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
Cada organización tiene certificados que no conoce. Estos certificados ocultos crean puntos ciegos que socavan la seguridad, el cumplimiento y la fiabilidad operativa. Obtener una visibilidad completa es el primer paso para recuperar el control.
Un certificado sombra es cualquier certificado digital que existe en su entorno pero no es rastreado, gestionado o incluso conocido por los equipos responsables de la seguridad y la infraestructura. Es el equivalente de certificado de shadow IT: algo implementado fuera de los límites de los procesos oficiales y la supervisión.
Los certificados sombra no son inherentemente maliciosos. En la mayoría de los casos, son creados por desarrolladores bien intencionados, ingenieros de la nube o unidades de negocio que necesitan un certificado rápidamente y lo obtienen sin pasar por el proceso formal de solicitud de la organización. El problema no es la intención; es invisibilidad. Cuando un certificado es invisible para sus equipos de seguridad y operaciones, no puede ser monitoreado para su expiración, validado contra la política, o rotado cuando se descubre una vulnerabilidad.
Las investigaciones demuestran consistentemente que las organizaciones subestiman su número de certificados entre un 40% y un 70%. Esa brecha, la diferencia entre los certificados que conoces y los que realmente existen, es tu brecha de visibilidad. Cerrarla es una de las acciones más impactantes que puede realizar un equipo de seguridad, porque no puedes proteger, renovar o gestionar lo que no puedes ver.
Los certificados sombra no aparecen de la noche a la mañana por una única causa. Se acumulan con el tiempo a través de múltiples canales, cada uno perfectamente racional en aislamiento, pero colectivamente crean una expansión que es difícil de gestionar.
Los desarrolladores provisionan certificados con frecuencia por su cuenta usando herramientas como Let's Encrypt, certbot, o paneles de proveedores de la nube. Necesitan HTTPS para un entorno de pruebas, una API de prueba o un punto final de microservicio, y obtienen un certificado en minutos sin abrir un ticket. Estos certificados funcionan perfectamente pero permanecen invisibles para la gestión centralizada.
Las plataformas en la nube como AWS, Azure y GCP pueden aprovisionar y adjuntar automáticamente certificados a balanceadores de carga, CDNs y puertas de enlace API. Cuando la infraestructura se despliega mediante Terraform, Pulumi u otras herramientas IaC, los certificados a menudo se crean como efectos secundarios del aprovisionamiento de recursos. A menos que el equipo de CLM supervise las APIs de los proveedores de la nube, estos certificados permanecen desconocidos.
Muchos productos SaaS permiten a los clientes configurar dominios personalizados con certificados TLS. Los equipos de marketing crean páginas de destino con marca, los equipos de soporte despliegan dominios personalizados para el centro de ayuda, y los equipos de socios crean portales co‑marcados. Cada uno de estos puede involucrar un certificado que el equipo de seguridad nunca ha visto.
Cuando las organizaciones adquieren otra empresa, heredan todo su conjunto de certificados. La empresa adquirida puede haber utilizado diferentes autoridades de certificación (CAs), diferentes convenciones de nomenclatura y diferentes (o ninguna) prácticas de gestión del ciclo de vida. Integrar estos certificados en un inventario unificado es una tarea importante que a menudo lleva meses o años, dejando una gran zona ciega mientras tanto.
Los certificados sombra no son solo una molestia organizacional. Introducen un riesgo real y medible en tres dimensiones críticas.
Un certificado del que no sabes es un certificado que no puedes asegurar. Los certificados sombra pueden usar algoritmos de clave débiles, ser emitidos por autoridades de certificación no confiables o comprometidas, o tener alcances de comodín excesivamente amplios. Si una clave privada asociada a un certificado sombra se ve comprometida, el equipo de seguridad no puede responder porque ni siquiera saben que el certificado existe. Los atacantes buscan activamente estos puntos finales no monitorizados.
Regulaciones como NIS2, DORA, PCI DSS y marcos industriales como ISO 27001 requieren que las organizaciones mantengan un inventario de activos criptográficos y demuestren que los certificados cumplen con las políticas definidas. Los certificados sombra quedan fuera de este inventario por definición. Durante una auditoría, la imposibilidad de contabilizar todos los certificados en su entorno es un hallazgo que puede conducir a sanciones, mandatos de remediación o pérdida de la certificación.
Esta es la consecuencia más común y más visible. Un certificado sombra expira, y el servicio que protege se cae. Porque nadie estaba monitoreando el certificado, no se activó ninguna renovación. El resultado interrupción puede tardar horas en diagnosticar, precisamente porque el certificado era desconocido en primer lugar. Los equipos pierden tiempo solucionando problemas de código de aplicación o infraestructura de red antes de descubrir que la causa raíz es un certificado expirado que nadie sabía que existía.
Antes de poder cerrar la brecha, necesitas medirla. La brecha de visibilidad es la diferencia entre los certificados que tu organización conoce (aquellos en hojas de cálculo, CMDB o una plataforma CLM) y los certificados que realmente existen en toda tu infraestructura.
Utilice herramientas de escaneo de red para sondear sus rangos de IP y descubrir todos los puntos finales TLS. Compare lo que encuentre con su inventario existente. La diferencia es su brecha de visibilidad. La mayoría de las organizaciones se sorprenden de lo grande que es.
Certificate Transparency (CT) los registros son públicos, registros de solo anexado de cada certificado emitido por las CA participantes. Consultar los registros CT para sus dominios revela certificados que quizás no conocía, incluidos los emitidos por CA que no autorizó.
Examinar inventarios de certificados en AWS Certificate Manager, Azure Key Vault, GCP Certificate Manager y cualquier otro servicio en la nube que utilicen sus equipos. Cruzar esta información con su inventario central para encontrar certificados que se hayan provisionado fuera de los canales habituales.
A veces el método de descubrimiento más eficaz es simplemente preguntar. Los equipos de desarrollo y DevOps a menudo saben exactamente qué certificados han provisionado de forma informal. Un breve cuestionario o entrevista puede revelar docenas de certificados previamente desconocidos.
Eliminar los certificados sombra por completo es poco realista. El objetivo es crear sistemas y procesos que hagan visibles los certificados sombra tan pronto como aparezcan y los incorporen a flujos de trabajo de ciclo de vida gestionados. Aquí están las estrategias clave.
Un escaneo único no es suficiente. Despliegue descubrimiento continuo que escanea automáticamente sus redes, entornos en la nube y puntos finales en un horario regular. Los nuevos certificados deben detectarse dentro de horas o días de su emisión, no meses después cuando expiran y causan una interrupción.
Definir claramente políticas de certificado que especifican algoritmos de clave aprobados, tamaños de clave mínimos, períodos de validez máximos y convenciones de nomenclatura requeridas. Luego, haga cumplir estas políticas automáticamente. Cuando se descubra un certificado que viole la política, el sistema debe marcarlo y notificar al equipo responsable.
Mantenga una lista de Autoridades de Certificación aprobadas y facilite a los equipos la solicitud de certificados a ellas. Si obtener un certificado de una AC aprobada es tan rápido y conveniente como usar una fuente no aprobada, los equipos naturalmente se inclinarán hacia la ruta aprobada. Combine esto con la monitorización de registros CT para detectar certificados emitidos por AC fuera de su lista aprobada.
Los certificados sombra aparecen con frecuencia porque los desarrolladores no se dan cuenta de que existe un proceso adecuado, o consideran que el proceso actual es demasiado lento. Aborde ambos lados: eduque a los equipos sobre los riesgos de los certificados no gestionados y agilice el proceso oficial de solicitud para que tome minutos, no días. Los portales de autoservicio con flujos de trabajo de aprobación automatizados son muy eficaces para reducir la creación de certificados sombra.
Descubrimiento continuo de múltiples fuentes: Evertrust CLM descubre certificados en sus redes, proveedores de nube, puntos finales y registros CT. Los escaneos se ejecutan de forma continua, de modo que los nuevos certificados se detectan en horas, no en meses.
Inventario unificado: Cada certificado descubierto se agrega automáticamente a un inventario centralizado con metadatos completos, atribución de propiedad y seguimiento de vencimiento. No más hojas de cálculo, no más sorpresas.
Alertas de violación de política: Defina sus políticas organizacionales una vez, y Evertrust marca automáticamente cualquier certificado (nuevo o existente) que las viole. Claves débiles, CAs no autorizados y configuraciones no conformes se muestran inmediatamente.
Autoservicio con salvaguardas: Proporcione a los desarrolladores una ruta rápida y aprobada para obtener certificados a través de portales de autoservicio respaldados por Evertrust PKI. Las solicitudes se cumplen en segundos con aplicación de políticas incorporada, eliminando el incentivo de salir de los canales oficiales.
