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

モデル排他アクセス

備考

プレビュー

この機能は パブリック プレビュー段階です。

排他的アクセスは、データアクセスをアンビエントではなく**オプトイン**にするパターンです。通常の Unity Catalog アクセス許可の場合、アクセス許可はユーザーに付随します。ユーザーは時間の経過とともにアクセス許可を蓄積し、どこでもそれらを保持するため、アクセスは直接付与されたアクセス許可と、メンバーであるすべてのグループから継承されたアクセス許可の合計になります。排他的アクセス パターンにより、顧客は機密データへのアクセスを意図的なアクションを必要とするものとしてモデル化できます。つまり、ユーザーは常にデータにアクセスできるのではなく、データにアクセスするために積極的にロールを引き受ける必要があります。これにより、独自の ID としてデータにアクセスすることや、ユースケース、臨床試験、プロジェクト、クライアント間でデータを混在させることが防止されます。

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

このパターンを説明するために、関連する明確なIDについて2つの用語を使用します。これらは説明用のラベルであり、正式なDatabricks用語ではありません。

  • アクセスロール ：機密データに対するアクセス許可を保持する、メンバーがいないグループです。ユーザーはこのロールを引き継いでデータにアクセスします。アクセスロールは空のままにする必要があります。アクセスロールのメンバーは、そのアクセス許可を直接継承し、ロールを 引き継ぐことなく 機密データに到達できるため、排他的アクセスが無効になります。Databricksでは、アクセスロールはグループとして実装されます。
  • メンバーグループ ：メンバーがアクセスロールを引き受けることを許可されたユーザーであるグループ。メンバーグループにアクセスロールに対するAssumeを付与すると、すべてのメンバーがそのロールを引き受けることができます。メンバーグループは利便性のためであり、必須ではありません。個々のユーザーまたはService Principalに直接Assumeを付与することもできます。これにより、Assume付与をプリンシパルごとに個別に管理する手間が省けます。

一度構成されると、ユーザーはサポートされているいずれかの方法（ロールスイッチャー、グループに割り当てられた専用アクセスモードのクラスター、CLI、API、またはサードパーティのBIツール）を介してアクセスロールを引き受けます。「ロールの切り替え」を参照してください。

Databricks はアクセスロールを作成するために2つのアプローチをサポートしています。組織のID管理方法に最も適したものを選択してください。

  • アカウントローカルアクセスロール ：アクセスロールとしてDatabricksアカウントローカルグループを作成します。Databricksでグループを作成する方が、新しいIDプロバイダーグループを作成するよりも簡単な場合（たとえば、IDプロバイダーの変更にITチケットまたは内部レビューが必要な場合）に最適です。
  • ID プロバイダーから同期されたアクセスロール: アクセスロールとして空の ID プロバイダー グループを使用し、SCIM 経由で Databricks に同期されます。ID プロバイダーでグループをすでに管理しており、すべてのグループライフサイクルをそこに維持したい場合に最適です。

要件​

  • Unity Catalog が有効なワークスペース。
  • グループを作成し、Assume を付与するには、アカウント管理者またはワークスペース管理者の権限が必要です。

アプローチ1：アカウントローカルアクセスロール​

このアプローチでは、アクセスロールはDatabricks内で完全に管理されるDatabricksアカウントローカルグループです。メンバーグループは、アクセスロールを引き受ける権限を持つ任意のグループであることができます。これは通常、機密データへのアクセスが許可されているユーザーを含む、IDプロバイダーから同期されたグループです。

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

ステップ 1: アクセスロールを作成し、ワークスペースに割り当てます​

メンバーなしでアカウントレベルのグループを作成し、アクセスロールとして機能させます。Databricks では、アクセスロールを通常のグループと区別するために、一貫した命名プレフィックス (例: role-) を使用することをお勧めします。たとえば、許可されたユーザーのメンバーグループが clinical-trial-1-ds の場合、アクセスロールの名前を role-clinical-trial-1-ds にすることができます。

アクセスロールを作成するには:

  1. アカウント管理者として、アカウントコンソールにログインします。
  2. サイドバーで、[ ユーザー管理 ] をクリックします。
  3. [ グループ ] タブで、[ グループの追加 ] をクリックします。
  4. アクセスロールの名前を入力してください。メンバーを追加しないでください。
  5. 確認 をクリックします。

アクセスロールを作成した後、利用可能にすべきワークスペースに割り当ててください。グループをワークスペースに割り当てるを参照してください。

ステップ2：データおよびワークスペース資産へのアクセスを許可する​

標準のDatabricksツールを使用して、機密データとワークスペース資産に対するアクセスロールのアクセス許可を付与します。

  • Unity Catalog セキュリティ保護可能なオブジェクト ：GRANT ステートメントまたはカタログエクスプローラーを使用して、アクセスロールにUC権限を付与します。
  • ワークスペース資産 ：アクセス制御リスト（ACL）を使用して、アクセスロールにノートブック、ジョブ、SQL Warehouse、およびその他のワークスペースオブジェクトに対する権限を付与します。

例えば、Unity Catalogテーブルを読み取るためのアクセスロール権限を付与するには：

SQL
GRANT USE SCHEMA ON <catalog>.<schema> TO `<access-role-name>`;
GRANT SELECT ON TABLE <catalog>.<schema>.<table> TO `<access-role-name>`;

ステップ3: Assume権限を付与する​

このロールを引き受けることができる必要があるユーザー、Service Principal、またはメンバーグループに Assume アクセス許可を付与します。グループの権限を管理するを参照してください。

ステップ 4：ユーザーがロールを割り当てる​

アクセスロールに対するAssume権限を持つユーザーは、そのロールを引き受けることができます。利用可能なメソッドについては、ロールの切り替えを参照してください。

アプローチ 2：ID プロバイダーから同期されたアクセスロール​

Databricks が管理する個別のアクセスロールを作成するのではなく、このアプローチを使用して、ID プロバイダーでアクセスロールを管理し、SCIM を使用して Databricks に同期してください。アクセスロールとメンバーグループの両方が、ID プロバイダーを起点としています。

IDプロバイダー同期アクセスロール：Databricksに同期された空のIdPグループがアクセスロールとして機能し、そのロールに対してIdPメンバーグループに引き受け権限が付与されます。

このアプローチでは：

  • アクセスロール は、Databricksに同期され、機密データに対する権限が付与されている空のIDプロバイダーグループです。
  • メンバーグループ は、アクセスロールを引き受けることが許可されているユーザーをメンバーとする既存のIDプロバイダーグループです。メンバーグループにアクセスロールに対するAssumeを付与すると、そのすべてのメンバーが自動的にAssumeを継承します。
注記

IDプロバイダーでは、アクセスロールを空のままにする必要があります。IDプロバイダーのアクセスロールに追加されたメンバーはDatabricksに同期され、ロールの権限を直接継承します。そのため、ロールを引き受けることなく機密データにアクセスできます。これにより、排他的アクセスモデルが損なわれます。

ステップ 1: ID プロバイダーでグループを設定します​

グループの設定方法は、新規に設定するのか、それともDatabricksですでに権限が付与されている既存のIDプロバイダーグループを再利用するのかによって異なります。

IDプロバイダー内:

  1. アクセスロールとして機能するように空のグループを作成します。例えば、role-clinical-trial-1-dsです。
  2. アクセス ロールを引き受けることができるメンバー グループを特定または作成します。例えば、clinical-trial-1-dsです。
  3. SCIMコネクターを使用して両方のグループをDatabricksに同期します。IDプロバイダーからSCIMを使用してユーザーとグループを同期するを参照してください。

ステップ2: 両方のグループをワークスペースに割り当てます。​

アクセスロールとメンバーグループの両方を、それらが利用可能であるべきワークスペースに割り当てます。グループをワークスペースに割り当てるを参照してください。

ステップ 3: データおよびワークスペース資産へのアクセスを許可する​

注記

ステップ1で既存のIDプロバイダーグループを再利用した場合、アクセスロールにはDatabricksの権限が既に付与されているため、このステップはスキップできます。

アプローチ1のステップ2と同じ手順に従って、機密データとワークスペース資産に対する**アクセスロール**の権限を付与します。

ステップ 4：メンバーグループに引き受けのアクセス許可を付与します​

メンバーグループにアクセスロールのAssume権限を付与します。メンバーグループのすべてのメンバーは、自動的にAssume権限を継承します。「グループのアクセス権限を管理する」を参照してください。

ステップ 5: ユーザーがロールを割り当てる​

メンバーグループのメンバーは、アクセスロールを想定できます。利用可能なメソッドについては、ロールの切り替えを参照してください。

次のステップ​

  • 権限の想定を管理 ：UIまたはAPIを使用して、アクセスロールの想定権限を付与または取り消します。グループの権限を管理するを参照してください。
  • **ロールを引き受ける**：ロールスイッチャー、専用アクセスモードクラスター、CLI、API、またはサードパーティのBIツールを使用します。「ロールの切り替え」をご覧ください。
  • ワークスペースアセットの共有を制限 : アクセスロールを引き受けるユーザーが、そのロールが所有するワークスペースアセットを共有できないようにします。「ワークスペース資産共有コントロール」を参照してください。
  • 制限事項の確認: ロールを想定した場合にサポートされない Databricks 機能、およびワークスペース SCIM API のグループ管理におけるギャップなどのその他の制約について理解してください。役割ベースのアクセス制御（RBAC）の制限事項を参照してください。
このページの見出し