Compartilhar via

Gerenciamento de Identidades de Hardware Confiável

  • Artigo

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.

Interações de atestado e gerenciamento de identidade de hardware confiável

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

Diagrama a seguir mostra as interações entre um serviço ou nó de atestado, Gerenciamento de Identidade de Hardware Confiável e um host de enclave.

Perguntas frequentes

Como fazer usar o Gerenciamento de Identidade de Hardware Confiável com processadores Intel?

Para gerar cotações Intel SGX e Intel TDX, a Biblioteca de Geração de Cotações da Intel (QGL) precisa ter acesso à garantia de geração/verificação de cotações. Toda ou parte dessa garantia deve ser buscada do Gerenciamento de Identidade de Hardware Confiável. Você pode efetuar fetch por meio da Biblioteca de Provedores de Cotação Intel (QPL) ou a biblioteca de clientes do Azure Data Center Attestation Primitives (DCAP).

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

O campo tcbinfo contém as informações de TCB. O serviço gerenciamento de identidade de hardware confiável fornece informações mais antigas do tcbinfo por padrão. Atualizar para o tcbinfo mais recente da Intel causaria falhas de atestado em clientes que não migraram para o SDK mais recente da Intel e poderia resultar em interrupções.

O SDK do Open Enclave e o Atestado do Azure não analisam a data nextUpdate e passarão o atestado.

O que é a Biblioteca de DCAP do Azure?

A biblioteca do Data Center Attestation Primitives (DCAP) do Azure, um substituto da Quote Provider Library (QPL) da Intel, busca garantias de geração de cotação e garantias de validação de cotação diretamente do serviço de Gerenciamento de Identidade de Hardware Confiável. Buscar garantias diretamente do serviço de Gerenciamento de Identidade de Hardware Confiável garantirá que todos os hosts do Azure tenham garantias prontamente disponíveis na nuvem do Azure para reduzir as dependências externas. A versão atual recomendada da biblioteca DCAP é 1.11.2.

Onde posso baixar a mais recente biblioteca do Azure DCAP?

Use os links a seguir para baixar os pacotes:

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

Por que o Gerenciamento de Identidade de Hardware Confiável e a Intel têm linhas de base diferentes?

O Gerenciamento de Identidade de Hardware Confiável e a Intel fornecem diferentes níveis de base da base computacional 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 interrupção se os clientes não tiverem atualizado para os requisitos especificados.

O Gerenciamento de Identidade de Hardware Confiável adota uma abordagem mais lenta para atualizar a linha de base de TCB para permitir que os clientes façam 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 experimentarão uma quebra se não atenderem aos requisitos da nova linha de base TCB. É por isso que a linha de base TCB do Gerenciamento de Identidade de Hardware Confiável é uma versão diferente da linha de base da Intel. Nosso foco são os clientes e queremos capacitá-los para que possam atender, em seu próprio ritmo, aos requisitos impostos pela nova linha de base de TCB, em vez de forçá-los a atualizar e causar uma interrupção que exigiria a repriorização dos respectivos fluxos de trabalho.

Com os processadores Intel Xeon E, eu podia obter meus certificados diretamente do Intel PCS. Por que, com os processadores Intel Xeon Scalable a partir da 4ª geração, preciso obter os certificados do Gerenciamento de Identidades de Hardware Confiável? E como posso buscar esses certificados?

A partir da 4ª Geração de Processadores Intel® Xeon® Scalable, o Azure executa 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 nesse caso, e isso é refletido por false no sinalizador CachedKeys nos Certificados PCK. Como o registro indireto é usado, todas as comunicações seguintes com o Intel PCS exigiriam 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 Azure DCAP.

Como posso usar o QPL da Intel com o Gerenciamento de Identidade de Hardware Confiável?

Os clientes podem querer a flexibilidade de usar o QPL da Intel para interagir com o Gerenciamento de Identidade de Hardware Confiável sem precisar baixar outra dependência da Microsoft (ou seja, a biblioteca de clientes do DCAP do Azure). Os clientes que desejam usar o QPL da Intel com o serviço gerenciamento de identidade de hardware confiável devem ajustar o arquivo de configuração sgx_default_qcnl.conf do QPL intel.

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ção. Para recuperá-lo, os clientes podem usar um ponto de extremidade de Gerenciamento de Identidade de Hardware Confiável ou um ponto de extremidade do Serviço de Certificação de Provisionamento (PCS) da Intel.

O arquivo de configuração do QPL da Intel QPL (sgx_default_qcnl.conf) contém três chaves utilizadas para definir os pontos de extremidade colaterais. A chave pccs_url define o ponto de extremidade usado para recuperar os certificados PCK. A chave collateral_service pode ser usada para definir o ponto de extremidade utilizado para recuperar todas as outras garantias de geração/verificação de cotações. Se a chave collateral_service não estiver definida, todas as garantias de verificação de cotação serão recuperadas a partir do ponto de extremidade definido com a chave pccs_url.

A seguinte tabela lista como essas chaves podem ser definidas.

Nome Possíveis pontos de extremidade
pccs_url Gerenciamento de Identidades de Hardware Confiável: https://global.acccache.azure.net/sgx/certification/v3.
collateral_service Ponto de extremidade de Gerenciamento de Identidade de Hardware Confiável (https://global.acccache.azure.net/sgx/certification/v3) ou ponto de extremidade do PCS da Intel. O arquivo sgx_default_qcnl.conf sempre lista o ponto de extremidade mais atualizado na chave collateral_service.

O snippet de código a seguir é proveniente de um exemplo de um arquivo de configuração do QPL da Intel:

    { 
        "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 QPL da Intel e ativar as alterações.

No Windows

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

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

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

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

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

No Linux

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

    sudo vim /etc/sgx_default_qcnl.conf

  2. Reinicie o serviço AESMD. Abra um terminal e execute o seguinte comando:

    sudo systemctl restart aesmd 
systemctl status aesmd

Como posso solicitar uma caução em uma máquina virtual confidencial?

Use o exemplo a seguir em um convidado de máquina virtual confidencial (CVM) para solicitar uma caução do AMD que incluem o certificado VCEK e a cadeia de certificados. Para obter os detalhes e a origem dessa caução, consulte Certificado Versioned Chip Endorsement Key (VCEK) e Especificação de Interface do KDS.

Parâmetros do URI

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

Corpo da solicitação

Nome Tipo Descrição
Metadata Boolean Definir como True permitirá que a garantia seja devolvida.

Solicitação de exemplo

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

Respostas

Nome Descrição
200 OK Lista as garantias disponíveis no corpo HTTP no formato JSON
Other Status Codes Descreve por que a operação falhou

Definições

Chave Descrição
VcekCert Certificado X.509v3, conforme definido em RFC 5280.
tcbm Base Computacional Confiável.
certificateChain Certificados AMD SEV Key (ASK) e AMD Root Key (ARK)

Como solicitar uma garantia AMD em um contêiner do Serviço de Kubernetes do Azure em um nó da CVM?

Siga estas etapas para solicitar a garantia AMD em um contêiner confidencial:

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

    • Crie um cluster do AKS em um nó da CVM:

      1. Crie um grupo de recursos em uma das regiões da CVM com suporte.

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

      2. Crie um cluster do AKS com um nó da 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 kubectil para conectar-se ao cluster.

        az aks get-credentials --resource-group <RG_NAME> --name <CLUSTER_NAME>

    • Adicione um pool de nós da CVM ao cluster do 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 por meio do comando kubectl get. Esse comando retorna uma lista dos nós de cluster.

    kubectl get nodes

    O exemplo de saída a seguir mostra o único nó criado nas etapas anteriores. Verifique se que o status do nó é Ready.

    NOME STATUS ROLES IDADE VERSION
    aks-nodepool1-31718369-0 Ready 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 efetuar fetch da garantia AMD do ponto de extremidade do Gerenciamento de Identidade do Hardware Confiável. Para obter mais informações sobre os trabalhos do Kubernetes, 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 argumentos a seguir.

    Nome Tipo Descrição
    Metadata Boolean Definir como True permitirá que a garantia seja devolvida.

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

  6. Execute o comando a seguir para obter os logs de trabalho e validar se ele está funcionando. Uma saída bem-sucedida deve incluir vcekCert, tcbm e certificateChain.

    kubectl logs job/curl

Próximas etapas