Oktaを使用した自動ID管理への移行

注記

自動ID管理には、プレミアムプラン以上が必要です。

このページでは、DatabricksアカウントをOktaを使用した自動ID管理に移行する方法について説明します。

Okta を構成するステップについては、「自動ID管理のための Okta の構成」を参照してください。

自動ID管理の概要については、「自動ID管理」を参照してください。

前提条件

自動ID管理を有効にする前に、環境が以下の要件を満たしていることを確認してください：

• シングル Okta テナント : 自動ID管理は、テナント間のIDをサポートしていません。すべてのユーザーとグループは、単一の Okta テナントに属している必要があります。テナント間のIDを持つ環境では、System for Cross-domain Identity Management（SCIM）プロビジョニングを継続する必要があります。
• 少なくとも1つのワークスペースでIDフェデレーションが有効 ：自動ID管理には、少なくとも1つのIDフェデレーションワークスペースが必要です。非フェデレーションワークスペースは引き続き機能しますが、自動ID管理は使用されません。有効にするには、IDフェデレーションの有効化を参照してください。
• アカウント管理者ロール : アカウント管理者のみが自動ID管理を有効にできます。

Okta を使用した自動ID管理では、同じテナントを使用して Databricks アカウントに対して Okta Single Sign On (SSO) が構成されている必要もあります。SSO が構成されていない場合、または別のテナントを使用する必要がある場合は、Databricks アカウントチームにお問い合わせください。Okta を構成するには、「自動ID管理のための Okta の構成」を参照してください。

変更されない点

自動ID管理を有効にすると、以下が保持されます：

• SCIM 同期されたグループメンバーシップ : 自動 ID 管理では、元々 SCIM によって同期されたグループメンバーシップは削除されません。これは、それらのメンバーシップに依存するジョブや権限が破損するのを防ぐための設計上の仕様です。
• 既存の権限 ：ワークスペースおよびUnity Catalogの権限は、引き続き同じプリンシパルに対して解決されます。
• アクティブなセッション : 自動ID管理は、ユーザーの強制ログアウトや実行中のセッションの中断を行いません。
• ワークスペースローカルグループ ：自動ID管理は、アカウントレベルのIDのみを管理します。ワークスペースローカルグループは引き続き機能しますが、Oktaからは同期されません。

既存のSCIMプロビジョニングなしで移行する

DatabricksアカウントにアカウントレベルのSCIMプロビジョニングがない場合は、このパスを使用してください。これが最もシンプルな移行パスです。

1. 自動ID管理を有効にする：

   自動ID管理のためのOktaの設定に従って、Oktaを構成し、自動ID管理を有効にします。これにより、必要なロールと権限を持つOktaアプリが作成され、自動ID管理が有効になります。変更が反映されるまで5～10分ほどお待ちください。

2. (オプション) アカウントアクセス拒否リストを構成します。アカウントアクセス拒否リストを使用して、特定のOkta IDによるDatabricksアカウントへのアクセスを制限します。IDによるアカウントへのアクセスを拒否するを参照してください。

3. （オプション）ワークスペース管理者に通知します。Just-in-Timeプロビジョニングを含む予期される動作の変更をワークスペース管理者が理解できるよう、自動ID管理の概要を共有してください。

自動 ID 管理を有効にした後、検証ステップを完了してください。

既存の SCIM プロビジョニングからの移行

現在DatabricksアカウントでアカウントレベルのSCIMプロビジョニングを使用している場合は、このパスを使用してください。Databricksでは、既存のSCIMプロビジョニングと並行して自動ID管理を有効にし、両方を並行して実行することを推奨しています。自動ID管理が正常に動作していることを確認した後で、SCIMを無効にできます。

自動ID管理を有効にした場合の変更点

挙動	自動ID管理の前	自動ID管理の後
IDの発生元	SCIMは、スケジュールに基づいてOktaからアカウントのSCIM Endpointにユーザーとグループをプッシュします。	Databricksは、Okta Identity APIを使用してOktaから直接IDを読み取ります。プロビジョニングは、初回使用時またはログイン時にジャストインタイム（JIT）で行われます。
Oktaでのグループ名の変更	SCIMは、次回の同期サイクルで表示名を更新します。	グループ名は自動的に再同期されません。アカウント管理者がアカウントコンソールでグループ詳細ページを開くと、更新がトリガーされます。resolveByExternalId APIを呼び出して同期をTriggerすることもできます。
グループメンバーシップの同期待機時間	次の SCIM サイクルまでお待ちください (通常 40 分かかります)。	ブラウザサインイン: 最大5分。非ブラウザ（ジョブ、CLI、Service Principal）: 最大40分。

挙動	自動ID管理の前	自動ID管理の後
IDの発生元	SCIMは、スケジュールに基づいてOktaからアカウントのSCIM Endpointにユーザーとグループをプッシュします。	Databricksは、Okta Identity APIを使用してOktaから直接IDを読み取ります。プロビジョニングは、初回使用時またはログイン時にジャストインタイム（JIT）で行われます。
Oktaでのグループ名の変更	SCIMは、次回の同期サイクルで表示名を更新します。	グループ名は自動的に再同期されません。アカウント管理者がアカウントコンソールでグループ詳細ページを開くと、更新がトリガーされます。resolveByExternalId APIを呼び出して同期をTriggerすることもできます。
グループメンバーシップの同期待機時間	次の SCIM サイクルまでお待ちください (通常 40 分かかります)。	ブラウザサインイン: 最大5分。非ブラウザ（ジョブ、CLI、Service Principal）: 最大40分。

移行の準備

自動ID管理を有効にする前に、Okta接続を構成してください。ステップ1: Oktaアプリケーションのセットアップに従い、必要なロールと権限を付与してください。次に、ステップ2: DatabricksでのOktaの構成 から Test connection を実行します。以下の準備ステップを完了するまで、 Enable AIM をクリックしないでください。

1. 自動ID管理の準備状況レポートを実行します。

   準備状況レポートは、DatabricksとOkta間の外部IDおよびグループメンバーシップの不一致を特定します。

注記

自動ID管理では、ID同期の信頼できるLinkとしてOkta IDを使用します。Databricksにおけるプリンシパルの externalId がOkta IDと一致しない場合、製品内でIDが複数回表示されたり、外部IDベースの同期が失敗したりする可能性があります。自動ID管理を有効にする前に準備状況レポートを実行し、これらの構成ミスを特定して解決してください。構成ミスの全リストとその影響については、エラーカテゴリと修復を参照してください。

2. (オプション) アカウントアクセス拒否リストを構成します。アカウントへのIDのアクセス拒否を参照してください。

3. （オプション）ワークスペース管理者に通知します。Just-in-Timeプロビジョニングを含む予期される動作の変更をワークスペース管理者が理解できるよう、自動ID管理の概要を共有してください。

自動ID管理を有効にする

ステップ2: DatabricksでのOktaの構成の手順に従って、 Okta org URL 、 Client ID 、 Client Private key を設定し、 Test connection を実行して、 Enable AIM をクリックします。変更が反映されるまで5～10分ほどお待ちください。

自動ID管理とSCIMプロビジョニングは、両方がアクティブな間は並行して実行されます。SCIMは、元々プロビジョニングしたIDの管理を継続します。自動ID管理を検証した後、SCIMを無効にできます。SCIMプロビジョニングを無効にするを参照してください。

自動ID管理を検証する

自動ID管理を有効にした後、IDが正しく同期されていることを確認してください。

ロールによるテスト

各ロールの代表ユーザーに、以下のテストを実行してもらってください。

Account admin

1. アカウントコンソールからユーザーをプロビジョニングします：

   1. アカウント console > User Management > Users に移動し、Add user をクリックします。
   2. DatabricksでプロビジョニングされていないユーザーをOktaで検索します。
   3. ユーザーを選択し、 [ユーザーの追加] をクリックします。
   4. ユーザーが Databricks 内でステータス Active として表示されることを確認します。

2. アカウントコンソールからグループをプロビジョニングします：

   1. アカウント console > User Management > グループ に移動し、Add グループ をクリックします。
   2. DatabricksでプロビジョニングされていないグループをOktaで検索します。
   3. グループがDatabricksに表示されることを確認します。グループメンバーは、ログイン時にJust-In-Timeベースでプロビジョニングされます。

3. ワークスペースのアクセス権を確認します：

   1. 前のステップのグループをワークスペースに割り当てます。
   2. そのグループのメンバーに、ワークスペースへの認証を行わせてください。
   3. 認証が成功し、ユーザーがDatabricksでプロビジョニングされ、ワークスペースに追加されたことを確認します。

Workspace admin

1. ワークスペースからユーザーをプロビジョニングします：

   1. [設定] > [IDとアクセス] > [ユーザーの管理] に移動し、 [ユーザーの追加] をクリックします。
   2. DatabricksでプロビジョニングされていないユーザーをOktaで検索します。
   3. ユーザーのステータスが アクティブ と表示されていることを確認します。

2. ワークスペースからグループをプロビジョニングします：

   1. クエリーやダッシュボードなどのワークスペースアセットを開き、 共有 をクリックします。
   2. DatabricksでプロビジョニングされていないグループをOktaで検索し、そのグループとアセットを共有します。
   3. グループがDatabricksでプロビジョニングされていることを確認してください。
   4. そのグループのメンバーにワークスペースで認証させ、共有アセットにアクセスできることを確認します。

監査logsで自動ID管理を確認する

system.access.auditテーブルをクエリーして、自動ID管理がアクティブであることを確認します。add、addPrincipalToGroup、createGroup、updateUserなどのイベントのカウントがゼロ以外であれば、IDが同期されていることが確認できます。

SQL

SELECT action_name, count(*) AS n
FROM system.access.audit
WHERE request_params.endpoint = 'autoUserCreation'
  AND event_time > current_timestamp() - INTERVAL 2 DAYS
GROUP BY action_name
ORDER BY n DESC;

自動 ID 管理の監査イベントの詳細については、自動 ID 管理イベントの監査を参照してください。

自動ID管理を無効化

自動ID管理を無効にするステップについては、「自動ID管理を無効にする」を参照してください。

SCIMから移行した後に自動ID管理を無効にする場合：

• 自動ID管理によって作成されたIDはDatabricksに残りますが、Oktaとは同期されなくなります。
• 自動ID管理によって同期されたグループメンバーシップは、権限の解決には使用されなくなりました。それらのグループメンバーシップを通じて以前に権限を継承していたユーザーは、アクセス権を失います。
• 自動 ID 管理が有効な間に Databricks に対して認証を行ったユーザーは、以前に表示したダッシュボードに引き続きアクセスできますが、グループメンバーシップは Okta から更新されません。
• 自動ID管理が無効化された後、Databricksに一度もアクセスしたことのないユーザーは、Oktaで割り当てられたグループに属していてもアクセスできません。

Databricksでは、自動ID管理を無効にする前にSCIMプロビジョニングを設定することをお勧めします。OktaのSCIMプロビジョニングを構成するを参照してください。

SCIMプロビジョニングを無効にする

自動ID管理の検証後、必要に応じてSCIMプロビジョニングを無効にできます。環境内で以下のすべての条件が満たされていることを確認した後にのみ、SCIMを無効にしてください。

• 外部IDの整合性 : SCIMを使用してOktaからレプリケートされたグループは、Databricks内のexternalId値が対応するOkta ID値と一致します。自動ID管理レディネスレポートを実行して、不一致を特定します。
• ローカルでのメンバーシップの変更なし ：グループメンバーシップはSCIMを通じてのみ管理されており、Databricksで手動で変更されていません。準備状況レポートは、ローカルで変更されたメンバーシップを検出できます。

環境がこれらの条件をすべて満たしていない場合、DatabricksではSCIMプロビジョニングと自動ID管理を並行して実行し続けることをお勧めします。

SCIM無効化後の既知の制限事項

永続的なSCIM同期グループメンバーシップ

SCIMによって同期されたグループメンバーシップは、SCIMが無効になった後も保持されます。Databricksでは、SCIMを無効にする前に、外部グループからの直接グループメンバーシップをクリーンアップすることを推奨しています。

手動で変更されたグループメンバーシップ

Databricksでグループメンバーシップが手動で編集されている場合、SCIMを無効にした後、それらのメンバーシップはOktaと同期されず、時間の経過とともに古くなる可能性があります。自動ID管理が有効な場合、Oktaがグループメンバーシップの信頼できる唯一のソースとなるため、Databricksではローカルで変更されたメンバーシップを削除することを推奨しています。SCIMを無効にする前に、自動ID管理準備状況レポートを実行して、これらのメンバーシップを特定してください。

移行における考慮事項

グループメンバーはJust-In-Timeベースでプロビジョニングされます

SCIM とは異なり、自動ID管理はグループメンバーシップを Databricks にプロアクティブに同期しません。グループメンバーは、Databricks でアクティビティが発生したとき（ログイン時など）、またはアカウント管理者やワークスペース管理者が明示的に追加したときにプロビジョニングされます。

削除されたユーザーはすぐには非アクティブ化されません

ユーザーがOktaから削除されると、Databricks上では引き続きアクティブとして表示されますが、ログインはできなくなります。

メールアドレスの変更により、新しいユーザーが作成されます

OktaでユーザーのEメールアドレスが変更された場合（例：alice@example.comがalice-new@example.comになる）、自動ID管理は既存のレコードを更新するのではなく、Databricksに新しいユーザーを作成します。これは現在のSCIMの動作と一致しています。Eメールアドレスの変更については、Databricks サポートにお問い合わせください。

SCIM API が自動ID管理を通じてプロビジョニングされたメンバーを返さない

SCIM GET /groups/{id} API は、Databricks UI または SCIM を介してプロビジョニングされたグループメンバーのみを返します。自動ID管理を介してプロビジョニングされたユーザーや、Oktaには存在するもののDatabricksではまだプロビジョニングされていないユーザーは返されません。

Unity Catalogの権限にはプロビジョニングされたIDが必要です

Unity Catalog のアクセス許可付与 APIs は、Databricks でまだプロビジョニングされていない ID を参照できません。ID にアクセス許可を付与する前に、resolveByExternalId API を使用してプロビジョニングしてください。ID がプロビジョニングされたら、通常どおりアクセス許可を付与できます。

is_account_group_member()のように名前でプリンシパルを参照する関数でも、最初にプリンシパルをプロビジョニングする必要があります。

ワークスペースローカルグループは自動ID管理によって管理されません

自動 ID 管理では、ワークスペースローカルグループは管理されません。ワークスペースローカルグループとその割り当てられた権限は引き続き機能しますが、メンバーシップの更新は自動 ID 管理の外部で処理する必要があります。

Databricksでは、自動ID管理がメンバーシップを管理できるように、ワークスペースローカルグループをアカウントレベルのグループに移行することを推奨しています。ワークスペースローカルグループをアカウントグループに移行するを参照してください。