Proteja a propriedade intelectual em VMs do Azure com o Secure Key Release condicionado por atestação

Este artigo descreve um padrão reutilizável para proteger um ativo sensível — por exemplo, pesos proprietários de modelos de aprendizagem automática, um conjunto de dados licenciado ou uma configuração secreta — que deve correr numa máquina virtual (VM) dentro da subscrição Azure de outra pessoa. A parte que detém o ativo (o editor) é diferente da parte que detém a subscrição onde a VM é executada (o consumidor). O cliente tem acesso total ao plano de controlo do Azure sobre essa máquina virtual, mas não deve conseguir extrair o recurso.

O padrão combina várias características Azure documentadas em camadas de defesa. O seu núcleo criptográfico é o Secure Key Release (SKR) condicionado por atestação do Azure Key Vault, condicionado pela atestação de vTPM do Trusted Launch. Não exige Computação Confidencial, embora a Computação Confidencial possa ser adicionada como uma camada opcional quando o modelo de ameaça assim o exige.

Cenário e modelo de ameaça

Um publicador distribui uma carga de trabalho baseada em máquinas virtuais na subscrição de um consumidor (por exemplo, através do Azure Marketplace como modelo de solução ou como imagem partilhada). A carga de processamento precisa de uma chave de desencriptação para desbloquear o recurso do fornecedor durante a execução. A chave deve ser disponibilizada apenas à imagem genuína e inalterada do publicador — nunca diretamente ao consumidor, nem a uma imagem manipulada ou substituída.

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

A direção da ameaça A é a principal ameaça e a que molda a arquitetura. No padrão base, a direção de ameaça B é um risco explicitamente aceite: a plataforma é confiável, correspondendo à postura comum de confiar no hipervisor do fornecedor de cloud. Adicionar a Camada 4 apenas quando não se puder confiar no próprio hipervisor (por exemplo, uma carga de trabalho sujeita a regulamentação que exige encriptação da memória).

Quando adicionar Computação Confidencial (Camada 4)

A Computação Confidencial não é uma alternativa a este padrão — é a Camada 4 opcional que se adiciona por cima. O padrão de base (Camadas 1–3) já condiciona a libertação da chave à atestação, protege o ativo contra o consumidor e é executado em qualquer SKU Gen2 do Trusted Launch ao custo padrão. Adicionar Computação Confidencial não altera a forma como o padrão funciona: SKR, a imagem reforçada e o isolamento de rede mantêm-se todos iguais, e o fluxo de lançamento é idêntico. As únicas diferenças são que a política de lançamento depende de declarações de hardware-TEE em vez de declarações de arranque medido do vTPM, e a carga de trabalho é executada numa SKU de VM confidencial. Ganhas proteção contra a direção de ameaça B (o host/hipervisor) e trocas SKU, GPU e amplitude de região a um custo premium.

A tabela seguinte mostra o que a Camada 4 adiciona e quanto custa — não uma escolha entre dois padrões:

Começa pelo padrão base. Adicione a Camada 4 apenas quando tiver de desconfiar do hipervisor — por exemplo, uma carga de trabalho regulada que exige encriptação de memória — aceitando a disponibilidade mais limitada de SKU, GPU e região, bem como o custo premium.

Os elementos do padrão

O padrão é uma estrutura em camadas de defesa em profundidade. Cada camada defende uma direção específica de ameaça: as camadas 1–3 defendem contra o consumidor (direção de ameaça A), e a camada opcional 4 defende contra o hospedeiro (direção de ameaça B). O ativo protegido encontra-se no núcleo, acessível apenas através de cada camada envolvente.

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: Libertação de Chave Segura Controlada por Atestação (a porta criptográfica)

Esta camada é a base. Uma VM de Lançamento Confiável arranca com Secure Boot e um TPM virtual (vTPM). O vTPM mede a cadeia de arranque em Registos de Configuração de Plataforma (PCRs), criando uma impressão digital criptográfica exatamente do que arrancou. O convidado solicita um token MAA que inclua estas medições, como a declaração secureboot e de x-ms-azurevm-attested-pcr-values.pcr0 a pcr7. Em seguida, chama o endpoint do Key Vault /release e apresenta o token. O Key Vault valida a assinatura do token e avalia-a em relação à política de libertação da chave. Se as declarações da política corresponderem, o Key Vault fornece a chave, cifrada com a chave efémera do vTPM, para que apenas essa VM atestada a possa desencapsular. Se não corresponderem, a versão retorna AccessDenied.

O que bloqueia (ameaça A): Uma VM adulterada, reimageada ou trocada de disco mede diferentes PCRs e não consegue obter a chave. Um snapshot do disco do sistema operativo montado numa VM diferente também falha.

Uma política representativa de lançamento para uma VM de Lançamento 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 desencriptado)

A Camada 1 controla se a chave é libertada; não protege o recurso assim que é desencriptado no sistema convidado em execução. Endureça a imagem para reduzir a superfície de ataque in-guest e do plano de controlo: integridade do sistema de ficheiros (por exemplo, dm-verity), um sistema raiz apenas de leitura, sem daemon SSH, sem login interativo e sem agente in-guest que pudesse executar comandos fornecidos pelo operador.

O que bloqueia (ameaça A): Exploração in-guest de uma VM em execução e atestada — processos maliciosos, escalonamento de privilégios, extração do ativo desencriptado da memória do processo através de uma vulnerabilidade ao nível do sistema operativo.

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

Limita a forma como a VM comunica com os âncoras de confiança e com os dados. Utilize pontos finais privados para o Key Vault, o armazenamento e qualquer registo; um caminho privado para o fornecedor de atestação; DNS privado; e nenhuma saída pública desnecessária. Quando o mecanismo de implementação o permite — por exemplo, uma aplicação gerida — as atribuições de recusa também podem retirar ao consumidor as permissões de RBAC sobre os recursos de computação, bloqueando de imediato ataques ao plano de controlo (run-command, operações de disco, consola série, roubo de identidade). Numa entrega baseada num template de solução, o consumidor mantém o RBAC sobre os recursos implementados, pelo que o endurecimento do plano de controlo não está disponível; nesse caso, as Camadas 1 e 2 asseguram a defesa contra a ameaça A — um snapshot ou disco trocado falha a atestação (Camada 1), e a imagem reforçada (Camada 2) impede a extração do ativo desencriptado no sistema convidado.

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

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

Tudo o que está acima confia no anfitrião. Se não conseguires confiar no hipervisor, executa a carga de trabalho numa VM Confidencial (AMD SEV-SNP ou Intel TDX). A encriptação da memória impede que o host leia a memória das máquinas virtuais convidadas, e o SKR substitui as declarações de arranque medido do vTPM por declarações de TEE de hardware na política de disponibilização. Esta camada é a única que defende a direção de ameaça B. Está desligada por defeito porque limita a disponibilidade de SKU, GPU e região, além de adicionar custo.

Identidade entre inquilinos

O publicador detém as âncoras de confiança — Key Vault (ou Managed HSM) e o provedor de atestação — no tenant do publicador, fora do RBAC do consumidor. A VM atestada é executada no tenant do consumidor e tem de aceder ao Key Vault através dessa fronteira. Duas restrições de plataforma excluem as abordagens óbvias:

• Uma identidade gerida existe exatamente num único inquilino. O tenant do publicador não reconhecerá nem emitirá tokens para uma identidade gerida que reside no tenant do consumidor.
• Uma atribuição de função do Azure RBAC só pode ter como destino uma identidade no próprio inquilino do recurso, pelo que não é possível conceder à identidade gerida do consumidor uma função no Key Vault do publicador.

Uma credencial de identidade federada (FIC) também não pode colmatar diretamente essa lacuna: o Entra ID não permite que uma FIC confie em tokens emitidos por outro tenant do Entra, pelo que uma aplicação pertencente ao publicador não pode federar a identidade gerida do consumidor através dessa fronteira.

O padrão que funciona coloca a identidade de ponte — uma aplicação multitenant — do lado do consumidor:

1. O cliente regista uma aplicação multitenant no seu inquilino e configura nessa aplicação um FIC do mesmo inquilino que confia na identidade gerida da VM. Um FIC que confie numa identidade no mesmo inquilino é permitido.
2. O publicador integra essa aplicação no seu próprio tenant ao aprovisionar um principal de serviço para a mesma e ao conceder a esse principal a função Key Vault Crypto Service Release User na chave. Este passo deliberado de integração, realizado por consumidor, é a fase em que o publicador concede a um ator externo acesso ao seu tenant.
3. Em tempo de execução, a identidade gerida da VM obtém um token do IMDS, troca-o por intermédio do FIC para se autenticar como a aplicação multicliente e invoca o ponto final /release do Key Vault com o token MAA no corpo do pedido.

Guia Passo-a-Passo

1. Configure as âncoras de confiança (tenant do publicador). Crie um Key Vault Premium ou Managed HSM. Crie uma chave de RSA-HSM exportável . Anexe uma política de publicação que vincule a sua autoridade MAA e as declarações do Lançamento Confiável (secureboot, selecionado x-ms-azurevm-attested-pcr-values.pcrN).
2. Determine os valores esperados de PCR. Ateste uma instância comprovadamente boa da sua imagem uma vez e leia x-ms-azurevm-attested-pcr-values do token MAA devolvido. Fixa os PCRs que a tua cadeia de arranque mede—normalmente pcr4 (carregador de arranque/kernel) e pcr7 (estado de arranque seguro).
3. Implemente a carga de trabalho (inquilino consumidor). Implemente uma VM de Trusted Launch (Gen2) com a imagem protegida. Dê-lhe uma identidade gerida e federe essa identidade com a aplicação multilocatário pertencente ao consumidor descrita em Cross-tenant identity, a cujo principal de serviço o publicador atribuiu Key Vault Crypto Service Release User na chave.
4. Atestar e libertar em tempo de execução. O convidado obtém um token MAA e depois chama POST /keys/{key-name}/release. O Key Vault valida e devolve a chave enrolada; o convidado desenrola-a dentro da VM.
5. Verifica o caso negativo. Altere uma PCR fixada na política de lançamento para um valor não correspondente (ou inicie uma imagem modificada) e confirme que a versão retorna AccessDenied.

Para código executável, consulte os exemplos em Conteúdo relacionado.

Conteúdo relacionado

• Gramática da política de liberação segura de chaves do Azure Key Vault
• Libertação Segura de Chaves com o Azure Key Vault e o Azure Confidential Computing
• Exemplos de políticas de Libertação Segura de Chaves
• Visão geral do Microsoft Azure Attestation
• Trusted Launch para máquinas virtuais da Azure
• Federação de identidades de tarefas
• Exemplo: cvm-securekey-release-app em Azure/confidential-computing-cvm-guest-attestation
• Exemplo: exemplos de SKR em Azure-Samples/confidential-computing