---
title: "Supabaseは安全？ Supabaseの担当と、あなたの担当"
description: "SupabaseはSOC 2 Type 2とISO 27001に準拠し、保管時も転送時も暗号化します。データが安全かどうかは、あなただけが管理する設定で決まります。"
url: "https://madsalt.tech/ja/blog/is-supabase-secure/"
author: "Denys Zaichenko"
language: "ja"
published: 2026-10-26
---

# Supabaseは安全？ Supabaseの担当と、あなたの担当

TL;DR

はい、プラットフォームは安全です。SupabaseはSOC 2 Type 2とISO 27001の認証を取得し、保管時のデータをAES-256、転送時のデータをTLSで暗号化し、TeamプランとEnterpriseプランでHIPAA契約も結びます。ただし、あなたのプロジェクトは別の問いです。Supabaseの責任共有モデルでは、テーブルへのアクセス、API keys、認証の設定はあなたの担当で、プラットフォームはその設定のとおりに動きます。私のローカルのテストテーブルでは、設定1つで、公開キーが0行を取るか3行すべてを取るかが決まりました。

Denysです。フルスタック・AIエンジニアで、私が作る、あるいは直すアプリのほとんどはSupabaseで動いています。クライアントが「Supabaseは安全ですか？」と聞くとき、実際には「自分のデータは安全ですか？」と聞いています。この2つは答えが違うので、この記事では1つずつ見ていきます。

## Supabaseのプラットフォームは安全？

プラットフォーム側は第三者の監査を受けています。2026年10月23日に読んだSupabaseの[セキュリティページ](https://supabase.com/security)と[セキュリティのドキュメント](https://supabase.com/docs/guides/security)によると、次のとおりです。

| コントロール   | Supabaseの記載                                                                         |
| -------------- | -------------------------------------------------------------------------------------- |
| SOC 2 Type 2   | 毎年監査を受ける。レポートはTeamとEnterpriseの顧客が利用可能                           |
| ISO 27001      | 認証取得済み。証明書はTeamとEnterpriseの顧客が利用可能                                 |
| HIPAA          | 署名済みのBusiness Associate AgreementとHIPAAアドオンで対応。Teamプラン以上            |
| 暗号化         | 保管時はAES-256、転送時はTLS。アクセストークンとキーはアプリケーションレベルでも暗号化 |
| バックアップ   | 有料プロジェクトは毎日。Point in Time RecoveryはProプラン以上でアドオン                |
| データの所在地 | データベース、Auth、Storageは、選んだAWSリージョンに留まる                             |

これらは、あなたが開けたままにしたテーブルを守ってくれません。[SOC 2のガイド](https://supabase.com/docs/guides/security/soc-2-compliance)ははっきり書いています。Supabaseのコンプライアンスは、Supabaseの管理外にあるものには引き継がれません。

## あなたの担当は何？

Supabaseの[責任共有モデル](https://supabase.com/docs/guides/deployment/shared-responsibility-model)は、常にあなたの担当となるものを挙げています。アカウント、データベースとそのテーブルへのアクセス管理、データ、そしてSecurity Advisorが出す警告を含むセキュリティコントロールの適用です。実際には、設定は4つの層になります。

![リクエストの各段階を守るのは誰か。通信とキーはSupabase、grantとポリシーはあなたの担当です。ブラウザから：ブラウザ → TLS・キー · Supabase → Grant · あなた → RLS · あなた、あなたのサーバーから：サーバー → TLS · Supabase → Secret key · あなた → RLSは素通り。](https://madsalt.tech/charts/ja/is-supabase-secure.svg)

*図1. Supabaseの責任共有モデルとAPI keysガイドに基づく、2026年10月。*

1. **誰がテーブルに触れるか。** grantは、`anon`と`authenticated`がそもそもテーブルに届くかを決めます。どの行かはRLSポリシーが決めます。
2. **どのキーをどこに置くか。** publishable keyは設計上公開で、secret keyはRLSを迂回します。2つの比較は[Supabase anon keyとservice role keyの違い](https://madsalt.tech/ja/blog/supabase-anon-key-vs-service-role-key/)にあります。
3. **認証の設定。** メール確認、leaked password protection（Proプラン以上）、パスワードの最小長、MFA、redirect URLs、CAPTCHAです。
4. **データベースの周辺すべて。** Storageのバケットとそのポリシー、`SECURITY DEFINER`関数、secret keyを使うEdge Function、そしてData APIがどのスキーマを公開するかです。

## 設定1つでどれだけ変わる？

ローカルのSupabaseスタック（CLI 2.109.1、Postgres 17.6、PostgREST 14.14）で、偽の注文3行のテーブルに対して、ブラウザと同じようにpublishable keyで同じリクエストを実行しました。

| テーブルの設定                  | 公開キーで取れたもの                     |
| ------------------------------- | ---------------------------------------- |
| RLSオフ                         | 3行すべて。INSERTは`201 Created`を返した |
| RLSオン、ポリシーなし           | `[]`                                     |
| RLSオン、ポリシー`using (true)` | 3行すべて                                |
| `anon`へのgrantなし             | `42501 permission denied`                |

同じプラットフォーム、同じ暗号化、同じ認証。違いはSQLの1行です。だから「安全なプラットフォーム」と、データが漏れるアプリは矛盾しません。[CVE-2025-48757](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/)では、Lovableのショーケースアプリ1,645件のうち170件が公開キーにデータを返していましたが、すべて同じ監査済みのプラットフォーム上のものです。

## Supabaseはデフォルトで安全になってきている？

はい、段階的に。[2026年4月28日のSupabaseのchangelog](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically)には、RLSをデフォルトでオンにするトグル、Data APIの公開バッジ、テーブル単位の細かなgrant、スキーマ列挙の制限が挙げられています。最も大きい変更は2026年10月30日に来ます。既存プロジェクトの新しいテーブルには、Data APIのgrantが自動で付かなくなるので、うっかり忘れたテーブルは、行の代わりに`42501`を返します。既存のテーブルはgrantを維持するので、すでに開いているものはこれでは直りません。従来の`anon`と`service_role`のキーも、publishable keyとsecret keyに置き換える形で2026年末までに非推奨になります。新しいsecret keyは、ブラウザからのリクエストを拒否します。

切り替えで他に何が壊れるか、事前の確認方法は[Supabase 10月30日のgrant変更：壊れる点と確認方法](https://madsalt.tech/ja/blog/supabase-october-30-grant-change/)にまとめました。

## 自分のプロジェクトをどう確認する？

まずSupabase自身のSecurity Advisorを使い、すべての警告を修正します。そのうえで、それがカバーしないものを確認します。

- 無料の[Supabase セキュリティチェック](https://madsalt.tech/ja/tools/supabase-security-check/)を実行します。読み取り専用で接続し、OWASP Top 10:2025に対応する46のルールでプロジェクトを評価します。RLS、ポリシー、ビュー、関数、grant、ストレージ、認証の設定が対象で、各指摘に修正SQLが付きます。
- 2社の2人のユーザーでテストします。どの行が誰のものかをスキャナーは知りません。テストの方法は[Lovableアプリのセキュリティチェックリスト](https://madsalt.tech/ja/blog/lovable-app-security-checklist/)にあります。
- アプリにロールと権限画面があるなら、[Supabase RLSのテスト方法](https://madsalt.tech/ja/blog/how-to-test-supabase-rls/)のように、権限のチェックボックスが表示どおりに動くことを証明します。

つまり、Supabaseはデータを置く場所として安全で、データを非公開に保つ道具も用意されています。実際に非公開のままかどうかは、あなたのスキーマと設定で決まります。

プロジェクトでSupabaseを検討していますか？

まず何を設定するか、情報交換できれば嬉しいです。売り込みはありません。

[お問い合わせ](https://madsalt.tech/ja/#contact)