Seguridad en tu infraestructura: las 10 medidas a implementar en AWS.

En esta entrada vamos a revisar los 10 puntos que, desde el punto de vista de seguridad, son los más importantes a la hora de securizar una infraestructura. Vamos a centrarnos en AWS, con lo que todos los servicios aquí mostrados son relativos a esta nube. Aquí encontrarás consejos y herramientas que pueden ayudarte en tu camino a ser un Jedi de la securización de infraestructuras, ¡vamos a ello!

A la hora de evaluar el grado de cumplimiento de requisitos de seguridad de una infraestructura suelen repetirse siempre los mismos puntos. Son acciones que aunque son importantes, muchas veces quedan relegadas a un segundo plano por el ritmo frenético del desarrollo de los proyectos.

Siguiendo los puntos que detallamos a continuación, puedes establecer una base para cumplir con los principales requisitos que los equipos de seguridad suelen pedir a la hora de evaluar una infraestructura en la nube.

1 Backups

Seguro que alguna vez has oído que la forma más efectiva de despertarse por las mañanas es borrar una base de datos en producción. Si te gusta el café y no quieres cambiar la forma en que te despiertas, hacer backups de todos los datos que sean susceptibles de perderse es la primera de las acciones que deberías tener en cuenta. A continuación te dejamos algunos de los servicios que deberías revisar:

Base de datos

En este punto, puedes estar tranquilo, AWS ya se ha preocupado de ello y te ofrece la posibilidad de crear backups automáticos para tus RDS en la ventana de mantenimiento que establezcas a tal efecto. Para que AWS empiece a hacer backups de tus RDS de manera automática, solo tienes que editar tu RDS. Cambia el valor del campo “Periodo de retención de copia de seguridad” en el apartado “Copia de Seguridad” en tu base de datos, estableciendo un valor entre 1 y 35.

Teniendo lo anterior, AWS creará un snapshot de las instancias RDS realizando así una copia de todas las bases de datos que tengas almacenadas. Esta copia la guarda en S3 según el tiempo de retención que le hayas indicado. Ten en cuenta lo siguiente si quieres basar tu estrategia de backups en los backups automáticos de AWS:

• Puedes establecer el tiempo de retención de los backups entre 1 y 35 días. Ten en cuenta que si estableces que el tiempo de retención de tus backups sea 0 días, los backups automáticos se desactivan.
• Estos backups solo se crean cuando la BBDD está activa, con lo que si tu instancia RDS está parada, no se harán backups sobre la misma. En este caso, deberías optar por hacer un snapshot manual de la misma.
• Este tipo de backups se pueden retener más allá del período de retención en caso de que la instancia RDS se detenga. Esto ocurre porque el período de retención de estos backups no tiene en cuenta el tiempo en el que la instancia RDS se encuentra parada.

Si quieres estar aún más seguro de que tus backups se almacenan y no se pierden con el tiempo, deberías crear snapshots manuales de tus RDS. La ventaja de los snapshots frente a los backups automáticos es que los snapshots deben ser borrados de manera explícita, con lo que no desaparecen hasta que tú los elimines. A continuación te dejamos algunos puntos a tener en cuenta si tomas este camino para guardar los backups de tus RDS:

• El tiempo de realización de un snapshot dependerá del tamaño de las bases de datos que estén almacenadas en tu instancia RDS. Esto también afectará al tamaño del snapshot.
• La base de datos debe estar en estado “Disponible” en el momento en que se cree un snapshot.
• Los snapshots no se eliminan basándose en un período de retención. Debes eliminarlos de manera manual. En este sentido, es conveniente que pienses en exportar los snapshots a S3 y apliques una regla de ciclo de vida a los mismos según lo que sea conveniente en tu caso.

Discos asociados a instancias

En caso de que en tu infraestructura cuentes con información importante almacenada en tus instancias, deberías tener en cuenta qué soluciones puedes aportar para evitar la pérdida de datos cuando estas se apaguen. En este sentido tienes varias opciones:

• Puedes hacer una imagen de la máquina y un snapshot del disco de manera periódica, según se vayan haciendo cambios sobre la máquina.
• Puedes configurar una regla en CloudWatch Events para que los backups de tu disco se creen de manera automática.

Versionado de los elementos en buckets de S3

El versionado de los objetos en S3 hace referencia al mantenimiento de varias versiones de un mismo elemento en un bucket. Con el versionado de los elementos almacenados en tus buckets te aseguras de que si tus ficheros se eliminan, cabe la posibilidad de recuperarlos de manera ágil y sencilla.

2 Zona geográfica de despliegue de servicios

Siguiendo la normativa europea en la que se obliga a que todos los datos de los ciudadanos europeos sean tratados bajo las premisas de su propia ley, es de vital importancia que todos los datos que sean de carácter personal almacenen y se traten dentro del territorio de la Unión Europea.

En caso de no cumplir estos requisitos, las sanciones son bastante fuertes, así que hay que ser especialmente cuidadoso con este punto y tener especial cuidado a la hora de decidir dónde desplegar los servicios.

En este sentido, AWS ofrece varias regiones en Europa, habiendo desplegado recientemente una en España con tres zonas de disponibilidad.

3 Bastionado de acceso a la cuenta de AWS

En AWS se permite gestionar varios aspectos relativos al proceso de login de los usuarios. En este punto, es bastante recomendable tener dos puntos principalmente en cuenta:

Habilitar MFA para los usuarios

AWS permite varios métodos de autenticación por multifactor para loguearse en las cuentas:

• FIDO security Keys: si no te van mucho los MFA virtuales, tienes la opción de hacerte con uno de tipo hardware, como son los FIDO.
• Virtual authenticator apps: si, por el contrario, prefieres configurar un MFA virtual en tu móvil o dispositivo, aquí te dejamos algunas opciones:
  • Android: Twilio Authy Authenticator, Duo Mobile, LastPass Authenticator, Microsoft Authenticator, Google Authenticator, Symantec VIP.
  • iOS: Twilio Authy Authenticator, Duo Mobile, LastPass Authenticator, Microsoft Authenticator, Google Authenticator, Symantec VIP.
• TOTP hardware tokens: en la línea de los dispositivos hardware, tenemos estos proporcionados por el proveedor Thales que soportan el algoritmo TOTP. Estos tokens solo se pueden usar con cuentas de AWS.
• TOTP hardware tokens para las regiones GovCloud (US) de AWS: en caso de que necesites trabajar con recursos desplegados en las regiones AWS GovCloud (EEUU), también existen una serie de dispositivos hardware distribuidos por el proveedor Hypersecu. Estos dispositivos también están limitados a su uso en cuentas de AWS.

Gestionar la fortaleza y caducidad de las contraseñas

AWS permite gestionar ciertos aspectos de las contraseñas que usan los usuarios para entrar a la consola. Aquí te dejamos algunos puntos que deberías considerar para securizar las contraseñas de los usuarios que acceden a tu cuenta:

• Longitud mínima de contraseña: generalmente, las contraseñas de 14 caracteres se consideran seguras, pero puedes establecer una longitud de contraseña entre 6 y 128 caracteres según tus necesidades.
• Fortaleza: siempre es mejor que la contraseña cuente con varios caracteres que hagan más difícil su ruptura en caso de ataque. AWS te ofrece establecer ciertos parámetros para que la contraseña incluya letras mayúsculas y minúsculas, números y caracteres especiales.
• Expiración: es una buena práctica que las contraseñas caduquen cada 90 días (3 meses), aunque depende una vez más de tus necesidades. En AWS se puede establecer entre 1 y 1095 días de expiración de las contraseñas. Desde aproximadamente 15 días antes de la expiración de la contraseña, los usuarios recibirán un aviso al entrar a la consola, para que tengan la opción de cambiarla. A la hora de cambiar la contraseña, podemos encontrarnos dos casos:
  • El administrador debe ser el único que puede cambiar las contraseñas a los usuarios una vez expiren. En caso de que sea necesario es posible que el administrador sea el que gestione la actualización de las contraseñas de los usuarios cuando estas expiren. Esto añade un alto grado de gestión de la cuenta por parte del administrador, pero también asegura que las contraseñas de los usuarios sean seguras.
  • Los usuarios pueden cambiar sus propias contraseñas. En caso de que los propios usuarios cambien sus propias contraseñas cuando estas expiren, deberá quedar reflejado política de gestión de contraseñas de AWS. Esto descarga de tareas de gestión al administrador, pero deja en los usuarios la responsabilidad de poner contraseñas seguras.
• Prevenir la reutilización: para evitar que los usuarios puedan reusar antiguas contraseñas, es necesario declararlo explícitamente en la configuración de la política de contraseñas aplicada en AWS.

Gestión de usuarios y grupos

Un aspecto muy importante a tener en cuenta es la gestión de los usuarios y grupos que tienen acceso a tu cuenta. A continuación te dejamos varios puntos de revisión básicos para asegurar la gestión de los mismos:

• En la medida de lo posible usa las políticas administradas por AWS, tratando de evitar las políticas personalizadas. En caso de necesitar hacer políticas customizadas, apóyate en el validador de políticas de AWS IAM Access Analyzer.
• Cada vez que un usuario deje de tener acceso a la cuenta elimínalo lo antes posible y establece revisiones periódicas de los usuarios que tienen acceso a tu cuenta.
• Gestiona grupos, no usuarios. Te será más fácil administrar los permisos que se otorgan a cada grupo y evitarás problemas de otorgar más permisos de los adecuados.
• No uses el usuario “raíz” como administrador. Cuando abras una cuenta, crea un usuario administrador y administra tu cuenta con el mismo. El usuario “raíz” de una cuenta solo debería usarse para aquellas tareas que solo el usuario "raíz" tenga permisos para realizar.

4 Activar y revisar los logs de auditoría

AWS cuenta con la herramienta CloudTrail, que monitoriza y registra la actividad de la cuenta en toda la infraestructura de AWS. CloudTrail recoge todos los logs de actividad tanto de usuarios como de llamadas a la API. Es un servicio que proporciona un histórico de acciones sobre la plataforma de los últimos 90 días sin coste adicional.

Para hacer una revisión más exhaustiva de los logs a nivel de servicio o de instancia, puedes ayudarte del servicio CloudWatch Logs. Este servicio recoge por defecto los logs de los componentes de tu plataforma y los almacena con un periodo de retención indefinido, el cual puedes cambiar según tus necesidades.

5 Gestión del contenido de buckets en S3

Amazon S3 proporciona una manera segura y eficaz de almacenar datos con alta disponibilidad según el tipo de almacenamiento usado. Sin embargo, hay varias cosas a tener en cuenta para asegurar la integridad y mínima exposición de nuestros ficheros.

Administración de permisos de acceso a los buckets

Es de vital importancia que tengas en cuenta el contenido almacenado en tus buckets. Si los objetos almacenados en el mismo tienen datos sensibles, debes bloquear el acceso público al mismo.

En caso de que necesites aplicar otra serie de políticas de acceso a los ficheros almacenados en un bucket, puedes hacer una política de acceso asociada a tu bucket donde definas a un nivel más bajo en qué situaciones se puede acceder o no al contenido del mismo. Igualmente, es preferible basarse siempre en la premisa de que cuanto más restringido el acceso, mejor.

Ciclo de vida de los objetos almacenados

El tiempo de almacenamiento de los logs y datos almacenados en tus buckets dependerá de la naturaleza de los mismos. La última palabra en cuanto a los tiempos de retención de este tipo de datos la tendrá el responsable de los mismos. De manera general, se recomienda:

• Almacenar los logs que tengan responsabilidad legal durante tres meses en caliente.
• Una vez transcurridos los tres meses de retención de estos logs, pasarlos a un almacenamiento frío durante 5 años.

En este último punto, puede serte útil revisar las clases de almacenamiento de Amazon S3 para elegir una opción basándote en tus necesidades.

6 Desplegar toda la infraestructura como código

En el día a día, cuando el tiempo apremia y necesitamos las cosas cuanto antes, podemos caer en la tentación de desplegar los recursos a mano. Esta solución a corto plazo, puede derivar en un problema bastante crítico en el peor de los casos. A continuación enumeramos algunas de las ventajas de desplegar tu infraestructura como código y mantenerla en un repositorio:

• Si trabajas en equipo, ya sabes que cuanta más gente implicada más difícil es mantener el control de quién toca qué. Si tenemos toda la infraestructura como código, existen flujos para asegurar que los cambios que se aplican a la infraestructura los revisa el equipo y que tenemos la vuelta atrás que nos permite el versionado en caso de que las cosas no vayan como deberían.
• En caso de trabajar tú solo, te será más sencillo hacer rollback cuando apliques algo que no va como habías pensado. Solo tendrás que desplegar una versión anterior de tu propio código.
• Si hay alguna catástrofe que destruya tu infraestructura actual en parte o en su totalidad, el proceso de recuperación y redespliegue de la misma será muchísimo más sencillo y mucho más rápido. Lo mismo es aplicable al despliegue de recursos en otras zonas o regiones.
• Partiendo de esta base, puedes elaborar un Plan de Recuperación Ante Desastres (en inglés DRP) que es uno de los puntos que normalmente se evalúan cuando se revisan los puntos de cumplimiento de estándares de seguridad de un proyecto.

Como ves, son razones de peso para pensárselo dos veces antes de desplegar algún recurso a mano. AWS cuenta con el servicio CloudFormation para codificar toda la infraestructura en formato YAML o Json además de proporcionar plantillas de ejemplo para el despliegue de recursos.

Aunque CloudFormation es la herramienta oficial de AWS, Terraform se está posicionando a pasos agigantados como principal herramienta para el despliegue de infraestructura en la nube.

7 Cifrado de volúmenes asociados a instancias EC2

Los volúmenes (EBS), que generalmente se usan para el almacenamiento de datos en las instancias, son susceptibles de guardar datos sensibles ya sea a nivel de log o de información que contengan por sí mismos. AWS proporciona el cifrado de estos volúmenes usando su propio cifrado, cifrando los siguientes datos asociados al volumen:

• Datos en reposo dentro del volumen.
• Todos los datos que se mueven entre el volumen y la instancia.
• Todas las instantáneas creadas a partir del volumen.
• Todos los volúmenes creados a partir de estas instantáneas.

A lo anterior hay que añadir usando el cifrado de Amazon EBS, no es necesario mantener ni proteger nuestra propia infraestructura de administración de claves, ya que es Amazon quien se encarga de toda esta parte, mediante el uso de KMS keys que utilizan el cifrado de datos estándar de la industria AES-256.

8 Auditar y actualizar las instancias: AWS Inspector

No tenemos que olvidar que Amazon dispone la infraestructura, pero los encargados de mantenerla actualizada y a punto somos los administradores. AWS tiene una serie de herramientas para auditar y evaluar los activos desplegados en la plataforma siendo una de las herramientas más potentes Amazon Inspector.

Amazon Inspector se presenta como una herramienta para administración de vulnerabilidades y detección de exposiciones involuntarias a la red.

Una vez se pone en marcha, detecta todas las instancias EC2 en ejecución en la cuenta, las imágenes de Amazon ECR y las funciones de AWS Lambda, buscando en cada uno de los puntos anteriores vulnerabilidades para que los administradores puedan mitigarlas.

Amazon Inspector genera una puntuación de riesgo por cada hallazgo, haciendo que sea más sencillo dar prioridad a los hallazgos más críticos y vulnerables.

Así como Amazon Inspector detecta hallazgos, también admite la supresión de los mismos según las reglas que definamos. A esto hay que añadir, que una vez se soluciona una vulnerabilidad de las detectadas por Amazon Inspector, la herramienta lo detecta de manera automática y clasifica el hallazgo asociado como “Cerrado”.

9 Limitar el acceso público a servicios

Las instancias y servicios que despliegues en tu plataforma, deben tener accesos limitados y restringidos. A tal efecto, deberías revisar los security groups que están asociados a los mismos teniendo en cuenta las siguientes buenas prácticas:

• Cierra la exposición de los puertos 22 (SSH) o 3389 (RDP) permitiendo solo el acceso a rangos de IPs específicos.
• No abras rangos grandes de puertos. Es preferible hacer más de una regla indicando en intervalos más pequeños qué rangos de puertos están permitidos a los servicios que deban de poder acceder a los mismos.
• Considera crear network ACLs para añadir una capa extra de seguridad a tu VPC.
• Asegúrate de que solo los administradores gestionan los Security Groups de las instancias.
• Crea el mínimo de Security Groups que sea posible. Si puedes, usa cada Security Group para gestionar los accesos a grupos de máquinas similares.

10 Revisar de manera periódica las recomendaciones de seguridad

AWS cuenta con el servicio Trusted Advisor, que genera recomendaciones basadas en las buenas prácticas recomendadas por AWS, tiendo en cuenta los servicios desplegados en tu cuenta.

AWS Trusted Advisor muestra recomendaciones con relación a cinco puntos clave:

• Optimización de costes.
• Rendimiento.
• Seguridad.
• Tolerancia a errores.
• Cuotas de servicio.

Es recomendable revisar de manera periódica las recomendaciones de esta herramienta para revisar el estado de seguridad de los componentes de la cuenta y tomar acciones correctivas en caso de ser necesario.

Para la clasificación de hallazgos, AWS Trusted Advisor diferencia entre los siguientes grados de criticidad:

• Acción recomendada, si existe una acción correctiva a aplicar para el hallazgo detectado.
• Investigación recomendada, en caso de que exista algún hallazgo de categoría menos crítica, pero que convenga igualmente revisar.
• Elementos en los que no se han detectado problemas, aquellos elementos en los que tras el escaneo de la plataforma no se han detectado problemas a corregir.
• Comprobaciones con elementos excluidos, en caso de que manualmente se excluya del escaneo algún tipo de servicio o casuística por ser algo controlado, se recogerá en esta categoría.

Entre otros aspectos, Trusted Advisor recoge información de seguridad de los siguientes servicios entre otros:

• Grupos de seguridad: puertos específicos con acceso sin restricciones.
• Grupos de seguridad: acceso sin restricciones.
• Uso de AWS IAM.
• Permiso para buckets de Amazon S3.
• Riesgo de acceso en grupos de seguridad de Amazon RDS.
• Registros de AWS CloudTrail.
• Grupos de seguridad de ELB
• Certificados SSL de Amazon CloudFront en el servidor de origen.
• Instantáneas públicas de Amazon EBS.
• Instantáneas públicas de Amazon RDS.

Conclusiones

Si has llegado hasta aquí, ¡enhorabuena! Ahora ya sabes donde poner foco para hacer tu arquitectura más segura, contribuyendo a la tranquilidad de todos los implicados en la administración de la misma. Como verás, en este top hemos recogido solo algunos de los aspectos que más se repiten cuando hacemos evaluaciones de seguridad de nuestros proyectos, pero, evidentemente, puedes llevar la seguridad de tu infraestructura hasta el infinito (¡y más allá!).

Referencias

• Estrategias de backup de AWS.
• AWS Trusted Advisor.
• AWS Inspector.
• AWS en España: La región de España ya está disponible.
• ¿Por qué Terraform ha plantado cara a Cloudformation?
• Terraform, la navaja suiza para dominar todos los IaaS.