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

Last reviewed 2024-06-26 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 管理者に付与します。

  • 必要最小限の数だけ特権管理者ユーザーを保持し、毎日の使用を制限します。

  • 管理ユーザーの不審なアクティビティを検出するには、監査を利用します。

シングル サインオンの使用時に外部 IdP を保護する

Cloud Identity と Google Workspace を使用すると、Active Directory、Azure Active Directory、Okta などの外部 IdP でシングル サインオンを設定できます。シングル サインオンが有効になると、外部 IdP は Cloud Identity と Google Workspace から信頼されるようになり、Google に代わってユーザー認証を行います。

シングル サインオンを有効にすると、次のようなメリットがあります。

  • ユーザーは既存の認証情報を使用して Google のサービスにログインできます。
  • 既存のログイン セッションがある場合、パスワードを再度入力する必要はありません。
  • アプリケーションとすべての Google サービスに一貫した多要素認証ポリシーを適用できます。

ただし、シングル サインオンを有効にすると、リスクも発生します。シングル サインオンが有効で、ユーザーの認証が必要な場合、Cloud Identity または Google Workspace はユーザーを外部 IdP にリダイレクトします。ユーザーを認証した後、IdP はユーザーの ID を示す SAML アサーションを Google に返します。SAML アサーションが署名されます。Google は SAML アサーションの正真性を検証し、正しい ID プロバイダが使用されていることを確認します。ただし、IdP が適切な認証を行い、ユーザーの ID を正しく記述していることを Cloud Identity と Google Workspace で確認する方法はありません。

シングル サインオンが有効になっている場合、Google デプロイの全体的なセキュリティと整合性は、IdP のセキュリティと整合性によって決まります。次のいずれかが安全に構成されていない場合、Cloud Identity アカウントまたは Google Workspace アカウントと、そのアカウントで管理されているユーザーに依存するすべてのリソースが危険にさらされます。

  • IdP 自体
  • プロバイダが実行されているマシン
  • プロバイダがユーザー情報を取得するユーザー データベース
  • プロバイダが依存する他のシステム

シングル サインオンがセキュリティ ポスチャーの弱点になることを防ぐために、次のようにして IdP とそれに依存するすべてのシステムを安全に構成します。

  • IdP またはプロバイダが依存するシステムで管理者権限を持つユーザーの数を制限します。
  • Cloud Identity または Google Workspace の特権管理者権限を付与しないユーザーには、これらのシステムに対する管理者権限を付与しないでください。
  • 外部 IdP のセキュリティ状況がわからない場合は、シングル サインオンを使用しないでください。

DNS ゾーンに対するアクセスを保護する

Cloud Identity アカウントと Google Workspace アカウントは、プライマリ DNS ドメイン名で識別されます。新しい Cloud Identity アカウントまたは Google Workspace アカウントを作成するときは、対応する DNS ゾーンに特別な DNS レコードを作成して DNS ドメインの所有権を確認する必要があります。

DNS の重要性と Google のデプロイによるセキュリティ全体への影響は、登録プロセスだけにとどまりません。

  • Google Workspace のメールのルーティングは DNS MX レコードに依存しています。MX レコードを変更すると、攻撃者が別のサーバーにメールを転送し、機密情報にアクセスしてしまう可能性があります。

  • 攻撃者が DNS ゾーンにレコードを追加できる場合、特権管理者ユーザーのパスワードをリセットし、アカウントへのアクセス権を取得する可能性があります。

DNS がセキュリティ ポスチャーの弱点になることを防ぐために、次のようにして DNS サーバーを安全に構成します。

  • Cloud Identity または Google Workspace に使用されるプライマリ ドメインを管理する DNS サーバーについては、管理者権限を持つユーザーの数を制限します。

  • Cloud Identity または Google Workspace の特権管理者権限を付与しないユーザーには、DNS サーバーへの管理者権限を付与しないでください。

  • 既存の DNS インフラストラクチャで満たしていないセキュリティ要件を持つワークロードを Google Cloud にデプロイする場合は、個別の DNS サーバーまたはマネージド DNS サービスを使用する新しい DNS ドメインの登録を検討してください。

監査ログを BigQuery にエクスポートする

Cloud Identity と Google Workspace では、複数の監査ログを保持して、構成の変更やその他の Cloud Identity アカウントまたは Google Workspace アカウントのセキュリティに関連するその他のアクティビティを追跡します。次のテーブルに、これらの監査ログの概要を示します。

ログ キャプチャされたアクティビティ
管理者 Google 管理コンソールでの操作
ログイン ドメインへのログインの成功、失敗、不審なログイン
トークン サードパーティのモバイルアプリやウェブアプリへのアクセスの承認または取り消し
グループ グループとグループ メンバーシップの変更

これらの監査ログにアクセスするには、管理コンソールまたは Reports API を使用します。ほとんどの監査ログのデータは 6 か月間保持されます

規制対象の業界で業務を行っている場合は、監査データの保存期間が 6 か月よりも長くなる場合があります。データを長期間保持する場合は、監査ログを BigQuery にエクスポートするように構成します

エクスポートされた監査ログへの不正アクセスのリスクを軽減するには、BigQuery データセット専用の Google Cloud プロジェクトを使用します。監査データを改ざんや削除から保護するには、最小限の権限の原則に従ってプロジェクトとデータセットに対するアクセス権を付与します。

Cloud Identity と Google Workspace の監査ログは、Cloud Audit Logs ログを補完するものです。BigQuery を使用して Cloud Audit Logs ログやその他のアプリケーション固有の監査ログを収集する場合、Google Cloud またはアプリケーションでユーザーが行ったアクティビティとログイン イベントを関連付けて分析できます。複数のソースから収集した監査データを関連付けることで、不審なアクティビティの検出と分析が可能になります。

BigQuery のエクスポートを設定するには、Google Workspace Enterprise ライセンスが必要です。メインの監査ログを設定すると、すべてのユーザー(Google Workspace ライセンスを持たないユーザーを含む)のログがエクスポートされます。ドライブやモバイルの監査ログなどの特定のログは、Google Workspace Business 以上のライセンスを持つユーザーについてエクスポートされます。

大半のユーザーに Cloud Identity Free を使用している場合でも、既存の Cloud Identity アカウントに Google Workspace Enterprise を追加し、選択した一連の管理者用に Google Workspace ライセンスを購入することで、BigQuery にエクスポートできます。

組織

組織を使用すると、組織ノードをルートとするプロジェクトとフォルダの階層にリソースを整理できます。組織は Cloud Identity アカウントまたは Google Workspace アカウントに関連付けられており、関連付けられているアカウントのプライマリ ドメイン名から組織名が生成されます。Cloud Identity アカウントまたは Google Workspace アカウントのユーザーが最初のプロジェクトを作成すると、組織が自動的に作成されます。

Cloud Identity または Google Workspace の各アカウントに設定できる組織は 1 つだけです。実際には、対応するアカウントがないと組織を作成できません。この依存関係にかかわらず、複数の異なるアカウントのユーザーに 1 つの組織内のリソースに対するアクセス権を付与できます。

複数のアカウントのユーザーにリソースに対するアクセス権を付与します。

異なる Cloud Identity アカウントまたは Google Workspace アカウントからのユーザーを柔軟に参照できるため、アカウントと組織の扱いを分けることができます。ユーザーの管理に必要な Cloud Identity アカウントまたは Google Workspace アカウントの数と、リソースの管理に必要な組織の数を別にすることができます。

作成する組織の数とその目的は、セキュリティ ポスチャー、チームや部門の自律性、管理の整合性と効率性に大きく影響を与える可能性があります。

以下では、使用する組織の数を決定する際のベスト プラクティスについて説明します。

必要最低限の組織数にする

組織のリソース階層を使用すると、継承により、IAM ポリシーと組織ポリシーを管理する労力を削減できます。フォルダレベルまたは組織レベルでポリシーを構成すると、リソースのサブ階層全体にポリシーが一貫して適用されるので、同じ構成作業を繰り返す必要がなくなります。管理オーバーヘッドを最小限に抑えるため、使用する組織の数をできる限り少なくすることをおすすめします

逆に、複数の組織を使用することで、柔軟性と管理の自主性を高めることができます。この後のセクションで、このような柔軟性や自主性が必要になる場合について説明します。

いずれの場合も、使用する組織の数を決定する際は、複数の組織を使用する場合の要件をすべて考慮する必要があります。そのうえで、必要最低限の数の組織を使用します。

組織を使用して管理権限を明確にする

リソース階層内では、リソース、プロジェクト、フォルダのレベルで権限を付与できます。ユーザーに付与できる最大の権限レベルは組織です。

組織レベルで組織管理者のロールが割り当てられたユーザーは、組織とそのリソース、組織に割り当てられている IAM ポリシーを完全に制御できます。組織管理者は、組織内のすべてのリソースを制御し、他のユーザーに管理者権限を自由に委任できます。

ただし、組織管理者の権限は組織に限定されるため、管理権限の最大範囲は組織になります。

  • 明示的に権限を付与されない限り、組織管理者は他の組織のリソースにはアクセスできません。
  • 組織外のユーザーがその組織の組織管理者を制御することはできません。

使用する組織の数は、社内の管理ユーザーの独立したグループ数によって異なります。

  • 会社が機能別に編成されている場合、1 つの部門で Google Cloud のすべてのデプロイを担当していること