Share via

Administración de identidades de hardware de confianza

  • Artículo

El servicio Trusted Hardware Identity Management controla la administración de caché de certificados de todos los entornos de ejecución de confianza (TEE) que residen en Azure. También proporciona información de base de computación de confianza (TCB) para aplicar una línea de base mínima para las soluciones de atestación.

Interacciones de atestación y Trusted Hardware Identity Management

Trusted Hardware Identity Management define la línea de base de seguridad de Azure para los nodos de computación confidencial de Azure (ACC) y almacena en caché la garantía de los proveedores de TEE. Los servicios de atestación y los nodos de ACC pueden usar la información almacenada en caché para validar las TEE. En el diagrama siguiente se muestran las interacciones entre un servicio de atestación o un nodo, Trusted Hardware Identity Management y un host de enclave.

Diagram that illustrates interactions between an attestation service or node, Trusted Hardware Identity Management, and an enclave host.

Preguntas más frecuentes

¿Cómo usar Trusted Hardware Identity Management con procesadores Intel?

Para generar ofertas de Intel SGX e Intel TDX, Intel Quote Generation Library (QGL) necesita acceso a la garantía de validación o generación de ofertas. Toda esta garantía o partes de ella se deben capturar desde Trusted Hardware Identity Management. Puede capturarlo mediante Intel Quote Provider Library (QPL) o la biblioteca cliente de Azure Data Center Attestation Primitives (DCAP).

La fecha de "próxima actualización" de la API del servicio de almacenamiento en caché interno de Azure, que usa Azure Attestation, parece que no está actualizada. ¿Sigue en funcionamiento y se puede usar?

El campo tcbinfo contiene la información de TCB. El servicio Trusted Hardware Identity Management proporciona información de tcbinfo anterior de manera predeterminada. La actualización a la información de tcbinfo más reciente de Intel provocaría errores de atestación para los clientes que no hayan migrado al SDK de Intel más reciente, así como interrupciones.

Sin embargo, Open Enclave SDK y Azure Attestation no examinan la fecha de nextUpdate y pasarán la atestación.

¿Qué es la biblioteca de Azure DCAP?

La biblioteca de Azure Data Center Attestation Primitives (DCAP), un reemplazo de Intel Quote Provider Library (QPL), captura la garantía de generación y validación de ofertas directamente del servicio Trusted Hardware Identity Management. La captura de material de garantía directamente del servicio Trusted Hardware Identity Management garantiza que todos los hosts de Azure tengan garantías disponibles en la nube de Azure para reducir las dependencias externas. La versión que se recomienda actualmente de la biblioteca DCAP es la 1.11.2.

¿Dónde puedo descargar la biblioteca de Azure DCAP más reciente?

Use los vínculos siguientes para descargar los paquetes:

Para versiones más recientes de Ubuntu (por ejemplo, Ubuntu 22.04), debe usar el Intel QPL.

¿Por qué Trusted Hardware Identity Management e Intel tienen líneas de base diferentes?

Trusted Hardware Identity Management e Intel proporcionan diferentes niveles de línea de base de la base de computación de confianza. Cuando los clientes asumen que Intel tiene las líneas de base más recientes, deben asegurarse de que se cumplen todos los requisitos. Este enfoque puede provocar una interrupción si los clientes no han actualizado a los requisitos especificados.

Trusted Hardware Identity Management adopta un enfoque más lento para actualizar la línea de base de TCB para que los clientes puedan hacer los cambios necesarios a su propio ritmo. Aunque este enfoque proporciona una línea de base de TCB anterior, los clientes no experimentarán una interrupción si no han cumplido los requisitos de la nueva línea de base de TCB. Este es el motivo por el que la línea de base de TCB de Trusted Hardware Identity Management es una versión diferente de la línea de base de Intel. Queremos capacitar a los clientes para que cumplan los requisitos de la nueva línea de base de TCB a su ritmo, en lugar de obligarlos a actualizar y provocar una interrupción que requeriría volver a priorizar las series de tareas.

Con los procesadores Intel Xeon E, puedo obtener mis certificados directamente desde Intel PCS. ¿Por qué, con procesadores escalables Intel Xeon a partir de la 4ª generación, necesito obtener los certificados de Administración de identidades de hardware de confianza? ¿Y cómo puedo capturar esos certificados?

A partir de la 4ª generación de procesadores escalables Intel® Xeon®, Azure realiza un registro indirecto en el servicio de registro de Intel mediante el manifiesto de plataforma y almacena el certificado PCK resultante en el servicio de Administración de identidades de hardware de confianza (THIM) que Azure usa el registro indirecto, ya que el servicio de registro de Intel no almacenará claves raíz para una plataforma en este caso y esto se refleja mediante false en la marca CachedKeys en certificados PCK. Como se usa el registro indirecto, toda la comunicación siguiente con PCS Intel requeriría el manifiesto de plataforma, que Azure no proporciona a las máquinas virtuales (VM). En su lugar, las máquinas virtuales tienen que ponerse en contacto con la THIM para recibir certificados PCK. Para recuperar un certificado PCK, puede usar el Intel QPL o la biblioteca de Azure DCAP.

¿Cómo usar Intel QPL con Trusted Hardware Identity Management?

Es posible que los clientes quieran la flexibilidad de usar Intel QPL para interactuar con Trusted Hardware Identity Management sin tener que descargar otra dependencia de Microsoft (es decir, la biblioteca cliente de Azure DCAP). Los clientes que quieran usar Intel QPL con el servicio Trusted Hardware Identity Management deben ajustar el archivo de configuración de Intel QPL, sgx_default_qcnl.conf.

La garantía de generación o comprobación de ofertas usada para generar las ofertas de Intel SGX o Intel TDX se puede dividir en las siguientes opciones:

  • El certificado PCK. Para recuperarlo, los clientes deben usar un punto de conexión de Trusted Hardware Identity Management.
  • El resto del material de garantía de comprobación o generación de ofertas. Para recuperarlo, los clientes pueden usar un punto de conexión de Trusted Hardware Identity Management o un punto de conexión de Intel Provisioning Certification Service (PCS).

El archivo de configuración de Intel QPL (sgx_default_qcnl.conf) contiene tres claves para definir los puntos de conexión de garantías. La clave pccs_url define el punto de conexión que se utiliza para recuperar los certificados PCK. La clave collateral_service puede definir el punto de conexión que se utiliza para recuperar todas las demás garantías de comprobación o generación de ofertas. Si no se define la clave collateral_service, se recupera toda la garantía de comprobación de ofertas desde el punto de conexión definido con la clave pccs_url.

En la tabla siguiente, se muestra cómo se pueden establecer estas claves.

Nombre Posibles puntos de conexión
pccs_url Punto de conexión de Trusted Hardware Identity Management: https://global.acccache.azure.net/sgx/certification/v3.
collateral_service Punto de conexión de Trusted Hardware Identity Management (https://global.acccache.azure.net/sgx/certification/v3) o punto de conexión Intel PCS. El archivo sgx_default_qcnl.conf siempre muestra el punto de conexión más actualizado de la clave collateral_service.

El siguiente fragmento de código es de un ejemplo de un archivo de configuración de 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" 
                } 
            } 
        } 
    }

En los procedimientos siguientes se explica cómo cambiar el archivo de configuración de Intel QPL y activar los cambios.

En Windows

  1. Haga los cambios en el archivo de configuración.

  2. Asegúrese de que haya permisos de lectura para el archivo desde la siguiente ubicación del registro y clave o valor.

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

  3. Reinicie el servicio AESMD. Por ejemplo, abra PowerShell como administrador y use los comandos siguientes:

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

En Linux

  1. Haga los cambios en el archivo de configuración. Por ejemplo, puede usar Vim para los cambios mediante el siguiente comando:

    sudo vim /etc/sgx_default_qcnl.conf

  2. Reinicie el servicio AESMD. Abra cualquier terminal y ejecute los comandos siguientes:

    sudo systemctl restart aesmd 
systemctl status aesmd

¿Cómo solicitar garantías en una máquina virtual confidencial?

Use el ejemplo siguiente en un invitado de máquina virtual confidencial (CVM), para solicitar garantías de AMD que incluya el certificado VCEK y la cadena de certificados. Para más información sobre estas garantías y su origen, consulte Certificado de clave de aprobación de chip con versiones (VCEK) y especificación de la interfaz de KDS.

Parámetros del identificador URI

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

Cuerpo de la solicitud

Nombre Tipo Description
Metadata Boolean Si se establece en True, se permite devolver material de garantía.

Solicitud de ejemplo

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

Respuestas

Nombre Descripción
200 OK Muestra el material de garantía disponible en el cuerpo HTTP en formato JSON
Other Status Codes Describe por qué se produjo un error en la operación

Definiciones

Clave Descripción
VcekCert Certificado X.509v3 tal y como se define en RFC 5280
tcbm Base de computación de confianza
certificateChain Certificados AMD SEV Key (ASK) y AMD Root Key (ARK)

¿Cómo solicitar garantías de AMD en un contenedor de Azure Kubernetes Service en un nodo de CVM?

Siga estos pasos para solicitar garantías de AMD en un contenedor confidencial:

  1. Para empezar, cree un clúster de Azure Kubernetes Service (AKS) en un nodo de CVM o agregue un grupo de nodos de CVM a un clúster existente:

    • Cree un clúster de AKS en un nodo de CVM:

      1. Cree un grupo de recursos en una de las regiones compatibles con CVM:

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

      2. Cree un clúster de AKS con un nodo de CVM en el 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 kubectl para conectarse al clúster:

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

    • Agregue un grupo de nodos de CVM a un clúster de 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. Compruebe la conexión al clúster con el comando kubectl get. Este comando devuelve una lista de los nodos del clúster.

    kubectl get nodes

    En el ejemplo de salida siguiente se muestra el nodo único que creó en los pasos anteriores. Asegúrese de que el estado del nodo es Ready.

    NOMBRE STATUS ROLES AGE VERSION
    aks-nodepool1-31718369-0 Ready agente 6 m 44 s v1.12.8

  3. Cree un archivo curl.yaml con el siguiente contenido. Define un trabajo que ejecuta un contenedor curl para capturar la garantía de AMD del punto de conexión de Trusted Hardware Identity Management. Para más información sobre los trabajos de Kubernetes, consulte la documentación de 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"

    El archivo curl.yaml contiene los argumentos siguientes.

    Nombre Tipo Description
    Metadata Boolean Si se establece en True, se permite devolver material de garantía.

  4. Aplique el archivo curl.yaml para ejecutar el trabajo:

    kubectl apply -f curl.yaml

  5. Compruebe el pod y espere a que complete su trabajo:

    kubectl get pods

    Este es un ejemplo de respuesta:

    Denominación Ready Estado Reinicios Age
    Curl-w7nt8 0/1 Completado 0 72 s

  6. Ejecute el siguiente comando para obtener los registros de trabajo y comprobar que funciona. Una salida correcta debe incluir vcekCert, tcbm y certificateChain.

    kubectl logs job/curl

Pasos siguientes