Creazione di immagini schermate personalizzate

Questo argomento descrive come preparare il disco, generare certificati di sicurezza e abilitare eventuali funzionalità del sistema operativo necessarie per creare un'immagine schermata personalizzata.

Per impostazione predefinita, la Shielded VM supporta Container-Optimized OS, varie distribuzioni di Linux e più versioni di Windows Server. Tuttavia, se richiedi immagini personalizzate per la tua applicazione, puoi comunque sfruttare la Shielded VM.

Nota: per l'elenco completo dei sistemi operativi supportati dalla Shielded VM, consulta Immagini con supporto per Shielded VM.

Preparazione del disco

La Shielded VM si basa su un firmware conforme a Unified Extensible Firmware Interface (UEFI) per supportare funzionalità come l'avvio protetto. La Shielded VM richiede uno schema GPT (GUID Partition Table); il record di avvio principale (MBR) non è supportato.

Il disco deve avere almeno due partizioni:

• EFI System Partition (ESP): 100 megabyte (MB) sono sufficienti per questa partizione e rappresenta solo un suggerimento. Puoi creare una partizione più grande, se necessario. L'unico requisito per l'ESP è che deve essere formattato con un file system FAT (File Usage Table).
• Partizione del sistema operativo: il resto del disco. Questa partizione contiene il sistema operativo di avvio (Linux o Windows). Non sono previste limitazioni alle dimensioni di questa partizione.

Se necessario, puoi creare più partizioni di dati.

Copia del sistema operativo nella partizione del sistema operativo

Dopo aver formattato e partizionato correttamente il disco, copia i file del sistema operativo nella partizione del sistema operativo. Il sistema operativo ha un bootloader che deve trovarsi in un percorso valido sull'ESP, come specificato nella specifica UEFI: \EFI\Boot\bootx64.efi. Tieni presente che potrebbe essere necessario copiare il bootloader del sistema operativo nella posizione specificata.

Per Windows, esiste il comando bcdboot che può essere utilizzato per copiare il bootloader del sistema operativo nella posizione corretta, oltre alle altre azioni richieste da Windows (come la copia dell'archivio BCD). Per ulteriori informazioni, consulta la pagina relativa alle opzioni a riga di comando BCDBoot nell'Hardware Dev Center di Microsoft.

Quando utilizzi le immagini Shielded VM, puoi sfruttare due funzionalità di sicurezza aggiuntive: il Virtual Trusted Platform Module (vTPM) e il monitoraggio dell'integrità. Le sezioni seguenti descrivono i vantaggi di queste funzionalità e i requisiti del sistema operativo.

Virtual Trusted Platform Module (vTPM)

Un modulo piattaforma attendibile è un dispositivo specializzato per proteggere oggetti, come chiavi e certificati, utilizzati per autenticare l'accesso al sistema. Sulle immagini Shielded VM, le versioni virtualizzate dei dispositivi TPM vengono utilizzate per abilitare l'avvio con misurazioni. In breve, l'avvio con misurazioni garantisce l'integrità del percorso di caricamento critico dei driver di avvio e del kernel. vTPM e Avvio con misurazioni sono trattati in modo più dettagliato nella documentazione relativa alle VM schermate.

Per poter utilizzare vTPM e l'avvio con misurazioni, è richiesto un driver. Le versioni minime del sistema operativo con supporto per TPM 2.0 sono:

• Windows Server 2012
• Linux versione 3.20
• Red Hat Enterprise Linux 7.3

Monitoraggio dell'integrità

Il monitoraggio dell'integrità consente di comprendere e prendere decisioni sullo stato delle istanze VM. Monitoring utilizza i dati generati da Avvio con misurazioni per generare report sull'istanza VM. La documentazione delle Shielded VM contiene ulteriori informazioni sul monitoraggio dell'integrità e sull'automazione delle risposte a errori di convalida dell'integrità.

Per supportare la funzionalità di monitoraggio dell'integrità della Shielded VM, l'immagine deve produrre indicatori di integrità:

• Windows genera indicatori di integrità per impostazione predefinita.
• Su Linux deve essere installato e abilitato il modulo IMA (Integrity Measurement Architecture). Il modulo deve avere CONFIG_IMA_MEASURE_PCR_IDX impostato su 10. Questo è il valore predefinito per il modulo IMA.

Importazione dell'immagine disco in Compute Engine

Una volta preparata l'immagine, devi caricarla in Compute Engine. Per i passaggi necessari per caricare l'immagine in Google Cloud, consulta Importazione delle immagini del disco di avvio in Compute Engine.

Avviso: se utilizzi il documento di importazione riportato sopra, non importare il file immagine nell'elenco di immagini personalizzate. La Shielded VM richiede i passaggi e gli argomenti aggiuntivi mostrati di seguito.

Configurazione dei certificati per l'avvio protetto

Quando aggiungi un'immagine Shielded VM, un set di certificati e database di avvio protetto vengono trasferiti in Compute Engine. Questi file vengono archiviati nelle variabili UEFI corrispondenti e utilizzati per stabilire relazioni di attendibilità tra piattaforma, firmware e sistema operativo. I certificati sono certificati X.509 con codifica DER (Distinguiped Encoding Rules). I database possono essere un certificato o un programma binario non elaborato. In totale ci sono quattro valori:

• Chiave della piattaforma (pk): una chiave utilizzata per stabilire la relazione di attendibilità tra il proprietario della piattaforma e il firmware. Puoi specificare una solo chiave della piattaforma, che deve essere un certificato X.509 valido.
• Chiave di scambio della chiave (kek): una chiave utilizzata per stabilire una relazione di attendibilità tra il firmware e il sistema operativo. Puoi specificare più chiavi per questo valore.
• Forbidden Key Database (dbx): un database di certificati che sono stati revocati e che causerà l'interruzione dell'avvio del sistema se un file di avvio è firmato con uno di questi. Puoi specificare uno o più valori per questo valore.
• Database di chiavi (db): un database di certificati attendibili e che può essere utilizzato per firmare i file di avvio. Puoi specificare uno o più valori per questo valore.

La specifica UEFI contiene ulteriori informazioni su questi valori e sul loro funzionamento.

Nel seguente esempio, OpenSSL viene utilizzato per creare chiavi e certificati di avvio protetto.

• Genera una coppia di chiave RSA a 2048 bit

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

• Genera un certificato X.509 autofirmato dalla chiave in formato DER

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

Aggiunta dell'immagine schermata a Google Cloud

Utilizzando l'immagine e i certificati caricati, ora puoi aggiungere l'immagine a Compute Engine. L'immagine può essere aggiunta utilizzando Google Cloud CLI o l'API Compute Engine.

gcloud

Aggiungi l'immagine personalizzata a 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]"

dove:

• [IMAGE_NAME] è il nome della nuova immagine.
• [SOURCE_DISK] è il disco da cui vuoi creare la nuova immagine.
• [ZONE] è la zona in cui si trova il disco.

L'opzione WINDOWS per guest-os-features è obbligatoria solo se si utilizza un'immagine Windows. Per ulteriori informazioni sulla creazione di un'immagine, consulta il riferimento gcloud create.

API

Segui le istruzioni per creare un'immagine da un disco permanente, ma specifica il initial_state_config nel corpo della richiesta.

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

Certificati predefiniti

Tieni presente che pk, keks, dbxs e dbs sono campi facoltativi. Se fornisci una configurazione dello stato iniziale, alcuni o tutti questi campi potrebbero non essere impostati. Quando viene creata una nuova istanza dall'immagine, Google Cloud fornisce un valore predefinito per PK, KEK, db e dbx, a meno che non sia stato impostato un valore personalizzato in un campo non impostato. Se non fornisci una configurazione dello stato iniziale (ovvero la configurazione è mancante, non solo vuota), l'immagine avrà la configurazione dello stato iniziale dell'immagine di origine.

I valori predefiniti di questi campi sono:

• PK: il certificato associato alla chiave privata predefinita creata da Google.
• KEK: il certificato KEK di Microsoft predefinito. Scarica da Microsoft: MicCorKEKCA2011_2011-06-24.crt.
• dbx: l'elenco di revoche predefinito di Microsoft DBX. Scarica dal forum di Unified Extensible Firmware Interface: file elenco revoche UEFI
• db: i seguenti due certificati:
  • Microsoft Windows Production PCA 2011 con un hash di certificazione SHA-1 di 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d. Scarica da Microsoft: MicWinProPCA2011_2011-10-19.crt.
  • UEFI CA 2011 di Microsoft Corporation con un hash del certificato SHA-1 di 46 de f6 3b 5c e6 1c f8 ba 0d e2 e6 63 9c 10 19 d0 ed 14 f3. Scarica da Microsoft: MicCorUEFCA2011_2011-06-27.crt.

Fai attenzione, poiché l'aggiunta di certificati personali sovrascriverà quelli predefiniti anziché unirli a quelli forniti da te.