TL;DR: La mayoría de las organizaciones gobiernan bien sus certificados. Esa misma disciplina rara vez se extiende a los tokens de API, las credenciales de servicio y los secretos compartidos que transmiten una confianza equivalente. Cerrar esa brecha es precisamente de lo que trata la gestión del ciclo de vida de la confianza, y se está convirtiendo rápidamente en una categoría que los CISO deben asumir.
La brecha a la que se enfrentan la mayoría de las empresas no es de herramientas. Es de gobernanza. Además, abarca un conjunto de artefactos de confianza mucho más amplio que el que cubría la gestión tradicional del ciclo de vida de certificados.
Un auditor interno entra en la oficina de un CISO y hace dos preguntas. Primera: ¿quién tiene acceso a producción y cuándo caducan esas credenciales? Para los certificados, la respuesta suele llegar rápido. Normalmente, la plataforma de gestión de certificados enumera cada certificado emitido, su propietario, su fecha de renovación y su estado de revocación. Mientras tanto, la segunda pregunta plantea lo mismo, pero para los tokens de API, las credenciales de cuentas de servicio y las claves de firma. Esos artefactos están dispersos entre Vault, AWS Secrets Manager, Kubernetes y doce pipelines de CI distintos. Como resultado, esa pregunta suele provocar una pausa más larga.
Esa pausa es una brecha de gobernanza, y los reguladores han empezado a detectarla. Tanto NIS2 como DORA exigen evidencias de controles del ciclo de vida sobre material criptográfico y credenciales de autenticación. Ese lenguaje abarca mucho más que X.509. Además, la realidad operativa coincide con la presión regulatoria. La mayoría de los incidentes actuales relacionados con credenciales implican secretos expuestos o robados, no criptografía rota. Sin embargo, las herramientas y la gobernanza que la mayoría de las organizaciones aplican a estas dos categorías son completamente distintas.
El problema de alcance: los certificados son una clase de artefacto de confianza
Primero, considere qué es lo que realmente transmite confianza dentro de una empresa moderna. Los certificados X.509 son el caso más evidente. Sin embargo, comparten función con varios otros tipos de artefactos. Entre ellos se incluyen secretos de cliente OAuth, tokens de API, credenciales de cuentas de servicio, secretos de firma de webhooks, contraseñas de bases de datos, claves SSH, claves de firma JWT y materiales de firma de código. Cada uno representa una afirmación: el portador puede actuar en nombre de una identidad, con un propósito determinado, hasta una fecha determinada.
La forma criptográfica varía. La audiencia varía. La duración puede ir de minutos a años. Sin embargo, las primitivas del ciclo de vida se mantienen sorprendentemente constantes. En concreto, cada artefacto necesita cuatro cosas: crear conforme a una política, sincronizar con cada consumidor, rotar según un calendario predecible y revocar rápidamente cuando se pierde la confianza. Alguien debe mantener la responsabilidad en cada paso.
Tratar los certificados como algo especial y todo lo demás como una categoría vagamente gobernada llamada “secretos” crea una división artificial que dificulta la gobernanza en lugar de facilitarla.
Qué significa realmente la gestión del ciclo de vida de la confianza
En la práctica, la gestión del ciclo de vida de la confianza es la disciplina de aplicar una gobernanza unificada a cada artefacto que confiere confianza dentro de una organización. Es importante destacar que no sustituye HashiCorp Vault, AWS Secrets Manager o Kubernetes Secrets por un sistema nuevo. Esas herramientas ya resuelven bien el almacenamiento y la distribución. Lo que falta es el plano de gobernanza por encima de ellas. Esa capa sabe que existe cada artefacto, independientemente del backend, y aplica una política coherente a todos.
Como consecuencia, las primitivas compartidas se aplican de forma uniforme a todos los artefactos de confianza. Crear bajo una política controlada. Sincronizar con los consumidores que necesitan el artefacto. Rotar según un calendario predecible. Revocar rápidamente cuando se pierde la confianza. Lo que cambia respecto a la PKI tradicional es el alcance, no las primitivas. Sobre todo, este enfoque importa en empresas reguladas. Nuestra publicación anterior sobre pasar del cumplimiento a la gestión del ciclo de vida de la confianza explica por qué.
La brecha de gobernanza creada por herramientas de secretos aisladas
En la práctica, recorra cualquier entorno empresarial y encontrará el mismo patrón. Los secretos viven en varios sistemas. Cada uno tiene su propio modelo de acceso, su propia semántica de rotación y su propio registro de auditoría.
| Herramienta | Alcance típico | Modelo de políticas | Registro de auditoría |
|---|---|---|---|
| HashiCorp Vault | Secretos de aplicaciones, PKI | Documentos de políticas HCL | Dispositivos de auditoría |
| AWS Secrets Manager | Credenciales nativas de AWS | Políticas IAM | CloudTrail |
| Kubernetes Secrets | Credenciales a nivel de pod | RBAC | Registro de auditoría de Kubernetes |
| Vault de GitHub Actions | Credenciales de pipeline | Permisos de repositorio | Registros de CI |
| Valores codificados directamente | Cargas de trabajo heredadas, scripts ad hoc | Ninguno | Ninguno |
Como resultado, hay tres preguntas operativas que se vuelven muy difíciles de responder con confianza:
- Inventario. “Enumere todas las credenciales con acceso a nuestra base de datos de producción, su propietario, la política de rotación y la última vez que se rotaron”. Reunir todo esto entre cinco o seis sistemas lleva días.
- Política. “¿Se rotan todos los secretos de producción al menos cada 90 días?”. La respuesta depende del backend y del equipo, sin ningún punto central de aplicación.
- Auditoría. “Muéstreme cada vez que se recuperó este token de API en los últimos 90 días, quién lo solicitó y si su acceso seguía siendo válido”. El rastro de evidencias abarca varios sistemas de registros, cada uno con su propio esquema y política de retención.
En la práctica, estas brechas no detienen las operaciones. Simplemente encarecen las auditorías y ralentizan la respuesta ante incidentes. Ambos resultados son cada vez menos aceptables bajo las expectativas regulatorias actuales. Además, ambos apuntan a la misma causa raíz: no existe un plano de gobernanza unificado.
Qué requiere una gestión unificada del ciclo de vida de la confianza
En resumen, una plataforma que unifique de verdad la gestión del ciclo de vida de la confianza tiene cuatro características. Juntas, cierran las brechas de gobernanza anteriores.
Por debajo de las cuatro existe un requisito arquitectónico: independencia del backend. La plataforma debe funcionar con las herramientas que las organizaciones ya utilizan. Obligar a sustituir Vault o AWS Secrets Manager no es realista ni deseable. Además, NIST SP 800-57 Parte 1 Revisión 5 ya trata los certificados y otros materiales de claves dentro de un marco de políticas coherente; consulte sus recomendaciones para la gestión de claves. Extender ese marco para cubrir tokens y credenciales es un siguiente paso lógico, no una invención nueva.
Cómo aborda OmniTrust la gestión unificada del ciclo de vida de la confianza
En RSA Conference 2026, OmniTrust lanzó la primera plataforma unificada de gestión del ciclo de vida de la confianza del sector. El posicionamiento es deliberado. Esta es la categoría que OmniTrust considera que los CISO deben asumir. Además, la plataforma operacionaliza el modelo de capacidades descrito anteriormente.
ILM, la plataforma de código abierto para la gestión del ciclo de vida de identidades, sustenta la oferta. En versiones anteriores, sus primitivas de políticas, inventario y auditoría gobernaban certificados. Hoy esas mismas primitivas también cubren secretos, claves y credenciales. Mientras tanto, el módulo Secrets Management federa HashiCorp Vault y backends similares dentro del plano de gobernanza de ILM. No los sustituye.
El mismo lenguaje de políticas que define la rotación de certificados ahora define la rotación de credenciales. Del mismo modo, el mismo flujo de auditoría cubre ambos. Para un CISO, el resultado práctico es sencillo. Las dos preguntas del inicio de esta publicación ahora tienen la misma respuesta. Además, esa respuesta procede de una única consola. Un auditor puede consumirla sin tener que unir registros de varios sistemas.
Conclusiones clave
- Los certificados son una clase de artefacto de confianza; los secretos, tokens y claves transmiten una confianza equivalente y merecen una gobernanza equivalente.
- La gestión del ciclo de vida de la confianza aplica un conjunto coherente de primitivas —crear, sincronizar, rotar, revocar— de forma uniforme a cada artefacto que transmite confianza.
- La brecha a la que se enfrentan la mayoría de las empresas no es de herramientas, sino de gobernanza: múltiples backends sin una política, un inventario o un plano de auditoría compartidos.
- La arquitectura adecuada federa backends existentes como Vault y AWS Secrets Manager en lugar de obligar a sustituirlos.
- Los marcos regulatorios como NIS2 y DORA esperan cada vez más evidencias de gobernanza sobre todos los artefactos de confianza, no solo sobre los certificados.
Para explorar en detalle la plataforma ILM y el módulo Secrets Management, visite la página de la plataforma Secrets Management. Por último, para conocer el contexto del posicionamiento, consulte el anuncio de RSA Conference 2026. Explica por qué OmniTrust lanzó esta categoría y qué aporta en la práctica la gestión unificada del ciclo de vida de la confianza.
