Para conseguir un modelo de seguridad Zero Trust, lo primero que debemos tener en cuenta es que este modelo se basa en la premisa que ningún entorno es seguro. Toda información confidencial debe ser protegida, al igual que los canales de comunicación tanto internos como externos.
Para entender el por qué es necesario el modelo zero trust pensemos en la siguiente situación.
Cómo conseguir seguridad Zero Trust
Los enfoques de seguridad tradicional se basan en la premisa de la seguridad perimetral. En ese sentido, el data center se considera el perímetro a proteger, y por tanto todo lo que está dentro de dicho data center es seguro. El único punto de entrada está protegido, normalmente mediante un firewall.
Primer ataque al data center desde un punto externo:
Segundo ataque al data center desde dentro:
En este caso, con la seguridad tradicional, podemos observar que el atacante ha tenido control total del data center, ya que internamente no se ha establecido ninguna medida de seguridad. Logra saltar sin problema al único punto de entrada protegido. Comúnmente se piensa que los ataques siempre se realizan desde fuera de nuestro data center, cuando la realidad es muy distinta.
Utilizando la seguridad tradicional tenemos los siguientes retos.
- Demasiados puntos de entradas a proteger, especialmente en la nube.
- Una vez dentro de la red, se puede mover libremente e incluso ver los secretos de nuestros aplicativos.
- Configuraciones manuales y dependientes de la plataforma.
¿Cómo cambiar al modelo de seguridad zero trust?.
Para conseguir un enfoque que sea escalable, seguro y que no dependa de la plataforma, en este post nos enfocaremos en las herramientas de Hashicorp que utilizan como base el modelo zero trust.
Este enfoque se basa en proporcionar el menor privilegio posible, de tal manera que ningún usuario o aplicación tenga mayor acceso que el mínimo requerido para operar en una aplicación o sistema.
Cómo conseguir un modelo de seguridad Zero Trust
Las soluciones Zero Trust de Hashicorp verifican de manera continua tanto a usuarios como a aplicaciones que intentan acceder a datos o a herramientas. Siempre asumen que cualquier conexión puede tratarse de un potencial ataque, por lo tanto, retan al usuario de manera continua a probar que no son atacantes.
Puntos a tener en consideración
- Se puede evolucionar poco a poco.
- Crear modelo basado en identificación y no basado en IPs.
- Mantener filtros en los puntos de entrada.
- Buscar automatizar para permitir escalar fácilmente.
- Utilizar herramientas no dependientes de la plataforma o tecnología.
- Aplicar reglas para identificar los servicios y no confiar directamente en ellos.
Autenticación y autorización
Existen soluciones maduras y con un amplio recorrido en el mercado con distintos enfoques para solucionar esta problemática.
En este post nos centraremos en la técnica Single Sign On o SSO (por sus siglas en inglés). Permite a los usuarios tener acceso a múltiples aplicaciones ingresando con una única cuenta a los diferentes sistemas y recursos.
El SSO es de gran utilidad cuando existen diferentes sistemas a los que es posible acceder mediante una única contraseña. Se desea evitar el ingreso repetitivo de éstas cada vez que el usuario se desconecte del servicio.
Para los usuarios supone una gran comodidad ya que identificándose solo una vez es posible mantener la sesión válida para el resto de las aplicaciones que hacen uso del SSO.
Algunas soluciones en entornos on-prem son:
- Active Directory
- LDAP
Como ejemplo de soluciones SaaS, tenemos:
- Google Authenticator
- OKTA
Acceso entre aplicaciones
Cómo conseguir un modelo de seguridad Zero Trust
Como se ha mencionado anteriormente, necesitamos hacer que nuestras comunicaciones sean seguras, tanto de manera interna como de manera externa. Con esto lograremos tener un mejor control de nuestras conexiones entre servicios y evitar algún ataque interno en nuestros data center.
Consul es una herramienta de Hashicorp , cuya función principal es facilitar la comunicación segura entre servicios y consumidores, llevando a cabo el registro y descubrimiento de los mismos.
Consul Connect proporciona autorización y encriptación de conexión de servicio a servicio utilizando Seguridad de capa de transporte (TLS) mutua. Las aplicaciones pueden usar proxies en una configuración de malla de servicio para establecer conexiones TLS, tanto para conexiones entrantes como salientes, de forma transparente para las aplicaciones.
Las aplicaciones también pueden integrarse de forma nativa con Consul Connect para lograr un mayor rendimiento y una seguridad óptima. De igual forma, Consul Connect puede ayudar a proteger sus servicios y proporcionar datos sobre las comunicaciones entre servicios.
Consul puede trabajar entre múltiples clústeres y entornos creando una malla de servicio global. Aplicando políticas y seguridad de manera coherente en todas las plataformas.
Se mostrarán dos ejemplos de comunicación, el primero es la arquitectura de comunicación entre múltiples data center y el segundo es una comunicación servicio a servicio.
Comunicación entre múltiples data center
En la imagen anterior se pueden ver cómo está establecida la comunicación entre los diferentes data center y sus elementos en común son los siguientes:
| servicio de consul |
| Envoy proxy: Encargado de establecer comunicaciones mTLS entre servicios |
La solución de Consul utiliza proxies con túneles tls para abrir y cerrar la comunicación entre las diferentes aplicaciones y servicios, con el fin de analizar las políticas de seguridad y saber cuándo un tráfico es bueno o malo.
Esto quiere decir que todos los servicios y aplicaciones deben conectarse a Consul para establecer comunicación y autenticarse contra el mismo, con el fin de tener un mejor control de quien accede a dicho servicio. Se puede observar mejor en la siguiente imagen.
Comunicación entre servicios
Como se muestra en la imagen anterior, con Consul las aplicaciones se comunican entre sí, mediante canales cifrados con tls. En esta arquitectura todas las comunicaciones pasan a través del proxy de Consul para que este pueda analizar y registrar todo el tráfico. De esta manera detectar cualquier ataque, al tiempo que puede realizar un análisis de forma muy sencilla.
El proxy también es el responsable de iniciar la comunicación entre las distintas aplicaciones, así que si éste detecta alguna conexión no segura, ésta evitará su acceso basado siempre en las políticas y la identificación del mismo.
Centralización de los secretos
El objetivo de esta técnica es evitar que nuestras aplicaciones almacenen sus credenciales de acceso (secretos) a recursos externos como bases de datos u otros sistemas o aplicaciones, en código fuente, variables de entorno u otros métodos vulnerables de ser comprometidos durante un ataque.
En su lugar utilicen a Vault como intermediario para la autenticación y con esto evitar que si uno de nuestros servicios es atacado, el atacante pueda obtener credenciales de otros servicios de bases de datos, token de AWS o archivos importantes para nuestra empresa.
Hashicorp Vault es un sistema de gestión de secretos, que nos permite implementar esta técnica de una forma ágil y sencilla. La arquitectura de la solución es la siguiente:
Tenemos un sistema de almacenamiento de secretos centralizado, desde el cual se puede gestionar de manera sencilla la autenticación entre nuestros servicios.
Vault proporciona todo lo anterior: admite secretos dinámicos para todos los sistemas y herramientas populares (proveedores de la nube, bases de datos, ssh, etc.) y proporciona un lugar central, seguro y configurable para almacenar secretos. Además, ofrece una variedad de métodos de autenticación que realizan autenticación y asignación de políticas a un usuario y servicios y, finalmente, tiene revocación y auditoría automáticas.
Si quieres conocer más sobre Vault y Terraform, no te pierdas estos vídeos de nuestro canal de YouTube:
