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

RBACの起動

Databricksで役割ベースのアクセス制御（RBAC）を設定し、ユーザーとDatabricks Service Principalが各タスクに必要な権限を持つロールを引き受けられるようにします。ロールとして使用するグループを選択し、それを引き受ける権限を付与し、そのアクセス権を構成します。権限モデルについては、役割ベースのアクセス制御（RBAC）を参照してください。

要件​

  • IDフェデレーションが有効になっているワークスペース。IDフェデレーションを参照してください。
  • アカウントおよびワークスペースレベルで有効なRBAC。アカウント管理者とワークスペース管理者が、それぞれの有効化ステップを実行します。
  • グループを作成してワークスペースに割り当てるためのアカウント管理者またはワークスペース管理者の権限。
  • ロールのグループに対する権限を管理して、Assume権限を付与または取り消します。アカウント管理者は、すべてのグループに対してManage（管理）権限を持っています。ワークスペース管理者は、作成したグループに対するManage（管理）権限を受け取ります。「グループを管理できるユーザー」を参照してください。
  • 既存のグループのワークスペースエンタイトルメントを管理するためのワークスペース管理者権限。
  • ロールに必要なデータ、コンピュート、およびワークスペースアセットへのアクセスを許可する権限。必要な権限は、選択するリソースによって異なります。

異なる管理者がこれらのタスクを実行できます。グループ管理者は、APIを使用してグループの権限を管理できます。「グループのアクセス権限を管理する」を参照してください。

RBAC の有効化​

RBACは、ほとんどの顧客に対してすでに有効になっています。アカウントおよびワークスペースでそれが有効になっているかどうかわからない場合は、これらの設定を確認してください。

  1. アカウント管理者として、プレビューページ のアカウントで 役割ベースのアクセス制御（RBAC）アカウントレベルの有効化 が有効になっていることを確認してください。
  2. ワークスペース管理者は、ワークスペースのプレビューページ で 役割ベースのアクセス制御（RBAC） が有効になっていることを確認してください。

アカウント設定によって、ワークスペース設定が利用可能になります。ユーザーがロールをAssumeする必要がある各ワークスペースで RBAC を有効にします。

ロールを選択または作成する​

Databricks では、ロールはアカウントグループとして実装されています。Databricksで作成したグループ、またはIDプロバイダーからの外部グループを使用できます。外部グループはアカウントグループでもあります。グループソース、およびアカウントグループとワークスペースローカルグループの違いについては、グループソースを参照してください。

グループにメンバーを含めるかどうかを決定します：

  • メンバーは、親グループの権限を含め、グループの権限を自身のアイデンティティの一部として継承します。メンバーは、グループをロールとして引き受けることで、セッションをグループの権限に制限し、グループが所有するアセットで共同作業を行うことができます。
  • グループメンバーとして追加することなく、非メンバーに直接 Assume 権限を付与できるため、グループの権限を独自のIDとして継承することはありません。データにアクセスするために意図的にロールを引き継ぐパターンでは、空のグループを使用し、空のままにします。チュートリアル: RBAC によるモデルの排他的アクセスを参照してください。

アカウントローカルロールを作成するには：

  1. アカウント管理者として、アカウントコンソールにログインします。
  2. サイドバーで、[ ユーザー管理 ] をクリックします。
  3. [ グループ ] タブで、[ グループの追加 ] をクリックします。
  4. ロールの名前を入力し、 確認 をクリックします。
  5. メンバーがグループの権限を自身のアイデンティティとして継承する必要がある場合にのみ、メンバーを追加してください。

Databricks では、ロールとして使用されるグループを区別するために、role- のような一貫したプレフィックスを使用することをお勧めします。例えば、ロールには role-study-1 を、そのロールを割り当てられるメンバーがいるグループには trial-researchers を使用します。

グループ同期の手順については、「Databricks グループの管理」を参照してください。

オプション：アカウントグループAPIを使用する​

アカウントグループAPIを使用してグループを作成および管理することもできます。Endpointと例については、「APIを使用したグループの管理」を参照してください。

Assume権限を管理する​

ユーザーとDatabricks Service Principalは、直接またはグループメンバーシップを通じてAssume権限を持っている場合、ロールを引き受けることができます。ロールを実装するグループに権限を付与します。グループメンバーはAssume権限を自動的に持っているため、メンバー以外には明示的な許可のみが必要です。

Assume権限を付与するには、アカウントコンソールまたはワークスペース管理者設定のいずれかを使用します：

  1. アカウント管理者として、 [ユーザー管理] > [グループ] を開き、そのロールのグループを選択します。
  2. アクセス許可 をクリックし、 アクセス権の付与 をクリックします。
  3. ロールを引き受けることができるユーザー、Databricks Service Principal、またはアカウントグループを選択します。
  4. 前提 を選択し、 保存 をクリックします。

グループにAssume権限を付与すると、そのメンバーはそのロールを想定できます。彼らはロール自体のメンバーである必要はありません。Assume権限を個々のユーザーまたはDatabricks Service Principalに直接付与することもできます。

Assume権限を取り消すには、適用される付与を削除します。プリンシパルが、ロールへの所属または Assume 権限を付与された別のグループへの所属を通じて、引き続きそのロールを引き受けられるか確認してください。直接の権限付与を削除しても、これらの他の経路は削除されません。

ロールの「管理」は、そのメンバーシップと権限に責任を持つ管理者に制限します。「管理」を持つプリンシパルは、他のプリンシパルに「想定」権限を付与できます。アカウントコンソールおよびワークスペース管理者の手順については「グループの権限を管理する」を、アクセス制御APIについては「グループの想定権限を付与または取り消す」を参照してください。

ワークスペースアクセスの構成​

ロールを利用可能にする各ワークスペースにロールを割り当てます。アカウント管理者とワークスペース管理者は、ワークスペースにグループを割り当てることができます。「ワークスペースにグループを割り当てる」を参照してください。

各アクセスエンタイトルメントは、ワークスペース内の特定の機能セットへのアクセスを許可します。ロールに必要なエンタイトルメントを選択してください：

  • ワークスペースへのアクセス : ノートブックやジョブなど、ワークスペースの主要機能へのアクセスを許可します。
  • Databricks SQLアクセス : ダッシュボード、クエリー、SQL WarehouseなどのDatabricks SQL機能へのアクセス権を付与します。

コンシューマーアクセスを含むすべてのアクセス権限と、それらの管理方法については、アクセス権限を参照してください。ワークスペースのdefaultの権限に依存するのではなく、ロールの権限を明示的に選択してください。概要を参照してください。

ユーザー自身のアイデンティティとしてワークスペースに割り当てるかどうかも決定します。

  • 直接または継承されたワークスペースの割り当てとアクセス権限を持つユーザーは、自分自身として入力し、そのロールを想定する許可を持つロールに切り替えることができます。
  • 直接または継承されたワークスペース割り当てを持たないユーザーがワークスペースに入るには、そのワークスペースに割り当てられたロールを引き受ける必要があります。ユーザーはそのロールに対する引き受け権限と、ロールに対するアクセス権限が必要です。「チュートリアル: ユーザーがワークスペースアクセスのためにロールを引き受けることを要求する」を参照してください。

引き受け権限は、ロールを使用できるユーザーを制御します。ワークスペースの割り当てはワークスペースがどこで利用可能かを制御し、アクセス権限はワークスペースのどの機能を使用できるかを制御します。コンピュートとワークスペースのオブジェクトに対して、データ特権と権限を個別に付与します。

リソースへのアクセスを付与する​

タスクに必要な権限をロールに付与します：

  • データ : SQL またはカタログ・エクスプローラーを使用して Unity Catalog の特権を付与します。テーブルを読み取るには、そのカタログに対する USE CATALOG、スキーマに対する USE SCHEMA、およびテーブルに対する SELECT が必要です。カタログまたはスキーマに付与された SELECT などの特権は、その現在および将来の子オブジェクトにも適用されます。特権の継承およびUnity Catalog での特権の管理を参照してください。
  • コンピュート ：選択したコンピュートリソースの使用権限を付与します。SQLウェアハウスの場合、ロールにクエリーをランすることを許可するには、「使用可能」権限を付与します。SQLウェアハウスの管理を参照してください。グループに割り当てられた専用コンピュートについては、専用コンピュートのグループアクセスを参照してください。
  • ワークスペースオブジェクト : アクセス制御リスト（ACL）を使用して、ノートブック、ジョブ、およびその他のワークスペースオブジェクトへのアクセス権を付与します。アクセス制御リストを参照してください。

ロールは、親グループから権限を継承します。defaultでは、ロールはワークスペースのusersシステムグループとアカウントのaccount usersシステムグループに付与された権限も継承します。共有権限を変更すると、それを継承する他のユーザーとロールに影響します。ロール権限の適用方法を参照してください。

ロールとして機能するユーザーが、そのロールが所有するワークスペースアセットを共有してはならない場合は、ワークスペースアセット共有コントロールを設定します。

ロールの使用と確認​

Assume権限を持つユーザーまたはDatabricks Service Principalは、RBACロールの切り替えの方法を使用してロールとして認証します。ロールが必要なリソースにアクセスできること、および意図したアクセス範囲外のリソースに対して権限エラーが発生することを確認します。その結果と、ロールなしで動作する同じアイデンティティの結果を比較します。

属性ベースのアクセス制御（ABAC）によって管理されるデータの場合、ポリシーはアクティブなロールを評価します。ID機能の動作と組み合わせパターンの詳細については、「RBAC と ABAC の使用」を参照してください。

監査属性の検証​

ロールをテストしたワークスペースと同じアカウントおよびクラウドリージョンの Unity Catalog 有効化ワークスペースから system.access.audit をクエリーします。監査リーダーには、system に対する USE CATALOG、system.access に対する USE SCHEMA、system.access.audit に対する SELECT、およびクエリーコンピュートを使用する権限が必要です。システムテーブルへのアクセス権限の付与を参照してください。

IDメタデータフィールドは、イベントに関係するIDを区別します。

  • run_by：イベントを開始したID。
  • run_as：認証に使用される ID。
  • run_by_display_name および run_as_display_name：対応する人間が読める名前です。

ロールを想定している間に行われた対話型リクエストの場合、run_by はユーザーを識別し、run_as はロールを識別します。ジョブ ワークロードの場合、run_by はジョブ サービスのアプリケーション Databricks service principal を識別します。ランユーザーをグループに設定するを参照してください。

workspace_id と event_date でフィルター処理して、テストアクティビティを見つけます。監査システムテーブルのデータは1日を通して更新され、リアルタイムモニタリングはサポートしていません。最近のイベントが見つからない場合は、後で再確認してください。監査ログシステムテーブルリファレンスおよびシステムテーブルリファレンスを参照してください。

その他のリソース​

セットアップと検証の手順については、チュートリアルを選択してください。

他のワークロードにロールを適用する前に、役割ベースのアクセス制御（RBAC）の制限事項を確認してください。

このページの見出し