Como verificar a atestação de hardware no Azure Confidential Computing

By Mirko Peters · 2026-10-26

Saiba como funciona a atestação de hardware do Azure, compare AMD SEV-SNP e Intel SGX e descubra como integrar a verificação criptográfica aos seus pipelines de CI/CD.

Automatically translated with AI from the original post. Read the English original

A atestação de hardware do Azure é um processo crítico de verificação criptográfica que comprova que o seu Trusted Execution Environment é autêntico e não foi adulterado antes que as cargas de trabalho sensíveis sejam carregadas. Ao avaliar as medições de inicialização segura e as chaves de hardware em relação às linhas de base da Microsoft e dos fornecedores, a atestação reduz a lacuna de confiança entre os operadores de nuvem e a privacidade dos dados do locatário.

Principais conclusões

• A atestação de hardware verifica criptograficamente que o seu Trusted Execution Environment (TEE) é autêntico e não está comprometido.
• O serviço de atestação remota avalia as medições da plataforma em relação às linhas de base de segurança antes de liberar as chaves de descriptografia.
• As arquiteturas AMD SEV-SNP e Intel SGX dependem da verificação remota para garantir que os administradores de nuvem não consigam inspecionar a memória em uso.
• Integrar a atestação aos pipelines de implantação de CI/CD automatiza a validação de confiança e impede que contêineres adulterados sejam iniciados.
• Entender o handshake de atestação é essencial para manter uma postura de confiança zero em ambientes de nuvem híbrida modernos.

O déficit de confiança em nuvens públicas

Ao migrar cargas de trabalho sensíveis para a nuvem pública, os modelos tradicionais de segurança protegem os seus dados em trânsito com TLS e em repouso com criptografia AES-256. No entanto, uma vulnerabilidade significativa permanece: os dados em uso. Historicamente, sempre que um processador executava código, esses dados precisavam ser descriptografados e colocados em texto simples na memória do sistema. Em um ambiente de nuvem multilocatário, isso significava confiar no hypervisor, no provedor da infraestrutura de nuvem e em qualquer pessoa com acesso administrativo ao hardware físico subjacente.

O Azure Confidential Computing muda esse paradigma ao introduzir Trusted Execution Environments (TEEs) baseados em hardware. Esses enclaves seguros e máquinas virtuais isoladas criptografam o conteúdo da memória usando chaves de hardware dedicadas, gerenciadas diretamente pelo silício da CPU. Ainda assim, ter uma sala trancada é só metade da batalha. Você também precisa de uma forma de verificar que a fechadura não foi forçada, que a porta foi construída corretamente e que nenhum software não autorizado está em execução dentro do limite seguro antes de entregar suas chaves criptográficas.

Como funciona a atestação remota

A atestação remota é o mecanismo de verificação que responde a uma pergunta fundamental: como você sabe que o ambiente de nuvem onde está implantando é realmente seguro e não foi adulterado? Sem a atestação, um invasor com acesso no nível do hypervisor poderia, em teoria, substituir uma BIOS maliciosa ou modificar o bootloader, interceptando suas chaves de criptografia no momento em que são carregadas na memória.

O fluxo de atestação funciona como um handshake criptográfico rigoroso e em várias etapas:

Etapa 1: inicialização segura e medição da plataforma

Quando uma máquina virtual confidencial do Azure ou uma instância de contêiner é inicializada, o hardware e o firmware registram medições criptográficas de cada componente envolvido no processo de boot. Isso inclui o bootloader, as imagens do kernel e quaisquer ramdisks iniciais. Essas medições ficam armazenadas com segurança em registradores de hardware dentro da CPU, que não podem ser modificados pelo sistema operacional do host nem pelo hypervisor.

Etapa 2: Geração do relatório criptográfico

Assim que a carga de trabalho é inicializada dentro do TEE, ela solicita à CPU um relatório assinado pelo hardware. O processador assina esse relatório de medições usando uma chave privada fixa e inalterável, gravada no silício durante a fabricação. Esse relatório funciona como um passaporte digital à prova de falsificação, que representa o estado exato da pilha de software em execução no ambiente isolado.

Etapa 3: Avaliação pelo Azure Attestation Service

O relatório de hardware assinado é enviado ao serviço Microsoft Azure Attestation (MAA) ou a um verificador de terceiros compatível. O serviço de atestação compara as medições recebidas com uma política de referência confiável definida pelo locatário. Se o código em execução no enclave corresponder à política autorizada, o serviço gera um token de atestação.

Etapa 4: Liberação dos segredos

Com um token de atestação válido em mãos, sua aplicação pode solicitar com segurança credenciais de banco de dados, certificados TLS ou chaves de criptografia de dados de um Key Vault Managed HSM. O Key Vault verifica o token e libera os segredos somente para o TEE verificado, garantindo que nenhum ambiente não autorizado possa acessar seus dados em texto simples.

Diferenças de arquitetura: AMD SEV-SNP vs. Intel SGX

Implementar a atestação exige entender a arquitetura de hardware que sustenta os nós de Azure Confidential Computing. O Microsoft Azure oferece suporte a duas tecnologias de hardware principais, cada uma tratando isolamento e atestação de forma um pouco diferente.

O Intel Software Guard Extensions (SGX) foca em isolamento no nível de processo. Em vez de proteger uma máquina virtual inteira, o SGX permite que desenvolvedores isolem códigos e estruturas de dados específicos em enclaves de granularidade fina. A atestação no SGX depende fortemente de enclaves de cotação, que empacotam o estado do hardware em uma cotação verificável, a qual é então validada pela infraestrutura Enhanced Privacy ID (EPID) ou pela mais moderna Data Center Attestation Primitives (DCAP) da Intel.

Por outro lado, o AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) protege máquinas virtuais inteiras. O SEV-SNP garante a integridade da memória por meio de criptografia de memória baseada em hardware e impede que hypervisors maliciosos remapeiem endereços físicos do convidado. O relatório de atestação gerado por uma VM AMD SEV-SNP inclui configurações de política do convidado e medições de inicialização, o que facilita o lift-and-shift de aplicações em contêineres existentes sem reescrever o código para APIs específicas de enclave.

Implementando a atestação em pipelines de CI/CD

Para arquitetos de nuvem e engenheiros de DevOps, verificar manualmente os relatórios de atestação não é escalável nem prático. Para construir uma infraestrutura de nuvem resiliente, a atestação precisa estar profundamente integrada aos seus pipelines de implantação automatizados.

Implantações modernas de contêineres executadas no Azure Kubernetes Service (AKS) com nós confidenciais podem usar contêineres sidecar ou device plugins para gerenciar automaticamente o handshake de atestação. Quando um pod confidencial é iniciado, o cliente de atestação obtém o relatório de hardware, envia-o ao serviço Azure Attestation e armazena em cache o token resultante. Somente quando o token é verificado é que o contêiner da aplicação monta seus volumes seguros e começa a processar requisições.

Ao incorporar verificações de atestação nos seus gates de release, você garante que qualquer alteração de código não autorizada — seja acidental ou maliciosa — invalide imediatamente as medições de hardware. Isso interrompe o processo de liberação de chaves e impede que a carga de trabalho comprometida seja iniciada em produção.

Conclusão: protegendo dados em uso hoje

O Azure Confidential Computing oferece a base técnica necessária para proteger cargas de trabalho sensíveis na nuvem contra ameaças modernas de infraestrutura, mas o isolamento de hardware sozinho é incompleto sem uma verificação rigorosa. Ao dominar a atestação remota, arquitetos de nuvem podem estabelecer confiança verificável entre o código do locatário e o hardware bare-metal, garantindo que os dados em uso permaneçam tão seguros quanto os dados em repouso e em trânsito. Para ouvir uma análise completa desses conceitos de segurança em nuvem e explorar o panorama mais amplo do Microsoft 365 e do Azure, ouça o episódio completo do M365 FM Podcast.

Perguntas frequentes

Qual é a finalidade principal do Azure Attestation?

O Azure Attestation é um serviço de nuvem unificado que verifica criptograficamente a confiabilidade de um Trusted Execution Environment e valida a integridade do software executado dentro dele antes que segredos ou chaves de criptografia sejam liberados.

Um administrador de nuvem pode contornar a atestação de hardware?

Não. A atestação de hardware depende de chaves criptográficas gravadas diretamente no silício da CPU pelo fabricante do hardware. Como essas chaves são inacessíveis a hypervisors e operadores de nuvem, os administradores não conseguem forjar um relatório de atestação válido para um ambiente comprometido.

Qual é a diferença entre atestação no nível de VM e no nível de processo?

A atestação no nível de VM (como o AMD SEV-SNP) mede e valida todo o sistema operacional de uma máquina virtual e suas cargas de trabalho. A atestação no nível de processo (como o Intel SGX) isola e atesta rotinas de código específicas ou enclaves dentro de um ambiente de sistema operacional padrão.

Como os tokens de atestação se integram ao Azure Key Vault?

Assim que uma carga de trabalho confidencial conclui com sucesso o handshake de atestação, ela recebe um token assinado. Esse token pode ser apresentado ao Azure Key Vault Managed HSM para comprovar a integridade do ambiente, acionando a liberação automatizada de chaves de criptografia e credenciais de banco de dados.