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 de base de computação confiável (TCB) para impor uma linha de base mínima para soluções de atestado.

Gerenciamento de identidade de hardware confiável e interações de atestado

O Gerenciamento de Identidade de Hardware Confiável define a linha de base de segurança do Azure para nós de computação confidencial (ACC) do Azure e armazena em cache garantias de provedores 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 parte dessa garantia deve ser obtida no Trusted Hardware Identity Management. Você pode buscá-lo usando a Intel Quote Provider Library (QPL) ou a biblioteca de cliente do Azure Data Center Attestation Primitives (DCAP).

A data da "próxima atualização" da API do serviço de cache interno do Azure que o Atestado do Azure usa 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.

No entanto, o SDK do Enclave Aberto e o Atestado do Azure não examinam a nextUpdate data e passarão pelo atestado.

O que é a biblioteca DCAP do Azure?

A biblioteca DCAP (Azure Data Center Attestation Primitives), um substituto do Intel Quote Provider Library (QPL), obtém garantias de geração de cotação e validação de cotação diretamente do serviço Trusted Hardware Identity Management. 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. A versão atual recomendada da biblioteca DCAP é 1.11.2.

Onde posso baixar a biblioteca DCAP do Azure mais recente?

Use os seguintes links para baixar os pacotes:

• Ubuntu 20,04
• Ubuntu 18.04
• Windows

Para versões mais recentes do Ubuntu (por exemplo, Ubuntu 22.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 CachedKeys no false 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 ponto de extremidade de Gerenciamento de Identidade de Hardware Confiável.
• Todas as outras garantias de 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 arquivo de configuração Intel QPL (sgx_default_qcnl.conf) contém três chaves para definir os pontos de extremidade colaterais. A pccs_url chave define o ponto de extremidade 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 collateral_service chave não estiver definida, todas as garantias de verificação de cotação serão recuperadas do ponto de extremidade definido com a pccs_url chave.

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 AESMS. 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 AESMS. Abra qualquer terminal e execute os seguintes comandos:

   sudo systemctl restart aesmd 
   systemctl status aesmd 
   

Como solicito garantias em uma máquina virtual confidencial?

Use o exemplo a seguir em um convidado confidencial de máquina virtual (CVM) para solicitar garantias 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 garantias AMD em um contêiner de serviço do Kubernetes do Azure em um 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 <RG_NAME> --location <LOCATION> 
        

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

        az aks create --name <CLUSTER_NAME> --resource-group <RG_NAME> -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 <RG_NAME> --name <CLUSTER_NAME> 
        

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

     az aks nodepool add --cluster-name <CLUSTER_NAME> --resource-group <RG_NAME> --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 o nó único que você criou nas etapas anteriores. Verifique se o status do nó é Ready.

   NOME	ESTADO	FUNÇÕES	IDADE	VERSÃO
   AKS-NodePool1-31718369-0	Pronta	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	Configuração para True permitir que as garantias sejam devolvidas.

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	Pronta	Status	Reinícios	Antiguidade
   Curl-w7nt8	0/1	Concluído	0	72 s

6. Execute o seguinte comando para obter os logs de trabalho e validar se ele está funcionando. 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.