Open ID Connect (OIDC) フェデレーションを使用して Delta Sharing 共有（オープン共有）への認証を有効にする。

このページでは、Azure Databricks のデータ プロバイダーが認証をアイデンティティプロバイダー (IdP) に委任し、Azure Databricks で作成された Delta Sharing の共有へのアクセスを管理する方法について説明します。 この認証フローでは OIDC フェデレーションが使用され、受信者の IdP によって発行された JSON Web トークン (JWT) が、Azure Databricks によって認証された有効期間の短い OAuth トークンとして許可されます。 この Databricks から開く共有 認証方法は、Unity カタログ対応 Databricks ワークスペースにアクセスできない受信者向けに設計されています。

OIDC フェデレーションでは、受信者の IdP が JWT トークンを発行し、Multi-Factor Authentication (MFA) などのセキュリティ ポリシーを適用する役割を担います。 同様に、JWT トークンの有効期間は受信者の IdP によって管理されます。 Databricks は、これらのトークンを生成または管理しません。 認証は受信者の IdP にのみフェデレーションされ、受信者の構成済みのフェデレーション ポリシーに対して JWT が検証されます。 データ プロバイダーは、組織内の他のユーザーまたは部門と内部的にデータを共有するときに、独自の IdP に認証をフェデレーションすることもできます。

OIDC フェデレーションは、有効期間の長い Azure Databricks によって発行されたベアラー トークンを使用して、Databricks 以外の受信者をプロバイダーに接続する代わりに使用します。 これにより、きめ細かなアクセス制御が可能になり、MFA がサポートされ、受信者が共有資格情報を管理してセキュリティで保護する必要がなくなるため、セキュリティリスクが軽減されます。 代わりにベアラー トークンを使用して共有への認証を管理する方法については、ベアラー トークンを使用して Databricks 以外のユーザーのための受信者オブジェクトを作成（オープン シェアリング）を参照してください。

OIDC フェデレーションはDelta Sharingでどのように機能しますか?

1. データ プロバイダーは、Azure Databricks の Delta Sharing で受信者を作成するときに、受信者 IdP の発行者 URL (Microsoft Entra ID や Okta など) を指定し、共有へのアクセス権を持つ受信者ユーザー、グループ、サービス プリンシパル、または OAuth アプリケーションを定義する OIDC トークン フェデレーション ポリシーを構成します。

2. Azure Databricks は、ポリシーに基づいて OIDC プロファイル Web ポータルの URL を生成し、プロバイダーはその URL を受信者と共有します。

   エンド ユーザーは、優先するプラットフォームに応じてエンドポイント URL をコピーするか、プロファイル ファイルをダウンロードし、共有データのクエリを実行するプラットフォームに URL またはプロファイル ファイルを提供します。 Databricks OIDC ポータル Web からダウンロードしたこの共有プロファイル ファイルには、機密情報は含まれません。

   • ユーザー間 (U2M) 認証の場合、受信者は OIDC プロファイル Web ポータルから U2M アプリケーションに受信者エンドポイントを入力します。
   • マシン間 (M2M) 認証の場合、受信者アプリケーション開発者はプロファイル ファイルをダウンロードし、受信者クライアント アプリで参照します。

3. 受信者が優先プラットフォームを使用して共有データにアクセスしようとすると、認証は IdP にフェデレーションされます。

   Databricks では、トークンや資格情報は生成または管理されません。 代わりに、受信者の IdP によって、ID 要求を含む JWT が生成されます。 この有効期間の短いトークンの有効期間は、受信者の IdP によって適用されます。 デルタ共有サービスは、受信者のポリシーに対して JWT を検証し、発行者、対象ユーザー、サブジェクトなど、予想される要求と一致することを確認します。 検証が成功すると、要求が認証され、Unity カタログのアクセス許可に基づいてアクセスが許可されます。

開始する前に

受信者を作成するには、次の要件を満たす必要があります。

• メタストア管理者であるか、共有するデータが登録されている Unity Catalog メタストアに対して CREATE_RECIPIENT 特権を持っている必要があります。
• その Unity Catalog メタストアがアタッチされている Azure Databricks ワークスペースを使用して受信者を作成する必要があります。
• Databricks ノートブックを使用して受信者を作成する場合、コンピューティングでは Databricks Runtime 11.3 LTS 以降と、標準アクセス モードまたは専用アクセス モード (以前の共有およびシングル ユーザー アクセス モード) を使用する必要があります。

使用する ID プロバイダー

共有シナリオに応じて、内部 ID プロバイダーまたは外部 ID プロバイダーと OIDC フェデレーションを使用できます。

• 内部 ID プロバイダー (Provider-Managed)

  • これは、異なる部門が直接 Databricks にアクセスせず、同じ IdP を共有している大規模な組織内でデータを共有する場合に便利です。
  • この方法により、プロバイダーは受信者に代わってアクセスを管理できます。
  • MFA やロールベースのアクセス制御などのセキュリティ ポリシーは、プロバイダーの IdP によって適用されます。

• 外部 ID プロバイダー (Recipient-Managed)

  • プロバイダーは、受信者の IdP を信頼するように共有ポリシーを設定します。
  • 受信者組織は、共有データにアクセスできるユーザーを完全に制御できます。
  • MFA やロールベースのアクセス制御などのセキュリティ ポリシーは、受信者の IdP によって適用されます。

認証シナリオ U2M または M2M

OIDC トークン フェデレーションを使用したセキュリティで保護されたオープン共有では、ユーザーからマシン (U2M) 認証フローとマシン間 (M2M) 認証フローの両方がサポートされるため、さまざまなセキュリティで保護されたデータ共有シナリオが可能になります。

ユーザーからマシンへの認証 (U2M)

受信者組織のユーザーは、IdP を使用して認証します。 MFA が構成されている場合は、ログイン中に適用されます。

認証が完了すると、ユーザーは Power BI や Tableau などのツールを使用して共有データにアクセスできます。 データ プロバイダーは、共有リソースにアクセスできるユーザーを正確に制御できるように、受信者組織内の特定のユーザーまたはグループへのデータ アクセスを制限するアクセス ポリシーを定義できます。 U2M クライアント アプリケーション (Power BI など) は、OAuth 承認コード付与フローを使用して IdP からアクセス トークンを取得します。

マシン間 (M2M) 認証

M2M は、夜間のジョブやバックグラウンド サービスなど、ユーザーの操作なしでアクセスする必要がある自動化されたワークロードに最適です。 受信者の組織は、サービス プリンシパルを IdP に登録します。 このサービス ID を使用すると、アプリケーションまたはスクリプトはプログラムによってリソースに安全にアクセスできます。 Databricks、プロバイダー、または受信者の間でシークレットや資格情報は交換されません。 すべてのシークレット管理は、各組織の内部に残ります。 Python 差分共有クライアントや Spark 差分共有クライアントなどの M2M クライアントは、OAuth クライアント資格情報付与フローを使用して IdP からアクセス トークンを取得します。

OIDC フェデレーション ポリシーを使用する受信者を作成する

ステップ 1. Open OIDC フェデレーション受信者を作成する

OIDC を使用して認証する受信者を作成するには:

1. Azure Databricks ワークスペースで、[ カタログ。

2. [カタログ] ウィンドウの上部にあるをクリックします。歯車アイコンをクリックし、[差分共有] を選択します。

   または、クイックアクセスページでDelta Sharing >ボタンをクリックします。

3. [自分と共有] タブで、[新しい受信者] をクリックします。

4. 受信者名を入力します。

5. 受信者の種類 で、開く を選択します。

6. [認証を開く ] 方法として[OIDC フェデレーション]を選択します。

7. Create をクリックしてください。

8. (省略可能) カスタムの受信者のプロパティを作成します。 [受信者の 詳細 ] タブで、[ プロパティの編集] > [+プロパティの追加] をクリックします。 次に、プロパティ名 (キー) と値を追加します。 詳細については、「受信者のプロパティを管理する」を参照してください。

手順 2. OIDC フェデレーション ポリシーの作成

ポリシーを作成する前に、共有にアクセスできるユーザー、グループ、サービス プリンシパル、OAuth アプリケーションなど、IdP に関する必要な情報を受信者から収集します。 内部共有に独自の (内部) IdP を使用している場合は、独自の ID システムからこの情報を取得します。

まず、受信者の IdP と、共有にアクセスできるユーザー、グループ、サービス プリンシパル、または OAuth アプリケーションに関する情報を要求する必要があります。 その後、受信者を作成するときに、その情報を Azure Databricks で指定します。

受信者の編集ページで、[ OIDC フェデレーション ポリシー] の [ ポリシーの追加] をクリックします。

次のように入力します。

• ポリシー名: ポリシーの人間が判読できる名前。

• 発行者 URL: JWT トークンを発行する IdP の HTTPS URL。

• サブジェクト要求: 認証 ID の種類を識別する JWT 内の要求。 Microsoft Entra ID では、次の値を構成できます。

  • oid (オブジェクト ID): ユーザーが PowerBI などの U2M アプリケーションを介してデータにアクセスすることを目的としているかどうかを選択します。
  • groups: ユーザーのグループが、PowerBI などの U2M アプリケーションを介してデータにアクセスすることを目的としているかどうかを選択します。
  • azp: OAuth アプリケーションが、Python Delta Sharing Client や Spark Delta Sharing Client などの M2M アプリケーション経由でデータにアクセスすることを目的としているかどうかを選択します。

  他のいくつかの IDP では、sub などのクレームが使用される場合があります。 ユース ケースの正しい要求を判断するには、IdP のドキュメントを参照してください。

• 件名: 共有へのアクセスが許可されている特定のユーザー、グループ、またはアプリケーション。

• 対象ユーザー: JWT が一致する必要がある 1 つ以上のリソース識別子。 トークンは、その aud 要求がリストされている対象ユーザーのいずれかと一致する場合に有効と見なされます。

使用する値 (発行者、サブジェクト要求、サブジェクト、対象ユーザー) が不明な場合は、次の例を参照してください。 OIDC フェデレーション ポリシーを作成する前に、詳細を確認する必要があります。

外部受信者マネージド IdP を使用している場合は、セキュリティで保護されたチャネルを使用して共有されている受信者に次の情報を要求します。 内部プロバイダーマネージド IdP を使用している場合、この情報は、共有している ID に基づいて独自の IdP から取得されます。

IdP が Entra ID の場合の U2M の例:

Entra ID テナントでオブジェクト ID 11111111-2222-3333-4444-555555555555 を持つ特定のユーザーと共有するための構成例を次に示します。 aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee

• 発行者: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• サブジェクト要求: oid (オブジェクト ID)
• 件名： 11111111-2222-3333-4444-555555555555
• 対象ユーザー: 64978f70-f6a6-4204-a29e-87d74bfea138 (これは、Databricks によって Entra ID で登録されたマルチテナント アプリのクライアント ID です)

Entra ID テナントでオブジェクト ID 66666666-2222-3333-4444-555555555555 を持つ特定のグループと共有するための構成例を次に示します。 aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee

• 発行者: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• サブジェクト要求: groups
• 件名： 66666666-2222-3333-4444-555555555555
• 対象ユーザー: 64978f70-f6a6-4204-a29e-87d74bfea138 (これは、Databricks によって Entra ID で登録されたマルチテナント アプリのクライアント ID です)

U2M アプリケーションとその OIDC フェデレーション ポリシーの詳細については、「ユーザー対マシン フロー (オープン共有) で Open ID Connect (OIDC) フェデレーションを使用して Delta Sharing を受信する」を参照してください。

IdP が Entra ID の場合の M2M の例:

Entra ID テナント 11111111-2222-3333-4444-555555555555にアプリケーション (クライアント) ID aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeeeを持つ M2M OAuth アプリケーションの場合:

• 発行者: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• サブジェクト要求: azp
• subject: 11111111-2222-3333-4444-555555555555 (これは、登録された OAuth アプリケーションのクライアント ID であり、受信者の Entra ID ポータルで確認できるアプリケーション (クライアント) ID です)
• 対象ユーザー: 66666666-2222-3333-4444-555555555555 (登録されている OAuth アプリケーションのクライアント ID など、受信者によって定義された任意の有効な対象ユーザー識別子を指定できます)。M2M アプリケーションとその OIDC フェデレーション ポリシーの詳細については、 コンピューター間フロー (オープン共有) で Python クライアントと Open ID Connect (OIDC) フェデレーションを使用して差分共有共有を受信するを参照してください。

手順 3. 共有へのアクセス権を受信者に付与する

受信者を作成し、 共有を作成したら、受信者にそれらの共有へのアクセス権を付与できます。

共有へのアクセスを受信者に許可するには、カタログ エクスプローラーまたは Databricks Unity Catalog CLI を使用するか、Azure Databricks ノートブックまたは Databricks SQL クエリ エディターで GRANT ON SHARE SQL コマンドを使用できます。

必要なアクセス許可: 次のいずれか。

• メタストア管理者。
• 共有オブジェクトと受信者オブジェクトの両方に対する委任されたアクセス許可または所有権 ((USE SHARE + SET SHARE PERMISSION) または共有所有者) かつ (USE RECIPIENT または受信者所有者)。

手順については、「 デルタ共有データ共有のアクセス管理 (プロバイダーの場合)」を参照してください。

受信者ワークフロー

受信者が OIDC トークン フェデレーションを使用して共有を認証およびアクセスする方法については、次を参照してください。

• ユーザーからマシンへのフロー (オープンシェアリング) で Open ID Connect (OIDC) フェデレーションを使用して Delta Sharing のシェアを受信する
• Python クライアントと Open ID Connect (OIDC) フェデレーションを使用して、機械間フローで Delta Sharing の共有を受信する（オープン共有）