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 que dependem remotamente podem ter confiança de que somente o software pretendido está em execução 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. O serviço recebe evidências de entidades de computação, as transforma em um conjunto de declarações, valida-as em relação a políticas configuráveis e produz provas criptográficas 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 no Atestado do Azure ocorre automaticamente durante o caminho de inicialização crítico das CVMs, sem necessidade de ação por parte 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 SEV-SNP da AMD em VMs Confidenciais

A VM Confidencial do Azure (CVM) é baseada em processadores AMD com tecnologia SEV-SNP. 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, o relatório SNP que contém as medidas de firmware da VM convidada é enviado para o 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 SEV-SNP da AMD 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 sua lógica de 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 Inicialização Segura e o vTPM estão habilitados na VM com a extensão de atestado de convidado instalada, as medições do vTPM são enviadas periodicamente ao Azure Attestation para monitorar a 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 da 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 de 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 seguros chamados enclaves 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 projetados para tirar proveito dos enclaves do SGX, delegando a realização de tarefas sensíveis à segurança dentro desses enclaves. Em seguida, esses aplicativos podem usar o Atestado do Azure para rotineiramente estabelecer a confiança no enclave e sua 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 é executado em um Ambiente de Execução Confiável (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 com 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 partes confiantes para interagir com o enclave.

Para manter a Microsoft operacionalmente fora da base de computação confiável (TCB), as operações críticas do Atestado do Azure, como validação da prova do atestado (quote), geração de token, avaliação de política e assinatura de token, são migradas para um enclave de 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 múltiplos ambientes, como TPMs, enclaves SGX e enclaves 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 enquanto estão em uso com a implementação em um enclave de SGX ou Máquina Virtual Confidencial baseada no SEV-SNP da AMD.
• 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 – um token de atestado gerado pelo Atestado do Azure é assinado usando um certificado autoassinado. A URL dos certificados de assinatura é exposta por meio de um ponto de extremidade de metadados OpenID. Uma parte confiável pode recuperar o certificado de assinatura e realizar a verificação da assinatura do token de atestado. Consulte 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 assinatura de token incluem informações sobre o TEE no qual o Atestado do Azure é executado. Essa colateral de TEE pode ser uma prova do atestado de SGX ou um relatório de SEV-SNP. A parte confiante pode verificar se o Atestado do Azure está em execução dentro de um TEE válido ao validar localmente a prova do atestado ou o relatório. Consulte exemplos de código para obter mais informações – SGX, SEV-SNP
3. Valide a vinculação da prova do atestado de SGX do Atestado do Azure com a chave que assinou o token de atestado: a parte confiante pode verificar se o hash da chave pública que assinou o token de atestado corresponde ao campo de dados de relatório do relatório de TEE do Atestado do Azure. Consulte aqui para obter mais detalhes.
4. Valide se as medições do código do Atestado do Azure correspondem aos valores publicados do Azure: o colateral de TEE incorporado aos certificados de assinatura dos tokens de atestado inclui medições de código do Atestado do Azure. Uma parte confiante pode validar que a cotação ou relatório pertence ao Atestado do Azure comparando valores específicos recuperados do colateral do TEE no certificado de assinatura do token de atestado com valores fornecidos pela equipe do Atestado do Azure. Para SGX, MRSIGNER deve ser validado. Para SEV-SNP, HOST_DATA deve ser validado. Consulte aqui para obter mais detalhes. Se você estiver interessado em executar essa validação, envie uma solicitação na página de suporte do Azure. A equipe do Atestado do Azure entra em contato com você quando esses valores específicos estiverem programados para serem rotacionados.

Espera-se que os valores que identificam instâncias válidas do Atestado do Azure sejam alterados quando os certificados de assinatura de código forem rotacionados ou quando as atualizações de segurança vierem a requerer novas versões de política. A equipe do Atestado do Azure seguirá a programação de distribuição abaixo para cada rotação planejada:

i. A equipe de Atestado do Azure notifica os consumidores sobre os novos valores com um período de carência de dois meses para implementar alterações de código relevantes

ii. Após o período de carência de dois meses, o Atestado do Azure começa a usar os novos valores.

iii. Três meses após a data de notificação, o Atestado do Azure para de usar os valores antigos.

Para rotações não planejadas, incluindo aquelas exigidas por atualizações de segurança, a equipe de Atestado do Azure comunica novos valores com um período de carência de um mês.

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 integrado no qual os clientes não precisam tomar nenhuma providência extra para a recuperação.
• O Gerenciador de Tráfego do Azure para a região detectará se a investigação de integridade foi degradada e alternará o ponto de extremidade para a região emparelhada.
• As conexões existentes não funcionarão e enfrentarão erros internos do servidor ou problemas 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 do plano de dados, incluindo chamadas de autenticação 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