Compute EngineのShielded VMについて調べてみた
はじめに
こんにちは。
クラウド事業本部コンサルティング部の渡邉です。
Google Cloud の Compute Engine には、Shielded VM というセキュリティ機能があります。資格勉強をしていて名前は聞いたことがある方も多いと思います。
しかし、Shielded VMが「具体的に何をしてくれるのか」「有効化すると何が変わるのか」がわかりにくいと感じている方も多いのではないでしょうか。
本記事では、Shielded VM の仕組みと実際に有効化する手順、有効化した後のCloud Loggingでのログの確認について紹介します。
Shielded VM とは
Shielded VM は、Compute Engine のVM インスタンスを、ブートレベルの攻撃（ルートキット、ブートキットなど）から保護するためのセキュリティ機能のセットです。
通常のVM では、OS が起動する前のブートシーケンス（ファームウェア → ブートローダー → カーネルの順に実行される一連の処理）に対して改ざん検知の仕組みがありません。Shielded VM は、このブートシーケンス全体を保護・監視することで、「起動時から安全なVM」を実現します。
3つのセキュリティ機能
Shielded VM は、以下の3つの機能で構成される「トリプルシールドアーキテクチャ」を採用しています。
特徴的なのは、vTPM（仮想 Trusted Platform Module） と Integrity Monitoring（整合性監視） に関しては、デフォルトで有効化されている点です。
ユーザが意識しなくても、上記の2つの機能については、VMインスタンス作成時にデフォルトで有効化されています。
Secure Bootのみ、明示的に有効化を選択する必要があります。
| 機能 | 概要 | デフォルト |
|---|---|---|
| Secure Boot | 署名されたソフトウェアのみ起動を許可 | 無効 |
| vTPM（仮想 Trusted Platform Module） | 暗号化キーの生成・保護、Measured Boot の実施 | 有効 |
| Integrity Monitoring（整合性監視） | ブート測定値をベースラインと比較して変更を検知 | 有効 |
以下で、各機能の詳細を見ていきたいと思います。
Secure Boot
Secure Boot は、UEFI ファームウェアの機能を使い、ブートコンポーネント（ファームウェアドライバ、OS ブートローダー、カーネルなど）のデジタル署名を検証します。署名が確認できないコンポーネントは起動を拒否され、ブートプロセスが停止します。
これにより、改ざんされたブートローダーやカーネルのロードを防止し、ルートキットやブートキットがVM の再起動をまたいで持続することを防ぎます。
vTPM（仮想 Trusted Platform Module）
vTPM は、ハードウェアの Trusted Platform Module（TPM）を仮想化したものです。Shielded VM の vTPM は Trusted Computing Group (TCG) TPM ライブラリ仕様 2.0 に完全準拠しており、BoringSSL ライブラリを使用しています。
vTPM は、以下の2つの主要な役割を担います。
Measured Boot の実施
ブート時に、ファームウェア・ブートローダー・カーネル・ドライバなどの各コンポーネントを順にロードするたびに暗号ハッシュを生成し、それらをチェーン状に結合して Platform Configuration Registers（PCR）に安全に格納します。最初の起動時に生成されたこの測定値が「整合性ポリシーベースライン」となり、以降の起動時に比較対象として使われます。
[公式引用] Measured Bootのイメージ図
暗号化キーの生成・保護
vTPM はキーや証明書を安全に保管するために使用できます。Windows VM での BitLocker を使ったディスク暗号化では、vTPM が暗号化キーを保管する仕組みになっています。
Integrity Monitoring（整合性監視）
Integrity Monitoring は、Measured Boot によって取得された現在のブート測定値を、整合性ポリシーベースラインと比較して一致するかどうかを検証します。
検証は2段階で実施されます。
- Early Boot Validation: UEFI ファームウェア開始からブートローダーへの制御移譲まで
- Late Boot Validation: ブートローダーから OS カーネルへの制御移譲まで
不一致（整合性検証失敗）が発生した場合、Cloud Logging と Security Command Center にアラートが生成されます。
実際に試してみる
前提条件
- Google Cloud プロジェクトが作成済みであること
gcloudCLI がインストール・認証済みであること- Shielded VM 対応の OS イメージを使用すること
compute.instances.updateShieldedInstanceConfig権限を持つ IAM ロール（roles/compute.instanceAdmin.v1またはroles/compute.securityAdmin）が付与されていること
1. Shielded VM を有効にした状態でインスタンスを作成する
新規インスタンス作成時にすべての Shielded VM オプションを有効にするには、以下のように --shielded-secure-boot、--shielded-vtpm、--shielded-integrity-monitoring フラグを指定します。
gcloud compute instances create my-shielded-vm \
--zone=asia-northeast1-a \
--image-family=debian-12 \
--image-project=debian-cloud \
--shielded-secure-boot \
--shielded-vtpm \
--shielded-integrity-monitoring
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/asia-northeast1-a/instances/my-shielded-vm].
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS
my-shielded-vm asia-northeast1-a n1-standard-1 10.x.x.x xx.xx.xx.xx RUNNING
Shielded VM (Secure Boot/vTPM/Integrity Monitoringの有効化確認)
コンソールの「セキュリティとアクセス」>「Shielded VM」セクションで、セキュアブート・vTPM・整合性モニタリングの3つがすべてオンになっていることが確認できます。
2. ブート整合性の検証結果を確認する
インスタンスの起動後、Cloud Logging でブート整合性の検証結果を確認できます。Cloud Logging のログエクスプローラーで以下のクエリを実行してください。
earlyBootReportEvent は UEFI ファームウェア開始からブートローダーへの制御移譲まで、lateBootReportEvent はブートローダーから OS カーネルへの制御移譲までの整合性検証になります。
resource.type="gce_instance"
(jsonPayload.earlyBootReportEvent.policyEvaluationPassed=true OR
jsonPayload.lateBootReportEvent.policyEvaluationPassed=true)
earlyBootReportEvent の検証結果です。
{
"insertId": "1",
"jsonPayload": {
"@type": "type.googleapis.com/cloud_integrity.IntegrityEvent",
"bootCounter": "1",
"earlyBootReportEvent": {
"policyEvaluationPassed": true,
"actualMeasurements": [
{
"value": "0KUbR/mg3+8bwW0xjQtbxWh/1gI=",
"hashAlgo": "SHA1",
"pcrNum": "PCR_0"
},
{
"value": "VdWbJrtJtrG8VMMtdzaFcnOsBWs=",
"pcrNum": "PCR_1",
"hashAlgo": "SHA1"
},
{
"value": "sqg7Dr8vg3Qpmlsr38MeqVWtcjY=",
"hashAlgo": "SHA1",
"pcrNum": "PCR_2"
},
{
"hashAlgo": "SHA1",
"pcrNum": "PCR_3",
"value": "sqg7Dr8vg3Qpmlsr38MeqVWtcjY="
},
{
"hashAlgo": "SHA1",
"pcrNum": "PCR_4",
"value": "HsBkpXdnNnug9eTayHfqMc0Kkww="
},
{
"value": "1G7L/FgtD8elD8YMEYP8sr2duYk=",
"pcrNum": "PCR_5",
"hashAlgo": "SHA1"
},
{
"value": "sqg7Dr8vg3Qpmlsr38MeqVWtcjY=",
"pcrNum": "PCR_6",
"hashAlgo": "SHA1"
},
{
"value": "Cweve3rkjFemIkotmLP1g3SObug=",
"hashAlgo": "SHA1",
"pcrNum": "PCR_7"
}
],
"policyMeasurements": [
{
"value": "0KUbR/mg3+8bwW0xjQtbxWh/1gI=",
"pcrNum": "PCR_0",
"hashAlgo": "SHA1"
},
{
"pcrNum": "PCR_7",
"hashAlgo": "SHA1",
"value": "Cweve3rkjFemIkotmLP1g3SObug="
}
]
}
},
"resource": {
"type": "gce_instance",
"labels": {
"instance_id": "INSTANCE_ID",
"project_id": "PROJECT_ID",
"zone": "asia-northeast1-a"
}
},
"timestamp": "2026-07-12T20:38:42.873251897Z",
"severity": "NOTICE",
"logName": "projects/PROJECT_ID/logs/compute.googleapis.com%2Fshielded_vm_integrity",
"receiveTimestamp": "2026-07-12T20:38:42.988115742Z"
}
policyEvaluationPassed: true となっており、ベースラインとの整合性検証に合格しています。bootCounter: "1" は初回起動であることを示しています。policyMeasurements には PCR_0（ファームウェアコンポーネント）と PCR_7（Secure Boot ポリシー）の2エントリのみ含まれています。Linux の初回起動では Early Boot のベースラインはこの2つの PCR から構成されます。一方 actualMeasurements には PCR_0〜PCR_7 の8エントリが含まれており、PCR_0 と PCR_7 の値が policyMeasurements と一致していることで整合性が確認できます。
lateBootReportEvent の検証結果です。
{
"insertId": "2",
"jsonPayload": {
"lateBootReportEvent": {
"policyMeasurements": [
{
"hashAlgo": "SHA1",
"pcrNum": "PCR_0",
"value": "0KUbR/mg3+8bwW0xjQtbxWh/1gI="
},
{
"pcrNum": "PCR_4",
"hashAlgo": "SHA1",
"value": "k0Fqp/nPMwgtIujHdIdMnOfypdo="
},
{
"value": "OS0YbqjyN8FioheRVQCNf+cQwdU=",
"pcrNum": "PCR_7",
"hashAlgo": "SHA1"
}
],
"actualMeasurements": [
{
"value": "0KUbR/mg3+8bwW0xjQtbxWh/1gI=",
"hashAlgo": "SHA1",
"pcrNum": "PCR_0"
},
{
"value": "VdWbJrtJtrG8VMMtdzaFcnOsBWs=",
"hashAlgo": "SHA1",
"pcrNum": "PCR_1"
},
{
"hashAlgo": "SHA1",
"pcrNum": "PCR_2",
"value": "sqg7Dr8vg3Qpmlsr38MeqVWtcjY="
},
{
"value": "sqg7Dr8vg3Qpmlsr38MeqVWtcjY=",
"pcrNum": "PCR_3",
"hashAlgo": "SHA1"
},
{
"pcrNum": "PCR_4",
"hashAlgo": "SHA1",
"value": "k0Fqp/nPMwgtIujHdIdMnOfypdo="
},
{
"hashAlgo": "SHA1",
"pcrNum": "PCR_5",
"value": "KIanvtYAeoPvIh6AWCfn5902hSE="
},
{
"pcrNum": "PCR_6",
"hashAlgo": "SHA1",
"value": "sqg7Dr8vg3Qpmlsr38MeqVWtcjY="
},
{
"value": "OS0YbqjyN8FioheRVQCNf+cQwdU=",
"hashAlgo": "SHA1",
"pcrNum": "PCR_7"
},
{
"hashAlgo": "SHA1",
"pcrNum": "PCR_8",
"value": "rBqzrJppUQnsP31OknqZWtP/CKE="
},
{
"pcrNum": "PCR_9",
"hashAlgo": "SHA1",
"value": "sLQZyOTkZb8R3GoG7zeT2+Dx1bs="
},
{
"pcrNum": "PCR_14",
"hashAlgo": "SHA1",
"value": "WLYQJjVM+fAOvfVZ2O0Km8MWa9M="
}
],
"policyEvaluationPassed": true
},
"bootCounter": "1",
"@type": "type.googleapis.com/cloud_integrity.IntegrityEvent"
},
"resource": {
"type": "gce_instance",
"labels": {
"project_id": "PROJECT_ID",
"instance_id": "INSTANCE_ID",
"zone": "asia-northeast1-a"
}
},
"timestamp": "2026-07-12T20:38:55.033315258Z",
"severity": "NOTICE",
"logName": "projects/PROJECT_ID/logs/compute.googleapis.com%2Fshielded_vm_integrity",
"receiveTimestamp": "2026-07-12T20:38:57.048236281Z"
}
こちらも policyEvaluationPassed: true で検証合格しています。Late Boot の policyMeasurements は PCR_0・PCR_4（UEFI ブートマネージャコード）・PCR_7 の3エントリで構成されており、Early Boot より測定対象が増えています。actualMeasurements は PCR_0〜PCR_9 および PCR_14 の11エントリとなっており、OS カーネルやドライバのロードを含むより広範な測定が行われていることがわかります。また、earlyBootReportEvent のタイムスタンプ（20:38:42）と lateBootReportEvent（20:38:55）の差は約13秒で、ブートローダーから OS カーネル起動完了までにかかった時間に相当します。
整合性モニタリングのCloud Loggingに記録される各イベントについての詳細なイベントについては、公式ドキュメントを確認してください。
3. 整合性ポリシーベースラインを更新する
カーネルアップデートなどの計画的な変更後は、ベースラインを更新します。インスタンスが起動中の状態で実行してください。
整合性ポリシーベースラインを更新しないと次回起動時に整合性検証が失敗してしまいます。
gcloud compute instances update my-shielded-vm \
--zone=asia-northeast1-a \
--shielded-learn-integrity-policy
Setting shieldedInstanceIntegrityPolicy of instance [my-shielded-vm]...done.
4. Cloud Monitoring でブート整合性を確認する
Cloud Monitoring の Metrics Explorer を使うと、ブート整合性の合否をメトリクスとして可視化できます。
- Google Cloud コンソールで [Metrics Explorer] を開く
- [Metric] の [Select a metric] メニューを展開し、フィルタバーに
Boot Validationと入力する - サブメニューで以下を選択する
- Active resources:
VM instance - Active metric categories:
Instance - Active metrics:
Early Boot ValidationまたはLate Boot Validation
- Active resources:
- [Apply] をクリックする
| メトリクス | 内容 |
|---|---|
| Early Boot Validation | UEFI ファームウェア開始からブートローダーへの制御移譲までの検証結果 |
| Late Boot Validation | ブートローダーから OS カーネルロード完了までの検証結果 |
Metrics Explorerでのブート整合性の合否の可視化
ツールチップに early_boot_validation_status: 1 / late_boot_validation_status: 1 と表示されており、値 1 が検証合格（pass）を意味します。グラフにはインスタンス起動のタイミングに合わせて1点のデータポイントのみ記録されており、このメトリクスが起動時にのみ計測されることが確認できます。
組織全体への適用（Organization Policy）
組織内のすべての Compute Engine VM に Shielded VM を強制するには、Organization Policy の制約を使用します。
constraints/compute.requireShieldedVm
この制約を True に設定することで、組織内で作成されるすべての Compute Engine VM インスタンスが Shielded VM である必要があります。
まとめ
Shielded VM は、Compute Engine VM のブートシーケンスをファームウェアレベルから保護・監視するセキュリティ機能セットです。
vTPM と Integrity Monitoring はデフォルトで有効になっており、Shielded VM 対応イメージを使うだけでブート整合性の記録と監視が自動的に開始されます。Secure Boot を追加で有効化すると、署名されていないブートコンポーネントの実行を拒否し、ルートキットやブートキットによる持続的な侵害をブートレベルで防止できます。また、Organization Policy と組み合わせることで、組織全体の Compute Engine VM に Shielded VM を強制適用し、セキュリティベースラインを統一的に管理できます。
一方で、いくつかの点に注意が必要です。Secure Boot を有効にすると、GPU ドライバやセキュリティ監視ツールなど署名されていないカーネルモジュールが動作しなくなる場合があるため、事前にテスト環境で確認してください。また、カーネルアップデートやドライバのインストールなど計画的な変更後は、整合性ポリシーベースラインを更新しないと次回起動時に整合性検証が失敗するため忘れずに実施してください。
セキュリティ要件の高い環境や、コンプライアンス対応が必要なシステムを Compute Engine 上で運用されている方は、Shielded VM の有効化を検討してみてはいかがでしょうか。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部コンサルティング部の渡邉でした！
