チュートリアル: RBACを使用したモデルの排他的アクセス

役割ベースのアクセス制御（RBAC）を使用して、相互に分離する必要があるデータセットへの排他的アクセスを強制します。各データセットが指定されたロールを通じてのみアクセス可能な場合、ユーザーと AI エージェントはデータセットにアクセスするためにそのロールを引き受ける必要があります。別のデータセットにアクセスするにはロールを切り替える必要があるため、単一のクエリーでユースケース、プロジェクト、臨床試験、またはクライアント間でデータを結合することはできません。分離したままにする必要があるデータセットを結合することは、 トキシック結合 と呼ばれることがあります。

シナリオ

ある研究者が、1つのワークスペースで2つの臨床試験に取り組んでいます。両方の試験にアクセスする必要がありますが、1つの試験での作業で他の試験のデータを使用することはできません。試験ごとに個別のロールを構成し、許可されたクエリーと拒否されたクエリーをテストし、いずれかのロールとして作成されたワークスペース資産の共有を制限します。

研究者は引き続きワークスペースに割り当てられ、自分自身としてワークスペースに入ることができます。ワークスペースへのエントリにロールを要求するには、「チュートリアル: ワークスペースアクセスにユーザーがロールを引き受けることを要求する」を参照してください。

この例では2種類のグループを使用します。これらは説明用のラベルであり、正式な Databricks 用語ではありません。

アクセスロール : トライアルのデータに対する権限を保持する空のグループ。role-study-1とrole-study-2を作成します。それらは空のままにしておきます。メンバーはグループの権限を継承するため、メンバーはロールを想定せずにデータを読み取ることができます。
メンバーグループ : trial-researchers。メンバーは両方のアクセスロールを引き受けることができます。これには Assume 権限が保持されますが、試用データに対する権限は保持されません。メンバーグループはオプションです。Assume権限を個々のユーザーまたはDatabricks Service Principalに直接付与することもできます。

研究者は役割を切り替えることができますが、各役割は自らの研究のテーブルのみを読み取ることができます：

排他的アクセス例：ユーザー1は、Study 1グループまたはStudy 2グループを引き継ぐことができます。自身のIDとして機能している場合、ユーザー1はいずれの研究データもクエリーできません。Study 1 グループとして機能している場合、ユーザー 1 は Study 1 のデータのみをクエリーできます。Study 2 グループとして機能している場合、Study 2 のデータのみをクエリーできます。

図では、Study 1グループは role-study-1 に対応し、Study 2グループは role-study-2 に対応しています。

前提条件

RBACが有効なUnity Catalog有効化ワークスペース。RBACを有効にするを参照してください。
ロールの作成、Assume権限の付与、ワークスペース割り当ての管理を行うためのアカウント管理者またはワークスペース管理者権限。「グループを管理できるユーザー」を参照してください。
エンタイトルメント、コンピュートアクセス、共有制限を構成するワークスペース管理者権限。
ワークスペースからアクセス可能な、マネージドストレージを持つ既存のテストカタログ。データを作成する管理者は、カタログの所有者でなければなりません。このチュートリアルでは、新しいスキーマ study_1 および study_2 で trials を使用します。研究者またはどちらかのロールが両方のデータセットにアクセスできるようにする広範な権限がないカタログを使用します。カタログの作成を参照してください。
テストデータセットを作成するカタログ所有者に使用権限が付与されたSQLウェアハウス。warehouseへのアクセスを許可するユーザーには、ワークスペース管理者権限またはwarehouseに対する管理権限が必要です。
研究者を含むアカウントグループ。この例では trial-researchers という名前です。そのメンバーの 1 人が、独自のサインインを使用して検証に参加します。この研究者は、管理者、カタログ所有者、または広範なデータアクセス権を持つグループのメンバーであってはなりません。
各ロールのテストノートブック用のワークスペースフォルダー。ワークスペース管理者は、ステップ3でこれらのフォルダーへのアクセスを構成します。
ステップ8については、「監査属性の確認」で説明されているように構成された監査リーダーが必要です。

全体を通して独自のカタログ名、グループ名、ワークスペース名に置き換えてください。クリーンアップが他のワークロードに影響しないように、架空のテストデータと新しいスキーマおよびロールを使用します。

ステップ 1: テストデータセットを作成する

スキーマのいずれかが既に存在する場合は、既存のオブジェクトを置き換えるのではなく、新しいスキーマ名を選択します。

カタログ所有者としてSQLエディターを開き、テストwarehouseを選択して、以下を実行します。

SQL
CREATE SCHEMA trials.study_1;
CREATE SCHEMA trials.study_2;

CREATE TABLE trials.study_1.patient_info (
  participant_id STRING,
  outcome STRING
) USING DELTA;

CREATE TABLE trials.study_2.patient_info (
  participant_id STRING,
  outcome STRING
) USING DELTA;

INSERT INTO trials.study_1.patient_info VALUES ('study-1-a', 'improved');
INSERT INTO trials.study_2.patient_info VALUES ('study-2-a', 'unchanged');

参加者IDと結果は架空のものです。両方のクエリーをランして、テーブルが存在し、warehouseがそれらを読み取れることを確認します：

SQL
SELECT * FROM trials.study_1.patient_info LIMIT 100;
SELECT * FROM trials.study_2.patient_info LIMIT 100;

各クエリーは、その調査の単一行を返します。

ステップ 2: アクセスロールを作成し、Assume権限を付与する

主要な手順では、アクセスロールにアカウントローカルグループを使用します。アカウントローカルグループは、Databricksでグループを作成する方が、IDプロバイダーから新しいグループをリクエストするよりも簡単である場合に便利です。メンバーグループは、この図に示すように、アカウントローカルにするか、IDプロバイダーから同期することができます。

アカウントローカルのアクセスロール：アカウントローカルのグループがアクセスロールとして機能し、メンバーグループにそのグループに対する割り当て権限が付与されます。

いずれかの方法で最初の空のロールを作成します：

Account console
Workspace admin settings

アカウント管理者として、アカウントコンソールにログインします。
サイドバーで、[ ユーザー管理 ] をクリックします。
[ グループ ] タブで、[ グループの追加 ] をクリックします。
role-study-1を入力してください。メンバーを追加しないでください。
確認をクリックします。
ワークスペースアクセス と Databricks SQLアクセス を使用して、テストワークスペースにグループを割り当てます。ワークスペースへのグループの割り当てを参照してください。

ワークスペース管理者として、テストワークスペースにログインします。
上部のバーにあるユーザー名をクリックし、 [設定] を選択します。
[ IDとアクセス ] タブをクリックします。
[ グループ ] の横にある [ 管理 ] をクリックします。
[ グループを追加 ]をクリックしてから、[ 新規追加 ]をクリックします。
role-study-1を入力し、 ワークスペースアクセス と Databricks SQLアクセス を選択します。ステップ3では、このチュートリアルで両方を使用する理由を説明します。
[ 追加 ] をクリックします。メンバーを追加しないでください。

これにより、グループがワークスペースに割り当てられ、それに対する管理権限が付与されます。

研究者にAssume権限を付与します

ロールのデータ権限を割り当てる前に、研究者にロールを引き継ぐ権限を付与します。

Account console
Workspace admin settings

アカウント管理者として、アカウントコンソールで ユーザー管理 > グループ を開き、role-study-1を選択します。
「権限」、次に「 アクセスを付与 」をクリックします。
trial-researchers を選択し、 Assume を選択して、 Save をクリックします。

ロールに対する管理権限を持つワークスペース管理者として、テストワークスペースで 「設定」 > 「アイデンティティとアクセス」 を開きます。
[ グループ ] の横にある [ 管理 ] をクリックし、role-study-1 を選択します。
「権限」、次に「 アクセスを付与 」をクリックします。
trial-researchers を選択し、 Assume を選択して、 Save をクリックします。

ステップを繰り返してロールを作成し、role-study-2に対してAssume権限を付与します。両方のロールは空のままです。命名ガイダンスとAPIベースのグループ作成については、ロールの選択または作成を参照してください。

ステップ 3：ワークスペースとコンピュートのアクセスを構成する

ステップ2で両方のロールをテストワークスペースに割り当てました。ワークスペース管理者として、両方のロールと trial-researchers が、既に割り当てられているグループを含めて、両方のアクセス権限を持っていることを確認します。

ワークスペースアクセス : ノートブック、ジョブ、モデル、パイプラインなどの主要なワークスペース機能へのアクセスを許可します。このチュートリアルでは、ノートブックを使用して共有制御を検証します。
Databricks SQLアクセス : ダッシュボード、クエリー、SQL WarehouseなどのDatabricks SQL機能へのアクセス権を付与します。このチュートリアルでは、SQLエディターを使用してデータアクセスを確認します。

すべてのアクセスの資格とそれらの管理方法については、アクセス権限を参照してください。

trial-researchersが割り当てられていない場合は、ワークスペースに割り当てます。ワークスペースにグループを割り当てるを参照してください。

研究者がユーザーIDとして入力し、ロールを使用した後に切り替えられるように、研究者を割り当てたままにしておきます。

各グループにSQLウェアハウスへのアクセス権を付与します。

ワークスペースのサイドバーで、[ SQL ウェアハウス ] をクリックします。
warehouseの [ アクセス許可 ] ダイアログを開きます。
各グループに 使用可能 を追加し、保存します。

継承アクセスが広範囲に及ばないワークスペースの場所にある、各ロール専用のテストフォルダーを作成します。role-study-1にフォルダーの「管理可能」権限を付与し、role-study-2にもう一方のフォルダーの「管理可能」権限を付与します。ロールは、ステップ7でノートブックを作成するためにこれらのフォルダーを使用します。ワークスペースオブジェクトの管理とフォルダーACLを参照してください。

ステップ 4: 各ロールにスタディへのアクセス権を付与する

カタログ所有者として、以下をラン。

SQL
GRANT USE CATALOG ON CATALOG trials TO `role-study-1`;
GRANT USE SCHEMA ON SCHEMA trials.study_1 TO `role-study-1`;
GRANT SELECT ON TABLE trials.study_1.patient_info TO `role-study-1`;

GRANT USE CATALOG ON CATALOG trials TO `role-study-2`;
GRANT USE SCHEMA ON SCHEMA trials.study_2 TO `role-study-2`;
GRANT SELECT ON TABLE trials.study_2.patient_info TO `role-study-2`;

trial-researchers にトライアルデータ権限を付与しないでください。そのメンバーは代わりにAssume権限を受け取ります。

テスト前に直接アクセスと継承されたアクセスを確認してください：

研究者は、ユーザーIDとしていずれかのテーブルの読み取りを許可する他の許可またはグループメンバーシップを持っていてはなりません。
親グループは、いずれのロールデータアクセスも他の研究に提供しません。
カタログとスキーマの権限とテーブルの権限を確認します。カタログレベルまたはスキーマレベルのSELECT権限は、現在および将来の子オブジェクトに適用され、両方のテーブルにアクセスできるようにします。特権の継承を参照してください。

Catalog Explorer の [アクセス許可] tab を使用して、カタログ、両方のスキーマ、および両方のテーブルの付与を検査します。Unity Catalog での特権の管理を参照してください。共有付与がこの構成を妨げる場合は、分離されたテストカタログまたはワークスペースを使用してください。共有付与を削除すると、無関係なユーザーやロールに影響を与える可能性があります。

ステップ5: ロールが所有するワークスペース資産の共有の制限

共有制限がない場合、ロールとして行動するユーザーは、そのロールが所有するワークスペースアセットを共有できます。両方のロールに対して制限を設定します。

ワークスペース管理者として、ユーザー名をクリックして「設定」を選択します。
詳細設定 をクリックします。
「グループの共有制限」 を見つけて、編集ボタンをクリックします。
role-study-1 と role-study-2 を追加します。リストに既にあるグループは維持されます。
保存をクリックします。

この制限は、制限付きロールとして機能している間に適用されます。そのロールが所有するワークスペース資産の共有を制御します。これは Unity Catalog オブジェクトの権限を制御するものではなく、データをコピーするあらゆる方法をブロックするものではありません。ワークスペースアセット共有コントロールを参照してください。

ステップ6: IDごとにデータアクセスを確認する

研究者の1人が自身のサインインを使用してこれらのチェックを完了します：

テストワークスペースにサインインし、ワークスペース名の下に自分のユーザー名が表示されていることを確認します。
SQLエディタを開き、テストwarehouseを選択します。

各クエリーを個別にランします：

SQL
SELECT * FROM trials.study_1.patient_info LIMIT 100;
SELECT * FROM trials.study_2.patient_info LIMIT 100;

どちらのクエリーも権限エラーで失敗します。

トップバーのワークスペース名をクリックし、現在のワークスペースにカーソルを合わせて、ロールスイッチャーから role-study-1 を選択します。
ワークスペースがリロードされたら、ロール名を確認し、SQLエディターを開き、同じwarehouseを選択して、両方のクエリーを繰り返します。Study 1クエリーのみが成功します。
role-study-2 に切り替えて、クエリーを繰り返します。Study 2 クエリーのみが成功します。
ユーザー名に切り替えてチェックを繰り返します。両方のクエリーが再び拒否されます。

アクティブなID	スタディ 1 のクエリー	Study 2クエリー
研究者のユーザーID	権限エラー	権限エラー
`role-study-1`	戻り値 `study-1-a`	権限エラー
`role-study-2`	権限エラー	戻り値 `study-2-a`

アクティブなID	スタディ 1 のクエリー	Study 2クエリー
研究者のユーザーID	権限エラー	権限エラー
`role-study-1`	戻り値 `study-1-a`	権限エラー
`role-study-2`	権限エラー	戻り値 `study-2-a`

テーブルが存在しない、Warehouseが利用できない、認証エラーが発生したとしても、アクセスが排他的であるとは限りません。ステップ1のカタログ所有者のチェックにより、両方のテーブルが存在することが確認されました。予期しないクエリーが成功した場合は、続行する前にステップ4の付与とメンバーシップを確認してください。

ロールを引き受ける他の方法については、「RBACロールの切り替え」を参照してください。このブラウザでロールを切り替えても、個別に認証されたDatabricks CLIプロファイルや接続は変更されません。

ステップ 7: ワークスペースアセットの共有を確認する

同じ研究者が各ロールに対してこれらのチェックを繰り返します。

ロール切り替え機能を使用してロールを引き受けてください。
[ワークスペース] で、ロールのテストフォルダを右クリックし、 [作成] > [ノートブック] を選択します。
研究にちなんでノートブックに名前を付けます。コードを実行する必要はありません。
ロールが新しいノートブックを所有していることを確認してから、それを共有してみてください。制限付きロールとして行動している間は、アセットに対して「管理可能」を持っている場合でも、共有は利用できません。

研究者が所有するノートブックではなく、そのロールとして行動している間に作成されたノートブックを使用します。ノートブックの作成および制限の検証を参照してください。

ステップ8: 監査の帰属を確認する

監査リーダーとして、このクエリーをランします。<workspace-id> をテストワークスペースのIDに置き換えます:

SQL
SELECT event_time, service_name, action_name,
       identity_metadata.run_by, identity_metadata.run_by_display_name,
       identity_metadata.run_as, identity_metadata.run_as_display_name
FROM system.access.audit
WHERE workspace_id = '<workspace-id>'
  AND identity_metadata.run_as_display_name IN ('role-study-1', 'role-study-2')
  AND event_date >= current_date() - INTERVAL 1 DAY
ORDER BY event_time DESC;

研究者のテストクエリーとノートブック作成のイベントを見つけます。identity_metadata.run_byは各イベントを開始した研究者を特定し、run_asは承認に使用されたロールを特定します。クエリーは、ロールの人間が読み取れる名前であるrun_as_display_nameでフィルタリングします。監査データは1日を通して更新されるため、最近のイベントはすぐには表示されない場合があります。ID メタデータのリファレンスを参照してください。

オプション: IDプロバイダーでアクセスロールを管理する

組織がグループのライフサイクル管理を ID プロバイダーで維持する場合は、この代替方法を使用します。System for Cross-domain Identity Management (SCIM) プロビジョニングを通じて、空のアクセスロールグループとメンバーグループを Databricks に同期します。SCIM を使用した ID プロバイダーからのユーザーとグループの同期を参照してください。

IdPから同期されたアクセスロール：空のグループがアクセスロールとして機能し、同期されたメンバーグループにそれに対する「Assume」権限が付与されます。

アイデンティティプロバイダーで各アクセスロールを空のままにします。そこにメンバーを追加すると、それらのメンバーシップが Databricks に同期され、メンバーはロールを引き継ぐことなくデータ権限を継承します。

新しいIDプロバイダーグループから起動

ステップ 2 でアカウントローカルロールの代わりに新しい ID プロバイダーグループを使用するには、次の手順を実行します:

IDプロバイダーで、各アクセスロールの空のグループを作成します。
研究者を含むメンバーグループを特定または作成します。
アクセスロールとメンバーグループをDatabricksアカウントに同期します。
ステップ2の手順を使用して、各アクセスロールにメンバーグループAssume権限を付与します。

既存のIDプロバイダーグループを再利用する

IDプロバイダーから同期されたグループがすでにDatabricksで目的のデータ特権を保持している場合は、グループをアクセスロールとして再利用することで、それらの許可を保持できます。

IDプロバイダーで新しいメンバーグループを作成します。たとえば、既存のグループがclinical-trial-1-dsの場合は、clinical-trial-1-ds-membersを作成します。
既存のグループのすべてのメンバーを新しいメンバーグループに移動し、既存のグループを空にします。
両方のグループをDatabricksに同期し、アクセスロールにメンバーがいないことを確認します。
新しいメンバーグループにアクセスロールのAssume権限を付与します。研究者がデータに永続的にアクセスできるようにする可能性のある他の付与やメンバーシップを確認します。

既存のグループは、データ権限とワークスペース権限を保持します。これらの付与を再作成する必要はありませんが、意図した研究境界と一致していることを確認してください。ユーザーが元のグループから移動すると継承された権限が失われるため、グループの所有者とメンバーシップの変更を計画してください。

ワークスペースの構成とチェックを完了する

ワークスペースとメンバーグループの両方にアクセスロールを割り当て、ステップ 3 のように資格とコンピュートアクセスを構成します。代わりにワークスペースへの入力にロールの想定を要求するには、「チュートリアル: ワークスペースアクセスにロールの想定を要求する」を参照してください。

新しいアクセスロールについては、ステップ4のようにデータアクセスを付与し、ステップ3のようにワークスペースアセットアクセスを付与してください。再目的化されたグループについては、既存の権限を置き換えるのではなく、確認してください。

メンバーグループに各アクセスロールに対するAssume権限があることを確認します。そのすべてのメンバーは、そのロールを引き受けることができます。

共有制限を構成し、IDプロバイダーのグループ名とデータセットを使用して、ステップ5から8までのデータ、共有、および監査チェックを繰り返します。

クリーンアップ

一時的なテストとして、このチュートリアルで作成されたリソースと権限のみを削除します:

カタログ所有者として、2つのテーブルにチュートリアルのテストデータのみが含まれていることを確認し、ランします。
SQL
```
DROP TABLE trials.study_1.patient_info;
DROP TABLE trials.study_2.patient_info;
DROP SCHEMA trials.study_1 RESTRICT;
DROP SCHEMA trials.study_2 RESTRICT;
```
スキーマドロップは、他のオブジェクトが残っている場合は失敗します。他のワークロードで使用されている既存のカタログまたはスキーマをドロップしないでください。
ワークスペース管理者として、テストノートブックとフォルダーを削除します。ロールを削除する前に、そのロールが所有する他のアセットを確認してください。
テスト用に作成されたAssume権限とリソース権限の許可を取り消します（カタログとwarehouseの許可を含みます）。研究者の既存のアクセス権を保持しながら、テスト専用のワークスペース割り当てを削除します。
グループの共有を制限 からテストロールを削除し、他のエントリはそのままにしてください。
新しく作成した空のロールは、どのワークロードやアセットもそのロールを使用していないことを確認した後にのみ削除してください。同期されたグループの場合、同期によって削除されたグループが再作成されないように、IDプロバイダーでライフサイクルを変更します。既存のメンバーグループとそのユーザーは保持してください。

既存のグループを再利用する場合は、元のメンバーシップと割り当てを復元する別のロールバックを計画してください。テストリソースのクリーンアップを使用して、既存のアクセスモデルを削除しないでください。

次のステップ

- Assume 権限の管理
- UIまたはAPIを使用して、ロールを引き受けることができるユーザーを管理します。
- RBAC ロールの切り替え
- ロールスイッチャー、専用コンピュート、Databricks CLI、API、またはサードパーティのBIツールを使用します。
- RBACによるワークスペース資産共有の制御
- ワークスペースアセットの共有コントロールが、ロールおよびネストされたグループにどのように適用されるかを確認します。
- 複合的な使用パターン
- ロールがアクセスできるテーブル内で、行フィルターまたは列マスクを適用します。
- ロールベースのアクセス制御 (RBAC) の制限
- 機能のサポート、既知の問題、およびグループ管理APIの制限を確認します。

シナリオ​

前提条件​

ステップ 1: テストデータセットを作成する​

ステップ 2: アクセスロールを作成し、Assume権限を付与する​

研究者にAssume権限を付与します​

ステップ 3：ワークスペースとコンピュートのアクセスを構成する​

ステップ 4: 各ロールにスタディへのアクセス権を付与する​

ステップ5: ロールが所有するワークスペース資産の共有の制限​

ステップ6: IDごとにデータアクセスを確認する​

ステップ 7: ワークスペースアセットの共有を確認する​

ステップ8: 監査の帰属を確認する​

オプション: IDプロバイダーでアクセスロールを管理する​

新しいIDプロバイダーグループから起動​

既存のIDプロバイダーグループを再利用する​

ワークスペースの構成とチェックを完了する​

クリーンアップ​

次のステップ​