Los protocolos SSL/TLS son un imperativo empresarial para proteger las conexiones entre aplicaciones, dispositivos y máquinas accesibles a través de Internet. Estos protocolos requieren certificados para proteger los datos mediante el cifrado y la autenticación para mitigar posibles manipulaciones y exploits maliciosos. Los certificados más seguros son emitidos y validados por autoridades certificadoras (CA) de confianza, lo que garantiza una cadena de confianza crucial para la autenticación.
En este blog analizamos el riesgo de los certificados autofirmados y por qué no deberías utilizarlos para proteger tu canal de DevOps.
¿Qué son los certificados autofirmados?
-
Los certificados de confianza pública, utilizados para aplicaciones y servidores web de cara al público, deben ser emitidos por una CA externa de confianza que verifique de forma segura al propietario del dominio. Algunas organizaciones gestionan su propia PKI interna y emiten sus propios certificados SSL/TLS de confianza privada para sus redes internas con el fin de autenticar dispositivos y usuarios.
-
Los certificados autofirmados no están firmados ni por una autoridad certificadora pública ni por una privada, ya que la información contenida en los certificados autofirmados no ha sido verificada ni autenticada por una autoridad certificadora de confianza, por lo que pueden activar alertas de seguridad. Esto plantea un problema importante cuando los navegadores web y los sistemas operativos marcan los certificados no firmados por una CA de confianza pública debido a los riesgos de seguridad para los usuarios. Sin autenticación a través de una CA, los usuarios no pueden determinar si el certificado es de confianza o ha sido generado por agentes maliciosos.
¿Por qué los certificados autofirmados son una opción atractiva para los desarrolladores?
Los desarrolladores utilizan certificados autofirmados en redes internas de bajo riesgo y en fases de desarrollo y prueba de software.
- Los certificados autofirmados ofrecen rapidez y agilidad en todas las fases del ciclo de desarrollo
- La generación de certificados autofirmados elimina los largos periodos de espera de los procesos de verificación y firma que causan pérdidas de tiempo, frustración e interrupciones
- Los certificados autofirmados no están sujetos a normativas sobre periodos de validez. En cambio, los certificados SSL/TLS de confianza pública están limitados actualmente a un periodo de validez de 13 meses.
Si los desarrolladores utilizan certificados autofirmados, deben establecerse políticas sólidas de protección y seguridad de acceso. Es esencial contar con un equipo establecido encargado de la gestión de certificados que disponga de herramientas de supervisión eficaces para realizar un seguimiento de todos los certificados y su autenticidad. Desafortunadamente, los problemas de seguridad no siempre se tienen en cuenta. Del mismo modo que la TI en la sombra provoca complejidad y riesgos innecesarios, los certificados autofirmados pueden dar lugar a importantes factores de riesgo.
¿Por qué los desarrolladores deben resistirse al uso de certificados autofirmados?
El argumento más importante en contra de los certificados autofirmados es simplemente que no son de confianza. Fuera de las redes internas, los certificados SSL/TLS deben estar firmados por una CA de confianza para obtener ese importante nivel de confianza del usuario. La validación por parte de una CA pública de confianza es crucial para eliminar el peligro de los certificados falsos no rastreables, la suplantación de identidad y la entrega de código malicioso.
Factores de riesgo en torno al uso de certificados autofirmados
1. Ausencia de proceso de revocación - No existe una autoridad de notificación para revocar los certificados caducados o comprometidos, lo que deja puertas de entrada potenciales para la explotación maliciosa y las brechas.
2. Falta de visibilidad, conocimiento del inventario y control - A los equipos de seguridad les resulta difícil saber cuántos certificados, la ubicación de la instalación, la propiedad y los detalles de almacenamiento de claves privadas o cuándo se ve comprometido un certificado.
3. Falta de soporte técnico - Los certificados generados internamente carecen de la amplitud de conocimientos, herramientas de gestión y mecanismos de revocación que ofrecen las autoridades de certificación públicas.
4. Deficiente cumplimiento y alineación con los estándares de seguridad - A menudo hay un conocimiento deficiente de las normativas y de la aplicación de las mejores prácticas para cumplir los estándares de cumplimiento.
¿Por qué la PKI alojada en DevOps es una alternativa segura y ventajosa?
La infraestructura de clave pública, o PKI, es el ecosistema tecnológico de políticas, procedimientos, hardware y software que permite los procesos de emisión, gestión, almacenamiento y revocación de certificados digitales. La PKI permite la creación de certificados digitales que autentican la identidad de dispositivos, usuarios y servicios mediante cifrado de datos, firmas digitales y emisión de autenticación de certificados a través de autoridades certificadoras de confianza.
Para los desarrolladores, PKI-as-a-Service (PKIaaS) es una gran alternativa a los certificados autofirmados por su facilidad de uso, escalabilidad, eficiencia y confianza.
Ventajas de la PKI alojada para DevOps
Una PKIaaS alojada proporciona numerosas ventajas, entre las que se incluyen:
- Visibilidad total, control de gestión y conocimiento de cada certificado emitido
- Elimina los riesgos de vulnerabilidad derivados de certificados falsos no fiables e imposibles de rastrear y de la suplantación de certificados.
- Emisión más rápida de certificados
- Permite una automatización DevSecOps más segura
- Reduce el costo de propiedad de SSL/TLS
- Automatiza la implementación de certificados
- Incluye una raíz de confianza pública compatible con todos los sistemas operativos y navegadores.
- Entrega libertad la gestión interna de certificados
- Ahorra tiempo y costos de gestión de software, mantenimiento, formación de empleados, supervisión y comprobaciones de estado.
El servicio PKI de GlobalSign para DevOps puede ayudar a superar los retos de los certificados
GlobalSign puede superar los retos de certificados de DevOps con nuestros servicios de CA alojados, fiables y de confianza. Asociarse con GlobalSign significa que los desarrolladores tienen una única fuente a la que recurrir para todas sus necesidades de certificados, lo que les permite centrarse en sus competencias principales. Nuestra experiencia en PKI garantiza el cumplimiento de las mejores prácticas y los requisitos de auditoría, a la vez que ofrece una asistencia de primera clase y acuerdos de nivel de servicio (SLA).
Los servicios de certificados PKI de GlobalSign se ofrecen a una velocidad DevOps rentable, al tiempo que garantizan que los certificados y los componentes PKI están actualizados con las mejores prácticas y normativas.
Características del PKI alojado de GlobalSign
- Servicios de revocación alojados compatibles con RFC 5280 (CRL u OCSP), almacenamiento seguro de claves sin conexión, y alojamiento y gestión de raíces de cliente dedicadas o compartidas, públicas o privadas.
- Se ofrece a través de las API de GlobalSign o la integración ACME.
- Integración directa con Venafi as a Service y HashiCorp Vault disponible
- Kubernetes Certmanager se conecta a través de Atlas
- Herramienta CLI para la emisión, renovación y revocación de certificados con HVClient
- Cubre las necesidades de certificados en toda la pila de aplicaciones
Más información sobre los servicios PKI alojados de GlobalSign para DevOps
