リソース階層は、Google Cloud のリソースの整理に役立ちます。このドキュメントでは、ランディング ゾーン設計の一環としてリソース階層を選択する方法について説明します。このドキュメントは、リソース階層の設計に関与するクラウド システム管理者、アーキテクト、技術担当者を対象としています。このドキュメントは、ランディング ゾーンに関するシリーズの一部です。企業が Google Cloud でリソースを構造化するための一般的な方法を示すサンプル階層が記載されています。
リソース階層の設計要素
Google Cloud でリソース階層を定義する場合は、組織の現在の働き方と、クラウド トランスフォーメーションによる理想的な最終状態を検討する必要があります。リソースを管理する最善の方法は、組織が目標とするクラウドを利用した働き方によって異なります。組織ごとに異なるため、リソース階層に対する 1 つの最善のアプローチというものはありません。
ただし、企業の組織構造をリソース階層に対応付けないようにして、Google Cloud におけるビジネスニーズとオペレーションを重視することをおすすめします。
Google Cloud のリソース階層
Google Cloud のリソース階層は「組織」と呼ばれるルートノードから始まります。特定の状況を除き、ルートノードは 1 つだけ設定することをおすすめします。「フォルダ」と「プロジェクト」を使用して下位レベルを定義し、フォルダ内にフォルダを作成して階層を構築します。ワークロードをホストするプロジェクトは、階層の任意のレベルで作成できます。
次の図は、「Organization」という名前のルートノードと、レベル 1、2、3 のフォルダを示しています。プロジェクトとサブフォルダは、レベル 2 のフォルダ内に作成されます。
リソース階層の決定要因
リソース階層を決定する際は、次の要素を考慮してください。
- クラウド リソースの責任者は誰ですか。お客様の企業の部門、子会社、技術チーム、法人のいずれかですか。
- コンプライアンスのニーズは何ですか。
- 合併、買収、スピンオフなどのビジネス イベントが予定されていますか。
階層全体でのリソースのインタラクションを理解する
組織のポリシーはリソース階層の子孫に継承されますが、下位レベルに定義されたポリシーが優先される可能性があります。詳細については、階層評価についてをご覧ください。組織のポリシーの制約を使用して、組織全体または組織の大部分に関するガイドラインを設定する一方で、例外も許可します。
許可ポリシー（旧称 IAM ポリシー）は子孫に継承されます。下位レベルの許可ポリシーは付加的なものです。ただし、許可ポリシーより拒否ポリシーが優先されることがあります。拒否ポリシーは、プロジェクト、フォルダ、組織レベルで権限を制限できます。拒否ポリシーは許可ポリシーより先に適用されます。
次の点も考慮する必要があります。
- Cloud Logging には、フォルダレベルまたは組織レベルでログを集約するために使用できる集約シンクが含まれています。詳細については、Google Cloud ランディング ゾーンのセキュリティを決定するをご覧ください。
- 請求はリソース階層に直接リンクされませんが、プロジェクト レベルで割り当てられます。ただし、フォルダレベルで集計情報を取得するには、請求レポートを使用してプロジェクト階層ごとに費用を分析します。
- 階層型ファイアウォール ポリシーを使用すると、組織全体で、または特定のフォルダ内での一貫したファイアウォール ポリシーを実装できます。継承は暗黙的に行われます。つまり、任意のレベルでトラフィックを許可または拒否することも、その決定を下位レベルに委任することもできます。
リソース階層設計の決定事項
次のフローチャートは、組織に最適なリソース階層を選択するために考慮すべき事項を示しています。
上の図は、次の決定事項の概要を示しています。
- 子会社、リージョン グループ、ビジネス ユニットごとにポリシー要件が大きく異なりますか。
- 「はい」の場合、リージョンまたは子会社に基づく設計に従います。
- 「いいえ」の場合、次の決定事項に進みます。
ワークロード チームまたはプロダクト チームが、ポリシーに対する強力な自律性を必要としていますか。たとえば、すべてのワークロード チームやプロダクト チームのポリシーを決定する中央のセキュリティ チームが存在しない場合などです。
「はい」の場合、アカウンタビリティ フレームワークに基づく設計をご覧ください。
「いいえ」の場合、アプリケーション環境に基づく設計をご覧ください。
特定のユースケースでは、意思決定のグラフに示されているものとは異なるリソース階層の設計につながることがあります。ほとんどの組織はハイブリッド アプローチを採用し、ポリシーとアクセスに最も影響を与える設計から始めて、リソース階層のレベルごとにそれぞれ異なる設計を選択します。
オプション 1: アプリケーションの環境に基づく階層
多くの組織では、開発環境、本番環境、テスト環境など、アプリケーションの環境ごとに異なるポリシーとアクセス制御を定義します。環境ごとに標準化された個別のポリシーを使用すると、管理と構成が容易になります。たとえば、本番環境には、テスト環境よりも厳格なセキュリティ ポリシーを適用するなどです。
次の条件に該当する場合は、アプリケーションの環境に基づく階層を使用します。
- ポリシーと管理要件が異なる個別のアプリケーション環境がある。
- 一元化されたセキュリティ要件または監査要件があり、中央のセキュリティ チームがすべての本番環境ワークロードとデータに対してその要件を一貫して適用できなければならない。
- さまざまな環境内の Google Cloud リソースにアクセスするには、環境ごとに異なる Identity and Access Management（IAM）ロールが必要である。
次の条件に該当する場合は、この階層の使用を避ける必要があります。
- 複数のアプリケーション環境を運用していない。
- 環境間でアプリケーションの依存関係とビジネス プロセスが異なることがない。
- 異なるリージョン、チーム、またはアプリケーションのそれぞれに対するポリシーが大きく異なる。
次の図に、架空の金融工学企業 example.com の階層を示します。
上の図に示すように、example.com には 3 つのアプリケーション環境があり、環境ごとにポリシー、アクセス制御、規制要件、プロセスが異なります。これらの環境は次のとおりです。
開発環境と QA 環境: この環境は、社内の従業員とコンサルタントの両方のデベロッパーによって管理されます。こうしたデベロッパーは継続的にコードを push し、品質保証を担当します。ビジネス ユーザーは、この環境を利用できません。この環境には、本番環境ほど厳格ではないインテグレーションと認証の要件があり、デベロッパーには適切な権限が含まれる承認済みのロールが割り当てられます。開発環境と QA 環境は、example.com による標準のアプリケーション サービス専用に設計されています。
テスト環境: この環境は、回帰とアプリケーションのテストに使用され、example.com API を使用する example.com クライアントの企業間（B2B）サービスをサポートします。この目的のために、example.com は 2 つのタイプのプロジェクトを作成します。
- 内部テスト プロジェクト。B2B サービス向けの内部回帰、パフォーマンス、構成を行うためのプロジェクトです。
- マルチテナントをサポートするクライアント UAT プロジェクト。B2B クライアントが構成を検証し、ユーザー エクスペリエンス、ブランディング、ワークフロー、レポートなどを example.com の要件に合わせて調整するためのプロジェクトです。
本番環境: この環境は、検証され、承認されてリリースされたすべてのプロダクトをホストします。この環境は、Payment Card Industry Data Security Standard（PCI DSS）規制の対象であり、ハードウェア セキュリティ モジュール（HSM）を使用し、認証や支払いなどのためにサードパーティのプロセッサと統合されます。監査チームとコンプライアンス チームは、この環境の重要な関係者です。この環境へのアクセスは厳格に制御され、自動化されたデプロイ プロセスにほぼ限定されています。
アプリケーション環境に基づく階層の設計の詳細については、エンタープライズ基盤ブループリントに記載されている組織構造をご覧ください。
オプション 2: 地域または子会社に基づく階層
組織によっては、さまざまな地域にわたって事業を展開し、その子会社がそれぞれに異なる地域でビジネスを展開していたり、合併または買収されたりしています。こうした組織に必要となるリソース階層は、Google Cloud のスケーラビリティと管理オプションを使用し、地域や子会社の間に存在するさまざまなプロセスやポリシーの独立性を維持するものです。この階層では、子会社または地域がリソース階層の最上位のフォルダレベルとして使用されます。通常、デプロイ手順は地域を中心に行われます。
次の条件に該当する場合は、この階層を使用します。
- 複数の地域または子会社での運営がそれぞれ独立している。
- 地域や子会社に異なる運用バックボーン、デジタル プラットフォーム サービス、プロセスがある。
- 事業を運営する地域または子会社にさまざまな規制やコンプライアンス標準が適用される。
次の図は、2 つの子会社と持ち株グループを持つグローバル組織の地域に基づく構造の例を示しています。
上の図の階層構造は次のとおりです。
- 最初のレベルには、次のフォルダがあります。
Subsidiary 1フォルダとSubsidiary 2フォルダは、会社の 2 つの子会社を表し、組織の残りの部分とは異なるアクセス権限とポリシーが適用されます。各子会社は、IAM を使用してプロジェクトと Google Cloud リソースへのアクセスを制限します。Holding groupフォルダは、すべての地域にわたって最上位レベルのポリシーが共通しているグループを表します。Bootstrapフォルダは、エンタープライズ基盤ブループリントで説明されている Google Cloud インフラストラクチャのデプロイに必要な一般的なリソースを表します。
- 第 2 レベルのグループ保留フォルダには、次のフォルダがあります。
APAC、EMEA、Americasの各フォルダは、ガバナンス、アクセス権限、ポリシーが異なるグループ内のさまざまな地域を表します。Shared infrastructureフォルダは、すべての地域にわたって使用されるリソースを表します。
- 各フォルダ内には、子会社または地域で担当するリソースを格納する各種のプロジェクトが存在します。
社内の別の法人、部門、チームを区別するためのフォルダを追加できます。
オプション 3: アカウンタビリティ フレームワークに基づく階層
アカウンタビリティ フレームワークに基づく階層は、プロダクトが独立して運用される場合や、組織部門がプロダクトのライフサイクルを担当するチームを明確に定義している場合に最適です。このような組織では、プロダクトのオーナーがプロダクトのライフサイクル全体（プロセス、サポート、ポリシー、セキュリティ、アクセス権など）を担当します。プロダクトは互いに独立しており、組織全体のガイドラインと管理は共通していません。
次の条件に該当する場合は、この階層を使用します。
- 各プロダクトのオーナー権限とアカウンタビリティが明確にされている組織を運営している。
- ワークロードが独立しており、共有する共通ポリシーの数が多くない。
- プロセスと外部のデベロッパー プラットフォームは、サービスまたはプロダクトとして提供される。
次の図は、e コマース プラットフォーム プロバイダの階層の例を示しています。
上の図の階層構造は次のとおりです。
- 最初のレベルには、次のフォルダがあります。
Ecommerce ModulesとLogistics and Warehousing Modulesという名前のフォルダは、プロダクト ライフサイクル全体を通して同じアクセス権限とポリシーを必要とする、プラットフォームが提供するモジュールを表します。Reconciliation and Billingフォルダは、プラットフォーム パッケージ内の特定のビジネス コンポーネントのエンドツーエンド モジュールを担当するプロダクト チームを表します。Bootstrapフォルダは、エンタープライズ基盤ブループリントで説明されている Google Cloud インフラストラクチャのデプロイに必要な一般的なリソースを表します。
- 各フォルダ内には、さまざまなプロダクト チームが担当する独立したモジュールを格納した各種のプロジェクトが存在します。
詳細については、Fabric FAST Terraform フレームワークのリソース階層をご覧ください。
リソース階層のベスト プラクティス
以降のセクションで、Google がおすすめするリソース階層を設計する際のベスト プラクティスについて説明します。これらのベスト プラクティスは、どのリソース階層を選択するとしても適用されます。
Cloud Identity と Google Workspace のアカウントおよび組織の構成方法に関するその他のベスト プラクティスについては、アカウントと組織の計画に関するベスト プラクティスをご覧ください。
単一の組織ノードを使用する
管理上のオーバーヘッドを回避するために、可能な限り単一の組織ノードを使用します。ただし、次のユースケースに対応する場合は、複数の組織ノードの使用を検討してください。
- IAM レベルまたはリソース階層に対する大幅な変更をテストする。
- 同じ組織のポリシーが適用されないサンドボックス環境でテストする必要がある。
- 組織に、今後売り出されたり、完全に独立したエンティティとして運営されたりする可能性のあるサブ会社が含まれている。
標準化された命名規則を使用する
組織全体で標準化された命名規則を使用します。セキュリティ基盤のブループリントに、要件に合わせて調整できる命名規則のサンプルがあります。
ブートストラップ リソースと共通サービスを分離する
Infrastructure as Code（IaC）を使用して Google Cloud 環境のブートストラップ用のフォルダと、環境またはアプリケーションの間で共有される一般的なサービス用のフォルダを分離して維持します。ブートストラップ用のフォルダは、リソース階層の組織ノード直下に配置します。
選択した構造に応じて、階層のさまざまなレベルに共通サービス用のフォルダを配置します。
次の条件に該当する場合は、共通サービス用のフォルダを組織ノード直下に配置します。
- 階層で、最上位のアプリケーション環境と 2 番目のレイヤでチームまたはアプリケーションを使用する。
- 環境間で共通する、モニタリングなどの共有サービスがある。
次の条件に該当する場合は、共通サービス用のフォルダをアプリケーション フォルダの下位レベルに配置します。
アプリケーション間で共有されるサービスがあり、デプロイ環境ごとに個別のインスタンスをデプロイする。
複数のアプリケーションが、各デプロイ環境の開発とテストを必要とするマイクロサービスを共有している。
次の図は、すべての環境で使用される共有インフラストラクチャ フォルダと、階層の下位レベルに各アプリケーション環境の共有サービス用のフォルダがある階層の例を示しています。
上の図の階層構造は次のとおりです。
- 最初のレベルには、次のフォルダがあります。
Development environmentフォルダとProduction environmentフォルダにはアプリケーション環境が含まれています。Shared infrastructureフォルダには、環境をまたいで共有されるモニタリングなどの共通リソースが含まれています。Bootstrapフォルダには、エンタープライズ基盤ブループリントで説明されている Google Cloud インフラストラクチャのデプロイに必要な共通リソースが含まれています。
- 第 2 レベルには、次のフォルダがあります。
- 各アプリケーション（
App 1とApp 2）の環境ごとのフォルダ。このフォルダには、これらのアプリケーションのリソースが含まれています。 - 両方のアプリケーション環境用の
Sharedフォルダ。このフォルダには、アプリケーション間で共有されるものの、環境ごとに独立したサービスが含まれています。たとえば、フォルダレベルのシークレット プロジェクトがあるとしたら、本番環境のシークレットと非本番環境のシークレットに異なる許可ポリシーを適用できます。
- 各アプリケーション（
- 各アプリケーション フォルダ内には、各アプリケーションに含まれる独立したモジュールを格納する各種のプロジェクトが存在します。
次のステップ
- ランディング ゾーンのネットワークを設計する（このシリーズの次のドキュメント）。
- エンタープライズ基盤ブループリントを確認する。
- Google Cloud セキュリティ ベスト プラクティス センターで入手可能なブループリントとホワイトペーパーを読む。