【初学者向け】Compute Engine のセキュリティ周りの設定を解説
はじめに
こんにちは。クラウドエースの中野（大）です。
今回は Google Cloud の Compute Engine のセキュリティ周りの設定について書いていきたいと思います。
Compute Engine のセキュリティ
クラウド上の仮想サーバは、設定次第で意図しないアクセスや攻撃のリスクに晒される可能性があります。適切なセキュリティ設定は、データ漏洩やサービス停止を防ぐために不可欠です。
以下からの章は、GCE インスタンスを作成する際に設定することができるセキュリティ項目です。
サービスアカウント
ご存じの方もいらっしゃると思いますが、GCE インスタンスへどのような権限を付与するかを設定する部分です。
権限を付与しないと GCE インスタンスは単なる仮想サーバとして機能しますが、Google Cloud のエコシステム内で他のサービスと連携するためのネイティブな ID と認証メカニズムを失います。これにより、仮想サーバ上のアプリケーションが Google Cloud API を安全かつ簡単に利用することができなくなります。
仮想サーバから Cloud SQL 上のデータを読み取る際の権限などを付与することで連携することが可能です。
また、デフォルトのサービスアカウントであるDefault compute service accountは初期値として「編集者 (roles/editor)」のロールが付与されています。
そのため、Default compute service accountをそのまま使用すると Google Cloud の最小権限の原則から外れてしまうことや、侵害された際の影響範囲が大きくなることからそのまま GCE インスタンスへ付与することは推奨されません。そのため、新規で作成したサービスアカウントを付与することを推奨します。
アクセススコープ
アクセススコープは、仮想サーバが、自身にアタッチされたサービスアカウントの認証情報を使って、どの Google Cloud API や Google API に対するアクセス権限を持つかを定義するための設定です。
明示的に何もロールを付与していないtest-gce-serviceaccountに「デフォルトのアクセス権を許可」を選択して権限がどうなるか確認してみます。
結果は以下のような形で、Stackdriver Logging（現 Cloud Logging）、Stackdriver Monitoring（現 Cloud Monitoring）、Stackdriver Trace（現 Cloud Trace）への書き込み権限など説明文にも記載のある通りの権限が付与されます。
「すべての Cloud API に完全アクセス権を許可」は設定名の通り、アクセススコープによる制限は事実上なくなり、IAM で許可されたすべての Google Cloud API へのアクセスが可能になります。
「API ごとにアクセス権を設定」は以下のような画面で API ごとに有効にする、読み取り/書き込みを許可のように設定することができます。
初期で有効になっているものは、「デフォルトのアクセス権を許可」で有効となっているものです。
Confidential Computing
Confidential Computing を有効にすることで、仮想サーバが使用するメモリ内のデータが暗号化され、基盤となるホスト OS やハイパーバイザー、他のテナントからの不正アクセスに対する保護が強化されます。
Confidential Computing を有効化する場合、以下の画像に記載があるように、対応するマシンタイプ、互換性のある OS イメージなどにする必要があります。
Confidential Computing がサポートされている構成については以下のドキュメントに記載があります。
Shielded VM
Shielded VM は、仮想サーバに対して、強化されたセキュリティ機能を提供するものです。主な目的は、仮想サーバが起動するプロセスの初期段階（ブートプロセス）やカーネルレベルでのマルウェア（ルートキットやブートキットなど）による攻撃から 仮想サーバを保護し、仮想サーバのソフトウェア環境の整合性を検証可能にすることです。
- セキュアブートをオンにします
仮想サーバの起動時に、ブートローダーや OS のカーネルなど、全てのブートコンポーネントのデジタル署名を検証します。
信頼できる認証局によって署名された、正規のソフトウェアのみが実行されることを保証します。 - vTPM をオンにする
仮想トラステッド プラットフォーム モジュール（vTPM）を使用可能にします。
vTPM は、鍵や証明書のような認証情報を保護するための専用チップです。
TPM ライブラリ仕様 2.0 と完全に互換性があり、FIPS 140-2 認証済みの BoringCrypto モジュールに依存する BoringSSL ライブラリを使用しています。
また、次の設定項目の「整合性モニタリング」関連機能である「メジャードブート」という機能を可能にします。
メジャードブートは、起動時の状態を測定し、「整合性ポリシーベースライン」と呼ばれる既知の正常な状態の記録を作成します。このベースラインは、その後の起動時の測定値と比較され、システムに予期せぬ変更がないかを確認するために使用されます。 - 整合性モニタリング
仮想サーバの初回起動時などの既知の正常な状態の測定値を「ベースライン」として保存し、その後の仮想サーバ起動時に取得された測定値をベースラインとして比較します。
ベースラインからの逸脱（予期しない変更）が検出された場合、それは潜在的なセキュリティ侵害やシステムファイルの改ざんを示唆する可能性があります。
整合性チェックの結果（成功または失敗）は Security Command Center (SCC) や Cloud Logging/Monitoring に報告され、管理者は異常を検知して対応できます。
デフォルトの設定では以下のように、「セキュアブートをオンにします」のみ無効となっており、残り 2 つに関しては有効となっています。
VM アクセス
仮想サーバへのアクセスを制限する設定です。主に IAM 権限や SSH 接続周りでの制限を設定することができます。
IAM 権限で VM アクセスを制御する
OS Login を有効にする設定です。
OS Login は Linux ユーザー アカウントを Google ID にリンクして、SSH アクセス管理を簡素化します。管理者は IAM 権限を設定して、インスタンスレベルまたはプロジェクトレベルで仮想サーバへのアクセスを簡単に管理できます。
OS Login を有効にすることで以下のようなメリットを得ることができます。
- 一元的なアクセス管理
- セキュリティの向上
- SSH 認証鍵管理の簡素化
「IAM 権限で VM アクセスを制御する」を有効にすることと同時に「2 段階認証プロセスを必須にする」を有効にすることができます。
「2 段階認証プロセスを必須にする」を有効にすることでドメインまたはユーザーアカウントでの 2 要素認証プロセスを使用できます。
OS Login を有効にすると、以下のような形でメタデータのキーと値に enable-oslogin true が追加されます。
OS Login について詳しくは以下をご覧ください。
プロジェクト全体の SSH 認証鍵をブロック
プロジェクトのメタデータに保存されている SSH 公開鍵を使用した仮想サーバへのログインを無効化します。
手動で生成した SSH 認証鍵の追加
ユーザーが自分自身で作成した SSH 認証鍵ペア（公開鍵と秘密鍵）のうち、公開鍵をアクセス許可したい特定の仮想サーバのメタデータに登録します。
しかし、ユーザー自身で SSH 認証鍵を管理する必要があるため、管理の手間がかかり、セキュリティリスクも伴います。そのため、特別な要件がない限りは先ほど説明した OS Login で SSH アクセスの管理をすることが推奨されます。
ネットワークセキュリティ
仮想サーバに対するネットワーク部分でのセキュリティです。
ファイアウォールルール
仮想サーバに対する内向き/外向きのネットワーク通信を許可/拒否する設定です。トラフィックの方向、ターゲット、送信元/宛先、プロトコル/ポートに基づいて、きめ細かなアクセス制御ポリシーを定義できます。
例として特定の IP アドレスからのみ SSH アクセスの許可、インターネット全体 (0.0.0.0/0) からウェブサーバー（web-server タグが付いた GCE インスタンス）への HTTP (TCP ポート 80) および HTTPS (TCP ポート 443) トラフィックを許可などを実施することができます。
Cloud Firewall サービスの詳しい説明は以下の記事をご覧ください。
VPC ネットワーク
GCE インスタンスへネットワークインターフェースの設定をする際、デフォルトで default ネットワークが設定されます。
default ネットワークは以下のように、いくつかの事前定義されたファイアウォールルールが自動的に設定されています。各ルールについてここでは詳しく解説しませんが、不必要な通信が許可されることにより、セキュリティリスクが高まります。
また、default ネットワークは Google Cloud の各リージョンに自動的にサブネットが作成されるため、攻撃者が IP アドレス範囲が予測しやすくなってしまいます。
そのため、default ネットワークは使用せず VPC ネットワークを新規で作成し、必要なリージョンに必要な IP アドレス範囲のサブネットを自分で定義し、ファイアウォールルールも最初からすべて拒否（implied deny）の状態から必要な通信のみを明示的に許可するようにすることが推奨されます。
default ネットワークについて詳しくは以下をご覧ください。
外部 IP アドレス
default ネットワークと同様に、ネットワークインターフェースの設定をする際、デフォルトで外部 IP アドレスがエフェメラルで付与されます。
仮想サーバへ外部 IP アドレスを直接指定してアクセスする必要がある場合は、デフォルトの設定から変更する必要はありませんが、そのほかの場合は、インターネットから直接仮想サーバへアクセス可能になってしまうため、不正アクセスのリスクが高まってしまいます。そのため、以下のように外部 IPv4 アドレスの設定を「なし」にする必要があります。
また、外部 IP アドレスの設定が必要な場合についても、ファイアウォールルールの項目で開設したように、アクセスを許可するポートや、IP アドレスを指定して仮想サーバへのアクセスを制限することでセキュリティリスクを軽減できます。
Cloud Armor
ロードバランサと組み合わせて使用することで、DDoS 攻撃や OWASP Top 10 などのウェブ攻撃から仮想サーバ上のアプリケーションを保護することができる設定です。
先述したように、Cloud Armor は GCE インスタンスへ直接設定するものではなく、GCE インスタンスをバックエンドとしているロードバランサに対してセキュリティポリシーを適用することで、間接的に仮想サーバ上のアプリケーションを DDoS 攻撃やウェブ攻撃から保護する役割を果たします。
限定公開の Google アクセス
限定公開の Google アクセスは、仮想サーバが外部 IP アドレスを持たない状態でも特定の Google API やサービス（Cloud Storage、BigQuery、Artifact Registry など）にアクセスできるようにする機能です。
通信は、Google Cloud 内部ネットワークを経由し、インターネットへ出ないため安全です。
推奨設定
ここまで GCE インスタンスのセキュリティについて解説してきました。
ここで、今まで解説してきたセキュリティの設定で、筆者が思う GCE インスタンスのセキュリティの推奨設定について表でまとめてみます。
| 設定項目 | 設定内容 | 備考 |
|---|---|---|
| サービスアカウント |
Default compute service accountは使用せずに、最小権限の原則に基づいたサービスアカウントを新規作成し、GCE インスタンスへ設定 |
|
| Confidential Computing | 基本的に無効 | 最高レベルの機密性が要求されるデータやワークロードを扱う場合については有効にする |
| Shielded VM | すべて有効 | 「セキュアブートをオンにします」のみデフォルトで無効になっているため、有効にする |
| IAM 権限で VM アクセスを制御する（OS Login） | 有効 | Linux OS 選択時のみ設定できる |
| VPC ネットワーク |
defaultネットワークは使用せずに、VPC ネットワークを新規で作成して必要な通信のみ許可する |
|
| 外部 IP アドレス | 仮想サーバへ直接外部 IP アドレスを付与する必要がある場合以外は「なし」にする | |
| Cloud Armor | GCE インスタンスの前段にロードバランサを配置する場合は設定推奨 | |
| 限定公開の Google アクセス | 有効 | 内部 IP アドレスのみで Google Cloud API にアクセスする必要があるため |
まとめ
Compute Engine についても他の Google Cloud のサービスや、オンプレミスのサーバなどと同様にセキュリティ対策をすることが必要で、説明した設定でセキュリティ対策を行うことが可能です。
また、Compute Engine のセキュリティは、インスタンス設定、ネットワーク設定、ID管理（IAM/OS Login）など、複数のレイヤーで対策することが重要です。
Discussion