はじめに
Google Cloudから 推奨セキュリティチェックリスト が公開されました。
クラウドセキュリティのベストプラクティス自体はこれまでも存在していましたが、
今回のポイントはそれらが チェックリストとして体系化された 点にあります。
今回公開されたチェックリストはどのようなものなのでしょうか。
また、これと同様のものは、AWSやAzureにもあるのでしょうか。
本記事では、これらを整理していきます。
Google Cloud 推奨セキュリティチェックリストとは
今回公開されたチェックリストは、クラウド環境を安全に構築・運用するために
何を設定すべきか を体系的に整理したものです。
主な特徴は以下の通りです。
- 設定レベルまで具体的に記載されている
- セキュリティ領域ごとに整理されている
- 初期構築（Landing Zone）での利用を想定
一言でいうと 「セキュアな環境を作るための実装ガイド」 です。
チェックリストの中身は3種類に分けられる
今回のチェックリストは一見すると「設定一覧」に見えますが、
実は中身はすべて同じ種類ではありません。
実務的には、次の3つに分類できます。
① 強制できるもの（Policy系）
特定の設定を「禁止・強制」できるものです。
例：
- 外部IPの付与禁止
- OS Loginの必須化
- 利用可能なリージョンの制限
これらはOrganization Policyなどで実現でき、
違反状態をそもそも作らせない（ガードレール）
という役割を持ちます。
② 設定できるが強制できないもの
設定としては有効化できるものの、後から変更される可能性があるものです。
例：
- ログの有効化
- 監査設定の追加
- セキュリティサービスの有効化
Terraformなどで初期構築時に設定することは可能ですが、
継続的に守られているかは別途確認が必要 なものになります。
③ 設計・運用・判断が必要なもの
ツールだけでは実現できない、設計や運用に依存する項目です。
例：
- IAMの最小権限設計
- ネットワーク分離の方針
- ログの運用ルール
- インシデント対応プロセス
これらは、人の設計・判断・運用が不可欠 なものです。
チェックリストの実装手段としてのTerraform
Google Cloud の推奨セキュリティチェックリストでは、
単に項目を提示するだけでなく、Terraformによるサンプル実装 も提供されています
Terraform 公式サンプルについて
Google Cloudが公開している以下のリポジトリは、
推奨設定のうち、特に重要なガードレールをTerraformで適用するサンプル
です。
チェックリストのすべての項目を実装しているわけではなく、
「強制可能で効果の高い設定」に絞られている という点が特徴です。
たとえば
- 外部IPの付与禁止
- OS Loginの必須化
- デフォルトVPCの無効化
などです。
チェックリストのすべての項目がTerraformで実装できるわけではなく、
設計や運用に依存する項目は別途対応が必要です。
なぜ今回このチェックリストが重要なのか
Google Cloud では、今回のような推奨チェックリストがなくても、
セキュリティ対策は可能でしたが、
設計（各自の知識） → 構築 → 検知 → 修正
のようになっており、
- ベストプラクティスを個別に調査
- Organization Policyで制御
- Security Command Centerで検知
という形で、やり方は人に依存していました。
今回のチェックリストが公開されたことで、
チェックリスト → 設計 → 構築
- やるべきことが明確
- 抜け漏れ防止
- 標準化が容易
のようになり、暗黙知が形式知となりました。
チェックリスト自体は、新しい仕組みというわけではないですが
既存のベストプラクティスが体系化されたという点が、大きなポイントかと思います。
セキュリティチェックは自動化できる？
さきほど記載したように、必要最低限の内容に関しては、
公式提供のTerraform がありますが、全てを網羅しているわけではありません。
自動化は、提供されている機能を組み合わせて実現する必要があり
また、役割ごとに分解して実現する必要があります。
例）
- 評価 ：Security Command Center
- 強制 ：Organization Policy
- 修復 ：Pub/Sub + Cloud Functions / Run
このチェックリストと同等のものは他クラウドにもあるのか
では、AWS や Azure など他のクラウドでは、同等のものはあるのでしょうか。
AWS の場合
AWSには、Google Cloudのような単一のチェックリストは存在しません。
セキュリティをチェックするという目的を実現する場合、
以下のような内容を組み合わせて実現する必要があります。
- AWS Foundational Security Best Practices（FSBP）
- CIS AWS Foundations Benchmark
- AWS Well-Architected（Security Pillar）
- AWS Config / Security Hub
AWSの代表的な仕組み
① AWS Foundational Security Best Practices（FSBP）
AWSが提供する、セキュリティ設定のベストプラクティスをまとめた標準ルール集です。
Security Hubで有効化することで、S3の公開設定やIAMの設定不備などを自動的にチェックできます。
Google Cloud のチェックリストと最も近い位置づけで、「何を設定すべきか」を
具体的なコントロールとして定義しているのが特徴です。
② CIS AWS Foundations Benchmark
セキュリティベンチマークを提供するCIS（Center for Internet Security）が定義した、
業界標準のAWSセキュリティガイドラインです。
IAMやログ設定などについて「どのように設定すべきか」が手順レベルで整理されており、
多くの企業でコンプライアンス基準として採用されています。
AWS公式ではないですが、実務で最も広く使われているチェックリストです
③ AWS Well-Architected（Security Pillar）
AWSが提唱する設計フレームワークの一部で、
安全なシステムを設計するための原則やチェック観点をまとめたものです。
他の2つが「設定」にフォーカスしているのに対し、こちらは
「そもそもどう設計すべきか」という上流の考え方を提供するのが特徴です。
レビューは質問形式で行われ、アーキテクチャ全体の健全性を評価できます。
④ AWS Config / Security Hub
これらはチェックリストそのものではなく、
設定が適切かどうかを継続的に監視・評価するための仕組みです。
- AWS Config：リソース設定のルールチェック
- Security Hub：複数のチェック結果を集約・可視化
これにより、構築後の環境に対しても継続的にセキュリティ状態を確認できます。
「作って終わり」ではなく、「運用で守る」ための基盤です。
まとめると
- ①FSBP / ②CIS：何を設定すべきか（チェックリスト）
- ③Well-Architected：どう設計すべきか（原則）
- ④Config / Security Hub：守れているか（継続チェック）
というイメージです。
Azureの場合
Azure に関しても、Google Cloud のような明示的なチェックリスト形式では提供されておらず
セキュリティをチェック・担保するためには、主に以下の仕組みを利用します。
- Azure Policy（設定の強制）
- Initiative（ポリシーセット）
- Microsoft Defender for Cloud（評価）
Azureの代表的な仕組み
① Azure Policy
Azureの中核となる機能で、リソースに対してルールを定義し、
設定の制御・強制・監査を行うことができます。
例えば：
- 特定リージョン以外へのデプロイを禁止
- パブリックアクセスを禁止
- タグの付与を強制
などが可能です。
特徴は、違反状態を検知するだけでなく、そもそも作らせないことができる
という点です。
② Initiative（ポリシーセット）
複数のAzure Policyをまとめたものです。
これは、Google Cloud のチェックリストや、AWSのCIS/FSBPに近い役割を持ちます。
例えば：
- セキュリティベストプラクティスのセット
- コンプライアンス基準（ISO、NISTなど）
をまとめて適用できます。
つまり、「何を守るべきか」をポリシーとして体系化したものです。
③ Microsoft Defender for Cloud
Azureのセキュリティ評価サービスで、
- 設定の不備を検出
- セキュリティスコアとして可視化
- 改善提案の提示
といったことを行います。
AWSのSecurity Hubや、Google CloudのSecurity Command Centerに相当します。
まとめ
Google Cloud の推奨セキュリティチェックリストは、
新しい仕組みを提供したというよりも、
既存のベストプラクティスを体系化し、使いやすくしたもの
と言えます。
一方で、AWSやAzureでは同様の考え方は存在するものの、
- AWS：複数の仕組みを組み合わせて実現
- Azure：ポリシーによって強制的に実現
といった形で提供されています。
これらを整理すると、
- GCP：何をやるべきかを示す（設計主導）
- AWS：継続的に守る仕組み（運用主導）
- Azure：ルールで統制する（ガバナンス主導）
という違いが見えてきます。
ただし重要なのは、どれか1つで完結するものではなく、
設計・実装・運用・統制のすべてが揃って初めてセキュリティが成立する
という点です。
今回のチェックリストは、その中でも特に
「設計の質を底上げする」ための重要な一歩
になると思います。
参考
チェックリストの具体的な内容の解説については、クラスメソッドさんの記事がとても参考になります。