Compute Engineセキュリティ入門

1. Compute Engineでもセキュリティ運用が必要な理由

Compute Engineは、Google Cloud上に仮想マシンを作成し、OSやアプリケーションを柔軟に構成できるサービスです。一方で、Cloud Runなどのフルマネージドサービスと比べて、利用者側で管理する範囲が広くなります。

たとえば、VMに外部IPアドレスが付与され、広い範囲からの通信が許可されていると、意図せずインターネットへ公開される可能性があります。また、VMへ設定されたサービスアカウントに強い権限が付与されていると、侵害時の影響範囲が大きくなる可能性があります。

さらに、ゲストOSや導入ソフトウェアの更新・パッチ適用も利用者側の運用範囲です。長期間稼働するVMでは、VM ManagerのPatchなどを利用して、パッチ適用状況を継続的に確認できるようにします。

まずは、公開範囲・権限・接続方法・ログを分けて確認することが重要です。

図1 Compute Engineでまず確認したいセキュリティ項目

2. VMの公開範囲とネットワーク設定を確認する

外部IPアドレス

最初に、VMへ外部IPアドレスが割り当てられているかを確認します。インターネットから直接アクセスする必要がないVMには外部IPアドレスを付与せず、外向き通信が必要な場合はCloud NAT、管理接続にはIAP TCP転送などの利用を検討します。

ファイアウォールルール

ファイアウォールでは、必要な通信だけを許可しているかを確認します。特にSSHやRDPなどの管理用ポートを広い範囲へ公開していないかは、優先的に点検したいポイントです。

VPCとサブネット

VMがどのVPCとサブネットに所属しているかも確認します。問題が起きたときに通信経路を追えるよう、ネットワーク構成と管理担当者を整理しておくことが重要です。

3. IAMとサービスアカウントを確認する

VMを操作できる主体

IAMでは、VMの作成、変更、停止、削除などを実行できるユーザー、グループ、サービスアカウントを確認します。広い権限が恒常的に残っていないか、一時的に付与した権限が残っていないかも点検します。

VMのサービスアカウント

Compute EngineのVMは、設定されたサービスアカウントの権限を使ってほかのGoogle Cloudサービスへアクセスできます。VMへ設定するサービスアカウントは用途別に分け、必要最小限の権限を付与します。デフォルトのサービスアカウントを広い権限のまま使い続けないことも重要です。

また、サービスアカウント自体へ権限を付与できる主体や、サービスアカウントを利用できる主体もあわせて確認します。

4. SSH接続とOS Loginを確認する

Compute EngineのVMへ接続する代表的な方法としてSSHがあります。安全に管理するためには、接続を許可する主体と、接続に使用する認証情報を整理する必要があります。

OS Loginを利用すると、IAMを使ってSSHアクセスを一元管理できます。管理アクセスを絞りたい場合は、公開範囲の見直しとあわせてOS LoginやIAPの利用を検討します。

図2 公開範囲と管理アクセスを整理する考え方

5. Compute Engineで利用する主なログ

Compute Engineの監視では、目的に応じてログを使い分けます。まずは「設定変更を見るログ」「接続を見るログ」「通信を見るログ」「OS内部を見るログ」を分けて整理すると理解しやすくなります。

図3 Compute Engineで確認したい主なログ

※図3は役割を簡略化したものです。OS Loginの監査ログだけでSSH接続のすべてを確認できるわけではないため、必要に応じてゲストOSの認証ログやIAPの監査ログも確認します。

Compute EngineのCloud Audit Logs

Compute Engineの監査ログでは、VMや関連リソースに対するAPI操作を確認できます。構成や権限に関する変更の調査には、主に管理アクティビティ監査ログを利用します。サービス名は compute.googleapis.com です。

• VMの作成、更新、停止、削除
• VMメタデータの変更
• サービスアカウントの設定変更
• ディスクやスナップショットの操作
• IAMポリシーの変更

OS Loginの監査ログ

OS Loginの監査ログでは、SignSshPublicKeyなど、OS Login APIで監査対象となる操作を確認できます。ただし、SSHセッションそのものを完全に記録するログではありません。実際のログイン状況を確認する場合は、ゲストOSの認証ログや、IAPを利用している場合はIAPの監査ログなども組み合わせて調査します。

VPC Flow Logs

VPC Flow Logsは、対象のVPCネットワークやサブネットなどで有効化し、VMが送受信するネットワークフローのサンプルを記録します。通信元IPアドレス、通信先IPアドレス、ポート、プロトコル、送受信バイト数などを確認でき、通信状況の調査に役立ちます。現在は、より柔軟に設定できるNetwork Management APIの利用が推奨されています。

OSログとアプリケーションログ

VM内部の状況を調査するには、OSログやアプリケーションログも必要です。OSへのログイン、管理者権限の使用、サービス変更、アプリケーションエラーなど、必要なログをCloud Loggingなどへ集約し、VMが停止または削除された後も確認できる状態にしておきます。

6. 注意したい設定変更とイベント

Compute Engineでは、次のような変更やイベントを監視対象として検討します。

• 外部IPアドレスが新たに付与された
• SSHやRDPが広い範囲へ公開された
• ファイアウォールルールが追加・変更された
• 新しいVMが作成された
• VMのサービスアカウントが変更された
• サービスアカウントへ強い権限が付与された
• VMまたはプロジェクトのメタデータにSSH鍵が追加された
• Shielded VMやSecure Bootなどの保護設定が変更された
• ディスクやスナップショットが作成された
• 想定していない外部IPアドレスとの通信が発生した

変更が行われたこと自体が、直ちに不正を意味するわけではありません。変更を行った主体、対象VM、変更前後の設定、変更申請、変更後の通信状況を組み合わせて判断します。

7. 運用を始めるためのチェックポイント

最初からすべてのVMやログを監視しようとすると、運用負荷やログ量が増えすぎる可能性があります。まずは重要なVMから対象を絞り、次の項目を確認します。

• VMの用途と管理担当者が整理されているか
• 外部IPアドレスが必要なVMを把握しているか
• ファイアウォールルールが必要な通信だけを許可しているか
• SSHやRDPの公開範囲が制限されているか
• OS Loginの利用方針が決まっているか
• VMのサービスアカウントが必要最小限の権限になっているか
• Shielded VMやSecure Bootの利用方針が決まっているか
• ゲストOSや導入ソフトウェアのパッチ適用状況を確認できるか
• Compute Engineの管理操作を監査ログで確認できるか
• VPC Flow Logsを利用するサブネットが決まっているか
• OSログやアプリケーションログが保存されているか
• 問題発生時の担当者と連絡方法が決まっているか

確認項目を決めた後は、テスト用のVMで設定変更や通信を発生させ、必要なログが記録されるかを確認します。あわせて、ログの保存期間、閲覧権限、通知方法も整理しておくと、問題発生時に調査を始めやすくなります。

8. まとめ

Compute Engineでは、VMの公開範囲、ファイアウォール、IAM、サービスアカウント、SSH接続、OSなど、利用者側で管理すべき項目が多くあります。

まずは、公開範囲・権限・接続・ログを分けて確認し、重要なVMから対象を絞って運用を始めることが現実的です。外部IPアドレス、ファイアウォール、サービスアカウント、OS Login、監査ログ、VPC Flow Logs、OSログを順番に整理すると進めやすくなります。

次回は、Compute EngineとVPCのログをGoogle SecOpsへ取り込み、外部IPアドレスの付与やファイアウォールルールの変更を検知し、変更後のネットワーク通信を調査する流れを紹介します。

9. 参考情報

• Best practices for controlling SSH network access
• About OS Login
• Best practices for using service accounts securely
• Compute Engine audit logging
• About Shielded VMs
• About Patch - VM Manager
• Configure VPC Flow Logs
• Cloud Audit Logs overview