Dónde desplegar una carga de trabajo que tiene que ser confidencial

Decidiste que alguna parte de tu producto tiene que correr donde vos, el operador, no podés leer los datos. Un banco no va a mandar el archivo de otra manera; un hospital tampoco; o simplemente no querés ser la parte que tiene una copia en claro de lo que hacen los clientes de un competidor.

La decisión que sigue es dónde vive la caja. Hay cuatro respuestas prácticas, y no son intercambiables. Lo que viene es la versión corta de cada una, con las partes que realmente deciden el asunto — no la página de marketing.

AWS Nitro Enclaves§

Una segunda VM, pelada, recortada de una instancia EC2 que ya pagás. Sin almacenamiento persistente, sin acceso interactivo y sin red propia: todo pasa por un canal vsock en la instancia padre, que vos proxyeás. La imagen es un EIF, y nitro-cli build-enclave imprime la medición (PCR0) que tus clientes van a fijar.

• La verificación es la más fácil de las cuatro. El documento lo firma la PKI de atestación de AWS, y un cliente en Synsema lo verifica contra la raíz fijada dentro del motor — cadena completa, firma COSE, fallando cerrado en la primera duda.
• Sin claves selladas. Nitro no deriva una clave a partir de la medición; el camino estándar es liberar una desde AWS KMS condicionada al documento de atestación. Presupuestalo, es trabajo real.
• Elegilo cuando tu infraestructura ya está en AWS, la contraparte es una empresa que va a aceptar "firmado por AWS" como raíz de confianza, y la carga es pedido/respuesta más que un servicio con estado de larga vida.

VMs confidenciales: Intel TDX y AMD SEV-SNP§

Google Confidential Space, VMs confidenciales de Azure, Constellation y Contrast, y el mismo silicio en otras nubes. La unidad es la VM entera: corrés tu contenedor como lo correrías en cualquier lado, y la plataforma mide la imagen que arrancó.

• De lejos, el menor esfuerzo. Tu despliegue de siempre, tus herramientas de siempre. En Linux ≥ 6.7 el reporte sale de configfs-tsm sin ningún SDK del fabricante dentro de la imagen.
• La verificación es la mitad difícil. Hoy un cliente de estas plataformas verifica el quote con el material del fabricante (Intel PCS, AMD KDS) o, en Confidential Space, comprueba el token firmado de la plataforma — que es verificación de JWT común. Definí quién hace eso antes de prometérselo a alguien.
• Elegilo cuando la carga es un servicio normal que tiene que estar arriba, mantener estado y escalar, y cuando la contraparte está cómoda con el proveedor de nube como parte de la historia de confianza.

dstack (Phala)§

Un agente guest dentro de una VM TDX que le da a tu contenedor el quote y, además, claves derivadas de la identidad de la app. Montás su socket adentro del contenedor y corrés compose como siempre.

• Estado sellado, sin un proyecto de KMS. attest_key("state") le pide al agente una clave atada a esta app; cifrás tu base o tu archivo de estado con ella y otra construcción simplemente no puede leerla.
• El quote lleva un event log, así que quien verifica puede reproducir la medición que cubre tu archivo de compose — el despliegue, no solo la imagen.
• Elegilo cuando querés estado confidencial con poca ceremonia, o cuando tus usuarios ya están en ese ecosistema.

Anclado a una cadena§

Cuando la contraparte no es una empresa sino un contrato — liquidación, un motor de matching, una política de pagos — el trabajo del enclave es producir un estado que la cadena acepte. Los adaptadores guest de Synsema corren con las etiquetas de flujo de información siempre prendidas y la cadena como sumidero público, así que lo que va on-chain es exactamente lo que el programa desclasificó y nada más.

• Elegilo cuando la disputa contra la que estás diseñando es "probarle a todos que se siguió la regla", y no "que una contraparte concreta pueda revisar antes de mandar un archivo".

Las tres preguntas que en realidad deciden§

1. ¿Quién no debe leer los datos — y es tu anfitrión? Si la respuesta incluye al proveedor de nube, una VM confidencial en ese mismo proveedor es una historia más débil que un enclave con una raíz de atestación independiente. Si es tu propio personal y tus propios operadores, cualquiera de las cuatro sirve. 2. ¿Quién verifica, y va a correr las herramientas de verdad? Un despliegue confidencial que nadie revisa es un despliegue común con costo extra. Si el equipo de seguridad de tu contraparte va a correr un verificador, elegí la plataforma cuyo documento le cueste menos comprobar. Si no lo va a correr, no compres nada exótico: elegí la más barata de operar y publicá igual la lista de comprobación. 3. ¿El estado tiene que sobrevivir a un reinicio? Las claves selladas son la línea divisoria. dstack las deriva por vos; Nitro te manda a KMS; en VMs confidenciales depende del producto. Respondé esto antes de escribir el esquema, no después.

Qué fijar, y qué no§

Un detalle que le cuesta una semana a los equipos: el digest de la imagen no es la medición. Un digest de Docker/OCI fija lo que desplegaste; PCR0 en Nitro, MRTD y RTMRs en TDX, measurement en SEV-SNP salen de cómo la plataforma envolvió esa imagen — la construcción del EIF, la imagen de sistema de dstack más el hash del compose, la política de imagen en Confidential Space. Tomá el valor esperado del propio paso de construcción de la plataforma y publicá ese como lo que los clientes deben esperar. Fijá los dos: el digest para tus despliegues, la medición para tus clientes.

Dónde encaja la Plataforma Synsema§

El enclave es la parte chica. Todo lo que lo rodea — el sitio, el alta, el panel, la cola, el almacenamiento del texto cifrado, la facturación, los jobs de conciliación — es software común que no debe estar dentro de la caja, y esa parte se despliega acá con un comando, con HTTPS, secretos y un registro de auditoría. La próxima entrada es sobre ese reparto, y sobre por qué achicar el enclave suele ser la decisión de mayor palanca de todo el diseño.

Los detalles del lado del motor — la capacidad attest, los drivers, serve --attested y el attestation_verify del cliente — están documentados en synsema.dev.