SSL/TLS certificados emitidos por autoridades de certificación (CA) de confianza, ya sean públicas o privadas, se utilizan para autenticar un único dominio en sitios web de cara al público. Las organizaciones con un puñado de dominios y subdominios públicos tendrían que emitir y gestionar un número igual de certificados digitales, lo que aumentaría la complejidad de la gestión del ciclo de vida de los certificados. La buena noticia es que existe una solución para eludir esta carga.
Los certificados comodín prometen simplicidad, pero ¿son la solución a todas nuestras plegarias?
Este blog está coescrito con Robert Masterson de Thales
El cambio hacia las aplicaciones nativas de la nube está modificando los componentes básicos de TI. En muchos casos, el desarrollo y mantenimiento de infraestructuras y aplicaciones en la propia empresa ya no es una opción. El desarrollo de aplicaciones nativas de la nube y el uso de contenedores y marcos de orquestación como Kubernetes ofrecen ventajas innegables en cuanto a rendimiento, portabilidad y escala.
Sin embargo, es obvio para los equipos de seguridad que la posible superficie de ataque ha crecido como consecuencia de ello. El despliegue a gran escala y bajo demanda de recursos informáticos en una combinación de nubes públicas y privadas significa que las vulnerabilidades de seguridad o los exploits pueden pasar a menudo desapercibidos. Saber en quién y qué se puede confiar es una lucha constante, ya que el código malicioso, las conexiones no fiables y la mala configuración conducen a una sola cosa: más riesgo.
Varios mecanismos ayudan a los equipos de aplicaciones y seguridad a mitigar estos riesgos, pero la identidad es el núcleo. Identificar todas las "cosas" (por ejemplo, cargas de trabajo, servicios, código) en cada nube o red, verificar la integridad y cifrar las conexiones de extremo a extremo es la mitad de la batalla. Dos funciones críticas que hacen esto posible son el refuerzo de la firma y la autenticación de la confianza, ambas realizables mediante el uso de certificados X.509.
Firmar todo
Los desarrolladores siempre deben firmar digitalmente el código para proteger a los usuarios finales de la descarga e instalación de código comprometido. La firma del código garantiza que la aplicación no pueda ser modificada por un usuario no autorizado y proporciona una gran seguridad de que sólo se ejecutará el código auténtico desarrollado y verificado por el proveedor. Una vez que software se empaqueta en contenedores para su despliegue en la nube, los contenedores también pueden firmarse. Por ejemplo, Docker admite la seguridad y firma de contenedores para permitir la verificación de la integridad y el editor del contenedor.
Recomendamos ambos niveles de firma. Si la aplicación está firmada, pero el contenedor no, entonces un usuario malintencionado podría ejecutar potencialmente otro código malicioso en el contenedor además del código legítimo. No cabe duda de que es necesario reforzar las firmas, pero aún más importante es la protección de los certificados -y su clave privada asociada- utilizados para firmar. Si estas claves se ven comprometidas, los atacantes pueden utilizarlas para firmar código malicioso, haciéndolo parecer auténtico y de confianza al igual que tu software.
Keyfactor Code Assure se ha creado específicamente para resolver estos problemas. La plataforma proporciona a los desarrolladores acceso programático a los certificados para firmar código, mientras que el equipo de seguridad mantiene un estricto registro de auditoría de todas las actividades de firma y garantiza que las claves privadas permanezcan seguras en un HSM integrado de Thales. El almacenamiento de las claves privadas en un HSM de Thales con certificación FIPS 140-2 de nivel 3, ya sea en las instalaciones o basado en la nube, garantiza que, aunque alguien tenga acceso a la ubicación, no pueda extraer ni copiar el certificado.
Además, la firma se puede realizar de forma remota, lo que elimina la necesidad de distribuir claves confidenciales entre varios equipos o ubicaciones. El proveedor de almacenamiento criptográfico (CSP) y las API de Keyfactor permiten la integración en casi cualquier proceso de creación o canalización de CI/CD, tanto si utiliza Microsoft SignTool para ejecutables de Windows, jarsigner para la autenticación de Java o una herramienta más compleja como Jenkins.
Establecer identidades seguras para todo
La mejor práctica es asegurarse de que cada conexión hacia, desde o dentro de un contenedor o clúster utilice SSL/TLS para permitir la autenticación mutua y el cifrado de extremo a extremo. Esto evita que adversarios no autorizados realicen una conexión que podría comprometer la seguridad del contenedor de todo un clúster. También es importante supervisar y auditar los certificados SSL/TLS emitidos y activos. Los certificados desconocidos, falsos o no conformes pueden provocar una interrupción inesperada o, lo que es peor, un uso indebido que permita el acceso no deseado a sistemas restringidos.
Por ejemplo, Kubernetes puede generar y emitir certificados por sí mismo, pero la mayoría considera que no proporciona la visibilidad que necesitan para garantizar que los certificados no se han emitido de forma inadecuada. Sin embargo, Kubernetes también admite el protocolo ACME, que puede utilizarse para obtener certificados de otras fuentes, como Let's Encrypt. Este soporte de protocolo se integra con el servidor ACME de Keyfactor , incluido como parte de Keyfactor Command -nuestra plataforma de automatización de certificados y PKI como servicio- para obtener certificados de cualquier PKI compatible con la empresa, ya sea pública o privada, que esté configurada en la plataforma Keyfactor . Esto permite la emisión segura y automática de un certificado de identidad único y de confianza para cada contenedor en el momento del despliegue. Esto se hace con un sólido control de acceso basado en roles a diferentes plantillas o productos de certificados, junto con amplias capacidades de flujo de trabajo, auditoría y alerta, para proporcionar la tranquilidad de que no se están emitiendo o utilizando certificados cuando no deberían.
Los certificados emitidos para contenedores deben ser de corta duración para limitar el número de certificados no caducados activos en un momento dado, que a menudo puede superar los miles. Esto ayudará a reducir el riesgo de compromiso y disminuir el impacto si un certificado fuera robado, ya que expirará pronto de todos modos. Sin embargo, el certificado que no puede ser efímero es también el más importante: el certificado de la propia Autoridad de Certificación (CA).
Al igual que con la firma de código, es fundamental proteger las CA que emiten los certificados. Si una CA se ve comprometida, los atacantes pueden emitir sus propias identidades que serán de confianza por defecto en todo su ecosistema, y esto puede ser extremadamente costoso de remediar, ya que invalida efectivamente cada identidad emitida por esa CA. La plataforma Keyfactor Command , integrada con los HSM de Thales para proteger sus certificados y claves de CA, garantiza una protección sólida y una visibilidad completa, la aplicación de políticas y la automatización de todos los certificados.
Descubra cómo la automatización del ciclo de vida de los certificados puede ayudarle a alcanzar los objetivos de DevOps y seguridad. Descargue el libro electrónico de DevOps.com: