ABAC DENY ポリシー (ベータ版)

備考

ベータ版

ABAC DENYポリシーはベータ版です。DENYポリシーはカタログまたはスキーマレベルで適用され、サポートされているセキュリティ保護可能タイプに対するMANAGE ACCESS CONTROL権限を拒否します。サポートされているセキュリティ保護可能タイプと権限を参照してください。

ABAC DENY ポリシーは、管理タグが条件に一致するセキュリティ保護可能なオブジェクトに対する Unity Catalog の権限をプリンシパルに対して明示的に拒否するものであり、常に付与よりも優先されます。このページでは、ABAC DENY ポリシーの作成、編集、一覧表示、削除の方法、MANAGE ACCESS CONTROL を拒否することの意味、および現在のスコープと制限事項について説明します。

Catalog Explorer、SQL、REST API、Terraform、またはDatabricks SDKを使用して、ABAC DENYポリシーを作成および管理できます。

ABAC の概要と、管理タグや has_tag や has_tag_value などの組み込み関数を含むコアコンセプトについては、属性ベースアクセス制御（ABAC）の基本概念を参照してください。

コンピュートの要件

SQLを使用してDENYポリシーを作成、変更、または削除するには、Databricks Runtime 18 LTS以上を実行しているクラシックコンピュートリソースが必要です。

注記

Databricks Runtime 18 は、Databricks Runtime 18.0、18.1、および 18.2 よりも新しいバージョンです。以前は後の番号のバージョンとしてリリースされていた機能が、今後は Databricks Runtime 18 への日付付きアップデートとしてリリースされるようになります。詳細については、統合リリースノートについてを参照してください。

DENYポリシーとは

DENYポリシーは、管理タグがポリシーの条件と一致するセキュリティ保護可能なオブジェクトに対して、指定されたプリンシパルへのUnity Catalog権限を明示的に拒否する属性ベースのアクセス制御ポリシーです。Unity Catalogは、アクセスがチェックされるたびに、ポリシーのスコープ内にある各セキュリティ保護可能なオブジェクトの管理タグに対してポリシーのWHEN条件を評価し、一致するすべてのセキュリティ保護可能なオブジェクトに対する権限を拒否します。

DENY ポリシーは、同じ権限のいかなる付与よりも優先され、個別の付与によって上書きすることはできません。

DENYポリシーは、以下のルールによって管理されます。

• DENY が常に優先されます。 DENY ポリシーは、継承、グループメンバーシップ、または オブジェクトの所有権を通じて暗黙的に保持される付与を含め、同じ権限のすべての付与を上書きします。個別の付与がアクティブな DENY を上書きすることはできません。
• メタストア管理者は、常に暗黙的に除外されます。 メタストア管理者はMANAGE ACCESS CONTROLに対するDENYポリシーの影響を受けることはありません。これにより、DENYポリシーをいつでも変更または削除できる経路が確保されます。
• 拒否（DENY）は下位に継承されます。 拒否自体も、権限付与が権限の継承に従うのと同様に、オブジェクト階層の下位に継承されます。カタログに対する拒否ポリシーは、そのカタログ内の現在および将来のすべてのオブジェクトに対する権限を拒否し、スキーマに対する拒否ポリシーは、そのスキーマ内の現在および将来のすべてのオブジェクトに対する権限を拒否します。
• 重複する DENY ポリシーは結合され、最も制限の厳しい結果が適用されます。 同じプリンシパルに複数の DENY ポリシーが適用される場合、その効果は統合されます。ある DENY ポリシーが、別の DENY ポリシーの対象となっているプリンシパルを免除することはできません。適用可能なポリシーのいずれかが権限を拒否する場合、その権限は拒否されます。
• DENYポリシーは付与とは独立しています。 明示的に付与された権限のみを削除するREVOKEとは異なり、DENYポリシーは既存の付与に依存しません。付与されたことのない権限を拒否することは可能であり、付与を取り消しても DENY ポリシーは削除されません。DENY ポリシーは、明示的に削除されるまで有効です。

DENY ポリシーの条件では、自身で作成した管理タグまたは Databricks によって事前定義されたシステムタグを参照できます。

DENY ポリシーは、行フィルターおよび列マスクポリシーとは以下の2点で異なります：

• 行フィルターポリシーと列マスクポリシーは、ユーザーがすでにアクセスできるデータの内容を制限します。DENY ポリシーは、プリンシパルがアクセス制御の管理などのアクションをまったく実行できるかどうかを決定します。
• 行フィルターおよび列マスクのポリシーでは、フィルターまたはマスクを実装するためにユーザー定義関数（UDF）が必要です。DENYポリシーではUDFを使用しません。条件は、ポリシー定義内にインラインで記述されます。

「アクセス制御の管理」を拒否するとはどういう意味ですか？

MANAGE ACCESS CONTROL は、権限の付与や取り消し、所有権の譲渡、ABACポリシーの管理など、アクセス管理を統括するMANAGE権限の子です。拒否することはできますが、許可することはできません。詳細については、アクセス制御を管理を参照してください。

DENY ポリシーを使用して MANAGE ACCESS CONTROL 権限を拒否することで、オブジェクト所有者を含む特定のプリンシパルが、ポリシーのスコープ内にあるオブジェクトに対してアクセス管理操作を実行できないようにすることができます。これにより、プリンシパルが MANAGE 権限を通じて保持しているか、オブジェクト所有権を通じて暗黙的に保持しているかに関係なく、この権限が管理するアクセス管理機能が削除されます。

影響を受けるオブジェクトにおいて、拒否されたプリンシパルは以下の操作を実行できなくなります：

• 権限の付与と取り消し。
• オブジェクトの所有権を変更します。
• ABAC ポリシーを作成および管理します。
• アクセスリクエストの宛先を構成します。
• カタログレベルで権限が拒否されている場合は、ワークスペースカタログのバインディングを管理します。

MANAGE ACCESS CONTROLを拒否しても、プリンシパルによるオブジェクトメタデータの表示機能は削除されません。MANAGEを持つプリンシパルまたはオブジェクトの所有者は、引き続きオブジェクトの存在を確認でき、MANAGE、その他の特権、または所有権によって提供される他のすべての機能を行使できます。これらが失うのは、上記に記載されたアクセス管理機能のみです。

MANAGE ACCESS CONTROLを拒否しても、プリンシパルがデータを共有できるすべてのパスが閉じられるわけではありません。データ共有に関する考慮事項を参照してください。

DENY ポリシーの例

以下のポリシーは、data_admins グループを除くすべてのアカウントユーザーに対して、catalog_a 内の sensitive とタグ付けされたすべてのテーブルでの MANAGE ACCESS CONTROL を拒否します。テーブル所有者を含む影響を受けるプリンシパルは、それらのテーブルに対する権限の付与や取り消し、所有権の変更、または行フィルターや列マスクの管理ができなくなります：

SQL

CREATE POLICY deny_manage_access_control_sensitive_tables
ON CATALOG catalog_a
COMMENT 'Prevent non-admins from managing permissions on sensitive tables'
TO `account users`
EXCEPT `data_admins`
DENY MANAGE ACCESS CONTROL
FOR TABLES
WHEN has_tag('sensitive');

次のポリシーは、data_admins を除き、指定されたグループに対して catalog_a 内のすべてのスキーマ上の MANAGE ACCESS CONTROL を拒否します。DENY は下位に継承されるため、影響を受けるプリンシパルは、それらのスキーマ内のオブジェクトに対するアクセス管理権限も失います：

SQL

CREATE POLICY deny_designated_users_catalog_access
ON CATALOG catalog_a
COMMENT 'Prevent designated users from managing access on catalog objects'
TO `designated_users`
EXCEPT `data_admins`
DENY MANAGE ACCESS CONTROL
FOR SCHEMAS;

サポートされているセキュリティ保護可能なタイプと権限

DENY ポリシーは、次の保護可能なタイプに対して 1 つの権限 MANAGE_ACCESS_CONTROL をサポートします。ポリシーは 1 つの保護可能なタイプに適用されます。Unity Catalogは、ポリシーを作成する際に、セキュリティ保護可能なタイプに対して権限を検証します。

セキュリティ保護可能なタイプ	MANAGE_ACCESS_CONTROL
カタログ	✓
スキーマ	✓
テーブル	✓
ボリューム	✓
関数	✓
モデル	✓
シークレット	✓

セキュリティ保護可能なタイプ	MANAGE_ACCESS_CONTROL
カタログ	✓
スキーマ	✓
テーブル	✓
ボリューム	✓
関数	✓
モデル	✓
シークレット	✓

これは、FOR句でサポートされているセキュリティ保護可能なタイプのリストです。ポリシーがカタログまたはスキーマにアタッチされると、そのDENYは、FOR句でサポートされていないタイプのオブジェクトであっても、そのカタログまたはスキーマ内のすべてのオブジェクトに継承されます。

SQL では、FOR の後に DENY MANAGE ACCESS CONTROL FOR TABLES や FOR SCHEMAS などの複数形の保護可能なタイプを使用します。単数形は受け付けられません。REST API では、for_securable_type を単数形（例：TABLE）に設定します。

拒否ポリシーの作成

Catalog Explorer UI、CREATE POLICY SQLステートメント、またはREST APIを使用して、DENYポリシーを作成できます。

DENY ポリシーを作成するには、ポリシーがアタッチされるカタログまたはスキーマに対する MANAGE 権限を持っているか、その保護可能なオブジェクトを所有している必要があります。

Catalog Explorer

DENY ポリシーは、カタログまたはスキーマから作成する必要があります。テーブルなどの個々のオブジェクトから開始する場合、 Deny access ポリシータイプは使用できません。

1. Databricks ワークスペースで、 カタログ をクリックします。

2. ポリシーを添付するカタログまたはスキーマを選択します。DENY ポリシーは、カタログレベルまたはスキーマレベルでのみ添付できます。

3. [ ポリシー ] タブをクリックします。

4. 新しいポリシー をクリックします。

5. ポリシーの識別 で、 ポリシー名 とオプションの 説明 を入力します。

6. プリンシパルとスコープ の下：

   • Applied to で、ポリシーを適用するプリンシパル（ユーザー、グループ、または Service Principal）を選択します。
   • Except for （除外対象）で、ポリシーから除外するプリンシパルを任意で選択します。
   • スコープ で、ポリシーが添付されているカタログまたはスキーマを確認します。

7. ポリシータイプ で、 アクセス拒否 を選択します。

8. セキュリティ保護可能なオブジェクト で、ポリシーを適用する保護対象のタイプを選択します。サポートされているタイプと権限を参照してください。

9. Condition （条件）で、カタログまたはスキーマ内の選択したタイプのセキュリティ保護可能オブジェクトに対してポリシーのスコープを設定する方法を選択します：

   • 条件なし は、選択したカタログまたはスキーマの下にあるそのタイプのすべてのセキュリティ保護可能なオブジェクトにポリシーを適用します。
   • これらのタグのいずれかに一致するセキュリティ保護可能なオブジェクト は、選択された管理タグの少なくとも1つを持つセキュリティ保護可能なオブジェクトにのみポリシーを適用します。
   • カスタム式に一致するセキュリティ対象 を使用すると、タグベースの式を記述して、ポリシーの適用対象となるセキュリティ対象を決定できます。使用可能な条件関数については、条件と組み込み関数を参照してください。

10. Privileges で、 MANAGE ACCESS CONTROL を選択します。これは、DENY ポリシーがサポートする唯一の権限です。

11. コードを表示 をクリックして保存前に同等の SQL ステートメントを確認し、 ポリシーを作成 をクリックします。

SQL

DENY ポリシーの SQL 構文では、ROW FILTER または COLUMN MASK の代わりに DENY ... FOR ... WHEN ... 本文を使用します。

SQL

CREATE [OR REPLACE] POLICY policy_name
ON { CATALOG catalog_name | SCHEMA schema_name }
[COMMENT description]
TO principal [, ...]
[EXCEPT principal [, ...]]
DENY MANAGE ACCESS CONTROL
FOR securable_type
[WHEN condition]

パラメーター:

• policy_name: ポリシーの名前。同じセキュリティ保護可能なオブジェクトに対して定義されているすべてのポリシー間で一意である必要があります。
• ON { CATALOG | SCHEMA }: ポリシーが添付されているスコープ。DENY ポリシーは、個々のセキュリティ保護可能なオブジェクトではなく、カタログまたはスキーマレベルでアタッチできます。
• TO principal [, ...]：ポリシーが適用されるユーザー、グループ、またはService Principal。
• EXCEPT principal [, ...]: ポリシーから除外されるプリンシパル。メタストア管理者は常に暗黙的に除外されるため、リストに記載する必要はありません。
• DENY MANAGE ACCESS CONTROL: 拒否する権限。MANAGE ACCESS CONTROL はサポートされている唯一の権限です。
• FOR securable_type：ポリシーが適用される範囲内のセキュリティ保護可能なタイプ。ポリシーは1つのタイプに適用されます。サポートされているタイプと特権を参照してください。
• WHEN condition：スコープ内でポリシーが適用されるセキュリティ保護可能なオブジェクトを決定する、タグベースの Boolean 式。組み込み関数 has_tag('tag_name') および has_tag_value('tag_name', 'tag_value') を使用します。省略した場合、default to TRUE（スコープ内のその型のすべてのセキュリティ保護可能なオブジェクトに適用されます）。使用可能な条件関数については、条件と組み込み関数を参照してください。

例については、「DENY ポリシーの例」を参照してください。

REST API

この例では、data_admins を除くすべてのアカウントユーザーに対して、catalog_a 内の sensitive がタグ付けされたすべてのテーブル上の MANAGE ACCESS CONTROL を拒否します：

Bash

curl -X POST "https://${DATABRICKS_HOST}/api/2.1/unity-catalog/policies" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  -H "Content-Type: application/json" \
  --data-binary @- << 'EOF'
{
  "name": "deny_manage_access_control_sensitive_tables",
  "comment": "Prevent non-admins from managing permissions on sensitive tables",
  "on_securable_type": "CATALOG",
  "on_securable_fullname": "catalog_a",
  "for_securable_type": "TABLE",
  "policy_type": "POLICY_TYPE_DENY",
  "to_principals": ["account users"],
  "except_principals": ["data_admins"],
  "deny": {
    "privileges": ["MANAGE_ACCESS_CONTROL"]
  },
  "when_condition": "has_tag('sensitive')"
}
EOF

name、on_securable_type、on_securable_fullname、for_securable_type、policy_type、to_principals、およびdeny.privilegesが必要です。comment、except_principals、およびwhen_conditionはオプションです。

リクエストとレスポンスの詳細については、REST API リファレンスの ポリシーの作成 を参照してください。

DENY ポリシーを編集

Catalog Explorer

DENY ポリシーは、それらが添付されている親カタログまたはスキーマの Policies tabから管理します。

1. Databricks ワークスペースで、 カタログ をクリックします。
2. ポリシーがアタッチされているカタログまたはスキーマを選択します。
3. [ ポリシー ] タブをクリックします。
4. 編集するポリシーを選択します。
5. 変更するフィールドを更新してください。
6. 「 ポリシーの更新 」をクリックします。

SQL

SQL で DENY ポリシーを編集するには、同じ名前とターゲットで CREATE OR REPLACE POLICY を実行します。拒否ポリシーの作成を参照してください。

REST API

SQL の CREATE OR REPLACE POLICY とは異なり、PATCH は部分的な更新をサポートしています。update_mask クエリーパラメーターを使用して、変更するフィールドを指定します。それらのフィールドのみが更新され、リクエスト本文に存在しないフィールドは変更されません。

この例では、ポリシーから除外されるプリンシパルに audit_admins を追加します：

Bash

curl -X PATCH "https://${DATABRICKS_HOST}/api/2.1/unity-catalog/policies/CATALOG/catalog_a/deny_manage_access_control_sensitive_tables?update_mask=except_principals" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  -H "Content-Type: application/json" \
  --data-binary @- << 'EOF'
{
  "except_principals": ["data_admins", "audit_admins"]
}
EOF

送信する値は既存のリストに追加されるのではなく置き換えられるため、新しいプリンシパルだけでなく、除外したいすべてのプリンシパルを含める必要があります。

DENY ポリシーを削除する

Catalog Explorer

DENY ポリシーは、それらが添付されている親カタログまたはスキーマの Policies tabから管理します。

1. Databricks ワークスペースで、 カタログ をクリックします。
2. ポリシーがアタッチされているカタログまたはスキーマを選択します。
3. [ ポリシー ] タブをクリックします。
4. ポリシーを選択します。
5. ポリシーを削除 をクリックします。

SQL

SQL を使用して DENY ポリシーを削除するには、DROP POLICYを実行します：

SQL

DROP POLICY deny_manage_access_control_sensitive_tables ON CATALOG catalog_a;

REST API

Bash

curl -X DELETE "https://${DATABRICKS_HOST}/api/2.1/unity-catalog/policies/CATALOG/catalog_a/deny_manage_access_control_sensitive_tables" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}"

ポリシーを表示

セキュリティ保護可能なオブジェクトに定義されているポリシーを一覧表示するには、SHOW POLICIES を使用します。スキーマに影響を与えるカタログレベルのポリシーなど、親スコープから継承されたポリシーも含めるには、SHOW EFFECTIVE POLICIES を使用します。

SQL

SHOW [EFFECTIVE] POLICIES ON { CATALOG | SCHEMA } securable_name

結果には、ポリシー名、ポリシータイプ、各ポリシーが定義されている保護対象オブジェクトのカタログとスキーマ、およびその保護対象オブジェクトのタイプとフルネームが含まれます。DENY ポリシーは、同じスコープにアタッチされている行フィルター、列マスク、および GRANT ポリシーとともに、ポリシータイプ DENY で返されます。Table 列は、テーブルにポリシーが定義されている場合にのみ入力されます。これは、行フィルターポリシーおよび列マスクポリシーに適用されます。GRANT ポリシーおよび DENY ポリシーの場合、Table 列は NULL です。

例：

SQL

SHOW EFFECTIVE POLICIES ON CATALOG catalog_a;

Text

Policy Name                                  Policy Type  Catalog    Schema  Table  Comment                                                           on_securable_type  on_securable_fullname
-------------------------------------------  -----------  ---------  ------  -----  ----------------------------------------------------------------  -----------------  ---------------------
deny_manage_access_control_sensitive_tables  DENY         catalog_a  NULL    NULL   Prevent non-admins from managing permissions on sensitive tables  CATALOG            catalog_a

SHOW GRANTS DENY ポリシーを反映しません。制限事項を参照してください。

ポリシーの記述

特定のDENYポリシーの詳細を表示するには、DESCRIBE POLICYを使用します。ターゲットのセキュリティ保護可能なオブジェクトに対するREAD METADATAまたはMANAGE、あるいはオブジェクトの所有権が必要です。

SQL

{ DESC | DESCRIBE } POLICY policy_name ON { CATALOG | SCHEMA } securable_name

結果には、名前、セキュリティ保護可能なオブジェクトのタイプ、セキュリティ保護可能なオブジェクトの名前、プリンシパル、拒否された権限、および WHEN 条件を含む、ポリシーのプロパティがキーと値のペアとして表示されます。

Information Schema を使用したクエリーポリシーの定義

INFORMATION_SCHEMA.ABAC_POLICY_DEFINITIONSを使用して、現在のカタログ内のDENYポリシー定義をクエリーできます：

SQL

SELECT *
FROM information_schema.abac_policy_definitions
WHERE policy_type = 'DENY';

利用可能な列とその他の例については、ABAC_POLICY_DEFINITIONSを参照してください。

ポリシーのクォータ

リソース	上限
メタストアごとのポリシー	10,000
カタログまたはスキーマごとのポリシー	100

リソース	上限
メタストアごとのポリシー	10,000
カタログまたはスキーマごとのポリシー	100

これらのクォータは、行フィルタおよび列マスクポリシーのクォータや、GRANT ポリシーのクォータとは別個のものです。

監査ログ

DENY ポリシーの作成、変更、および削除操作は、行フィルターや列マスクのポリシーと同じ createPolicy、deletePolicy、getPolicy、および listPolicies アクションの下でログに記録されます。See Audit Logs for example audit log クエリー.

ベストプラクティス

• 個々のユーザーではなく、TO および EXCEPT でグループを使用してください。 ポリシーで指定されたグループに対してユーザーを追加または削除すると、ポリシーを編集することなく、ポリシーの適用対象が変更されます。
• 誤って全員をロックアウトしないように、信頼できるグループを常にポリシーから除外してください。 これは、ポリシーがaccount usersグループに適用される場合に特に重要です。少なくとも1つのプリンシパルセットが影響を受けるオブジェクトへのアクセスを管理できるように、権限を保持するグループを指定するにはEXCEPT句を使用してください。
• ターゲットをカバーする最小のスコープでポリシーを適用してください。 スコープが広すぎると、関連のないセキュリティ保護可能オブジェクトがポリシーのタグマッチングに含まれてしまい、意図しないアクセス拒否が発生する可能性があります。

データ共有に関する考慮事項

MANAGE ACCESS CONTROLを拒否しても、所有権とMANAGE権限が制御する機能のみがブロックされます。プリンシパルがデータを共有できるすべてのパスを閉じるわけではありません。DENYポリシーでは、以下の処理は防止されません：

• CTAS を使用したデータのコピー。 テーブルに対する SELECT とスキーマに対する CREATE TABLE (USE CATALOG および USE SCHEMA と併せて) を持つプリンシパルは、CREATE TABLE ... AS SELECT を使用してデータを新しいテーブルにコピーできます。これを制限するには、CREATE TABLE を付与しないようにしてください。
• ビューを通じたデータの公開。 テーブルに対するSELECTとスキーマに対するCREATE TABLE（およびUSE CATALOGとUSE SCHEMA）を持つプリンシパルは、そのテーブル上にビューを作成できます。ビューは所有者の特権で実行されるため、ビューに対するSELECTを付与されたプリンシパルは、ソーステーブルへの直接アクセス権がなくても、基になるデータを読み取ることができます。これを制限するには、ビューの作成も許可するCREATE TABLEを付与しないようにしてください。
• 管理タグの適用または削除。 オブジェクトに対する APPLY TAG と 管理タグ に対する ASSIGN 特権を持つプリンシパルは、オブジェクト上のそのタグを変更でき、タグベースのポリシーに影響を与える可能性があります。これを制限するには、管理タグに対する ASSIGN とオブジェクトに対する APPLY TAG を保持するユーザーを制限してください。管理タグのアクセス許可の管理を参照してください。
• OpenSharing. オブジェクトに対する必要な権限を持つ共有所有者は、そのオブジェクトを 共有 に追加できます。これを制限するには、メタストアに対する CREATE SHARE の付与を避けてください。
• 資格情報のベンディング プリンシパルは、資格情報のベンディングを通じてオブジェクトへのアクセスを共有できます。これを制限するには、メタストアでの外部データ アクセスを有効にせず、EXTERNAL USE SCHEMA を付与しないでください。
• グループ管理。 Databricks グループ に対する Manage 権限を持つプリンシパル（自動的に権限を持つアカウント管理者およびワークスペース管理者を含む）は、グループのメンバーシップを変更できます。これにより、そのグループを通じてアクセス権を継承するユーザーが変わる可能性があります。これを制限するには、グループに対する Manage 権限を持つユーザーを制限します。

制限事項

• MANAGE ACCESS CONTROL権限のみを拒否できます。SELECTやMODIFYなどの他の権限は、DENYポリシーではサポートされていません。
• MANAGE ACCESS CONTROL権限は拒否できますが、付与することはできません。
• ポリシーはカタログまたはスキーマにアタッチできますが、個々の保護可能なオブジェクトにはアタッチできません。
• ポリシーは、1つの保護可能なオブジェクトタイプに適用されます。同じスコープ内の複数の保護可能なオブジェクトタイプに対して権限を拒否するには、タイプごとに個別のポリシーを作成するか、スキーマ内のすべてのオブジェクトタイプに対して MANAGE ACCESS CONTROL が拒否されるようにポリシー FOR SCHEMAS を作成します。
• SHOW GRANTS、GetPermissions、および GetEffectivePermissions は DENY ポリシーを反映していません。有効な DENY ポリシーを確認するには、オブジェクトのカタログまたはスキーマで SHOW EFFECTIVE POLICIES を使用します。

詳細情報

• ABAC GRANT ポリシー
• 属性ベースのアクセス制御（ABAC）の基本概念
• Unity Catalogでの権限の管理