Un algoritmo tiene que salir
Deprecado, roto, o rechazado por el cuestionario de un cliente. El incidente tiene reloj, y tu respuesta honesta es un calendario de releases en cada aplicación que lo toca.
ANKASecure© convierte un cambio criptográfico en una operación de política en vez de un proyecto de aplicación. Las aplicaciones referencian una llave por un identificador estable y nunca nombran un algoritmo, así que el algoritmo, la versión de material y los parámetros detrás de ese identificador pueden cambiar mientras los datos históricos se siguen descifrando bajo la versión que los escribió. El conjunto permitido de algoritmos es una política de disponibilidad aplicada a todo el despliegue o por tenant, con veintinueve plantillas que incluyen conjuntos jurisdiccionales alineados a BSI, ANSSI, ETSI, CNSA 2.0, CRYPTREC y KCMVP, sobre un catálogo de más de 120 algoritmos de los cuales 33 son post-cuánticos. Antes de hacer un cambio, la plataforma calcula la admisibilidad de rotación por candidato y devuelve un código de razón — degradación de seguridad, requiere híbrido, violación de propósito — con la misma regla que ejecuta. Un cambio de política propaga al punto de enforcement por tenant en menos de un segundo sin reinicio, y cada operación posterior queda registrada con la política que la decidió en un rastro de auditoría firmado y a prueba de manipulación. Esto aplica a aplicaciones ya onboardeadas al control plane; el onboarding es trabajo real, y lo que cambia es la economía de cada transición posterior.
Cada cambio criptográfico te cuesta un proyecto por aplicación.
Nadie pide agilidad criptográfica por su nombre. Lo que se vive es esto: cuando un algoritmo tiene que cambiar, es un cambio de código, un ciclo de regresión, una validación de seguridad y un release — multiplicado por cada aplicación que lo usa. Así que el cambio se aplaza, y el parque sigue corriendo sobre lo que ya debería haber dejado atrás. ANKASecure© convierte ese cambio en una operación de política.
CISOResponsable de criptografíaArquitecto empresarial
Es su caso
Tres formas en que esto llega a tu escritorio
Dos jurisdicciones, dos listas aprobadas
Una filial bajo BSI necesita híbrido. Un contrato federal nombra CNSA 2.0. Una operación en Japón corre sobre CRYPTREC. Hoy eso significa stacks separados, o excepciones que nadie quiere firmar.
Quieres subir el nivel y no puedes justificar un release
Sin vulnerabilidad y sin incidente — solo una postura que preferirías tener. Sin un evento que fuerce, el cambio nunca llega a un sprint, y la brecha entre lo que corres y lo que elegirías se ensancha.
Quién firma esto: Un CISO o responsable de criptografía a quien van a preguntarle qué tan rápido puede moverse la organización, y un arquitecto empresarial que sabe lo que cuesta de verdad un cambio en doscientas aplicaciones. Si la respuesta a “¿cuánto para salir de este algoritmo?” se mide en trimestres, esta es la conversación.
Cómo funciona
Cuatro movimientos, ninguno es un release
La aplicación nunca nombra un algoritmo, así que cambiar el algoritmo no es un cambio en la aplicación. Lo que se mueve es la política — y la plataforma puede decirte de antemano si el movimiento está permitido.
La aplicación referencia un nombre, no un mecanismo
Pide una llave por su identificador estable. Qué algoritmo, qué versión de material y qué parámetros hay detrás es asunto de la plataforma, y pueden cambiar por debajo mientras los datos históricos se siguen descifrando.
- KID estable
- versiones de material
El cambio es una decisión de política, no de código
El conjunto permitido de algoritmos es una política, aplicada a todo el despliegue o por tenant. El producto trae veintinueve plantillas, incluidas las jurisdiccionales — BSI, ANSSI, ETSI, CNSA 2.0, CRYPTREC, KCMVP — sobre un catálogo de 120+ algoritmos, 33 de ellos post-cuánticos.
- política de disponibilidad
- 29 plantillas
- plano de despliegue o de tenant
El servidor te dice si el movimiento es admisible, antes de hacerlo
Pides la admisibilidad de rotación de una llave y la plataforma devuelve un veredicto por candidato con su código de razón — degradación de seguridad, requiere híbrido, violación de propósito. Es la misma regla que corre al ejecutar, así que la vista previa y el resultado no pueden contradecirse.
- admisibilidad de rotación
- reasonCode
Surte efecto en menos de un segundo, y la evidencia muestra que aplicó
Un cambio de política llega al punto de enforcement por tenant sin reiniciar nada. Cada operación posterior queda registrada con la política que la decidió, firmada, en una cadena que delataría cualquier edición. El cambio no es una afirmación: es un hecho consultable.
- propagación sub-segundo
- auditoría firmada
El algoritmo es una configuración. Esta es la configuración.
Veintinueve plantillas en el catálogo —NIST_APPROVED, EU_COMPLIANT para ENISA, GDPR, NIS2 y eIDAS 2.0, HIGH_SECURITY para niveles 3 y 5— aplicadas a todo el despliegue y sobreescribibles por tenant. Cambiar la plantilla cambia lo que puede usar la siguiente operación.
Quince minutos
Lo que vas a ver de verdad
En vivo, sobre un despliegue real, con un algoritmo del tipo en el que estás atascado. Nada de esta lista es una maqueta ni un elemento de roadmap.
Una aplicación cifrando bajo un algoritmo clásico, referenciando su llave por nombre.
El veredicto de admisibilidad de esa llave: qué candidatos se permiten, cuáles se rechazan y el código de razón de cada uno.
La política cambia centralmente. Ninguna aplicación se toca. No se corta ningún release.
La misma aplicación, sin cambios y sin reiniciar, escribiendo ahora bajo el mecanismo nuevo.
Un candidato que la política rechaza: la operación se deniega con su razón, nunca se degrada en silencio.
El rastro de auditoría: qué política decidió qué operación, firmado — la evidencia que pide un auditor.
Sobre qué se apoya
Las capabilities debajo, con su estado
Disponible
Identificadores estables de llave
La aplicación referencia un kid; las versiones de material se mueven por debajo y los datos históricos se siguen descifrando bajo la versión que los escribió.
Disponible
Política de disponibilidad, dos planos
Para todo el despliegue o por tenant, enforced en cada operación y fail-closed: una política ilegible deniega, no permite.
Disponible
Veintinueve plantillas de política
Conjuntos jurisdiccionales y alineados a estándares sobre un catálogo de 120+ algoritmos, 33 de ellos post-cuánticos.
Disponible
Admisibilidad de rotación calculada por el servidor
Un veredicto por candidato con su código de razón, producido por la misma regla que corre cuando la rotación se ejecuta.
Disponible
Propagación de política sub-segundo
Un cambio llega al punto de enforcement por tenant sin reinicio ni redespliegue.
Disponible
Auditoría firmada
Qué política decidió qué operación, a prueba de manipulación, reenviable a tu SIEM con la firma intacta.
El marco
Dónde encaja en CAPA
La arquitectura de referencia del Cryptographic Control Plane describe cada pilar por los escenarios que debe resolver y una prueba práctica. Esta solución es dos de los tres escenarios del primer pilar: responder a una vulnerabilidad de algoritmo, y evolucionar la estrategia criptográfica sin un release de aplicación.
01
Pilar principal
Crypto-Agility
Escenario que realiza
Responder a una vulnerabilidad de algoritmo
Prueba práctica
“¿Puede cambiar la estrategia criptográfica sin exigir un cambio o un release de la aplicación?”
04
Pilar de apoyo
Cryptographic Governance & Compliance
Escenario que realiza
Hacer cumplir un nuevo requisito de seguridad empresarial
Prueba práctica
“¿Puede la organización demostrar, consultando el control plane, qué política aplicó a una operación dada, y cambiar esa política centralmente?”
L2–L3L4–L5
Salto de madurez
De un cambio criptográfico que necesita un release a uno que es una operación de política — y de ahí a una organización que puede decir cuánto tarda una transición, porque ya hizo una y tiene la evidencia.
Lo que esto no hace
No aplica a aplicaciones que no han sido onboardeadas. La arquitectura de referencia es explícita y nosotros también: el onboarding es trabajo real. Lo que cambia es la economía de cada transición posterior — la primera aplicación es un proyecto; el siguiente cambio, no.
No hace una representación universalmente interoperable. Un sistema externo puede leer lo que produces solo si soporta los algoritmos, identificadores y perfiles de esa operación; tu agilidad no es su adopción.
No reescribe datos ya escritos. Mover un cifrado existente a un algoritmo nuevo es re-cifrado — esa es la conversación de migración post-cuántica, y usa el mismo control plane.
Después de esto
La misma instalación ya hace estas
Sin despliegue nuevo y sin un segundo contrato por la plataforma. Cuando la criptografía es una operación de política, el resto es un cambio de política.
¿Cuánto tardarías en salir de un algoritmo?
Trae el que más te gustaría quitarte de encima. Quince minutos sobre un despliegue real: el veredicto de admisibilidad, el cambio de política, y la misma aplicación escribiendo bajo el mecanismo nuevo sin un release.
Agendar la demo