ABAC の要件、クォータ、制限事項

このページでは、Unity カタログの属性ベースのアクセス制御 (ABAC) の要件、ポリシー クォータ、および現在の制限事項の一覧を示します。

コンピューティング要件

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

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

管理タグの要件

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

Note

タグを割り当てたり変更したりすると、変更が有効になるまで数分かかることがあります。

ポリシー クォータ

リソース 極限
メタストアあたりのポリシー数 １万
カタログまたはスキーマごとのポリシー 100
テーブルあたりのポリシー数 50
ポリシーごとのプリンシパル ( TO 句と EXCEPT 句の両方に適用されます) 20
MATCH COLUMNS句ごとの列条件 3

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

ABAC の制限事項

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

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

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

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

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

Note

ABAC ポリシーを持つテーブルに関数を介してアクセスする場合も、同じセッション ユーザー ID モデルが適用されます。

セッション ユーザー ID モデルは、ABAC GA リリースと共に導入されました。 以前は、ビュー所有者または関数定義者の ID を使用してポリシーが評価されていました。 詳細については、 2026 年 4 月のリリース ノートを参照してください。

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

Note

以前は、具体化されたビューとストリーミング テーブルに対する ABAC ポリシーは、パイプライン所有者または 実行 ID が ポリシーから除外された場合にのみサポートされていました。 この制限は削除されました。

パイプラインが具体化されたビューまたはストリーミング テーブルを更新すると、ポリシーはパイプライン所有者または実行 ID を使用して評価されます。 その ID がポリシーの対象である場合、具体化されたビューまたはストリーミング テーブルには、マスクまたはフィルター処理されたデータが永続的に含まれます。 Databricks では、 EXCEPT 句を使用して更新 ID を除外し、 TO 句でマスクまたはフィルター処理されたデータを表示するコンシューマーを対象にすることをお勧めします。

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

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

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

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

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

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

Important

除外されたプリンシパルには、フィルター処理されていないマスクされていないデータが表示されます。 ETL またはパイプライン ワークロードに使用されるサービス プリンシパルなどの信頼できる ID のみを除外します。

たとえば、次のポリシーでは、 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;

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

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

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

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

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

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

ABAC ポリシーと情報スキーマ

ABAC ポリシーの情報スキーマ テーブルはありません。 information_schema.row_filtersテーブルとinformation_schema.column_masksテーブルには、テーブル レベルの行フィルターと列マスクのみが表示されます。 実行時に ABAC ポリシー定義や ABAC ポリシーから派生したフィルターとマスクは表示されません。

ABAC ポリシーを一覧表示するには、Unity カタログ REST API を使用します。 ポリシーの作成、変更、および削除のイベントは、 監査ログ システム テーブルにキャプチャされます。

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

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

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

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

  • Last updated on