組織ポリシーを適⽤する

はじめに

こんにちは、クラウドアーキテクトの⼭下です。

GCPは組織を組むことでプロジェクトに対して全体的に予防的統制をかけられることを今までお話してきました。

前回は組織を構成する事にフォーカスしてきましたが、より細かいセキュリティ要件を満たす内容について触れられればと思います。まず第１弾として組織ポリシーについて今回は触れていきたいと思います。

組織ポリシーとは

組織ポリシーは組織全体で特定のサービスに対して多種多様な制限をかける事ができる機能です。AWS OrganizationのSCPやAzureのAzure Policyに近い機能です。組織配下のプロジェクトを操作するユーザに許可/有効にさせたくない機能を制限することが出来ます。

例えば、CloudSQLのインスタンスにパブリックIP付与を禁じてインターネット接続できないようにしたり、ServiceAccountのシークレットキーを作成させないなどの措置を取る事が出来ます。

https://cloud.google.com/resource-manager/docs/organization-policy/overview?hl=ja

実際に組織ポリシーを適⽤すると以下のような挙動になります。

組織ポリシーによって制限がかけられるだけでなく、配下のプロジェクトに対して何故作成できないかの理由まで提⽰されます。他社クラウドが権限エラーだけ出し、原因の深堀はユーザに任されているのに⽐べると親切に⾒えます。

例：CloudSQLへのパブリックIP付与禁⽌

例：CloudSQLインスタンス作成画⾯

事前定義ポリシー

この記事を書いている2024年6⽉時点での事前定義の組織ポリシーは123個になります。

事前定義ポリシーはアップデートにより増減するため、今後増加したりリタイアしていくものもあります。利⽤対象/利⽤予定となっているサービスについて特に有効にしていく事をお勧めします。可能であれば全部を有効/リスト登録することも有⽤ですが、あとから追加する事も出来ますし、プロジェクト側の要望に応じて除外する事も可能です。確実なものから徐々に有効にすることをお勧めします。

https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints?hl=ja

ポリシーの階層

組織ポリシーはその名前とは異なり組織のみで有効にするものではありません。

親⼦関係になっており、組織→フォルダ→プロジェクトの順に伝播していき、フォルダ単位でもプロジェクト単位でも組織ポリシーは設定できます。

ここでポイントになるのが継承です。親のポリシーを継承するかオーバーライドするかが選択できます。デフォルトでは親のポリシーを継承するにチェックが⼊っており、親はGoogle管理となるためGoogleで管理されるデフォルトポリシーとなります。

整理すると要するに組織/フォルダ/プロジェクトのいずれかの階層でオーバーライドされていないとデフォルトのままなのでどこかでオーバーライドする必要があります。オーバーライドされた箇所からその配下にかけてポリシーは適⽤されていきます。

https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy?hl=ja

ちなみにデフォルトで有効のポリシーは以下になり、それ以外は無効化されているためオーバライドして有効化します。

https://cloud.google.com/resource-manager/docs/secure-by-default-organizations?hl=ja

ルール種別

オーバライドが必要な事が分かりましたが、ではどのように適⽤していけばよいか⾒ていきます。

事前定義ポリシーは⼤きく２種類に分かれます。有効と無効だけではなく、リストに追加していくパターンもあるため設定⽅法が異なります。

• Bool型：有効/無効かを選ぶ2択パターン
• List型：適⽤対象をListに追加していくパターン

Bool型は適⽤のオン/オフを選択するのみのシンプルなパターンです。適⽤したタイミングからその配下のフォルダ/プロジェクト全体に適⽤されていきます。

List型の組織ポリシーの場合は適⽤だけでなく結合と置換の2つが新たに選択肢が出ます。結合とする場合はListが継承元(親)にその配下で設定したリストが加えられます。また、置換とする場合は親のポリシーは無視されます。

また、ポリシーは”すべて許可”、”すべて許可しない”、カスタムとなります。List型の例はサービスを利⽤できるリージョンを許可に加えたい場合などがあります。

カスタムでは許可/拒否の選択と対象となる値の登録を⾏えます。

※ここでは東京リージョンにのみリソースを配置できるポリシーを例に値を設定しています。

ポリシーの適⽤条件

ポリシーはさらに適⽤条件を設定する事が出来ます。

タグのみとなりますが、特定のタグが付与されたリソースや階層にのみ適⽤させることができます。プロジェクト全体ではなく特定のタグがあるもののみに適⽤させることが出来ます。

組織ポリシーの除外/要注意ポイント

組織ポリシーを組織で設定し、オーバライドする事で組織全体にポリシーを効かせることが可能ですが、例外というのはプロジェクトが増加するにつれて発⽣し得ます。

そこで例外として除外を⾏うために出来るのは除外したい範囲でのオーバライドです。これにより親から継承されることを防ぐことが出来ます。例えば組織全体でServiceAccountのキー作成を禁じたいが、特定のプロジェクトでどうしてもキー作成が必要な場合などです。

組織ポリシーを触らせない

オーバライドできることからユーザで変更されてしまうと元も⼦もなくなります。ユーザ側で上書きを⾃由にされないよう組織ポリシー管理者のロール(それに相当する権限)を渡さないようにします。フォルダやプロジェクト配下のメンバーにはあくまでその範囲までとして組織ポリシーは組織管理者相当の担当者が実施する事が推奨です。

プロジェクトの移⾏に気を付ける

プロジェクトの移⾏に関わるポリシーはデフォルトでは無効(許可なし)となっています。そのため、組織間でプロジェクトを移⾏させる際には⼀時的に有効にしたり、特定の組織だけ許可リストに⼊れるなどの対応が必要です。組織ポリシーが思わぬ操作の障壁になる事もあるので注意が必要です。

カスタム定義ポリシー

組織レベルでのみカスタム制約を設定する事が可能です。

カスタム制約ではリソース(対象API)に対して許可/拒否のルールを設定できます。

https://cloud.google.com/resource-manager/docs/organization-policy/custom-constraint-supported-services?hl=ja

カスタム制約の条件句はCELで定義を⾏う事が出来ます。サポートされているサービスも条件句も⼤量にあるわけはないので事前定義と⽐べると若⼲⾃由度は落ちますが、GCEが関わるIaaS系サービスで制限をかけられます。

https://cloud.google.com/resource-manager/docs/organization-policy/creating-managing-custom-constraints?hl=ja#common_expression_language

整数(Int),⽂字列(String),Bool,配列(List),KV(Map)などリソースが持つデータ型に応じて設定を⼊れる事が出来ます。

判定に使⽤できるデータの型はカスタム制約に対応した各サービスのドキュメントから確認ができます。量は多くはないですが、サンプルも載っているので組織で特に統制の効きにくいIaaS部分にも適⽤が可能になります。

https://cloud.google.com/compute/docs/access/custom-constraints?hl=ja#supported-resources

まとめ

今回は組織ポリシーについて内容を⾒てきました。⾊々と紹介したためハードルが⾼いようにも思えますが、組織ポリシーは⼤変有⽤なので出来るところから実施を⽬指してみましょう。

まずは組織レベルで事前定義ポリシーの有効化から実施する事をお勧めします。プロジェクトからの要望に合わせて後から除外していけるためです。ServiceAccountのキー作成などベストプラクティスとして無効化すべき内容から実施していき、使⽤していないサービスの細かい項⽬は後から実施しても問題ありません。