RBACとABACの併用

役割ベースのアクセス制御 (RBAC) は、セッションのアクティブな ID を設定します。Unity Catalog の 属性ベースのアクセス制御 (ABAC) は、その ID に行フィルターと列マスクを適用します：

• RBAC : ユーザーはロールを想定して、自身の権限ではなくそのロールの権限でアクションを実行します。ロールを使用して、プロジェクトや感度ティア間のアクセスを分離します。
• ABAC 行フィルターおよび列マスクポリシー ：アクティブな ID がすでにアクセスできるテーブルの行をフィルター処理するか、列値をマスクします。ポリシーは、カタログやスキーマなどの保護可能なオブジェクトで定義され、管理タグを使用して一致するテーブルと列を識別します。属性ベースアクセス制御（ABAC）の基本概念を参照してください。

ロールを引き受ける際の ID 機能の動作

Unity Catalog のアイデンティティ関連 SQL 関数は、基になる認証ユーザーではなく、セッションのアクティブなアイデンティティに対して解決されます。ユーザーがロールを割り当てると、アクティブなセッションのアイデンティティがそのロールになります：

関数	ユーザーが自身のユーザー ID として機能する場合	ユーザーがロールを引き受ける場合
session_user()	ユーザーのユーザー名を返します	引き受けたロールの名前を返します
is_member(group)	ユーザーがワークスペースローカルグループ、またはワークスペースに割り当てられたアカウントグループの直接または間接のメンバーである場合は、trueを返します	引き受けられたロール自体がgroupのメンバーである場合にのみ、trueを返します。基盤となるユーザーがメンバーであるグループに対してfalseを返しますが、引き受けられたロールはメンバーではありません。
is_account_group_member(group)	ユーザーがアカウントグループの直接または間接的なメンバーである場合、trueを返します	ワークスペースに割り当てられていないグループも含め、想定されるロールのアカウントおよびグループへの直接および間接のメンバーシップに基づいてtrueを返します。

関数	ユーザーが自身のユーザー ID として機能する場合	ユーザーがロールを引き受ける場合
session_user()	ユーザーのユーザー名を返します	引き受けたロールの名前を返します
is_member(group)	ユーザーがワークスペースローカルグループ、またはワークスペースに割り当てられたアカウントグループの直接または間接のメンバーである場合は、trueを返します	引き受けられたロール自体がgroupのメンバーである場合にのみ、trueを返します。基盤となるユーザーがメンバーであるグループに対してfalseを返しますが、引き受けられたロールはメンバーではありません。
is_account_group_member(group)	ユーザーがアカウントグループの直接または間接的なメンバーである場合、trueを返します	ワークスペースに割り当てられていないグループも含め、想定されるロールのアカウントおよびグループへの直接および間接のメンバーシップに基づいてtrueを返します。

引き受けたロールは、ABACポリシー評価、Unity Catalogの許可解決、および監査帰属のアクティブなIDです。したがって、ロールを引き受けることによって、ユーザーごとのIDを中心に構築された既存のポリシーとビューの動作が変更される可能性があります。

注記

ロールはそれ自体のメンバーではありません。ユーザーが役割 G を引き受けるとき、session_user() は G を返しますが、is_member('G') と is_account_group_member('G') は false を返します。ポリシーで引き受けたロールを照合するには、is_member や is_account_group_member でメンバーシップをテストするのではなく、session_user() と比較します。

SQLリファレンスでは、非推奨のcurrent_user()エイリアスの代わりにsession_user()を使用することをお勧めします。is_account_group_member()を使用してアカウントグループのメンバーシップをテストします。session_user関数とis_member関数を参照してください。

よくある落とし穴: 行レベルセキュリティビューの構築 session_user()

ABAC および テーブルレベルの行フィルターに共通するパターンは、session_user() によって返されるユーザー名をキーとしたプロビジョニングテーブル（マッピングテーブルまたはアクセス制御リストとも呼ばれます）に対して結合することによって行をフィルターすることです。例えば：

SQL

CREATE OR REPLACE FUNCTION facility_filter(facility_id STRING)
RETURN EXISTS (
  SELECT 1
  FROM governance.user_facility_provisioning p
  WHERE p.user = session_user()
    AND p.facility_id = facility_filter.facility_id
);

facility_filter.facility_id 参照は、関数パラメーターを識別します。関数名がない場合、 facility_id は代わりにプロビジョニングテーブルの列に解決されます。名前の解決を参照してください。

同じユーザーが役割を引き受けると、session_user()はユーザー名を返さなくなります。役割の名前を返します。役割はプロビジョニングテーブルに存在しないため、フィルターは行を返さず、ユーザーは許可されたデータへのアクセス権を失ったように見えます。

ロールをプロビジョニングテーブルに追加します

ロールをプロビジョニングデータ内の別のプリンシパルとして扱います。ロールが表示すべき機能（またはその他の属性）をロールごとに1行挿入します。フィルターは、アクティブなIDがユーザーか、それとも引き受けられたロールかを照合します。

組み合わせ使用パターン

以下の例は、RBACとABACの行フィルターおよび列マスクを組み合わせたものです。

要件

例を使用する前に、次のステップを完了してください。

• ABACをサポートするコンピュートを使用します。
• 管理タグを作成し、タグの適用、ユーザー定義関数(UDF)の作成、およびポリシーの管理に必要な権限を付与します。職務の分離と権限を参照してください。
• クエリーを行うアイデンティティUSE CATALOG、USE SCHEMA、およびSELECTに関連データへの権限を付与します。行フィルターと列マスクは、これらの権限を付与しません。使用権限を参照してください。
• 各UDFを権限を持つスキーマ内に作成し、そのポリシーを作成するときにそのスキーマを現在のスキーマとして使用するか、関数名を完全修飾します。完全なウォークスルーについては、 チュートリアル: SQL で ABAC を構成するを参照してください。

プロジェクトごとの行フィルターで、引き受けたロールに基づいてキー付けされたもの

ある臨床研究組織が、それぞれ独自のアクセスロールを持つ複数の並列トライアルをランします。行フィルターは、各ロールをそのトライアルのデータに制限します。同じパターンが、個別のデータアクセスを必要とする他のプロジェクトにも適用されます。各テーブルの project_id 列に、管理タグキー project のタグを付けます。列の値は、各行のプロジェクトを識別します。

セットアップ：

• clinical_trials.* のテーブルには、管理タグキー project でタグ付けされた project_id 列があります。
• 各プロジェクトには、role-<project> という名前の対応するアクセスロールがあります (例: role-alpha、role-beta)。
• ユーザーは、作業するプロジェクトのロールに対してのみ、Assume アクセス許可を持っています。

行フィルター UDF:

SQL

CREATE FUNCTION project_match(project_id STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN session_user() = CONCAT('role-', project_id);

ポリシー:

SQL

CREATE POLICY per_project_row_filter
ON CATALOG clinical_trials
ROW FILTER project_match
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('project') AS project
USING COLUMNS (project);

この UDF は、アクティブな ID と各行の project_id 列の値を比較します。MATCH COLUMNS は管理タグを使用して、その列を検索します。TO 句と EXCEPT 句は、ポリシーが適用されるプリンシパルを選択します。これらは行の値を比較しません。プリンシパルをターゲットにするガイダンスで説明されているように、単純なプリンシパルのスコープ指定には TO / EXCEPT を優先し、単一のルールがアクティブな ID と行の内容の両方に依存する場合のこのケースのように、UDF 内の ID 関数を予約します。

単一のポリシーがすべてのプロジェクトをカバーします：USING COLUMNS (project)は、一致した列からUDFに各行の値を渡します。エイリアス project は、タグ値ではなく、一致する列に名前を付けます。ルックアップ テーブルを使用して行アクセスを決定する例については、 「動的アクセス制御にマッピング テーブルを使用する」を参照してください。

動作:

• ユーザーIDとして動作するユーザーは、clinical_trialsテーブルのどの行も表示されません。session_user()はユーザー名を返します。ユーザーのユーザー名または Databricks Service Principal のアプリケーション ID と一致しないロール名を選択してください。
• role-alphaを想定しているユーザーは、project_idがalphaと等しい行のみを表示します。role-betaに切り替えた後、クエリーを再度ランしてproject_idがbetaと等しい行を表示します。

ロールが想定されない限り、個人を特定できる情報をマスクする

この例では、社会保障番号やEメールアドレスなどの個人識別情報 (PII) は、defaultでマスクされて表示されます。生の値を表示するには、ユーザーは role-pii-cleared を引き受ける必要があります。監査イベントは、データへのアクセスに使用されたロールと、イベントを開始したアイデンティティを特定します。

セットアップ：

• 機密性の高い列に、管理タグ キー pii (ssn、email、phone などの許可された値) をタグ付けします。
• メンバーを含まない role-pii-cleared グループを作成します。そのグループにAssume権限を付与します。
  • 未加工のPIIを表示する権限を持つユーザーは、このアクセスロールを引き受けてマスクされていないデータを表示できます。グループにメンバーを追加しないでください。ポリシーの EXCEPT 句によって、ロールを引き受けずにマスクされていないデータを表示できるようになるためです。

この SQL を使用して列マスク UDF を作成します：

SQL

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

ポリシー:

SQL

CREATE POLICY pii_default_mask
ON CATALOG customer_data
COLUMN MASK mask_pii
TO `account users`
EXCEPT `role-pii-cleared`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS pii_col
ON COLUMN pii_col;

EXCEPT句はポリシーからrole-pii-clearedを完全に除外するため、そのロールがアクティブなIDである場合、UDFは呼び出されません。TO/EXCEPTを介したプリンシパルターゲティングに関する一般的なガイダンスについては、プリンシパルターゲティングにはTO/EXCEPTを優先を参照してください。

動作:

• ユーザー IDとして動作するユーザーは、すべてのPII列で***を確認します。これは、role-pii-clearedに対するAssume権限を持つユーザーを含む、すべての人にとってのdefaultの状態です。
• role-pii-clearedを引き受けた後、ポリシーはセッションに適用されなくなり、同じユーザーには生の値が表示されます。
• これらのクエリーの監査イベントは、identity_metadata.run_asの承認ロールとその名前をidentity_metadata.run_as_display_nameで識別します。監査の帰属を参照してください。

引き受けられたロールによって異なる感度層ポリシー

データは機密性ティア (internal, confidential, restricted) に分類されます。各ティアには対応するアクセスロールがあり、restrictedはconfidentialとinternalへのアクセスも意味します。単一の行フィルターUDFは、各行のティアをユーザーの仮定されたロールと比較することで、行の可視性を制御します。

セットアップ：

• テーブルには、管理タグキーsensitivity（許可されている値：internal、confidential、restricted）でタグ付けされたsensitivity_level列があります。
• 3つのアクセスロール: role-sens-internal, role-sens-confidential, role-sens-restricted。

行フィルター UDF:

SQL

CREATE FUNCTION sensitivity_allowed(row_sensitivity STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN CASE
  WHEN session_user() = 'role-sens-restricted' THEN TRUE
  WHEN session_user() = 'role-sens-confidential' THEN row_sensitivity IN ('internal', 'confidential')
  WHEN session_user() = 'role-sens-internal' THEN row_sensitivity = 'internal'
  ELSE FALSE
END;

ポリシー:

SQL

CREATE POLICY sensitivity_filter
ON CATALOG corp_data
ROW FILTER sensitivity_allowed
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('sensitivity') AS sens
USING COLUMNS (sens);

ロールはそれ自体のメンバーではないため、この UDF は is_account_group_member() によるメンバーシップをテストするのではなく、session_user() を各ロール名と比較します。メンバーシップのテストが想定ロールと一致しない理由については、ロールを想定する場合の ID 関数の動作の注記を参照してください。UDF の ID 関数のパフォーマンス特性については、行フィルターおよび列マスク ポリシーのパフォーマンスに関する考慮事項を参照してください。

動作:

• ユーザー IDとして動作するユーザーには、行が表示されません。ELSE FALSE Branchは、3つのロールのいずれにも該当しないものすべてに一致します。
• role-sens-internalを仮定すると、internal行のみが表示されます。
• role-sens-confidentialと仮定すると、internalとconfidential行が表示されます。
• role-sens-restrictedですべての行が表示されると仮定します。

ユーザーはセッションに必要なティアを想定します。このフィルタはタグ付けされた列を持つテーブルに適用され、そのロールによって許可される行を返します。

監査属性

監査ログシステムテーブルでは、identity_metadata.run_by イベントを開始したユーザーを識別し、identity_metadata.run_as は認可に使用された ID を識別します。対応するrun_by_display_nameフィールドとrun_as_display_nameフィールドには、人間が読み取り可能な名前が含まれています。ロールを引き受けている間にインタラクティブに行われたクエリーの場合、これらはそれぞれユーザーとロールを識別します。ジョブワークロードには、異なるイニシエーターが存在する場合があります。ランユーザーをグループに設定するを参照してください。

監査イベントを使用して、ロールに基づくアクティビティをレビューします。どのポリシーがテーブルに適用されているかを検査するには、動的ポリシー評価の計画で説明されているようにSHOW EFFECTIVE POLICIESを使用します。監査アクセス、スキーマ、および可用性については、監査帰属の検証を参照してください。

その他のリソース

• • チュートリアル: RBAC を使用したモデルの排他的アクセス
  • ロールを使用して、2つの臨床試験の別々のデータアクセスを構成および検証します。
• • RBACロールの切り替え
  • ロールスイッチャー、専用アクセスモードクラスター、Databricks CLI、API、またはサードパーティのBIツールを使用してロールを引き受けます。
• • グループのアクセス権限を管理する
  • ユーザーが対応するロールを引き受けられるように、グループのAssume権限を付与または取り消します。
• • Unity Catalogの属性ベースのアクセス制御
  • 管理タグ、ポリシー、およびポリシー評価がどのように機能するかを学びます。