Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
O Microsoft Azure Attestation é 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 oferece suporte à atestação das plataformas apoiadas por Trusted Platform Modules (TPMs) junto com a capacidade de atestar o estado dos Ambientes de Execução Confiável (TEEs), como enclaves das Intel® Software Guard Extensions (SGX), enclaves de Segurança Baseada em Virtualização (VBS), Trusted Platform Modules (TPMs), Lançamento confiável para VMs do Azure e VMs confidenciais do Azure.
A certificação é um processo para demonstrar que os binários de software foram instanciados corretamente numa plataforma confiável. As partes confiáveis remotas podem então ganhar confiança de que apenas tal software pretendido está a executar em hardware confiável. O Azure Attestation é um serviço unificado voltado para o cliente e uma estrutura para atestação.
O Azure Attestation possibilita paradigmas de segurança de ponta, como Azure Confidential computing e proteção Intelligent Edge. O serviço recebe evidências de entidades computacionais, transforma-as num conjunto de alegações, valida-as contra políticas configuráveis e produz provas criptográficas para aplicações baseadas em reivindicações (por exemplo, partes confiantes e autoridades de auditoria).
O Azure Attestation suporta tanto a atestação de plataforma quanto a atestação de convidados de VMs Confidenciais (CVMs) baseadas em AMD SEV-SNP. A atestação da plataforma baseada em Azure Attestation acontece automaticamente durante o caminho de arranque crítico dos CVMs, sem necessidade de ação por parte do cliente. Para mais informações sobre a attestation de convidados, consulte Annunciando a disponibilidade geral de attestation de convidados para VMs confidenciais.
Casos de uso
Azure Attestation fornece serviços de atestação abrangentes para múltiplos ambientes e casos de uso distintivos.
Atestação AMD SEV-SNP em VMs Confidenciais
Azure Confidential VM (CVM) é baseado em processadores AMD com tecnologia SEV-SNP. A CVM oferece uma opção de encriptação de disco do SO da VM com chaves geridas pela plataforma ou chaves geridas pelo cliente e associa as chaves de encriptação do disco ao TPM da máquina virtual. Quando uma CVM é iniciada, o relatório SNP contendo as medições de firmware da VM de convidado é enviado para o Azure Attestation. O serviço valida as medições e emite um token de atestação que é usado para libertar chaves de Managed-HSM ou Azure Key Vault. Estas chaves são usadas para desencriptar o estado do vTPM da VM convidada, desbloquear o disco do sistema operativo e iniciar o CVM. O processo de atestação e liberação de chave é realizado automaticamente a cada inicialização do CVM, e assegura que o CVM arranque apenas após a atestação bem-sucedida do hardware.
Comprovação AMD SEV-SNP em Contêineres Confidenciais
Azure Confidential Containers é baseado em processadores AMD com tecnologia SEV-SNP. Contentores confidenciais, hospedados no Azure Container Instances e no Azure Kubernetes Service (em pré-visualização), oferecem a capacidade de executar grupos de contentores num ambiente de execução confiável protegido por SEV-SNP, que isola esse grupo de contentores do plano de controlo de gestão de contentores e de outros contentores em execução. A autenticação em contentores confidenciais envolve a obtenção do relatório de autenticação de hardware AMD diretamente do processador. This can be accomplished with our SKR sidecar container or compiled directly into your application logic. O relatório de hardware pode então ser trocado com o Azure Attestation e o managed-HSM ou o Azure Key Vault (AKV) Premium para obter segredos. You can also provide the hardware report to your own key vault system as desired.
Atestação de Lançamento Confiável
Azure customers can prevent bootkit and rootkit infections by enabling trusted launch for their virtual machines (VMs). When the VM is Secure Boot and vTPM enabled with guest attestation extension installed, vTPM measurements get submitted to Azure Attestation periodically for monitoring boot integrity. An attestation failure indicates potential malware, which is surfaced to customers via Microsoft Defender for Cloud, through Alerts and Recommendations.
Atestação TPM
O atestado baseado em Trusted Platform Modules (TPM) é fundamental para fornecer prova do estado de uma plataforma. Um TPM atua como a raiz de confiança e o coprocessador de segurança para fornecer validade criptográfica às medições (evidências). Dispositivos com um TPM podem contar com a atestação para provar que a integridade do arranque não foi comprometida e utilizar as declarações para detectar a ativação de estado de funcionalidade durante o arranque.
As aplicações cliente podem ser projetadas para tirar proveito da atestação TPM, delegando tarefas sensíveis à segurança para serem realizadas apenas depois que a plataforma tiver sido validada como segura. Essas aplicações podem então utilizar o Azure Attestation para estabelecer rotineiramente confiança na plataforma e na sua capacidade de aceder a dados sensíveis.
Atestado de enclave SGX
Intel® Software Guard Extensions (SGX) refere-se a isolamento de nível de hardware, que é suportado em certos modelos de CPU Intel. O SGX permite que o código seja executado em compartimentos sanitizados conhecidos como enclaves SGX. As permissões de acesso e memória são então geridas por hardware para garantir uma superfície de ataque mínima com o devido isolamento.
As aplicações cliente podem ser projetadas para tirar proveito das enclaves SGX delegando tarefas sensíveis à segurança para que ocorram dentro dessas enclaves. Essas aplicações podem, então, utilizar a Atuação Azure para estabelecer rotineiramente a confiança no enclave e na sua capacidade de acessar dados sensíveis.
Os processadores Intel® Xeon® Scalable suportam apenas soluções de atestação baseadas em ECDSA para atestar remotamente os enclaves SGX. Utilizando o modelo de atestação baseado em ECDSA, o Azure Attestation suporta a validação de processadores Intel® Xeon® E3 e plataformas de servidores baseadas em processadores escaláveis Intel® Xeon®.
Nota
Para realizar a atestação de plataformas de servidores com processadores Intel® Xeon® Scalable usando o Azure Attestation, os utilizadores devem instalar a Azure DCAP versão 1.10.0 ou superior.
Open Enclave attestation
Open Enclave (OE) is a collection of libraries targeted at creating a single unified enclaving abstraction for developers to build TEE-based applications. It offers a universal secure app model that minimizes platform specificities. A Microsoft vê isso como um passo crucial para democratizar as tecnologias de enclave baseadas em hardware, como o SGX, e aumentar a sua adoção no Azure.
OE standardizes specific requirements for verification of an enclave evidence. Isto qualifica o OE como um consumidor de atestados altamente adequado para o Azure Attestation.
Azure Attestation runs in a TEE
O Azure Attestation é crucial para cenários de Computação Confidencial, pois realiza as seguintes ações:
- Verifica se a evidência da enclave é válida.
- Avalia as evidências do enclave em relação a uma política definida pelo cliente.
- Gere e armazena políticas específicas do inquilino.
- Gera e assina um token que é usado por partes confiáveis para interagir com o enclave.
Para manter a Microsoft operacionalmente fora da base de computação confiável (TCB), operações críticas da Azure Attestation, como validação de cotações, geração de tokens, avaliação de políticas e assinaturas de tokens, são transferidas para um enclave SGX.
Porque usar o Azure Attestation
Azure Attestation is the preferred choice for attesting TEEs as it offers the following benefits:
- Estrutura unificada para a atestação de múltiplos ambientes, tais como TPMs, enclaves SGX e enclaves VBS.
- Permite a criação de fornecedores de atestação personalizados e a configuração de políticas para restringir a geração de tokens.
- Protege os seus dados em uso com a implementação num enclave SGX ou numa Máquina Virtual Confidencial baseada em AMD SEV-SNP.
- Serviço altamente disponível
Como estabelecer confiança com o Azure Attestation
- Verifique se o token de atestado é gerado pelo Azure Attestation - Um token de atestado gerado pelo Azure Attestation é assinado usando um certificado autoassinado. O URL dos certificados de assinatura é disponibilizado através de um OpenID metadata endpoint. Uma parte confiável pode recuperar o certificado de assinatura e realizar a verificação da assinatura do token de atestado. Veja exemplos de código para mais informações.
- Verificar se o Atestado do Azure está sendo executado dentro de um enclave SGX ou contêiner SEV-SNP - Os certificados de assinatura de token incluem informações sobre o TEE dentro do qual o Atestado do Azure é executado. Este colateral TEE pode ser uma cotação SGX ou um relatório SEV-SNP. A parte confiável pode verificar se o Azure Attestation está a correr dentro de um TEE válido, validando localmente a citação ou o relatório. Consulte os exemplos de código para mais informações – SGX, SEV-SNP
- Validar a associação do relatório TEE de Atestado do Azure com a chave que assinou o token de atestado – A parte confiável pode verificar se o hash da chave pública que assinou o token de atestado corresponde ao campo de dados do relatório TEE de Atestado do Azure. Consulte here para mais detalhes.
- Validar se as medições de código de Azure Attestation correspondem aos valores publicados pela Azure - O colateral TEE incorporado nos certificados de assinatura de token de atestado inclui medições de código TEE do Azure Attestation. Uma parte dependente pode validar que a cotação ou relatório pertence ao Azure Attestation ao comparar valores específicos retirados do colateral TEE no certificado de assinatura do token de atestação com valores fornecidos pela equipa do Azure Attestation. Para o SGX, o MRSIGNER deve ser validado. Para SEV-SNP, HOST_DATA deve ser validado. Consulte aqui para mais detalhes. Se estiver interessado em realizar esta validação, envie um pedido na página de suporte do Azure. A equipa do Azure Attestation entra em contacto consigo quando estes valores específicos estão programados para rotação.
The values identifying valid Azure Attestation instances are expected to change when code-signing certificates are rotated or when security updates require new policy versions. A equipa de Certificação do Azure segue o cronograma de lançamento abaixo para cada rotação planeada:
i. A equipa do Azure Attestation notifica os consumidores sobre os novos valores com um período de carência de dois meses para implementar as alterações de código relevantes.
ii. Após o período de tolerância de dois meses, o Azure Attestation começa a usar os novos valores.
iii. Três meses após a data de notificação, o Azure Attestation deixa de usar os valores antigos.
Para rotações não planeadas, incluindo aquelas exigidas por atualizações de segurança, a equipa de Certificação Azure comunica os novos valores com um período de tolerância de um mês.
Suporte de Continuidade de Negócios e Recuperação de Desastres (BCDR)
Continuidade de Negócio e Recuperação de Desastres (BCDR) para Azure Attestation permite mitigar interrupções de serviço resultantes de problemas significativos de disponibilidade ou de desastres numa região.
Clusters implantados em duas regiões operam de forma independente em circunstâncias normais. In the case of a fault or outage of one region, the following takes place:
- O Azure Attestation BCDR proporciona uma recuperação transparente, na qual os clientes não precisam tomar quaisquer medidas adicionais para recuperarem.
- O Azure Traffic Manager para a região irá detectar que a sonda de saúde está degradada e muda o ponto final para a região emparelhada.
- As ligações existentes não funcionarão e receberão erro interno do servidor ou problemas de tempo de espera.
- Todas as operações do plano de controlo serão bloqueadas. Os clientes não poderão criar provedores de atestação na região principal.
- Todas as operações do plano de dados, incluindo chamadas de atestado e configuração de políticas, serão atendidas pela região secundária. Customers can continue to work on data plane operations with the original URI corresponding to primary region.