Partilhar via


Microsoft Azure Attestation

O Atestado do Microsoft Azure é uma solução unificada para verificar remotamente a confiabilidade de uma plataforma e a integridade dos binários executados dentro dela. O serviço oferece suporte ao atestado das plataformas apoiadas por TPMs (Trusted Platform Modules), juntamente com a capacidade de atestar o estado de TEEs (Trusted Execution Environments), como enclaves Intel® Software Guard Extensions (SGX), enclaves VBS (Virtualization-based Security), TPMs (Trusted Platform Modules), inicialização confiável para VMs do Azure e VMs confidenciais do Azure.

O atestado é um processo para demonstrar que os binários de software foram instanciados corretamente em uma plataforma confiável. As partes confiadoras remotas podem, então, obter confiança de que apenas o software pretendido está sendo executado em hardware confiável. O Atestado do Azure é um serviço e uma estrutura unificados voltados para o cliente para atestado.

O Atestado do Azure permite paradigmas de segurança de ponta, como a computação Confidencial do Azure e a proteção da Borda Inteligente. Os clientes têm solicitado a capacidade de verificar independentemente a localização de uma máquina, a postura de uma máquina virtual (VM) nessa máquina e o ambiente no qual os enclaves estão sendo executados nessa VM. O Atestado do Azure habilita 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 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).

O Atestado do Azure dá suporte ao atestado de plataforma e convidado de VMs confidenciais (CVMs) baseadas em AMD SEV-SNP. O atestado de plataforma baseado em Atestado do Azure acontece automaticamente durante o caminho de inicialização crítico dos CVMs, sem necessidade de ação do cliente. Para obter mais informações sobre o atestado de convidado, consulte Anunciando a disponibilidade geral do atestado de convidado para VMs confidenciais.

Casos de utilização

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

Atestado AMD SEV-SNP 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 VM OS com chaves gerenciadas por plataforma ou chaves gerenciadas pelo cliente e vincula as chaves de criptografia de disco ao TPM da máquina virtual. Quando um CVM é inicializado, o relatório SNP contendo as medições de firmware da VM convidada será 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 Managed-HSM ou do Azure Key Vault. Essas chaves são usadas para descriptografar o estado vTPM da VM convidada, desbloquear o disco do sistema operacional e iniciar o CVM. O processo de atestado e liberação de chaves é realizado automaticamente em cada inicialização do CVM, e o processo garante que o CVM inicialize 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. Os contêineres confidenciais, hospedados nas Instâncias de Contêiner do Azure e no Serviço Kubernetes do Azure (em visualização), 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 outros contêineres em execução. O atestado em contêineres confidenciais envolve a busca do relatório de atestado de hardware da AMD diretamente do processador. Isso pode ser feito com nosso contêiner de sidecar SKR ou compilado diretamente em sua lógica de aplicação. O relatório de hardware pode ser trocado com o Atestado do Azure e gerenciado-HSM ou Premium Azure Key Vault (AKV) para recuperar segredos. Você também pode fornecer o relatório de hardware para seu próprio sistema de cofre de chaves, conforme desejado.

Atestado de lançamento confiável

Os clientes do Azure podem evitar infeções por bootkit e rootkit habilitando a inicialização confiável para suas máquinas virtuais (VMs). Quando a VM é Inicialização Segura e vTPM habilitado com a extensão de atestado convidado instalada, as medições vTPM são enviadas ao Atestado do Azure periodicamente para monitorar a integridade da inicialização. Uma falha no atestado indica um potencial malware, que é apresentado aos clientes por meio do Microsoft Defender for Cloud, por meio de Alertas e Recomendações.

Atestado de TPM

O atestado baseado em TPM (Trusted Platform Modules) é fundamental para fornecer prova do estado de uma plataforma. Um TPM atua como a raiz da confiança e o coprocessador de segurança para fornecer validade criptográfica às medições (evidências). Os dispositivos com um TPM podem confiar no atestado para provar que a integridade da inicialização não está comprometida e usar as declarações para detetar a ativação do estado do recurso durante a inicialização.

Os aplicativos cliente podem ser projetados para tirar proveito do atestado TPM, delegando tarefas sensíveis à segurança para que só ocorram depois que uma plataforma tiver sido validada para ser segura. Esses aplicativos podem usar o Atestado do Azure para estabelecer rotineiramente a confiança na plataforma e sua capacidade de acessar dados confidenciais.

Atestado de enclave SGX

Intel® Software Guard Extensions (SGX) refere-se ao isolamento de nível de hardware, que é suportado em determinados modelos de CPU Intel. O SGX permite que o código seja executado em compartimentos higienizados conhecidos como enclaves SGX. As permissões de acesso e memória são entã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 SGX, delegando tarefas sensíveis à segurança para ocorrer dentro desses enclaves. Esses aplicativos podem usar o Atestado do Azure para estabelecer rotineiramente a confiança no enclave e sua capacidade de acessar dados confidenciais.

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

Nota

Para executar o atestado de plataformas de servidor baseadas no processador Intel® Xeon® Scalable usando o Atestado do Azure, os usuários devem instalar o Azure DCAP versão 1.10.0 ou superior.

Atestado de Enclave Aberto

Open Enclave (OE) é uma coleção de bibliotecas destinadas a criar uma única abstração de enclave unificada para desenvolvedores criarem aplicativos baseados em TEE. Ele oferece um modelo de aplicativo seguro universal que minimiza as especificidades da plataforma. A Microsoft vê isso como um trampolim essencial para democratizar tecnologias de enclave baseadas em hardware, como SGX, e aumentar sua aceitação no Azure.

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

O Atestado do Azure é executado em um TEE

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

  • Verifica se as provas 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 pelas partes confiáveis 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 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 opção 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 provedores de atestado personalizados e a configuração de políticas para restringir a geração de tokens.
  • Protege seus dados enquanto estiver em uso com implementação em um enclave SGX ou máquina virtual confidencial baseada 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 assinatura é exposta por meio de um ponto de extremidade de metadados OpenID. A terceira parte confiável pode recuperar o certificado de assinatura e executar a verificação de assinatura do token de atestado. Consulte exemplos de código para obter mais informações
  2. Verifique se o Atestado do Azure está sendo executado dentro de um enclave SGX - Os certificados de assinatura de token incluem a cotação SGX do TEE dentro do qual o Atestado do Azure é executado. Se a terceira parte confiável preferir verificar se o Atestado do Azure está sendo executado dentro de um enclave SGX válido, a cotação SGX poderá ser recuperada do certificado de assinatura e validada localmente. Consulte exemplos de código para obter mais informações
  3. Validar a associação da cotação 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 do relatório da cotação SGX do Atestado do Azure. Consulte exemplos de código para obter mais informações
  4. Validar se as medições do código de Atestado do Azure correspondem aos valores publicados do Azure - A cotação SGX incorporada nos certificados de assinatura de token de atestado inclui medições de código do Atestado do Azure, como MRSIGNER. Se a terceira parte confiável estiver interessada em validar se a cotação SGX pertence ao Atestado do Azure em execução dentro do Azure, o valor MRSIGNER pode ser recuperado da cotação SGX no certificado de assinatura de token de atestado e comparado com o valor fornecido pela equipe de Atestado do Azure. Se você estiver interessado em executar essa validação, envie uma solicitação na página de suporte do Azure. A equipe de Atestado do Azure entrará em contato com você quando planejarmos girar o MRSIGNER.

Espera-se que o signatário do Atestado do Azure mude quando os certificados de assinatura de código forem rotacionados. A equipe de Atestado do Azure segue o cronograma de distribuição abaixo para cada rotação mrsigner:

i. A equipe de Atestado do Azure notifica o próximo valor MRSIGNER com um período de carência de dois meses para fazer 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 o novo valor MRSIGNER

iii. Três meses após a data de notificação, o Atestado do Azure para de usar o valor MRSIGNER antigo

Suporte a BCDR (Business Continuity and Disaster Recovery, recuperação de desastres)

O BCDR (Business Continuity and Disaster Recovery ) para Atestado do Azure permite mitigar interrupções de serviço resultantes de problemas significativos de disponibilidade ou eventos de desastre em uma região.

Os clusters implantados em duas regiões operam de forma independente em circunstâncias normais. No caso de uma falha ou interrupção de uma região, ocorre o seguinte:

  • O BCDR de Atestado do Azure fornece failover contínuo no qual os clientes não precisam executar nenhuma etapa extra para se recuperar.
  • O Gerenciador de Tráfego do Azure para a região detetará que a investigação de integridade está degradada e alternará o ponto de extremidade para região emparelhada.
  • As conexões existentes não funcionarão e receberão erros internos do servidor ou problemas de tempo limite.
  • Todas as operações do avião de controlo serão bloqueadas. Os clientes não poderão criar provedores de atestado 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 por região secundária. Os clientes podem continuar a trabalhar em operações de plano de dados com o URI original correspondente à região primária.

Próximos passos