MODELOS DE DESPLIEGUE
Tres formas de operarlo, una frontera de custodia
El modelo de despliegue se elige al crear el entorno y no cambia después. Lo que separa a los modelos es quién los opera: ANKATech en SaaS y tu propio equipo en nube privada y on-premise.
Operado por ANKATech
SaaS
- Quién lo opera
- ANKATech opera la plataforma; tú administras tu tenant.
- Dónde se ejecuta
- Infraestructura de ANKATech, compartida entre tenants y aislada por tenant.
- Raíz de confianza
- Una clave de cifrado de claves por tenant en un backend que gestiona ANKATech, cuyo nivel de garantía depende de la edición, hasta un HSM dedicado en la nube. En las ediciones que lo incluyen, traes en su lugar tu propia clave de Cloud KMS: AWS KMS (también en un almacén de claves sobre tu propio clúster CloudHSM), Google Cloud KMS o Azure Key Vault.
- Qué puede ver ANKATech
- Estado del servicio, cantidad de tenants, conteo de claves y volúmenes de uso. No tus claves, aplicaciones, usuarios, políticas ni el contenido de tu auditoría. ANKATech no puede actuar dentro de tu tenant salvo que tu administrador conceda un acceso de soporte acotado en el tiempo (24 horas como máximo), e incluso entonces no puede importar ni destruir claves.
- Conexión con ANKATech
- El propio servicio.
Operado por ti
Nube privada
- Quién lo opera
- Tu equipo opera toda la plataforma.
- Dónde se ejecuta
- Tu propia cuenta de nube (AWS, Azure, Google Cloud).
- Raíz de confianza
- Tu HSM o Cloud KMS. Las claves de cifrado de claves nunca salen de él.
- Qué puede ver ANKATech
- Nada: ni texto en claro, ni texto cifrado, ni claves, ni auditoría, ni tenants, ni usuarios.
- Conexión con ANKATech
- Ninguna: sin acceso entrante, sin telemetría y sin conexiones de vuelta a ANKATech. La licencia es un archivo firmado que se verifica localmente.
Operado por ti
On-premise
- Quién lo opera
- Tu equipo opera toda la plataforma.
- Dónde se ejecuta
- Tu centro de datos, conectado o aislado de la red (air-gapped).
- Raíz de confianza
- Tu HSM (Thales Luna, Entrust nShield y otros dispositivos PKCS#11) o Cloud KMS. Las claves de cifrado de claves nunca salen de él.
- Qué puede ver ANKATech
- Nada: ni texto en claro, ni texto cifrado, ni claves, ni auditoría, ni tenants, ni usuarios.
- Conexión con ANKATech
- Ninguna: sin acceso entrante, sin telemetría y sin conexiones de vuelta a ANKATech. La licencia es un archivo firmado que se verifica localmente, así que un sitio aislado no necesita activación en línea.
Nube privada y on-premise se comportan igual: cada decisión de la plataforma que depende del modelo de despliegue los trata de la misma forma. Solo cambia dónde está tu infraestructura. En ambos, tus propios administradores de plataforma pueden administrar todos los tenants, pero aun así no pueden extraer material de claves del HSM ni alterar registros de auditoría históricos.
ARQUITECTURA DE SEGURIDAD
Controles que la plataforma aplica en todos los modelos
Son propiedades del código, no de un procedimiento operativo: se cumplen sin importar quién opere el despliegue.
Claves envueltas bajo tu raíz de confianza
Cada clave se guarda envuelta con AES-256-GCM bajo una clave de cifrado de claves que permanece en el HSM o Cloud KMS: dispositivos PKCS#11, AWS KMS, Google Cloud KMS o Azure Key Vault. El envoltorio queda ligado al tenant, así que una clave envuelta no puede reutilizarse en otro tenant.
Aislamiento de tenants que falla cerrado
El tenant sale del token verificado, nunca de la petición, y cada consulta se limita a él. Los datos de autorización que comparten los servicios van firmados con Ed25519; un valor ausente, vencido o que no se puede verificar deniega la operación en lugar de caer en un valor por defecto.
TLS mutuo entre servicios
Cada salto interno es TLS mutuo: cada servicio presenta su propio certificado y solo admite a los pares que espera. Las conexiones a la base de datos usan TLS 1.3 con verificación completa del servidor.
Auditoría firmada y a prueba de manipulación
Cada operación criptográfica y administrativa emite un evento de auditoría firmado con HMAC-SHA256 por el servicio que lo produjo y verificado antes de almacenarse. Los eventos pueden reenviarse a tu SIEM en CEF u OCSF por Syslog, Splunk HEC, Microsoft Sentinel o webhook.
Claves híbridas que exigen las dos mitades
Las claves compuestas combinan un algoritmo clásico y uno poscuántico con descifrado AND: un atacante debe romper ambos. ANKASecure© no implementa a propósito la variante OR, que solo es tan fuerte como su mitad más débil. Además, los datos sensibles pueden viajar dentro de una sesión ML-KEM.
Versiones y licencias firmadas
Cada versión publica sus imágenes de contenedor por digest en un manifiesto de versión firmado, y un entorno instalado despliega exactamente esos digests. La licencia se firma con una clave compuesta ML-DSA-65 y Ed25519 y se verifica localmente contra una clave pública incluida en la plataforma.
ESTÁNDARES
Alineado con estándares publicados
ANKASecure© implementa los estándares poscuánticos de NIST y el catálogo más amplio de algoritmos internacionales y regionales.
FIPS 203
ML-KEM
FIPS 204
ML-DSA
FIPS 205
SLH-DSA
CNSA 2.0
Alineación de algoritmos
PREGUNTAS FRECUENTES
Lo primero que preguntan los equipos de seguridad
Revisa la arquitectura con nuestros ingenieros
Trae tus preguntas de seguridad y las restricciones de tu despliegue; recorremos custodia, aislamiento y auditoría sobre tu modelo.
Hablar con ingeniería