このドキュメントでは、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 ドメイン、ユーザー、グループについて、同じマッピング アプローチを両方のフォレスト / アカウントのペアに適用します。
本番環境とステージングの Active Directory フォレスト / ドメインが使用する DNS ドメインで、ステージングと本番環境に同じドメイン マッピング アプローチを適用できない場合があります。この場合は、ステージング フォレストにユーザー プリンシパル名（UPN）サフィックス ドメインを登録することを検討してください。
同様に、Azure Active Directory との連携を設定する場合は、次の方法をおすすめします。
- ステージング用の Cloud Identity アカウントまたは Google Workspace アカウントを、ステージング用の Azure Active Directory テナントと統合します。
- その後、本番環境用の Cloud Identity アカウントまたは Google Workspace アカウントをメインの Azure Active Directory テナントと統合します。
DNS ドメイン、ユーザー、グループについて、テナント / アカウントの両方のペアに同じマッピング アプローチを適用します。
本番環境とステージングの Azure Active Directory テナントが使用する DNS ドメインで、ステージングと本番環境に同じドメイン マッピング アプローチを適用できない場合があります。この場合は、ステージング用のテナントにドメインを追加することを検討してください。
Cloud Identity アカウントと Google Workspace アカウントで別々の DNS ドメインを使用する
example.com などのドメインを Cloud Identity アカウントまたは Google Workspace アカウントに初めて追加する場合は、ドメインの所有権を確認する必要があります。ドメインを追加、確認した後は、サブドメインを個別に確認しなくても marketing.example.com や finance.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 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 のすべてのデプロイを担当していることがあります。
- 会社が部門別に組織されている場合や、複数の子会社を所有している場合は、1 つの部門で担当していないこともあります。
1 つの部門で Google Cloud のデプロイを管理している場合は、1 つの Google Cloud 組織ノードを使用することをおすすめします。組織内で、フォルダを使用してリソースを構成し、他のチームや部門にさまざまなレベルのアクセス権を付与します。
複数の独立した部門を扱う場合、1 つの組織で管理を一元化しようとすると、問題が発生する可能性があります。
- 組織を管理する部門を 1 つに限定すると、他の部門からクレームを受ける可能性があります。
- 複数のチームや部門が 1 つの組織を共有して所有すると、リソース階層の一貫性を維持するのが困難になり、リソース全体で一貫した IAM ポリシーと組織のポリシーを適用できなくなる可能性があります。
このような問題を回避するには、複数の組織を使用して、組織ごとに個別のフォルダ構造を作成します。別々の組織を使用することで、管理ユーザーのグループ間に境界を設定し、管理権限を明確にします。
別のステージング組織を使用する
整合性を維持しながら、同じ構成作業を繰り返さないようにするには、プロジェクトをフォルダに整理し、フォルダまたは組織レベルで IAM ポリシーと組織ポリシーを適用します。
多くのプロジェクトやリソースにポリシーを適用することにはデメリットがあります。ポリシー自体またはポリシーが適用されるリソース階層が変更されると、広範囲にわたり意図しない結果が生じる可能性があります。こうしたリスクを回避するため、メインの組織に適用する前に、ポリシーの変更をテストすることをおすすめします。
別のステージング組織を作成することをおすすめします。この組織では、アクセスレベルやポリシーなど、組織全体に影響を及ぼす可能性のあるリソース階層の変更、IAM ポリシー、組織ポリシー、その他の構成をテストできます。
ステージング組織で行ったテストまたはテスト結果が本番環境の組織にも反映されるように、メインの組織と同じフォルダ構造にします。ステージング組織の IAM ポリシーと組織ポリシーは、本番環境の組織ポリシーと一致するか、本番環境の組織に適用する次のバージョンのポリシーを反映している必要があります。
次の図に示すように、ステージング用の Cloud Identity アカウントまたは Google Workspace アカウントをステージング組織の基盤として使用します。ステージング アカウント（またはステージング アカウントが統合されている外部 IdP）を使用して専用のテストユーザーを作成し、本番環境の Cloud Identity アカウントまたは Google Workspace アカウントで使用するものと同じグループ構造を作成します。これらの専用のテストユーザーとグループを使用することで、既存のユーザーに影響を与えることなく、IAM ポリシーをテストできます。
別のテスト組織を使用しない
Google Cloud にデプロイする本番環境のワークロードごとに複数のテスト環境が必要になります。たとえば、開発チームと DevOps チームが新しいリリースの検証に使用できるテスト環境が必要になります。
セキュリティの観点から、テストされていないリリースが本番環境のワークロードに誤って影響しないように、テスト環境を本番環境から明確に分離する必要があります。同様に、この 2 つの環境では IAM ポリシーの要件も異なります。たとえば、デベロッパーやテスターに必要な柔軟性を付与するために、テスト環境のセキュリティ要件を本番環境よりも大幅に緩和できます。
次の図に示すように、構成上はテスト環境をできるだけ本番環境に近いものにする必要があります。相違があると、テスト環境で正常に動作したデプロイが本番環境で失敗するリスクが高くなります。
環境を分離しながら一貫性を保つには、同じ組織内のフォルダを使用して、テスト環境と本番環境を管理します。
- 組織レベルで共通の IAM ポリシーまたは組織ポリシーを適用します。あるいは、共通の親フォルダを使用して同じ処理を行います。
- 個々のフォルダを使用して、環境の種類ごとに異なる IAM ポリシーと組織のポリシーを管理します。
テスト環境の管理にステージング組織を使用しないでください。テスト環境は、開発チームと DevOps チームの生産性にとって重要な環境です。このような環境をステージング環境で管理すると、ステージング組織でポリシーの変更をテストできなくなります。このような変更は、上記のチームの作業に支障をきたす可能性があります。つまり、ステージング組織を使用してテスト環境を管理すると、ステージング組織の目的が損なわれます。
テストに別の組織を使用する
Google Cloud を最大限に活用するには、開発チーム、DevOps チーム、運用チームがチュートリアルを行い、プラットフォームの使い方に慣れ、使いこなす必要があります。また、新機能やサービスを試すことも必要です。
このような実験的なアクティビティを行うには、サンドボックス環境として別の組織を使用します。別の組織を使用することで、本番環境の組織で使用しているポリシー、構成、自動化の制約を受けずに作業を行うことができます。
テストにはステージング組織を使用しないでください。ステージング環境では、本番環境の組織と同様の IAM ポリシーと組織のポリシーを使用する必要があります。そのため、ステージング環境に本番環境と同じ制限が適用される可能性があります。同時に、テストを許可するためにポリシーを緩和すると、ステージング組織の目的が損なわれます。
試験的に使用している組織の混乱や過剰なコストの発生を避け、セキュリティ リスクを回避するには、組織の使用方法と組織の管理責任者を定義したガイドラインを作成します。また、一定の日数が経過すると、リソースやプロジェクト全体が自動的に削除されるように自動化を設定することも検討してください。
次の図に示すように、試験運用版の組織を作成する場合は、まず専用の Cloud Identity アカウントを作成します。次に、メインの Cloud Identity アカウントまたは Google Workspace アカウントの既存のユーザーを使用して、試験運用版の組織へのアクセス権をユーザーに付与します。
追加の Cloud Identity アカウントを管理するには、Cloud Identity アカウントに少なくとも 1 つの特権管理者ユーザー アカウントが必要です。これらの特権管理者ユーザー アカウントを保護する方法については、特権管理者アカウントのベスト プラクティスをご覧ください。
ドメインで制限された共有を使用して信頼関係を適用する
IAM ポリシーを使用すると、有効な Google ID をメンバーとして追加できます。つまり、リソース、プロジェクト、フォルダ、組織の IAM ポリシーを編集するときに、次のようなソースからメンバーを追加できます。
- 組織が関連付けられている Cloud Identity アカウントまたは Google Workspace アカウントのユーザーと、同じ組織のサービス アカウント
- 他の Cloud Identity アカウントまたは Google Workspace アカウントのユーザー
- 他の組織のサービス アカウント
- 一般ユーザー向けのアカウント（
gmail.comユーザー、会社のメールアドレスを使用する一般ユーザー向けアカウントを含む）
さまざまなソースのユーザーを参照できると、アフィリエイトや他の企業とのコラボレーションが必要な場合に便利です。それ以外のほとんどの場合は、信頼できるソースのメンバーのみを許可するように IAM ポリシーを制限することをおすすめします。
ドメインで制限された共有を使用して、信頼できる一連の Cloud Identity アカウントまたは Google Workspace アカウントを定義します。そのアカウントからメンバーを IAM ポリシーに追加できるようになります。この組織ポリシーは、組織レベルで定義してすべてのプロジェクトに適用するか、リソース階層の最上部近くのフォルダで定義し、特定のプロジェクトを除外します。
ステージング環境、本番環境、試験運用環境を分離するために、個別の Cloud Identity アカウントまたは Google Workspace アカウントと組織を使用する場合は、次のテーブルに示すように、ドメインで制限された共有ポリシーを使用して、分離の適用を行います。
| 組織 | 信頼できる Cloud Identity アカウントまたは Google Workspace アカウント |
|---|---|
| ステージング | ステージング |
| 本番環境 | 本番環境 |
| テスト | 本番環境 |
組織に中立的なドメイン名を使用する
組織は、example.com などの DNS ドメイン名で識別されます。ドメイン名は、関連付けられた Cloud Identity アカウントまたは Google Workspace アカウントのプライマリ ドメイン名を元に作成されます。
会社全体で使用される正規 DNS ドメイン名がある場合は、そのドメインを本番環境の Cloud Identity アカウントまたは Google Workspace アカウントのプライマリ ドメインとして使用します。正規の DNS 名を使用することで、従業員が組織ノードの名前を簡単に認識できるようになります。
会社に複数の支社がある場合や、さまざまなブランドを所有している場合は、正規のドメイン名がない可能性があります。既存のドメインを勝手に選択するのではなく、Google Cloud 専用の新しい DNS ドメインを登録することを検討してください。中立的な DNS 名を使用することで、社内の特定のブランド、関連会社、部門を優先的に指定する必要がなくなりますが、クラウドの導入に悪影響が生じる可能性があります。他のブランド固有のドメインをセカンダリ ドメインとして追加し、ユーザー ID やシングル サインオンで使用できるようにします。
Google Cloud 組織全体の請求先アカウントを使用する
請求先アカウントは、特定の Google Cloud リソースセットの支払者を定義します。請求先アカウントは Google Cloud 組織の外部に存在することもありますが、通常は組織に関連付けられています。
請求先アカウントが組織に関連付けられている場合、対象アカウントは組織のサブリソースとみなされ、組織内で定義された IAM ポリシーが適用されます。最も重要な点は、Billing IAM のロールを使用して、アカウントの管理や使用を許可するユーザーまたはグループを定義できることです。
Billing Account User ロールが付与されたユーザーは、プロジェクトを請求先アカウントにリンクできます。これにより、リソースの使用料金がこのアカウントに請求されます。プロジェクトと請求先アカウントのリンクは、同じ組織内だけでなく、組織間でも機能します。
複数の組織を使用している場合は、請求先アカウントを組織全体で使用できるという利点があります。これにより、必要な組織の数に関係なく、必要な請求先アカウントの数を決めることができます。
適切な請求先アカウント数は、通貨、お支払いプロファイル、必要とする個別の請求書数など、業務上または契約上の要件によってのみ決定されます。アカウントや組織と同様に、複雑さを最小限に抑えるため、要件を満たす最も小さい数の請求先アカウントを使用します。
複数の組織で発生した費用の内訳を確認できるように、BigQuery に課金データをエクスポートするように請求先アカウントを構成します。BigQuery にエクスポートされた各レコードには、プロジェクト名と ID だけでなく、プロジェクトが関連付けられている組織の ID も含まれます（project.ancestry_numbers フィールドを参照）。
次のステップ
- 新しい Cloud Identity アカウントを作成する。
- Google Cloud でハイブリッド環境の企業ユーザーを認証する方法と一般的なパターンについて確認する。
- Google Cloud と外部 ID プロバイダの連携に関するベスト プラクティスを確認する。
- Active Directory と Google Cloud を連携させる方法または Azure Active Directory と連携させる方法を確認する。
- ID とアクセスを管理するためのベスト プラクティスを確認する。