メインコンテンツまでスキップ

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

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

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

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

管理階層

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

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

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

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

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

管理職の役割設計戦略

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

グローバル管理者ロール

管理者タイプ

スコープ

主な責任

アカウント管理者

アカウント全体

アカウント設定、請求、ID 構成、ワークスペースの作成、 Unity Catalogメタストア、クラウド リソースの割り当てを管理します。

ワークスペース管理者

シングルワークスペース

ワークスペース ID、アクセス制御、設定、機能、コンピュート ポリシーを管理する

管理者タイプ

スコープ

主な責任

アカウント管理者

アカウント全体

アカウント設定、請求、ID 構成、ワークスペースの作成、 Unity Catalogメタストア、クラウド リソースの割り当てを管理します。

ワークスペース管理者

シングルワークスペース

ワークスペース ID、アクセス制御、設定、機能、コンピュート ポリシーを管理する

機能固有の管理者ロール

管理者タイプ

スコープ

主な責任

メタストア管理者

Unity Catalogメタストア

メタストア レベルでUnity Catalogオブジェクトのストレージを管理し、ワークスペース全体でデータを一元管理するためのオプションのロール

マーケットプレイスのアドミン

アカウント全体

Marketplace提供者プロフィールの管理、 Marketplaceプレイス出品の作成と管理

請求管理者

アカウント全体

予算を表示し、サーバーレス使用状況を管理する アカウント全体にわたるポリシー

管理者タイプ

スコープ

主な責任

メタストア管理者

Unity Catalogメタストア

メタストア レベルでUnity Catalogオブジェクトのストレージを管理し、ワークスペース全体でデータを一元管理するためのオプションのロール

マーケットプレイスのアドミン

アカウント全体

Marketplace提供者プロフィールの管理、 Marketplaceプレイス出品の作成と管理

請求管理者

アカウント全体

予算を表示し、サーバーレス使用状況を管理する アカウント全体にわたるポリシー

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

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

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

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

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

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

DatabricksにおけるIDタイプ:

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

ID連携のメリット:

  • 一元管理:アカウントレベルでユーザー、グループ、およびサービスプリンシパルを設定します。

  • 管理の簡素化:アカウントレベルのIDを複数のワークスペースに再作成することなく割り当てることができます。

  • 統合ガバナンス: すべてのワークスペースにわたるアイデンティティ管理のための真実の単一ソース。

  • 自動プロビジョニング: 自動 ID 管理または SCIM を使用して、ID プロバイダーから ID を同期します。

アカウントレベルのSCIM図

Databricks は、すべての新しいワークスペースで 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

プロトコル

ユースケース

サポート対象プロバイダー

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 管理により、Databricks は手動の SCIM 設定なしで、ID プロバイダーからユーザーとグループを自動的に同期できます。これは、以前の SCIM プロビジョニング モデルに置き換わり、構成の複雑さを排除します。

自動 ID 管理機能

  • 直接同期 :ユーザー、サービスプリンシパル、グループ、およびネストされたグループが、IDプロバイダーから直接同期されます。
  • 真実のソース : アイデンティティ プロバイダーが記録のソースです。変更は自動的にDatabricksに反映されます。
  • 構成の簡素化 :SCIMと比較して管理上の負担を軽減します。
  • 強化された機能 : ネストされたグループとサービスプリンシパルを Microsoft Entra ID から同期します (SCIM では利用できません)。

自動 ID 管理のベストプラクティス

  • ID同期の標準的な方法として、自動ID管理を使用してください(すべての新規導入に推奨)。
  • ネストされたグループを活用して、権限管理を簡素化しましょう。
  • 自動化されたワークロードには、ユーザーアカウントの代わりにサービスプリンシパルを使用してください。
  • Databricks管理者向けに、IDプロバイダーのグループ構造を文書化してください。

自動ID管理の詳細な設定については、 「自動ID管理」を参照してください。

注記

ID プロバイダーが自動 ID 管理でサポートされていない場合は、代わりに SCIM を使用してください。SCIM を使用して ID プロバイダーからユーザーとグループを同期するを参照してください。

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

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

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

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

JITの利点

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

JIT設計上の考慮事項

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

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

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

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

推奨

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

要件に基づいて評価する

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

フェーズ1の結果

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

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

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

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