はじめに
Google Cloudを構成する上で必要な組織やフォルダ・プロジェクトといったリソース階層の説明および、ランディングゾーンとして設計する際のリソース階層決定について記載できればと思います。
何か異なっている点などあればご指摘いただけると幸いです。
更新履歴
2024.03.10 新規作成
リソース階層の目的
リソース階層の目的は以下の2つです。公式ドキュメントを引用します。
- 所有権を階層的に編成し、リソースのライフサイクルを階層で直接の親にバインドする。
階層にすることで誰が所有者・責任者であるかがはっきりとわかるし、委任が可能なので手離れがいいことを示していると考えます。
- アクセス制御ポリシーと組織のポリシーの接続ポイントを提供し、継承を可能にする。
一番のメリットはこちらだと思います。
階層的にすることでその組織全体に必要なポリシーや分けた階層ごとに必要なポリシーを配下のリソースに確実に提供できるということを示していると考えます。
※実際続きの引用部分には以下のように記載されています。
Google Cloud のリソース階層は、エンティティを階層的に編成して管理している点では、従来のオペレーティング システムのファイル システムに類似しています。一般的に、各リソースの親は 1 つだけです。リソースを階層的に編成することで、親リソースにアクセス制御ポリシーと構成設定を割り当て、ポリシーと Identity and Access Management （IAM）設定を子リソースに継承できます。
リソース階層
リソース階層として、以下の4つのものがあります。
無料トライアル時は、プロジェクトリソースとサービスリソースしか作れません。
最上位リソースがプロジェクトリソースになります。
- 組織リソース(最上位リソース)
- フォルダリソース
- プロジェクトリソース
- サービスリソース(最下位リソース)：GCSやGCEなど
最上位のリソースを除いて、すべてのリソースの親は1つだけとなります。
最下位リソースはプロジェクトリソースを親として持ちますので、組織やフォルダがない構成も可能になりますし、最上位リソースをプロジェクトにしていても、別途組織リソースなどを作成して移行することも可能です。
一方で、Google WorkspaceやCloud Identityを使用していると、組織やフォルダリソースを作成することができ、各リソースの集中管理ができるようになります。
階層構造を完全に図示したものを公式から引用します。
リソースについて
組織リソース
1つのGoogle WorkspaceやCloud Identityに1つ作成可能なリソースで、組織や会社などを表し、Google Cloudリソース階層の唯一のルートとなります。
後から記載する、フォルダやプロジェクトリソースの大元にあたるリソースなので、IAMのアクセス制御ポリシーを配下のリソースすべてに継承させることができます。
組織リソースを作成しないと一部機能として使えないものがあります。
組織リソースを作成することにより、以下のメリットがあります。
- プロジェクトリソースが組織に属する
作成したプロジェクトが組織に属するため、個人で作成している場合にその人が退職してもプロジェクトが削除されず、組織のライフサイクルとして定めた方法に従うというメリットがあります。
※完全に個人のものであれば人事異動発生時に削除するといったことや、サービスを提供しているプロジェクトであれば権限をアカウントを削除して権限を剥奪するという対応を取ってプロジェクト自体は活かすといったことも可能です。 - 不正プロジェクトや管理者の抑制
組織管理者は作成されたすべてのプロジェクトが閲覧可能なため、隠れて作成しているプロジェクトがすべてわかります。
※通知の仕組みは必要です。 - 組織に付与したロールですべてのリソースのロール管理が可能
組織レベルで付与したロールはすべてのプロジェクト・フォルダに継承されるため、セキュリティ担当などにログを閲覧可能にする権限を与えるなどすれば、すべてのプロジェクトのログを見ることが可能になるといったことが可能になります。
フォルダリソース
プロジェクトリソースをグループ化し、プロジェクトを分離することができます。
フォルダごとに隔絶させることができるため、サブ組織として扱うことが可能になり、さらにそのフォルダに対して管理権限を委任することが可能です。
フォルダのネストは10個まで可能です。
意外と重要視されていないフォルダリソースではありますが、設計という意味合いでは、その組織の特性によって使い方が分かれてくるため、重要な要素となっています。
プロジェクトリソース
Google Cloudを使用するために欠かせない基本要素で、すべての Google Cloud サービスの作成、有効化、使用、API の管理、課金の有効化、共同編集者の追加と削除、権限の管理などに使うリソースです。
サービスリソース
Google Cloudの各サービス(Google Cloud StorageやBigQueryなど)を指します。
親がプロジェクトなので基本的にロールが継承されていますが、一部のサービスについては、プロジェクトレベルのものとは個別にロールを付与することが可能です。
例えば、Google Cloud Storage(GCS)のバケットに閲覧可能な人を制限するなどといったことです。
これにより1つのプロジェクト内で閲覧できないリソースを作成し、情報保護などの対策が取れるようになっています。
一部のサービスと付与可能なロールはこちらを参照ください。
また、一部のサービスについて個別にロールを付与できる対象は最下位レベルのリソースという記載がされています。
例) 2024.03.04時点のBigQuery Data Viewerのロール画像を以下に添付しますが、適用できる最下位レベルのリソース(Lowest-level resources)にテーブルとビューがあります。つまり、このロールはプロジェクトのほかにテーブルやビューに個別適用ができることを意味しています。
BigQuery Data Viewer
リソース階層の設計について
ここまででリソース階層および各リソースについて記載しましたが、Googleが提唱するランディングゾーンで、どういう基準で組織内の階層化を決定しているかについて記載できればと思います。
設計するにあたって必要な要素
Googleが提唱するランディングゾーンでは、リソース階層を設計するにあたって、現在の働き方を整理し、その働き方がクラウド利用した際にどのように変化するかを考慮することが必要と記載されています。
また、決定する要素として以下を挙げています。
- クラウドリソース責任者
お客様の企業の部門、子会社、技術チーム、法人のいずれか - コンプライアンスのニーズ
データのアクセスに当たって、厳密な権限管理や制御をしないといけないかなど - 合併、買収、スピンオフなどのビジネスイベントが予定されているか
組織自体が変化してしまうようなビジネス的なイベントがあるかなど
リソース階層決定フローチャート
前述した必要な要素を元に、以下のようなフローチャートに従ってリソース階層を決定していきます。
以下、各内容について記載します。
- 子会社、リージョングループ、ビジネスユニットごとにポリシー要件が大きく異なるか
ポリシー要件が大きく異なる場合(はいの場合)は、リージョンか子会社に基づくリソース階層を設計することになります。
別段大きく異ならない場合(いいえの場合)は次のNo.2に移行します。 - ワークロードチームまたはプロダクトチームが、ポリシーに対する強力な自律性を必要としているか。
書いてることが難しいですが、プロダクト毎に適用するポリシーレベルが異なっているかどうかと考えればわかりやすいかと思います。
ポリシーに対する強力な自律性を必要とする場合(はいの場合)は、アカウンタビリティフレームワークに基づく設計、ポリシーに対する強力な自律性が必要ない場合(いいえの場合)は、アプリケーション環境に基づく設計を設計することになります。
上記のフローを考慮しながら、各リソースレベルでどの階層設計をするかを決めていきます。
(どれかの設計のみというわけではなく、例えば組織直下のフォルダは「リージョンか子会社に基づくリソース階層設計」としてフォルダを分け、そのフォルダ配下でポリシーに対する強力な自律性が必要な部分な場合は、その部分を「アカウンタビリティフレームワークに基づいた設計」にするという風に、ハイブリッドに決めていいという意味です。)
以下は各階層がどのようなものになるのかを記載します。
アプリケーション環境に基づく階層
企業ではよくありますが、本番・開発・検証環境(場所によっては品証環境など)を作成し、運用している場合があります。
上記の場合だと、環境によって異なるポリシーがあるため異なる階層にまとめると維持管理しやすくなります。
フローチャートに若干記載がありますが、アプリケーション環境に基づく階層は以下のような条件に合致していると採用しやすいです。
(公式ドキュメントから引用します。)
- ポリシーと管理要件が異なる個別のアプリケーション環境がある
その環境が組織やフォルダのポリシーより厳しい場合、一緒のフォルダにしてしまうとほかのプロジェクトに影響が出ますので、そのアプリケーション専用の環境にしたほうがいいという理由です。
- 一元化されたセキュリティ要件または監査要件があり、中央のセキュリティチームがすべての本番環境ワークロードとデータに対してその要件を一貫して適用できなければならない。
業界特有のセキュリティ要件などがある場合は、その条件を満たしているかを監査されますので、それに対応するためにはアプリケーション専用の環境にしたほうがいいという理由です。
- さまざまな環境内の Google Cloud リソースにアクセスするには、環境ごとに異なる Identity and Access Management（IAM）ロールが必要である。
開発環境や検証環境、本番環境にアクセスする人が限られている場合はそれぞれフォルダ分け、プロジェクト分けをする必要があるため、そのアプリケーション専用の環境にしたほうがいいという理由です。
また、以下のような条件の場合は採用しないほうがいいです。
(これも公式ドキュメントから引用します。)
- 複数のアプリケーション環境を運用していない。
単一のアプリケーションの場合、そもそも階層にする必要がないという意味だと思われます。
ただ、将来的に考えて複数のアプリケーション環境を開発する可能性があるのであればこれには合致しないと考えられます。
- 環境間でアプリケーションの依存関係とビジネス プロセスが異なることがない。
これは単に一緒のポリシーでいいなら別段分ける必要がないのでは？という意味だと思われます。
- 異なるリージョン、チーム、またはアプリケーションのそれぞれに対するポリシーが大きく異なる。
これはEUやアメリカ、日本などで求めるポリシーが異なる場合はアプリケーション環境で分けると要件が合わないので、階層にできないという意味だと思われます。
以下、サンプルとして公式ドキュメントにある金融工学企業の例を引用します。
上の図を見ると、3つのアプリケーション環境があり、環境ごとにポリシー、アクセス制御、規制要件、プロセスが異なるようです。
(サンプルなので以下それぞれどのような要件になっているのか引用します。
難しい内容に見えますが、ポリシーやアクセス制御、規制要件などに着目すると3つの環境が異なっていることがわかります。)
- Development and QA environment folder(開発環境と QA 環境)
この環境は、社内の従業員とコンサルタントの両方のデベロッパーによって管理されます。こうしたデベロッパーは継続的にコードを push し、品質保証を担当します。ビジネス ユーザーは、この環境を利用できません。この環境には、本番環境ほど厳格ではないインテグレーションと認証の要件があり、デベロッパーには適切な権限が含まれる承認済みのロールが割り当てられます。開発環境と QA 環境は、example.com による標準のアプリケーション サービス専用に設計されています。
- Testing environment folder(テスト環境)
この環境は、回帰とアプリケーションのテストに使用され、example.com API を使用する example.com クライアントの企業間（B2B）サービスをサポートします。この目的のために、example.com は 2 つのタイプのプロジェクトを作成します。
- 内部テスト プロジェクト。B2B サービス向けの内部回帰、パフォーマンス、構成を行うためのプロジェクトです。
- マルチテナントをサポートするクライアント UAT プロジェクト。B2B クライアントが構成を検証し、ユーザー エクスペリエンス、ブランディング、ワークフロー、レポートなどを example.com の要件に合わせて調整するためのプロジェクトです。
- Production environment folder(本番環境)
この環境は、検証され、承認されてリリースされたすべてのプロダクトをホストします。この環境は、Payment Card Industry Data Security Standard（PCI DSS）規制の対象であり、ハードウェア セキュリティ モジュール（HSM）を使用し、認証や支払いなどのためにサードパーティのプロセッサと統合されます。監査チームとコンプライアンス チームは、この環境の重要な関係者です。この環境へのアクセスは厳格に制御され、自動化されたデプロイ プロセスにほぼ限定されています。
地域または子会社に基づく階層
グループ会社や親会社・子会社、はたまた買収・合併などしている場合、それぞれの会社ごとに異なるプロセスやポリシー、規制を持っているため、一つにまとめることはせず、フォルダによって分けると管理しやすくなります。
次の要件に合致すると、地域または子会社に基づく階層を採用しやすいです。
(公式引用しますが、上記に書いた内容とほぼ同様の内容です。)
- 複数の地域または子会社での運営がそれぞれ独立している。
- 地域や子会社に異なる運用バックボーン、デジタル プラットフォーム サービス、プロセスがある。
- 事業を運営する地域または子会社にさまざまな規制やコンプライアンス標準が適用される。
以下、サンプルとして公式ドキュメントにある2 つの子会社と持ち株グループを持つグローバル組織の地域に基づく構造の例を引用します。
上の図を見ると、持ち株グループ(Holding group)と2つの子会社(Subsidiary1とSubsidiary2)のフォルダ、ならびにBootstrapフォルダに分かれています。
それぞれのフォルダは次のような要件で分割されているようです(引用します。)。
最初のレベルのフォルダ
- Subsidiary 1 フォルダと Subsidiary 2 フォルダは、会社の 2 つの子会社を表し、組織の残りの部分とは異なるアクセス権限とポリシーが適用されます。各子会社は、IAM を使用してプロジェクトと Google Cloud リソースへのアクセスを制限します。
- Holding group フォルダは、すべての地域にわたって最上位レベルのポリシーが共通しているグループを表します。
- Bootstrap フォルダは、セキュリティ基盤のブループリントで説明されている Google Cloud インフラストラクチャのデプロイに必要な一般的なリソースを表します。
第2レベルのフォルダ
- APAC、EMEA、Americas の各フォルダは、ガバナンス、アクセス権限、ポリシーが異なるグループ内のさまざまな地域を表します。
- Shared infrastructure フォルダは、すべての地域にわたって使用されるリソースを表します。
全体を通して
- 各フォルダ内には、子会社または地域で担当するリソースを格納する各種のプロジェクトが存在します。
アカウンタビリティ フレームワークに基づく階層
サービスなどのプロダクトが独立して運用されていたり、組織において明確にプロダクトの担当チームを割り当てている場合にフォルダ分けしたほうが管理しやすくなります。
次の要件に合致すると、アカウンタビリティフレームワークに基づく階層を採用しやすくなります。
(公式引用しますが、上記に書いた内容とほぼ同様の内容です。)
- 各プロダクトのオーナー権限とアカウンタビリティが明確にされている組織を運営している。
- ワークロードが独立しており、共有する共通ポリシーの数が多くない。
- プロセスと外部のデベロッパー プラットフォームは、サービスまたはプロダクトとして提供される。
以下、サンプルとして公式ドキュメントにあるe コマース プラットフォーム プロバイダの例を引用します。
それぞれのフォルダは次のような要件で分割されているようです(引用します。)。
最初のレベルのフォルダ
- Ecommerce Modules と Logistics and Warehousing Modules という名前のフォルダは、プロダクト ライフサイクル全体を通して同じアクセス権限とポリシーを必要とする、プラットフォームが提供するモジュールを表します。
- Reconciliation and Billing フォルダは、プラットフォームが提供する特定のビジネス コンポーネントのエンドツーエンド モジュールを担当するプロダクト チームを表します。
- Bootstrap フォルダは、セキュリティ基盤のブループリントで説明されている Google Cloud インフラストラクチャのデプロイに必要な一般的なリソースを表します。
各フォルダ内には、さまざまなプロダクト チームが担当する独立したモジュールを格納した各種のプロジェクトが存在します。