行レベルセキュリティとは何ですか？

行レベルセキュリティ（RLS）とは、ユーザーの識別情報、ロール、またはセッションコンテキストに基づいて、ユーザーが読み取りまたは変更できるテーブルの行を制限するデータベースのアクセス制御です。

RLSは、テーブル全体や特定の列へのアクセスを制限するのではなく、データを行ごとにフィルタリングします。データベースエンジンはクエリ実行時にフィルターを自動的に適用するため、ユーザーがデータへのアクセスにどのツールを使用しても、同じルールが適用されます。

RLSは、以下のようなきめ細かなアクセス制御の一部です。

• 列レベルセキュリティ
• データマスキング
• テーブルレベルの権限付与

例えば、営業担当者が会社の注文テーブルにクエリを実行する場合、テーブルにすべての地域のデータが含まれていても、自分が担当する地域の注文のみを表示できます。ユーザーは通常の SELECT ステートメントを記述するだけで、エンジンは表示が許可されている行のみを返します。

RLSは現在、マルチテナントSaaS、地域ごとのデータ分離、コンプライアンスのユースケースにおける中核的な構成要素となっています。この記事では、RLSの仕組み、役立つ場面、不十分な点、そしてDatabricksプラットフォームでの仕組みについて説明します。

行レベルセキュリティの仕組み

行レベルセキュリティは、ポリシーや述語（プレディケート）と呼ばれるフィルタールールをテーブルに適用することで機能します。ユーザーがクエリを実行すると、データベースエンジンは自動的にそのフィルターを適用し、ユーザーが表示を許可されている行のみを返します。

実際には、RLSは通常、次の3つのステップで機能します。

1. ユーザーがクエリを実行する：ユーザーは、自身でセキュリティフィルターを追加することなく、標準的なクエリを記述します。
2. データベースがユーザーの識別情報を確認する：エンジンは、CURRENT_USERのような組み込み関数、アプリケーションによって設定されたセッション変数、またはユーザーやグループを許可されたデータに関連付けるマッピングテーブルを介して、ユーザーを評価します。
3. エンジンが結果をフィルタリングする：RLSの述語は、ユーザーが表示できる行に対してはTRUEを返し、それ以外に対してはFALSEを返します。述語を通過した行のみが返されます。

適用はデータベースレイヤーで行われるため、BIダッシュボード、ノートブック、アドホックSQL、API、サードパーティツールなど、あらゆるアクセスパスにわたって同じルールが一貫して適用されます。この一貫性こそがRLSの強力な点です。1つのルールがすべての場所に適用され、エンジンによって強制されます。

ほとんどのエンジンは、読み取り側と書き込み側の適用を区別します。読み取りの述語は、SELECTクエリが返す内容を制御します。書き込みの述語は、多くの場合WITH CHECK句を使用して個別に定義され、ユーザーが挿入、更新、または削除できる行を制御します。

2つの述語は同じでも構いませんが、同じである必要はありません。例えば、ユーザーはすべての地域の行を読み取ることは許可されていても、自身の地域の行のみを挿入することしか許可されない場合があります。テーブルが書き込みを受け入れる場合、両方を定義することが重要です。書き込みチェックの省略は、本番環境でチームがRLSの設定を誤る最も一般的な原因の1つだからです。

行レベルセキュリティ vs. 列レベルセキュリティおよびその他のアクセス制御

RLSは、いくつかあるきめ細かなアクセス制御の1つであり、本番環境ではほぼ常に他の制御と組み合わせて使用されます。以下の表は、それぞれの制御がどのように適合するかを示しています。

これらの制御は、レイヤー状に重ねて適用するように設計されています。一般的な設定では、テーブルレベルの権限付与を使用してテーブルにアクセスできるユーザーを制御し、RLSを使用して表示可能な行の範囲を制限し、列レベルセキュリティまたはデータマスキングを使用してそれらの行の中の機密フィールドを保護します。これらを代替手段のメニューとしてではなく、スタックとして扱うことで、ガバナンスの監査が容易になり、回復力も高まります。1つのレイヤーで設定ミスが発生しても、他のレイヤーが損なわれることはありません。

行レベルセキュリティの一般的なユースケース

RLSは、共有テーブル内で誰が何を表示できるかを強制するための標準的な方法であり、地域、テナント、分類などのキー列に対してユーザーの属性に基づいて行をフィルタリングします。ほとんどのチームは、1つのデータセットが異なる表示ルールを持つ複数の対象者にサービスを提供する必要がある場合に、これを利用します。

• マルチテナントSaaS：tenant_id列とセッションコンテキストを使用して、共有テーブル内の各顧客のデータを分離します。これにより、テナントごとに1つのスキーマまたは1つのデータベースを用意する運用コストを回避しながら、クエリ実行時に各顧客のデータを完全に分離できます。
• 地域ごとの分離：売上、HR、または注文データを制限して、地理的に基になるテーブルを分割することなく、ユーザーが自分の国または地域のレコードのみを表示できるようにします。
• 部門ごとのアクセス：財務、マーケティング、運用の各チームに同じテーブルへのアクセスを許可しますが、部門またはコストセンターの列によってマッピングされた異なる行へのアクセスを許可します。
• 規制コンプライアンス：データレジデンシー（データの所在）ルールを強制します。例えば、GDPRに基づいてEUのレコードをEU在住のスタッフのみに表示するようにしたり、HIPAA、CCPA、または業界固有の規制に基づいて保護されたカテゴリを制限したりします。
• ヘルスケアおよび臨床データ：臨床医が患者テーブルを共有しながら、自身の患者のみを表示できるようにし、サイロ間でレコードを重複させることなく、HIPAAの必要最小限のアクセスをサポートします。
• パートナーおよびベンダーポータル：外部パートナー間で単一のデータセットを共有しながら、それぞれを独自のレコードにフィルタリングすることで、1つの信頼できる唯一の情報源（Source of Truth）テーブルから、パートナー向けの多数のビューを構成できます。

行レベルセキュリティを実装する方法：4つのステップ

一般的なパターンはプラットフォーム間で一貫しており、必要に応じてベンダー固有の構文が入力されます。

1. フィルターロジックを特定する：ユーザーID、グループメンバーシップ、地域、テナントID、またはマッピングテーブルなど、アクセスを決定する要素を決定します。フィルターロジックは、ユーザーがクエリ実行時に制御する値からではなく、セッションコンテキストまたは安定したルックアップから導出できる必要があります。
2. キー列を追加または確認する：テーブルに、tenant_id, regionやowner_idなど、フィルターが使用できる列があることを確認します。そのような列がまだ存在しない場合は、ポリシーが有効になる前にバックフィルを計画し、述語のコストを低く抑えるために列のインデックス作成を検討してください。
3. ポリシーまたは行フィルターを定義する：ユーザーが表示を許可されている行に対してTRUEを返す述語を記述し、テーブルが書き込みを受け入れる場合は書き込み用の個別のチェックを記述します。可能な限りロジックはSQLで記述してください。ほとんどのエンジンは、他の言語への関数呼び出しよりもSQLの述語を適切に最適化します。
4. 複数のユーザー識別情報でテストする：異なるロールとしてクエリを実行し、正しい行が表示され、テナント間で何も漏洩していないことを確認します。ネガティブテストも含めてください。一致する行がないユーザーにはエラーではなく空の結果が表示される必要があり、特権ユーザーは個別にテストしてオーナーバイパスの動作を確認する必要があります。

行レベルセキュリティのメリット

アクセスロジックをデータレイヤーに移行することには、いくつかの実用的なメリットがあります。簡単に言えば、データに触れるすべてのアプリケーションではなく、データベースがアクセスの信頼できる唯一の情報源（Source of Truth）になります。

• ロジックの一元化：アクセスルールはデータとともに存在し、アプリケーションコードやBIツールに分散することはありません。
• 一貫した適用：ユーザーがノートブック、ダッシュボード、またはAPIのどこからクエリを実行しても、同じルールが適用されます。
• 多層防御：アプリレイヤーのチェックがバイパスされたり、バグがあったりした場合でも、RLSが第2の保護レイヤーを追加します。
• アプリケーションコードの簡素化：開発者は、すべてのクエリに手動でWHERE句を追加する必要がありません。
• 監査の容易化：コンプライアンスチームは、システム全体でアクセスロジックを追跡する代わりに、1つのポリシーを確認するだけで済みます。

行レベルセキュリティの制限事項とリスク

RLSは強力ですが、チームが事前に対策を立てておくべき、よく知られた落とし穴があります。これらのほとんどは、本番環境や監査の際になって初めて明らかになるため、事前に把握しておく価値があります。

管理者および所有者によるバイパス

多くのデータベースでは、テーブルの所有者や高権限の管理者は、デフォルトでRLSをバイパスします。たとえばPostgreSQLでは、テーブル所有者にポリシーを適用するためにFORCE ROW LEVEL SECURITY設定が必要であり、他のエンジンにも同様の設定が存在します。これは監査でよく指摘される事項です。設定で明示的にポリシーの適用を強制しない限り、特権ユーザーはすべての行を表示できると想定してください。承認する前に、通常のセッションだけでなく、特権セッションからもポリシーをテストしてください。

列やサマリーの非表示化は不可

RLSは行をフィルタリングしますが、列を非表示にしたり、集計結果をブロックしたりはしません。RLSが列や集計の制限と組み合わされていない場合、個々のEUレコードの表示をブロックされているアナリストであっても、フィルタリングされていないテーブルに対してSELECT COUNT(*)を実行できてしまいます。このギャップを埋めるために、RLSを列レベルセキュリティやデータマスキングと組み合わせ、最も機密性の高いテーブルについては集計クエリ自体を管理する必要があるかどうかを検討してください。

パフォーマンスのオーバーヘッド

すべてのクエリにRLSの述語（プレディケート）が適用されるため、フィルターロジックが複雑な場合や、キーとなる列にインデックスが作成されていない場合、パフォーマンスが低下する可能性があります。ポリシーが参照する列にインデックスを作成し、述語をできるだけシンプルに保ちます。フィルター内でのサブクエリやマッピングテーブルのルックアップよりも、シンプルなCASE式を優先してください。エンジンがサポートしている場合は、ユーザーと行のマッピングをオンザフライで計算するのではなく、インデックスが適切に作成された小さなテーブルにマテリアライズ（実体化）します。

デバッグの複雑さ

RLSによって結果セットが空になった場合、「一致するデータなし」とまったく同じように見えます。存在しない行を探している開発者は、ポリシーによってそれがフィルタリングされたことに気づくまでに、何時間も費やすことがよくあります。開発中は有効なユーザーIDとポリシーのバージョンをログに記録し、結果が正しくないように見える場合にRLSが有効かどうかをエンジニアが確認できるようにし、ポリシーをテーブルスキーマと同じ場所に文書化して見つけやすくします。

書き込みルールの設定ミス

RLSポリシーには通常、ユーザーが読み取れる内容をフィルタリングするUSING句と、挿入または更新できる内容を制御するWITH CHECK句の2つの側面があります。一方を定義せずにもう一方だけを定義するのは、よくある間違いです。書き込みチェックのない読み取りフィルタリングでは、ユーザーが所有すべきでない行を挿入または更新できてしまいます。テーブルが書き込みを受け入れる場合は常に両方を定義し、ポリシーレビューの一環として書き込み側のテストを実行してください。

Databricksプラットフォームにおける行レベルセキュリティ

Databricksプラットフォームでは、データとAIのための統合ガバナンスレイヤーであるUnity Catalogの行フィルターを通じて行レベルセキュリティが処理されます。そのパターンはシンプルです。特定のユーザーの表示が許可されている行に対してtrueを返すSQLユーザー定義関数を定義し、それを対象のテーブルにアタッチします。フィルターはクエリ実行時に自動的に実行され、現在のユーザーのIDまたはセッションコンテキストを使用して、返す行を決定します。

行フィルターは、Databricks SQL、ノートブック、ジョブ、および接続されたBIツール全体で一貫して適用され、インターフェースごとのカスタムロジックは必要ありません。これらは列マスクと連携して完全なきめ細かいアクセス制御を実現し、フィルターされたテーブルにアクセスするすべてのクエリがUnity Catalogのリネージと監査ログに記録されるため、ガバナンスチームやセキュリティチームは、どのポリシーがどのテーブルに適用され、どのユーザーが何をクエリしたかを正確に把握できます。

よくある質問

動的行レベルセキュリティとは何ですか？ 動的RLSは、現在のユーザーのIDまたはセッションコンテキストを使用してクエリ実行時にアクセスルールを評価するため、同じポリシーであってもユーザーによって異なる結果が返されます。DatabricksのABACポリシー、行フィルター、動的ビューなど、最新のRLS実装はすべてこのように動作します。

行レベルセキュリティと列レベルセキュリティの違いは何ですか？ RLSはユーザーが表示できる行を制限し、列レベルセキュリティは列を制限します（通常、給与や社会保障番号などの機密フィールドを非表示にするため）。ほとんどの本番環境のデプロイでは、両方を組み合わせて使用します。

機密データを保護するには、行レベルセキュリティだけで十分ですか？ いいえ。RLSは行の可視性を処理しますが、列の値のマスキング、集計クエリのブロック、またはアイデンティティとアクセス管理の代替を行うものではありません。多層防御戦略の一環として、列レベルセキュリティ、テーブルレベルの権限付与、監査ログと組み合わせてください。

Databricksはどのように行レベルセキュリティを実装していますか？ Unity Catalogを通じて、ABACポリシー、テーブルレベルの行フィルター、動的ビューの3つのオプションを提供しています。大規模なガバナンスにはABACが推奨され、より個別化されたニーズには行フィルターと動的ビューが利用可能です。

行レベルセキュリティはクエリのパフォーマンスに影響しますか？ はい、影響しますが、通常はその影響を管理可能な範囲に抑えることができます。ポリシーのロジックをシンプルに保ち、ポリシーが参照する列にインデックスを作成し、Python UDFよりもSQL UDFを優先してください。ポリシーの変更前後にクエリのプロファイリングを行い、パフォーマンスの低下を早期に検出します。

Databricksでのきめ細かいアクセス制御の開始

行レベルセキュリティは、列、マスキング、リネージ、監査もカバーする、より広範なガバナンスモデルの一部として最も効果的に機能します。 Unity Catalogが、どのように行レベルセキュリティ、列マスキング、統合ガバナンスをDatabricksプラットフォーム上で統合しているかをご覧ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事