Certificados TLS de servidor
Tráfico web seguro a gran escala
Inventario de certificados
Descubrir y rastrear todos los certificados
Certificados DevOps
Automatizar para pipelines CI/CD
Cifrado de correo electrónico
S/MIME para correo electrónico empresarial
A medida que aumentan los volúmenes de certificados, la gestión ad hoc se descompone. Un marco de gobernanza sólido, basado en políticas claras, roles definidos y aplicación automatizada, es la diferencia entre una PKI segura y una responsabilidad descontrolada.
Cuando una organización gestiona un puñado de certificados, la gobernanza es simple. Alguien solicita un certificado, otra persona lo aprueba, y una hoja de cálculo lleva el registro de las fechas de vencimiento. Pero las empresas modernas no gestionan un puñado; gestionan decenas de miles, a veces cientos de miles, a través de múltiples Autoridades de Certificación, proveedores de nube y unidades de negocio.
A esa escala, la ausencia de política no es libertad; es caos. Los equipos eligen diferentes algoritmos de clave, los certificados se emiten con convenciones de nomenclatura inconsistentes, los períodos de validez varían enormemente, y nadie puede decir con certeza qué CAs están realmente en uso. El resultado es un entorno que es difícil de auditar, costoso de mantener y vulnerable tanto a interrupciones como a brechas de seguridad.
Política de certificados y gobernanza resuelven esto estableciendo un conjunto claro de reglas que definen quién puede solicitar certificados, qué tipos de certificados están permitidos, cómo deben configurarse, y cómo se verifica el cumplimiento. Este capítulo explica cómo construir y aplicar ese marco.
Dos documentos fundamentales definen cómo funciona una PKI. Aunque a menudo se confunden, sirven a propósitos distintos y son ambos esenciales para un entorno bien gobernado.
El CP es un documento de alto nivel que establece qué la organización requiere. Define las reglas, obligaciones y expectativas para el uso de certificados: qué tipos de certificados están permitidos, qué niveles de garantía se requieren y bajo qué condiciones los certificados pueden ser emitidos o revocados. Piense como la "constitución" de su PKI.
El CPS describe cómo la CA implementa los requisitos establecidos en el CP. Cubre los procedimientos operativos, los controles técnicos y las medidas de seguridad física en vigor. Si el CP dice "los certificados deben usar RSA 2048 o superior," el CPS explica exactamente cómo la CA hace cumplir ese requisito en su proceso de emisión.
El marco estándar para redactar documentos CP y CPS está definido en el RFC 3647. Proporciona una estructura común con nueve secciones que cubren todo, desde obligaciones y responsabilidad hasta controles de seguridad técnicos, facilitando la comparación de políticas entre organizaciones y autoridades de certificación.
Sin un CP, no hay reglas acordadas. Sin un CPS, las reglas existen solo en papel. Juntos, crean una cadena de gobernanza completa: el CP establece el estándar, y el CPS demuestra que se está cumpliendo el estándar. Los auditores y reguladores esperan que ambos estén actualizados y alineados.
Cada política de certificados debe abordar un conjunto de decisiones clave. Estas elecciones moldean la postura de seguridad de toda la organización y determinan cuán fácil (o difícil) será gestionar los certificados a lo largo del tiempo.
¿Qué CAs están autorizados para emitir certificados para su organización? Esto incluye tanto CAs públicas (para TLS de cara externa) y CAs internas (para mTLS, identidad de dispositivos, y firma de código). Una lista de CAs aprobadas evita que los equipos adquieran certificados de proveedores no confiables o no evaluados, reduciendo el riesgo de certificados sombra.
Defina los tipos y tamaños de clave mínimos aceptables. La mayoría de las organizaciones hoy requieren RSA 2048 (o superior) y están migrando hacia ECDSA P-256 o P-384 para un mejor rendimiento y mayor seguridad. Su política también debe abordar la preparación postcuántica y establecer un cronograma para la transición de algoritmos.
¿Cuánto tiempo deben permanecer válidos los certificados? Los certificados TLS públicos ya están limitados a 398 días por el foro CA/Browser y pronto pasarán a 90 días (y eventualmente a 47 días). Los certificados internos pueden tener requisitos diferentes. Su política debe definir la validez máxima para cada tipo de certificado y caso de uso.
Los nombres distinguidos de sujeto (DN) y los nombres alternativos de sujeto (SAN) estandarizados facilitan la identificación, búsqueda y gestión de los certificados. Una buena política de nomenclatura especifica los campos obligatorios (Organización, Unidad organizativa, País), prohíbe los certificados comodín donde no son necesarios y define patrones SAN para diferentes entornos.
Redactar una política es solo el comienzo. El verdadero desafío es asegurarse de que cada certificado emitido en toda la organización cumpla realmente con esa política. Existen dos enfoques fundamentales, y la mayoría de las organizaciones maduras utilizan una combinación de ambos.
Depende de revisores humanos para comprobar las solicitudes de certificados contra la política antes de aprobar la emisión. Esto funciona a pequeña escala, pero se convierte en un cuello de botella a medida que aumentan los volúmenes de certificados. Las revisiones manuales también son propensas a la inconsistencia: diferentes revisores pueden interpretar la misma política de manera distinta.
Utiliza plataformas CLM para validar cada solicitud de certificado contra las reglas de la política antes de que se emita el certificado. Las solicitudes no conformes se rechazan o marcan automáticamente. Este enfoque escala a cualquier volumen y garantiza un 100% de consistencia.
La aplicación más eficaz ocurre antes de que se cree el certificado. La emisión basada en plantillas (donde los solicitantes eligen entre perfiles de certificado preaprobados) elimina categorías enteras de violaciones de políticas por diseño, en lugar de detectarlas después.
Incluso con controles de preemisión sólidos, las organizaciones necesitan monitoreo continuo para detectar certificados emitidos fuera de la canalización gestionada. Escanear redes, entornos en la nube y los registros de Transparencia de Certificados revela certificados no conformes o desconocidos que requieren remediación.
La gobernanza requiere más que reglas sobre configuraciones de certificados. También exige una responsabilidad clara: quién puede hacer qué, y quién debe aprobar operaciones sensibles.
Defina roles distintos para sus operaciones de certificados. Los roles comunes incluyen Solicitante (puede enviar solicitudes de certificados), Aprobador (puede aprobar o rechazar solicitudes), Administrador (puede gestionar configuraciones y plantillas de la CA), y Auditor (acceso solo de lectura a registros e informes). La separación de funciones es esencial: la persona que solicita un certificado no debe ser la misma que lo aprueba.
No todas las solicitudes de certificado requieren el mismo nivel de escrutinio. Un certificado interno de bajo riesgo para un entorno de desarrollo podría ser aprobado automáticamente si coincide con una plantilla preaprobada. Un certificado comodín o un certificado para una pasarela de pago de producción debería requerir la aprobación explícita de un miembro del equipo de seguridad. Los flujos de trabajo de aprobación escalonada equilibran la velocidad con el control.
Cada certificado debe tener un propietario claro: un equipo o individuo responsable de su renovación, configuración y desmantelamiento. Sin un mapeo de propiedad, los certificados quedan huérfanos con el tiempo, y cuando expiran, nadie sabe a quién contactar. Un marco de gobernanza debe hacer que la asignación de propiedad sea obligatoria en el momento de la emisión.
La gobernanza no está completa hasta que puedas demostrarlo. Los marcos regulatorios como ISO 27001, eIDAS, y NIS2 exigen a las organizaciones demostrar que sus activos criptográficos se gestionan de acuerdo con políticas documentadas. Los auditores quieren evidencia, no promesas.
La auditoría eficaz y la generación de informes de cumplimiento para certificados requiere varias capacidades. Primero, una inventario completo de todos los certificados en toda la organización, incluidos los emitidos por CAs externos. Segundo, paneles de cumplimiento de políticas que muestran, de un vistazo, qué certificados cumplen con la política y cuáles la violan (algoritmo incorrecto, expirado, CA desconocida, falta de titularidad). Tercero, registros de auditoría inmutables que registran cada acción: quién solicitó un certificado, quién lo aprobó, cuándo se emitió y cuándo se renovó o revocó.
Organizaciones que invierten en gobernanza PKI preparada para el cumplimiento encuentran que las auditorías se vuelven más rápidas y menos estresantes. En lugar de apresurarse a recopilar evidencia manualmente, exportan informes directamente desde su plataforma CLM. La política está documentada, la aplicación está automatizada y cada acción se registra.
Definir y aplicar políticas de forma centralizada: Evertrust CLM le permite definir políticas de certificados (CAs aprobados, algoritmos de clave, límites de validez, reglas de nomenclatura) y aplicarlas automáticamente en cada solicitud de certificado, sin importar la CA emisora.
Control de acceso basado en roles: RBAC incorporado con flujos de trabajo de aprobación configurables garantiza que las personas correctas aprueben los certificados correctos. La separación de funciones es aplicada por la plataforma, no por convención.
Informes listos para auditoría: Cada acción de certificado se registra en una cadena de auditoría inmutable. Los paneles de cumplimiento resaltan violaciones de políticas en tiempo real, y los informes exportables facilitan las auditorías.
Emisión basada en plantillas: Evertrust PKI proporciona plantillas de certificado preconfiguradas que incorporan los requisitos de política directamente en el proceso de emisión. Los solicitantes seleccionan una plantilla; la plataforma gestiona el cumplimiento.
