Benutzerdefinierte Shielded Images erstellen

In diesem Thema wird beschrieben, wie Sie das Laufwerk vorbereiten, Sicherheitszertifikate generieren und alle erforderlichen Betriebssystemfeatures aktivieren, um ein benutzerdefiniertes Shielded Image zu erstellen.

Standardmäßig unterstützt Shielded VM Container-Optimized OS, verschiedene Linux-Distributionen und mehrere Versionen von Windows Server. Wenn Sie jedoch benutzerdefinierte Images für Ihre Anwendung benötigen, können Sie trotzdem die Vorteile von Shielded VM nutzen.

Hinweis: Eine vollständige Liste der von Shielded VM unterstützten Betriebssysteme finden Sie unter Images mit Shielded VM-Unterstützung.

Laufwerk vorbereiten

Shielded VM benötigt zur Unterstützung von Funktionen wie Secure Boot eine Unified Extensible Firmware Interface (UEFI)-konforme Firmware. Shielded VM erfordert ein GPT-Schema (GUID Partition Table). Master Boot Record (MBR) wird nicht unterstützt.

Das Laufwerk muss mindestens zwei Partitionen haben:

• DFI-Systempartition (ESP): 100 Megabyte (MB) sind für diese Partition ausreichend und nur ein Vorschlag. Bei Bedarf können Sie eine größere Partition erstellen. Die einzige Voraussetzung für den ESP ist, dass er mit einem FAT-Dateisystem (File Allocation Table) formatiert werden muss.
• Betriebssystempartition:Der Rest des Laufwerks. Diese Partition enthält das Bootbetriebssystem (Linux oder Windows). Die Größe dieser Partition ist nicht beschränkt.

Sie können bei Bedarf weitere Datenpartitionen erstellen.

Betriebssystem in die Betriebssystempartition kopieren

Sobald das Laufwerk korrekt formatiert und partitioniert ist, kopieren Sie die Betriebssystemdateien in die Betriebssystempartition. Das Betriebssystem verfügt über einen Bootloader, der sich in einem gültigen Pfad auf dem ESP befinden muss, wie in der Android-Spezifikation angegeben: \EFI\Boot\bootx64.efi. Beachten Sie, dass der Bootloader des Betriebssystems möglicherweise an den angegebenen Speicherort kopiert werden muss.

Unter Windows gibt es den Befehl bcdboot, mit dem der Bootloader des Betriebssystems an den richtigen Speicherort kopiert werden kann, sowie andere Aktionen, die Windows benötigt (z. B. den BCD-Speicher kopieren). Weitere Informationen finden Sie im Microsoft Hardware Dev Center unter BCDBoot-Befehlszeilenoptionen.

Wenn Sie Shielded VM-Images verwenden, können Sie auch zwei zusätzliche Sicherheitsfunktionen nutzen: Virtual Trusted Platform Module (vTPM) und Integritätsüberwachung. In den folgenden Abschnitten werden die Vorteile dieser Funktionen und die Betriebssystemanforderungen beschrieben.

Virtual Trusted Platform Module (vTPM)

Ein Trusted Platform Module ist ein spezielles Gerät zum Schutz von Objekten wie Schlüsseln und Zertifikaten, mit denen Sie den Zugriff auf Ihr System authentifizieren. Auf Shielded VM-Images werden virtualisierte Versionen von TPM-Geräten verwendet, um den gemessenen Start zu aktivieren. Kurz gesagt: Measured Boot gewährleistet die Integrität des kritischen Ladepfads von Boot- und Kerneltreibern. Weitere Informationen zu vTPM und Gemessenem Start finden Sie in der Dokumentation zu Shielded VM.

Zur Nutzung von vTPM und Measured Boot ist ein Treiber erforderlich. Folgende Betriebssystemversionen müssen mindestens TPM 2.0 unterstützen:

• Windows Server 2012
• Linux-Version 3.20
• Red Hat Enterprise Linux 7.3

Integritätsmonitoring

Da Integritätsmonitoring hilft Ihnen, den Zustand Ihrer VM-Instanzen zu verstehen und entsprechende Entscheidungen zu treffen. Monitoring verwendet die von Measured Boot generierten Daten, um Berichte über die VM-Instanz zu erstellen. Die Shielded VM-Dokumentation enthält weitere Informationen zum Integritätsmonitoring und zur Automatisierung von Antworten auf Fehler bei der Integritätsprüfung.

Zur Unterstützung des Integritätsmonitoring von Shielded VM muss das Image Integritätssignale erzeugen:

• Windows generiert standardmäßig Integritätssignale.
• Unter Linux muss das IMA-Modul installiert und aktiviert sein. Für das Modul muss CONFIG_IMA_MEASURE_PCR_IDX auf 10 gesetzt sein. Dies ist der Standardwert für das IMA-Modul.

Laufwerk-Images in Compute Engine importieren

Sobald das Image vorbereitet ist, müssen Sie es in Compute Engine hochladen. Die erforderlichen Schritte zum Hochladen des Images in Google Cloud finden Sie unter Bootlaufwerk-Images in Compute Engine importieren.

Warnung: Wenn Sie das obige Importdokument verwenden, importieren Sie die Image-Datei nicht in Ihre benutzerdefinierte Bilderliste. Für Shielded VM sind die unten aufgeführten zusätzlichen Schritte und Argumente erforderlich.

Zertifikate für Secure Boot einrichten

Wenn Sie ein Shielded VM-Image hinzufügen, werden eine Reihe öffentlicher Secure Boot-Zertifikate und -Datenbanken an Compute Engine übergeben. Diese Dateien werden in den entsprechenden UEFI-Variablen gespeichert und verwendet, um Vertrauensstellungen zwischen Plattform, Firmware und Betriebssystem herzustellen. Zertifikate sind X.509-Zertifikate, die mit Distinguished Encoding-Regeln (DER) codiert sind. Die Datenbanken können entweder ein Zertifikat oder eine binäre Binärdatei sein. Es gibt insgesamt vier Werte:

• Platform Key (pk): Ein Schlüssel, mit dem die Vertrauensstellung zwischen dem Plattforminhaber und der Firmware hergestellt wird. Sie können nur einen Plattformschlüssel angeben. Dabei muss es sich um ein gültiges X.509-Zertifikat handeln.
• Schlüsselaustauschschlüssel (kek): Ein Schlüssel, mit dem eine Vertrauensstellung zwischen der Firmware und dem Betriebssystem hergestellt wird. Sie können mehrere Schlüssel für diesen Wert angeben.
• Forbidden Key Database (dbx): Eine Datenbank mit Zertifikaten, die widerrufen wurden und das System nicht mehr startet, wenn eine Bootdatei mit einem dieser signiert ist. Sie können einen oder mehrere Werte für diesen Wert angeben.
• Key Database (db): Eine Datenbank mit vertrauenswürdigen Zertifikaten, die zum Signieren von Bootdateien verwendet werden können. Sie können einen oder mehrere Werte für diesen Wert angeben.

Weitere Informationen zu diesen Werten und ihrer Funktionsweise finden Sie in der UEFI-Spezifikation.

Im folgenden Beispiel wird OpenSSL verwendet, um die Secure Boot-Schlüssel und -Zertifikate zu erstellen.

• Generieren Sie ein 2048-Bit-RSA-Schlüsselpaar.

    $ openssl genrsa -out secure-boot-key.rsa 2048
  

• Generieren Sie ein selbstsigniertes X.509-Zertifikat aus dem Schlüssel im DER-Format

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

Schutzschild in Google Cloud hinzufügen

Mithilfe des hochgeladenen Images und der Zertifikate können Sie das Image jetzt Compute Engine hinzufügen. Das Image kann über das Google Cloud CLI oder die Compute Engine API hinzugefügt werden.

gcloud

Fügen Sie Compute Engine das benutzerdefinierte Image hinzu:

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]"

wobei

• [IMAGE_NAME] ist der Name für das neue Image.
• [SOURCE_DISK] ist das Laufwerk, von dem Sie das neue Image erstellen möchten.
• [ZONE] ist die Zone, in der sich das Laufwerk befindet.

Die Option WINDOWS für guest-os-features ist nur erforderlich, wenn Sie ein Windows-Image verwenden. Weitere Informationen zum Erstellen eines Images finden Sie in der gcloud create-Referenz.

API

Folgen Sie der Anleitung zum Erstellen eines Images von einem nichtflüchtigen Speicher. Geben Sie dabei aber initial_state_config im Anfragetext an.

...
"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]
        },
        ...
    ]
}

Standardzertifikate

Beachten Sie, dass pk, keks, dbxs und dbs optionale Felder sind. Wenn Sie eine anfängliche Statuskonfiguration angeben, sind einige oder alle dieser Felder möglicherweise nicht festgelegt. Wenn eine neue Instanz aus dem Image erstellt wird, stellt Google Cloud einen Standardwert für PK, KEK, db und dbx bereit, sofern für kein nicht festgelegtes Feld ein benutzerdefinierter Wert festgelegt wurde. Wenn Sie keine anfängliche Statuskonfiguration angeben (d. h. die Konfiguration fehlt oder ist nicht nur leer), hat das Image die ursprüngliche Statuskonfiguration des Quell-Images.

Die Standardwerte dieser Felder sind:

• PK: Das Zertifikat, das dem von Google erstellten privaten Standardschlüssel zugeordnet ist.
• KEK: Das standardmäßige Microsoft KEK-Zertifikat. Von Microsoft herunterladen: MicCorKEKCA2011_2011-06-24.crt
• dbx: Die standardmäßige Microsoft DBX-Sperrliste. Download aus dem Forum der Unified Extensible Firmware Interface: Datei der UEFI-Sperrliste
• db: Die beiden folgenden Zertifikate:
  • Das Microsoft Windows-Produktions-PCA 2011 mit einem SHA-1-Zertifikats-Hash von 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d. Von Microsoft herunterladen: MicWinProPCA2011_2011-10-19.crt
  • The Microsoft Corporation UEFI CA 2011 mit einem SHA-1 Certificate Hash von 46 de f6 3b 5c e6 1c f8 ba 0d e2 e6 63 9c 10 19 d0 ed 14 f3. Von Microsoft herunterladen: MicCorUEFCA2011_2011-06-27.crt

Seien Sie dabei vorsichtig, denn wenn Sie Ihre eigenen Zertifikate hinzufügen, werden die Standardzertifikate überschrieben, anstatt sie mit den von Ihnen angegebenen Zertifikaten zusammenzuführen.