カスタムのシールドされたイメージの作成

このトピックでは、ディスクの準備、セキュリティ証明書の生成、必要なオペレーティングシステム（OS）の機能の有効化を行い、カスタムシールドイメージを作成する方法について説明します。

Shielded VM はデフォルトで、Container-Optimized OS、Linux のさまざまなディストリビューション、および複数のバージョンの Windows Server をサポートしています。アプリケーションにカスタムイメージが必要な場合でも、Shielded VM を活用できます。

ディスクの準備

Shielded VM は、セキュアブートなどの機能をサポートするために、Unified Extensible Firmware Interface（UEFI）に準拠したファームウェアを使用します。Shielded VM に必要なのは、GUID パーティションテーブル（GPT）です。マスターブートレコード（MBR）はサポートされていません。

ディスクには少なくとも次の 2 つのパーティションが必要です。

EFI システムパーティション（ESP）: このパーティションは 100 MB あれば十分で、これは提案にすぎません。必要に応じて、より大きなパーティションを作成できます。ESP の要件は、ファイル割り当てテーブル（FAT）ファイルシステムを使用してフォーマットすることだけです。
OS パーティション: 残りのディスク。このパーティションにはブート OS（Linux または Windows）が含まれます。このパーティションのサイズに上限はありません。

必要に応じて、追加のデータパーティションを作成できます。

OS を OS パーティションにコピーする

ディスクが正しくフォーマットされて、分割されたら、OS ファイルを OS パーティションにコピーします。OS には、UEFI 仕様 \EFI\Boot\bootx64.efi で指定されているとおり、ESP 上の有効なパスにブートローダーが配置されている必要があります。指定された場所に OS ブートローダーをコピーする必要がある場合がありますので、注意してください。

Windows の場合は、Windows に必要な他のアクション（BCD ストアのコピーなど）に加えて、OS ブートローダーを正しい場所にコピーするための bcdboot というコマンドがあります。詳細については、Microsoft Hardware Dev Center の BCDBoot コマンドラインオプションをご覧ください。

Shielded VM イメージを使用する場合は、仮想トラステッドプラットフォームモジュール（vTPM）と整合性モニタリングの 2 つの追加のセキュリティ機能も利用できます。以下のセクションでは、これらの機能のメリットと OS の要件について説明します。

仮想トラステッドプラットフォームモジュール（vTPM）

トラステッドプラットフォームモジュールは、システムへのアクセスを認証するために使用するキーや、証明書などのオブジェクトを保護する特別なデバイスです。Shielded VM イメージでは、仮想化バージョンの TPM デバイスを使用してメジャードブートを有効にします。つまり、メジャードブートは、ブートドライバとカーネルドライバのクリティカルロードパスの整合性を保証します。vTPM とメジャードブートについての詳細は、Shielded VM のドキュメントをご覧ください。

vTPM とメジャードブートを利用するには、ドライバが必要です。TPM 2.0 をサポートする最小 OS バージョンは次のとおりです。

Windows Server 2012
Linux バージョン 3.20
Red Hat Enterprise Linux 7.3

整合性モニタリング

整合性のモニタリングには、VM インスタンスの状態を理解し、判断する方法が用意されています。Monitoring は、メジャードブートによって生成されたデータを使用して VM インスタンスのレポートを作成します。Shielded VM のドキュメントには、整合性モニタリングと整合性検証の失敗に対するレスポンスの自動化についての詳細が記載されています。

Shielded VM 整合性モニタリング機能をサポートするには、イメージで整合性シグナルを生成する必要があります。

Windows はデフォルトで整合性シグナルを生成します。
Linux では、Integrity Measurement Architecture（IMA）モジュールをインストールして有効にする必要があります。このモジュールの CONFIG_IMA_MEASURE_PCR_IDX を 10 に設定する必要があります。これは、IMA モジュールのデフォルト値です。

ディスクイメージを Compute Engine にインポートする

イメージの準備ができたら、イメージを Compute Engine にアップロードする必要があります。イメージを Google Cloud にアップロードするために必要な手順については、ブートディスクイメージを Compute Engine にインポートするをご覧ください。

セキュアブートの証明書の設定

Shielded VM イメージを追加すると、セキュアブートの公開証明書とデータベースのセットが Compute Engine に渡されます。これらのファイルは対応する UEFI 変数に格納され、プラットフォーム、ファームウェア、OS 間の信頼関係を確立するために使用されます。証明書は、識別符号化規則（DER）でエンコードされた X.509 証明書です。データベースは証明書または未加工のバイナリのいずれかです。全部で次の 4 つの値があります。

Platform Key（pk）: プラットフォームオーナーとファームウェア間の信頼関係を確立するために使用される鍵。指定できるプラットフォーム鍵は 1 つだけです。有効な X.509 証明書である必要があります。
Key Exchange Key（kek）: ファームウェアと OS の間の信頼関係を確立するために使用する鍵。この値には複数の鍵を指定できます。
禁止キーデータベース（dbx）: 取り消された証明書のデータベース。この中の証明書でブートファイルが署名されている場合は、システムが起動を停止します。この値には、1 つまたは複数の値を指定できます。
Key Database（db）: 信頼できる証明書のデータベース。ブートファイルへの署名に使用されます。この値には、1 つまたは複数の値を指定できます。

これらの値とその仕組みについての詳細は、UEFI 仕様をご覧ください。

次の例では、OpenSSL を使用してセキュアブート鍵と証明書を作成します。

2,048 ビットの RSA 鍵ペアを生成します。
```
  $ openssl genrsa -out secure-boot-key.rsa 2048
```

自己署名された X.509 証明書を鍵から DER 形式で生成する。

  $ openssl req -new -x509 -sha256 -subj '/CN=secure-boot' -key secure-boot-key.rsa
  -outform DER -out secure-boot-cert.pem

シールドされたイメージを Google Cloud に追加する

アップロードされたイメージと証明書を使用して、Compute Engine にイメージを追加できるようになりました。イメージは、Google Cloud CLI または Compute Engine API を使用して追加できます。

gcloud

Compute Engine にカスタムイメージを追加します。

gcloud compute images create [IMAGE_NAME] \
--source-disk [SOURCE_DISK] \
--source-disk-zone [ZONE] \
--platform-key-file=<file.der> \
--key-exchange-key-file=<file.der> \
--signature-database-file=<file.bin>,<file.der> \
--forbidden-database-file=<file.bin> \
--guest-os-features="UEFI_COMPATIBLE[,WINDOWS]"

ここで

[IMAGE_NAME] は、新しいイメージの名前です。
[SOURCE_DISK] は、新しいイメージを作成するディスクです。
[ZONE] は、ディスクが配置されているゾーンです。

guest-os-features の WINDOWS オプションは、Windows イメージを使用する場合のみ必要です。イメージ作成の詳細については、gcloud create リファレンスをご覧ください。

API

手順に沿って永続ディスクからイメージを作成しますが、リクエスト本文には initial_state_config を指定します。

...
"sourceDisk": "/zones/[ZONE]/disks/[SOURCE_DISK]",

"initial_state_config": {
    "pk": {
        "content": [KEY],
        "fileType": [BIN,X509]
    },
    "keks": [
        {
            "content": [KEY],
            "fileType": [BIN,X509]
        },
        ...
    ],
    "dbxs": [
        {
            "content": [KEY],
            "fileType": [BIN,X509]
        },
        ...
    ],
    "dbs": [
        {
            "content": [KEY],
            "fileType": [BIN,X509]
        },
        ...
    ]
}

デフォルトの証明書

pk、keks、dbxs、dbs は、オプションフィールドです。初期状態の構成を指定すると、これらのフィールドの一部またはすべての設定が解除されることがあります。イメージから新しいインスタンスが作成される際は、未設定のフィールドにカスタム値が設定されていなければ、Google Cloud は PK、KEK、db、dbx のデフォルト値を指定します。初期状態の構成を指定しない場合（つまり、構成がただ空ではなく、省略されている場合）、イメージにはソースイメージの初期状態の構成が含まれます。

これらのフィールドのデフォルト値は、次のとおりです。

PK: Google が作成したデフォルトの秘密鍵に関連付けられた証明書。
KEK: デフォルトの Microsoft KEK 証明書。Microsoft からダウンロードします（MicCorKEKCA2011_2011-06-24.crt）。
dbx: デフォルトの Microsoft DBX 取り消しリスト。Unified Extensible Firmware Interface フォーラムからダウンロードします（UEFI 取り消しリストファイル）。
db: 次の 2 つの証明書。
- SHA-1 証明書ハッシュ（58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d）を持つ Microsoft Windows Production PCA 2011。Microsoft からダウンロードします（MicWinProPCA2011_2011-10-19.crt）。
- SHA-1 証明書ハッシュ（46 de f6 3b 5c e6 1c f8 ba 0d e2 e6 63 9c 10 19 d0 ed 14 f3）を持つ Microsoft Corporation UEFI CA 2011。Microsoft からダウンロードします（MicCorUEFCA2011_2011-06-27.crt）。

独自の証明書を追加すると、指定した証明書と統合されるのではなく、デフォルトの証明書が上書きされますので、注意してください。