行レベルのセキュリティは、データを保護する Supabase プロジェクトと、データを静かに公開するプロジェクトの間の境界線です。 RLS が適切に構成されている場合、データベースは、RLS の対象となるロールに対して行レベルでアクセス ルールを適用します。サービス ロールを含む特権ロールは、これらのルールをバイパスできます。構成が不適切な場合、テーブルは保護されているように見えますが、ポリシーによって意図した以上の透過が許可されます。
この記事では、Supabase RLS セキュリティ チェックを実行する 2 つの方法、つまりポリシーを手動で検証する方法と自動 RLS 監査を実行する方法を比較します。どちらにも場所があります。それぞれの原因がどこにあるのかを知ることで、データベース アクセス ポリシーが意図したとおりに機能することを確認できます。
行レベルセキュリティの仕組みと、ポリシーが密かに間違っている場所
RLS は、Supabase がテーブルごとに公開する Postgres 機能です。有効にすると、ポリシーで許可されていない限り、テーブルは RLS の対象となるロールへの行アクセスを拒否します。テーブル所有者とバイパス権限を持つロールは例外です。ポリシーは、現在のユーザー、そのクレーム、および実行されているクエリに対して評価されます。の auth.uid() 通常、関数はアンカーです。次のようなポリシーです。 using (auth.uid() = user_id) サインインしているユーザー自身のデータベース行へのアクセスを制限します。
モデルはきれいです。失敗は失敗に見えないため、失敗ではありません。
RLS の問題のほとんどは、いくつかのパターンで説明されます。
RLS はすべてのテーブルではなく、一部のテーブルで有効になっています。 起動後に追加された新しいテーブル、または移行によって作成されたテーブルは、RLS をオフにして出荷できます。すべての行は、テーブルにアクセスできる任意のロールで読み取り可能になります。
読んでいる以上に幅広い政策。
using (true)選択ポリシーでは、すべての行が表示されることを意味します。開発中にデバッグのために追加し、削除し忘れるのが簡単です。あらゆる場所で想定されるサービスの役割。 サービス ロール キーを使用するサーバー側コードは、RLS を完全にバイパスします。ユーザー向けのリクエストがそのキーを介して実行される場合、ポリシーは決して適用されません。
間違った列をチェックするポリシー。
auth.uid() = idテーブルの上でid行の主キーであり、所有者ではありません。意図と一致することはありません。ポリシーは存在し、エラーまたは空のセットを返しますが、サーフェスは引き続き動作します。適切なアクセス制御を行わないデータベースの更新と削除。 開発者は、選択を徹底的に保護し、書き込みポリシーを緩くしたままにすることがよくあります。読み取りチェックに合格しても、次に誰が行を変更できるかについては何もわかりません。
これらはいずれも自ら発表するものではありません。それぞれがアプリの動作を維持するため、本番環境まで存続します。
手動による RLS 監査の実施: 検査対象と見逃されるミス
手動監査は直接的なものであり、新しいツールは必要ありません。ポリシー自体を表ごとに確認していきます。
まず、すべてのテーブルをリストし、それぞれのテーブルで RLS が有効になっていることを確認します。次に、テーブルごとにポリシーを列挙し、目的のアクセス (誰が読み取り、誰が書き込み、誰が決して触れてはならない) にマップします。各ポリシー式を、それが比較する列に対して読み取ります。選択、挿入、更新、および削除のそれぞれに、意図したロールと一致するポリシーがあることを確認します。
次に、コードパスを確認します。アプリケーションがユーザー向けのリクエストに実際に使用するキーと、それらのキーがサービス ロールを介して実行されるかどうかを判断します。次に、別のユーザーとしてテスト クエリを作成し、結果が期待どおりであることを確認します。ユーザーは自分の行を読み取る必要があり、他のユーザーの行を読み取る必要はなく、所有していない行を更新することはできません。
手動レビューは行う価値があり、多くのことがわかります。予測可能な盲点もあります。
テストすることを覚えているものをテストします。 2 番目のユーザーとして削除を試行しようと考えていない場合は、広範すぎる削除ポリシーを見逃す可能性があります。 RLS が有効になっている場合、該当する削除ポリシーがないため、削除は拒否されます。
それは老化します。 機能が追加されるとポリシーが変化します。前四半期に徹底的に行われたレビューでは、先週追加したテーブルについては何も述べられていません。
それはポリシーを構成したのと同じ人に依存します。 ポリシーを作成した構築者は、自分自身の仮定に気づく可能性が最も低いです。
記録された証拠が必要です。 「確認したところ、問題はなかった」と判断しても、後には何も残りません。証拠も範囲も、後で再スキャンできる成果物も何も残りません。
手動監査は、「これはシステムのメンタル モデルと一致しますか?」という質問に答えます。それ自体では、データベースが実際に何を返すかを証明するものではありません。
自動RLSチェックを実行し、結果に基づいて行動する
自動化された Supabase RLS セキュリティ チェックは、反対方向から機能します。攻撃者や設定を誤ったクライアントが行うのと同じ方法でプロジェクトを実行し、データ層で実際に許可されている内容を報告します。
この変化は 3 つの理由から重要です。まず、メモリを超えて拡張します。スキャンは、構成されたスコープ内で使用可能なテーブルとエンドポイント全体でチェックを繰り返します。外部スキャンでは、適切なアクセスがなければすべてのポリシーを検査できません。第 2 に、行動に移せる証拠が得られます。調査結果により、テーブル、ポリシーの状態、テーブルに到達可能になった条件の名前が示されるため、何を変更する必要があるか、そしてその理由がわかります。第三に、再現可能です。再度実行できるチェックにより、1 回限りのレビューが継続的な検証に変わります。
VICE は、Web アプリケーションと Supabase/RLS 構成をスキャンし、結果をその背後にある証拠と修正ガイダンスとともにレポートします。修正をマークして再チェックをリクエストできますが、問題が解決されたことを確認できるのは同等の再スキャンのみです。修正は編集から想定されたものではなく、同じスコープに対して検証されます。スケジュールされたスキャンとアラートは継続的な監視をサポートするため、来月追加されるテーブルによってギャップが再び発生することはありません。
役割分担は単純です。自動チェックを実行して手動レビューで見逃した部分を見つけてから、手動パスを使用してスキャン フラグの各ポリシーの背後にある意図を確認します。自動化により、データベースで何が許可されているかがわかります。その許可が意図的に行われたかどうかを判断するのはあなたです。
スキャンのスコアはテストされた範囲を表すものであり、プロジェクトが完全に安全であることを保証するものではありません。これを証明書ではなく、どこを見るべきかを示す信号として扱います。
どのアプローチを使用する必要がありますか?
Supabase で構築された製品を導入していて、ポリシーを監査したことがない場合、正直な答えは両方です。自動化された RLS チェックから始めて、テーブルで何が許可されているかについて証拠に裏付けられた最新の状況を把握します。次に、結果を手作業で調べ、各ポリシーの意図を確認し、逸脱したポリシーを修正します。自動チェックをスケジュールに入れて、新しいテーブルと新しいポリシーが元のテーブルと同じ精査を受けるようにします。
どちらのアプローチをスキップしても、データを保護しているように見えるデータベース アクセス ポリシーが残る可能性がありますが、依然として不正アクセスが許可されています。
無料スキャンを開始する Vice-platform.com にアクセスして、サインアップする前に公開 Web サイトを確認してください。特殊な Supabase スキャンには、検証済みのドメインと有料サブスクリプションまたは購入したクレジットが必要です。その範囲は、設定されたアクセスによって異なります。
