Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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 suporta a atestação das plataformas suportadas por Módulos de Plataforma Confiável (TPMs), juntamente com a capacidade de atestar o estado dos Ambientes de Execução Confiável (TEEs), como enclaves Intel® Software Guard Extensions (SGX), enclaves de Segurança Baseada em Virtualização (VBS), Módulos de Plataforma Confiável (TPMs),lançamento confiável para VMs 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 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, alojados em Azure Container Instances e em Azure Kubernetes Service (em pré-visualização), oferecem a capacidade de executar grupos de containers num ambiente de execução confiável SEV-SNP protegido que isola esse grupo de contentores do plano de controlo de gestão de contentores e de outros containers 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. Podes realizar esta tarefa com o contentor SKR sidecar ou compilá-lo diretamente na lógica da tua aplicação. O relatório de hardware pode então ser partilhado com o Azure Attestation e com o HSM gerido ou o Azure Key Vault (AKV) Premium para obter segredos. Também pode fornecer o relatório de hardware ao seu próprio sistema de gestão de chaves, se assim o pretender.
Atestação de Lançamento Confiável
Os clientes do Azure podem prevenir infeções por bootkit e rootkit ao ativar o lançamento confiável das suas máquinas virtuais (VMs). Quando a VM está ativada com Secure Boot e vTPM com a extensão de guest attestation instalada, as medições do vTPM são submetidas periodicamente ao Azure Attestation para monitorização da integridade do arranque. Uma falha de atestação indica potencial malware, que é apresentado aos clientes através do Microsoft Defender para a Cloud, através de Alertas e Recomendações.
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.
Atestação Open Enclave
O Open Enclave (OE) é um conjunto de bibliotecas destinado a criar uma abstração unificada única de enclaves para que os programadores possam construir aplicações baseadas em TEE. Oferece um modelo universal de aplicação segura que minimiza as especificidades da plataforma. 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.
A OE padroniza requisitos específicos para a verificação de provas de um enclave. Isto qualifica o OE como um consumidor de atestados altamente adequado para o Azure Attestation.
Azure Attestation corre num 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, do ponto de vista operacional, fora da base informática de confiança (TCB), as operações críticas do Azure Attestation, como a validação de quotes, a geração de tokens, a avaliação de políticas e a assinatura de tokens, são transferidas para contentores confidenciais baseados em AMD SEV-SNP.
Porque usar o Azure Attestation
O Azure Attestation é a escolha preferida para atestar TEEs, pois oferece os seguintes benefícios:
- Estrutura unificada para atestar vários ambientes, 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 quando estão a ser utilizados através da implementação num TEE.
- 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. Para mais informações, consulte exemplos de código.
- Verifique se Azure Attestation está a correr dentro de um contentor SEV-SNP - Os certificados de assinatura de tokens incluem informações sobre o TEE dentro do qual Azure Attestation corre. Esta informação auxiliar do TEE é um relatório SEV-SNP. A parte confiadora pode verificar se o Azure Attestation está a correr dentro de um TEE válido, através da validação local do relatório. Para exemplos de código, veja SEV-SNP.
- Validar a ligação do relatório Azure Attestation TEE com a chave que assinou o token de atestação - A parte confiável pode verificar se o hash da chave pública que assinou o token de atestação corresponde ao campo de dados do relatório Azure Attestation TEE. Para mais informações, consulte o exemplo de código.
- 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 confiante pode validar que o relatório pertence ao Azure Attestation comparando valores específicos obtidos dos dados auxiliares do TEE no certificado de assinatura do token de atestação com os valores fornecidos pela equipa do Azure Attestation. Para SEV-SNP, HOST_DATA deve ser validado. Para mais informações, consulte o exemplo de código. Se estiver interessado em realizar esta validação, submeta 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.
- Obtenha garantia na proveniência das builds - O Azure Attestation está integrado com o Signing Transparency (MST) da Microsoft. O MST regista assinaturas de código num registo imutável e à prova de adulterações. O serviço MST fornece recibos criptograficamente verificáveis e compatíveis com SCITT, que proporcionam uma visibilidade clara sobre as implementações do Azure Attestation — reforçando a confiança, a auditabilidade e a conformidade regulatória. Para saber mais sobre o MST e como validar artefactos de construção, consulte Acerca do Microsoft Signing Transparency ledger.
Espera-se que os valores que identificam instâncias válidas do Azure Attestation mudem quando os certificados de assinatura de código são rotacionados ou quando as atualizações de segurança exigem novas versões de políticas. A equipa do Azure Attestation segue este calendário de implementação para cada rotação planeada:
- A equipa do Azure Attestation notifica os consumidores dos novos valores com um período de carência de dois meses para implementar alterações relevantes ao código.
- Após o período de tolerância de dois meses, o Azure Attestation começa a usar os novos valores.
- 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.
Apoio à continuidade do negócio 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. No caso de uma falha ou indisponibilidade de uma região, ocorre o seguinte:
- O Azure Attestation BCDR proporciona uma recuperação transparente, na qual os clientes não precisam tomar quaisquer medidas adicionais para recuperarem.
- O Gestor de Tráfego do Azure para a região deteta que a sonda de saúde está degradada e muda o endpoint para a região emparelhada.
- As ligações existentes não funcionam e apresentam erros de servidor interno ou problemas de tempo limite.
- Todas as operações no plano de controlo estão bloqueadas. Os clientes não podem criar fornecedores 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, são servidas pela região secundária. Os clientes podem continuar a trabalhar nas operações do plano de dados com o URI original correspondente à região primária.