Gestión de certificados y claves digitales en DevOps

La gestión de certificados y claves en DevOps consiste en emitir, almacenar, rotar y revocar automáticamente certificados digitales y claves criptográficas en pipelines de CI/CD, contenedores e infraestructura en la nube. Si se implementa correctamente, proporciona a cada carga de trabajo una identidad confiable sin ralentizar la entrega.

La gestión de certificados y claves digitales en DevOps implica automatizar la emisión, el almacenamiento, la rotación y la revocación de certificados TLS, claves de firma de código, claves SSH y secretos en los flujos de trabajo de CI/CD y las cargas de trabajo en la nube. La automatización mediante el protocolo ACME (Automatic Certificate Management Environment), las plataformas de gestión del ciclo de vida de los certificados y los gestores de secretos garantiza una entrega rápida, al tiempo que previene la caducidad de los certificados y la filtración de claves privadas.

Puntos Clave

• Los certificados y las claves autentican cada máquina en una canalización: TLS para las conexiones de cliente, TLS mutuo entre servicios, firma de código para los artefactos de compilación y SSH para el acceso al repositorio y al servidor.
• La propuesta SC-081v3 del Foro CA/Browser reduce la validez máxima de los certificados TLS públicos a 200 días a partir del 15 de marzo de 2026, a 100 días a partir del 15 de marzo de 2027 y a 47 días a partir del 15 de marzo de 2029. La renovación se convierte en un proceso mensual que solo la automatización puede gestionar.
• ACME, estandarizado como IETF RFC 8555 en marzo de 2019, automatiza la validación, emisión y renovación. cert-manager, cuya certificación CNCF se anunció en noviembre de 2024, aplica la misma automatización dentro de Kubernetes.
• La filtración de datos de Equifax en 2017 expuso información de aproximadamente 147 millones de personas, y la exfiltración pasó desapercibida durante 76 días porque un certificado en un dispositivo de monitoreo de tráfico había caducado.
• Las claves privadas deben almacenarse en un gestor de secretos o en un módulo de seguridad de hardware (HSM), nunca en repositorios de código fuente. La filtración de datos de Uber en 2016, que expuso 57 millones de registros, comenzó con credenciales encontradas en un repositorio privado de GitHub.

¿Qué hacen los certificados y las claves en un pipeline de DevOps?

Los certificados y las claves proporcionan una identidad confiable a cada máquina, servicio y artefacto con el que interactúa una canalización de DevOps. Los certificados digitales protegen el tráfico de clientes a través de HTTPS , y los certificados TLS mutuos autentican los microservicios entre sí dentro del clúster. Las claves de firma de código demuestran que un artefacto de compilación o una imagen de contenedor proviene de su canalización y no ha sido alterada posteriormente. Las claves SSH controlan el acceso a repositorios y servidores, y los tokens de API autentican cada llamada automatizada.

El resultado es que las identidades de las máquinas en una canalización superan con creces a las personas que la gestionan. Cada servidor de compilación, contenedor y entorno de prueba efímero necesita credenciales, y cada credencial tiene un ciclo de vida: se crea, se usa, se rota y se retira. La gestión de certificados y claves consiste en gestionar ese ciclo de vida de forma deliberada, en lugar de dejar que ocurra por accidente.

Por qué DevOps supera la gestión manual de certificados

Los procesos manuales de certificación fallan en DevOps porque la infraestructura cambia más rápido de lo que una cola de tickets puede responder. Una solicitud de certificado tradicional requería días de validación y aprobación, lo cual era tolerable cuando los servidores tenían una vida útil de varios años. Un contenedor que solo dura veinte minutos no puede abrir un ticket.

Cuando la emisión de certificados es lenta, los ingenieros buscan soluciones alternativas. Generan certificados autofirmados, reutilizan un certificado comodín en decenas de servicios o almacenan las claves en un repositorio para que el sistema pueda encontrarlas. Cada solución alternativa crea criptografía que ningún inventario registra ni ningún proceso de renovación cubre. Cada certificado que un sistema crea fuera del inventario representa una interrupción o una brecha de seguridad pendiente de resolución.

Cómo se ve el fracaso: Equifax y Uber

Dos incidentes bien documentados demuestran lo que sucede cuando la certificación y la higiene básica no se corresponden con la velocidad de entrega.

En 2017, Equifax sufrió una brecha de seguridad debido a una vulnerabilidad sin parchear en Apache Struts (CVE-2017-5638), que expuso datos personales de aproximadamente 147 millones de personas. La lección sobre certificados radica en el fallo de detección: la revisión de la Oficina de Responsabilidad Gubernamental de EE. UU. descubrió que un certificado en el dispositivo que Equifax utilizaba para inspeccionar el tráfico de red había caducado, por lo que la filtración se prolongó durante 76 días antes de que alguien la detectara. Un certificado caducado no fue la causa de la brecha, pero impidió que las herramientas que deberían haberla detectado la detectaran.

En 2016, unos atacantes obtuvieron credenciales de Uber de un repositorio privado de GitHub y las utilizaron para acceder al almacenamiento en la nube que contenía datos de 57 millones de pasajeros y conductores, una brecha de seguridad que Uber reveló en 2017. Las claves y credenciales almacenadas en el control de versiones son secretos en el lugar que todo atacante revisa primero. Uber respondió con controles de acceso más estrictos y autenticación multifactor para el acceso al código; la solución más económica es no almacenar nunca material clave en un repositorio.

El plazo de validez de 47 días aumenta las expectativas.

La duración de los certificados TLS públicos se reducirá a 47 días para marzo de 2029 según la votación SC-081v3 del Foro CA/Browser , aprobada en abril de 2025. La reducción se implementará por etapas:

Fecha efectiva	Validez máxima del certificado TLS
Hasta el 14 de marzo de 2026	398 días
Marzo 15, 2026	200 días
Marzo 15, 2027	100 días
Marzo 15, 2029	47 días

A los 47 días, todos los servicios de cara al público renuevan sus certificados aproximadamente cada mes, y cualquier equipo que aún los renueve manualmente invertirá más tiempo en ello del que realmente vale la pena. Para los equipos de DevOps, esto resuelve la cuestión de la automatización: el pipeline que implementa el servicio también debe poder renovar su certificado. Las organizaciones pueden evaluar su nivel de riesgo ahora mismo mediante una revisión de preparación de certificados a los 47 días, en lugar de esperar a la fase de los 100 días en marzo de 2027 para abordar el problema.

Seis prácticas para gestionar certificados y claves en DevOps

Seis prácticas cubren la mayor parte del riesgo en la gestión de certificados y claves de DevOps, y cada una de ellas se puede implementar sin interrumpir la entrega.

1. Cree y mantenga un inventario de certificados y claves: Registre cada certificado y clave del entorno: tipo, propietario, fecha de vencimiento, ubicación y autoridad emisora. El inventario es fundamental para todo lo demás, ya que no se puede renovar, rotar ni revocar lo que no se puede ver. El descubrimiento debe ser continuo; una auditoría puntual queda obsoleta el día que se ejecuta el siguiente proceso.
2. Automatice la emisión y renovación: Utilice el protocolo ACME (IETF RFC 8555, marzo de 2019) o una plataforma de gestión del ciclo de vida de los certificados para que estos se emitan y renueven sin tickets. En Kubernetes, administrador de certificados Automatiza la emisión y renovación de TLS y TLS mutuo, y su graduación de la CNCF, anunciada en noviembre de 2024, refleja lo estandarizada que se ha vuelto esta automatización.
3. Proteja las claves privadas en un HSM o un gestor de secretos: Las claves nunca deben estar en repositorios de código fuente, imágenes de contenedores ni variables de canalización simples. Almacénelas en un módulo de seguridad de hardware o un gestor de secretos, y permita que las cargas de trabajo las obtengan en tiempo de ejecución mediante un acceso auditado y de corta duración.
4. Implementar el principio de acceso con privilegios mínimos: Restrinja quién y qué puede solicitar certificados, leer claves o cambiar la política de emisión, y registre cada acceso. Los controles basados ​​en roles en la autoridad de certificación y el almacén de secretos limitan el alcance de las consecuencias cuando se filtra una sola credencial.
5. Supervise la fecha de caducidad y reciba alertas con antelación; Realiza un seguimiento de cada certificado según su fecha de vencimiento y recibe alertas mucho antes de que venza el plazo de renovación, incluidos los certificados de las propias herramientas de seguridad. Equifax demuestra por qué: monitorizar algo que no se puede descifrar es monitorizar algo que no existe.
6. Prefiera credenciales de corta duración: Los certificados y tokens de corta duración reducen el tiempo que un atacante puede usar una credencial robada y disminuyen la dependencia de la revocación. De todos modos, la industria ya se está moviendo en esta dirección; adoptar duraciones cortas desde el principio hace que el plazo de 47 días sea irrelevante.

Integración de la seguridad de certificados en CI/CD

La seguridad de los certificados se mantiene en DevOps cuando se expresa de la misma manera que el resto de la infraestructura: como código. Las políticas de emisión, los perfiles de certificados y la configuración de confianza deben estar en el control de versiones, donde se revisan y revierten como el código de la aplicación. El análisis de secretos en el pipeline debería provocar el fallo de cualquier compilación que incluya una clave privada o una credencial codificada, lo que convierte el modo de fallo de Uber en una fusión bloqueada en lugar de una brecha de seguridad. La monitorización continua cierra el ciclo, enviando los eventos de caducidad de certificados y de emisión anómala al mismo sistema de alertas que supervisa la aplicación.

Cómo ayuda la consultoría de cifrado

CertSecure Manager es la plataforma de gestión del ciclo de vida de certificados de Encryption Consulting. Descubre e inventaría los certificados en todo su entorno y automatiza la emisión, renovación y revocación, de modo que los certificados de canalización se renuevan según un calendario establecido, en lugar de por incidencias. Para los equipos que amplían la seguridad de su canalización, la práctica de Securing DevOps abarca la gestión de claves y la arquitectura PKI . Respaldada por las prácticas certificadas ISO/IEC 27001:2022 y SOC 2.

Preguntas frecuentes

¿Por qué la gestión de certificados es más difícil en DevOps que en la TI tradicional?

La infraestructura de DevOps es efímera. Los contenedores y las instancias en la nube se crean y se destruyen en minutos, y cada uno necesita una identidad de confianza, por lo que el volumen de certificados crece mucho más allá de lo que puede gestionar un proceso de emisión basado en tickets. La TI tradicional renovaba un conjunto conocido de certificados una vez al año; una canalización puede solicitar cientos de certificados al día y no puede esperar días por cada uno.

¿Qué es ACME y cómo ayuda a los equipos de DevOps?

ACME (Automatic Certificate Management Environment) es el protocolo estandarizado en el RFC 8555 de la IETF en marzo de 2019. Automatiza la validación de dominios, la emisión y la renovación de certificados entre un cliente y una autoridad de certificación, sin intervención humana. Herramientas como cert-manager utilizan ACME para emitir y renovar certificados para cargas de trabajo de Kubernetes de forma automática, que es como operan las autoridades de certificación públicas como Let's Encrypt a gran escala.

¿Cómo afecta la norma de validez de los certificados de 47 días a los flujos de trabajo de DevOps?

La propuesta SC-081v3 del Foro CA/Browser reduce gradualmente la validez máxima de los certificados TLS públicos: 200 días a partir del 15 de marzo de 2026, 100 días a partir del 15 de marzo de 2027 y 47 días a partir del 15 de marzo de 2029. Con 47 días, todos los servicios públicos renuevan sus certificados aproximadamente cada mes. La renovación manual no puede mantener ese ritmo, por lo que la emisión y renovación automatizadas dentro del proceso se convierten en un requisito indispensable, en lugar de una optimización.

¿Dónde deben almacenarse las claves privadas en un pipeline de CI/CD?

Las claves privadas deben almacenarse en un gestor de secretos o en un módulo de seguridad de hardware (HSM), nunca en repositorios de código fuente, imágenes de contenedores ni variables de canalización sin procesar. La filtración de Uber en 2016 comenzó con credenciales encontradas en un repositorio privado de GitHub. Las canalizaciones deben obtener las claves en tiempo de ejecución mediante un acceso auditado y de corta duración, y el análisis de secretos debe rechazar cualquier compilación que incluya información confidencial en el código.

¿Cuál es la diferencia entre un gestor de secretos y una plataforma de gestión del ciclo de vida de los certificados?

Un gestor de secretos almacena y rota valores confidenciales como claves privadas, tokens de API y contraseñas, y los proporciona a las cargas de trabajo en tiempo de ejecución. Una plataforma de gestión del ciclo de vida de los certificados (CLM) administra el certificado en sí: descubrimiento, inventario, emisión a través de una autoridad de certificación, renovación y revocación. Ambos son complementarios. La plataforma CLM decide cuándo y cómo existe un certificado; el gestor de secretos protege el material clave del que depende.

Automatice el ciclo de vida de los certificados antes de que se agote el tiempo.

El límite de 200 días entró en vigor el 15 de marzo de 2026, y el ritmo se acelerará aún más a partir de ahora. Vea CertSecure Manager en acción para automatizar la detección, emisión y renovación en todos sus flujos de trabajo, o genere una solicitud de prueba con el Generador de CSR gratuito para comprobar su flujo de emisión actual.