メインコンテンツまでスキップ
に最終更新

ABACの要件、割り当て、および制限

このページでは、Unity Catalogにおける属性ベースアクセス制御（ABAC）の要件、ポリシーの割り当て、および現在の制限事項について説明します。

コンピュート要件​

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

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

管理タグの要件​

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

注記

タグの割り当てまたは変更後、変更が反映されるまで数分かかる場合があります。

ポリシーの割り当て​

リソース

上限

メタストアごとのポリシー

10,000

カタログまたはスキーマごとのポリシー

100

テーブルごとのポリシー

50

ポリシーごとのプリンシパル ( TO条項とEXCEPT条項の両方に適用されます)

20

MATCH COLUMNS句ごとの列条件

3

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

ABACの制限​

古いランタイムからのアクセス​

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

ビューに関するABACポリシー​

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

基となるテーブルに対する ABAC 行フィルタと列マスクは、 セッションユーザーの ID 、つまりクエリを実行している人物を使用して評価されます。ユーザーは、基本テーブル上のABACで定義された、アクセス権限のある行と列の値のみを見ることができます。 基本テーブル上で。 基本テーブルへのアクセスチェックと依存関係へのアクセスチェックは、ビュー所有者のIDを使用するため、ユーザーは基となるテーブルに対する直接的な権限がなくてもビューを照会できます。

注記

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

セッションユーザーIDモデルは、ABACの一般提供版リリースと同時に導入されました。従来、ポリシーの評価はビュー所有者または関数定義者のIDを使用して行われていました。詳細については、 2026 年 4 月のリリースノートを参照してください。

ABACのマテリアライズドビューとストリーミングテーブルに関するポリシー​

注記

以前は、マテリアライズドビューおよびストリーミング テーブルに関する ABAC ポリシーは、パイプライン所有者または実行者としての ID がポリシーから免除されている場合にのみサポートされていました。 その制限は撤廃されました。

パイプラインがマテリアライズドビューまたはストリーミングテーブルを更新する場合、ポリシーはパイプラインの所有者または実行者のIDを使用して評価されます。そのIDがポリシーの対象となる場合、マテリアライズドビューまたはストリーミングテーブルには、マスクまたはフィルタリングされたデータが永続的に含まれます。Databricks 、 EXCEPT句を使用して更新IDを除外し、 TO句でマスクまたはフィルタリングされたデータを見るべき消費者をターゲットにすることを推奨します。

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

ABAC を含むテーブル または ABAC を含むテーブルを参照するビュー 共有所有者が免除されている場合に限り、 Delta Sharingを通じて共有できます （ EXCEPT条項に記載されています）。 このポリシーは、受信者のアクセス権限を規定するものではありません。受信者は、共有テーブルに独自のABACを適用して、自身側でアクセス制御を強制できます。

Delta SharingをABACと併用する方法の詳細については、 「Delta SharingとABAC」を参照してください。

ABAC ポリシーを使用したテーブルのタイムトラベルとクローン作成​

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

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

重要

免除された校長は、フィルタリングもマスクもされていないデータを見ることができる。ETLやパイプラインワークロードに使用されるサービスプリンシパルなど、信頼できるIDのみを除外します。

例えば、次のポリシーでは、タイムトラベルクエリやクローン操作を実行できるユーザーetl_service_principalを除くすべてのユーザーのPII列をマスクします。

SQL
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 つのポリシーの条件のみが一致する必要があります。 同じユーザー、テーブル、または列に対して複数の異なる行フィルターまたは列マスクが適用された場合、Databricks はアクセスをブロックし、エラーを返します。同じ引数を持つ同じ行フィルタまたは列マスクUDFに解決される場合、複数のポリシーが許可されます。

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

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

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

ABAC ポリシーを一覧表示するには、 Unity Catalog REST API使用します。 ポリシーの作成、変更、削除イベントは、監査ログシステムテーブルに記録されます。

専用コンピュート上のABAC​

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

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

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

このページの見出し