Atestado do Microsoft Azure

O Atestado do Microsoft Azure é uma solução unificada para verificar remotamente a confiabilidade de uma plataforma e a integridade dos binários em execução dentro dela. O serviço dá suporte ao atestado das plataformas com suporte de TPMs (Módulos de Plataforma Confiáveis) e oferece a capacidade de atestar TEEs (Ambientes de Execução Confiáveis), como enclaves Intel® SGX (Software Guard Extensions) e enclaves VBS (Segurança baseada em Virtualização), TPMs (Módulos de Plataforma Confiáveis), Início Confiável para VMs do Azure e VMs confidenciais do Azure.

O atestado é um processo usado para demonstrar que os binários de software foram instanciados corretamente em uma plataforma confiável. Em seguida, as partes confiáveis remotas podem ter a confiança de que apenas esse software pretendido está sendo executado no hardware confiável. O Atestado do Azure é um serviço unificado voltado ao cliente e uma estrutura para o atestado.

O Atestado do Azure permite paradigmas de segurança de ponta, como a Computação confidencial do Azure e a proteção de borda inteligente. Os clientes estão solicitando a capacidade de verificar de maneira independente a localização de um computador, a postura de uma VM (máquina virtual) nesse computador e o ambiente no qual os enclaves estão em execução nessa VM. O Atestado do Azure capacitará essas e muitas solicitações de clientes adicionais.

O Atestado do Azure recebe evidências de entidades de computação, transforma-as em um conjunto de declarações, valida-as em relação às políticas configuráveis e produz provas de criptografia para aplicativos baseados em declarações (por exemplo, partes confiáveis e autoridades de auditoria).

Atestado do Azure dá suporte ao atestado de plataforma e convidado de CVMs (VMs Confidenciais) baseadas em AMD SEV-SNP. O atestado de plataforma baseado Atestado do Azure ocorre automaticamente durante o caminho de inicialização crítico das CVMs, sem a necessidade de ação do cliente. Para ver mais detalhes sobre o atestado de convidado, consulte Anunciamos a disponibilidade geral do atestado de convidado para VMs confidenciais.

Casos de uso

O Atestado do Azure fornece serviços de atestado abrangentes para vários ambientes e casos de uso diferentes.

Atestado AMD SEV-SNP em VMs Confidenciais

A VM Confidencial do Azure (CVM) é baseada em processadores AMD com tecnologia SEV-SNP. Para isso, a CVM oferece a opção de criptografia de disco de SO de VM com chaves gerenciadas pela plataforma ou pelo cliente e vincula as chaves de criptografia de disco ao TPM da máquina virtual. Quando um CVM é inicializado, um relatório SNP com as medições de firmware da VM convidada é enviado ao Atestado do Azure. O serviço valida as medições e emite um token de atestado que é usado para liberar chaves do HSM gerenciado ou do Azure Key Vault. Essas chaves são usadas para descriptografar o estado vTPM da VM convidada, desbloquear o disco do SO e iniciar o CVM. O processo de atestado e liberação de chave é executado automaticamente em cada inicialização do CVM e garante que ele seja inicializado somente após o atestado bem-sucedido do hardware.

Atestado AMD SEV-SNP em contêineres confidenciais

Os Contêineres Confidenciais do Azure são baseados em processadores AMD com tecnologia SEV-SNP. Contêineres confidenciais, hospedados em Instâncias de Contêiner do Azure e em Serviço de Kubernetes do Azure (em versão prévia), oferecem a capacidade de executar grupos de contêineres em um ambiente de execução confiável protegido por SEV-SNP, que isola esse grupo de contêineres do plano de controle de gerenciamento de contêineres e de outros contêineres em execução. O atestado em contêineres confidenciais envolve a obtenção do relatório de atestado de hardware da AMD diretamente do processador. Isso pode ser feito com o nosso contêiner sidecar SKR ou compilado diretamente na lógica do seu aplicativo. O relatório de hardware pode então ser trocado com o Atestado do Azure e o managed-HSM ou o Premium Azure Key Vault (AKV) para recuperar segredos. Você também pode fornecer o relatório de hardware ao seu próprio sistema de cofre de chaves, conforme desejado.

Atestado de Início Confiável

Os clientes do Azure podem impedir infecções de bootkit e rootkit habilitando o Início confiável para suas máquinas virtuais (VMs). Quando a VM é habilitada para Inicialização Segura e vTPM com a extensão de atestado de convidado instalada, as medidas do vTPM são enviadas ao Atestado do Azure periodicamente para monitoramento da integridade da inicialização. Uma falha de atestado indica um possível malware, que aparece para os clientes por meio do Microsoft Defender para Nuvem, por meio de Alertas e Recomendações.

Atestado de TPM

O atestado baseado em Trusted Platform Modules (TPM) é fundamental para fornecer prova do estado de uma plataforma. O TPM funciona como a raiz de confiança e o coprocessador de segurança para fornecer a validade de criptografia para medidas (evidência). Os dispositivos com um TPM podem depender do atestado para provar que a integridade da inicialização não está comprometida e usar as declarações para detectar a habilitação do estado do recurso durante a inicialização.

Os aplicativos cliente podem ser criados para aproveitar o atestado TPM, delegando tarefas confidenciais de segurança para ocorrerem apenas depois que uma plataforma for validada para ser segura. Em seguida, esses aplicativos podem usar o Atestado do Azure para estabelecer a confiança rotineiramente na plataforma e a capacidade dela de acessar dados confidenciais.

Atestado de enclave do SGX

O Intel® Software Guard Extensions (SGX) refere-se ao isolamento de nível de hardware, que é compatível com determinados modelos de CPUs Intel. O SGX permite que o código seja executado em compartimentos corrigidos conhecidos como enclaves do SGX. Depois, as permissões de acesso e de memória são gerenciadas pelo hardware para garantir uma superfície de ataque mínima com isolamento adequado.

Os aplicativos cliente podem ser criados para aproveitar os enclaves do SGX, delegando a ocorrência de tarefas de segurança confidenciais nesses enclaves. Em seguida, esses aplicativos podem usar o Atestado do Azure para estabelecer a confiança rotineiramente no enclave e a capacidade de acessar dados confidenciais.

Os processadores escaláveis Intel® Xeon® dão suporte apenas a soluções de atestado baseadas em ECDSA para atestar remotamente enclaves SGX. Utilizando o modelo de atestado baseado em ECDSA, o Atestado do Azure dá suporte à validação de processadores Intel® Xeon® E3 e plataformas de servidor escalonáveis baseadas em processador Intel® Xeon®.

Atestado de enclave aberto

O OE (Open Enclave) é uma coleção de bibliotecas destinadas à criação de uma abstração unificada de enclaves para que os desenvolvedores criem aplicativos baseados em TEE. Ele oferece um modelo de aplicativo seguro universal que minimiza as especificidades de plataforma. A Microsoft o considera como uma base essencial para a democratização das tecnologias de enclave baseadas em hardware, como o SGX, e para a adoção delas no Azure.

O OE padroniza os requisitos específicos para a verificação de uma evidência de enclave. Isso qualifica o OE como um consumidor de atestado altamente qualificado do Atestado do Azure.

O Atestado do Azure pode ser executado em um TEE

O Atestado do Azure é crítico para cenários de Computação Confidencial, pois ele executa as seguintes ações:

• Verifica se as evidências do enclave são válidas.
• Avalia as evidências do enclave em relação a uma política definida pelo cliente.
• Gerencia e armazena políticas específicas do locatário.
• Gera e assina um token que é usado por terceiras partes confiáveis para interagir com o enclave.

Para manter a Microsoft operacionalmente fora da TCB (base de computação confiável), as operações críticas do Atestado do Azure, como validação de cotação, geração de token, avaliação de política e assinatura de token, são movidas para um enclave SGX.

Por que usar o Atestado do Azure

O Atestado do Azure é a escolha preferencial para atestar os TEEs, pois oferece os seguintes benefícios:

• Estrutura unificada para atestar vários ambientes como enclaves TPMs, SGX e VBS.
• Permite a criação de provedores de atestado personalizados e a configuração de políticas para restringir a geração de token.
• Protege seus dados em uso com implementação em um enclave SGX ou Máquina Virtual Confidencial com base em AMD SEV-SNP.
• Serviço altamente disponível

Como estabelecer confiança com o Atestado do Azure

1. Verifique se o token de atestado é gerado pelo Atestado do Azure – O token de atestado gerado pelo Atestado do Azure é assinado usando um certificado autoassinado. A URL dos certificados de autenticação é exposta por meio de um ponto de extremidade de metadados OpenID. A terceira parte confiável pode recuperar o certificado de autenticação e executar a verificação de assinatura do token de atestado. Confira exemplos de código para obter mais informações
2. Verifique se o Atestado do Azure está em execução dentro de um enclave SGX – Os certificados de autenticação de tokens incluem a cotação de SGX do TEE dentro da qual o Atestado do Azure é executado. Se a terceira parte confiável preferir verificar se o Atestado do Azure está sendo executado em um enclave de SGX válido, a cotação de SGX poderá ser recuperada do certificado de autenticação e validada localmente. Confira exemplos de código para obter mais informações
3. Valide a associação da cotação de SGX do Atestado do Azure com a chave que assinou o token de atestado – A terceira parte confiável pode verificar se o hash da chave pública que assinou o token de atestado corresponde ao campo de dados de relatório da cotação de SGX do Atestado do Azure. Confira exemplos de código para obter mais informações
4. Valide se as medidas do código do Atestado do Azure correspondem aos valores publicados do Azure: a cotação de SGX inserida nos certificados de autenticação de tokens de atestado inclui medidas de código de Atestado do Azure, como mrsigner. Se a terceira parte confiável estiver interessada em validar se a cotação de SGX pertence ao Atestado do Azure em execução no Azure, o valor MRSIGNER poderá ser recuperado da cotação de SGX no certificado de autenticação de tokens de atestado e comparado com o valor fornecido pela equipe do Atestado do Azure. Se você tiver interesse em executar essa validação, envie uma solicitação na página de Suporte do Azure. A equipe do Atestado do Azure entrará em contato com você quando planejar girar o MRSIGNER.

Espera-se que o Mrsigner do Atestado do Azure seja alterado quando os certificados de autenticação de código forem girados. A equipe do Atestado do Azure seguirá a agenda de distribuição abaixo para cada rotação de mrsigner:

i. A equipe do Atestado do Azure notificará o valor de MRSIGNER futuro com um período de carência de 2 meses para fazer alterações relevantes no código

ii. Após o período de carência de 2 meses, o Atestado do Azure começará a usar o novo valor de MRSIGNER

iii. 3 meses após a data de notificação, o Atestado do Azure deixará de usar o valor de MRSIGNER antigo

Suporte de BCDR (continuidade dos negócios e recuperação de desastres)

A BCDR (Continuidade dos Negócios e Recuperação de Desastres) do Atestado do Azure permite reduzir as interrupções de serviço resultantes de problemas de disponibilidade ou eventos de desastres significativos em uma região.

Os clusters implantados em duas regiões funcionarão de maneira independente em circunstâncias normais. No caso de uma falha ou uma interrupção de uma região, ocorrerá o seguinte:

• A BCDR do Atestado do Azure fornecerá um failover contínuo no qual os clientes não precisam realizar nenhuma etapa extra para recuperação.
• O Gerenciador de Tráfego do Azure para a região detectará se a investigação de integridade está degradada e alternará o ponto de extremidade para a região emparelhada.
• As conexões existentes não funcionarão e receberão problemas de erro interno do servidor ou de tempo limite.
• Todas as operações do painel de controle serão bloqueadas. Os clientes não poderão criar provedores de atestado na região primária.
• Todas as operações de plano de dados, incluindo chamadas de atestado e configuração de política, serão atendidas pela região secundária. Os clientes podem continuar trabalhando nas operações do plano de dados com o URI original correspondente à região primária.

Próximas etapas

• Saiba mais sobre os conceitos básicos do Atestado do Azure
• Como criar e assinar uma política de atestado
• Configurar o Atestado do Azure usando o PowerShell