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

このドキュメントでは、使用する Cloud Identity アカウントまたは G Suiteアカウント、Google Cloud 組織、請求先アカウントの数を決める際のベスト プラクティスについて説明します。このドキュメントでは、セキュリティと組織の要件を満たす設計を特定するためのガイダンスを示します。

Google Cloud では、ID とアクセスの管理は次の 2 つの要素に基づいています。

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

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

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

Cloud Identity アカウントと G Suite アカウント

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

Cloud Identity は G Suite の機能のサブセットを提供します。Cloud Identity では、G Suite と同様にユーザー、グループ、認証を管理できますが、G Suite のすべてのコラボレーション機能や生産性向上機能を使用できるわけではありません。

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

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

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

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

同様に、すでに Cloud Identity Free または Premium アカウントを管理している場合は、特定のユーザーに G Suite を使用する権限を付与できます。これらのユーザーに個別の G Suite アカウントを作成する代わりに、既存の Cloud Identity アカウントに G Suite を追加できます。選択したユーザーに G Suite ライセンスを割り当てると、そのユーザーは生産性向上アプリやコラボレーション アプリを使用できるようになります。

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

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

単一の Cloud Identity アカウントまたは G Suite アカウントを使用するメリットはありますが、複数のアカウントを使用すると、より柔軟な管理が可能になります。使用する Cloud Identity アカウントまたは G Suite アカウントの数を決める場合は、複数のアカウントを使用する場合の要件をすべて考慮する必要があります。そのうえで、必要最低限の数の Cloud Identity アカウントまたは G Suite アカウントを使用します。

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

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

他の設定とは異なり、Cloud Identity または G Suite アカウントと外部 ID プロバイダ(IdP)の統合の影響は全体に及びます。

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

こうしたリスクを軽減するには、ステージング用と本番環境用に別々の Cloud Identity アカウントまたは G Suite アカウントを用意します。

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

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

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

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

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

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

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

  • ステージング用の Cloud Identity または G Suite アカウントをステージング用の Azure Active Directory テナントに統合します。
  • 本番環境用の Cloud Identity アカウントまたは G Suite アカウントをメインの Azure Active Directory テナントに統合します。

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

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

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

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

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

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

G Suite と Google Cloud を分離しない

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

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

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

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

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

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

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

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

個別のアカウントを使用するよりも、G Suite 管理者と Google Cloud 管理者を分離して特権管理者の数を減らすほうが効果的です。

  • G Suite の管理作業で特権管理者権限が必要になることはほとんどありません。特権管理者権限の代わりに、事前定義の管理者ロールまたはカスタム管理者ロールを使用して、これらの管理作業に必要な権限を G Suite 管理者に付与します。

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

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

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

Cloud Identity と G Suite では、Active Directory、Azure Active Directory、Okta などの外部 IdP でシングル サインオンを設定できます。シングル サインオンが有効になっている場合、Cloud Identity と G Suite は Google の代わりにユーザー認証を行う外部 IdP を信頼します。

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

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

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

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

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

シングル サインオンがセキュリティ体制の弱点にならないように、IdP とそれに依存するすべてのシステムが安全に構成されている必要があります。

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

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

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

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

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

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

セキュリティ体制で DNS が弱点にならないようにするには、DNS サーバーが安全に構成されている必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

組織

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 会社が機能別に編成されている場合、1 つの部門で Google Cloud のすべてのデプロイを担当していることがあります。
  • 会社が部門別に組織されている場合や、複数の子会社を所有している場合は、1 つの部門で担当していないこともあります。

1 つの部門で Google Cloud のデプロイを管理している場合は、1 つの Google Cloud 組織ノードを使用することをおすすめします。組織内で、フォルダを使用してリソースを構成し、他のチームや部門にさまざまなレベルのアクセス権を付与します。

複数の独立した部門を扱う場合、1 つの組織で管理を一元化しようとすると、問題が発生する可能性があります。

  • 組織を管理する部門を 1 つに限定すると、他の部門からクレームを受ける可能性があります。
  • 複数のチームや部門が 1 つの組織を共有して所有すると、リソース階層の一貫性を維持するのが困難になり、リソース全体で一貫した Cloud IAM ポリシーと組織ポリシーを適用できなくなる可能性があります。

このような問題を回避するには、複数の組織を使用して、組織ごとに個別のフォルダ構造を作成します。別々の組織を使用することで、管理ユーザーのグループ間に境界を設定し、管理権限を明確にします。

別のステージング組織を使用する

整合性を維持しながら、同じ構成作業を繰り返さないようにするには、プロジェクトをフォルダに整理し、フォルダまたは組織レベルで IAM ポリシーと組織ポリシーを適用します。

多くのプロジェクトやリソースにポリシーを適用することにはデメリットがあります。ポリシー自体またはポリシーが適用されるリソース階層が変更されると、広範囲にわたり意図しない結果が生じる可能性があります。こうしたリスクを回避するため、メインの組織に適用する前に、ポリシーの変更をテストすることをおすすめします。

別のステージング組織を作成することをおすすめします。この組織では、アクセスレベルポリシーなど、組織全体に影響を及ぼす可能性のあるリソース階層の変更、IAM ポリシー、組織ポリシー、その他の構成をテストできます。

ステージング組織で行ったテストまたはテスト結果が本番環境の組織にも反映されるように、メインの組織と同じフォルダ構造にします。ステージング組織の IAM ポリシーと組織ポリシーは、本番環境の組織ポリシーと一致するか、本番環境の組織に適用する次のバージョンのポリシーを反映している必要があります。

次の図に示すように、ステージング用の Cloud Identity アカウントまたは G Suite アカウントをステージング組織のベースとして使用します。ステージング アカウント(またはステージング アカウントが統合されている外部 IdP)を使用して、専用のテストユーザーを作成し、本番環境の Cloud Identity アカウントまたは G Suite アカウントで使用するものと同じグループ構造を作成します。これらの専用のテストユーザーとグループを使用することで、既存のユーザーに影響を与えることなく、IAM ポリシーをテストできます。

アカウントをステージングのベースとして使用する。

別のテスト組織を使用しない

Google Cloud にデプロイする本番環境のワークロードごとに複数のテスト環境が必要になります。たとえば、開発チームと DevOps チームが新しいリリースの検証に使用できるテスト環境が必要になります。

セキュリティの観点から、テストされていないリリースが本番環境のワークロードに誤って影響しないように、テスト環境を本番環境から明確に分離する必要があります。同様に、この 2 つの環境では IAM ポリシーの要件も異なります。たとえば、デベロッパーやテスターに必要な柔軟性を付与するために、テスト環境のセキュリティ要件を本番環境よりも大幅に緩和できます。

次の図に示すように、構成上はテスト環境をできるだけ本番環境に近いものにする必要があります。相違があると、テスト環境で正常に動作したデプロイが本番環境で失敗するリスクが高くなります。

本番環境に類似したテスト環境を用意する。

環境を分離しながら一貫性を保つには、同じ組織内のフォルダを使用して、テスト環境と本番環境を管理します。

  • 組織レベルで共通の IAM ポリシーまたは組織ポリシーを適用します。あるいは、共通の親フォルダを使用して同じ処理を行います。
  • 個々のフォルダを使用して、環境の種類ごとに異なる IAM ポリシーと組織のポリシーを管理します。

テスト環境の管理にステージング組織を使用しないでください。テスト環境は、開発チームと DevOps チームの生産性にとって重要な環境です。このような環境をステージング環境で管理すると、ステージング組織でポリシーの変更をテストできなくなります。このような変更は、上記のチームの作業に支障をきたす可能性があります。つまり、ステージング組織を使用してテスト環境を管理すると、ステージング組織の目的が損なわれます。

テストに別の組織を使用する

Google Cloud を最大限に活用するには、開発チーム、DevOps チーム、運用チームがチュートリアルを行い、プラットフォームの使い方に慣れ、使いこなす必要があります。また、新機能やサービスを試すことも必要です。

このような実験的なアクティビティを行うには、サンドボックス環境として別の組織を使用します。別の組織を使用することで、本番環境の組織で使用しているポリシー、構成、自動化の制約を受けずに作業を行うことができます。

テストにはステージング組織を使用しないでください。ステージング環境では、本番環境の組織と同様の IAM ポリシーと組織のポリシーを使用する必要があります。そのため、ステージング環境に本番環境と同じ制限が適用される可能性があります。同時に、テストを許可するためにポリシーを緩和すると、ステージング組織の目的が損なわれます。

試験的に使用している組織の混乱や過剰なコストの発生を避け、セキュリティ リスクを回避するには、組織の使用方法と組織の管理責任者を定義したガイドラインを作成します。また、一定の日数が経過すると、リソースやプロジェクト全体が自動的に削除されるように自動化を設定することも検討してください。

次の図に示すように、テスト用の組織を作成する場合は、まず専用の Cloud Identity アカウントを作成します。次に、メインの Cloud Identity アカウントまたは G Suite アカウントの既存のユーザーを使用して、ユーザーに試験運用版の組織へのアクセスを許可します。

試験運用版の組織。

追加の Cloud Identity アカウントを管理するには、Cloud Identity アカウントに少なくとも 1 つの特権管理者ユーザー アカウントが必要です。これらの特権管理者ユーザー アカウントを保護する方法については、特権管理者アカウントのベスト プラクティスをご覧ください。

ドメインで制限された共有を使用して信頼関係を適用する

IAM ポリシーを使用すると、有効な Google ID をメンバーとして追加できます。つまり、リソース、プロジェクト、フォルダ、組織の IAM ポリシーを編集するときに、次のようなソースからメンバーを追加できます。

  • 組織が関連付けられている Cloud Identity アカウントまたは G Suite アカウントのユーザーと、同じ組織のサービス アカウント
  • 他の Cloud Identity アカウントまたは G Suite アカウントのユーザー
  • 他の組織のサービス アカウント
  • 一般ユーザー向けのアカウント(gmail.com ユーザー、会社のメールアドレスを使用する一般ユーザー向けアカウントを含む)

さまざまなソースのユーザーを参照できると、アフィリエイトや他の企業とのコラボレーションが必要な場合に便利です。それ以外のほとんどの場合は、信頼できるソースのメンバーのみを許可するように IAM ポリシーを制限することをおすすめします。

ドメインで制限された共有を使用して、信頼できる一連の Cloud Identity アカウントまたは G Suite アカウントを定義し、IAM ポリシーへのメンバーの追加を許可します。この組織ポリシーは、組織レベルで定義してすべてのプロジェクトに適用するか、リソース階層の最上部近くのフォルダで定義し、特定のプロジェクトを除外します。

ステージング環境、本番環境、テスト環境を分離するために個別の Cloud Identity アカウントまたは G Suite アカウントと組織を使用する場合は、次の表のように、ドメインで制限された共有ポリシーを適用します。

組織 信頼できる Cloud Identity アカウントまたは G Suite アカウント
ステージング ステージング
本番環境 本番環境
テスト 本番環境

組織に中立的なドメイン名を使用する

組織は、example.com などの DNS ドメイン名で識別されます。ドメイン名は、関連付けられた Cloud Identity または G Suite のアカウントのプライマリ ドメイン名から取得されます。

会社全体で使用される正規の DNS ドメイン名がある場合は、そのドメインを本番環境の Cloud Identity または G Suite のアカウントのプライマリ ドメインとして使用します。正規の DNS 名を使用することで、従業員が組織ノードの名前を簡単に認識できるようになります。

会社に複数の支社がある場合や、さまざまなブランドを所有している場合は、正規のドメイン名がない可能性があります。既存のドメインを勝手に選択するのではなく、Google Cloud 専用の新しい DNS ドメインを登録することを検討してください。中立的な DNS 名を使用することで、社内の特定のブランド、関連会社、部門を優先的に指定する必要がなくなりますが、クラウドの導入に悪影響が生じる可能性があります。他のブランド固有のドメインをセカンダリ ドメインとして追加し、ユーザー ID やシングル サインオンで使用できるようにします。

Google Cloud 組織全体の請求先アカウントを使用する

請求先アカウントは、特定の Google Cloud リソースセットの支払者を定義します。請求先アカウントは Google Cloud 組織の外部に存在することもありますが、通常は組織に関連付けられています。

請求先アカウントが組織に関連付けられている場合、そのアカウントは組織のサブリソースと見なされ、組織内で定義された IAM ポリシーが適用されます。最も重要な点は、Billing Cloud IAM のロールを使用して、アカウントの管理や使用を許可するユーザーまたはグループを定義できることです。

Billing Account User ロールが付与されたユーザーは、プロジェクトを請求先アカウントにリンクできます。これにより、リソースの使用料金がこのアカウントに請求されます。プロジェクトと請求先アカウントのリンクは、同じ組織内だけでなく、組織間でも機能します。

複数の組織を使用している場合は、請求先アカウントを組織全体で使用できるという利点があります。これにより、必要な組織の数に関係なく、必要な請求先アカウントの数を決めることができます。

請求先アカウントに適切な数は、通貨、お支払いプロファイル、必要な請求書の数など、業務上または契約上の要件によって決まります。アカウントや組織と同様に、複雑さを最小限に抑えるため、要件を満たす最も小さい数の請求先アカウントを使用します。

複数の組織で発生した費用の内訳を確認できるように、BigQuery に課金データをエクスポートするように請求先アカウントを構成します。BigQuery にエクスポートされた各レコードには、プロジェクト名と ID だけでなく、プロジェクトが関連付けられている組織の ID も含まれます(project.ancestry_numbers フィールドを参照)。

次のステップ