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

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

このページでは、ABAC（属性ベースアクセス制御）について、ABACが 管理タグ 、 ポリシー 、 ユーザー定義関数 を使用して、ユーザーが表示できる行と列の値の表示方法を制御する方法、およびその利点について説明します。このページでは、ABACの設定に必要な権限と、ABACによってチーム間で可能になる職務分掌についても説明します。

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

ABACとは何ですか？​

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

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

ABACは、テーブル、マテリアライズドビュー、およびストリーミングテーブルに対して 、行フィルタポリシー と 列マスクポリシー を通じて、行レベルおよび列レベルのセキュリティをサポートします。行フィルタポリシーは、ユーザーが表示できる行を制限します。列マスクポリシーは、列の値がユーザーにどのように表示されるかを制御します。

テーブルレベルの行フィルターと列マスクとの比較については、 「ABACとテーブルレベルの行フィルターおよび列マスクの使い分け」を参照してください。

管理タグ​

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です。
    • 現在サポートされているセキュリティ保護可能なオブジェクトタイプは、ストリーミングテーブルやマテリアライズドビューを含むテーブルのみであり、 FOR TABLES句を使用して指定します。
    • カタログに添付されたポリシーは、そのカタログ内のすべてのテーブルに対して評価されます。スキーマに添付されたポリシーは、そのスキーマ内のすべてのテーブルに対して評価されます。テーブルに添付されたポリシーは、そのテーブルに対してのみ評価されます。
注記

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

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

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

ポリシーの種類​

ABAC は、行フィルター ポリシーと列マスク ポリシーという 2 つのポリシー タイプをサポートします。 どちらの場合も、フィルタリングまたはマスキングのロジックを実装するために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言語の選択に関するガイダンスについては、 「パフォーマンスに関する考慮事項」を参照してください。

条件と組み込み機能​

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

  • テーブル条件 （ 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_name')

表と列

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

has_tag_value('tag_name', '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分類システムは、カタログ、スキーマ、テーブル、または列に管理タグを適用します。 例えば、個人を特定できる情報を含む列にはpii : ssnというタグを付けます。正しいタグは、ABAC ポリシーを適用するために不可欠な最初のステップです。

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

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

  1. ポリシーを作成する。 ガバナンス管理者は、カタログやスキーマなどのスコープでポリシーを作成します。このポリシーでは、適用対象、評価する条件、およびフィルタリングまたはマスキングのロジックを実装するUDF（ユーザー定義関数）が指定されます。

    • 必要な権限: ポリシーが添付されているセキュリティ保護可能なオブジェクト (カタログ、スキーマ、またはテーブル) に対するMANAGE権限またはオブジェクト所有権、および UDF に対するEXECUTE特権。

  2. データオブジェクトを作成します。 データ作成者は、アクセス権限が付与された範囲内でテーブルを作成します。新しいテーブルは、カタログやスキーマなどの親オブジェクトからタグを継承します。データ作成者は、作成したオブジェクトに自動的にAPPLY TAG付与するため、追加のタグを適用できます。あるいは、自動データ分類を利用してタグ付けを処理することもできる。組織がデータ作成者にオブジェクトへのタグ付けを委ねる場合、明確なタグ付け手順を確立する必要がある。 データ作成者は、ポリシーが上位レベルで設定されている場合、アクセス制御を構成する必要はありません。Databricksは上位レベルでの設定を推奨しています。

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

  3. クエリデータ。 データ利用者がポリシーの範囲内のテーブルに対してクエリを実行すると、ポリシーは自動的に評価されます。テーブルまたは列がポリシーの条件に一致し、かつユーザーが免除対象でない場合、消費者はフィルタリングまたはマスクされたデータを見ることができます。

    • 必要な権限: ユーザーは、直接オブジェクト権限付与によって、 SELECTなどのテーブルに対する権限を付与されている必要があります。ABACの行フィルタおよび列マスキングポリシーは、それ自体では権限を付与するものではありません。これらは、ユーザーが既にアクセスできるテーブルのレコードのみをフィルタリングしたり、列をマスクしたりするものです。

ABACの利点​

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

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

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

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

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

詳細情報​

このページの見出し