アカウントと組織の計画に関するベスト プラクティス

Last reviewed 2023-02-27 UTC

このドキュメントでは、Cloud Identity アカウント、Google Workspace アカウント、Google Cloud 組織、請求先アカウントをいくつ使用する必要があるかを決定する際のベスト プラクティスを紹介します。このドキュメントでは、セキュリティと組織の要件を満たす設計を特定するためのガイダンスを示します。

Google Cloud では、Cloud Identity and Access Management は次の 2 つの要素に基づいています。

  • Cloud Identity アカウントと Google Workspace アカウントは、ユーザーとグループのコンテナです。したがって、これらのアカウントは企業ユーザーを認証し、Google Cloud リソースへのアクセスを管理するための鍵となります。Cloud Identity アカウントと Google Workspace アカウントは、個々のユーザー アカウントではなく、ユーザーのディレクトリを表します。個々のユーザー アカウントはユーザーまたはユーザー アカウントと呼ばれます。

  • 組織は、Google Cloud 内のプロジェクトとリソースのコンテナです。組織を使用すると、リソースを階層的に構成し、リソースを一元的かつ効率的に管理できます。

このドキュメントは、主にエンタープライズ環境を設定するユーザーを対象としています。

Cloud Identity アカウントと Google Workspace アカウント

Google Workspace は、クラウドネイティブなコラボレーション アプリと生産性向上アプリの統合スイートです。これには、ユーザー、グループ、認証を管理するツールが含まれています。

Cloud Identity は、Google Workspace の機能の一部を提供します。Cloud Identity も Google Workspace と同様にユーザー、グループ、認証を管理できますが、Google Workspace のすべてのコラボレーション機能と生産性向上機能を備えているわけではありません。

Cloud Identity と Google Workspace は共通の技術プラットフォームを共有し、同じ API と管理ツールのセットを使用します。これらのプロダクトは、ユーザーとグループのコンテナとしてアカウントというコンセプトを共有しています。このコンテナは、example.com などのドメイン名で識別されます。ユーザー、グループ、認証を管理する点では、この 2 つのプロダクトは同等と見なされます。

Cloud Identity と Google Workspace を 1 つのアカウントに統合する

Cloud Identity と Google Workspace は共通のプラットフォームを共有しているため、プロダクトへのアクセス権を 1 つのアカウントに統合できます。

すでに Google Workspace アカウントを管理しており、さらに多くのユーザーが Google Cloud を使用できるようにする必要があるものの、Google Workspace ライセンスをすべてのユーザーに割り当てることは回避する必要があると考えているとします。この場合、Cloud Identity Free を既存のアカウントに追加します。その後、追加料金なしでより多くのユーザーをオンボーディングし、そのユーザーに Google Workspace ライセンスを割り当てることで Google Workspace にアクセスできるユーザーを決定できます。

同様に、すでに Cloud Identity Free または Premium アカウントを管理している場合は、特定のユーザーに Google Workspace を使用する権限を付与できます。それらのユーザー用に個別の Google Workspace アカウントを作成するのではなく、既存の Cloud Identity アカウントに Google Workspace を追加できます。選択したユーザーに Google Workspace ライセンスを割り当てると、ユーザーは仕事効率化アプリとコラボレーション アプリを使用できるようになります。

必要最小限のアカウントを使用する

ユーザーが Google Workspace を使用して共同作業できるようにし、管理上のオーバーヘッドを最小限に抑えるためには、1 つの Cloud Identity アカウントまたは Google Workspace アカウントですべてのユーザーを管理して、個々のユーザーには 1 つのユーザー アカウントを付与することをおすすめします。これにより、パスワード ポリシー、シングル サインオン、2 段階認証プロセスなどの設定をすべてのユーザーに一貫して適用できます。

単一の Cloud Identity アカウントまたは Google Workspace アカウントを使用することにはこうしたメリットがあります。一方、複数のアカウントを使用すると、柔軟性と管理上の自主性を高めることができます。使用する Cloud Identity アカウントまたは Google Workspace アカウントの数を決定する際は、複数のアカウントを使用する場合の要件をすべて考慮する必要があります。そのうえで、必要最小限の数の Cloud Identity アカウントまたは Google Workspace アカウントを使用します。

ステージング環境と本番環境に別々のアカウントを使用する

Cloud Identity と Google Workspace で構成できるほとんどの設定では、各設定を適用する範囲を選択できます。たとえば、データの地理的な保管場所をユーザー別、グループ別、組織部門別に指定できます。新しい構成を適用する場合は、最初に小さな範囲(ユーザーなど)を選択し、その構成が期待どおり機能しているかどうか確認します。構成に問題がなければ、同じ設定をより多くのグループや組織部門に適用します。

一般的な設定とは異なり、Cloud Identity アカウントまたは Google Workspace アカウントを外部 ID プロバイダ(IdP)と統合することの影響は全体に及びます。

  • シングル サインオンの有効化は、特権管理者以外のすべてのユーザーに適用されるグローバル設定です。
  • 外部 IdP によっては、ユーザー プロビジョニングの設定も全体に影響します。外部 IdP で誤って構成された場合、ユーザーが誤って変更、停止、削除されてしまう可能性があります。

これらのリスクを軽減するために、ステージング用と本番環境用の Cloud Identity アカウントまたは Google Workspace アカウントを用意します。

  • 本番環境用アカウントに変更を適用する前に、ステージング用のアカウントで構成の変更にリスクがないかどうか確認します。
  • 自分や他の管理者が構成の変更を確認できるように、ステージング用のアカウントに数人のテストユーザーを割り当てます。ただし、ユーザーにステージング用アカウントへのアクセスを許可してはなりません。

外部 IdP のステージング インスタンスと本番環境のインスタンスが異なる場合は、次の操作を行います。

  • ステージング用の Cloud Identity アカウントまたは Google Workspace アカウントを、ステージング用の IdP インスタンスと統合します。
  • その後、本番環境用の Cloud Identity アカウントまたは Google Workspace アカウントを、本番環境用の IdP インスタンスと統合します。

たとえば、Active Directory との連携を設定し、テスト用の Active Directory フォレストを用意するとします。この場合、ステージング用の Cloud Identity アカウントまたは Google Workspace アカウントをステージング フォレストと統合し、その後、本番環境用の Cloud Identity アカウントまたは Google Workspace アカウントをメインのフォレストと統合します。次の図に示すように、DNS ドメインユーザーグループについて、同じマッピング アプローチを両方のフォレスト / アカウントのペアに適用します。

DNS ドメイン、ユーザー、グループの Active Directory マッピング アプローチ。

本番環境とステージングの Active Directory フォレスト / ドメインが使用する DNS ドメインで、ステージングと本番環境に同じドメイン マッピング アプローチを適用できない場合があります。この場合は、ステージング フォレストにユーザー プリンシパル名(UPN)サフィックス ドメインを追加登録することを検討してください。

同様に、Azure Active Directory との連携を設定する場合は、次の方法をおすすめします。

  • ステージング用の Cloud Identity アカウントまたは Google Workspace アカウントを、ステージング用の Azure Active Directory テナントと統合します。
  • その後、本番環境用の Cloud Identity アカウントまたは Google Workspace アカウントをメインの Azure Active Directory テナントと統合します。

DNS ドメインユーザーグループについて、テナント / アカウントの両方のペアに同じマッピング アプローチを適用します。

DNS ドメイン、ユーザー、グループの Azure Active Directory マッピング アプローチ。

本番環境とステージングの Azure Active Directory テナントが使用する DNS ドメインで、ステージングと本番環境に同じドメイン マッピング アプローチを適用できない場合があります。この場合は、ステージング用のテナントにドメインを追加することを検討してください。

Cloud Identity アカウントと Google Workspace アカウントで別々の DNS ドメインを使用する

example.com などのドメインを Cloud Identity アカウントまたは Google Workspace アカウントに初めて追加する場合は、対象ドメインを所有していることを確認する必要があります。ドメインを追加、確認した後は、サブドメインを個別に確認しなくても marketing.example.comfinance.example.com などのサブドメインを追加できます。

ただし、各サブドメインを確認せずに追加すると、このサブドメインをすでに使用している別の Cloud Identity アカウントまたは Google Workspace アカウントが存在する場合、競合が発生する可能性があります。このような競合を避けるには、アカウントごとに別のドメインを使用することをおすすめします。たとえば、2 つの Cloud Identity アカウントまたは Google Workspace アカウントが必要な場合は、一方のドメインが他方のサブドメインになっているような 2 つのドメインを使用しないようにします。別のドメインのサブドメインになっていないドメインを使用してください。この方法は、プライマリ ドメインとセカンダリ ドメインにも適用されます。

Google Workspace と Google Cloud を分離しない

すでに Google Workspace を使用している場合は、Google Workspace アカウントの一部のユーザーに特権管理者権限が付与されている可能性があり、それらのユーザーは管理タスクを行うことが可能です。

特権管理者権限を持つユーザーには、組織ノードの Identity and Access Management(IAM)ポリシーを変更する権限が暗黙的に付与されます。この権限により、特権管理者は自分自身に組織管理者ロールまたは Google Cloud 組織内の他のロールを割り当てることができます。Cloud Identity アカウントまたは Google Workspace アカウントに対する特権管理者権限があれば、アカウントとそのアカウントに関連付けられている Google Cloud 組織、およびそのすべてのリソースを削除することもできます。特権管理者は組織内のすべてのリソースに完全アクセス権を持っていると想定する必要があります。

既存の Google Workspace 管理者が Google Cloud 組織の管理を担当するユーザーと異なる場合、特権管理者が組織管理者でもあるという事実は、特権管理者が組織管理者になっていると、セキュリティ上の問題が発生する可能性がありますこの場合、Google Workspace の特権管理者の Google Cloud リソースへのアクセス権を制限するために、Google Cloud 専用の Cloud Identity アカウントを別に作成すること決定することもできます。Google Workspace と Google Cloud を分離すると、予期しない結果が生じることがあります。

たとえば、Cloud Identity アカウントに個別のユーザーを作成し、Google Cloud 組織ユーザーに対するアクセスを Cloud Identity アカウントに制限できます。これにより、Google Cloud のデプロイメントと Google Workspace が完全に分離されます。ただし、ユーザーが重複していると、ユーザー エクスペリエンスが低下し、管理オーバーヘッドが増加します。また、Cloud Identity で使用されているドメインは、Google Workspace で使用されているドメインとは異なる必要があり、メールのルーティングに適していないため、Google Cloud から送信される通知メールは受信できません。

代わりに Google Cloud 組織の Google Workspace アカウントからユーザーを参照すると、Google Workspace と Google Cloud の間の分離は弱くなります。

Google Cloud 組織の Google Workspace アカウントからユーザーを参照する。

Google Workspace の特権管理者は、ドメイン全体の委任を使用して、同じ Google Workspace アカウント内で任意のユーザーの権限を借用できます。悪意のある特権管理者が、昇格した権限を使用して Google Cloud にアクセスする可能性があります。

個別のアカウントを使用するよりも効果的な手段は、Google Workspace 管理者と Google Cloud 管理者間で権限を分離して、特権管理者の数を減らすことです。

  • Google Workspace での多くの管理作業には、特権管理者の権限は必要ありません。特権管理者の権限の代わりに、既定の管理者ロールまたはカスタムの管理者ロールを使用して、管理者の作業に必要な権限を Google Workspace 管理者に付与します。

  • 必要最小限の数だけ特権管理者ユーザーを保