フェーズ1：アカウントとアイデンティティ戦略の設計

このフェーズでは、 Databricksアカウントの基本的なアカウント管理と ID 管理戦略を設計します。

行政区域の境界を理解する

Databricksの管理は、データのセキュリティ確保とユーザーの利便性向上において柔軟性と制御性を提供する、意図的に設計された4つのレイヤーで構成されています。これらの境界を理解することは、効果的な管理戦略を策定する上で極めて重要である。

管理階層

アカウントレイヤー ：テナント全体の管理と共有サービス（例えば、ID連携、ワークスペース管理、請求など）を一元管理します。
ワークスペース層 : チームが実行するワークロードとワークスペース固有の制御が適用される運用境界。
データガバナンス層 : Unity Catalogを通じて実現され、アカウント全体にわたるデータとAI資産の一元的なガバナンスを可能にします。
コンピュートプレーン層 : ワークロードが実行される場所とネットワークパスがどのように管理されるかを記述します。

階層型セキュリティモデル

単一の層だけでは十分ではない。管理者は、保護対策を1つの境界だけに集中させることを避け、代わりに以下の点を検討すべきです。

アカウントレベルの制御により、 一貫性のあるIDおよびガバナンスの基本事項が確立されます（例：メタストアの作成、ワークスペースとメタストアの連携、ID管理）。
ワークスペースレベルの制御は、 ユーザーの操作方法と許可される実行パターンを規定します。
データガバナンス制御は、 メタストアおよびワークスペースレベルで、きめ細かなアクセス制御と監査機能を提供します。
コンピュートプレーンの制御によって 、ワークロードが実行される場所と、ランタイムが使用できるネットワークパスが決まります。

このモデルは、データとコンピュートリソースを保護しながらユーザーを有効にするために必要な柔軟性を管理者に提供します。

管理職の役割設計戦略

Databricksは、異なる管理範囲を持つ5つの管理者ロールを提供します。組織構造、ガバナンスモデル、および職務分掌の要件に基づいて、管理職の役割戦略を設計してください。

グローバル管理者ロール

管理者タイプ	スコープ	主な責任
アカウント管理者	アカウント全体	アカウント設定、請求、ID 構成、ワークスペースの作成、 Unity Catalogメタストア、クラウドリソースの割り当てを管理します。
ワークスペース管理者	シングルワークスペース	ワークスペース ID、アクセス制御、設定、機能、コンピュートポリシーを管理する

機能固有の管理者ロール

管理者タイプ	スコープ	主な責任
メタストア管理者	Unity Catalogメタストア	メタストアレベルでUnity Catalogオブジェクトのストレージを管理し、ワークスペース全体でデータを一元管理するためのオプションのロール
マーケットプレイスのアドミン	アカウント全体	Marketplace提供者プロフィールの管理、 Marketplaceプレイス出品の作成と管理
請求管理者	アカウント全体	アカウント全体で予算を表示し、サーバーレス予算ポリシーを管理します

管理職の役割設計パターン

集中管理 ：少数のアカウント管理者チームがすべてのワークスペースとメタストアを管理します（小規模組織に適しています）。
フェデレーション管理 : アカウント管理者はアカウントレベルのサービスを処理し、ワークスペース管理者はワークスペースを管理し、メタストア管理者はデータガバナンスを管理します (大規模組織に適しています)
職務分掌 ：コンプライアンスを徹底するため、アカウント管理者、請求管理者、メタストア管理者の役割をそれぞれ別の担当者が担う（規制対象業界に適している）。

管理職向けのベストプラクティス

アカウント管理者権限は、信頼できる2～3名に限定してください。
ワークスペースの日常的な管理には、ワークスペース管理者を使用してください。
ガバナンスモデル（集中型か分散型か）に基づいて、メタストア管理者の役割を割り当てます。
監査ログを有効にして、すべてのレイヤーにわたる管理者アクティビティを追跡します。
管理上の責任とエスカレーション手順を文書化する。
可能な限り、管理者権限には個々のユーザーではなくグループを使用してください。
管理アカウント間で職務分掌を徹底する。

デザインアイデンティティ戦略

IDフェデレーションにより、アカウントレベルでユーザー、サービスプリンシパル、およびグループを一元管理し、それらのIDに特定のワークスペースへのアクセス権を割り当てることができます。アイデンティティ戦略を設計する際は、中央集権的な管理と運用上の柔軟性のバランスを取ることが重要です。

DatabricksにおけるIDタイプ：

ユーザー： Databricksによって認識されるユーザーIDであり、Eメールアドレスで表されます。
サービスプリンシパル：ジョブ、自動化ツール、スクリプト、アプリ、CI/CDプラットフォームなどのシステムで使用するためのID。
グループ: ワークスペース、データ、その他のセキュリティ保護可能なオブジェクトへのグループアクセスを管理するための ID のコレクション。

ID連携のメリット：

一元管理：アカウントレベルでユーザー、グループ、およびサービスプリンシパルを設定します。
管理の簡素化：アカウントレベルのIDを複数のワークスペースに再作成することなく割り当てることができます。
統合ガバナンス: すべてのワークスペースにわたるアイデンティティ管理のための真実の単一ソース。
自動プロビジョニング：SCIMを使用して、IDプロバイダーからIDを同期します。

アカウントレベルのSCIM図

ID フェデレーションはUnity Catalogメタストアが割り当てられているすべてのワークスペースに対して自動的に有効になります。新しいワークスペースでは、 Unity Catalogと ID フェデレーションが確実に有効になります。

包括的なID管理に関するドキュメントについては、「ユーザー、サービスプリンシパル、およびグループの管理」を参照してください。

ドメイン間アイデンティティ要件を検討する

企業によっては、電子メール専用に使用されるドメインとユーザーアクセス用に別のドメインなど、複数の電子メールドメインを持っていることがあります。このセットアップは、 SCIMプロビジョニングまたは ID プロバイダー構成で適切なマッピングを提供することでDatabricksでサポートされます。

ドメイン横断的なアイデンティティシナリオ

電子メールドメインとアクセスドメイン: ユーザーは、認証ではなく通信用に異なる電子メールアドレスを持ちます。
統合された組織: 異なる電子メールドメインを持つ複数の組織が 1 つのDatabricksアカウントに統合されました。
マルチブランド企業：異なる事業部門がそれぞれ別のメールアドレスドメインを使用するが、 Databricksプラットフォームは共有する。

ドメイン間アイデンティティ管理のベストプラクティス：

SCIM属性マッピングにおいて、電子メールアドレスを正しくマッピングします。
本番運用のロールアウト前に、すべてのドメインのユーザーの認証フローをテストします。
運用チーム向けに、ドメインマッピングの設定を文書化する。
IDプロバイダーがマルチドメインシナリオをサポートしていることを確認してください。

シングルサインオン戦略を設計する

シングルサインオン（SSO）は、IDプロバイダーを通じて認証を一元化することで、セキュリティを強化し、ユーザー管理を効率化します。IDプロバイダーの機能、セキュリティ要件、およびユーザーエクスペリエンスの目標に基づいて、SSO戦略を設計してください。

SSOプロトコルの選択

プロトコル	ユースケース	サポート対象プロバイダー
OIDC（OpenID Connect）	最新の認証方式、API統合に対応しており、新規導入に推奨されます。	Microsoft Entra ID、Okta、Google ワークスペース、OneLogin
SAML 2.0	エンタープライズSSO、レガシーシステム、一部のIDプロバイダーで必要	Microsoft Entra ID、Okta、PingFederate、ADFS

SSO設計上の考慮事項：

多要素認証（MFA）：セキュリティ強化のため、IDプロバイダーでMFAを有効にしてください。
代替認証：緊急アクセスを利用して、IDプロバイダーの障害発生に備える計画を立てる。

AWS固有のオプション ：企業全体でIDプロバイダーを使用していない組織向けに、DatabricksはソーシャルSSOオプションとして「Googleでサインイン」と「Microsoftでサインイン」をサポートしています。これらはOAuth 2.0およびOpenID Connectプロトコルに依存しています。GoogleもMicrosoftも利用しない場合は、ユーザーは電子メールでワンタイムパスコードを受け取ることもできます。

SSOのベストプラクティス：

SSOと多要素認証を組み合わせることで、認証を一元化し、パスワードのリスクを軽減できます。
SSO設定を有効にする前に、テストユーザーを使用して設定をテストしてください。
ユーザーのメールアドレス、名、姓の属性マッピングを正確に設定してください。
ユーザーが締め出されないように、徹底的なテストを行った後にのみSSO（シングルサインオン）の適用を有効にしてください。
IDプロバイダーのメンテナンス期間とフェイルオーバーシナリオを計画してください。
ロックアウトを防ぐために、緊急アクセスを設定してください。鍵の紛失を防ぐための緊急アクセスについては、「緊急アクセス」を参照してください。

SSOの設定手順の詳細については、「DatabricksでのSSOの設定」を参照してください。

ユーザープロビジョニング戦略の設計

自動化されたユーザープロビジョニングにより、一貫性のあるID管理が保証され、手動によるユーザー管理が不要になります。IDプロバイダーの機能、組織規模、および運用要件に基づいて、プロビジョニング戦略を設計してください。

SCIMは、IDプロバイダーからDatabricksへのユーザーおよびグループのプロビジョニングを自動化します。SCIMは手動によるユーザー管理を不要にし、組織全体で同期されたアクセスを保証します。

SCIMは以下のIDプロバイダーをサポートしています。

Microsoft Entra ID
Okta
OneLogin
ピングワン
汎用SCIM 2.0準拠プロバイダー

SCIMのベストプラクティス：

SCIMとSSOを組み合わせることで、シームレスな認証とプロビジョニングを実現します。
すべてのユーザーに対して有効化する前に、テストユーザーまたはテストグループを使用してテストユーザープロビジョニングを実施してください。
SCIM安全に保管し、定期的にローテーションします。
IDプロバイダーからDatabricksのフィールドに、ユーザーおよびグループの属性を正確にマッピングします。
SCIM同期ログを監視して、プロビジョニングのエラーや障害がないか確認してください。
ディザスタリカバリシナリオのSCIM構成を文書化します。

SCIM の設定手順の詳細については、「SCIM を使用して ID プロバイダからユーザーとグループを同期する」を参照してください。

ジャストインタイムプロビジョニングを理解する

ジャストインタイム（JIT）プロビジョニングは、ユーザーがシングルサインオン（SSO）を使用してDatabricksに初めてログインしたときに、ユーザーアカウントを自動的に作成します。これにより、手動でのアカウント作成が不要になり、ユーザーのオンボーディングが効率化されます。

JITプロビジョニングワークフロー

ユーザーはSSO IDプロバイダーを介して認証を行う
Databricksは認証済みユーザーのアカウントが存在するかどうかを確認します
アカウントが存在しない場合、Databricks は ID プロバイダーの属性を使用して新しいユーザーアカウントをプロビジョニングします。
ユーザーは割り当てられたワークスペースに即座にアクセスできるようになります

JITの利点

自動オンボーディング ：新規ユーザーは手動でアカウントを作成する必要はありません。
管理業務の負担軽減 ：アカウント作成に関するチケット発行やそれに伴う遅延を解消します。
一貫性のあるプロビジョニング ：ユーザー情報はIDプロバイダーから自動的に同期されます。
ユーザーエクスペリエンスの向上 ：認証後、ユーザーはすぐにDatabricksにアクセスできるようになります。

JIT設計上の考慮事項

ワークスペースの割り当て : 新しいユーザーをワークスペースに割り当てる方法を計画します (たとえば、手動割り当てと自動グループベースの割り当て)。
まだ権限 : 新しくプロビジョニングするユーザーのための権限を定義します。
属性マッピング ：IDプロバイダーが正確なユーザー属性（例：メールアドレス、名前）を提供することを確認します。

JIT プロビジョニングは、2025 年 5 月 1 日以降に作成されたアカウントに対して、安全により有効になります。

JIT プロビジョニング構成の詳細については、「ユーザーを自動的にプロビジョニングする (JIT)」を参照してください。

アカウントと本人確認に関する推奨事項

推奨

アカウントレベルで、IDプロバイダーによるシングルサインオン（SSO）認証を実施してください。
セキュリティ強化のため、IDプロバイダーの多要素認証（MFA）を活用してください。
SCIMまたはAIMを使用して、ユーザーとグループをアカウントコンソールに同期します。
自動化されたユーザーオンボーディングのために、ジャストインタイム（JIT）プロビジョニングを有効にします。
アカウント管理者の数を制限する（信頼できる2～3名程度）。
管理アカウント間で職務分掌を徹底する。
組織構造とガバナンス要件に基づいて、ワークスペース管理者の権限を制限する。
サービスプリンシパルにはOAuth認証を使用してください。
サービスプリンシパルを使用して、管理タスクと本番運用ワークロードを実行します。
Terraformまたは類似のツールを使用して、すべての管理業務を自動化する。
管理上の役割、責任、およびエスカレーション手順を文書化する。
可能な限り、管理者権限には個々のユーザーではなくグループを使用してください。

要件に基づいて評価する

組織が複数のメールドメインを使用している場合は、ドメイン間のID要件を検討してください。
管理上の役割の細分化と業務の複雑さのバランスを取る。
認証プロバイダーの障害発生時の緊急アクセス手順を検討してください。
IDプロバイダーのメンテナンス期間とSSOフェイルオーバーシナリオを計画する。

第1相の結果

フェーズ1を完了すると、以下のものが得られます。

管理者役割戦略を設計しました（例：アカウント管理者、ワークスペース管理者、メタストア管理者）。
IDフェデレーション戦略が定義されました（SCIMを使用したアカウント優先プロビジョニング）。
プロトコル選択（OIDCまたはSAML）とMFA要件を考慮して設計されたSSO戦略。
ユーザープロビジョニング戦略が定義されました ( SCIM + JIT プロビジョニング)。
ドメインをまたいだ本人確認要件を特定しました（該当する場合）。
管理上の責任とエスカレーション手順が文書化されている。
自動化されたワークロード向けに設計されたサービスプリンシパル戦略。

次の段階 ：フェーズ2：ワークスペース戦略の設計

実装ガイダンス ：アカウントとID戦略を実装するための手順については、「ユーザー、サービスプリンシパル、およびグループの管理」を参照してください。

行政区域の境界を理解する​

管理職の役割設計戦略​

デザインアイデンティティ戦略​

ドメイン間アイデンティティ要件を検討する​

シングルサインオン戦略を設計する​

ユーザープロビジョニング戦略の設計​

ジャストインタイムプロビジョニングを理解する​

アカウントと本人確認に関する推奨事項​

第1相の結果​