El protocoloSSL / TLS trata de la seguridad y la autenticación. Permite cifrar las comunicaciones de datos a través de redes abiertas, protegiéndolas contra la manipulación y la interceptación por agentes malintencionados. Además, el uso de certificados SSL autentica a las partes comunicantes, creando un entorno de confianza. La seguridad y la autenticación son los pilares del éxito de las empresas en el mundo digital.
Para establecer el nivel de confianza requerido y eliminar el uso de certificados falsos que se hacen pasar por empresas legítimas, los certificados de SSL deben estar firmados y validados por una Autoridad de Certificación (CA) de confianza. Las CA emiten certificados raíz de confianza que se incluyen en almacenes de confianza. Los certificados digitales firmados con la clave privada raíz son de confianza para todos los dispositivos y aplicaciones cuyo almacén de confianza incluya los certificados raíz. De este modo, se crea una cadena de confianza que se utiliza para autenticar organizaciones.
Hoy en día, los certificados digitales se utilizan para proteger miles de conexiones entre máquinas, dispositivos y aplicaciones. Tradicionalmente, las organizaciones utilizan certificados SSL/TLS firmados por autoridades de certificación (CA) públicas de confianza. Con la proliferación de tecnologías e iniciativas como la nube, la contenedorización, IoT y los dispositivos móviles, y la consiguiente explosión en el número de certificados digitales, muchos también han desplegado CA internas y privadas para asegurar estos despliegues.
Veamos algunas de las principales diferencias:
Certificados de confianza pública
Los certificados de confianza pública SSL/TLS se utilizan para servidores y aplicaciones web de cara al público. Un certificado de confianza pública sólo puede ser emitido por una CA externa de confianza (por ejemplo, Entrust, DigiCert, etc.) que verifique al propietario del dominio.
Certificados privados de confianza
Los certificados de confianza privada SSL/TLS se utilizan para autenticar usuarios y dispositivos en la red interna. Un certificado de confianza privada puede ser emitido por una CA pública o, más a menudo, por cualquier organización que gestione su propia infraestructura interna de clave pública (por ejemplo, Microsoft CA).
¿Qué es un certificado autofirmado?
Otra estrategia consiste en emitir certificados autofirmados en SSL . Un certificado autofirmado es aquel que no está firmado por ninguna CA, ni privada ni pública. En este caso, el certificado se firma con su propia clave privada, en lugar de solicitarlo a una CA pública o privada.
Los certificados autofirmados ofrecen algunas ventajas cuando se utilizan en redes internas y en las fases de desarrollo de software , sin embargo, también pueden crear varios riesgos sin la visibilidad y el control adecuados.
El mayor reto de los certificados autofirmados es que los equipos de seguridad a menudo carecen de visibilidad sobre cuántos tienen, dónde están instalados, quién es su propietario y cómo se almacena la clave privada. Ya es bastante difícil hacer un seguimiento de los certificados emitidos por distintas CA públicas y privadas. Es prácticamente imposible hacer un seguimiento de los certificados autofirmados emitidos sin ningún proceso formal de solicitud o aprobación.
Si la red corporativa es violada, no hay forma de saber si un certificado autofirmado (y su clave privada) ha sido comprometido. Los certificados autofirmados comprometidos pueden plantear muchos problemas de seguridad, ya que los atacantes pueden suplantar la identidad de la víctima. A diferencia de los certificados emitidos por una CA, los certificados autofirmados no pueden revocarse. La incapacidad de encontrar y revocar rápidamente la clave privada asociada a un certificado autofirmado crea un grave riesgo.
Los riesgos de los certificados autofirmados y las CA en DevOps
Estos riesgos se ven acelerados por el número de CA integradas y autofirmadas en las herramientas DevOps y los servicios en la nube, así como por los certificados autofirmados emitidos por los desarrolladores.
DevOps se basa en la velocidad y la agilidad. Aunque los certificados autofirmados permiten a los desarrolladores obtener certificados de forma rápida y sencilla, a menudo eluden las políticas que ha establecido para mantener la seguridad de su red. Tanto si los desarrolladores crean un certificado autofirmado como si crean una CA autofirmada, estos métodos crean una falsa sensación de confianza en su proceso de desarrollo y entrega.
Entonces, ¿por qué iban a utilizar los desarrolladores certificados autofirmados? La mejor pregunta es por qué no lo harían. El proceso manual habitual de enviar una solicitud de firma de certificado (CSR) y esperar horas para su verificación y firma no es intuitivo. Para ahorrar tiempo y frustración, tiene sentido que los desarrolladores opten por certificados autofirmados o CA integradas como HashiCorp Vault, Istio y Kubernetes.
En su informe "Managing Machine Identities, Secrets, Keys and Certificates", Gartner recomienda "Que los gestores de secretos se integren con emisores que cumplan las políticas (CA públicas o privadas)" y "Que los sistemas de gestión de certificados supervisen la emisión del gestor de secretos para ayudar a auditar y gestionar el ciclo de vida de los certificados emitidos".
La simple creación de una CA autofirmada y la emisión de grandes volúmenes de certificados sin adherirse a las prácticas PKI y las políticas de certificación adecuadas no es una opción viable.
A pesar de la evidente ventaja de acelerar el proceso de desarrollo, esta práctica presenta varias implicaciones para la seguridad, ya que a menudo se piensa en ella a posteriori. Los certificados autofirmados no fiables y sin seguimiento pueden utilizarse en ataques a la cadena de suministro de software y permitir a los malos actores descargar código malicioso.
Las organizaciones deben asegurarse de que todos sus certificados se emiten desde una raíz de confianza segura, cumplen las políticas y buenas prácticas, y se gestionan a lo largo de su ciclo de vida.
La alternativa: Pasar del autofirmado al autoservicio
La solución para superar este reto requiere un cambio fundamental en la forma en que colaboran los equipos de seguridad y desarrollo. En última instancia, es necesario permitir a los desarrolladores un acceso rápido y sencillo a los certificados desde sus flujos de trabajo, sin sacrificar la confianza y las políticas.
En Keyfactor, trabajamos con equipos DevOps para hacer el cambio de certificados autofirmados a certificados como servicio. Esto significa que los desarrolladores pueden obtener certificados mediante procesos automatizados y API integradas directamente con herramientas nativas de la nube como Jenkins, Ansible, Kubernetes, HashiCorp Vault, Istio y otras. Mientras tanto, cada certificado se emite desde una PKI as-a-Service de confianza empresarial y la seguridad mantiene una visibilidad y un control totales sobre cada certificado emitido.
Habilitación de PKI como servicio en DevOps
PKI como servicio (PKIaaS) es la combinación perfecta de confianza y facilidad de uso. Los certificados se emiten desde una PKI privada y de confianza, y los equipos de DevOps pueden solicitar y emitir certificados fácilmente mediante procesos de autoservicio, lo que reduce la necesidad de certificados autofirmados.
Para obtener más información sobre cómo puede eliminar la necesidad de certificados autofirmados y adoptar la automatización de autoservicio, solicite hoy mismo una demostración de Keyfactor .
