database-security

セキュリティ監査

行レベルセキュリティ（RLS）の適用、ゼロトラストデータベースアーキテクチャ、フォレンジック監査証跡を専門とするデータベースセキュリティ監査ツールです。Supabase、Postgres、Convex のデータレイヤーセキュリティに重点を置いています。一般的なアプリケーションセキュリティ（OWASP Top 10、認証パターン、セキュリティヘッダー、入力検証）には、代わりに security スキルを使用してください。

クイックリファレンス

必要な項目	アプローチ
RLS の適用	すべての public テーブルで有効にし、操作ごとにポリシーを分けます
RLS のパフォーマンス	RLS の列にインデックスを付け、auth.uid() を (select ...) サブクエリで囲みます
ゼロトラスト DB	マイクロセグメンテーション、ID の伝播、TLS の適用
RLS での Supabase 認証	(select auth.uid()) と auth.jwt() を使用し、auth.role() は決して使いません
Convex の認証ガード	すべての公開関数で ctx.auth.getUserIdentity() を呼び出します
JIT アクセス	自動的に期限切れになる、時間制限付きの権限付与
監査証跡	不変の audit_log テーブルを使用したデータベーストリガー
PGAudit	ステートメントレベルおよびオブジェクトレベルの SQL 監査用拡張機能
サービスロールの安全性	クライアント側のコードで service_role キーを決して使用しません
ビューと RLS	RLS を適用するには security_invoker = true（Postgres 15+）を使用します
スキーマのセグメント化	public、private、audit の各スキーマを分離します
データベースコンプライアンス	RLS + 監査ログ + 暗号化により、複数のフレームワークに準拠できます

監査プロトコル

データベースのセキュリティ監査を行う際は、次の手順に従ってください。

1. 攻撃対象領域のマッピング：データレイヤーへのすべてのエントリーポイント（公開 API、内部ダッシュボード、AI エージェント、cron ジョブ）を特定します
2. RLS の適用範囲の確認：pg_tables を照会し、public スキーマ内のすべてのテーブルで RLS が有効になっており、適切なポリシーが設定されていることを確認します
3. ポリシーのレビュー：論理的な回避策、WITH CHECK 句の欠落、過度に許容的な FOR ALL ポリシーがないか確認します
4. サービスロールの監査：クライアントコードで service_role キーが公開されていないか検索し、サーバー側のコードにのみ存在することを確認します
5. 関数の監査：公開スキーマ内の security definer 関数、および認証ガードが欠けている Convex 関数を確認します
6. アクセスのシミュレーション：anon および authenticated ロールとしてクエリを実行し、適用状況を確認します
7. ビューの監査：ビューで security_invoker = true が使用されていること、または公開スキーマに含まれていないことを確認します
8. 監査証跡の検証：トリガーまたは PGAudit により、セキュリティに関連するすべての操作が記録されていることを確認します
9. コンプライアンスの検証：データベースの制御を、適用される規制フレームワークに照らし合わせます

セキュリティの原則

原則	データベースでの適用例
多層防御	RLS + アプリケーションのチェック + スキーマのセグメント化
最小権限	ロールごとに最小限の GRANT を設定し、anon のアクセス権限をほぼゼロにします
ゼロトラスト	内部リクエストでも、DB レベルで ID を検証します
デフォルトでセキュア	作成時に RLS を有効にし、ポリシーがない場合はデフォルトで拒否します
セキュアなフェイル	Postgres の RLS ではデフォルトで拒否し、一般的なエラーレスポンスを返します
侵害を前提とする	攻撃者が有効な JWT を持っていると想定して設計します

アンチパターン

アンチパターン	リスク
隠蔽によるセキュリティ（UUID のみ）	攻撃者が IDOR 経由で ID を列挙する
機密テーブルに対する anon ロールの SELECT 権限	Supabase API 経由で公開データが漏えいする
インデックスのない RLS 列	本番環境のパフォーマンスが低下する（100 倍以上）
フロントエンドのみでの権限チェック	攻撃者が直接 API を呼び出して回避する
恒常的な管理者権限	侵害された場合の影響範囲が過剰に広がる
クライアント側コード内の service_role キー	すべての RLS ポリシーを完全に回避する
操作ごとのポリシーではなく FOR ALL ポリシー	広範なルールによって意図しない書き込み権限が生じる
public スキーマ内の security definer 関数	API から関数を呼び出せるため、RLS を回避する
security_invoker のないビュー	ビューが気付かれないまま RLS を回避する

よくある間違い

間違い	正しいパターン
auth.uid() = user_id を (select ...) で囲まずに使用する	(select auth.uid()) = user_id を使用し、Postgres が initPlan 経由で結果をキャッシュできるようにする
操作ごとに分けず、FOR ALL を使用する	明確さと安全性のため、SELECT、INSERT、UPDATE、DELETE ごとに個別のポリシーを作成する
機密テーブルに anon ロールの SELECT 権限を残す	anon のアクセスを制限し、機密データには authenticated ロールを必須にする
UUID のみをアクセス制御として頼りにする	一意の識別子と併せて RLS ポリシーと明示的な認証チェックを適用する
RLS の USING 句で使用される列にインデックスがない	RLS ポリシー式で参照されるすべての列に B-tree インデックスを追加する
Convex 関数に ctx.auth.getUserIdentity() の呼び出しがない	すべてのパブリッククエリとミューテーションで、データにアクセスする前に ID を検証する
クライアント側コード内で service_role キーを使用する	クライアント側では anon キーを使用し、service_role はサーバー側関数でのみ使用する
security_invoker を設定せず、ビューが RLS を回避している	Postgres 15 以降では、ビューに security_invoker = true を設定する
公開スキーマ内に security definer 関数がある	security definer 関数を非公開スキーマに配置し、search_path = '' を設定する
セキュリティに関わるデータベースイベントの監査ログがない	トリガーと PGAudit を使用して、すべてのデータアクセスと変更を記録する

セキュリティスキルとの関係

application-security スキルは、OWASP Top 10、認証パターン、入力検証、セキュリティヘッダー、コンプライアンスの概要など、一般的なアプリケーションセキュリティを扱います。この database-security スキルは、RLS ポリシーの設計とパフォーマンス、Supabase／Postgres 固有のパターン、Convex の認証ガード、PGAudit の設定、データベース固有のコンプライアンス実装（GDPR 消去用の SQL 関数、HIPAA PHI 監査トリガーなど）に焦点を当て、これを補完します。

委任

• アクセスシミュレーションで RLS の適用を検証する：Task エージェントを使用して、すべての公開テーブルに対する匿名および認証済みのクエリを実行します
• 認証ガードが欠落した Convex 関数を監査する：Explore エージェントを使用して、すべてのクエリおよびミューテーションのハンドラーを調べ、getUserIdentity の呼び出しを確認します
• ゼロトラストのデータベースアーキテクチャを設計する：Plan エージェントを使用して、スキーマ、アクセス ポリシー、JIT 付与、監査ログの設計を整理します
• データベースのコンプライアンス証跡を生成する：Task エージェントを使用して監査クエリを実行し、コンプライアンスレポートを作成します

参考資料

• rls-performance.md -- RLS ポリシーのパフォーマンス、initPlan キャッシュ、安定関数、個別ポリシー、EXPLAIN によるベンチマーク
• zero-trust-database.md -- マイクロセグメンテーション、ID の伝播、接続セキュリティ、JIT アクセス制御
• audit-logging.md -- トリガーベースの監査、PGAudit 拡張機能とログクラス、ログの完全性、改ざん防止ストレージ
• convex-security.md -- ID の検証、関数内での手動 RLS、粒度の細かい関数、JWT クレームによるロールベースのアクセス制御
• threat-modeling.md -- データベースアクセスに適用する STRIDE、RLS のバイパス経路、データレイヤーの信頼境界
• application-security.md -- サービスロールの管理、スキーマの公開、security definer 関数、ビューと RLS
• compliance-frameworks.md -- データベース固有の GDPR、HIPAA、SOC2、PCI-DSS 要件と SQL 実装