【GCPでセキュリティの柱を築く】組織ポリシーを適用する
こんにちは、クラウドアーキテクトの山下です。
GCPは組織を組むことでプロジェクトに対して全体的に予防的統制をかけられることを今までお話してきました。
前回は組織を構成する事にフォーカスしてきましたが、より細かいセキュリティ要件を満たす内容について触れられればと思います。まず第１弾として組織ポリシーについて今回は触れていきたいと思います。
組織ポリシーとは
組織ポリシーは組織全体で特定のサービスに対して多種多様な制限をかける事ができる機能です。AWS OrganizationのSCPやAzureのAzure Policyに近い機能です。組織配下のプロジェクトを操作するユーザに許可/有効にさせたくない機能を制限することが出来ます。
例えば、CloudSQLのインスタンスにパブリックIP付与を禁じてインターネット接続できないようにしたり、ServiceAccountのシークレットキーを作成させないなどの措置を取る事が出来ます。
実際に組織ポリシーを適用すると以下のような挙動になります。
組織ポリシーによって制限がかけられるだけでなく、配下のプロジェクトに対して何故作成できないかの理由まで提示されます。他社クラウドが権限エラーだけ出し、原因の深堀はユーザに任されているのに比べると親切に見えます。
例：CloudSQLへのパブリックIP付与禁止
例：CloudSQLインスタンス作成画面
事前定義ポリシー
この記事を書いている2024年6月時点での事前定義の組織ポリシーは123個になります。
事前定義ポリシーはアップデートにより増減するため、今後増加したりリタイアしていくものもあります。利用対象/利用予定となっているサービスについて特に有効にしていく事をお勧めします。可能であれば全部を有効/リスト登録することも有用ですが、あとから追加する事も出来ますし、プロジェクト側の要望に応じて除外する事も可能です。確実なものから徐々に有効にすることをお勧めします。
ポリシーの階層
組織ポリシーはその名前とは異なり組織のみで有効にするものではありません。
親子関係になっており、組織→フォルダ→プロジェクトの順に伝播していき、フォルダ単位でもプロジェクト単位でも組織ポリシーは設定できます。
ここでポイントになるのが継承です。親のポリシーを継承するかオーバーライドするかが選択できます。デフォルトでは親のポリシーを継承するにチェックが入っており、親はGoogle管理となるためGoogleで管理されるデフォルトポリシーとなります。
整理すると要するに組織/フォルダ/プロジェクトのいずれかの階層でオーバーライドされていないとデフォルトのままなのでどこかでオーバーライドする必要があります。オーバーライドされた箇所からその配下にかけてポリシーは適用されていきます。
ちなみにデフォルトで有効のポリシーは以下になり、それ以外は無効化されているためオーバライドして有効化します。
ルール種別
オーバライドが必要な事が分かりましたが、ではどのように適用していけばよいか見ていきます。
事前定義ポリシーは大きく２種類に分かれます。有効と無効だけではなく、リストに追加していくパターンもあるため設定方法が異なります。
- Bool型：有効/無効かを選ぶ2択パターン
- List型：適用対象をListに追加していくパターン
Bool型は適用のオン/オフを選択するのみのシンプルなパターンです。適用したタイミングからその配下のフォルダ/プロジェクト全体に適用されていきます。
List型の組織ポリシーの場合は適用だけでなく結合と置換の2つが新たに選択肢が出ます。結合とする場合はListが継承元(親)にその配下で設定したリストが加えられます。また、置換とする場合は親のポリシーは無視されます。
また、ポリシーは”すべて許可”、”すべて許可しない”、カスタムとなります。List型の例はサービスを利用できるリージョンを許可に加えたい場合などがあります。
カスタムでは許可/拒否の選択と対象となる値の登録を行えます。
※ここでは東京リージョンにのみリソースを配置できるポリシーを例に値を設定しています。
ポリシーの適用条件
ポリシーはさらに適用条件を設定する事が出来ます。
タグのみとなりますが、特定のタグが付与されたリソースや階層にのみ適用させることができます。プロジェクト全体ではなく特定のタグがあるもののみに適用させることが出来ます。
組織ポリシーの除外/要注意ポイント
組織ポリシーを組織で設定し、オーバライドする事で組織全体にポリシーを効かせることが可能ですが、例外というのはプロジェクトが増加するにつれて発生し得ます。
そこで例外として除外を行うために出来るのは除外したい範囲でのオーバライドです。これにより親から継承されることを防ぐことが出来ます。例えば組織全体でServiceAccountのキー作成を禁じたいが、特定のプロジェクトでどうしてもキー作成が必要な場合などです。
組織ポリシーを触らせない
オーバライドできることからユーザで変更されてしまうと元も子もなくなります。ユーザ側で上書きを自由にされないよう組織ポリシー管理者のロール(それに相当する権限)を渡さないようにします。フォルダやプロジェクト配下のメンバーにはあくまでその範囲までとして組織ポリシーは組織管理者相当の担当者が実施する事が推奨です。
プロジェクトの移行に気を付ける
プロジェクトの移行に関わるポリシーはデフォルトでは無効(許可なし)となっています。そのため、組織間でプロジェクトを移行させる際には一時的に有効にしたり、特定の組織だけ許可リストに入れるなどの対応が必要です。組織ポリシーが思わぬ操作の障壁になる事もあるので注意が必要です。
constraints/resourcemanager.allowedImportSources
constraints/resourcemanager.allowedExportDestinations
カスタム定義ポリシー
組織レベルでのみカスタム制約を設定する事が可能です。
カスタム制約ではリソース(対象API)に対して許可/拒否のルールを設定できます。
カスタム制約の条件句はCELで定義を行う事が出来ます。サポートされているサービスも条件句も大量にあるわけはないので事前定義と比べると若干自由度は落ちますが、GCEが関わるIaaS系サービスで制限をかけられます。
整数(Int),文字列(String),Bool,配列(List),KV(Map)などリソースが持つデータ型に応じて設定を入れる事が出来ます。
condition: "resource.ipCidrRange.startsWith('10.')"
判定に使用できるデータの型はカスタム制約に対応した各サービスのドキュメントから確認ができます。量は多くはないですが、サンプルも載っているので組織で特に統制の効きにくいIaaS部分にも適用が可能になります。
まとめ
今回は組織ポリシーについて内容を見てきました。色々と紹介したためハードルが高いようにも思えますが、組織ポリシーは大変有用なので出来るところから実施を目指してみましょう。
まずは組織レベルで事前定義ポリシーの有効化から実施する事をお勧めします。プロジェクトからの要望に合わせて後から除外していけるためです。ServiceAccountのキー作成などベストプラクティスとして無効化すべき内容から実施していき、使用していないサービスの細かい項目は後から実施しても問題ありません。
Discussion