Gestión de certificados basada en la nube

La gestión de certificados en la nube consiste en descubrir, emitir, renovar, revocar y auditar certificados digitales en infraestructuras de nube, contenedores y entornos híbridos desde una plataforma centralizada. Esto es importante porque los entornos de nube generan certificados a una escala y velocidad que el seguimiento manual no puede seguir, y un solo certificado caducado en un balanceador de carga o puerta de enlace API provoca una interrupción total del servicio. Se recomienda implementar una plataforma centralizada de gestión del ciclo de vida de los certificados (CLM) con renovación automatizada basada en ACME antes de que el calendario SC-081v3 del CA/Browser Forum reduzca la validez de los certificados TLS a 47 días para marzo de 2029.

Respuesta rápida: ¿Qué requisitos debe cumplir la gestión de certificados basada en la nube?

La gestión de certificados en la nube requiere cuatro capacidades que funcionen conjuntamente: detección continua de todos los certificados en todas las cuentas, regiones y servicios en la nube, de modo que ningún certificado pase desapercibido para el equipo de seguridad; renovación automatizada mediante ACME o API nativas de la nube antes de que caduquen los certificados; protección de la clave privada en almacenes de claves respaldados por hardware, en lugar de en la configuración de la aplicación o variables de entorno; y un registro de auditoría centralizado de cada evento de emisión, renovación y revocación vinculado a una identidad autenticada. Cada una de estas capacidades es necesaria de forma independiente; ninguna es suficiente por sí sola.

Puntos Clave

• La proliferación de certificados es el principal riesgo para la gestión del ciclo de vida del certificado (CLM) en la nube: El escalado automático en la nube, los contenedores y los microservicios generan certificados de forma programática, a menudo sin visibilidad para el departamento de TI. La mayoría de las organizaciones descubren que tienen entre tres y cinco veces más certificados de los que creían una vez que realizan un análisis completo de la nube.
• Los plazos de validez más cortos hacen que la automatización sea obligatoria: El calendario del CA/Browser Forum SC-081v3 reduce la validez máxima de los certificados TLS a 200 días a partir de marzo de 2026, a 100 días a partir de marzo de 2027 y a 47 días a partir de marzo de 2029. Con una validez de 47 días, la renovación manual resulta operativamente imposible a cualquier escala significativa.
• Las soluciones CLM nativas de la nube y las de terceros cubren ámbitos diferentes: Los servicios nativos (AWS Certificate Manager, certificados de Azure App Service, GCP Certificate Manager) automatizan la renovación dentro del ecosistema de un proveedor de nube. Las plataformas CLM de terceros proporcionan visibilidad unificada y aplicación de políticas en todos los proveedores de nube, sistemas locales y tipos de certificados.
• La protección de la clave privada es tan importante como la renovación del certificado: Un proceso de renovación automatizado que almacena la nueva clave privada en texto plano en una variable de entorno o en un archivo de configuración crea una postura de seguridad peor que la del certificado caducado al que reemplaza.
• Los marcos de cumplimiento ahora requieren explícitamente la gobernanza de certificados: PCI DSS v4.0.1 (obligatorio a partir de marzo de 2025), DORA (aplicable a partir de enero de 2025), HIPAA, FedRAMP y GDPR exigen controles documentados del ciclo de vida de los certificados, no solo el cifrado durante la transmisión.

¿Qué es la gestión de certificados basada en la nube?

Un certificado digital es una credencial criptográfica que vincula una clave pública a una identidad (un nombre de dominio, un servicio, un dispositivo o una persona) y está firmado por una Autoridad de Certificación (CA) para garantizar la confianza de las partes que confían en él. Los certificados TLS/SSL son los más comunes en entornos de nube: autentican servidores web, puntos finales de API, balanceadores de carga y microservicios internos ante los clientes, y cifran la conexión entre ellos.

La gestión de certificados en la nube abarca el ciclo de vida completo de estos certificados en entornos de nube: descubrimiento (localización de todos los certificados en cada cuenta y región de la nube), emisión (solicitud de certificados a una CA pública o privada), implementación (instalación de certificados en los puntos finales correctos), renovación (sustitución de certificados antes de su vencimiento), revocación (invalidación de certificados comprometidos o dados de baja) y auditoría (registro de cada evento del ciclo de vida para demostrar el cumplimiento normativo). Gestionar este ciclo de vida manualmente mediante hojas de cálculo y recordatorios de calendario resulta ineficaz en entornos de nube donde los certificados se cuentan por miles y sus periodos de validez se reducen a tan solo 47 días.

¿Por qué los entornos en la nube dificultan la gestión de certificados?

Los entornos locales suelen tener un inventario limitado y relativamente estático de servidores y servicios, cada uno con certificados cuya validez oscila entre uno y dos años. Los entornos en la nube son fundamentalmente diferentes en cuatro aspectos que agravan el problema de la gestión de certificados.

Escalabilidad y velocidad: Los grupos de autoescalado, las plataformas de orquestación de contenedores (Kubernetes), las funciones sin servidor y las implementaciones de microservicios generan y consumen certificados mediante programación. Un único clúster de Kubernetes puede ejecutar cientos de pods, cada uno con su propio certificado de servicio, y estos se crean y eliminan continuamente. El inventario de certificados en un entorno de nube cambia más rápido de lo que cualquier proceso manual puede gestionar.

Propiedad distribuida: En entornos de nube, los certificados son aprovisionados por equipos de aplicaciones, pipelines de DevOps, equipos de ingeniería de plataforma y, en ocasiones, por desarrolladores individuales, a menudo sin la participación del departamento central de TI. Esto crea inventarios de certificados ocultos que el equipo de seguridad no puede ver, lo que significa que los certificados caducan sin previo aviso y las claves privadas se almacenan de forma insegura en los repositorios de aplicaciones.

Complejidad de entornos multinube e híbridos: La mayoría de las empresas ejecutan cargas de trabajo en AWS, Azure y GCP simultáneamente, junto con infraestructura local. Cada proveedor de nube cuenta con sus propios servicios de certificados nativos, con diferentes API, distintos tipos de certificados y diferentes mecanismos de renovación. Gestionar la política de certificados de forma coherente en este entorno requiere una capa de gestión superior a la de cada proveedor de nube.

Reducción de la validez de los certificados: La propuesta SC-081v3 del Foro CA/Browser reduce la validez máxima de los certificados TLS de confianza pública de forma gradual: 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 una validez de 47 días, cada certificado en una gran infraestructura en la nube debe renovarse aproximadamente ocho veces al año. Esto convierte la renovación automatizada no solo en una buena práctica, sino en una necesidad operativa.

Plataforma CLM nativa en la nube frente a plataforma CLM de terceros: qué cubre cada una

Todos los principales proveedores de servicios en la nube ofrecen un servicio nativo de gestión de certificados. Es fundamental comprender qué abarca cada uno y cuáles son sus limitaciones antes de elegir una estrategia de gestión de certificados (CLM).

AWS Certificate Manager (ACM): Emite y renueva automáticamente certificados TLS públicos para recursos de AWS (Elastic Load Balancers, distribuciones de CloudFront, API Gateway, Elastic Beanstalk). AWS gestiona las claves privadas en un almacenamiento respaldado por HSM y nunca se exponen; no se pueden exportar. ACM también admite un complemento de CA privada para la emisión de certificados privados. ACM no gestiona certificados en infraestructura que no sea de AWS, no proporciona visibilidad de los certificados implementados directamente en instancias EC2 y no gestiona certificados de CA de terceros fuera del ecosistema de ACM.

Certificados de Azure Key Vault: Almacena, administra y renueva automáticamente certificados en Azure Key Vault, con integración a los servicios de Azure (App Service, Application Gateway, Front Door). Admite certificados de DigiCert y GlobalSign mediante las integraciones de socios de CA de Key Vault, y permite importar certificados de otras CA. Azure Key Vault no administra certificados en entornos de AWS o GCP, y para acceder a los certificados fuera de Key Vault se requieren herramientas adicionales.

Administrador de certificados de GCP: Administra certificados SSL para balanceadores de carga y CDN de Google Cloud, con renovación automática basada en ACME para certificados administrados por Google. El Servicio de Autoridad de Certificación (CAS) de GCP proporciona una CA privada administrada para la emisión de certificados internos. El Administrador de certificados de GCP no administra certificados en entornos que no sean de GCP.

La limitación de alcance de cada servicio nativo es la misma: gestiona los certificados dentro del ecosistema de su propio proveedor de nube. Una organización que ejecuta cargas de trabajo en los tres proveedores tiene tres silos de certificados separados, sin un inventario unificado, sin una aplicación coherente de las políticas y sin un registro de auditoría único.

Capacidad	CLM nativo en la nube (por proveedor)	Plataforma CLM de terceros
Alcance del descubrimiento del certificado	Dentro de un único proveedor de nube	Todos los proveedores de nube, en las instalaciones, SaaS
Tipos de certificados gestionados	TLS para los recursos de ese proveedor	TLS, firma de código, S/MIME, dispositivo, SSH
Integraciones de CA	Autoridad de certificación propia del proveedor (y socios limitados)	Cualquier CA público, cualquier CA privado, ACME
Renovación automatizada	Sí (dentro de ese proveedor)	Sí (a través de todos los proveedores mediante ACME/API)
Aplicación unificada de las políticas	No (solo por proveedor)	Sí (una única política para todos los entornos)
Registro de auditoría centralizado	No (solo registros por proveedor)	Sí (registro de auditoría único para el cumplimiento normativo)
Visibilidad de la clave privada	Gestionado por el proveedor (no exportable en ACM)	Configurable; opciones compatibles con HSM disponibles
Ideal para	Nube única, cargas de trabajo sencillas	Complejos de infraestructura multi-nube, regulados y a gran escala.

Protección de claves privadas en la gestión de certificados en la nube

La vulneración de la clave privada es un incidente de seguridad más grave que la caducidad de un certificado. Un certificado caducado provoca una interrupción del servicio; una clave privada comprometida puede permitir a un atacante suplantar la identidad de su servicio, descifrar el tráfico histórico o firmar contenido malicioso. Los entornos en la nube generan varios riesgos de exposición de claves privadas que, por lo general, no se presentan en las implementaciones locales.

Los vectores de exposición de claves privadas en la nube más comunes son: claves privadas almacenadas en texto plano en archivos de configuración de aplicaciones o variables de entorno visibles en el control de versiones; claves privadas incluidas en imágenes de contenedores que se envían a registros públicos o compartidos; claves privadas almacenadas en buckets de S3, contenedores de Azure Blob o buckets de GCS con políticas de acceso demasiado permisivas; y claves privadas en secretos de canalizaciones de CI/CD accesibles para todas las canalizaciones en un repositorio sin restricciones de alcance.

La arquitectura correcta para la protección de claves privadas en entornos de nube depende de si la clave privada necesita ser accesible para la aplicación en tiempo de ejecución o no.

Claves gestionadas por el servicio CLM en la nube (no accesibles para la aplicación): Para certificados TLS en balanceadores de carga, puertas de enlace de API y puntos de conexión de CDN, utilice el servicio de gestión de certificados nativo del proveedor de la nube. AWS ACM, la integración de certificados de Azure Key Vault y GCP Certificate Manager almacenan las claves privadas en infraestructura respaldada por HSM y presentan el certificado al servicio sin exponer la clave privada a la aplicación ni a ninguna entidad de IAM. Este es el modelo más seguro y debe utilizarse siempre que la aplicación no necesite acceso directo a la clave.

Claves accesibles para la aplicación en tiempo de ejecución: Para TLS mutuo (mTLS) entre servicios, firma de código o tipos de certificados donde la aplicación deba realizar operaciones criptográficas directamente, almacene la clave privada en un administrador de secretos en la nube (AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager). Rote el secreto con la misma frecuencia que la renovación del certificado. Nunca almacene la clave como un secreto de Kubernetes en YAML sin formato; utilice un operador de secretos externo para inyectarla desde el administrador de secretos al iniciar el pod.

Para los requisitos de protección de claves más exigentes (FIPS 140-2 Nivel 3, FedRAMP Alto o cargas de trabajo clasificadas), utilice un Módulo de Seguridad de Hardware (HSM) dedicado para generar y almacenar claves privadas. Los proveedores de servicios en la nube ofrecen almacenamiento de claves respaldado por HSM a través de AWS CloudHSM, Azure Dedicated HSM y GCP Cloud HSM. Además, el servicio HSM as a Service de Encryption Consulting proporciona una infraestructura HSM dedicada con certificación FIPS 140-2 Nivel 3 que se integra con los flujos de trabajo de gestión de certificados en la nube.

Modelo IAM para la gestión de certificados en la nube

El control de acceso para la gestión de certificados en la nube debe aplicar el principio de mínimo privilegio en tres niveles, separando quién puede emitir certificados, quién puede acceder a las claves privadas y quién puede gestionar la propia plataforma CLM.

Permisos de emisión de certificados: Solo las identidades autorizadas (canalizaciones de implementación de aplicaciones, cuentas de servicio CLM o roles de DevOps aprobados) deberían poder solicitar la emisión de certificados a la CA. En AWS ACM, esto significa que las políticas de IAM otorgan acm:RequestCertificate Solo para roles específicos. En Azure Key Vault, esto significa la asignación del rol de Oficial de certificados de Key Vault a entidades de servicio específicas. Los desarrolladores y los roles de tiempo de ejecución de la aplicación no deben tener permisos para emitir certificados.

Permisos de acceso a la clave privada: El acceso a las claves privadas almacenadas en los administradores de secretos o en Key Vault debe limitarse a la identidad de la aplicación específica que necesita la clave, utilizando permisos a nivel de recurso en lugar de un acceso de lectura amplio al administrador de secretos. En AWS, utilice las políticas de recursos de Secrets Manager para restringir el acceso. secretsmanager:GetSecretValue al rol de IAM específico de la aplicación. En Azure, utilice directivas de acceso de Key Vault o RBAC para otorgar Key Vault Secrets User únicamente a la identidad gestionada específica de la aplicación.

Administración de la plataforma CLM: La capacidad de configurar integraciones con CA, establecer políticas de certificados, aprobar la emisión de certificados confidenciales y acceder al registro de auditoría de CLM debe requerir un rol de administrador de CLM independiente y auditado, distinto de los roles utilizados por las canalizaciones de aplicaciones. Ninguna cuenta de servicio de CI/CD debe tener permisos administrativos de CLM. Se debe exigir la autenticación multifactor (MFA) para todo el acceso administrativo a CLM.

ACME Automation: Cómo funciona la renovación automatizada de certificados en la nube

ACME (Automatic Certificate Management Environment) es un protocolo IETF definido en el RFC 8555 que automatiza la emisión y renovación de certificados. Un cliente ACME demuestra a una CA compatible con ACME que controla un dominio (o, en el caso de certificados IP, una dirección IP) mediante uno de varios tipos de desafío, y luego recibe un certificado firmado sin intervención humana. ACME es el protocolo que utiliza Let's Encrypt para la emisión gratuita de certificados públicos y cuenta con el respaldo de un número creciente de CA empresariales.

En entornos de nube, ACME opera a través de tres tipos de desafíos principales:

• Desafío HTTP-01: El cliente ACME coloca un token en una URL HTTP conocida del dominio que se está validando. La CA obtiene la URL y verifica el token. Esto funciona para puntos finales accesibles desde internet, pero no para servicios internos ni certificados comodín.
• Desafío DNS-01: El cliente ACME crea un registro TXT en la zona DNS del dominio que se está validando. La CA consulta el DNS para verificar el registro. Esto funciona con certificados comodín y con servicios internos donde la validación HTTP no es posible. Los proveedores de DNS en la nube (Route 53, Azure DNS, Cloud DNS) admiten la creación programática de registros DNS, lo que convierte a DNS-01 en el tipo de desafío preferido para la automatización en la nube.
• Desafío TLS-ALPN-01: El cliente ACME responde al protocolo de enlace TLS en el puerto 443 mediante un certificado especial que contiene el token de validación. Esto se utiliza con menos frecuencia en entornos de nube debido a la complejidad del balanceador de carga.

Una implementación de ACME en producción para la gestión de certificados en la nube ejecuta agentes cliente de ACME (como Certbot, acme.sh o el cliente ACME integrado de una plataforma CLM) según un cronograma que renueva los certificados cuando alcanzan aproximadamente 30 días de validez restante. Dado que el cronograma SC-081v3 pasará a certificados de 47 días para marzo de 2029, la renovación a los 30 días restantes significa que los certificados se renuevan cada 17 días, lo que requiere una renovación totalmente automatizada sin ningún paso de aprobación humana en la ruta crítica.

Cuándo utilizar una CA privada en entornos de nube

No todos los certificados en un entorno de nube necesitan ser emitidos por una CA pública. Se requieren certificados de confianza pública para cualquier punto final que reciba conexiones de navegadores o sistemas operativos que confíen en el almacén raíz público. La comunicación interna entre servicios (mTLS de microservicios, servicios internos de Kubernetes, llamadas a la API entre servicios de backend), las herramientas para desarrolladores y la identidad de dispositivos IoT pueden usar certificados de una CA privada, lo que ofrece varias ventajas sobre los certificados de CA pública para estos casos de uso.

Los certificados de CA privados no están sujetos a las restricciones de validez del Foro CA/Navegador que rigen los certificados públicos. Puede emitir certificados internos con periodos de validez que se ajusten a su ciclo de implementación. Las CA privadas le brindan control total sobre el perfil del certificado: puede incluir extensiones personalizadas, nombres alternativos del sujeto para nombres DNS internos y direcciones IP, y valores de uso de clave extendido específicos para su aplicación (como clientAuth para mTLS). La emisión de certificados de CA privados también es más rápida y no requiere validación de dominio con DNS externo.

Las opciones de CA privadas nativas de la nube incluyen AWS Private CA (anteriormente ACM Private CA), que cobra 400 dólares por CA al mes para una CA de propósito general o 50 dólares por CA al mes para una CA de certificados de corta duración, y GCP Certificate Authority Service (CAS), que proporciona una CA privada administrada con almacenamiento de claves de CA respaldado por Cloud HSM. Para las organizaciones que necesitan una CA privada que abarque varios proveedores de nube o se integre con PKI local, PKI como servicio de Encryption Consulting proporciona una CA privada administrada con soporte para ACME, conector AD para entornos Windows e integración con las principales plataformas en la nube.

Registro de auditoría para la gestión de certificados en la nube

Un registro de auditoría completo para la gestión de certificados requiere dos flujos de registros: eventos del ciclo de vida del certificado y eventos de acceso a la clave privada. Los marcos de cumplimiento, incluidos PCI DSS v4.0.1, FedRAMP (controles NIST SP 800-53 AU) y DORA, exigen evidencia documentada de la gobernanza del ciclo de vida del certificado.

Registros del ciclo de vida de los certificados capture cada evento de emisión, renovación, revocación y despliegue. En AWS, los eventos de certificados ACM aparecen en AWS CloudTrail en el acm: Espacio de nombres de eventos. En Azure, las operaciones con certificados de Key Vault se registran en los registros de diagnóstico de Azure Monitor. En GCP, las operaciones de Certificate Manager y CAS aparecen en los registros de auditoría de la nube. Estos registros deben habilitarse explícitamente para las operaciones del plano de datos y enrutarse a un destino de registro a prueba de manipulaciones (un bucket de S3 protegido contra escritura, una cuenta de Azure Storage con inmutabilidad o un bucket de GCS con bloqueo de objetos).

Registros de acceso a claves privadas captura cada instancia de un secreto o clave que está siendo leída por una aplicación o identidad. En AWS Secrets Manager, cada GetSecretValue La llamada se registra en CloudTrail. En Azure Key Vault, cada lectura de secreto se registra en los registros de diagnóstico de Key Vault. En GCP Secret Manager, cada acceso se registra en los registros de auditoría de la nube. Alerta sobre: ​​cualquier acceso a clave desde una identidad que no esté en la lista de roles de aplicación aprobados; cualquier exportación o descarga de clave por una identidad humana; cualquier revocación de un certificado que no se haya renovado; y cualquier vencimiento de certificado dentro de los próximos 30 días sin renovación pendiente.

Arquitectura de gestión de certificados multi-nube

Las organizaciones que ejecutan cargas de trabajo de certificados en AWS, Azure y GCP se enfrentan al mismo problema de coherencia en la gestión de la cadena de bloques (CLM) que se aplica a la gestión de claves: las herramientas nativas de cada proveedor de nube están limitadas a ese proveedor. Tres patrones de arquitectura abordan la gestión de certificados en múltiples nubes:

• Plataforma CLM centralizada con conectores por nube: Implemente una plataforma CLM de terceros que se conecte a los tres proveedores de nube mediante sus respectivas API (ACM, Azure Key Vault y GCP Certificate Manager). La plataforma CLM mantiene un inventario de certificados unificado, aplica políticas de certificados coherentes (longitud mínima de clave, CA permitidas, validez máxima, SAN requeridos) y activa la renovación mediante las API nativas de cada proveedor o mediante ACME. Este es el enfoque recomendado para organizaciones con una presencia significativa en múltiples nubes y requisitos de cumplimiento normativo.
• Autoridad de certificación privada como única raíz de emisión: Implemente una CA privada (nativa de la nube o de terceros) que emita certificados para todos los servicios internos en todos los entornos de nube. Todos los certificados entre servicios se rastrean hasta la misma raíz privada, independientemente de la nube en la que se ejecute el servicio. Los puntos finales de acceso público siguen utilizando certificados de CA pública a través de los servicios CLM nativos de la nube. Esto proporciona coherencia en la emisión de certificados internos sin necesidad de una plataforma CLM completa de terceros.
• ACME con una CA compartida entre proveedores: Configure los clientes ACME en los servicios de todos los proveedores de nube para que renueven sus certificados desde la misma CA compatible con ACME. La CA puede ser pública (para certificados de acceso público) o privada ACME (para certificados internos). La política de certificados se aplica a nivel de la CA y de forma uniforme, independientemente de la nube en la que se ejecute el cliente ACME. Este enfoque ofrece la automatización más sencilla, pero requiere que la CA admita los tipos y perfiles de certificado necesarios en todos los entornos.

Requisitos de cumplimiento para la gestión de certificados en la nube

Actualmente, varios marcos de cumplimiento exigen explícitamente controles de gestión del ciclo de vida de los certificados, y no solo el cifrado durante la transmisión.

PCI DSS v4.0.1 (obligatorio desde el 31 de marzo de 2025): El requisito 4.2.1 exige que todos los certificados utilizados para proteger los datos del Número de Cuenta Principal (PAN) en tránsito se confirmen como válidos, confiables y vigentes. El requisito 12.3.3 exige un inventario documentado de todos los conjuntos de cifrado criptográfico y certificados utilizados en el Entorno de Datos del Titular de la Tarjeta (CDE), revisado al menos una vez cada 12 meses. Este requisito convierte una plataforma de gestión de certificados que genera un informe de inventario en un control de cumplimiento directo, y no solo en una buena práctica.

DORA (Ley de Resiliencia Operativa Digital, aplicable a partir del 17 de enero de 2025): El artículo 9 exige a las entidades financieras de la UE el uso de cifrado robusto y controles criptográficos, y el artículo 10 exige capacidades de detección de incidentes relacionados con las TIC. Las interrupciones por vencimiento de certificados que provocan la indisponibilidad del servicio son incidentes de TIC que deben notificarse según DORA; por lo tanto, los controles de gestión de certificados que previenen dichas interrupciones son un requisito de gestión de riesgos de TIC de DORA.

HIPAA: La salvaguarda técnica 164.312(e)(2)(ii) de la norma de seguridad HIPAA exige el cifrado durante la transmisión de la información médica protegida electrónicamente (ePHI). En entornos de nube, esto implica mantener certificados TLS válidos en todos los puntos finales que transmiten ePHI, con evidencia documentada de los controles de gestión de certificados.

FedRAMP (NIST SP 800-53 Rev. 5): El control IA-3 (Identificación y autenticación de dispositivos) exige que los sistemas en la nube gestionen las credenciales de identidad de los dispositivos, incluidos los certificados utilizados para la autenticación mutua. El control SC-17 (Certificados de infraestructura de clave pública) exige una política de certificados que abarque la emisión, renovación y revocación. FedRAMP High también exige módulos criptográficos validados según FIPS 140-2 o FIPS 140-3 para las operaciones con certificados.

Lista de verificación para la implementación de la gestión de certificados en la nube

1. Ejecutar un escaneo completo de detección de certificados: Utilice su plataforma CLM, herramientas de descubrimiento nativas de la nube o Encryption Consulting. CBOM seguro Para descubrir todos los certificados en todas las cuentas en la nube, regiones y sistemas locales. Es probable que encuentre muchos más certificados de los que muestra su inventario actual.
2. Clasifique los certificados por tipo y titularidad: Para cada certificado detectado, identifique la CA emisora, el tipo de certificado (TLS público, TLS privado, firma de código, S/MIME, dispositivo), el equipo propietario, la ubicación de implementación y el mecanismo de renovación (manual, ACME, renovación automática nativa de la nube).
3. Identifique los certificados sin renovación automática: Cualquier certificado sin un mecanismo de renovación automática supone una futura interrupción del servicio. Priorice la implementación de la renovación automática ACME o nativa de la nube para estos certificados, comenzando por los que caduquen próximamente.
4. Auditoría del almacenamiento de claves privadas: Verifique que las claves privadas de todos los certificados detectados estén almacenadas en ubicaciones aprobadas (HSM en la nube, gestor de secretos, plataforma CLM). Identifique y corrija cualquier clave almacenada en el control de versiones, las imágenes de contenedores o los archivos de configuración de la aplicación.
5. Implemente una política de certificados en su plataforma CLM: Defina los parámetros mínimos aceptables para los certificados: longitud mínima de la clave RSA (mínimo de 2048 bits; 4096 bits para certificados de CA), algoritmos de firma permitidos (SHA-256 o superior), validez máxima (de acuerdo con el cronograma SC-081v3), SAN requeridos (no se permiten certificados comodín cuando sea posible especificar SAN más específicos) y autoridades de certificación emisoras aprobadas.
6. Configurar alertas de caducidad: Configure alertas a 60, 30 y 14 días antes del vencimiento de cualquier certificado sin renovación automática. Envíe las alertas al equipo responsable y al equipo de operaciones de seguridad.
7. Habilitar y enrutar los registros de auditoría: Habilite los registros del ciclo de vida de los certificados y los registros de acceso a las claves privadas en todos los proveedores de nube. Enrute a un destino a prueba de manipulaciones. Configure alertas para los eventos de seguridad clave descritos en la sección de registro de auditoría anterior.
8. Revisar y probar el proceso de renovación trimestralmente: Para cada tipo de certificado con renovación automática, verifique que el proceso de renovación se complete correctamente y que el certificado renovado se implemente correctamente. Pruebe los procedimientos de revocación para al menos un certificado por trimestre para verificar que la infraestructura de revocación funcione correctamente.

Cómo puede ayudar la consultoría de cifrado

Encryption Consulting es una empresa de criptografía aplicada con certificaciones ISO/IEC 27001:2022 y SOC 2. Ayudamos a las organizaciones a diseñar, implementar y auditar programas de gestión de certificados en la nube, desde el descubrimiento inicial hasta la generación continua de evidencia de cumplimiento.

• Administrador de CertSecure: Consultoría de cifrado Administrador de CertSecure CertSecure Manager es una plataforma centralizada de gestión del ciclo de vida de los certificados que ofrece detección automatizada en proveedores de nube y sistemas locales, renovación automatizada basada en ACME, protección de claves privadas, aplicación de políticas de certificados, alertas de caducidad y un registro de auditoría unificado. CertSecure Manager se integra de forma nativa con AWS, Azure y GCP, admite ACME para cualquier CA compatible con ACME e incluye un conector de Active Directory para entornos Windows que utilizan la inscripción automática de Microsoft.
• Infraestructura de clave pública como servicio: Para las organizaciones que necesitan una CA privada administrada para certificados internos en la nube, Encryption Consulting ofrece PKI como servicio Ofrece una CA privada totalmente gestionada con soporte ACME, integración con las principales plataformas en la nube y almacenamiento de claves validado por FIPS. Ideal para certificados de malla de servicios de Kubernetes, mTLS entre microservicios y programas de identificación de dispositivos.
• HSM como servicio: Para escenarios de gestión de certificados que requieren protección de clave privada FIPS 140-2 Nivel 3, Encryption Consulting HSM como servicio Proporciona una infraestructura HSM dedicada que se integra con plataformas CLM y servicios de certificados en la nube, manteniendo las claves privadas de CA y las claves privadas de entidades finales de alto valor en almacenamiento respaldado por hardware.
• CBOM Seguro: Consultoría de cifrado CBOM seguro Realiza un descubrimiento automatizado en entornos de AWS, Azure, GCP y locales para generar una lista de materiales criptográficos (CBOM) en formato CycloneDX. Esto proporciona el inventario de certificados requerido por el requisito 12.3.3 de PCI DSS v4.0.1 y los controles FedRAMP IA-3, e identifica certificados no oficiales y certificados con configuraciones inseguras.
• Aviso de cumplimiento: Mapeamos sus controles de administración de certificados en la nube a los requisitos específicos de PCI DSS v4.0.1, DORA, HIPAA, FedRAMP, NIS2 y otros marcos aplicables, identificamos brechas de control, creamos la hoja de ruta de remediación y generamos el paquete de evidencia de auditoría. Consulte nuestra Servicios de asesoramiento sobre cumplimiento.
• Preparación para PQC: El NIST finalizó los estándares de criptografía post-cuántica FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) en agosto de 2024. El NIST IR 8547 apunta a la desaprobación de RSA y ECC para nuevos usos alrededor de 2030. La transición a algoritmos post-cuánticos requerirá la reemisión de todos los certificados en su entorno de nube. Preparación para PQC El servicio analiza su postura criptográfica y de certificados completa en función del cronograma de migración post-cuántica y diseña la secuencia de migración para los entornos de certificados en la nube.

Para hablar sobre sus necesidades de gestión de certificados en la nube, póngase en contacto con Encryption Consulting.

Conclusión

La gestión de certificados en la nube ha pasado de ser un proceso operativo deseable a un control de seguridad y cumplimiento obligatorio. El calendario del CA/Browser Forum SC-081v3 convierte la renovación automatizada en una necesidad operativa para 2029. PCI DSS v4.0.1 y DORA establecen requisitos de cumplimiento explícitos para el inventario documentado de certificados y la gobernanza del ciclo de vida. Además, la proliferación de certificados nativos de la nube en grupos de escalado automático, contenedores y cargas de trabajo multinube hace que la gestión manual sea operativamente imposible a cualquier escala significativa.

Las organizaciones que logren gestionar esta transición sin interrupciones ni incumplimientos normativos serán aquellas que implementen el descubrimiento continuo de certificados ahora, desplieguen la automatización ACME antes de la fecha límite de validez de 100 días en marzo de 2027, establezcan políticas de protección de claves privadas que se mantengan vigentes tras la migración a certificados de menor duración y creen el registro de auditoría que exigen cada vez más los marcos de cumplimiento normativo. Quienes esperen hasta que los certificados de 47 días sean obligatorios en marzo de 2029 se enfrentarán a una remediación acelerada y de alto riesgo bajo la presión de los plazos.

Preguntas frecuentes

¿Qué es la gestión de certificados basada en la nube?

La gestión de certificados en la nube consiste en descubrir, emitir, renovar, revocar y auditar certificados digitales en infraestructuras de nube, contenedores y entornos híbridos desde una plataforma centralizada. Sustituye el seguimiento manual de certificados por una gestión automatizada del ciclo de vida que evita interrupciones por caducidad de certificados, garantiza la protección de las claves privadas y genera evidencia de auditoría de cumplimiento en entornos multinube.

¿Por qué los entornos en la nube necesitan una gestión de certificados dedicada?

Los entornos en la nube generan certificados a una escala y velocidad que la gestión manual no puede controlar. Los grupos de autoescalado, los contenedores, los microservicios y las puertas de enlace de API requieren certificados válidos, y muchos se aprovisionan sin visibilidad centralizada por parte del departamento de TI. Un solo certificado caducado en un balanceador de carga o puerta de enlace de API en la nube provoca una interrupción total del servicio. La gestión de certificados (CLM) dedicada proporciona detección continua, renovación automatizada y visibilidad centralizada de las fechas de caducidad, las autoridades de certificación emisoras, las principales fortalezas y el estado de cumplimiento en todas las cuentas y regiones de la nube.

¿Cuál es la diferencia entre la gestión de certificados nativa en la nube y una plataforma CLM de terceros?

Los servicios nativos en la nube (AWS Certificate Manager, Azure Key Vault Certificates, GCP Certificate Manager) automatizan la renovación de los recursos dentro del ecosistema de un único proveedor de nube. No ofrecen visibilidad de los certificados en otras nubes, sistemas locales ni tipos de certificados fuera de su ámbito. Una plataforma CLM de terceros proporciona un inventario de certificados unificado y una aplicación de políticas coherente en todos los proveedores de nube, infraestructura local y tipos de certificados, incluidos los de firma de código, S/MIME y certificados de dispositivos.

¿Cómo deben protegerse las claves privadas en un entorno de gestión de certificados en la nube?

Las claves privadas deben almacenarse en almacenes de secretos respaldados por hardware, nunca en archivos de configuración de texto plano, variables de entorno ni sistemas de control de versiones. Para los certificados de balanceadores de carga y puertas de enlace API, utilice el servicio de certificados gestionados del proveedor de la nube, donde la clave nunca se expone. Para los certificados que requieren acceso directo a la clave, almacénela en un gestor de secretos en la nube con rotación automatizada. Para cumplir con los requisitos de FIPS 140-2 Nivel 3, utilice un HSM dedicado a través de servicios HSM en la nube o un proveedor de HSM como servicio de terceros.

¿Qué es ACME y cómo permite la renovación automatizada de certificados en la nube?

ACME (Automatic Certificate Management Environment) es un protocolo IETF (RFC 8555) que automatiza la emisión y renovación de certificados, permitiendo que un cliente demuestre el control del dominio ante una CA y reciba un certificado sin intervención humana. En entornos de nube, los clientes ACME se ejecutan como agentes en instancias de computación o en contenedores, y renuevan los certificados automáticamente antes de su vencimiento. Dado que los certificados TLS tendrán una validez de 47 días a partir de marzo de 2029, según el cronograma SC-081v3 del CA/Browser Forum, la automatización ACME es esencial para cualquier entorno de nube con un número considerable de certificados.

¿Qué marcos de cumplimiento normativo requieren controles de gestión de certificados en entornos de nube?

PCI DSS v4.0.1 (obligatorio desde el 31 de marzo de 2025) requiere un inventario de certificados documentado y certificados válidos para los datos de los titulares de tarjetas en tránsito. DORA (aplicable en enero de 2025) requiere controles de gestión de riesgos de TIC que abarquen la gobernanza del ciclo de vida de los certificados criptográficos. HIPAA requiere certificados TLS válidos en todos los puntos finales que transmitan información de salud protegida. FedRAMP (NIST SP 800-53 Rev. 5) requiere una política de certificados que abarque la emisión, renovación y revocación. GDPR requiere medidas técnicas apropiadas para los datos en tránsito, incluida la higiene de certificados.