Como criar imagens protegidas e personalizadas

Neste tópico, descrevemos como preparar o disco, gerar certificados de segurança e ativar todos os recursos necessários do sistema operacional (SO) para criar uma imagem protegida personalizada.

Por padrão, a VM protegida é compatível com o Container-Optimized OS, várias distribuições do Linux e várias versões do Windows Server. No entanto, se você precisar de imagens personalizadas para seu aplicativo, ainda poderá aproveitar a VM protegida.

Observação: para ver a lista completa de sistemas operacionais compatíveis com VM protegida, consulte Imagens com suporte a VM protegida.

Como preparar o disco

A VM protegida depende de um firmware compatível com a Unified Extensible Firmware Interface (UEFI) para oferecer suporte a recursos como a inicialização segura. A VM protegida requer um esquema de tabela de partição GUID (GPT); O registro mestre de inicialização (MBR) não é compatível.

O disco precisa ter pelo menos duas partições:

• EFI System Partition (ESP): 100 megabytes (MB) são suficientes para essa partição e são apenas uma sugestão. Você pode criar uma partição maior, se necessário. O único requisito para o ESP é que ele seja formatado com um sistema de arquivos da tabela de alocação de arquivos (FAT, na sigla em inglês).
• Partição do SO: o restante do disco. Essa partição contém o SO de inicialização (Linux ou Windows). Não há restrições quanto ao tamanho dessa partição.

Você pode criar mais partições de dados conforme necessário.

Como copiar o SO para a partição do SO

Depois que o disco for formatado e particionado corretamente, copie os arquivos do SO para a partição do SO. O SO tem um carregador de inicialização que precisa estar localizado em um caminho válido no ESP, conforme especificado na especificação UEFI: \EFI\Boot\bootx64.efi. Pode ser necessário copiar o carregador de inicialização do SO para o local especificado.

No Windows, há um comando chamado bcdboot que pode ser usado para copiar o carregador de inicialização do SO para o local correto, além de outras ações exigidas pelo Windows (como copiar o armazenamento do BCD). Para mais informações, consulte Opções de linha de comando do BCDBoot no Microsoft Hardware Dev Center.

Ao usar imagens de VM protegidas, você também pode aproveitar dois recursos de segurança adicionais: Módulo de plataforma confiável virtual (vTPM) e monitoramento de integridade. As seções a seguir descrevem os benefícios desses recursos e os requisitos do sistema operacional.

Módulo de plataforma confiável virtual (vTPM)

Um módulo de plataforma confiável é um dispositivo especializado para proteger objetos, como chaves e certificados, que você usa para autenticar o acesso ao sistema. Nas imagens de VM protegidas, as versões virtualizadas dos dispositivos TPM são usadas para ativar a Inicialização medida. Em resumo, a Inicialização medida garante a integridade do caminho de carregamento crítico dos drivers de inicialização e kernel. O vTPM e a Inicialização medida são abordados em mais detalhes na documentação da VM protegida.

Para aproveitar o vTPM e a inicialização medida, é necessário um driver. As versões mínimas do SO compatíveis com o TPM 2.0 são:

• Windows Server 2012
• Versão 3.20 para Linux
• Red Hat Enterprise Linux 7.3

Monitoramento da integridade

O monitoramento de integridade oferece uma maneira de entender e tomar decisões sobre o estado das instâncias de VM. O Monitoring usa os dados gerados pela Inicialização medida para gerar relatórios sobre a instância de VM. A documentação da VM protegida tem mais informações sobre monitoramento de integridade e como automatizar respostas a falhas de validação de integridade.

Para oferecer suporte ao recurso de monitoramento de integridade da VM protegida, a imagem precisa produzir sinais de integridade:

• O Windows gera sinais de integridade por padrão.
• O Linux precisa ter o módulo Arquitetura de avaliação de integridade (IMA) instalado e ativado. O módulo precisa ter CONFIG_IMA_MEASURE_PCR_IDX definido como 10. Este é o valor padrão para o módulo IMA.

Como importar a imagem de disco para o Compute Engine

Quando a imagem estiver preparada, será necessário fazer o upload dela para o Compute Engine. Para ver as etapas necessárias para fazer upload da imagem no Google Cloud, consulte Como importar imagens de disco de inicialização para o Compute Engine.

Aviso: ao usar o documento de importação acima, não importe o arquivo de imagem para sua lista de imagens personalizadas. A VM protegida requer as etapas e os argumentos adicionais mostrados abaixo.

Como configurar certificados para inicialização segura

Ao adicionar uma imagem de VM protegida, um conjunto de certificados públicos e bancos de dados de inicialização segura é transmitido para o Compute Engine. Esses arquivos são armazenados nas variáveis UEFI correspondentes e usados para estabelecer relações de confiança entre a plataforma, o firmware e o SO. Os certificados são certificados X.509 codificados por regras distintas (DER, na sigla em inglês). Os bancos de dados podem ser certificados ou binários brutos. Há quatro valores no total:

• Platform Key (pk): uma chave usada para estabelecer a relação de confiança entre o proprietário da plataforma e o firmware. Só é possível especificar uma chave de plataforma, que precisa ser um certificado X.509 válido.
• Chave de troca de chaves (kek): uma chave usada para estabelecer uma relação de confiança entre o firmware e o SO. Você pode especificar várias chaves para esse valor.
• Banco de dados de chaves proibido (dbx): um banco de dados de certificados que foi revogado e fará com que o sistema interrompa a inicialização se um arquivo de inicialização for assinado com um deles. Você pode especificar um ou vários valores para esse valor.
• Banco de dados de chaves (db): um banco de dados de certificados confiáveis e que podem ser usados para assinar arquivos de inicialização. Você pode especificar um ou vários valores para esse valor.

A especificação UEFI contém mais informações sobre esses valores e como eles funcionam.

No exemplo a seguir, o OpenSSL é usado para criar as chaves e os certificados de inicialização segura.

• Gere um par de chaves RSA de 2.048 bits.

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

• Gerar um certificado X.509 autoassinado a partir da chave no formato DER

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

Como adicionar a imagem protegida ao Google Cloud

Usando a imagem e os certificados enviados, agora é possível adicionar a imagem ao Compute Engine. É possível adicionar a imagem usando a CLI do Google Cloud ou a API Compute Engine.

gcloud

Adicione a imagem personalizada ao 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]"

onde:

• [IMAGE_NAME] é o nome da nova imagem;
• [SOURCE_DISK] é o disco que você usa para criar a nova imagem;
• [ZONE] é a zona onde o disco está localizado.

A opção WINDOWS para guest-os-features é obrigatória somente ao usar uma imagem do Windows. Para mais informações sobre como criar uma imagem, consulte a referência de gcloud create.

API

Siga as instruções para criar uma imagem a partir de um disco permanente, mas especifique o initial_state_config no corpo da solicitação.

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

Certificados padrão

Observe que pk, keks, dbxs e dbs são campos opcionais. Se você fornecer uma configuração de estado inicial, alguns ou todos esses campos poderão não estar definidos. Quando uma nova instância é criada a partir da imagem, o Google Cloud fornece um valor padrão para PK, KEK, db e dbx, a menos que um valor personalizado tenha sido definido em qualquer campo não definido. Se você não fornecer nenhuma configuração de estado inicial (ou seja, a configuração estiver ausente, não apenas vazia), a imagem terá a configuração de estado inicial da imagem de origem.

Os valores padrão desses campos são:

• PK: o certificado associado à chave privada padrão criada pelo Google.
• KEK: o certificado Microsoft KEK padrão. Faça o download no site da Microsoft: MicCorKEKCA2011_2011-06-24.crt.
• dbx: a lista de revogação padrão do Microsoft DBX. Faça o download no Fórum de interface de firmware extensível unificado: arquivo de lista de revogação UEFI
• db: os dois certificados a seguir:
  • O PCA de produção do Microsoft Windows 2011 com um hash de certificação SHA-1 de 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d. Faça o download no site da Microsoft: MicWinProPCA2011_2011-10-19.crt.
  • A Microsoft Corporation UEFI CA 2011 com um hash de certificado SHA-1 de 46 de f6 3b 5c e6 1c f8 ba 0d e2 e6 63 9c 10 19 d0 ed 14 f3. Faça o download no site da Microsoft: MicCorUEFCA2011_2011-06-27.crt.

Tenha cuidado, pois adicionar seus próprios certificados substituirá os certificados padrão em vez de mesclá-los com os que você fornecer.