Proteja la propiedad intelectual en máquinas virtuales de Azure con Liberación segura de claves controlada por atestación

En este artículo se describe un patrón reutilizable para proteger un recurso confidencial (por ejemplo, ponderaciones de modelos de aprendizaje automático propietarios, un conjunto de datos con licencia o una configuración secreta) que debe ejecutarse en una máquina virtual (VM) dentro de la suscripción de Azure de otra persona. La entidad propietaria del recurso (el publicador) es diferente de la entidad propietaria de la suscripción en la que se ejecuta la máquina virtual (el consumidor). El cliente tiene acceso completo al plano de control de Azure de esa máquina virtual, pero no debe poder extraer el activo.

El patrón combina varias características de Azure documentadas en capas de defensa. Su núcleo criptográfico es la liberación segura de claves (SKR) condicionada por atestación de Azure Key Vault, condicionada por la atestación vTPM de Trusted Launch. No requiere computación confidencial, aunque la computación confidencial se puede agregar como una capa opcional cuando el modelo de amenazas lo exige.

Escenario y modelo de amenazas

Un publicador distribuye una carga de trabajo basada en máquinas virtuales en la suscripción de un consumidor (por ejemplo, a través de Azure Marketplace como plantilla de solución o como una imagen compartida). La carga de trabajo necesita una clave de descifrado para desbloquear el recurso del publicador en tiempo de ejecución. La clave debe liberarse únicamente a la imagen genuina y sin modificar del editor; nunca directamente al consumidor, ni a una imagen manipulada o sustituida.

El patrón se defiende frente a dos direcciones de amenazas distintas. Asignarles nombres explícitamente es lo que hace que las decisiones de capas sean claras.

Dirección de amenaza A es la amenaza principal y la que da forma a la arquitectura. En el patrón base, la dirección de amenaza B es un riesgo aceptado explícitamente: la plataforma es de confianza y coincide con la posición común de confiar en el hipervisor del proveedor de nube. Añada Capa 4 solo cuando no se deba confiar en el propio hipervisor (por ejemplo, una carga de trabajo regulada que exija el cifrado de memoria).

Cuándo añadir Computación confidencial (capa 4)

La proceso confidencial no es una alternativa a este patrón, sino la capa 4 opcional que se añade sobre él. El patrón base (capas 1–3) ya supedita la liberación de la clave a la atestación, protege el activo del consumidor y se ejecuta en cualquier SKU Gen2 de Trusted Launch con coste estándar. Incorporar la computación confidencial no cambia la forma en que funciona el patrón: SKR, la imagen reforzada y el aislamiento de red siguen siendo los mismos, y el flujo de publicación es idéntico. Las únicas diferencias son que la directiva de liberación se basa en las declaraciones de TEE de hardware en lugar de en las declaraciones de arranque medido de vTPM, y que la carga de trabajo se ejecuta en una SKU de máquina virtual confidencial. Se obtiene protección frente a la dirección de amenaza B (el host/hipervisor) y se sacrifica la variedad de SKU, GPU y regiones a un coste superior.

En la tabla siguiente se muestra lo que agrega la capa 4 y lo que cuesta, no una opción entre dos patrones:

Comience con el patrón base. Añada la capa 4 solo cuando deba desconfiar del hipervisor; por ejemplo, en una carga de trabajo regulada que exija cifrado de memoria, asumiendo una disponibilidad más limitada de SKU, GPU y regiones, así como un coste superior.

Elementos del patrón

El patrón es una arquitectura de defensa en profundidad por capas. Cada capa defiende una dirección de amenaza específica: las capas 1–3 defienden contra el consumidor (dirección de amenaza A) y la capa 4 opcional se defiende contra el host (dirección de amenaza B). El recurso protegido se encuentra en el núcleo, accesible solo a través de cada capa envolvente.

flowchart TB
    threatA["Threat direction A<br/>Consumer / VM and subscription owner<br/>run-command, disk snapshot and swap,<br/>serial console, managed-identity theft"]
    threatB["Threat direction B<br/>Host / hypervisor<br/>reads guest memory"]

    subgraph L4 ["Layer 4 (optional) — Confidential Computing: host memory encryption"]
        subgraph L3 ["Layer 3 — Network isolation: private endpoints, no public egress, deny assignments"]
            subgraph L2 ["Layer 2 — Hardened image: dm-verity, read-only root, no SSH or agent"]
                subgraph L1 ["Layer 1 — Attestation-gated SKR: vTPM measured-boot claims gate key release"]
                    asset["Protected asset<br/>released key, then decrypted weights"]
                end
            end
        end
    end

    threatA -. "defended by Layers 1–3" .-> asset
    threatB -. "defended only by Layer 4" .-> asset
    style L4 stroke-dasharray: 5 5

Las capas defienden el recurso en reposo y en uso. En tiempo de ejecución, la máquina virtual del consumidor y los anclajes de confianza del publicador interactúan de la siguiente manera:

flowchart TB
    subgraph consumer ["Consumer tenant (untrusted operator)"]
        vm["Trusted Launch VM<br/>Secure Boot + vTPM<br/>Hardened image"]
    end
    subgraph publisher ["Publisher tenant (holds the trust anchors)"]
        maa["Microsoft Azure Attestation"]
        akv["Key Vault Premium / Managed HSM<br/>exportable key + release policy"]
    end
    vm -->|"1. Attestation request (vTPM evidence)"| maa
    maa -->|"2. Signed MAA token (secureboot, PCR claims)"| vm
    vm -->|"3. POST /keys/{key}/release (MAA token)"| akv
    akv -->|"4. Key wrapped to vTPM ephemeral key, or AccessDenied"| vm
    linkStyle default stroke-width:2px

Nivel 1: Liberación segura de claves controlada por atestación (el control criptográfico)

Esta capa es la base. Una máquina virtual de inicio seguro arranca con arranque seguro y un TPM virtual (vTPM). El vTPM mide la cadena de arranque en los Registros de Configuración de la Plataforma (PCR), creando una huella criptográfica de exactamente lo que se ha arrancado. El cliente solicita un token MAA que incluya estas mediciones, como la declaración secureboot y de x-ms-azurevm-attested-pcr-values.pcr0 a pcr7. A continuación, llama al punto de conexión /release de Key Vault y presenta el token. Key Vault valida la firma del token y evalúa el token con respecto a la directiva de liberación de la clave. Si las declaraciones de la directiva coinciden, Key Vault libera la clave, envuelta con la clave efímera del vTPM para que solo esa máquina virtual atestada pueda desencapsularla. Si no coinciden, la versión devuelve AccessDenied.

Lo que bloquea (amenaza A): Una VM alterada, recreada a partir de una imagen o con el disco intercambiado registra valores de PCR distintos y no puede obtener la clave. También falla una instantánea del disco del sistema operativo montado en otra máquina virtual.

Una directiva de liberación representativa para una máquina virtual de arranque confiable (Trusted Launch VM):

{
  "version": "1.0.0",
  "anyOf": [
    {
      "authority": "https://<MAA_PROVIDER>.<region>.attest.azure.net",
      "allOf": [
        { "claim": "secureboot", "equals": true },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr4", "equals": "<BASE64_PCR4>" },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr7", "equals": "<BASE64_PCR7>" }
      ]
    }
  ]
}

Capa 2: Imagen protegida (proteger el recurso descifrado)

La capa 1 controla si se libera la clave; no protege el recurso una vez que se descifra en el invitado en ejecución. Refuerce la imagen para reducir la superficie de ataque dentro del invitado y en el plano de control: integridad del sistema de archivos (por ejemplo, dm-verity), un sistema de archivos raíz de solo lectura, sin demonio SSH, sin inicio de sesión interactivo y sin ningún agente dentro del invitado que pueda ejecutar comandos suministrados por el operador.

Lo que bloquea (amenaza A): Explotación en invitado de una máquina virtual en ejecución, atestiguada: procesos no autorizados, escalación de privilegios, extracción del recurso descifrado de la memoria del proceso a través de una vulnerabilidad de nivel de sistema operativo.

Capa 3: Aislamiento de red (reducir la superficie)

Restrinja cómo la máquina virtual se comunica con los delimitadores de confianza y los datos. Use puntos de conexión privados para Key Vault, almacenamiento y cualquier registro; una ruta de acceso privada al proveedor de atestación; DNS privado y ninguna salida pública innecesaria. Cuando el mecanismo de implementación lo permite —por ejemplo, una aplicación administrada—, las asignaciones de denegación también pueden retirar al consumidor los permisos de RBAC sobre los recursos de cómputo, con lo que se bloquean por completo los ataques al plano de control (run-command, operaciones de disco, consola serie, robo de identidad). En una implementación basada en una plantilla de solución, el consumidor conserva el control RBAC sobre los recursos implementados, por lo que el refuerzo del plano de control no está disponible; en ese caso, las capas 1 y 2 proporcionan la defensa contra la amenaza A: una instantánea o un disco sustituido no superan la atestación (capa 1), y la imagen reforzada (capa 2) impide la extracción del activo descifrado dentro del sistema invitado.

Lo que bloquea (amenaza A): Reduce la superficie expuesta a ataques tanto del plano de control como del plano de datos y evita las vías de exfiltración desde la máquina virtual invitada validada.

Capa 4 (opcional): Computación confidencial (defiende la dirección de amenazas B)

Todo lo anterior confía en el host. Si no puede confiar en el hipervisor, ejecute la carga de trabajo en una máquina virtual confidencial (AMD SEV-SNP o Intel TDX). El cifrado de memoria impide que el host lea la memoria del invitado, y el SKR pasa de las afirmaciones de arranque medido por vTPM a afirmaciones de TEE de hardware en la directiva de liberación. Esta capa es la única capa que defiende la dirección de amenaza B. Está desactivada de forma predeterminada porque reduce la disponibilidad de SKU, GPU y región y agrega costos.

Identidad entre inquilinos

El publicador mantiene los anclajes de confianza —Key Vault (o Managed HSM) y el proveedor de atestación— en el tenant del publicador, fuera del RBAC del consumidor. La máquina virtual atestada se ejecuta en el tenant del consumidor y tiene que acceder a Key Vault a través de ese límite. Dos restricciones de plataforma descartan los enfoques obvios:

• Una identidad administrada existe exactamente en un único inquilino. El inquilino del editor no reconocerá ni emitirá tokens a una identidad administrada que resida en el inquilino del consumidor.
• Una asignación de roles de Azure RBAC solo puede asignarse a una identidad del propio tenant del recurso, por lo que no se puede conceder a la identidad administrada del consumidor un rol en el Key Vault del proveedor.

Una credencial de identidad federada (FIC) no puede salvar la brecha directamente: Entra ID no permite que un FIC confíe en tokens emitidos por otro inquilino de Entra, por lo que una aplicación propiedad del publicador no puede federar la identidad administrada del consumidor a través del límite.

El patrón que funciona sitúa la identidad puente —una aplicación multitenant— en el lado del consumidor:

1. El consumidor registra una aplicación multitenant en su inquilino y configura en ella un FIC del mismo inquilino que confía en la identidad administrada de la máquina virtual. Se permite un FIC que confíe en una identidad en el mismo inquilino.
2. El editor integra esa aplicación en su propio inquilino aprovisionando una entidad de servicio para ella y otorgándole a dicha entidad el rol Usuario de liberación del servicio criptográfico de Key Vault sobre la clave. Este paso de incorporación deliberado, específico para cada consumidor, es donde el editor concede a un agente externo acceso a su inquilino.
3. En tiempo de ejecución, la identidad administrada de la máquina virtual obtiene un token de IMDS, lo intercambia a través del FIC para autenticarse como la aplicación multitenant y llama al punto de conexión /release de Key Vault con el token MAA en el cuerpo de la solicitud.

Guía paso a paso

1. Provisiona los anclajes de confianza (inquilino editor). Cree un Key Vault Premium o un HSM administrado. Cree una clave de RSA-HSM exportable . Adjunte una directiva de liberación que fije su autoridad MAA y las reclamaciones de Trusted Launch (secureboot, seleccionadas x-ms-azurevm-attested-pcr-values.pcrN).
2. Determine los valores de PCR esperados. Certifique una vez una instancia válida conocida de su imagen y lea x-ms-azurevm-attested-pcr-values del token MAA devuelto. Fije los PCR que mide su cadena de arranque, normalmente pcr4 (cargador de arranque/kernel) y pcr7 (estado de arranque seguro).
3. Implemente la carga de trabajo (inquilino consumidor). Implemente una máquina virtual de inicio seguro (Gen2) que ejecute la imagen protegida. Asigne una identidad administrada y federar esa identidad con la aplicación multiinquilino propiedad del consumidor descrita en Identidad entre inquilinos, a cuya entidad de servicio el editor ha concedido Usuario de liberación del servicio criptográfico de Key Vault sobre la clave.
4. Certifique y libere en tiempo de ejecución. El invitado obtiene un token MAA y, a continuación, llama a POST /keys/{key-name}/release. Key Vault valida y devuelve la clave encapsulada; el sistema invitado la desencapsula dentro de la máquina virtual.
5. Compruebe el caso negativo. Cambie una PCR anclada en la directiva de versión a un valor de no coincidencia (o arranque una imagen modificada) y confirme que la versión devuelve AccessDenied.

Para obtener código ejecutable, consulte los ejemplos en Contenido relacionado.

Contenido relacionado

• Gramática de la directiva de versión de clave segura de Azure Key Vault
• Liberación segura de claves con Azure Key Vault y Azure Confidential Computing
• Ejemplos de directivas de versión de clave segura
• Información general sobre Microsoft Azure Attestation
• Inicio seguro para máquinas virtuales de Azure
• Federación de identidades de carga de trabajo
• Ejemplo: cvm-securekey-release-app en Azure/confidential-computing-cvm-guest-attestation
• Ejemplo: ejemplos de SKR en Azure-Samples/confidential-computing