10 errores de seguridad habituales al trabajar en la nube

Cada vez son más las empresas que están migrando sus sistemas de almacenamiento y procesamiento de datos on-premise a la cloud pública. Esto supone que gran parte de los datos que manejan tanto grandes como pequeñas organizaciones pase de estar almacenada en data centers corporativos y privados a la nube.

Una de las principales preocupaciones de estas empresas es garantizar la privacidad y seguridad de la información cumpliendo con el Reglamento General de Protección de Datos (GDPR) que entró en vigor en el año 2018. Para ello, los proveedores cloud como AWS, Google Cloud o Microsoft Azure ofrecen gran cantidad de servicios y herramientas que ayudan a monitorizar y securizar nuestros sistemas de almacenamiento, análisis y procesamiento de grandes cantidades de datos.

Sin embargo, los temas relacionados con la seguridad, privacidad y conformidad de estos sistemas son una responsabilidad compartida entre el proveedor y el cliente, como queda reflejado, por ejemplo, en el Modelo de Responsabilidad Compartida de AWS.

En Keepler somos expertos en ayudar a grandes clientes corporativos de sectores regulados o con fuertes requisitos de seguridad como banca, seguros, energía, telecomunicaciones, retail, farma o industria, a diseñar, implementar y refactorizar sistemas de procesamiento de datos en la nube pública, siguiendo las mejores prácticas en securización y privacidad de la información.

Basándonos en nuestra experiencia en múltiples proyectos, a continuación vamos a explicar las 10 vulnerabilidades más comunes que nos encontramos al auditar entornos de trabajo cloud, concretamente en AWS, y cómo podemos evitarlas.

1. Multi-Factor Authentication (MFA) deshabilitado en las cuentas de los usuarios de AWS y política de contraseñas no configurada

Con MFA deshabilitado facilitas que cualquier atacante que consiga tu contraseña pueda acceder a tu cuenta. Esto, unido a una contraseña no robusta y a la inexistencia de una política de rotado de passwords adecuada, facilita el acceso al atacante. Para evitarlo, se debe activar Multi-Factor Authentication en tus cuentas de AWS de modo que, además de la contraseña, se necesite un token de autenticación generado automáticamente en un dispositivo para acceder a ellas.

2. Visibilidad de la actividad de nuestras cuentas de AWS insuficiente y descentralizada

Uno de los principales errores que cometemos los usuarios de AWS es crear recursos sin activar la monitorización y el registro de logs sobre éstos y sobre nuestra cuenta de AWS en general. No es posible securizar lo que no puedes ver y en esta situación resulta difícil detectar riesgos.

Para tener un entorno lo más seguro y controlado posible existen algunos servicios de AWS como AWS CloudTrail, AWS CloudWatch, VPC Flow Logs y AWS Guarduty que podemos utilizar.

Se debe activar AWS CloudTrail para capturar los eventos o llamadas al API de AWS de modo que la información sobre las distintas actividades o cambios que realizan los usuarios en todos los servicios de tus cuentas de AWS se registren en ficheros de logs almacenados en buckets de S3 correctamente cifrados y protegidos. Por otro lado, es posible configurar alarmas de CloudWatch para detectar cualquier cambio que se produzca en tu infraestructura, o el uso inadecuado de cualquier recurso. También se debe activar VPC Flow Logs, para monitorizar el tráfico de red que circula por nuestra VPC, permitiendo así detectar cualquier anomalía. Además de esto, podemos añadir AWS Guarduty para detectar actividades maliciosas y comportamientos no autorizados mediante el análisis constante de los registros de eventos.

En definitiva, AWS proporciona potentes herramientas de auditoría y debemos habilitarlas y utilizarlas para tener un entorno lo más seguro y controlado posible.

3. Mantener antiguos empleados de tu compañía y AWS Access Keys no utilizadas habilitados en AWS

Tanto las Access Key no utilizadas como los usuarios inactivos incrementan el riesgo de que tus datos se vean comprometidos o tus aplicaciones sobre AWS sufran cualquier ataque. Por ello, resulta muy importante establecer regularmente procesos para deshabilitar usuarios inactivos y eliminar las Access Keys que ya no se usen.

4. Incumplimiento del principio de conceder los menores privilegios posibles

Desafortunadamente, los administradores a menudo asignan permisos demasiado permisivos para acceder a los recursos de AWS, lo que permite que los usuarios quizás puedan realizar cambios de configuración que no deberían y que si un atacante consigue acceder a la cuenta y obtener dichos permisos haga mayor daño en la aplicación. Por ello, cualquier usuario, grupo o rol de IAM sólo debe tener permisos para realizar su trabajo y nada más.

Para reducir este riesgo, se recomienda asignar políticas a grupos o roles de IAM en lugar de usuarios, ya que esto facilita la gestión de permisos en AWS, y cuanto más simple sea esa gestión, más difícil será conceder permisos excesivos a cada entidad de AWS IAM y ser estrictos de cara a asignar únicamente aquellos permisos necesarios.

5. Permitir el acceso a puertos de gestión como SSH y RDP desde cualquier punto de Internet

Con una configuración de red demasiado permisiva cualquiera puede acceder al puerto 22 (SSH) o al puerto 3389 (RDP) de tus instancias EC2 en AWS. Esto supone que cualquier atacante, utilizando técnicas como acceso por fuerza bruta, puede conseguir el control de tus servidores, acceder a los datos que en ellos residen o incluso destruir esos datos. Además, podrían realizar ataques distribuidos de denegación de servicio (DDoS) que afecten al funcionamiento de tu sistema y que pueden suponer grandes pérdidas de dinero para la empresa.

Para mitigar estos riesgos se debe realizar las siguientes acciones:

• Limitar las direcciones IP desde las que se permite el acceso al puerto 22 o 3389 de cada instancia.
• Desplegar una instancia bastión securizada de modo que este sea el único punto de acceso para comunicarse con otras instancias dentro de la cuenta de AWS.

6. Utilizar buckets de S3 públicos o con políticas demasiado permisivas y no cifrados

Crear buckets de S3 con acceso público y sin cifrar, implica que cualquiera, desde cualquier punto de Internet, tiene acceso a los datos que almacenas en él. Para evitar esto se debe cifrar la información en ese bucket y denegar el acceso público al mismo o asociar una bucket policy que permita restringir el acceso únicamente a los usuarios o roles deseados desde rangos de direcciones IPs específicos.

7. No tener habilitado AWS Inspector para detectar vulnerabilidades en tus instancias EC2

No realizar actualizaciones o parches de seguridad en el software instalado en tus instancias EC2 supone un riesgo para tus aplicaciones. Para mitigar este riesgo, se debe habilitar AWS Inspector que se encarga de buscar y evaluar vulnerabilidades dentro de tus instancias que no cumplan con las buenas prácticas recomendadas. Además, se debe realizar actualizaciones periódicas del software instalado en las instancias EC2.

8. Cifrado automático de información deshabilitado en volúmenes EBS, en RDS y en buckets de S3

La información sin cifrar es de fácil acceso para un atacante, lo que pone en peligro tanto los datos como las claves de tu sistema.

Para reducir este riesgo, debes cifrar la información. Para ello, en el caso de volúmenes EBS puedes crear un nuevo volumen cifrado y migrar los datos al nuevo volumen. En el caso de RDS, puedes crear un snapshot cifrado de tu base de datos y crear una nueva base de datos a partir de él. Para S3 es suficiente con habilitar el cifrado del bucket.

9. Acceso al API de la cuenta root no está deshabilitado

Uno de los errores más comunes es utilizar el usuario root en las cuentas de AWS y olvidarse de deshabilitar el acceso a través del API para este usuario. Como consecuencia, se permite el acceso a todos los recursos de AWS a quien tenga estas claves, lo que supone un grave riesgo en caso de que las credenciales de esta cuenta se pierdan o alguien consiga hacerse con ellas.

Para mitigar este riesgo, se recomienda crear cuentas basadas en roles IAM en lugar de usar el usuario root de las cuentas de AWS y deshabilitar el acceso a través del API para el usuario root.

10. Configuración de los Network Access Control List

La configuración del NACL por defecto ofrece poca protección, de modo que se pone en riesgo los datos en la VPC, ya que no hay restricciones de tráfico a nivel de red aunque utilicemos Security Groups a nivel de instancia. Para evitar este riesgo, se puede configurar un NACL restrictivo que sólo permita el tráfico necesario para el funcionamiento de tu sistema y asociarlo a la VPC.

Estas malas prácticas pueden no suponer un problema para el funcionamiento diario de nuestra aplicación o plataforma. Sin embargo, representan un riesgo aún mayor, con consecuencias catastróficas para nuestra compañía, clientes y usuarios cuyos datos podemos comprometer. Evitarlas no supone un gran esfuerzo y AWS proporciona gran cantidad de facilidades para ello. Por tanto, nuestro consejo es: úsalas correctamente, presta atención a estos riesgos y mantén el entorno de tus sistemas AWS limpio, seguro, ordenado y constantemente vigilado.

Imagen: unsplash | @fantasyflip