¿Está intentando mejorar su postura de seguridad en AWS? Lea las siguientes recomendaciones y consejos para evitar estos problemas comunes de seguridad en la nube.
Este top 5 ha sido creado por nuestro equipo de Consultoría de Seguridad, basándose en la experiencia real de diversas evaluaciones realizadas durante los últimos años.
1. Registro
Uno de los problemas más comunes en las arquitecturas de nube es la falta de mecanismos de registro para los servicios utilizados en AWS.
Los logs son registros del uso y rendimiento de las aplicaciones. Tras los ataques, los logs pueden consultarse para obtener información sobre cómo se produjo el ataque y sobre los daños sufridos en lo que se denomina análisis forense.
Para las organizaciones con niveles de madurez de seguridad más elevados, los registros pueden ser incluso útiles en tiempo real para detectar y mitigar los ataques en cuanto se producen.
Durante nuestros proyectos de evaluación de seguridad en arquitecturas Cloud -ya sea AWS, GCP o Azure- uno de los puntos clave a auditar es cómo están configuradas las políticas de logging para cada servicio utilizado.
Una validación básica debe responder “sí” a todas las preguntas siguientes:
- ¿Está activado el registro para el servicio?
- ¿Se escribe en los registros sólo la información útil? Escribir todo sin filtro es ineficiente y podría causar otros problemas de seguridad.
- ¿Se almacenan los logs en una cuenta de AWS independiente? El aislamiento de la infraestructura productiva es importante, ya que los registros deben conservarse cuando la cuenta de producción se vea comprometida.
- ¿Están configurados en IAM los accesos a servicios de registro como CloudTrail y CloudWatch, utilizando el principio de mínimo privilegio? Seguir este principio reduce la superficie de ataque al minimizar las posibilidades de que un atacante comprometa los registros y procesos relacionados.
2. Principio del menor privilegio
El principio del mínimo privilegio consiste en proporcionar a los usuarios de la organización únicamente los privilegios y accesos necesarios para llevar a cabo sus tareas. Ni más, ni menos.
¿Por qué es útil este principio para una infraestructura en nube?
Supongamos que los usuarios tienen los menores privilegios posibles y que un ataque compromete la cuenta de AWS explotando una vulnerabilidad concreta. En ese caso, la aplicación de este principio creará un contexto adverso para los atacantes. Les impedirá acceder a todos los servicios e información y/o escalar sus privilegios a otros superiores. Por supuesto, esto depende de la vulnerabilidad explotada y de otros factores particulares de cada escenario.
Un error muy común es conceder privilegios de “Administrador” a los desarrolladores, por ejemplo. Conceder acceso ilimitado a usuarios que no lo requieren expone la infraestructura de la Nube a mayores vectores de ataque, aumentando el riesgo de un compromiso total, incluyendo la información almacenada en la Nube.
¿Cómo podemos verificar que seguimos este principio en nuestra nube?
En primer lugar, necesitamos obtener un mapa de todos los usuarios y grupos y sus privilegios para verificar que estos accesos son los mínimos necesarios para cada uno.
Por ejemplo, una forma sencilla de verificar si seguimos este principio es comprobar que todos los usuarios han utilizado los privilegios que tienen asignados durante los últimos 90 días.
Podemos verificar qué usuarios no han utilizado sus privilegios o no los han utilizado nunca utilizando la función Asesor de acceso de AWS herramienta. Podemos suponer que estos privilegios ya no son necesarios y pueden eliminarse en este caso.
Una segunda recomendación es utilizar herramientas que permitan crear un mapa de usuarios, grupos, roles y privilegios, buscando rutas para ejecutar escaladas de privilegios. Panda púrpura, Pacu iam__privesc_scanproyectos de Asesor de acceso de AWS son las mejores opciones para empezar.
3. API de metadatos de instancias de AWS
API de metadatos de instancias de AWS (IMDS)) es una API que contiene información sobre la instancia EC2 que se está utilizando. Esta información se utiliza para configurar o administrar la instancia actual e incluso para acceder a otros servicios de la cuenta de AWS que se esté utilizando (en función del rol establecido en la instancia).
Este último detalle es importante: la API de IMDS expone credenciales temporales que un atacante podría utilizar para acceder a determinados servicios, según el rol establecido en la instancia.
Dado que esta API es una API Rest Json que está disponible en una dirección local concreta (169.254.169.254), algunos ataques, como una Server Side Request Forgery (el más común y mencionado) u otros -como una mala configuración del Firewall y los Reverse proxies-, pueden aprovechar la existencia de esta API para explotar una vulnerabilidad en la aplicación y obtener acceso a la cuenta de AWS.
¿Cómo prevenir este tipo de ataques?
IMDSv1 no contiene ninguna mitigación para evitar este tipo de ataques.
En IMDSv2, la segunda versión de la API, AWS añadió una verificación de token para validar y permitir la solicitud. Esto invalida los ataques SSRF, ya que los atacantes no tienen acceso al token requerido.
La recomendación es activar IMDSv2 en todas las instancias de ECS que contengan aplicaciones web que se ejecuten o estén expuestas a un Firewall y/o proxy inverso.
4. Cubos AWS S3
AWS S3 es un servicio de almacenamiento de objetos que ofrece escalabilidad, disponibilidad de datos, seguridad y rendimiento.
Estos buckets pueden configurarse como públicos para que cualquier usuario -sin necesidad de autenticación o autorización- acceda a la información almacenada en ellos. Dado que estos datos pueden ser privados y/o sensibles para la organización, AWS S3 se ha convertido en el vector de fugas más conocido en la Nube.
La recomendación es verificar que la política “Bloquear todo acceso público” está activada en la cuenta de AWS. De esta forma, ningún bucket será público bajo ninguna circunstancia
Si se necesitan cubos públicos, es necesario evaluar los accesos relacionados para cada uno y utilizar el principio del menor privilegio para reducir la superficie de ataque.
Una excelente herramienta para detectar rápidamente este tipo de problemas es Merodeador y su comprobación: check_extra73
Para más información sobre la supervisión y alerta de cubos públicos, vaya a: https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/
5. Imágenes de contenedores AWS ECR
Amazon ECR es un registro completo de contenedores que ofrece alojamiento de alto rendimiento, permitiendo el despliegue de imágenes y artefactos en cualquier lugar.
Este registro permite que las imágenes de contenedores y/o artefactos sean públicas. De esta forma, la información que podría ser sensible para la organización incluye código fuente, aplicaciones internas y API/aplicaciones de terceros. Y más: podría verse comprometida por un atacante externo.
La recomendación es verificar que todas las imágenes y artefactos son privados y cumplen un proceso de autorización. De este modo, evitamos una posible fuga de información sensible y propiedad intelectual.
Otra vez, Merodeador y su comprobación (check_extra77) es una herramienta excelente para detectar estos problemas rápidamente.
Truvy, Anchor y Clair también son útiles para buscar vulnerabilidades en imágenes de contenedores AWS ECR.
Por último, pero no por ello menos importante, he aquí algunas recomendaciones generales que siempre es bueno recordar:
- Active la autenticación multifactor para todas las cuentas a través del software.
- Rote regularmente las contraseñas de acceso cada 90 días.
- Aplique una política de contraseñas seguras: 14 caracteres como mínimo con símbolos y números no repetidos.
- Utilizar AWS Configuration y AWS Organizations para separar los entornos de aplicaciones, recursos y servicios. Aplicar políticas de seguridad a nivel de cuenta de AWS.
- Para conocer más buenas prácticas, consulte el Marco de adopción de la nube de AWS.
Te interesa leer la segunda parte? ⚡🚀
