G-gen の杉村です。 Google Cloud (旧称 GCP) には 組織のポリシー 機能があり、企業や官公庁など、組織における Google Cloud 利用に統制を効かせることができます。当記事では組織のポリシーを徹底解説します。

組織のポリシーとは

Google Cloud (旧称 GCP) には組織 (Organization) の機能があり、複数のプロジェクトを統合管理することができます。会社や官公庁などで組織的に Google Cloud を利用するに当たり必須の機能です。

組織では フォルダ (Folder) を使って階層構造を作り、個別のテナントにあたる Google Cloud プロジェクト を格納することができます。

このように組織で管理されたプロジェクトに対し一定のルールを課し、統制を効かせるための機能が 組織のポリシー (Organization Policy) 機能です。

例として、組織のポリシーでは以下のようなことが実現できます。

特定のリージョン (ロケーション) 以外は使わせないようにする
特定のサービス (Compute Engine 等) 以外は使わせないようにする
組織外部との IAM 紐づけを禁止する

仕組み

制約 (constraints)

組織のポリシーの個々のルールは制約 (constraints) と呼ばれます。「組織のポリシーの制約 (Organization policy constraints) 」という用語がドキュメントに現れることもあります。

例として Google Cloud Platform - リソースロケーションの制限 (Resource Location Restriction) という制約は Google Cloud リソースを作成できるロケーション (リージョンやマルチリージョン) を制限できます。

制約は リスト か ブール の2タイプに分けられます。

リスト型制約は「許可する値」または「拒否する値」をリストとして持つことができます。先ほど例に挙げた リソースロケーションの制限 (Resource Location Restriction) はリスト型であり、許可対象あるいは拒否対象のロケーションのリストを持たせることができます。

ブール型制約は True か False で指定する制約です。例として サービスアカウントキーの作成を無効化 (Disable service account key creation) があります。

なお、制約には 表示名 と名前 (または ID) があります。先ほど例に上げた リソースロケーションの制限 (Resource Location Restriction) は表示名であり正式名称 (ID) は constraints/gcp.resourceLocations です。

制約の一覧は以下のドキュメントにあるので、ご参照ください。

参考 : 組織のポリシーの制約

継承

組織のポリシーには継承という特性があります。

組織のポリシーの制約は「組織 (ルート)」「フォルダ」「プロジェクト」のレベルでそれぞれ設定することができます。

階層の上位に設定した制約は、下位のリソースに継承させることができます。

制約を設定する際に 親のポリシーを継承する (inheritFromParent) を有効化すると、上位リソースに設定された制約を引き継ぎます。

リスト型制約では、制約を上位から継承したうえで 親と結合する を選択することもできます。これを選択した場合、リストに値を追加することができます。

参考 : 階層評価について

デフォルトで適用される制約

2024年初頭以降に新しく作成された Google Cloud 組織では、いくつかの制約がはじめから有効化されています。以下に、その制約の一覧を記載します。

なお、それ以前から Google Cloud 組織を保有している場合は、初期状態ではどの制約も有効化されていません。2024年2月から2024年4月の間に作成された組織の一部には、これらのデフォルトの制約が適用されている場合と、されていない場合があります。2024年5月3日以降に作成されたすべての組織には、これらのデフォルトの制約が適用済みです。

参考 : デフォルトで安全な組織リソースを管理する

表示名	ID	説明
Disable service account key creation	iam.disableServiceAccountKeyCreation	サービスアカウントキーの作成を禁止
Disable service account key upload	iam.disableServiceAccountKeyUpload	サービスアカウントキーの公開鍵のアップロードを禁止
Disable automatic role grants to default service accounts	iam.automaticIamGrantsForDefaultServiceAccounts	Compute Engine 等のデフォルトサービスアカウントに編集者ロールが付与されることを防ぐ
Restrict identities by domain	iam.allowedPolicyMemberDomains	許可した組織以外に所属するアカウントへの権限付与を禁止する
Restrict contacts by domain	essentialcontacts.allowedContactDomains	許可した組織以外に所属するアカウントに対してGoogle Cloudからの重要な通知が届く設定をできないようにする
Uniform bucket-level access	storage.uniformBucketLevelAccess	Cloud Storage バケットで均一なバケットレベルのアクセスを必須にする
Use zonal DNS by default	compute.setNewProjectDefaultToZonalDNSOnly	Compute Engine VM が global DNS を使うことを禁止する (※1)

(※1) 2018年9月6日以前に作成された組織で使われていた、可用性の低い DNS サービスのこと（参考)

カスタム制約

カスタム制約 を作成することで、独自の制約を作成することができます。

YAML ファイルで制約を定義し、条件の詳細は Common Expression Language (CEL)の文法で定義します。

参考 : カスタム制約の作成と管理

組織のポリシーの管理

IAM 権限

組織のポリシーを管理するには、管理者の Google アカウントが 組織レベル で 組織ポリシー管理者 (roles/orgpolicy.policyAdmin) ロールを持っている必要があります。

なおポリシーを作成・変更できるのは事前定義ロールの中では 組織ポリシー管理者 ロールだけです。オーナー (roles/owner) や 組織の管理者 (roles/resourcemanager.organizationAdmin) でさえも、ポリシーをリスト表示することはできますが、作成や変更はできません。

また 組織ポリシー管理者 ロールを付与できる最下位のリソースは組織レベルです。フォルダやプロジェクトレベルに付与することでフォルダ・プロジェクトの管理者に管理を委任することはできません。これは、管理を委任できてしまうと、下位リソースでポリシーを上書き・置換できてしまうため、統制が効かなくなってしまうためです。

ドライラン

一部の制約ではドライランを用いて、実際に制約を適用する前に影響を確かめることができます。ドライランモードで制約を適用すると、制約に違反したアクションは Cloud Logging へ記録されますが、実際に拒否されません。

ドライランが利用可能な制約はごく一部ですのでご注意ください。どの制約でドライランが使用可能かは、以下のドキュメントをご参照ください。

参考 : Create a dry-run organization policy

有効にすべき組織ポリシー

Google Cloud の利用を始めたとき、どの制約を有効化すべきでしょうか。

本来は、組織のセキュリティ要件を検討し、適切な設計に基づいて有効化する制約と設定値を設計することが望ましいです。しかし、その内容に迷った場合は、いくつかの指針があります。

まずは、前掲の組織のデフォルトの制約です。2024年初頭以降に新しく作成された Google Cloud 組織では、明示的に設定しなくても、最初から前掲のデフォルトの制約が有効化されています。必要に応じて、それらの制約の設定値を修正してください。それ以前に作成された組織であれば、明示的に有効化することを検討しましょう。

また、Security Command Center から提供される Predefined posture for secure by default, essentials の設定値も参考になります。Predefined posture は Security Command Center の Enterprise ティアと Premium ティアで提供される機能で、Google Cloud 組織をセキュアに利用するための一通りの設定を提供する機能です。同機能を利用しなくても、ドキュメントで掲示されている組織ポリシーの設定値を参考にすることができます。

この Predefined posture で定義されている組織ポリシーは、組織のデフォルトの制約と重複しているものもありますが、compute.requireOsLogin や compute.skipDefaultNetworkCreation のように独自のものもあります。内容は、以下の公式ドキュメントを参考にしてください。