行フィルターポリシーと列マスク ポリシーの要件、クォータ、制限事項

このページでは、Unity カタログの ABAC 行フィルターポリシーと列マスク ポリシーの要件、ポリシー クォータ、および現在の制限事項の一覧を示します。

コンピューティング要件

ABAC ポリシーを使用するには、次のいずれかのコンピューティング構成を使用する必要があります。

• サーバーレス コンピューティング
• Databricks Runtime 16.4 以降の標準コンピューティング
• Databricks Runtime 16.4 以降できめ細かなアクセス制御フィルタリングが有効になっている専用コンピューティング

古いランタイムを必要とするワークロードの実行に関するガイダンスについては、「 古いランタイムからのアクセス」を参照してください。

管理タグの要件

ABAC ポリシーでは、管理されていないタグではなく、管理されたタグが使用されます。 管理タグは、アカウント レベルで定義され、ユーザーが作成、割り当て、管理できるユーザーを決定するアクセス制御を使用します。 詳細については、 管理タグを参照してください。

ポリシー クォータ

管理タグのクォータなど、詳細については、「 サービスの制限」を参照してください。

ABAC の制限事項

ポリシー条件における同一属性

has_identity_attribute_value関数とhas_identity_attribute_tag_match関数は、クエリを実行するユーザーの同一属性を評価します。 これらはカラムマスクポリシーの条項 WHEN で支持されています。 次の制限事項が適用されます。

• これらはカラムマスクポリシーの条項 MATCH COLUMNS では支持されていません。
• GRANTやDENYの政策では支持されていません。
• カタログエクスプローラーのポリシー作成インターフェースは属性機能をサポートしていません。 これらのポリシーを作成するにはSQLを使いましょう。

使用パターンについては、「 クエリユーザーの属性に基づくカラムのマスク」を参照してください。

以前のランタイムからのアクセス

16.4 より前のバージョンの Databricks ランタイムの Standard および専用コンピューティングは、ABAC で保護されたテーブルにアクセスできません。 特定のワークロードを古いランタイムで実行し続ける必要がある場合は、広範に適用するのではなく、ABAC ポリシーのスコープを特定のグループに設定します。 ポリシーをそのグループに適用するユーザーまたはプリンシパルのみを追加し、 EXCEPT 句を使用して古いランタイム ワークロードを実行するプリンシパルを除外します。 グループ外のユーザーは、基になるテーブルへのフル アクセスを保持します。 これにより、サポートされているランタイムに移行している間も、ワークロードはテーブルに引き続きアクセスできます。

ビューに対する ABAC ポリシー

ABAC ポリシーをビューに直接適用することはできません。 ただし、ABAC ポリシーを使用してテーブルを参照するビューに対してユーザーがクエリを実行すると、ビューを介してデータにアクセスするときにそれらのポリシーが尊重されます。

基になるテーブルの ABAC 行フィルターと列マスクは、 セッション ユーザーの ID (つまり、クエリを実行しているユーザー) を使用して評価されます。 ユーザーには、ベース テーブルの ABAC ポリシーで定義されているように、アクセスが許可されている行と列の値のみが表示されます。 ベース テーブルのアクセス チェックと依存関係へのアクセス チェックでは、ビュー所有者の ID が使用されるため、ユーザーは基になるテーブルに対する直接権限なしでビューに対してクエリを実行できます。

具体化されたビューとストリーミング テーブルに対する ABAC ポリシー

パイプラインがマテリアル化されたビューやストリーミングテーブルを更新すると、パイプライン所有者または実行時の識別子を使ってポリシーを評価します。 そのアイデンティティがABACポリシーの対象であれば、マテリアライズドビューまたはストリーミングテーブルに永久にマスクまたはフィルタリングされたデータが含まれます。 これを避けるために、パイプラインの所有者または実行時の識別子を、パイプライン更新中に読み取るすべてのテーブルに関連付けられたABACポリシーの EXCEPT 節に追加してください。 TO句を使用して、マスクされたデータまたはフィルター処理されたデータを受け取るユーザーとグループを指定します。

ABAC ポリシーまたはそれらを参照するビューを使用した OpenSharing テーブル

ABAC ポリシーを使用してテーブルを参照する ABAC ポリシーまたはビューを持つテーブルは、共有所有者がポリシーから除外されている場合にのみ OpenSharing を通じて共有できます ( EXCEPT 句に記載されています)。 このポリシーでは、受信者のアクセスは管理されません。 受信者は、独自の ABAC ポリシーを共有テーブルに適用して、自分の側でアクセス制御を適用できます。

• 共有プロバイダーについては、「 ABAC ポリシーによってセキュリティ保護されたテーブルとスキーマを共有に追加する」を参照してください。
• 共有受信者については、「 ABAC で保護されたデータを読み取り、ABAC ポリシーを適用する」を参照してください。

ABAC で OpenSharing を使用する方法の詳細については、 OpenSharing と ABAC を参照してください。

ABAC ポリシーを使用したテーブルのタイム トラベルと複製

ABAC ポリシーは履歴テーブル スナップショットに対して評価できないため、アクティブな行フィルターまたは列マスクを持つテーブルではタイム トラベル クエリが失敗します。 ABAC ポリシーを使用するテーブルでは、ディープクローンとシャロークローンもサポートされていません。

これらの操作を有効にするには、サービス プリンシパルまたはグループを作成し、ポリシーの EXCEPT 句に追加します。 ポリシーは除外されたプリンシパルに対して評価されないため、これらの操作を実行できます。

たとえば、次のポリシーでは、 etl_service_principalを除くすべてのユーザーの PII 列がマスクされ、タイム トラベル クエリと複製操作を実行できます。

CREATE POLICY mask_pii
ON CATALOG prod
COLUMN MASK prod.governance.mask_value
TO `account users`
EXCEPT `etl_service_principal`
FOR TABLES
MATCH COLUMNS
  has_tag_value('pii', 'ssn') AS ssn
ON COLUMN ssn;

AI 検索インデックスと ABAC ポリシー

ソース テーブルの ABAC ポリシーは、そのテーブルから作成された AI Search インデックスには適用されません。 インデックスはソース テーブルのすべての行を同期し、クエリを処理するときに行フィルターまたは列マスク ポリシーを適用しません。

列マスクを含むテーブルの場合は、設定を 同期する列 を使用して、マスクされた列をインデックスから除外できます。

同じユーザーの同じテーブルまたは列に対する複数のポリシー

特定のテーブルと特定のユーザーに対して実行時に解決できる個別の行フィルターは 1 つだけで、特定の列と特定のユーザーに対して解決できる個別の列マスクは 1 つだけです。 複数のポリシーを定義できますが、ユーザーがテーブルに対してクエリを実行する場合は、1 つのポリシーの条件のみが一致する必要があります。 複数の個別の行フィルターまたは列マスクが同じユーザーとテーブルまたは列に適用される場合、Azure Databricksはアクセスをブロックし、エラーを返します。 複数のポリシーは、同じ引数を持つ同じ行フィルターまたは列マスク UDF に解決される場合に許可されます。

詳細については、「 複数のフィルターとマスクのルール」を参照してください。

専用コンピューティングでの ABAC

専用コンピューティングでの ABAC の制限については、「 制限事項」を参照してください。

ABAC およびテーブル レベルの行フィルターと列マスクに共通する制限事項

ABAC およびテーブル レベルの行フィルターと列マスクの両方に適用される 行フィルターと列マスクの一般的な制限については、「 制限事項」を参照してください。