Web開発 2026年5月8日

Supabase のコンプライアンス対応 — ISO 27001 / SOC 2 / HIPAA / GDPR の現状

Supabase の取得認証・コンプライアンス対応状況を整理する。SOC 2 Type II / ISO/IEC 27001 / HIPAA BAA / GDPR / DPA / Data Residency など、実務で採用判断に必要な要点を一次ソース付きでまとめる。

本稿は 2026-05-08 時点 の Supabase 公式ドキュメントおよび Trust Center の記載内容にもとづく。認証スコープや適用プランは更新されることがあるため、採用判断の前には必ず一次ソースを再確認すること。

この章の要点

  • Supabase は SOC 2 Type 2 / ISO/IEC 27001:2022 / HIPAA / PCI DSS / GDPR に対応していると Trust Center 上で明示している。
  • SOC 2 レポートと ISO 27001 証明書は Team / Enterprise プランの顧客に限り、ダッシュボードの Legal Documents から取得できる。
  • HIPAA は BAA 締結 + HIPAA add-on によって有効化する仕組みであり、Free / Pro 単独では PHI を扱えない。
  • 全プロジェクトには Point-in-Time Recovery、SSL 強制、ネットワーク制限など追加のセキュリティ要件が課せられる。
  • 認証取得はあくまでクラウド事業者側の責任範囲を保証するもので、RLS・アクセス管理・アプリ層の暗号化などは利用側の責任として残る。

Supabase のコンプライアンスとは

Supabase はマネージド PostgreSQL を中核に据えた BaaS（Backend as a Service）であり、AWS 上に自社のサービスを展開するクラウド事業者である。そのため Supabase 自身が独立したコンプライアンスプログラムを保有し、毎年外部監査機関の評価を受けて取得認証を更新している。

採用判断においてコンプライアンスが効くのは、企業内のセキュリティ部門・法務部門が要求する「ベンダー評価チェックリスト」に直接的な回答を与えられるためである。SOC 2 や ISO 27001 を取得していないバックエンドサービスは、エンタープライズ案件や医療・金融領域の案件において、評価フェーズで落選する可能性が高い。Supabase は Firebase / PlanetScale / Neon など競合と並び、これらの認証を一通り揃えることで「採用できる SaaS」のリストに入っている。

ただし重要な前提として、クラウドサービスは 共有責任モデル（Shared Responsibility Model） で運用される。Supabase 側はインフラ・プラットフォーム・SOC 2 統制の維持を担うが、テーブル設計・RLS・API キー管理・アクセス権限などアプリ側の安全性は利用者の責任となる。「Supabase が SOC 2 を取っているから自社サービスも安全」という単純な構図にはならない点を最初に押さえておく必要がある。

何が解説されているか（公式ページの俯瞰）

公式ドキュメントとセキュリティ関連ページは、概ね次のように整理されている。

カテゴリ主な公式ページ概要
Trust Centertrust.supabase.io取得認証・ポリシー・サブプロセッサ等を一元集約するハブ。SOC 2、ISO/IEC 27001:2022、HIPAA、PCI DSS、GDPR の対応状況を掲載
Security トップsupabase.com/security暗号化（AES-256 at rest / TLS in transit）、侵入テスト、Cloudflare による DDoS 防御、自動バックアップなどの要点を概観
Security Guidesdocs/guides/security各認証ガイドへの入口。「すべてのプロジェクトが同じ統制下に置かれる」と明示
SOC 2docs/guides/security/soc-2-complianceSOC 2 Type 2 の監査期間、レポート取得方法、顧客側の責任範囲
HIPAAdocs/guides/security/hipaa-complianceBAA、ePHI の扱い、Self-hosted は対象外である旨
HIPAA Projectsdocs/guides/platform/hipaa-projectsHIPAA add-on の有効化、High Compliance 設定、PITR・SSL 強制・ネットワーク制限の必須要件
Shared Responsibilitydocs/guides/platform/shared-responsibility-modelSupabase 側 / 顧客側それぞれの責任を明示
Privacy / DPAsupabase.com/privacy ・ supabase.com/legal/dpaGDPR、データ処理者契約、EU/UK 居住者の権利、SCC（標準契約条項）に基づく国際移転
Regionsdocs/guides/platform/regionsプロジェクト作成時のリージョン選択。General regions と Specific regions の二種類

なお docs/guides/platform/compliance docs/guides/platform/data-residency といった単独パスは 2026-05-08 時点で 404 を返す。コンプライアンス情報は Trust Center と Security ガイド配下に分散していると理解しておくのが現実的である。

使い方（実務で採用判断にどう使うか）

1. Trust Center で取得認証を確認する

最初の入口は https://trust.supabase.com/（trust.supabase.io にリダイレクトされる）である。ここに掲載されている認証一覧（SOC 2 Type 2 / ISO/IEC 27001:2022 / HIPAA / PCI DSS / GDPR）が、社内のベンダー評価シートに転記する一次ソースとなる。証明書本体（SOC 2 レポートや ISO 27001 証書）の PDF は、Team / Enterprise プラン契約後にダッシュボードの Legal Documents から取得する。Free / Pro プランでは閲覧できない点に注意する。

2. HIPAA を有効にする

医療データを扱う場合、次の手順を踏む。

  1. https://forms.supabase.com/hipaa2 から Supabase に問い合わせ、BAA を締結する。
  2. 組織で HIPAA add-on を有効化する（Team / Enterprise プランが前提）。
  3. 対象プロジェクトのダッシュボード一般設定で High Compliance をオンにする。
  4. Point-in-Time Recovery（small compute add-on 以上が必要）、SSL 強制、ネットワーク制限を有効化する。
  5. Security Advisor が指摘する警告をすべてクリアする。

Self-hosted Supabase は HIPAA の対象外である。マネージドプラットフォーム上でしか HIPAA 統制は提供されない。

3. GDPR DPA を取得する

EU/UK の個人データを扱う場合、supabase.com/legal/dpa から DPA（データ処理者契約） を確認する。Supabase は EU から米国・シンガポール等への国際移転について、欧州委員会が承認した 標準契約条項（SCC） を根拠としている。利用者は管理者（Controller）として、自社サービスのプライバシーポリシー・Cookie 同意・データ削除フローを別途整備する必要がある。

4. Data Residency（リージョン選択）

Supabase プロジェクトは作成時に単一の主リージョンへデプロイされる。General regions と Specific regions の 2 種類があり、後者では正確な AWS リージョンを指定できる。日本国内データの保管が必要なら ap-northeast-1（Tokyo）を選択する運用となる。リージョンの後からの変更については公式ドキュメントに明示がなく、現実的には新規プロジェクトを作成して移行するのが安全である。

5. セキュリティ Q&A への回答テンプレ

エンタープライズ案件のセキュリティ問診票は、概ね以下のテンプレで回答できる。

  • 「データは保管時・転送時に暗号化されているか」 → AES-256 at rest / TLS in transit（Security ページに記載）
  • 「SOC 2 / ISO 27001 を取得しているか」 → 双方取得済み。Team / Enterprise 契約により証憑提供可
  • 「侵入テストは実施されているか」 → 定期的に外部の専門家により実施。Vanta / Snyk による自動スキャンも併用
  • 「BAA は締結可能か」 → Team / Enterprise + HIPAA add-on で可
  • 「DPA は提供されるか」 → supabase.com/legal/dpa で公開、SCC ベース

注意点・セキュリティ観点

取得認証 ≠ 自社の責任が消える、ではない

SOC 2 公式ガイドにも「the data on the customer side of the boundary … is the responsibility of the customer」と明記されている。Supabase が SOC 2 を保有していても、自社サービスのコンプライアンスを別途証明する義務は消えない。エンタープライズ案件では多くの場合、自社側でも SOC 2 監査を受けることが求められる。

自社実装側で守るべき範囲

最低限、次の領域は利用者の責任として残る。

  • RLS（Row Level Security） の設計と適用。anon / authenticated / service_role の境界設計
  • API キー管理。service_role キーをクライアントに露出させない、Edge Functions・サーバーサイドのみで扱う
  • アプリ層の暗号化。特にセンシティブカラム（PHI、決済情報）を扱う場合のフィールドレベル暗号化
  • アクセス管理。組織メンバーへの権限付与、MFA 強制、退職者のアクセス剥奪
  • バックアップとリカバリ。Pro 以上で PITR を有効化し、復旧手順を定期的にテスト

これらは Shared Responsibility Model の「顧客側」に明記されている事項である。

Self-hosted は認証範囲外

Supabase の OSS スタックを自前のインフラで稼働させる Self-hosted モードは、当然ながら Supabase の SOC 2 / ISO 27001 / HIPAA の対象外である。Self-hosted を採用する場合、自社のインフラ全体に対して別途認証を取得する必要がある。

認証の有効期限・更新タイミング

SOC 2 Type 2 は毎年 3 月 1 日から翌年 2 月末までの 12 ヶ月間を監査期間としている。年次更新ベースで運用されているため、ベンダー評価時には最新レポートの監査期間を必ず確認する。ISO 27001 もサーベイランス監査と再認証監査の周期で運用されており、Trust Center 上の証書発行日が陳腐化していないかを採用判断時にチェックする運用が望ましい。

一次ソース（原文）