Este artigo fornece respostas para algumas das perguntas mais comuns sobre o Atestado do Azure.
Se o seu problema com o Azure não foi abordado neste artigo, você também pode enviar uma solicitação de suporte do Azure na página de suporte do Azure.
O que é o gerenciamento de identidade de hardware confiável (THIM) e sua função no atestado de enclave?
O THIM (gerenciamento de identidades de hardware confiável) efetua fetch na linha de base de segurança do Azure para os nós do Azure Confidential Computing (ACC) da Intel e armazena os dados em cache. O Atestado do Azure também usa as informações armazenadas em cache na validação de TEEs (Ambientes de Execução Confiável).
O THIM é recomendado pelos seguintes motivos:
- Oferece alta disponibilidade
- Reduz as dependências de serviços hospedados externamente e conectividade com a Internet.
- Periodicamente busca as versões mais recentes de certificados Intel, CRLs, informações de Base de Computação Confiável (TCB) e a identidade do Enclave de Cotação dos nós ACC da Intel. O serviço confirma a linha de base de segurança do Azure a ser referenciada pelo Atestado do Azure ao validar os TEEs, reduzindo consideravelmente as falhas de atestado devido à invalidação ou à revogação de certificados Intel.
O atestado SGX (Software Guard Extensions) é suportado pelo Atestado do Azure em ambientes que não são do Azure?
Não. O Atestado do Azure depende da linha de base de segurança declarada pelo gerenciamento de identidade de hardware confiável (THIM) para validar o TEEs. Atualmente, o THIM foi projetado para dar suporte apenas a nós de computação confidencial do Azure.
Que validações o Atestado do Azure executa para atestar enclaves SGX?
Durante o processo de atestado do SGX, Atestado do Azure executa as seguintes validações:
- Valida se a raiz confiável de uma citação de enclave assinada pertence à Intel
- Ele valida se a citação TEE atende à linha de base de segurança do Azure, conforme definido pelo gerenciamento de identidades de hardware confiável (THIM)
- Se o cliente criou um provedor de atestado e configurou uma política personalizada, além das validações acima, Atestado do Azure avaliará a citação do TEE em relação à política de atestado. Os clientes podem usar políticas de atestado para definir regras de autorização para o TEE e também determinam as regras de emissão para gerar o token de atestado.
Como um verificador pode obter o material de apoio para o atestado de SGX com suporte do Atestado do Azure?
Em geral, para os modelos de atestado com a Intel como a raiz de confiança, o cliente de atestado conversa com as APIs do enclave para buscar a evidência de enclave. As APIs do enclave internamente chamam o serviço de cache Intel PCK para buscar certificados Intel do nó a ser atestado. Os certificados são usados para assinar a evidência de enclave, gerando assim um material de apoio que pode ser atestado remotamente.
O mesmo processo pode ser implementado para o Atestado do Azure. No entanto, para colher os benefícios oferecidos pelo gerenciamento de identidade de hardware confiável (THIM), 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 enclave são redirecionadas do serviço de cache do Intel PCK para o THIM. A Biblioteca DCAP do Azure tem suporte em ambientes baseados no Windows e no Linux.
Como posso alternar para o Atestado do Azure a partir de outros modelos de atestado SGX?
- Depois de instalar a máquina virtual de computação confidencial do Azure, instale a Biblioteca DCAP do Azure (Windows/ Linux) para colher os benefícios oferecidos pelo gerenciamento de identidade de hardware confiável (THIM).
- O cliente de atestado remoto precisa ser criado, o que pode recuperar a evidência de 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 ponto de extremidade da API de atestado SGX. O token de acesso do Microsoft Entra não é um parâmetro obrigatório para executar o atestado SGX na versão 2020-10-01 da API.
Como a terceira parte confiável pode verificar a integridade do token de atestado e confirmar se o Atestado do Azure está em execução em um enclave?
O token de atestado gerado por Atestado do Azure é assinado usando um certificado autoassinado. Os certificados de autenticação são expostos por meio de um ponto de extremidade de metadados OpenID. A parte de confiança pode recuperar os certificados de autenticação desse ponto de extremidade e executar a verificação de assinatura do token de atestado. O certificado de autenticação também inclui uma cota de SGX do TEE, no qual o Atestado do Azure é executado. Se a terceira parte confiável também preferir verificar se o Atestado do Azure está sendo executado em um enclave de SGX válido, a cota de SGX poderá ser recuperada do certificado de autenticação e validada localmente. Para obter mais informações, consulte exemplos de código.
Por quanto tempo um token de atestado é válido?
O tempo de validade do token de atestado é de 8 horas. No momento, não há provisionamento para personalizar o valor.
Como identificar o certificado a ser usado para verificação de assinatura do ponto de extremidade de metadados OpenID
Vários certificados expostos no ponto de extremidade de metadados OpenID correspondem a diferentes casos de uso (por exemplo, atestado SGX) com suporte do Atestado do Azure. De acordo com os padrões especificados pelo RFC 7515,o certificado com a ID de chave (filho) correspondente ao parâmetro dofilho no título do token de atestado deve ser usado para verificação de assinatura. Se nenhum filho correspondente for encontrado, espera-se que ele tente todos os certificados expostos pelo ponto de extremidade de metadados OpenID.
É possível que a parte confiável compartilhe segredos com os Ambientes de Execução Confiáveis (TEEs) validados?
No momento da criação de evidências do TEE, o código em execução dentro do 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 chave como cadeia de caracteres JWKS JSON 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 do TEE, o Atestado do Azure gera JWT com o JWKS disponível como uma declaração chamada "chaves" na declaração "x-ms-runtime". O RunTimeData pode ser mais usado pela terceira parte confiável para estabelecer um canal seguro e transmitir dados com segurança para o TEE.
Em que local o Atestado do Azure armazena os dados do cliente?
O Atestado do Azure armazena dados inativos do cliente, durante o processamento e a replicação para fins de BCDR na geografia em que o cliente implanta a instância de serviço.