Perguntas frequentes sobre o Atestado do Microsoft Azure

O THIM (Trusted Hardware Identity Management, gerenciamento de identidade de hardware confiável) busca a linha de base de segurança do Azure para os nós de computação confidencial (ACC) do Azure da Intel e armazena os dados em cache. As informações armazenadas em cache serão usadas pelo Atestado do Azure na validação de TEEs (Ambientes de Execução Confiáveis).

O THIM é recomendado pelas seguintes razões:

• Oferece alta disponibilidade
• Reduz as dependências de serviços hospedados externamente e conectividade com a Internet.
• Busca periodicamente as versões mais recentes dos certificados Intel, CRLs, informações da Trusted Computing Base (TCB) e identidade do Enclave de Cotação dos nós ACC da Intel. Portanto, o serviço confirma a linha de base de segurança do Azure a ser encaminhada pelo Atestado do Azure durante a validação dos TEEs, reduzindo consideravelmente as falhas de atestado devido à invalidação ou revogação de certificados Intel

Não O Atestado do Azure depende da linha de base de segurança declarada pelo THIM (Trusted Hardware Identity Management) para validar os TEEs. Atualmente, o THIM foi projetado para dar suporte apenas a nós de computação Confidenciais do Azure.

Durante o processo de atestado SGX, o Atestado do Azure executa as seguintes validações:

• Valida se a raiz confiável da cotação de enclave assinada pertence à Intel
• Valida se a cotação TEE atende à linha de base de segurança do Azure, conforme definido pelo THIM (Trusted Hardware Identity Management, gerenciamento de identidade de hardware confiável)
• Se o cliente criou um provedor de atestado e configurou uma política personalizada, além das validações acima, o Atestado do Azure avaliará a cotação TEE em relação à política de atestado. Usando políticas de atestado, os clientes podem definir regras de autorização para o TEE e também ditar regras de emissão para gerar o token de atestado

Em geral, para os modelos de atestado com a Intel como a raiz da confiança, o cliente de atestado conversa com APIs de enclave para buscar a evidência do enclave. As APIs de enclave chamam internamente o serviço de cache Intel PCK para buscar certificados Intel do nó a ser atestado. Os certificados são usados para assinar as provas do enclave, gerando assim uma garantia remotamente atestável.

O mesmo processo pode ser implementado para o Atestado do Azure. No entanto, para aproveitar os benefícios oferecidos pelo THIM (Trusted Hardware Identity Management), depois de instalar a máquina virtual ACC, é recomendável instalar a biblioteca DCAP do Azure. Com base no contrato com a Intel, quando a biblioteca DCAP do Azure é instalada, as solicitações para gerar evidências de enclave são redirecionadas do serviço de cache Intel PCK para THIM. A biblioteca DCAP do Azure é suportada em ambientes baseados em Windows e Linux.

• Depois de instalar a máquina virtual de computação confidencial do Azure, instale a biblioteca DCAP do Azure (Windows/Linux) para aproveitar os benefícios oferecidos pelo THIM (Trusted Hardware Identity Management).
• O cliente de atestado remoto precisa ser criado, o que pode recuperar as evidências do enclave e enviar solicitações para o Atestado do Azure. Consulte exemplos de código para referência
• As solicitações de atestado podem ser enviadas para o ponto de extremidade da API REST de provedores padrão ou provedores de atestado personalizados
• Na versão 2018-09-01-preview da API, o cliente precisa enviar o token de acesso do Microsoft Entra junto com as evidências para o endpoint da API de atestado SGX. O token de acesso Microsoft Entra não é um parâmetro necessário para executar o atestado SGX na versão 2020-10-01 API

O token de atestado gerado pelo Atestado do Azure é assinado usando um certificado autoassinado. Os certificados de assinatura são expostos através de um ponto final de metadados OpenID. A terceira parte confiável pode recuperar os certificados de assinatura desse ponto de extremidade e executar a verificação de assinatura do token de atestado. O certificado de assinatura também inclui a cotação SGX do TEE dentro do qual o Atestado do Azure é executado. Se a terceira parte confiável também 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

O tempo de validade do token de atestado é de 8 horas. Atualmente, não há nenhuma disposição para personalizar o valor.

Vários certificados expostos no ponto de extremidade de metadados OpenID correspondem a diferentes casos de uso (por exemplo, atestado SGX) suportados pelo Atestado do Azure. De acordo com os padrões especificados pelo RFC 7515, o certificado com ID de chave (kid) correspondente ao parâmetro kid no cabeçalho do token de atestado deve ser usado para verificação de assinatura. Se nenhum kid correspondente for encontrado, espera-se que ele tente todos os certificados expostos pelo endpoint de metadados OpenID.

No momento da criação da evidência TEE, o código executado dentro da TEE pode incluir informações arbitrárias na evidência. Por exemplo, o TEE pode criar um ou mais pares de chaves assimétricas, serializar os componentes de chave pública desses pares de chaves como cadeia de caracteres JSON JWKS e incluir a cadeia de caracteres JSON JWKS na evidência TEE como RunTimeData { quote, JWKS JSON string }. O Atestado do Azure verifica se o hash SHA256 do RuntimeData corresponde aos 32 bytes inferiores do atributo "dados de relatório" da citação. Após avaliar a evidência TEE, o Atestado do Azure gera JWT com o JWKS disponível como uma declaração chamada "chaves" sob a declaração "x-ms-runtime". O RunTimeData pode ser usado ainda mais pela terceira parte confiável para estabelecer um canal seguro e transmitir dados com segurança para o TEE.

O Atestado do Azure armazena dados do cliente em repouso, durante o processamento e a replicação para fins de BCDR dentro da geografia em que o cliente implanta a instância de serviço.