ポリシーの評価とランタイムの動作

このページでは、ABAC クエリ実行時に評価される方法について説明します。これには以下が含まれます。

• 複数のポリシー間の矛盾はどのように処理されるか
• 列マスク型キャストの仕組み
• ポリシーが依存するタグや関数が削除された場合、データ漏洩を防ぐための安全対策はどのようなものか

ポリシーの評価と施行

ユーザーがテーブルに対してクエリを実行すると、ABACの評価はUnity Catalogでのポリシー評価とDatabricks Runtimeでのポリシー適用という2つの段階で進行します。

ポリシー評価はユーザーのID、グループメンバーシップ、およびアクセスするデータに付けられたタグによって異なるため、同じクエリでもユーザーによって異なる結果が表示される場合があります。グループメンバーシップやタグ割り当ての変更は、クエリ実行時に有効なポリシーを動的に変更します。

ポリシー評価 ( Unity Catalog )

Unity Catalogセキュリティ保護可能なオブジェクトのメタデータ (管理タグの割り当てなど) と、ユーザーの ID およびグループ メンバーシップのクエリを使用して、次のステップを実行します。

1. クエリ対象のテーブルをスコープとするすべてのポリシーを識別します。
2. これらの各ポリシーについて、クエリを実行したユーザーがTOリストに含まれており、 EXCEPTリストには含まれていないかどうかを確認します。
3. 各ポリシーについて、クエリ対象オブジェクトのタグ（継承されたタグを含む）に対して、テーブルおよび列の条件を評価します。列条件は少なくとも1つの列と一致する必要があります。
4. が適用される場合、有効な行フィルタまたは列マスクを決定し、テーブルメタデータの一部としてDatabricks Runtimeに送信します。

ポリシーの適用（Databricks Runtime）

Databricks Runtimeクエリプランナーは、有効な行フィルタまたは列マスクを、クエリ実行中にフィルタリングとマスキングを強制するテーブルスキャン上のセキュアビューに変換します。 これは、テーブルレベルの行フィルタや列マスクに使用されるのと同じ強制メカニズムです。

フェイルクローズ設計

ABACはフェイルクローズモデルを採用しており、Databricksはセキュリティを検証できない場合、デフォルトでアクセスを拒否します。Databricksは、適用されるすべてのポリシーを安全に実施できる場合にのみ、ABACで保護されたテーブルへのアクセスを許可します。これは、サポートされていないコンピュート バージョン、基になるテーブル データに対する特定の操作、およびポリシーの依存関係 (タグまたは関数) が削除された状況に適用されます。

サポートされていないコンピュートのバージョン

ABAC ポリシーには、 Databricks Runtime 16.4 以降、またはサーバレス コンピュートが必要です。 ユーザーがサポートされていないバージョンからABACで保護されたテーブルにアクセスしようとすると、保護されていないデータが漏洩するのを防ぐため、クエリは失敗して閉じられ（アクセスが拒否され）、アクセスが拒否されます。

専用アクセス モードでは、 Databricks施行をサーバレス コンピュートに委任して、きめ細かいアクセス制御が適用されることを保証します。 古いランタイムを使用しているユーザーがこれらのテーブルにアクセスできるようにするには、それらのユーザーをポリシーから明示的に除外する必要があります。

保護されたデータに対するサポートされていない操作

一部の操作は、行フィルターまたは列マスクと互換性がありません。これらの作戦は、法執行を回避するどころか、むしろ失敗に終わる。これらを実行するには、プリンシパルが、テーブルに適用されるすべての ABAC のEXCEPT句に記載されている必要があります。 免除対象のプリンシパルはポリシーの対象外であるため、Databricksはポリシーを強制する必要がなく、安全に操作を許可できます。

実行主体が免除される必要がある操作には、パイプラインの更新、バックアップ処理、および以下のような管理ワークフローが含まれます。

• 16.4 より前のDatabricks Runtimeバージョンを実行しているコンピュートから ABAC で保護されたテーブルにアクセスする
• タイムトラベルに関する質問
• 深層クローニングと浅層クローニング
• Delta Sharingでは、株主は の免除を受け、必要なDelta Sharing許可を得ている必要があります。 なお、このポリシーは受信者のアクセス権限を規定するものではありません。
• ベクトル検索インデックスの作成と同期

これらの制限事項およびその他の制限事項の詳細については、 「ABACの要件、割り当て、および制限事項」を参照してください。

ポリシーの依存関係を削除しました

ABAC ポリシーは管理タグと UDF に依存します。 これらの依存関係のいずれかが、ポリシーがまだ参照している状態で削除された場合、ポリシーのスコープ内のテーブルに対するクエリは失敗します。

管理タグの削除

ABAC ポリシーが参照する管理タグを削除すると、ポリシーが添付されているオブジェクトとその子オブジェクトに対するすべてのクエリがINVALID_PARAMETER_VALUE.UC_ABAC_UNKNOWN_TAG_POLICYエラーで失敗します。 これは、クエリ対象のテーブルにタグが適用されていない場合でも発生します。

管理タグを削除すると非管理タグとなります。 許可される値の制限が解除され、 APPLY TAG権限を持つユーザーは、 ASSIGN権限がなくても値を変更できます。

警告

UI とAPI 、ABAC ポリシーで参照されている管理タグの削除を妨げません。 管理タグを削除する前に、ABAC ポリシーがそれを参照していないことを確認してください。

エラーを解決するには、削除されたタグを復元するか、そのタグを参照しているポリシーを更新または削除してください。「管理タグの作成と管理」を参照してください。

タグが付けられた列を削除する

Databricksでは、管理タグが適用されている列の削除はできません。列を削除するには、タグにASSIGN 、オブジェクトにAPPLY TAGを持つユーザーがまずタグを削除してから、列を削除する必要があります。

これは、宣言型パイプラインや、テーブルスキーマを変更するその他の自動化されたワークフローに関係します。パイプラインがタグ付き列を削除しようとすると、操作は失敗します。パイプラインのブロックを解除するには、必要なタグ権限を持つユーザーがタグを削除し、スキーマ変更が成功するようにパイプラインを実行してから、関連する列にタグを再適用する必要があります。タグが再適用されない場合、ポリシーは依然として有効であるにもかかわらず、オブジェクトに期待されるタグが存在しないため、データに対するクエリは失敗します。

ポリシー参照機能の削除

ポリシーによって参照されている UDF が、ポリシーがまだ有効範囲内にある間に削除された場合、その範囲内のテーブルに対するクエリはUC_DEPENDENCY_DOES_NOT_EXISTで失敗します。解決するには、関数を復元するか、ポリシーを更新して別のUDFを参照するようにしてください。

複数のフィルターとマスクに関するルール

特定のテーブルとユーザーに対して、クエリ実行時に適用できる行フィルタは、1つのみです。同様に、特定の列とユーザーに対して、列ごとに解決できる列マスクは1つだけです。 特定の列とユーザーに対して。 これにより、曖昧な結果を防ぐことができます。

同じユーザーとテーブル（または列）に対して複数の異なるフィルタまたはマスクが適用される場合、Databricks はアクセスをブロックし、エラーを返します。例えば：

• テーブルレベルのフィルタまたはマスクがABACと競合します 。 既に手動で行フィルタまたは列マスクが適用されているテーブルまたは列は、同じ対象に対してABACで定義されたフィルタまたはマスクと競合します。
• 行フィルターのUSING COLUMNS句は、複数の列に一致するMATCH COLUMNSエイリアスを参照します。 USING COLUMNS句は列の値をUDFに渡します。USING COLUMNS句内のMATCH COLUMNSエイリアスが複数の列に一致する場合、エンジンはUDFに渡す列を判断できず、クエリはエラーで失敗します。
• マスクされた列が、別のポリシーのUSING COLUMNS句で参照されています。 あるポリシーによって列がマスクされている場合、その列は別のポリシーのUSING COLUMNS句の入力引数として使用することはできません。

複数のABAC 同じテーブルまたは列に対して、同じ有効なフィルタまたはマスクになる場合は、複数のABACを共存させることができます。 例えば、同じ引数で同じUDFを参照する2つのポリシーは、同じフィルタまたはマスクに解決され、競合しません。

ポリシーの競合のトラブルシューティング

Databricks は、特定のユーザーに対するポリシー評価中に複数の異なるフィルタまたはマスクを検出すると、 INVALID_PARAMETER_VALUE.UC_ABAC_MULTIPLE_ROW_FILTERSまたはCOLUMN_MASKS_FEATURE_NOT_SUPPORTED.MULTIPLE_MASKSエラーをスローし、競合が解決されるまでテーブルへのアクセスをブロックします。

診断と解決のため：

1. テーブルに適用されるすべてのポリシーを表示するには、 SHOW EFFECTIVE POLICIESを使用してください。
2. INFORMATION_SCHEMA.ROW_FILTERSとINFORMATION_SCHEMA.COLUMN_MASKSを確認して、競合する可能性のあるテーブルレベルの行フィルタまたは列マスクを特定してください。
3. どのポリシーがTO / EXCEPT原則とWHEN / MATCH COLUMNS条件で重複しているかを確認してください。
4. 解決方法：
   • ポリシー条件の調整。 WHENまたはMATCH COLUMNS条項をより具体的に更新して、異なるポリシーが異なるテーブルまたは列を対象とするようにします。
   • 管理タグを調整しています。 意図しないポリシーの一致を引き起こす列またはテーブルのタグ割り当てを確認し、削除または更新してください。
   • 原則を調整する。 TO / EXCEPT条項を更新して、各ユーザーがテーブルごと（行フィルタの場合）または列ごと（列マスクの場合）に最大で 1 つのポリシーの対象となるようにします。
   • 再構築ポリシー。 重複するポリシーを 1 つのポリシーに統合するか、広範なポリシーを個別の明示的に対象を絞ったポリシーに分割します。

列マスクの自動型変換

Databricks 、ABAC から解決された列マスク関数の入力と出力の両方を自動的にキャストします。 。 入力列の値はマスク関数のタイプに一致するようにキャストされ、関数の出力はターゲットカラムのデータ型に一致するようにキャストされます。 これにより、列をマスキングする際の型の一貫性と信頼性の高いクエリ動作が保証されます。自動鋳造の仕組みは以下のとおりです。

1. マスキング機能の実行 ：ポリシー評価によりマスキングが適用されることが判明した場合、一致する列の値に対してマスキング機能が実行されます。
2. 自動型キャスト : Databricks 、関数の注目型に一致するように入力列の値をキャストし、ターゲットカラムのデータ型に一致するように関数の出力をキャストします。
3. 結果の返送 ：適切な型の結果がクエリに返されます。

入力または出力の型に互換性がない場合、キャストは失敗し、クエリは エラーを返します。 キャストは、 CAST操作に関する ANSI SQL 標準に準拠しています (完全な互換性の詳細)。ただし、Databricks Runtime 18.1 以降では、ABAC 列マスク ポリシーにより構造体をVARIANTにキャストできますが、これは一般的な SQL ではサポートされていません。

マスク関数の戻り値の型がターゲットカラムと互換性があることを確認する必要があります。 例については「キャスト互換のマスキング関数」を、列の型を跨いで柔軟にマスキングを行うには「VARIANT」アプローチを参照してください。