synsema

Todas las entradas · · 5 min de lectura

Mantené el enclave chico

Cada línea dentro de la caja cuesta más escribirla, más cambiarla y más verificarla — y cada cambio invalida la medición que tus clientes fijaron. El reparto entre el núcleo confidencial y el producto común es la decisión de mayor palanca del diseño.

teearquitecturacomputación confidencialdespliegue

La primera arquitectura confidencial que dibuja casi todo equipo mete el producto adentro del enclave. La capa web, la base de datos, el panel, los jobs — todo, porque todo termina tocando los datos en algún momento.

Es la respuesta cara, y casi siempre es la equivocada. No porque un enclave sea lento, sino por lo que cuesta vivir adentro de uno después.

Lo que cuesta una línea de código adentro de la caja§

El reparto§

Poné en el enclave lo que cumple las dos cosas: código que estarías dispuesto a publicar, sobre datos que no tenés permitido leer. Todo lo demás queda afuera.

AdentroAfuera
La decisión: el score, el match, la regla de pago, la firmaEl sitio, el alta, las sesiones, el panel
El descifrado de lo que mandó la contraparteEl almacenamiento del texto cifrado, la cola, los reintentos
La clave que solo este código puede usarFacturación, cuotas, correos, el registro de auditoría
El único valor que vuelve para afueraTodo lo que el cliente mira

La forma se sigue sola: afuera se guardan el texto cifrado y los metadatos, se le pasa un trabajo al enclave y se recibe una respuesta chica y deliberada. En Synsema esa última parte no es una convención — la respuesta es un sumidero público, así que cualquier cosa privada que no se desclasifique explícitamente nunca sale:

let score be private(payload["score"], "applicant")
let approved be score >= CUTOFF
give declassify(approved, "the yes/no is what the lender asked for; the score stays inside")

Un valor, una oración que dice por qué puede publicarse, y esa oración queda listada por synsema code check --json antes de que corra nada. Un enclave chico tiene una lista corta, y una lista corta es una revisión de seguridad que tu cliente puede leer de verdad.

El recambio de versión: planificalo antes del primer cliente§

Como la medición está fijada, distribuir adentro de la caja es distinto:

1. Publicá el nuevo program_sha y la medición esperada antes del despliegue, donde los clientes las buscan. 2. Corré la versión vieja y la nueva en paralelo durante la ventana. Los clientes que fijaron la medición vieja siguen funcionando; los que adoptan el valor nuevo se mudan. 3. Retirá la vieja en una fecha que anunciaste. Esto es deprecación de API, con criptografía en lugar de una cabecera de versión.

Los equipos que se saltean esto lo descubren la primera vez que un arreglo de seguridad tiene que salir un viernes.

Dónde corre cada mitad§

El enclave corre donde elegiste — Nitro, una VM confidencial, dstack, o anclado a una cadena; eso es la entrada anterior. El resto es software común con un vecino poco común, y necesita exactamente lo que necesita cualquier producto: HTTPS, sesiones, una base de datos, secretos que nunca se imprimen, jobs programados, un panel, facturación.

Eso es lo que hace esta plataforma. syn deploy pone la capa pública en línea con un certificado, un registro de auditoría de cada capacidad que usó el programa y secretos guardados sellados — y lo hace con un comando, para que la mitad interesante de tu semana se vaya a las doscientas líneas que viven en la caja.

Las dos mitades se hablan por HTTPS común, con un agregado: antes de mandar un trabajo adentro, la capa de afuera verifica el documento de identidad del enclave y fija la clave que viene en él. Veinte líneas, el mismo lenguaje, sin SDK — la forma está en el manual.

La regla práctica§

Si no podés decir, en una oración por valor, qué sale del enclave y por qué, la caja es demasiado grande. Achicala hasta que puedas. Cada hora puesta en eso se devuelve en el proceso de release, en la auditoría y en la conversación donde el equipo de seguridad de un cliente pregunta qué es, exactamente, lo que están confiando.