属性ベースのアクセス制御 (ABAC) の中心概念

属性ベースのアクセス制御 (ABAC) は、 管理されたタグ とポリシーを使用して、オブジェクトごとの許可ではなく、オブジェクト属性に基づいてアクセス許可を付与するアクセス制御モデルです。 このページでは、管理タグ、3 種類の ABAC ポリシー (行フィルター、列マスク、 GRANT ポリシー)、構成に必要なアクセス許可、および ABAC がチーム間で有効にする職務の分離という構成要素を定義します。

チュートリアル、ポリシー管理、ベスト プラクティス、制限事項など、ABAC のすべてのトピックの概要については、 Unity カタログの属性ベースのアクセス制御 に関するページを参照してください。

ABAC とは

属性ベースのアクセス制御 (ABAC) は、セキュリティ保護可能なオブジェクトに関連付けられている属性に対して評価されるポリシーに基づいてアクセスの決定が行われる動的アクセス制御モデルです。 Unity カタログでは、これらの属性は 管理タグによって表されます。 これらの管理タグは、カタログやスキーマなど、特定のスコープ内のデータ オブジェクトを照合するためにポリシー条件で使用されます。 これにより、条件を満たす複数のデータ オブジェクトに対して 1 つのポリシーを自動的に適用できます。

たとえば、ABAC ポリシーでは、PIIタグ付けされたスキーマ内のテーブルに対してHRタグ付けされたすべての列をマスクできます。 新しいデータ オブジェクトが作成されてタグ付けされると、ポリシーはオブジェクトごとに個別のポリシー定義を必要とせずに自動的に適用されます。

ABAC では、テーブル、具体化されたビュー、およびストリーミング テーブルに対する 行フィルター ポリシー と 列マスク ポリシー によって、行レベルと列レベルのセキュリティがサポートされます。 行フィルター ポリシーでは、ユーザーが表示できる行が制限されます。 列マスク ポリシーは、ユーザーに列の値を表示する方法を制御します。 テーブル レベルの行フィルターと列マスクとの比較については、「ABAC とテーブル レベルの行フィルターと列マスクを使用する場合」を参照してください。

ABACはまた、サポートされているセキュラブルタイプに対する GRANT ポリシー (ベータ版)を通じて動的特権付与もサポートしています。 ABACのGRANTポリシー(ベータ版)を参照してください。

統制されたタグ

Unity カタログでは、属性は 管理タグとして実装されます。 管理タグは、アカウント レベルで定義され、ワークスペース オブジェクトに加えて、カタログ、スキーマ、テーブル、列、モデル、ボリュームなどの Unity カタログのセキュリティ保護可能なオブジェクトに適用されるキーと値のペアです。 秘密度、分類、ビジネス ドメインなどの特性を表します。

既定では、セキュリティ保護可能なリソースは親カタログまたはスキーマからタグを継承します。 継承されたタグは、列レベルを除くすべてのレベルでオーバーライドできます。列タグは親テーブルから継承されないため、直接適用する必要があります。

管理タグは、やhas_tag()などの組み込み関数を使用してhas_tag_value()条件で参照できます。これにより、特定のタグがターゲット データ オブジェクトに直接存在するか、タグ継承によって存在するかを確認できます。

管理タグは、アカウント レベルで定義されます。 つまり、複数のメタストアを含め、アカウント内のデータ資産全体で同じタグ分類を使用できます。

詳細については、「 管理タグ 」および「 Unity Catalog のセキュリティ保護可能なオブジェクトにタグを適用する」を参照してください。

ポリシー

ポリシーは Unity カタログの セキュリティ保護可能なオブジェクト にアタッチされ、タグ条件に基づいてアクセス制御ルールを定義します。 次に例を示します。

CREATE FUNCTION mask_pii(val STRING) RETURNS STRING
    RETURN '***';

CREATE POLICY mask_pii_for_hr
ON CATALOG catalog_a
COLUMN MASK mask_pii
TO `account users` EXCEPT `HR admins`
FOR TABLES
WHEN has_tag('HR')
MATCH COLUMNS has_tag('PII') AS pii_col
ON COLUMN pii_col;

各ポリシーは次を指定します。

• スコープ: ON 句で指定された、ポリシーがアタッチされているセキュリティ保護可能なオブジェクト。 セキュリティ保護可能なオブジェクトにポリシーをアタッチすると、そのオブジェクトとそのすべての子孫にわたって、 FOR 句で指定された型のすべてのオブジェクトに対してポリシー条件が評価されることを意味します。
  • 行フィルター ポリシーと列マスク ポリシーの場合、サポートされているポリシー スコープは CATALOG、 SCHEMA、または TABLEです。 GRANT ポリシー (ベータ) では、サポートされているポリシー スコープは CATALOG と SCHEMA です。
  • テーブルはストリーミングテーブルやマテリアル化されたビューを含め、行フィルタおよびカラムマスクポリシーで唯一サポートされているセキュア可能なタイプであり、 FOR TABLES 節で指定されます。 GRANT ポリシー(ベータ版)はモデル、モデルサービス、モデルプロバイダーサービス、MCPサービス、エージェントサービスに適用され、 GRANT <privilege> FOR <securable_type> 節を使用します。 サポート可能なセキュア可能なタイプおよび権限の完全なリストについては 、「サポートされたセキュア可能なタイプおよび権限」をご覧ください。
  • カタログにアタッチされたポリシーは、そのカタログ内のすべてのテーブルに対して評価されます。 スキーマにアタッチされたポリシーは、そのスキーマ内のすべてのテーブルに対して評価されます。 テーブルにアタッチされたポリシーは、そのテーブルに対してのみ評価されます。

• プリンシパル: ポリシーが適用されるユーザーと除外されるユーザー。 TO句は、ポリシーの対象となるユーザー、グループ、またはサービス プリンシパルを指定します。 省略可能な EXCEPT 句は、このポリシーから特定のプリンシパルを除外します。
• アクション: ポリシーが行フィルター、列マスク、または特権付与を適用するかどうか。 行フィルターポリシーと列マスク ポリシーでは、 ユーザー定義関数 (UDF) を使用して、フィルター処理またはマスク ロジックを実装します。 GRANT ポリシー (ベータ) では UDF は使用されません。 「ポリシーの種類」を参照してください。
• 条件: ポリシーが対象とするテーブルまたは列を決定するタグベースの式。 条件と組み込み関数を参照してください。

ポリシーは、UI を介して、または、SQL ステートメント、REST API、Databricks SDK、Terraform などを使用してプログラムによって作成および管理されます。 完全な構文と例については、 ABAC ポリシーの作成と管理 に関するページを参照してください。

ポリシー タイプ

ABAC では、行フィルター ポリシー、列マスク ポリシー、 GRANT ポリシー (ベータ) の 3 種類のポリシーがサポートされています。 行フィルターポリシーと列マスク ポリシーでは、 UDF で フィルター処理またはマスク ロジックを実装する必要があります。 GRANT ポリシーは UDF を使用せず、タグベースの条件がターゲット オブジェクトの属性と一致する場合に特権を付与します。

行フィルター ポリシー

行フィルター ポリシーは、 条件と組み込み関数に一致するタグによって識別される列の値に基づいて、ユーザーがテーブルに表示できる行を制限します。 このポリシーは、各行を評価する UDF を参照します。 関数が FALSE を返す行は、クエリ結果から除外されます。 引数は、 USING COLUMNS 句を介して UDF に渡されます。

ユース ケースの例: 販売カタログの場合は、列に regionタグが付いているすべてのテーブルで、EMEA チームに EMEA 販売レコードのみが表示されていることを確認します。

CREATE FUNCTION filter_by_region(region STRING, allowed STRING) RETURNS BOOLEAN
    RETURN region = allowed;

CREATE POLICY regional_access_emea
ON CATALOG sales
ROW FILTER filter_by_region
TO `emea team`
FOR TABLES
MATCH COLUMNS has_tag('region') AS rgn
USING COLUMNS (rgn, 'EMEA');

列マスク ポリシー

列マスク ポリシーは、 条件と組み込み関数に一致するタグによって識別される特定の列に対してユーザーに表示される値を制御します。 このポリシーは、列の値を入力として受け取り、元の値またはマスクされたバージョンを返す UDF を参照します。 マスクされた列の値は、 ON COLUMN 句の最初の引数として自動的にバインドされ、 USING COLUMNSを介して追加の引数を渡すことができます。 戻り値の型は、列のデータ型と一致するか、キャスト可能である必要があります。

ユース ケースの例:ポリシーから除外されたコンプライアンス グループに含まれている場合を除き、pii : ssn (最後の 4 桁のみ) が表示されるように、***-**-XXXXでタグ付けされた SSN 列をマスクします。

CREATE FUNCTION mask_ssn(ssn STRING, show_last INT) RETURNS STRING
    RETURN CONCAT('***-**-', RIGHT(ssn, show_last));

CREATE POLICY mask_ssn_columns
ON CATALOG hr_catalog
COLUMN MASK mask_ssn
TO `account users` EXCEPT `compliance team`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn_col
ON COLUMN ssn_col
USING COLUMNS (4);

USING COLUMNS句は、UDF に引数を渡します。 関数が期待する順序で提供された、タグベースの式に一致する列のエイリアスや、定数値（引用符で囲まれた文字列、数値リテラル、ブール値 (TRUE/FALSE)、または NULL）を受け入れます。 また、 タグイントロスペクション関数を受け入れます。これは、クエリ時にタグの値を抽出し、UDF に渡します。 列マスク ポリシーの場合、これらはマスクされた列を超える追加の引数です ( ON COLUMNから自動的にバインドされます)。 これにより、異なるパラメーターを持つポリシー間で 1 つの UDF を再利用できます。

パフォーマンスを向上させるには、SQL UDF をお勧めします。 Unity カタログに登録されているPYTHON UDF もサポートされていますが、クエリ オプティマイザーは SQL UDF と同じようにインライン化したり最適化したりすることはできません。 UDF 言語の選択に関するガイダンスについては、パフォーマンスに関 する考慮事項 を参照してください。

GRANT ポリシー (ベータ)

GRANT ポリシーは、タグベースの条件がセキュリティ保護可能なオブジェクトのタグと一致すると、Unity カタログ特権を動的に付与します。 ユーザーがセキュリティ保護可能なオブジェクトにアクセスしようとするたびに、Unity Catalog は、オブジェクトを対象とするスコープを持つすべてのGRANT ポリシーを識別し、ユーザーがTOリストではなくEXCEPTリストに含まれているかどうかを確認し、ポリシーのWHEN条件を、継承されたタグを含むセキュリティ保護可能なタグに対して評価します。 ポリシーが適用される場合、Unity Catalog は特権を付与します。 GRANT ポリシーでは、UDF を使用しない場合を除き、行フィルターポリシーと列マスク ポリシーと同じ 評価モデル が使用されます。 条件は、ポリシー定義でインラインで表されます。

オブジェクトに対する有効な特権は、直接付与と適用可能な GRANT ポリシーの和集合です。 スコープ内の GRANT ポリシーがそのプリンシパルに適用される場合、または同じ特権の直接 GRANT が適用される場合、プリンシパルには特権があります。 GRANT ポリシーはアクセス権を追加するだけです。 直接付与されたアクセス権を取り消すことはできません。

条件と組み込み関数

条件は、ポリシーがスコープ内で対象とするテーブルと列を決定するタグベースの式です。

• テーブル条件 (WHEN 句): タグに基づいてテーブルに一致するブール式。 省略すると、既定で TRUEされます。つまり、ポリシーはスコープ内のすべてのテーブルに適用されます。
• 列の条件 (MATCH COLUMNS 句): ポリシーが対象とする列を識別する 1 つ以上のコンマ区切りのブール式。 各式には、 has_tag('pii')などの 1 つの組み込み関数や、 has_tag_value('pii', 'ssn') AND has_tag('sensitive')などの論理演算子を使用した組み合わせを指定できます。 各式には、(AS の後に指定) エイリアスを割り当てることができ、これは ON COLUMN および USING COLUMNS 句で参照できます。 ポリシーには最大 3 つの列式を含めることができます。ポリシーを適用するには、すべて一致する必要があります。

どちらの種類の句でも、セキュリティ保護可能なメタデータに対して Unity カタログによって評価される次の組み込み関数が使用されます。

リソースタグではなく、クエリを実行しているユーザーの属性に基づいて照合するには、Identity attribute functionsを参照してください。

呼び出しアプリケーションのような要求のコンテキストにマッチングする場合は、 コンテキスト属性関数を参照してください。

タグはテーブルから列に伝達されません。 has_tag() 句で MATCH COLUMNS を使用する場合、その一致は親テーブルやその祖先のタグではなく、列レベルのタグに限られます。

例: 2 つの列条件を使用する。 customers スキーマには、電子メール列にpii : emailタグが付き、同意列にconsent_to_contactタグが付いたテーブルがあります。 このポリシーは、お客様が連絡を受ける同意を得ていない限り、メール アドレスをマスクします。 次の 2 つの列条件を使用します。

1. has_tag_value('pii', 'email') は、メール アドレスを含む列 (マスクする列) を識別します。
2. has_tag('consent_to_contact') は、同意情報を含む列を識別します (マスクするかどうかを決定するために UDF によって使用されます)。

CREATE FUNCTION mask_email_by_consent(email STRING, consent BOOLEAN)
RETURNS STRING
RETURN CASE
  WHEN consent = true THEN email
  ELSE '****@****.***'
END;

CREATE POLICY mask_email_with_consent
ON SCHEMA customers
COLUMN MASK mask_email_by_consent
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'email') AS m,
  has_tag('consent_to_contact') AS c
ON COLUMN m
USING COLUMNS (c);

このポリシーは、 pii : email タグ付けされた列と consent_to_contactタグ付けされた列の両方を持つテーブルにのみ適用されます。 テーブルに両方の条件に一致する列がない場合、ポリシーは適用されず、データはマスクされずに返されます。

ID 属性関数 (ベータ版)

識別属性関数は、検索を実行するユーザーの部門、国、職務など属性を評価します。 これらの属性はアイデンティティプロバイダーからプロビジョニングされ、ポリシー条件で直接参照できます。 これにより、恒等性の各組み合わせごとに別々のグループを作ることなく、より柔軟な条件を表現できます。 アイデンティティプロバイダーのアイデンティティ情報が変更されると、ポリシーは更新された属性値を使用します。これは更新されたグループメンバーシップと同じです。

これらの機能はカラムマスクポリシーの WHEN 節でサポートされています。

それらを使用するポリシーを作成する際は、次の動作を念頭に置いてください。

• 欠けている属性は falseに解決されます。 ユーザーが属性の価値を持っていなかったり、そもそも属性が存在しない場合、関数はエラーを出すのではなく false を返します。 この false 結果がアクセスを制限するように条件を表現しましょう。 「 同一属性条件」を参照してください。
• 属性キーと値は大文字差し区別があり 、正確に比較されます: Finance と finance は一致しません。
• 属性の変化は即座に起こりません。 アイデンティティプロバイダーの変更はすぐにAzure Databricksに同期されません。 詳細は 識別属性 を参照してください。

Azure Databricksがサポートする属性とそのプロビジョニング方法については、アイデンティティ属性をご覧ください。 ポリシーでアイデンティティ属性の使い方の例については、「 クエリユーザーの属性に基づくカラムをマスクする」を参照してください。

コンテキスト属性関数(ベータ版)

コンテキスト属性は、OAuthアプリケーションを通じてユーザーを代表して行われるリクエストのデータアクセスを制限するために使われます。 この仕組みは、エージェントがユーザーを代表して行動する際にデータへのアクセスを制限しつつ、ユーザーがワークスペースで直接クエリした場合も同じデータをアクセス可能に保つことができます。

Azure Databricks CLIのような組み込みアプリからカスタムOAuthアプリまで、あらゆるOAuthアプリケーションをカバーします。 コンテキスト属性には2つの異なるものがあります。

• request.is_on_behalf_of:文字列 'true' または 'false'。 OAuthアプリを通じてユーザーの代理でリクエストが実行されているかどうかを示します。 OAuthアプリからのリクエストはこの値が 'true'に設定されています。
• request.client_id:OAuthクライアントID。 これは特定のOAuthクライアント、例えば組み込みのOAuthアプリ(例: databricks-cli)やカスタムOAuthアプリをターゲットにすることができます。 client_idはアカウントコンソールのアプリ接続ページで確認できます。 Databricks Appsの場合、アプリの 認証 詳細ページ、 OAuth2 App Client IDでも確認できます。 または、identity_metadata.acting_resourceのフィールドから照会できます。

これらの属性はユーザーが変更できず、システムによって明示的に提供されています。電話をかける人は、彼らがどのように認証するかによってのみ影響を受けます。 これらの属性は外部エージェントを識別するために使われ、Genieエージェントではありません。

コンテキスト属性は以下の関数を通じて使用できます:

属性キーは大文字を区別せず、値は大文字を区別します。

これらのコンテキスト属性を使って外部エージェントからのアクセスを制御する方法を学びたい方は、「 ユーザーを代表して行動する外部エージェントのアクセス制限」を参照してください。

ユーザー定義関数 (UDF)

行フィルターポリシーと列マスク ポリシーでは、ユーザー定義関数 (UDF) を使用して、フィルター処理またはマスク ロジックを実装します。 UDF の作成方法と管理方法については、Unity カタログの SQL および Python ユーザー定義関数 (UDF) と、行フィルターと列マスクの一般的なパターン (例) を参照してください。

タグ イントロスペクション機能

タグイントロスペクション関数は、管理タグの値を抽出し、 USING COLUMNS 句を介して UDF に渡します。 UDF はタグ値を引数として受け取るため、1 つのポリシーと UDF で、タグ値ごとに個別のポリシーを必要とするのではなく、複数のタグ値を処理できます。 これらの関数は、行フィルター ポリシーと列マスク ポリシーでのみ使用できます。 GRANT ポリシーでは UDF が使用されないためです。

これらの関数を使用するポリシーを作成するには、Databricks Runtime 18 LTS 以上が必要です。 この要件は、ポリシーの作成にのみ適用され、管理テーブルのクエリには適用されません。

クエリ時に、Unity Catalog は、ポリシーに一致するテーブルまたは列に付与されたタグに対して、これらの関数を評価します。get_tag_value() は WHEN 条件を満たすテーブルから読み取り、get_column_tag_value() は MATCH COLUMNS によって識別される列から読み取ります。 これらはUSING COLUMNS句にのみ出現でき、WHENまたはMATCH COLUMNS条件では出現できません。

どちらの関数も、タグ キーを文字列リテラルとして受け取ります。 タグは管理タグである必要があり、 get_column_tag_value() はポリシーの MATCH COLUMNS 句に存在するエイリアスを参照する必要があります。 タグが管理されていない場合、またはエイリアスが有効でない場合、ポリシーの作成は失敗します。 クエリの実行時に参照先タグが制御されなくなった場合、ポリシーのターゲット テーブルに対するクエリは実行時に失敗します。

例: すべての PII タイプに対して 1 つのポリシー

タグイントロスペクションを使用しない場合、個人を特定できる各種類の情報 (電子メール、SSN、電話) をマスクするには、タグ値ごとに個別のポリシーと UDF が必要です。 get_column_tag_value()では、1 つのポリシーが一致する列のpii タグ値を 1 つの UDF に渡します。 UDF はその値に基づいて分岐します。

CREATE FUNCTION mask_pii(col STRING, pii_type STRING)
RETURNS STRING
RETURN CASE
  WHEN pii_type = 'email' THEN regexp_replace(col, '(^[^@]+)', '***')
  WHEN pii_type = 'ssn' THEN '***-**-' || right(col, 4)
  WHEN pii_type = 'phone' THEN '***-***-' || right(col, 4)
  ELSE col
END;

CREATE POLICY mask_all_pii
ON CATALOG main
COLUMN MASK mask_pii
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS col
ON COLUMN col
USING COLUMNS (get_column_tag_value(col, 'pii'));

マスクされた各列について、get_column_tag_value(col, 'pii') はその列の pii タグ値（email、ssn、phone など）を参照し、mask_pii には対応する変換が適用されます。 新しいタグ値には、新しいポリシーではなく、UDF 内の新しいブランチのみが必要です。

職務と権限の分離

ABAC のセットアップには、それぞれ独自のアクセス許可要件を持ついくつかの手順が含まれます。 組織は、職務を分離する方法に応じて、これらのタスクを特殊なグループに分散させることができます。 たとえば、組織はタグ分類を一元的に定義し、データ スチュワードにデータを分類させ、ガバナンス管理者にポリシーを書き込み、データ作成者が管理スコープ内でオブジェクトを作成し、データ コンシューマーが管理オブジェクトにアクセスできるようにします。

1. タグ分類を作成します。 誰かがポリシーを適用または書き込む前に、管理タグ キーとその許容値を定義します。 たとえば、制御された値 (sensitivity、public、internal、confidential) を含むrestricted タグや、pii、ssn、emailなどの値を持つphone_number タグを作成します。 名前付け規則と分類設計に関する推奨事項については、「属性と名前付けの標準化」を参照してください。

   • 必要なアクセス許可: アカウント管理者、またはアカウント レベルでタグ CREATE アクセス許可を持つユーザー。

2. データ資産にタグを付けます。 データ スチュワード、データ作成者、または AI 分類システムは、カタログ、スキーマ、テーブル、列、モデル、ボリュームなどのセキュリティ保護可能なオブジェクトに、管理タグを Unity カタログに適用します。 たとえば、個人を特定できる情報を含む列に pii : ssnタグを付けたり、モデルに lifecycle : productionタグを付けたりします。 適切なタグ付けは、ABAC ポリシーを適用するための重要な最初の手順です。

   • 必要なアクセス許可: タグに ASSIGN し、オブジェクトに APPLY TAG します。

3. ポリシーを作成します。 ガバナンス管理者は、カタログやスキーマなどのスコープでポリシーを作成します。 ポリシーは、適用するユーザー、評価する条件、適用するアクション (行フィルター、列マスク、特権付与など) を指定します。

   • 必要なアクセス許可: ポリシーが適用されているセキュリティ保護可能なオブジェクトに対する MANAGE アクセス許可、またはそのオブジェクトの所有権。 行フィルターポリシーおよび列マスクポリシーでは、UDF に対する EXECUTE 権限も必要です。

4. データ オブジェクトを作成します。 データ作成者は、アクセス権が付与されたスコープ内に、テーブル、モデル、ボリュームなどのセキュリティ保護可能なオブジェクトを作成します。 新しいオブジェクトは、親カタログとスキーマからタグを継承します。 また、データ作成者は、作成したオブジェクトに対して自動的に APPLY TAG されるので、追加のタグを適用できます。 または、 自動データ分類 に依存してタグ付けを処理することもできます。 組織がデータ作成者に依存して独自のオブジェクトにタグを付ける場合は、明確なタグ付けプラクティスを確立する必要があります。 ポリシーが高いレベルで設定されている場合、データ作成者はアクセス制御を構成する必要はありません。Azure Databricks推奨されます。

   • 必要なアクセス許可: 親オブジェクトに対する CREATE TABLE またはその他の関連する作成特権。

5. 管理オブジェクトにアクセスします。 ユーザーがポリシーのスコープ内のセキュリティ保護可能なオブジェクトにアクセスしようとすると、Unity カタログは適用可能なポリシーを自動的に評価します。 行フィルターポリシーと列マスク ポリシーの場合、テーブルまたは列がポリシーの条件と一致し、ユーザーが除外されていない場合、ユーザーはフィルター処理またはマスクされたデータを表示します。 GRANT ポリシー (ベータ) の場合、条件が一致し、ユーザーがTOではなくEXCEPTされている場合、ユーザーは付与された特権を取得します。

   • 必要なアクセス許可: 行フィルターポリシーと列マスク ポリシーの場合、ユーザーには、直接オブジェクトの付与を通じて、テーブルに対するアクセス許可 ( SELECT など) を付与する必要があります。 これらのポリシーは、ユーザーが既にアクセスできるテーブルのレコードまたはマスク列をフィルター処理します。 それ自体ではアクセス許可は付与されません。 GRANT ポリシー (ベータ) は、その権限を直接付与するとともに、同じ保護対象に対する直接的な権限と合算されます。

ABAC の利点

• 属性に基づく再利用可能なポリシー: 1 つのポリシーは、1 つの特定のオブジェクトに関連付けるのではなく、同じ属性ベースの条件に一致する複数のデータ オブジェクトに適用できます。

• 新しいオブジェクトへの自動アプリケーション: 新しいデータ オブジェクトがスコープ内で作成され、関連する属性でタグ付けされると、既存の ABAC ポリシーが追加の構成なしで適用されます。 ポリシーは将来の付与と同様に機能します。つまり、新しいデータが作成され、適切にタグ付けされると、アクセス制御が自動的に適用されます。

• スコープ内での一貫した適用: カタログ レベルまたはスキーマ レベルでアタッチされたポリシーは、そのスコープ内の一致するデータ オブジェクトに対して動的に評価されるため、類似データのフィルター処理またはマスクの方法の違いが排除されます。

• 継続的なメンテナンスの削減: 変更は、テーブル レベルの行フィルターと列マスクで必要な個々のオブジェクトを見直すのではなく、ポリシー ロジックまたは管理タグを更新することによって行うことができます。

• 一元化されたガバナンス: ポリシーは 1 回定義し、多数の一致するデータ オブジェクトに適用できるため、ガバナンス チームは、より少ないポリシー定義でデータ資産の大部分にわたって制御を管理できます。

その他のリソース

• 統制タグ
• ポリシーを作成
• Unity カタログで権限を管理する
• 行フィルターと列マスク
• 監査ログ システム テーブルリファレンス
• 行フィルターポリシーと列マスク ポリシーの要件、クォータ、制限事項