Gerenciamento de identidade de hardware confiável

O serviço Gerenciamento de Identidade de Hardware Confiável lida com o gerenciamento de cache de certificados para todos os ambientes de execução confiáveis (TEEs) que residem no Azure. Ele também fornece informações da base de computação confiável (TCB) para impor uma referência mínima para soluções de certificação.

Gestão de identidade de hardware fiável e interações de certificação

A Gestão de Identidade de Hardware Confiável define a linha de base de segurança do Azure para os nós de computação confidencial (ACC) do Azure e armazena em cache informações de garantia de fornecedores TEE. Os serviços de atestado e os nós ACC podem usar as informações armazenadas em cache para validar TEEs. O diagrama a seguir mostra as interações entre um serviço ou nó de atestado, o "Trusted Hardware Identity Management" e um host de enclave.

Perguntas mais frequentes

Como faço para usar o Trusted Hardware Identity Management com processadores Intel?

Para gerar cotações Intel SGX e Intel TDX, a Intel Quote Generation Library (QGL) precisa ter acesso à garantia de geração/validação de cotações. Toda ou partes desta garantia devem ser obtidas a partir do Trusted Hardware Identity Management. Você pode buscá-lo usando a Intel Quote Provider Library (QPL) ou a biblioteca de cliente Azure Data Center Attestation Primitives (DCAP).

A data da "próxima atualização" da API do serviço de cache interno do Azure, utilizada pelo Atestado do Azure, parece estar desatualizada. Ainda está em funcionamento e posso usá-lo?

O tcbinfo campo contém as informações do TCB. O serviço Trusted Hardware Identity Management fornece informações mais antigas tcbinfo por padrão. A atualização para as informações mais recentes tcbinfo da Intel causaria falhas de atestado para os clientes que não migraram para o SDK Intel mais recente e poderia resultar em interrupções.

O SDK do Enclave Aberto e o Atestado do Azure não examinam a nextUpdate data e mesmo assim passarão pelo atestado.

O que é a biblioteca DCAP do Azure?

A biblioteca DCAP (Azure Data Center Attestation Primitives), que substitui a Intel Quote Provider Library (QPL), obtém diretamente do serviço Trusted Hardware Identity Management a informação colateral para geração e validação de cotação. Obter garantias diretamente do serviço Trusted Hardware Identity Management garante que todos os hosts do Azure tenham garantias prontamente disponíveis na nuvem do Azure para reduzir dependências externas. Recomenda-se usar a versão mais recente disponível para o seu sistema operacional de destino.

Onde posso baixar a biblioteca DCAP do Azure mais recente?

Use os seguintes links para baixar os pacotes:

• Ubuntu 22,04
• Ubuntu 20,04
• Ubuntu 18.04
• Mac OS

Para versões mais recentes do Ubuntu (por exemplo, Ubuntu 24.04), você tem que usar o Intel QPL.

Por que o Trusted Hardware Identity Management e a Intel têm linhas de base diferentes?

O Trusted Hardware Identity Management e a Intel fornecem diferentes níveis de linha de base da base de computação confiável. Quando os clientes assumem que a Intel tem as linhas de base mais recentes, eles devem garantir que todos os requisitos sejam atendidos. Essa abordagem pode levar a uma quebra se os clientes não tiverem atualizado para os requisitos especificados.

O Trusted Hardware Identity Management adota uma abordagem mais lenta para atualizar a linha de base do TCB, para que os clientes possam fazer as alterações necessárias em seu próprio ritmo. Embora essa abordagem forneça uma linha de base TCB mais antiga, os clientes não sofrerão uma quebra se não tiverem atendido aos requisitos da nova linha de base TCB. É por isso que a linha de base TCB do Trusted Hardware Identity Management é uma versão diferente da linha de base da Intel. Queremos capacitar os clientes a atender aos requisitos da nova linha de base do TCB em seu ritmo, em vez de forçá-los a atualizar e causar uma interrupção que exigiria a repriorização dos fluxos de trabalho.

Com os processadores Intel Xeon E, eu poderia obter meus certificados diretamente dos PCS Intel. Por que, com os processadores Intel Xeon Scalable a partir da 4ª geração, preciso obter os certificados do Trusted Hardware Identity Management? E como posso buscar esses certificados?

A partir da 4ª geração de processadores escaláveis Intel® Xeon®, o Azure realiza o registro indireto no Serviço de registro da Intel usando o manifesto da plataforma e armazena o certificado PCK resultante no serviço THIM (Trusted Hardware Identity Management) O Azure usa o registro indireto, porque o serviço de registro da Intel não armazenará chaves raiz para uma plataforma neste caso e isso é refletido false no CachedKeys sinalizador em Certificados PCK. Como o registro indireto é usado, toda a comunicação seguinte com o Intel PCS exigiria o Manifesto da Plataforma, que o Azure não fornece às máquinas virtuais (VMs). Em vez disso, as VMs precisam entrar em contato com o THIM para receber certificados PCK. Para recuperar um certificado PCK, você pode usar o Intel QPL ou a biblioteca DCAP do Azure.

Como faço para usar o Intel QPL com o Trusted Hardware Identity Management?

Os clientes podem querer a flexibilidade de usar o Intel QPL para interagir com o Trusted Hardware Identity Management sem precisar baixar outra dependência da Microsoft (ou seja, a biblioteca de cliente DCAP do Azure). Os clientes que desejam usar o Intel QPL com o serviço Trusted Hardware Identity Management devem ajustar o arquivo de configuração do Intel QPL, sgx_default_qcnl.conf.

A garantia de geração/verificação de cotação usada para gerar as cotações Intel SGX ou Intel TDX pode ser dividida em:

• O certificado PCK. Para recuperá-lo, os clientes devem usar um endpoint de Gestão de Identidade de Hardware de Confiança.
• Todo o material de apoio para a geração/verificação de cotações. Para recuperá-lo, os clientes podem usar um endpoint do Trusted Hardware Identity Management ou um endpoint do Intel Provisioning Certification Service (PCS).

O ficheiro de configuração Intel QPL (sgx_default_qcnl.conf) contém três chaves para definir os endpoints colaterais. A pccs_url chave define o endpoint usado para recuperar os certificados PCK. A collateral_service chave pode definir o ponto de extremidade que é usado para recuperar todas as outras garantias de geração/verificação de cotação. Se a chave collateral_service não estiver definida, todos os elementos de verificação de cotação serão obtidos a partir do ponto de extremidade definido com a chave pccs_url.

A tabela a seguir mostra como essas chaves podem ser definidas.

O trecho de código a seguir é de um exemplo de um arquivo de configuração Intel QPL:

    { 
        "pccs_url": "https://global.acccache.azure.net/sgx/certification/v3/", 
        "use_secure_cert": true, 
        "collateral_service": "https://global.acccache.azure.net/sgx/certification/v3/",  
        "pccs_api_version": "3.1", 
        "retry_times": 6, 
        "retry_delay": 5, 
        "local_pck_url": "http://169.254.169.254/metadata/THIM/sgx/certification/v3/",
        "pck_cache_expire_hours": 24, 
        "verify_collateral_cache_expire_hours": 24, 
        "custom_request_options": { 
            "get_cert": { 
                "headers": { 
                    "metadata": "true" 
                }, 
                "params": { 
                    "api-version": "2021-07-22-preview" 
                } 
            } 
        } 
    }   

Os procedimentos a seguir explicam como alterar o arquivo de configuração do Intel QPL e ativar as alterações.

No Windows

1. Faça alterações no arquivo de configuração.

2. Verifique se há permissões de leitura para o arquivo do seguinte local do Registro e chave/valor:

   [HKEY_LOCAL_MACHINE\SOFTWARE\Intel\SGX\QCNL]
   "CONFIG_FILE"="<Full File Path>"
   

3. Reinicie o serviço AESMD. Por exemplo, abra o PowerShell como administrador e use os seguintes comandos:

   Restart-Service -Name "AESMService" -ErrorAction Stop
   Get-Service -Name "AESMService"
   

No Linux

1. Faça alterações no arquivo de configuração. Por exemplo, você pode usar o Vim para as alterações através do seguinte comando:

   sudo vim /etc/sgx_default_qcnl.conf
   

2. Reinicie o serviço AESMD. Abra qualquer terminal e execute os seguintes comandos:

   sudo systemctl restart aesmd 
   systemctl status aesmd 
   

Como solicito garantias em uma máquina virtual confidencial?

Utilize o exemplo abaixo numa máquina virtual confidencial (CVM) para solicitar ativos AMD que incluem o certificado VCEK e a cadeia de certificados. Para obter detalhes sobre essa garantia e de onde ela vem, consulte Certificado VCEK (Versioned Chip Endorsement Key) e Especificação da interface KDS.

Parâmetros de URI

GET "http://169.254.169.254/metadata/THIM/amd/certification"

Corpo do pedido

Pedido de amostra

curl GET "http://169.254.169.254/metadata/THIM/amd/certification" -H "Metadata: true"

Respostas

Definições

Como solicito colateral AMD num contêiner do serviço Azure Kubernetes num nó CVM?

Siga estas etapas para solicitar garantias da AMD em um contêiner confidencial:

1. Comece criando um cluster do Serviço Kubernetes do Azure (AKS) em um nó CVM ou adicionando um pool de nós CVM a um cluster existente:

   • Crie um cluster AKS em um nó CVM:

     1. Crie um grupo de recursos em uma das regiões suportadas pelo CVM:

        az group create --resource-group <resource-group> --location <location> 
        

     2. Crie um cluster AKS com um nó CVM no grupo de recursos:

        az aks create --name <aks-cluster-name> --resource-group <resource-group> -l <location> --node-vm-size Standard_DC4as_v5 --nodepool-name <pool-name> --node-count 1
        

     3. Configure o kubectl para se conectar ao cluster:

        az aks get-credentials --resource-group <resource-group> --name <aks-cluster-name> 
        

   • Adicione um pool de nós CVM a um cluster AKS existente:

     az aks nodepool add --cluster-name <aks-cluster-name> --resource-group <resource-group> --name <pool-name> --node-vm-size Standard_DC4as_v5 --node-count 1 
     

2. Verifique a conexão com o cluster usando o kubectl get comando. Este comando retorna uma lista dos nós do cluster.

   kubectl get nodes 
   

   O exemplo de saída a seguir mostra apenas um nó que você criou nas etapas anteriores. Verifique se o status do nó é Ready.

   NOME	ESTADO	FUNÇÕES	IDADE	VERSÃO
   AKS-NodePool1-31718369-0	Pronto	agente	6m44s	v1.12.8

3. Crie um arquivo curl.yaml com o seguinte conteúdo. Ele define um trabalho que executa um contêiner curl para buscar garantias AMD do endpoint do Trusted Hardware Identity Management. Para obter mais informações sobre o Kubernetes Jobs, consulte a documentação do Kubernetes.

   apiVersion: batch/v1 
   kind: Job 
   metadata: 
     name: curl 
   spec: 
     template: 
       metadata: 
         labels: 
           app: curl 
       spec: 
         nodeSelector: 
           kubernetes.azure.com/security-type: ConfidentialVM 
         containers: 
           - name: curlcontainer 
             image: alpine/curl:3.14 
             imagePullPolicy: IfNotPresent 
             args: ["-H", "Metadata:true", "http://169.254.169.254/metadata/THIM/amd/certification"] 
         restartPolicy: "Never" 
   

   O arquivo curl.yaml contém os seguintes argumentos.

   Nome	Tipo	Descrição
   Metadata	Booleano	Definir para True permite que o colateral seja devolvido.

4. Execute o trabalho aplicando o arquivo curl.yaml :

   kubectl apply -f curl.yaml 
   

5. Verifique e aguarde até que o pod conclua seu trabalho:

   kubectl get pods 
   

   Eis uma resposta de exemplo:

   Nome	Pronto	Estado	Reinicializações	Idade
   Curl-w7nt8	0/1	Concluído	0	72 s

6. Execute o seguinte comando para obter os registos do trabalho e verificar se está a funcionar. Uma saída bem-sucedida deve incluir vcekCert, tcbme certificateChain.

   kubectl logs job/curl  
   

Próximos passos

• Saiba mais sobre a documentação do Atestado do Azure.
• Saiba mais sobre a computação confidencial do Azure.