ANKASecure© permite que cada tenant elija el Root of Trust que envuelve sus llaves, mediante una precedencia de tres escalones resuelta por tenant: el backend propio del tenant, el backend gestionado que asigna su edición licenciada, o el valor por defecto del despliegue. Un tenant puede traer su propia llave de AWS KMS, GCP KMS, Azure Key Vault o Azure Managed HSM en su propia cuenta bajo su propia credencial, o un AWS CloudHSM u otro HSM PKCS#11; ANKASecure© ejecuta un ciclo completo en vivo antes de aceptar la declaración, y la llave de cifrado de llaves que envuelve las llaves de datos del tenant nunca sale de ese backend. La custodia es independiente del modelo de despliegue — SaaS, nube privada u on-premise incluido aislado de red — y cada envoltura y desenvoltura aparece tanto en el rastro de auditoría firmado de ANKASecure© como en el log del propio proveedor. La arquitectura de referencia hace de los Roots of Trust distribuidos un requisito de conformidad.
Todos los proveedores dicen que sus llaves siguen siendo suyas. ANKASecure© lo convierte en un ajuste que usted puede leer: cada tenant declara el backend que envuelve sus llaves — su propio HSM, o su propia cuenta de KMS bajo su propia credencial — y la llave de cifrado de llaves nunca sale de ese backend. La prueba está en el log de su proveedor, no en una diapositiva.
Es su caso
Un regulador, una política de la junta o un contrato con un cliente exige que el material de llaves nunca salga de su HSM o de su jurisdicción. Cualquier plataforma que necesite tener el Root of Trust queda descalificada antes de empezar la evaluación.
Las cargas de trabajo pueden moverse. Las llaves no, o deben ir a una cuenta que la empresa controle. La migración espera una respuesta a quién envuelve qué, y dónde.
Una entidad mantiene un HSM en sus instalaciones, otra es solo nube, una tercera está en una jurisdicción con su propia lista. Una sola plataforma tiene que sostener las tres sin hacerlas compartir un dominio de fallo.
Quién firma esto: Un CISO o responsable de criptografía que es dueño del requisito de custodia, y un responsable de infraestructura que es dueño del HSM o de la cuenta en la nube que ese requisito nombra. Si una evaluación de proveedores se detuvo en “¿dónde vive el Root of Trust?”, esta es la conversación.
Cómo funciona
El tenant elige el Root of Trust. ANKASecure© envuelve bajo él y nunca lo tiene.
Tres escalones, resueltos por tenant y deteniéndose en el primero declarado: el backend propio del tenant, el backend gestionado que asigna su edición licenciada, o el valor por defecto del despliegue. Una filial que trae su propio HSM y una que no conviven en la misma instalación.
Declare su HSM o su llave de KMS en la nube — en su cuenta, bajo su credencial. ANKASecure© ejecuta un ciclo completo en vivo contra él antes de aceptar la declaración. Desde entonces la llave de cifrado de llaves que envuelve las llaves de datos del tenant vive ahí y solo ahí.
SaaS operado por ANKATech, su nube privada, u on-premise, incluido aislado de red. Custodia y despliegue son decisiones separadas: un tenant SaaS puede envolver bajo su propia cuenta de KMS, y una instalación on-premise puede servir a un tenant que trae una llave en la nube.
Cada envoltura y desenvoltura de una llave de datos es una llamada a su backend, así que aparece en el log de auditoría de su proveedor — CloudTrail, Cloud Audit Logs, Azure Monitor, el log de su HSM — junto al rastro firmado de ANKASecure©. Dos registros, dos dueños, una sola historia.
Quince minutos
En vivo, sobre un despliegue real, contra un backend en una cuenta que usted controla. Nada de esta lista es una maqueta ni un elemento de roadmap.
Un tenant en el backend gestionado. Sus llaves, y el backend que las envuelve, en pantalla.
El tenant declara su propia llave de KMS en su propia cuenta. Se ejecuta el ciclo en vivo; la declaración se acepta.
Se crea una llave bajo ella. La llamada de envoltura aparece en el log de auditoría del proveedor de nube, en su cuenta, segundos después.
Un segundo tenant, en un backend distinto, en la misma instalación. Ninguno puede alcanzar el Root of Trust del otro.
El rastro firmado de ANKASecure© junto al log del proveedor: las mismas operaciones, registradas por dos partes.
Su cláusula de custodia, verificada sobre el despliegue y no sobre una diapositiva.
Sobre qué se apoya
Disponible
Precedencia de backend en tres escalones
BYOK del tenant, luego el backend que asigna la edición licenciada, luego el valor por defecto del despliegue; resuelto por tenant.
Disponible
Backends de KMS en la nube
AWS KMS, GCP KMS, Azure Key Vault y Azure Managed HSM, cada uno ejercitado en un ciclo completo en vivo contra el servicio real.
Disponible
Backends HSM
AWS CloudHSM ejercitado en vivo; los adaptadores PKCS#11 para otros HSM se entregan con un estado de certificación publicado por mecanismo.
Disponible
Keystores por tenant y ciclo de vida de llaves
Cifrado de sobre: llaves de datos envueltas por una llave de cifrado de llaves por tenant que nunca sale del backend; un ciclo de vida de siete estados por llave.
Disponible
Tres modelos de despliegue
SaaS, nube privada, on-premise incluido aislado de red, independientes de la decisión de custodia.
Disponible
Rastro de auditoría firmado
Cada envoltura y desenvoltura registrada, a prueba de manipulación, junto al log de su proveedor.
El marco
La arquitectura de referencia del Cryptographic Control Plane lo establece como requisito de conformidad, no como preferencia: una plataforma que exige que toda llave o Root of Trust viva en un único proveedor o dominio de fallo criptográfico no conforma.
02
Pilar principal
Escenario que realiza
Conservar el control del Root of Trust
Prueba práctica
“¿Puede la organización gobernar la política en todos sus dominios de confianza sin mover llaves, y revocar la autoridad criptográfica de un tercero sin recifrar los datos?”
05
Pilar principal
Escenario que realiza
Integración con el ecosistema de seguridad empresarial existente
Prueba práctica
“¿Puede adoptarse el plano de control sin reemplazar las plataformas de identidad, KMS/HSM, PKI o monitoreo ya existentes?”
04
Pilar de apoyo
Escenario que realiza
Aplicación de política en múltiples jurisdicciones
Prueba práctica
“¿Puede la organización demostrar, consultando el plano de control, qué política se aplicó a una operación dada, y cambiar esa política de forma centralizada?”
Salto de madurez
De un KMS del que la plataforma depende a un Control Plane que gobierna las llaves dondequiera que se custodien. La custodia es la propiedad que hace aceptable el nivel 3 para una organización que de otro modo no podría adoptarlo.
No opera su HSM ni su cuenta en la nube. El backend, su credencial y su disponibilidad siguen siendo suyos; ANKASecure© lo llama y registra la llamada.
No mueve por su cuenta el material de llaves existente de un tenant entre backends. Cambiar el Root of Trust es una operación gobernada con su propia evidencia, no una migración en segundo plano.
No lo certifica. ANKASecure© mapea sus controles a NIST CSWP 39, la PQC Buyer’s Guide de la GSA y OWASP y le entrega la evidencia; la determinación sigue siendo de su auditor.
Después de esto
Sin nuevo despliegue ni segundo contrato por la plataforma. Una vez el Root of Trust está donde debe estar, todo lo demás encima es política.
La que dice que las llaves se quedan. Quince minutos sobre un despliegue real para mostrarla como un ajuste, contra una cuenta que usted controla.
Agendar la demo