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

属性ベースアクセス制御（ABAC）の基本概念

属性ベースのアクセス制御 (ABAC) は、オブジェクトごとの付与ではなく、オブジェクト属性に基づいて権限を付与するために、 管理タグ およびポリシーを使用するアクセス制御モデルです。このページでは、構成要素として、管理タグ、3つのABACポリシータイプ（行フィルター、列マスク、GRANTポリシー）、それらを構成するために必要な権限、およびABACがチーム間で実現する職務の分離について説明します。

チュートリアル、ポリシー管理、ベスト プラクティス、制限事項を含む、ABAC のすべてのトピックの概要については、 Unity Catalogの属性ベースのアクセス制御」を参照してください。

ABACとは何ですか？​

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

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

ABACは、テーブル、マテリアライズドビュー、ストリーミングテーブルに適用される**行フィルターポリシー**と**列マスクポリシー**を介して、行レベルおよび列レベルのセキュリティをサポートします。行フィルターポリシーは、ユーザーが参照できる行を制限します。列マスクポリシーは、列の値がユーザーにどのように表示されるかを制御します。「テーブルレベルの行フィルターと列マスク」との比較については、「ABAC とテーブルレベルの行フィルターおよび列マスクのどちらを使用するか」を参照してください。

ABAC は、 GRANT ポリシー （ベータ版）を介した動的な権限付与もサポートしており、現在、モデル上のEXECUTEに限定されています。モデル向けABAC GRANTポリシー（ベータ）を参照してください。

管理タグ​

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

デフォルトでは、セキュリティ保護可能なオブジェクトは、親カタログまたはスキーマからタグを継承します。列レベルを除くすべてのレベルで、継承されたタグを上書きできます。列のタグは親テーブルから継承されず、直接適用する必要があります。

管理タグ階層図

管理タグは、 has_tag()やhas_tag_value()などの組み込み関数を使用してポリシー条件で参照できます。これらの関数は、指定されたタグがターゲット データ オブジェクトに存在するかどうかを、直接またはタグの継承を通じてチェックします。

管理タグはアカウントレベルで定義されます。 これは、アカウント内のデータ全体（複数のメタストアを含む）で同じタグ分類体系を使用できることを意味します。

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

ポリシー​

ポリシーは、タグ条件に基づいてアクセス制御ルールを定義するために、 Unity Catalog内のセキュリティ保護可能なオブジェクトに添付されます。 以下に例を示します。

SQL
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 ポリシー（ベータ版）はモデルのみをサポートし、GRANT EXECUTE FOR MODELS を使用して指定されます。モデルのABAC GRANTポリシー (Beta)を参照してください。
    • カタログに添付されたポリシーは、そのカタログ内のすべてのテーブルに対して評価されます。スキーマに添付されたポリシーは、そのスキーマ内のすべてのテーブルに対して評価されます。テーブルに添付されたポリシーは、そのテーブルに対してのみ評価されます。
注記

Databricksは、ガバナンスの効率を最大化するために、ポリシーを適用可能な最高レベル（通常はカタログ）に添付することを推奨しています。ABAC ポリシーのベスト プラクティスを参照してください。

  • 本人 : ポリシーが適用される人、および適用されない人。 TO条項は、ポリシーの対象となるユーザー、グループ、またはサービスプリンシパルを指定します。オプションのEXCEPT条項は、特定の主要関係者をこのポリシーから除外します。
  • アクション: ポリシーが行フィルター、列マスク、または特権付与のいずれかを適用するかどうか。行フィルターと列マスクのポリシーは、ユーザー定義関数 (UDF) を使用してフィルターまたはマスキングのロジックを実装します。GRANT ポリシー（Beta）は UDF を使用しません。ポリシーの種類を参照してください。
  • 条件 ：ポリシーの対象となるテーブルまたは列を決定するタグベースの式。条件と組み込み関数を参照してください。

UI を介して、またはCREATE POLICY 、 DROP POLICY 、 SHOW POLICIES 、 DESCRIBE POLICYなどのSQLステートメント、 REST APIs 、 Databricks SDK 、またはTerraformを使用してプログラム的に作成および管理されます。 完全な構文と例については、「ABAC ポリシーの作成と管理」を参照してください。

ポリシーの種類​

ABACは3つのポリシータイプ、行フィルターポリシー、列マスクポリシー、およびGRANTポリシー（ベータ版）をサポートしています。行フィルターと列マスクポリシーには、フィルタリングまたはマスキングロジックを実装するためのUDFが必要です。GRANTポリシーはUDFを使用するのではなく、タグベースの条件がターゲットオブジェクトの属性と一致する場合に権限を付与します。

行フィルタポリシー​

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

使用例: 販売カタログの場合、EMEA チームが、 regionタグの列を持つすべてのテーブルで EMEA 販売レコードのみを表示できるようにします。

SQL
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でタグ付けされた SSN 列をマスクして、ポリシーの適用除外となるコンプライアンス グループに属していない限り、ユーザーには***-**-XXXX (下 4 桁のみ) が表示されるようにします。

SQL
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 ）を受け入れます。 列マスクポリシーの場合、これらはマスクされた列（ ON COLUMNから自動的にバインドされます）以外の追加の引数です。これにより、単一のUDFさまざまなポリシー全体で再利用できるようになります。

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

GRANT ポリシー（ベータ版）​

備考

ベータ版

GRANT ポリシーはBetaであり、現在、モデル上でのEXECUTEにスコープされています。シンタックス、例、およびベータ版の制限については、モデルのABAC GRANTポリシー（ベータ版）を参照してください。

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

オブジェクトに対する有効な権限は、直接付与と適用されるGRANTポリシーの集合です。適用範囲内のGRANTポリシーがそのプリンシパルに適用されるか、または同じ権限の直接的な GRANT が適用される場合、プリンシパルは権限を持ちます。GRANT ポリシーはアクセスのみを追加します。直接付与されたアクセス権を取り消すことはできません。

条件と組み込み機能​

条件とは、ポリシーの適用範囲内でどのテーブルと列を対象とするかを決定するタグベースの式です。

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

どちらの句タイプも、Unity Catalogによってセキュリティ保護可能なメタデータに対して評価される以下の組み込み関数を使用します。

関数

コンテキスト

説明

has_tag('tag_key')

表と列

指定されたタグがリソースに存在する場合はtrueを返します。テーブル条件（ WHEN ）では、テーブルに直接設定されたタグ、または親カタログやスキーマから継承されたタグをチェックします。列条件（ MATCH COLUMNS ）では、列に直接設定されたタグのみをチェックし、テーブルタグとは一致しません。

has_tag_value('tag_key', 'tag_value')

表と列

指定されたタグと指定された値を持つリソースが存在する場合、trueを返します。has_tag()と同じコンテキスト動作。

タグはテーブルから列へは伝播しません。MATCH COLUMNS句でhas_tag()使用すると、列レベルのタグのみが一致し、親テーブルまたはその祖先のタグは一致しません。

注記

has_tagとhas_tag_value関数はスネークケースの命名規則を使用します。古いキャメルケース形式（ hasTag 、 hasTagValue ）は引き続き機能しますが、推奨されません。Databricksは、新しいポリシーを作成する際にキャメルケースの形式を使用することを非推奨にする予定です。既存のポリシーには影響はありません。

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

  1. has_tag_value('pii', 'email') Eメールアドレスを含む列（マスクする列）を特定します。
  2. has_tag('consent_to_contact') 同意情報を含む列を識別します（UDFがマスクするかどうかを決定するために使用します）。
SQL
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タグの列の両方を持つテーブルにのみ適用されます。テーブルに両方の条件に一致する列がない場合、ポリシーは適用されず、データはマスクされていない状態で返されます。

ユーザー定義関数（UDF）​

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

職務と権限の分離​

ABAC のセットアップにはいくつかのステップがあり、それぞれ独自の権限要件があります。組織は、職務をどのように分担するかによって、これらのタスクを特殊なグループに分配できます。例えば、組織はタグ分類を中央で定義し、その後、データスチュワードがデータを分類し、ガバナンス管理者がポリシーを作成し、データ作成者が統制された範囲内でオブジェクトを作成し、データ消費者が統制されたオブジェクトにアクセスできます。

ABACの職務分担

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

    • 必要な権限: アカウント管理者、またはアカウント レベルでタグに対するCREATE権限を持つユーザー。

  2. データアセットにタグ付け。 データスチュワード、データ作成者、または AI 分類システムは、カタログ、スキーマ、テーブル、列、モデル、およびボリュームなどの Unity Catalog セキュリティ保護可能なオブジェクトに管理タグを適用します。例えば、個人情報を含む列をpii : ssnでタグ付けするか、モデルをlifecycle : productionでタグ付けします。適切なタグ付けは、ABACポリシーが適用されるための不可欠な最初のステップです。

    • 必要な権限：タグに対してASSIGN 、オブジェクトに対してAPPLY TAG 。
警告

タグ付けはセキュリティ上の境界である。ユーザーがデータ資産のタグを変更できる場合、そのデータ資産に適用されるポリシーも変更できる。組織は、誰がタグを適用できるかを制御し、タグの変更を監査する必要があります。

  1. ポリシーを作成 ガバナンス管理者は、カタログやスキーマといったスコープでポリシーを作成します。ポリシーは、適用対象、評価する条件、および行フィルター、列マスク、または特権付与などの適用するアクションを指定します。

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

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

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

  3. 管理対象オブジェクトにアクセスします。 ユーザーがポリシーの範囲内にあるセキュリティ保護可能なオブジェクトにアクセスしようとすると、Unity Catalogは適用可能なポリシーを自動的に評価します。行フィルターと列マスクのポリシーの場合、テーブルまたは列がポリシーの条件と一致し、ユーザーが免除されていない場合は、フィルター処理またはマスクされたデータが表示されます。GRANT ポリシー（ベータ版）では、条件が一致し、ユーザーが TO に含まれ、EXCEPT に含まれていない場合に、付与された権限がユーザーに付与されます。

    • 必要な権限：行フィルターおよび列マスクのポリシーについては、ユーザーは、直接オブジェクトの付与を通じて、テーブルに対する権限（たとえば SELECT など）を付与されている必要があります。これらのポリシーは、ユーザーが既にアクセス可能なテーブルに対して、レコードをフィルター処理したり、列をマスクしたりします。それ自体では権限を付与しません。GRANT ポリシー（ベータ版）は、自らが権限を付与し、同じセキュリティ保護可能なオブジェクトに対するすべての直接付与と結合します。

ABACの利点​

  • 再利用可能 属性に基づく： 単一の は、特定のオブジェクトに縛られることなく、同じ属性ベースの条件に一致する複数のデータオブジェクトに適用できます。

  • 新規オブジェクトへの自動適用： スコープ内および関連属性を持つタグ内に新しいデータオブジェクトが作成されると、既存のABAC が追加の設定なしに適用されます。 ポリシーは将来の助成金のように機能するため、新しいデータが作成され、適切にタグ付けされると、アクセス制御が自動的に適用されます。

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

  • 継続的なメンテナンスの削減: 変更は、 テーブルレベルの行フィルターや列マスクのように個々のオブジェクトをそれぞれ再確認するのではなく、ロジックまたは管理タグを更新することで行うことができます。

  • 一元化されたガバナンス: は一度定義すれば、多くの一致するデータオブジェクトに適用できるため、ガバナンスチームはより少ない 定義で、データ資産のより広い範囲にわたるコントロールを管理できます。

その他のリソース​

このページの見出し