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

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

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

ABAC とは

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

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

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

テーブル レベルの行フィルターと列マスクとの比較については、「ABAC とテーブル レベルの行フィルターと列マスクを使用する場合」を参照してください。

統制されたタグ

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です。
  • ストリーミング テーブルや具体化されたビューを含むテーブルは、現在、 FOR TABLES 句を使用して指定された、サポートされている唯一のセキュリティ保護可能な型です。
  • カタログにアタッチされたポリシーは、そのカタログ内のすべてのテーブルに対して評価されます。 スキーマにアタッチされたポリシーは、そのスキーマ内のすべてのテーブルに対して評価されます。 テーブルにアタッチされたポリシーは、そのテーブルに対してのみ評価されます。

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

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

ポリシー タイプ

ABAC では、行フィルター ポリシーと列マスク ポリシーの 2 種類のポリシーがサポートされています。 どちらの場合も、フィルター処理またはマスク ロジックを実装するために 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）を受け入れます。 列マスク ポリシーの場合、これらはマスクされた列を超える追加の引数です ( ON COLUMNから自動的にバインドされます)。 これにより、異なるパラメーターを持つポリシー間で 1 つの UDF を再利用できます。

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

条件と組み込み関数

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

• テーブル条件 (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 カタログによって評価される次の組み込み関数が使用されます。

タグはテーブルから列に伝達されません。 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タグ付けされた列の両方を持つテーブルにのみ適用されます。 テーブルに両方の条件に一致する列がない場合、ポリシーは適用されず、データはマスクされずに返されます。

ユーザー定義関数 (UDF)

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

職務と権限の分離

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

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

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

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

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

3. ポリシーを作成します。 ガバナンス管理者は、カタログやスキーマなどのスコープでポリシーを作成します。 ポリシーでは、適用するユーザー、評価する条件、フィルター処理またはマスク ロジックを実装する UDF を指定します。

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

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

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

5. データのクエリを実行します。 データ コンシューマーがポリシーのスコープ内のテーブルに対してクエリを実行すると、ポリシーは自動的に評価されます。 テーブルまたは列がポリシーの条件と一致し、ユーザーが除外されていない場合、コンシューマーにはフィルター処理されたデータまたはマスクされたデータが表示されます。

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

ABAC の利点

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

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

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

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

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

詳細情報

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