Proteja a propriedade intelectual em VMs do Azure com a Liberação Segura de Chaves controlada por atestação

Este artigo descreve um padrão reutilizável para proteger um ativo confidencial, por exemplo, pesos de modelo de machine learning proprietários, um conjunto de dados licenciado ou uma configuração secreta, que deve ser executado em uma VM (máquina virtual) dentro da assinatura Azure de outra pessoa. A parte que possui o ativo (o publicador) é diferente da parte que possui a assinatura em que a VM é executada (o consumidor). O consumidor tem acesso total ao plano de controle do Azure dessa VM, mas, ainda assim, não deve poder extrair o ativo.

O padrão combina vários recursos de Azure documentados em camadas de defesa. Seu núcleo criptográfico é a Liberação Segura de Chaves (SKR) condicionada à atestação do Azure Key Vault, condicionada à atestação de vTPM do Trusted Launch. Ele não requer computação confidencial, embora a computação confidencial possa ser adicionada como uma camada opcional quando o modelo de ameaça exige isso.

Cenário e modelo de ameaça

Um publicador distribui uma carga de trabalho baseada em VM na assinatura de um consumidor (por exemplo, por meio do Azure Marketplace como um modelo de solução ou como uma imagem compartilhada). A carga de trabalho precisa de uma chave de descriptografia para desbloquear o ativo do publicador em tempo de execução. A chave deve ser liberada apenas para a imagem genuína e não modificada do publicador — nunca diretamente ao consumidor e nunca para uma imagem adulterada ou substituída.

O padrão se defende contra duas direções de ameaça distintas. Nomeá-los explicitamente é o que torna as decisões de camadas claras.

A direção da ameaça A é a principal ameaça e aquela que molda a arquitetura. No padrão base, a direção de ameaça B é um risco explicitamente aceito: a plataforma é confiável, correspondendo à postura comum de confiar no hipervisor do provedor de nuvem. Adicione a Camada 4 somente quando o próprio hipervisor precisar ser ignorado (por exemplo, uma carga de trabalho regulamentada que exige criptografia de memória).

Quando adicionar Computação Confidencial (Camada 4)

A computação confidencial não é uma alternativa a essa abordagem — é a Camada 4 opcional que você adiciona por cima dela. O padrão básico (Camadas 1–3) já condiciona a liberação da chave à atestação, protege o ativo do consumidor e funciona em qualquer SKU Gen2 do Trusted Launch com custo padrão. Adicionar Computação Confidencial não altera como o padrão funciona: SKR, a imagem protegida e o isolamento de rede permanecem iguais e o fluxo de liberação é idêntico. As únicas diferenças são que a política de lançamento depende de declarações do hardware TEE, em vez de declarações de inicialização medida do vTPM, e que a carga de trabalho é executada em um SKU de máquina virtual confidencial. Você obtém proteção contra a direção de ameaça B (host/hipervisor) e negocia SKU, GPU e amplitude da região a um custo premium.

A tabela a seguir mostra o que a Camada 4 adiciona e o que ela custa, não uma opção entre dois padrões:

Comece com o padrão base. Adicione a Camada 4 somente quando você não puder confiar no hipervisor — por exemplo, em uma carga de trabalho sujeita a regulamentação que exige criptografia de memória — aceitando a disponibilidade mais limitada de SKU, GPU e região, além do custo mais alto.

Os elementos do padrão

O padrão consiste em camadas de defesa em profundidade. Cada camada defende uma direção de ameaça específica: as camadas 1 a 3 se defendem contra o consumidor (direção de ameaça A) e a Camada 4 opcional se defende contra o host (direção da ameaça B). O ativo protegido fica no núcleo, acessível apenas por meio de cada camada delimitada.

As camadas defendem o ativo em repouso e em uso. Em tempo de execução, a VM do consumidor e as âncoras de confiança do publicador interagem da seguinte forma:

Camada 1: Liberação Segura de Chave controlada por atestação (a barreira criptográfica)

Essa camada é a base. Uma VM de Inicialização Confiável é inicializada com Secure Boot e um TPM virtual (vTPM). O vTPM mede a cadeia de inicialização em PCRs (Registros de Configuração de Plataforma), criando uma impressão digital criptográfica exatamente do que foi inicializado. O hóspede solicita um token MAA que inclua essas medições, como a declaração secureboot e de x-ms-azurevm-attested-pcr-values.pcr0 a pcr7. Em seguida, ele chama o endpoint /release do Key Vault e apresenta o token. Key Vault valida a assinatura do token e a avalia em relação à política de lançamento da chave. Se as declarações da política corresponderem, Key Vault liberará a chave, encapsulada na chave efêmera do vTPM para que somente a VM atestada possa desembrulhá-la. Se eles não corresponderem, a versão retornará AccessDenied.

O que ele bloqueia (ameaça A): Uma VM adulterada, recriada a partir de imagem ou com o disco trocado mede PCRs diferentes e não consegue obter a chave. Um instantâneo do disco do sistema operacional montado em uma VM diferente também falha.

Uma política de lançamento representativa para uma VM de Inicialização Confiável:

{
  "version": "1.0.0",
  "anyOf": [
    {
      "authority": "https://<MAA_PROVIDER>.<region>.attest.azure.net",
      "allOf": [
        { "claim": "secureboot", "equals": true },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr4", "equals": "<BASE64_PCR4>" },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr7", "equals": "<BASE64_PCR7>" }
      ]
    }
  ]
}

Camada 2: imagem reforçada (proteger o ativo descriptografado)

A camada 1 controla se a chave é liberada; ela não protege o recurso depois que é descriptografado no sistema convidado em execução. Reforce a segurança da imagem para reduzir a superfície de ataque no guest e no plano de controle: integridade do sistema de arquivos (por exemplo, dm-verity), sistema de arquivos raiz somente leitura, sem daemon SSH, sem login interativo e sem agente no guest que possa executar comandos fornecidos pelo operador.

O que ele bloqueia (ameaça A): Exploração em convidado de uma VM em execução e atestada — processos desonestos, escalonamento de privilégios, extração do ativo descriptografado da memória do processo por meio de uma vulnerabilidade no nível do sistema operacional.

Camada 3: Isolamento de rede (reduzir a superfície)

Restrinja como a VM fala com as âncoras de confiança e os dados. Use pontos de extremidade privados para Key Vault, armazenamento e qualquer registro; um caminho privado para o provedor de atestado; DNS privado; e nenhuma saída pública desnecessária. Quando o mecanismo de entrega permite isso — por exemplo, uma aplicação gerenciada — as atribuições de negação também podem remover as permissões de RBAC do consumidor sobre os recursos de computação, bloqueando por completo ataques ao plano de controle (run-command, operações de disco, console serial, roubo de identidade). Em uma entrega baseada em modelo de solução, o consumidor mantém o RBAC sobre os recursos implantados, portanto o reforço de segurança do plano de controle não está disponível; nesse caso, as Camadas 1 e 2 fazem a defesa contra a ameaça A — um instantâneo ou disco substituído não passa na atestação (Camada 1), e a imagem reforçada (Camada 2) impede a extração do ativo descriptografado dentro da máquina virtual convidada.

O que ele bloqueia (ameaça A): Reduz a superfície exposta para ataques de plano de controle e plano de dados e impede a exfiltração de caminhos do convidado atestado.

Camada 4 (opcional): Computação confidencial (defende a direção da ameaça B)

Tudo acima confia no host. Se você não puder confiar no hipervisor, execute a carga de trabalho em uma VM Confidencial (AMD SEV-SNP ou Intel TDX). A criptografia de memória impede que o host leia a memória do convidado, e o SKR passa de alegações de inicialização medida do vTPM para alegações de TEE de hardware na política de liberação. Essa camada é a única camada que defende a direção da ameaça B. Ele está desativado por padrão porque restringe a disponibilidade de SKU, GPU e região e adiciona custo.

Identidade entre locatários

O publicador mantém as âncoras de confiança — Key Vault (ou HSM Gerenciado) e o provedor de atestação — no locatário do publicador, fora do RBAC do consumidor. A VM atestada é executada no tenant do consumidor e precisa acessar o Key Vault através dessa fronteira. Duas restrições de plataforma descartam as abordagens óbvias:

• Uma identidade gerenciada existe em um único locatário. O locatário do publicador não reconhecerá nem emitirá tokens para uma identidade gerenciada que está no locatário do consumidor.
• Uma atribuição de função do Azure RBAC só pode ter como destino uma identidade no próprio locatário do recurso; portanto, você não pode conceder à identidade gerenciada do consumidor uma função no Key Vault do publicador.

Uma FIC (credencial de identidade federada) também não pode preencher diretamente a lacuna: Entra ID não permite que um FIC confie em tokens emitidos por outro locatário do Entra, portanto, um aplicativo de propriedade do editor não pode federar a identidade gerenciada do consumidor através do limite.

O padrão que funciona coloca a identidade intermediária — um aplicativo multilocatário — do lado do consumidor:

1. O cliente registra um aplicativo multilocatário em seu tenant e configura nele um FIC do mesmo tenant que confia na identidade gerenciada da VM. Um FIC que confia em uma identidade no mesmo locatário é permitido.
2. O publicador adiciona esse aplicativo ao seu próprio tenant, provisionando uma entidade de serviço para ele e concedendo a essa entidade de serviço a função Key Vault Crypto Service Release User na chave. É nessa etapa deliberada de integração para cada consumidor que o publicador concede a um ator externo acesso ao seu locatário.
3. Em tempo de execução, a identidade gerenciada da VM obtém um token do IMDS, troca-o por meio do FIC para se autenticar como o aplicativo multilocação e chama o ponto de extremidade /release do Key Vault com o token MAA no corpo da solicitação.

Walkthrough

1. Configure as âncoras de confiança (locatário do publicador). Crie um Key Vault Premium ou um Managed HSM. Crie uma chave de RSA-HSM exportável . Anexe uma política de liberação que vincule sua autoridade MAA e as declarações de Inicialização Confiável (secureboot, selecionadas x-ms-azurevm-attested-pcr-values.pcrN).
2. Determine os valores de PCR esperados. Faça a atestação de uma instância válida conhecida da sua imagem uma vez e leia x-ms-azurevm-attested-pcr-values do token MAA retornado. Fixe as PCRs que sua cadeia de inicialização mede — geralmente pcr4 (carregador de inicialização/kernel) e pcr7 (estado do Secure Boot).
3. Implante a carga de trabalho (locatário do consumidor). Implante uma VM de Inicialização Confiável (Gen2) executando a imagem protegida. Atribua-lhe uma identidade gerenciada e federe essa identidade ao aplicativo multilocatário de propriedade do consumidor descrito em Identidade entre locatários, cuja entidade de serviço recebeu do publicador a função Key Vault Crypto Service Release User na chave.
4. Ateste e libere em tempo de execução. O convidado obtém um token MAA e, em seguida, chama POST /keys/{key-name}/release. Key Vault valida e retorna a chave encapsulada; o convidado a desembrulha dentro da VM.
5. Verifique o caso negativo. Altere um PCR fixado na política de versão para um valor sem correspondência (ou inicialize uma imagem modificada) e confirme se a versão retorna AccessDenied.

Para obter código executável, consulte os exemplos no conteúdo relacionado.

Conteúdo relacionado

• Gramática da política de liberação de chave segura do Azure Key Vault
• Liberação segura de chaves com Azure Key Vault e Azure Confidential Computing
• Exemplos de política de versão de chave segura
• Visão geral do Atestado do Azure da Microsoft
• Inicialização confiável para máquinas virtuais do Azure
• Federação de identidade de carga de trabalho
• Exemplo: cvm-securekey-release-app em Azure/confidential-computing-cvm-guest-attestation
• Exemplo: exemplos de SKR em Azure-Samples/confidential-computing