Google Compute Engineのセキュリティチェックポイント
はじめに
クラウドエースの島田です。
本記事ではGoogle Compute Engine(以降、GCEと記述)のセキュリティチェックポイントを紹介します。
GCEを利用する際の参考にしていただければ幸いです。
以下のようなトピックになっています。
- サービスアカウントとIAM
- ネットワーク
- GCEまわりの設定
本記事ではチェックポイントを紹介するだけにとどめます。
各項目の確認、修正方法はドキュメントのリンクを参照してください。
注意事項
本記事で紹介する設定は、一般的なベストプラクティスにSecurity Command CenterのGCEの推奨設定を加えたものになります。
実際の設定にあたっては要件に適しているか、制約はないかなどの確認が必要になります。
推奨設定を闇雲にお勧めするものではありませんのでご注意ください。
Security Command Center推奨設定リスト
サービスアカウントとIAM
✅デフォルトサービスアカウントを使用していないか
Compute Engineのデフォルトサービスアカウントとは、{project-number}-compute@developer.gserviceaccount.comの形式でプロジェクトに自動作成されるサービスアカウントのことです。
VMの作成時、任意のサービスアカウントを指定しない限りCompute Engineデフォルトサービスアカウントが設定されます。
デフォルトサービスアカウントはプロジェクトレベルで編集者ロールを自動付与されているため、VMが侵害された際に被害を広げるリスクがあります。
また、ユーザーで命名したサービスアカウントと違い、サービスアカウント名、IDからどのリソースにどのような目的で使用されているか分からないという管理の問題も生じるため、デフォルトサービスアカウントは使用しないようにしましょう。
サービスアカウントを使用したワークロードの認証 ベスト プラクティス
確認・修正方法（default service account used）
✅サービスアカウントのIAMは最小権限になっているか
VMを実行するサービスアカウントに余分な権限が付与されていないか、最小権限の原則に則っているかを確認しましょう。
IAMは組織、フォルダ、プロジェクト、リソースレベルで適用でき、サービスによってはさらに細かく制御できるものもあります。例：BigQueryのテーブル、列
基本的には可能な限り細かい粒度で権限付与をするのが望ましいですが、難しい場合は少なくとも「〇〇編集者」や「〇〇閲覧者」等の目的に応じた事前定義ロールを付与するようにしましょう。
プロジェクトオーナーやプロジェクト編集者はVMを侵害された際に影響が広がるリスクがありますので、出来るだけ付与しないようにしましょう。
✅アクセススコープはcloud-platformになっているか
アクセススコープはインスタンス単位で設定できるAPIごとのアクセス制御機能です。
IAMと併用することもできますが、どちらも権限を制御しているため二重に管理することになります。
公式ドキュメントではアクセススコープに個別のAPIを設定せずcloud-platformを設定し、権限制御はIAMで一括して管理することが推奨されています。
インスタンス作成時のスコープ設定の挙動は以下になります。
- Consoleでデフォルトサービスアカウント(SA)を指定して作成する：デフォルトのアクセススコープ（ラジオボタンで変更可）
- Consoleで任意のSAを指定して作成する：cloud-platform
- gcloudコマンドで任意のSAを指定して作成する(スコープ指定なし)：デフォルトのアクセススコープ
- gcloudコマンドで任意のSAを指定して作成する(スコープ指定あり)：任意のアクセススコープ
デフォルトのアクセススコープは以下です。（公式ドキュメントより引用）
- Cloud Storage への読み取り専用アクセス権: https://www.googleapis.com/auth/devstorage.read_only
- Compute Engine ログに書き込むための書き込みアクセス権: https://www.googleapis.com/auth/logging.write
- Google Cloud プロジェクトに指標データを公開するための書き込みアクセス権: https://www.googleapis.com/auth/monitoring.write
- Google Cloud Endpoints に必要な Service Management 機能に対する読み取り専用アクセス権（アルファ版）: https://www.googleapis.com/auth/service.management.readonly
- Google Cloud Endpoints に必要な Service Control 機能に対する読み取り / 書き込みアクセス権（アルファ版）: https://www.googleapis.com/auth/servicecontrol
- Cloud Trace への書き込みアクセス権により、VM 上で実行されているアプリケーションは、トレースデータをプロジェクトに書き込むことができます。 https://www.googleapis.com/auth/trace.append
スコープのベストプラクティス
確認・修正方法（Full API access）
以下のページではデフォルトのSAを使用していてかつ、アクセススコープをcloud-platformに設定している場合に修正する方法が記載されています。
ネットワーク
✅外部IPは付与していないか
特別な要件が無い限り、VMに外部IPは付与しないようにして攻撃表面（攻撃者が侵入を試みるポイント）を減らしましょう。
GCEのVMでは外部IPを付与せずとも、Cloud Load BalancingやCloud NATを使用してインターネット越しのアクセスが可能です。
また、IAP TCP転送を使う事で、SSHやRDPのリモートアクセスも外部IPなしで行うことができます。
外部IPなしのリモートアクセス
確認・修正方法（Public IP address）
✅Private Google Accessは有効になっているか
Private Google Accessをサブネットで有効にすると、サブネット上のGCEインスタンスは外部IPが無くとも内部経路でGoogle CloudのAPIにアクセスできます。
VMに外部IPが無い場合はほぼ必須の設定になります。
確認・修正方法（Private Google access disabled）
✅デフォルトVPCネットワークは使用していないか
Google CloudのデフォルトVPCネットワークはデフォルトのファイアウォールルールも自動で作成しています。
このFWルールはSSHとRDPをインターネットを含む全てのアドレス(0.0.0.0/0)からアクセスを許可するような設定になっています。
この設定がセキュリティ上リスクとなるため、CISなどのベンチマークでも修正または削除するように指摘されています。
上記のような脆弱なFWルールを含むという点以外にも、デフォルトVPCネットワークはその配下に作成されるサブネットワークも名前がdefaultで自動作成されます。
規則や目的に基づいた命名がされていないリソースは運用においてトラブルの元になるため、ユーザーで命名して作成したネットワーク/サブネットを使用するようにしましょう。
また、デフォルトVPCサブネットはリージョンごとに自動でIPアドレスが割り当てられて作成されるため、ネットワーク規模の大きい環境や、オンプレミスと接続した環境において、IPアドレスの枯渇や重複といった問題が発生しやすくなります。
まとめると、以下の理由からデフォルトのVPCネットワーク/サブネット/FWは使用しないようにしましょう。
- デフォルトFWルールは脆弱な設定を含む
- デフォルトで作成されるリソースは運用においてトラブルの元になる（リソースの使用/存在理由が不明確になる）
- デフォルトVPCサブネットはIPアドレスの枯渇や重複の元になりやすい
デフォルトFWルールを削除したいが、プロジェクトごとに作業するのが大変な場合は、組織ポリシーを使用してデフォルトVPCネットワークの作成をスキップすることをおすすめします。
Compute Engine | デフォルト ネットワークの作成をスキップ
確認・修正方法（default network）
GCEまわりの設定
GCEにはオプションで有効/無効にできるセキュリティの設定があります。
一部ネットワークに関する項目も含みます。
✅Shielded VMは有効になっているか
Shielded VMはインスタンスがブートレベルまたはカーネルレベルでマルウェアなどに改ざんされていないかを検証する機能です。
以下3つのオプションから構成されます。各オプションの説明については割愛します。
- セキュアブート
- vTPM
- 整合性モニタリング
vTPMと整合性モニタリングはデフォルトでONになっているのですが、セキュアブートはデフォルトでOFFになっています。
セキュアブートをONにすることでVMをよりセキュアに構成できます。
公式ドキュメント
確認・修正方法（Shielded VM disabled）
✅Confidential VMは有効になっているか
Confidential Computingは、実行中のVMのメモリを暗号化する機能です。
この機能を有効にできるマシンタイプが限られている、パフォーマンスが数パーセント低下する点に注意してください。
公式ドキュメント
確認・修正方法（Confidential Computing disabled）
✅OS Loginが有効になっているか
OS LoginはIAMベースでインスタンスへのSSHアクセスを管理できる機能です。
これを有効にすることで、プロジェクトやインスタンスのメタデータを使わずにSSH鍵を交換・認証できるようになります。
また、追加で2要素認証も設定することができます。
注意点としては、Windows Serverを含む一部のOSイメージでは使用できません。
確認・修正方法（OS login disabled）
✅SSH認証鍵がプロジェクトに設定されていないか
SSH認証鍵はプロジェクトレベルまたはインスタンスレベルで設定できます。プロジェクトレベルで設定すると、プロジェクト配下のすべてのインスタンスに認証鍵を設定できるため管理が容易な反面、認証鍵漏洩時のリスクが増大します。
運用とも相談しつつ、可能な限りインスタンスレベルで鍵を設定しましょう。
ただし、VMへの鍵設定の機能としては、原則として一つ前の項目のOS Loginを使うことがベストプラクティスとなります。
確認・修正方法（Compute project wide SSH keys allowed）：
✅シリアルポート接続が有効になっていないか
シリアルコンソールはIPアクセス制御が出来ないため、設定を有効にすると任意のIPアドレスからインスタンスへアクセス出来てしまいます。
特別な要件が無い限りは無効にしましょう。
デフォルトでOFFになっています。
確認・修正方法（Compute serial ports enabled）
✅VMのディスクがCMEKまたはCSEKで暗号化されているか
VMのディスクの暗号化にCMEK(顧客管理の暗号鍵)またはCSEK(顧客提供の暗号鍵)を使用する場合はユーザー側で鍵の運用が発生します。
デフォルトではGoogle管理の鍵によって暗号化されていますので、独自の暗号化要件などがある場合に検討しましょう。
確認・修正方法（Disk CMEK/CSEK disabled）
✅HTTPSではなくHTTPのLoad Balancerを使用していないか
HTTP(S)ロードバランサのプロトコルにおいて、HTTPSを使用しているかの確認項目です。
確認・修正方法（HTTP load balancer）
✅IP転送が有効になっていないか
データの損失や漏洩を防ぐため、IP転送を無効にしましょう。
デフォルトでOFFになっています。
確認・修正方法（IP forwarding enabled）
✅脆弱なSSLポリシーを使用していないか
HTTP(S)ロードバランサに設定するSSL Policyが脆弱な設定ではないかを確認する項目です。
SSL Policyが未設定になっていないか、TLSバージョンやプロファイルが適切かどうかを確認しましょう。
確認・修正方法（Weak SSL policy）
さいごに
今回はSCC(Security Command Center)のGCEの項目に記載されている推奨設定を紹介しました。 実際にはこれ以外にもGCEやネットワークに関連する項目がいくつかあります（FWログの有効化、VPCフローログの有効化、脆弱なポート開放等）。 是非ドキュメントを参照してみてください。
Discussion