G-gen の杉村です。Google Cloud（旧称 GCP）には組織（Organization）という概念があります。ガバナンスとセキュリティのために重要なこの機能を解説します。

組織の基本
組織のメリットとユースケース
組織の作成
組織の表示
- 階層構造（ツリー）の表示
- 表示に必要な権限
組織の管理
監査
構成情報管理
組織のポリシー
詳細な管理
関連する Google Cloud サービス
ベストプラクティス

組織の基本

組織（Organization）とは

Google Cloud の組織（Organization）とは、Google Cloud リソースの集中管理と整理のための仕組みです。Google Cloud プロジェクトを始めとする Google Cloud リソースは組織に所属して、管理下に入ることができます。

組織は、Google Workspace（Cloud Identity）のドメインと1:1で紐付きます。example.com という Google Workspace ドメインがある場合、そこには Google Cloud 組織 example.com が作成できます。

参考 : 組織リソース

リソースの階層構造

Google Cloud において、Compute Engine の VM（仮想サーバ）や BigQuery のテーブルなど、1つ1つのオブジェクトはリソースと呼ばれます。

そして、全てのリソースは階層構造を取ります。つまり、リソースには親子関係があり、リソース同士の関係はツリー構造で表現することができます。

ツリーの頂点には組織リソースがあり、このツリーにリソースが所属している状態を「このプロジェクトは組織 my-domain.com に所属する」のように表現します。

参考 : リソース階層

組織リソース

組織自体も1つのリソースです。ツリーのトップレベルノード（最上位の節）が組織リソースであり、前掲の図で言うと、最上位にある my-domain.com が組織リソースです。組織リソースは、組織ノード、あるいはルートノードともいいます。

組織自体がリソースであるため、組織は IAM 許可ポリシーを持つことができます。また、組織に対して CRUD（Create、Read、Update、Delete）操作をする API が存在します。

参考 : Google CloudのIAMを徹底解説！ - G-gen Tech Blog - IAM ポリシーの構造

なお、組織リソースを操作する Google Cloud API は Resource Manager API（cloudresourcemanager.googleapis.com）です。

組織 ID（顧客 ID）

組織はドメイン名の他に10桁〜13桁程度の数字で表現される、一意の組織 ID を持ちます。また Google Workspace（Cloud Identity）ドメインと共通の顧客 ID（お客様 ID）も存在します。

ID は、後述の「組織のポリシー」機能を使う際や、gcloud CLI などで組織リソースを対象とした操作を行うときに必要です。これらの ID を調べる方法については、以下の記事を参照してください。

blog.g-gen.co.jp

フォルダ、プロジェクト

リソース階層を構成する要素としてフォルダとプロジェクトがあります。

フォルダは、下位のフォルダやプロジェクトをグルーピングするためのリソースです。

プロジェクトは、ほとんどの Google Cloud リソースが所属する最も基本的な管理単位です。Google Cloud におけるプロジェクトは、Amazon Web Services（AWS）でいうところの「AWS アカウント」や Microsoft Azure でいうところの「サブスクリプション」と似ています。BigQuery テーブルや Compute Engine の VM など、ほとんどの Google Cloud リソースは1つのプロジェクトに所属します。

フォルダやプロジェクトも IAM 許可ポリシーを持っているので、権限管理の単位として使うことができます。また請求先アカウントのレポートでは、組織単位、フォルダ単位、プロジェクト単位で請求を分類することができるので、請求の管理単位としても利用できます。

フォルダやプロジェクトも、Resource Manager API のリソースです。

組織のメリットとユースケース

組織を使う理由

Google Cloud は組織なしでも利用することが可能です。

無料の Google アカウント（Gmail アカウント）で Google Cloud プロジェクトを作成すると、そのプロジェクトは組織に所属せず「組織なし」となります。この状態でも Compute Engine や BigQuery といった Google Cloud サービスは利用できます。

ただし、ほとんどの企業や官公庁では、組織機能を使うべきと言えます。以下にそのいくつかの理由と、逆に組織を使わない場合のリスクを解説します。

複数プロジェクトの管理

組織を使うメリットは、複数プロジェクトを利用するときに出てきます。

企業や官公庁において、複数のシステムを Google Cloud で開発・運用する際、それぞれのシステムを異なる部署やチームで管理し、またチームごとに異なる権限を付与したい場合があります。

組織機能を使って複数プロジェクトを組織下に束ねることにより、組織のポリシーや IAM、VPC Service Controls などで継承の性質を利用したセキュリティ・統制の管理ができるようになります。

継承（inheritance）とは、ここではリソースツリーの親から子へ、IAM 権限や組織ポリシーの設定が引き継がれることを指します。これによって、組織の管理者は、多数存在するプロジェクトなどの Google Cloud リソースに1つ1つ設定を施していく運用オーバヘッドを節約することができます。工数を削減することで、効果的に、また現実的な工数でガバナンスを実現できるようになります。

利用可能なサービス・機能

後述の組織のポリシー機能をはじめ、重要なセキュリティ機能の多くでは、組織を有効化していることが利用条件となっています。以下は、その例です。

フォルダ
グループでの IAM 管理
組織のポリシー
VPC Service Controls
Security Command Center
ログの集約（ログルーティング）

上記のような機能については、以下の当社記事でも解説していますので、参考にしてください。

組織を使わないリスク

逆に組織を利用しない場合、個別のプロジェクトに対して権限管理や統制を行う必要があるため、運用工数が大きくなります。また、Google Workspace や Cloud Identity で利用可能な Google アカウントの集約管理やグループ機能も使えないため、組織内で誰がどのように Google Cloud や Google サービスを使っているのか、把握する術がありません。

また企業や官公庁内で、いわゆる「野良プロジェクト」の存在を許すことになり、意図しないセキュリティ事故のリスクが高まります。

企業で Google Cloud を利用する場合は、たとえ最初は Google Cloud プロジェクトを1つしか使わない場合でも、将来の拡張性も見込んで最初から組織を作成しておき、組織下でプロジェクトを管理することが望ましいと言えます。

組織の作成

Google Workspace と Cloud Identity

Google Cloud 組織は、Google Workspace または Cloud Identity の組織（ドメイン）と必ず1:1になります。そのため、Google Cloud 組織を作成するには Google Workspace（Cloud Identity）ドメインを作成します。

Google Workspace とは、Google 製のグループウェアツールです。ディレクトリ管理機能（アカウントやグループ、組織部門の管理機能）と、Gmail や Google ドライブなどのグループウェア機能を持ちます。

Cloud Identity とは、Google Workspace と同等のディレクトリ管理機能を持つサービスです。Cloud Identity は Google Workspace と同じようにアカウントやグループの管理が可能ですが、Gmail などのグループウェア機能がありません。Cloud Identity には Free と Premium の2エディションがあり、Premium ではセキュリティ関連の機能がより強化されています。

Google Cloud の視点からは、Google Workspace と Cloud Identity のどちらを使っても、機能の差はありません。すでに Microsoft 365 などのグループウェアツールを導入済みの組織が Google アカウントを集約管理したい場合に、Cloud Identity が採用されることがあります。

なお、他のクラウドを例に取ると、Amazon Web Services（AWS）ではクラウドリソースとして IAM ユーザーを作成します。一方で Google Cloud には、クラウドリソースとしての IAM ユーザーは存在しません。Google Workspace で管理される Google アカウントが、Google Cloud 管理・利用のためのアカウントとなります。つまり、アカウントは Google Cloud の外で管理されます。

参考 : Google CloudのIAMを徹底解説！ - G-gen Tech Blog - AWS IAM との比較と連携

組織の作成方法

Google Cloud 組織を作成するには、まず Google Workspace または Cloud Identity の組織（テナント）を作成します。

Web の利用申込み画面から組織の情報やドメイン名などを記入し、発行された TXT もしくは CNAME レコードをそのドメイン名を管理する DNS に追加してドメインを認証することで、利用開始できます。

ある Google Workspace（Cloud Identity）組織の Google アカウントで初めて Google Cloud コンソールにログインした際に、表示される利用規約に同意すると、そのタイミングで Google Cloud 組織が自動的に作成されます。

Cloud Identity の組織作成の方法は、以下の記事をご参照ください。

blog.g-gen.co.jp

組織作成直後の特権

Google Workspace（Cloud Identity）の管理者権限と、Google Cloud の管理者権限は、それぞれ別々のものです。

Google Workspace（Cloud Identity）には「特権管理者」「グループ管理者」「ユーザー管理者」などの管理者ロールがあり、Google アカウントにロールをアサインできます。

一方で Google Cloud では、Identity and Access Management（IAM）の仕組みで、リソースベースで権限管理します。

Google Workspace（Cloud Identity）の権限管理と Google Cloud の権限管理は、本来は完全に別ものであり、管理体系も異なっていますが、「特権管理者」だけは関連があります。Google Workspace（Cloud Identity）の特権管理者ロールを持つアカウントは、Google Cloud 組織に対しても、組織の管理者（roles/resourcemanager.organizationAdmin）ロールと同等の権限を持ちます。これは暗黙的な権限であり、Google Cloud 組織の IAM 許可ポリシーの一覧画面には表示されません。組織作成直後には、一部のアカウントのみ、このロールバインディングが表示されていることがあります。しかし、このロールバインディングを Google Cloud 側で削除しても、暗黙的な権限はなくなりません。

Google Workspace の特権管理者は Google Cloud の組織の管理者と同等

運用体制として、Google Workspace（Cloud Identity）の管理体制と、Google Cloud の管理体制が別である場合は、Google Cloud 組織を作成した直後に Google Workspace（Cloud Identity）の特権管理者アカウントを使って、Google Cloud を管理する担当者の Google アカウントやグループに対して、Google Cloud 組織レベルで組織の管理者ロール等を付与することで、Google Cloud 環境の管理を委任することが推奨されています。

参考 : 組織リソースを作成、管理する
参考 : 特権管理者アカウントのベストプラクティス

組織の表示

階層構造（ツリー）の表示

Google Cloud コンソールでリソースの管理（Manage resources）という画面に遷移すると、組織階層がツリー形式で表示されます。

Google Cloud コンソールにログインし、IAM と管理 の画面の左部メニューから リソースの管理 をクリックするか、Google Cloud コンソール上部の検索ボックスに Manage Resources と入力することで、この画面に遷移できます。

この画面を使う方法以外にも、gcloud コマンドや REST API 等で組織情報を取得することが可能です。

表示に必要な権限

組織とその配下のフォルダやプロジェクトを全て表示するには、組織・フォルダ・プロジェクトに対する get list 権限が必要です。

組織のトップノードに対して、Google アカウントが参照者（roles/browser）ロールや組織の管理者（roles/resourcemanager.organizationAdmin）ロールを持っていれば、組織とその配下の全てのフォルダやプロジェクトを閲覧することができます。

参照者ロールや組織の管理者ロールは、組織・フォルダ・プロジェクトのツリー構造を見られる権限はありますが、プロジェクト内のリソース（Compute Engine VM や BigQuery テーブル等）を見る権限は持っていません。これにより、クラウド環境の全体管理をするチームと、実際の開発・構築を行うチームの権限を分けることができます。

一方で、基本ロールである閲覧者（roles/viewer）ロールやオーナー（roles/owner）は、組織やフォルダに対する get・list 権限を持っていません。組織トップノードにこれらのロールを付与しても、「組織なし（No organization）」としてプロジェクトが平坦に一覧表示されます。これらのロールには、プロジェクトに対する get・list 権限を持つためプロジェクトの情報は得られるのですが、組織やフォルダの情報は得られないためです。

つまり、閲覧者ロールやオーナーロールはあくまでプロジェクトの中を管理するためのロールであり、組織構成を閲覧したり、管理することはできない点に注意しましょう。

参考 : 階層内のすべてのリソースの一覧表示
参考 : IAM basic and predefined roles reference
参考 : IAM permissions reference

組織の管理

組織の管理者ロール

組織の管理に必要な IAM 権限の考え方についても解説します。

管理担当者の Google アカウントに対して、組織のトップノードレベルで、組織の管理者（roles/resourcemanager.organizationAdmin）ロールを付与することで、以下のような管理タスクを実行することができます。

組織ツリー全体の表示
組織トップノードの IAM ポリシーの編集
組織配下の全フォルダの IAM ポリシーの編集
組織配下の全プロジェクトの IAM ポリシーの編集

組織の管理者ロールは「何でもできる権限」を持っているわけではありませんが、組織と配下の全フォルダ・全プロジェクトの IAM を編集できることから、自分に対して「どんな権限でも付与できる」ことになります。よって実質的に、最も強い権限を持っていると言えます。

強力な管理権限

組織の管理者ロールは、フォルダの作成・削除などは行えません。それが行えるのはフォルダ管理者（roles/resourcemanager.folderAdmin）等です。またプロジェクトの作成には、プロジェクト作成者（roles/resourcemanager.projectCreator）が必要ですし、組織のポリシーの管理には組織ポリシー管理者（roles/orgpolicy.policyAdmin）が必要です。

ある Google アカウントが、以下のロールを組織トップノードレベルで持っていれば、その Google アカウントは組織全体でほとんどの管理・構築タスクを行うことができます。

フォルダ管理者（roles/resourcemanager.folderAdmin）
プロジェクト作成者（roles/resourcemanager.projectCreator）
組織の管理者（roles/resourcemanager.organizationAdmin）
組織ポリシー管理者（roles/orgpolicy.policyAdmin）

実際には最小権限の原則に従い最小限のロールのみを付与することが望ましいですが、常にクラウド環境全体を管理するような管理者の場合は、上記のようなロールを持つことを検討します。

ただし、上記ロールにはプロジェクトの中のリソース（VM や BigQuery データセット等）を操作する権限は入っていません。それらを行うには、プロジェクトレベルでオーナー（roles/owner）ロールや、サービスごとの事前定義ロールを持つ必要があります。

管理の委任

システム単位の管理者や部署のクラウド管理者に対して、フォルダレベルで IAM ロールを付与することで、管理を委任することができます。

例えばフォルダ system-a 以下は john@my-domain.com に管理を委任し、フォルダ system-b 以下は mary@my-domain.com に管理を委任する、という場合は、それぞれのフォルダレベルでそれぞれの担当者に対して フォルダ管理者 ロールを付与することで管理を委任できます。

フォルダ管理者ロールは、フォルダレベルの IAM ポリシーの編集に加え、そのフォルダ配下のプロジェクトの IAM 権限を編集することができます。

また、プロジェクト単位で管理を委任することも可能です。その場合はプロジェクトレベルでオーナーロールを付与することなどで実現できます。

どのロールにどのような権限があるかは、以下のドキュメントで確かめることができます。

監査

組織と監査ログ（Cloud Audit Logs）

Google Cloud の API 実行履歴は Cloud Audit Logs で収集されます。Cloud Audit Logs の詳細は以下の記事をご参照ください。

blog.g-gen.co.jp

Cloud Audit Logs はデフォルトで有効であり、管理アクティビティ監査ログ（Admin Activity audit logs）と呼ばれる変更系オペレーションは、必ず記録されるようになっています。

しかし、データアクセス監査ログ（Data Access audit logs）と呼ばれる参照系オペレーションを含むすべての API 履歴を残すためには、明示的に設定する必要があります。

この明示的な設定も、組織内で親リソースから子リソースに継承されます。そのため組織トップノードでデータアクセス監査ログを有効化することで、組織内の全てのプロジェクトで有効化できます。

参考 : データアクセス監査ログを有効にする - デフォルト構成を設定する

監査ログの収集

ログの生成自体は、前述のデフォルト構成の設定で実施できますが、デフォルtおではログの保管先はそれぞれのプロジェクト、フォルダ、組織レベルのログバケット（_Default や _Required）です。

ログルーティング（シンク）の仕組みを利用すると、監査ログなどをログ集約用のプロジェクトに集約し、社内のルールや監査基準に沿ったログの保持や、必要なときのエクスポートを行うことができます。

組織（Resource Manager）自体の監査ログ

組織リソースを管理するための API である Resource Manager API 自体のログも、Cloud Audit Logs に保存されます。

この監査ログには、フォルダやプロジェクト、組織ポリシーなどの作成、削除、変更が記録されます。

参考 : Resource Manager の監査ロギングの情報
参考 : 組織のポリシーの監査ロギング情報

構成情報管理

Google Cloud 組織やプロジェクトのリソース構成情報は、Cloud Asset Inventory というサービスに記録されます。

詳細は、以下の記事を参照してください。

blog.g-gen.co.jp

組織のポリシー

組織のポリシー（Organization Policy）機能では、組織で管理されたプロジェクトに対してルールを課し、統制を効かせることができます。組織のポリシーは、組織を使うにあたって最も基本的なセキュリティ機能です。一般的に、このようなルールを、セキュリティガードレイルと呼ぶこともあります。

例として、以下のような組織のポリシーの制約があります。

Cloud Storage で公開アクセスを禁止する
利用可能な Google Cloud サービスを制限する
リソースを作成できるリージョンを制限する

組織のポリシーはリソース階層の上から下へ継承されていくため、フォルダを適切に分けることによって、システムごとに適用するポリシーを変えることができます。

組織のポリシーについては以下の記事で詳細に解説しています。

blog.g-gen.co.jp

詳細な管理

タグ（tags）

Google Cloud にはタグという仕組みがあります。タグは Key-Value の文字列であり、それ自体が Google Cloud リソースです。IAM の条件（Condition）として利用可能であり、親リソースから子リソースへ継承されます。

タグをうまく使うことで、権限が及ぶ範囲をコントロールすることができます。

よく似た概念で「ラベル」という概念もありますが、タグとラベルは全くの別ものです。

タグの詳細は、以下の記事もご参照ください。

blog.g-gen.co.jp

プロジェクトの移動

Google Cloud プロジェクトは、組織直下からフォルダ内へ、あるいはあるフォルダから別のフォルダへと、移動することができます。移動を行う際は、継承の性質を持つ IAM や組織ポリシーなどの影響範囲が変わることに注意が必要です。設定の継承元が変わるため、予期せぬ結果を生まないよう確認しましょう。

また、プロジェクトは「組織なし」から組織に所属させたり、ある組織から違う組織に移動することもできます。

ただし、組織間でプロジェクトを移行する場合、さまざまな考慮事項があります。以下に代表的なもののみを記載します。

上位リソースから継承される IAM 権限は移行されない
プロジェクトに紐づくサポートケースが閲覧できなくなる（サポートケースを移行するには、Google サポートに連絡してメタデータ移行を依頼する必要がある）
VPC Service Controls 境界にプロジェクトが入っている場合、移行ができない（移行するには、プロジェクトを境界の保護から外す必要がある）

より詳細なリストは、以下をご参照ください。

参考 : 特殊なケースを処理する

プロジェクトの組織間移動の手順等は、以下のドキュメントをご参照ください。

参考 : 組織リソース間のプロジェクトの移行

通知の連絡先

エッセンシャルコンタクト

Google Cloud から「料金改定」「サービス仕様」「法令に関連する通達」「セキュリティ関連通知」など重要なお知らせが通知される場合があります。

こういったお知らせの通知先メールアドレスは、エッセンシャルコンタクトという仕組みで指定することができます。

なお、エッセンシャルコンタクトで明示的に通知先を指定しない場合、お知らせは所定の IAM ロールを付与されている Google アカウントのメールアドレスに通知されます。

例えば課金に関するお知らせや法令遵守に関するお知らせは請求先アカウント管理者（roles/billing.admin）ロールを持つ Google アカウントに通知され、Google プロダクトの変更点に関するお知らせはオーナー（roles/owner）ロールを持つアカウントに届きます。

通知カテゴリとロールのデフォルトの対応表は、以下のドキュメントをご参照ください。

参考 : 通知の連絡先の管理 - 通知のカテゴリ

連絡先の継承

連絡先設定にも継承の概念があります。組織レベルで連絡先を設定すると、その設定が下位のフォルダ・プロジェクトにまで継承されます。下位プロジェクトで発生したお知らせは組織レベルで設定した連絡先へ通知されます。

「課金」「法務」「セキュリティ」カテゴリの通知は組織レベルで設定することが推奨されています。

参考 : 通知の連絡先の管理 - 連絡先の割り当てに関するベストプラクティス

組織内アクセス制限

組織内アクセス制限（organization restrictions）は、指定された Google Cloud 組織以外の組織へのアクセスを制限する機能です。

当機能は、企業や官公庁のネットワークで HTTP プロキシサーバを利用しており、そのプロキシサーバ以外にはインターネットに出る手段がないことが前提になります。プロキシサーバにおいて、Google Cloud に向けた HTTP リクエストの HTTP ヘッダに特定の Key-Value を強制的に追加することで、そこで指定された組織 ID 以外の組織にアクセスできなくさせます。

詳細は以下の公式ドキュメントをご参照ください。

参考 : 組織内アクセス制限の概要

また実際の利用方法については、以下の当社記事もご参照ください。

blog.g-gen.co.jp

ベストプラクティス

フォルダ構造の決め方

組織配下ではフォルダを使って Google Cloud プロジェクトを整理することができますが、どのようなフォルダ構成とすべきかは悩みの種です。しかしながら、どのような環境でも通用するような絶対の答えはありません。

「IAM」「組織のポリシー」「階層型ファイアウォール」など、継承によって影響範囲が決まる機能を考慮に入れ、どの単位でまとめて管理したいか、という観点でフォルダ構成を決めます。

一例として、以下の図は 組織 ＞ 環境別フォルダ ＞ システム別フォルダ ＞ 機能別プロジェクト という構成になっています。

この会社、あるいは官公庁では、クラウドを横断管理する CCoE チームが存在し、本番環境には本番環境のための統制を、開発環境には開発環境のための統制を、というように環境別に異なったセキュリティポリシーを割り当てるために、このような構成になっています。

別のパターンでは、以下のような構成も取ることができます。以下の例は 組織 ＞ システム別フォルダ ＞ 環境別フォルダ ＞ 機能別プロジェクト という構成になっています。

この環境では、それぞれのシステムはそれぞれの部門が管理していて、あるシステムでは「本番環境」「開発環境」の2面しか用意されていないが、別の部門の別のシステムでは「本番」「UAT」「テスト」「開発」の4面構成であり、セキュリティポリシーも異なる...というように、システムごとに統制の設計が大きく異なります。そのため、システム別フォルダ以下において、担当部署に IAM 権限を与えて、裁量を持たせています。

上記の例でも分かるように、組織の構成を設計する際は、クラウド環境がどのような運用体制でどのように統制されるか、という観点を持つ必要があります。

組織作成直後にやるべきこと

組織作成直後には、組織トップノードの IAM 許可ポリシーにおいて、以下のロールバインディングが存在します。

プリンシパル	ロール
(組織のドメイン名)	プロジェクト作成者（`roles/resourcemanager.projectCreator`）
(組織のドメイン名)	請求先アカウント作成者（`roles/billing.creator`）

(組織のドメイン名) とは、その組織のドメインの Google アカウント全員に権限が与えられていることを意味します。組織レベルの IAM 画面では、以下のように表示されます。

この状態だと、組織のすべてのアカウントがプロジェクトを作成したり、請求先アカウントを作成できます。この状態では、クラウド管理者が気づかないうちに「野良アカウント」が作成できてしまいます。クラウド環境を集中管理するのであれば、この IAM ロールバインディングは削除するべきといえます。

以下のように My First Project というプロジェクトが乱立している状態を見たことがあるでしょうか。

前掲のように組織のアカウントの全員がプロジェクト作成権限を持っている場合、Google Cloud 画面に初めてアクセスした際や、チュートリアルのドキュメントからコンソール画面に遷移した際に、My First Project という名称のプロジェクトが自動的に作成されてしまいます。前述の、プロジェクト作成者ロールの割り当てが削除してあれば、この状況は起こりません。

以下の記事もご参照ください。

blog.g-gen.co.jp