El protocolo SSL/TLS se centra en la seguridad y la autenticación. Permite el cifrado de las comunicaciones de datos a través de redes abiertas, protegiendo contra la manipulación y la interceptación por parte de actores maliciosos. Además, el uso de certificados SSL autentica a las partes que se comunican, creando un entorno de confianza. La seguridad y la autenticación son los pilares de las empresas exitosas en el mundo digital.
Para establecer el nivel de confianza requerido y eliminar el uso de certificados fraudulentos que suplantan a empresas legítimas, los certificados SSL deben ser firmados y validados por una Autoridad de Certificación (CA) de confianza. Las CA emiten certificados raíz de confianza que se incluyen en los almacenes de confianza. Los certificados digitales que se firman con la clave privada raíz son de confianza para todos los dispositivos y aplicaciones cuyo almacén de confianza incluye los certificados raíz. Así, se crea una cadena de confianza que se utiliza para autenticar organizaciones.
Hoy en día, los certificados digitales se utilizan para asegurar 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 contenerización, el IoT y los dispositivos móviles, y la posterior explosión en el número de certificados digitales, muchas también han implementado CA internas y privadas para asegurar estas implementaciones.
Analicemos algunas de las diferencias clave:
Certificados de confianza pública
Los certificados SSL/TLS de confianza pública se utilizan para servidores web y aplicaciones de cara al público. Un certificado de confianza pública solo puede ser emitido por una CA externa de terceros de confianza (por ejemplo, Entrust, DigiCert, etc.) que verifica al propietario del dominio.
Certificados de confianza privada
Los certificados SSL/TLS de confianza privada 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 ejecute su propia infraestructura de clave pública interna dedicada (por ejemplo, Microsoft CA).
¿Qué es un certificado autofirmado?
Otra estrategia es emitir certificados SSL autofirmados. 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 fases de desarrollo de Software; sin embargo, también pueden generar varios riesgos sin la visibilidad y el control adecuados.
El mayor desafío con 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 los posee y cómo se almacena la clave privada. Ya es bastante difícil hacer un seguimiento de los certificados emitidos por varias CA públicas y privadas diferentes. 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 vulnerada, no hay forma de saber si un certificado autofirmado (y su clave privada) ha sido comprometido. Los certificados autofirmados comprometidos pueden plantear numerosos desafíos 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 ser revocados. La imposibilidad de encontrar y revocar rápidamente la clave privada asociada a un certificado autofirmado genera un riesgo grave.
Los riesgos de los certificados autofirmados y las CA en DevOps
Estos riesgos se ven acelerados por el número de CA autofirmadas integradas en las herramientas de DevOps y los servicios en la nube, así como por los certificados autofirmados emitidos por los desarrolladores.
DevOps se centra en la velocidad y la agilidad. Si bien los certificados autofirmados permiten a los desarrolladores obtener certificados de forma rápida y sencilla, a menudo eluden las políticas establecidas para mantener la seguridad de la red. Ya sea que los desarrolladores creen un certificado autofirmado o implementen una CA autofirmada, estos métodos generan una falsa sensación de confianza en el proceso de desarrollo y entrega.
Entonces, ¿por qué los desarrolladores usarían certificados autofirmados? La pregunta más acertada es, ¿por qué no lo harían? El proceso manual habitual de enviar una solicitud de firma de certificado (CSR) y luego esperar horas para la verificación y la firma simplemente 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 “Gestión de identidades de máquinas, secretos, claves y certificados”, 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.”
Simplemente configurar una CA autofirmada y emitir grandes volúmenes de certificados sin adherirse a las prácticas PKI adecuadas y a las políticas de certificados no es una opción viable.
A pesar de la ventaja obvia de acelerar el proceso de desarrollo, esta práctica presenta varias implicaciones de seguridad, ya que a menudo la seguridad es una consideración posterior. Los certificados autofirmados no confiables y no rastreados pueden utilizarse en ataques a la cadena de suministro de Software y permitir que actores maliciosos distribuyan código malicioso.
Las organizaciones deben asegurarse de que todos sus certificados se emitan desde una raíz de confianza segura, cumplan con las políticas y las mejores prácticas, y se gestionen a lo largo de todo su ciclo de vida.
La alternativa: del autofirmado al autoservicio
La solución para superar este desafío requiere un cambio fundamental en la forma en que los equipos de seguridad y desarrollo colaboran. En última instancia, es necesario facilitar a los desarrolladores un acceso rápido y sencillo a los certificados desde sus propios flujos de trabajo, sin sacrificar la confianza ni las políticas.
En Keyfactor, trabajamos con equipos de DevOps para facilitar la transición de certificados autofirmados a certificados como servicio (as-a-service). Esto significa que los desarrolladores pueden obtener certificados utilizando 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 como servicio (as-a-Service) de confianza empresarial y la seguridad mantiene una visibilidad y un control completos sobre cada certificado emitido.
Habilitación de PKI como servicio en DevOps
PKI como servicio (PKIaaS) es la combinación adecuada de confianza y facilidad de uso. Los certificados se emiten desde una PKI de confianza con raíz privada, y los equipos de DevOps pueden solicitar y emitir certificados fácilmente a través de procesos de autoservicio, reduciendo 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.
