¿Es AWS seguro?

Seguramente, esta pregunta o nos la hemos hecho en alguna ocasión o, bien, nos la ha preguntado alguien. Desde que empecé en este mundo de AWS, me he dado cuenta de que mucha gente asume que la seguridad en Cloud o no existe o es muy baja.

Y, he de reconocer que, antes de empezar en este mundo, yo también tenía esta visión, pero era una visión basada en mi desconocimiento y en ciertas afirmaciones que había leído o escuchado que eran erróneas.

Vamos a dedicar este post a intentar explicar ciertos conceptos de la seguridad en AWS, repasar cómo funciona AWS y cómo podemos securizar nuestras cargas al máximo.

Haciendo peticiones a AWS

Lo primero es saber cómo funciona una petición en AWS. Vamos a explicar una llamada para crear un bucket S3 y desde ahí vamos a ver cómo de seguro es AWS y cómo podemos gestionar la Seguridad.

Vamos a usar un usuario federado desde un Identity Provider utilizando AWS Identity Center, que es el sucesor de AWS Single Sign-On.

Esta llamada es exactamente igual si la realizamos vía consola, vía API o desde el cli de AWS.

1. Primero es necesario realizar una llamada a AWS Identity Center para autentificar el usuario.
2. AWS Identity Center se conectará con el Identity Provider que tengamos configurado para autentificar al usuario y este solicitará las credenciales al usuario para validarlas.
3. El Identity Provider validará la credenciales y autentificará la petición contra AWS Identity Center que permite al usuario asumir un rol en AWS dependiendo de los permisos que tenga otorgados en Identity Center.
4. AWS Identity Center realizará una llamada a STS (Security Token Service) para generar una credencial temporal que devolverá en la petición inicial del usuario y que podremos reutilizar durante un corto periodo de tiempo (de 1 hora a 12 horas máximo, dependiendo de configuración).

Este primer flujo es el correspondiente a un login en la consola, un login vía cli o un AssumeRoleWithSAML vía API y solamente es necesario realizarlo una vez, es posible utilizar el token durante el periodo de validez de este.

Con este token asumimos un rol dentro de una cuenta en AWS con los permisos que tenga ese rol asignado.

5. Con esta credencial temporal lanzaremos la petición para crear un bucket S3 al endpoint de S3 en nuestra región.
6. El servicio de S3 llamará a IAM para autorizar la petición dependiendo de los permisos que tenga el rol IAM que se ha asumido con las credenciales.
7. IAM autorizará la petición devolviéndole esta firmada a S3.
8. Finalmente, S3 creará el Bucket.
9. S3 responderá a la petición indicando que se ha generado el bucket.

Este flujo está simplificado al máximo para explicarlo de la forma más sencilla posible (es algo más complejo).

Todas las peticiones a AWS van firmadas de forma individual con AWS Signature Version 4 (AWS SigV4) que es el proceso por el que AWS firma todas sus peticiones y que lleva en uso desde hace más de 10 años sin ningún problema conocido.

Cada petición aunque sean iguales y reiterativas tienen una firma diferente y no es posible ni siquiera realizar un ataque por fuerza bruta aunque se tuviese la potencia de computación suficiente.

Si queréis más info sobre este tema, os recomiendo la sesión de Eric Brandwine sobre este tema.

Este tipo de flujo es extremadamente seguro y vamos a tratar de explicar todas sus ventajas.

Securizando las acciones via IAM y SCPs

En primer lugar, al utilizar AWS Identity Center además de poder autentificar con un IdP propio, utilizamos AWS STS para generar tokens seguros y temporales, de forma que estos Token tienen una duración limitada y aunque alguien consiguiera robar uno (en caso de que un usuario los publicara de forma explícita por error), este token expirará automáticamente pasadas unas horas, además es posible revocar un token temporal en caso necesario.

Como otra ventaja de este modelo es que cada petición es autorizada vía IAM y requiere que la acción esté permitida de forma explícita en alguna política asociada al rol o usuario IAM y que además no esté denegada en ninguna otra política asociada.

IAM es extremadamente flexible y podemos llegar a limitar acciones muy determinadas o permitir diferentes grados de acceso con una granularidad inmensa.

Todo esto sin entrar en la potencia de las Permission Boundaries que es un feature muy potente para delegar la Administración IAM a otros usuarios, pero limitando los permisos que pueden gestionar.

Además, es posible denegar ciertas acciones de forma organizativa usando una funcionalidad de AWS Organizations llamada Service Control Policies (SCPs), que permiten bloquear acciones a nivel de cuenta de AWS, OUs (que son agrupaciones de cuentas similares a una carpeta) o toda la organización.

De esta forma, podemos limitar ciertas acciones, como por ejemplo que los usuarios creen infraestructura para que su VPC tenga acceso a Internet de forma directa. O el uso de ciertos servicios sin una configuración determinada.

Hay mil casos de uso en los cuales se pueden utilizar SCP y permiten una potencia infinita a la hora de limitar ciertas acciones, tanto en la documentacion de AWS, en aws-samples, o en la documentación de Control Tower hay multitud de ejemplos muy utilies, además de poder construir tus propias SCPs.

Auditando recursos con CloudTrail y Config

Ya hemos visto que debido al flujo de peticiones de AWS podemos bloquear ciertas acciones, pero ¿qué pasa si no podemos bloquearlas todas o queremos más control sobre ella? El siguiente paso es CloudTrail, que si no está activado en vuestras cuentas, estáis tardando en activarlo: es gratis (el primer trail en cada cuenta) y sin él no tenéis auditoría de vuestros eventos.

CloudTrail registra automáticamente todos los eventos generados en nuestra cuenta de AWS, es posible centralizarlo utilizando AWS Organization y tiene diferentes niveles de configuración, pero basicamente nos da la posibilidad de auditar todas las peticiones que se realicen en nuestra cuenta a servicios de AWS.

Aquí se suele decir que CloudTrail está muy bien, aunque no bloquea acciones indebidas, solo nos avisa. Para esto, tenemos otros servicios de AWS que se pueden combinar con CloudTrail.

Amazon EventBridge es una maravilla (anteriormente conocido como CloudWatch Events), que simplificando mucho es un bus de eventos que nos permite enlazar servicios de AWS.

Con Amazon EventBridge podemos capturar los eventos registrados en CloudTrail y generar llamadas a otros servicios como Lambda.

De esta manera, podemos generar una acción de evaluación sobre diferentes acciones en la consola e incluso derivar en acciones de remediación.

Por ejemplo, con respecto a seguridad, un gran miedo suele ser que alguien genere un Security group abriendo puertos indebidos a todo el mundo (por ejemplo, SSH y RDP). De esta forma, podemos generar un automatismo que revise cada vez que se genera o modifica una regla dentro de un Security group; si esta cumple ciertos requisitos, eliminarla y, a su vez, mandar un aviso al responsable de la cuenta indicando que se ha ejecutado esta remediación.

Para mí, esta es una de las grandes ventajas del cloud podemos evaluar un montón de acciones con este método y generar automáticamente remediaciones. Y con la ventaja de que usamos 2 servicios con un coste muy bajo, como son EventBridge y Lambda.

Si nos parece muy complejo generar estas reglas de evaluación con Lambda, ya que no disponemos de un equipo que desarrolle estas reglas, tenemos AWS Config. AWS Config es un servicio que evalúa todos nuestros recursos y los cambios de configuración de estos basándose en unas reglas que podemos configurar.

Existen multitud de reglas a implementar AWS tiene muchas reglas gestionadas para diferentes casos de uso que podéis consultar aquí y también existe un recurso muy interesante que las recopila por Conformace Packs para diferentes casos de uso.

Con base en esto, podemos evaluar si nuestros recursos cumplen nuestros estándares y es posible ejecutar acciones de remediación, para estas acciones podemos utilizar o bien Lambda o también System Manager Automation que permite la ejecución de ciertos runbook desarrollados por AWS para multitud de acciones de remediación.

Como nota importante de AWS Config, es usado por todos los CSPM (Cloud Security Posture Management) para evaluar recurso. Y, también, destacar que es un servicio que en ocasiones puede tener unos costes bastante elevados.

Inspeccionando nuestros recursos con Amazon Inspector y System Manager

Vale ya hemos visto que las acciones dentro de AWS están cubiertas, pero ¿y las instancias de EC2 y el código que ejecutan? Aquí entran otros servicios maravillosos de AWS.

El primero es Amazon Inspector que permite analizar las cargas de trabajo en AWS en busca de vulnerabilidades. Este servicio es capaz de encontrar vulnerabilidades en instancias EC2, en imágenes de contenedores almacenadas en ECR (Elastic Container Registry que es el servicio de Registry para contenedores de AWS) y, desde hace relativamente poco tiempo, en el propio código desplegado en Lambda.

Es un servicio muy útil y que como todos los servicios de AWS permite la integración con otros como Lambda y System Manager para automatizar remediaciones.

Pero además, hemos hablado un poco de System Manager que es un servicio alucinante con un montón de módulos (varios de ellos muy interesantes para seguridad).

• El primero de ellos sería Patch Manager, que permite gestionar nuestro parque de instancias EC2 para mantenerlas actualizadas y aplicar los parches de forma automática. Es un servicio sencillo de usar y con una potencia infinita que permite mantener nuestras máquinas actualizadas, permitiéndonos generar ventanas para su aplicación, diferentes ventanas por tipo de entorno, SO, e incluso llegar a tener diferentes niveles de parcheo para poder probar en un pequeño número de instancias actualizaciones que puedan ser más disruptivas.
• Otro servicio que se utiliza poco, pero me parece fundamental es Session Manager, que nos permite acceder a nuestras instancias utilizando nuestras credenciales IAM y sin utilizar el protocolo SSH. Esta funcionalidad es increíble, ya que permite un acceso mucho más securizado a nuestra instancias sin necesidad de exponerlas de ninguna manera. Únicamente requieren acceso al servicio de SSM (que se puede realizar de forma totalmente privada utilizando VPC Endpoints).
• También existe este mismo servicio para instancias Windows sin utilizar el protocolo RDP y en este caso se llama Fleet Manager.

Lo más impresionante de System Manager es que los 3 módulos de los que hemos hablado son gratuitos.

Automatizando el análisis de eventos de seguridad con AWS GuardDuty

Tenemos un montón de servicios que nos dan apoyo de forma preventiva, pero ¿qué pasa si alguien consigue entrar en nuestras cuentas y empieza a hacer el mal?

Aquí tenemos uno de los servicios más importantes de AWS en seguridad. AWS GuardDuty es un servicio que utiliza la inteligencia artificial para detectar amenazas.

Esto suena muy bien, pero ¿cómo funciona realmente? Este servicio es capaz de identificar patrones de uso inadecuados dentro de AWS. Esto es sencillo porque hay que tener en cuenta que se alimenta de los datos de seguridad de todas las cuentas existentes en AWS.

AWS no es capaz de acceder a tus datos, pero sí que tiene visibilidad sobre las acciones que se realizan sobre sus servicios de forma que es bastante “sencillo” identificar patrones de uso inadecuados. Y es más, al utilizar Inteligencia Artificial y alimentarse de una cantidad ingente de datos, si en una cuenta se denuncia un uso inadecuado se puede identificar el patrón de uso y analizar si se repite en más cuentas de AWS generando avisos a los usuarios para que mitiguen el problema.

Es un servicio brutal, que detecta instantáneamente si se están produciendo eventos inadecuados.

Mucha gente no utiliza el servicio pensando que es extremadamente caro, cuando no lo es. Es más, realmente a mí me parece un servicio muy económico, teniendo en cuenta que nos puede ahorrar muchos problemas detectando usos inadecuados incluso dentro de nuestra propia organización.

Además de este servicio existe un equipo de seguridad dentro de AWS, llamado Ghostbusters, que es el último escalado para eventos de seguridad de AWS que es increíble. Os recomiendo revisar esta sesión en la que hablan sobre este equipo y cómo gestionaron un evento como Log4Shell.

Entonces ¿cómo de seguro es AWS?

Solo hemos hablado de unos pocos servicios involucrados en la seguridad dentro de AWS, pero hay muchos más: Macie (servicio para detectar datos sensible), Secret Manager (gestión de secretos), Network Firewall (solución de Firewall Perimetral), WAF (Web Application Firewall con reglas gestionadas de AWS o de Third Parties), Firewall Manager (gestión centralizada de reglas de seguridad, WAF, etc.), AWS Shield Advanced (mejora sobre la protección para ataques DDoS) y muchos más.

De esta forma, podemos tomar consciencia del nivel de seguridad que podemos alcanzar en AWS, que puede ser extremadamente alto si implementamos los servicios de seguridad que AWS provee.

Además, una de las ventajas no es solo el nivel de seguridad y aviso que podamos tener, sino la posibilidad de auto remediar que a mi modo de ver es la gran ventaja que tenemos en el mundo AWS.

La posibilidad de automatizar no solo el descubrimiento de incidentes, sino automatizar la remediación reduciendo el tiempo de respuesta al mínimo es una ventaja inmensa.
También es común pensar que nosotros requerimos un nivel de seguridad que AWS no va a ser capaz de proveer, para estos casos recomiendo revisar quién usa las Secret Regions de AWS.

Un entorno seguro tiene que ser utilizable. Esta es quizás la parte más complicada, tener un entorno seguro sin sacrificar la usabilidad es muy complejo, pero con las herramientas de AWS es más sencillo llegar a un entorno seguro y utilizable. Existen muchos entornos hiperseguros, pero que son inutilizables y esto suele provocar que se busquen alternativas poco seguras y de las que probablemente los equipos de seguridad no tengan constancia.

Con un entorno en AWS, podemos llegar a tener un entorno que sea utilizable y a la vez que podamos controlar y securizar el entorno.

Como conclusión AWS no es solamente seguro, sino que probablemente nos puede ayudar a incrementar la seguridad de nuestro propio entorno y llegar a unos niveles muy altos de seguridad, incrementando la automatización. Si quieres profundizar en este tema, en este post te contamos las 10 medidas a implementar en AWS.

Si quieres ahondar más en la seguridad de AWS...

Escucha este episodio de podcast en el que examinamos en detalle la seguridad en AWS hablando de desafíos y soluciones