Cómo evitar los 11 errores de configuración más comunes de AWS

Siempre que vayamos a configurar una nueva infraestructura en la nube de AWS, o a modificar una configuración existente para conceder o retirar permisos, debemos tener en cuenta la seguridad.

Según el modelo de responsabilidad compartida de AWS, el usuario es el responsable de la seguridad "en" la nube, mientras que AWS lo es de la seguridad "de" la nube. En resumidas cuentas, el cliente es el responsable de aquellos cambios realizados que supongan la exposición de sus datos al público.

En este artículo, analizaremos los conjuntos de errores de configuración más comunes en los servicios más habituales, y te guiaremos para que puedas preservar la seguridad y evitar posibles brechas cuando modifiques tu infraestructura.

Los cuatro errores de configuración más frecuentes de S3

1. Buckets públicos u objetos públicos dentro de buckets

Cada vez que necesites utilizar S3 para el almacenamiento de sitios web o como opción de alojamiento de sitios estáticos, probablemente tendrás que hacer público parte de su contenido, si no todo. Se trata de un proceso sencillo, pero si se hace de forma incorrecta, puede poner en riesgo todos los datos. Como bien es sabido, las brechas de este tipo han tenido consecuencias de gran alcance en los últimos años. Si creas un nuevo bucket y quieres hacerlo público, dispones de varias opciones.

Como observamos en la siguiente captura de pantalla, puedes permitir el acceso público a buckets y objetos a través de listas de control de acceso (ACL) nuevas, de cualquier ACL, de directivas de punto de acceso nuevas o de cualquier directiva de punto de acceso:

Debes prestar atención a la hora de escoger la mejor solución para tu aplicación. Piensa bien qué añadirás a tu bucket, ya que será público a menos que lo cambies, lo que podría exponer datos confidenciales.

2. No utilizar logs de acceso

El registro de accesos de S3 es una opción que puede activarse fácilmente. Basta con que vayas a la pestaña Propiedades del bucket y allí encontrarás la opción:

Este ajuste está desactivado por defecto, pero puedes activarlo haciendo clic en el botón Editar y asignando un bucket de destino en el que almacenar los registros.

Al activar esta opción, se registra cada solicitud de acceso al bucket. Estos logs no suponen ningún coste adicional, por lo que pueden ser realmente útiles en determinadas situaciones e incluso ayudar a explicar una factura de S3 a un cliente. Aun así, ten en cuenta que sí se te cobrará por el almacenamiento de esos logs en el bucket de destino; los precios de S3 se aplicarán como de costumbre. Estos logs pueden llegar a acumularse rápidamente, por lo que tal vez sea recomendable configurar un mecanismo de eliminación.

Además, es importante que no habilites el registro de acceso en tu bucket de destino ya que, de hacerlo, causarás un bucle infinito y tu factura podría incrementarse notablemente.

3. No utilizar control de versiones + ciclo de vida de S3

Si habilitas el control de versiones en buckets, puedes almacenar varias instancias de un objeto dentro del mismo bucket. El aspecto más útil de esta función es que te permite recuperarte de un mal funcionamiento de la aplicación o de cualquier acción involuntaria del usuario.

Puedes habilitarlo en la consola S3, en la pestaña Propiedades:

Activarlo es muy sencillo, pero debes acompañarlo de la eliminación mediante autenticación multifactor (MFA) para evitar la eliminación involuntaria de instancias anteriores de objetos.

El inconveniente de esta función es que, para cada versión de un objeto, se almacena el objeto completo, no solo la diferencia entre ese objeto y otras versiones del mismo. Para resolverlo, utiliza las reglas de configuración del ciclo de vida de S3, que te permiten determinar que los objetos no actuales se eliminen solos después de un período de tiempo determinado. También puedes transferirlos a servicios de almacenamiento más asequibles, como S3 Glacier Flexible Retrieval, y eliminarlos cuando sean reemplazados por su versión más reciente.

4. No cifrar información crítica

Si almacenas datos confidenciales, recuerda cifrarlos. Puedes hacerlo del lado del servidor, a través del propio S3, o del lado del cliente, por ti mismo. Si decides hacerlo a través del servidor, el proceso será mucho más sencillo, ya que Amazon se encarga del cifrado, el almacenamiento y el descifrado cuando el objeto se descarga o copia. Puedes activar esta opción en la pestaña Propiedades, haciendo clic en el botón Editar en la sección Cifrado predeterminado:

Podrás elegir las claves que quieres utilizar para el cifrado. Las claves SSE-S3 están gestionadas por el S3, por lo que no tienes que hacer nada. Las claves SSE-KMS se gestionan a través de KMS y requieren algo más de configuración.

Si tus datos son extremadamente confidenciales, quizás estés contemplando la posibilidad de cifrarlos tú mismo antes de almacenarlos. Aunque es una opción, este enfoque es algo arriesgado, ya que si pierdes las claves, no podrás recuperar ni descifrar tus objetos. Este proceso es extenso y requiere configuración, por lo que debes consultar la documentación de AWS al respecto.

Los tres errores de configuración más frecuentes de EC2

1. Instantáneas públicas o instantáneas compartidas no cifradas

Por defecto, las instantáneas que tomas de tus instancias son privadas, pero hay dos escenarios en los que esto podría cambiar.

El primero es cuando alguien con suficientes permisos (incluido un servicio como AWS Lambda) cambia la configuración a pública, haciendo que el estado anterior de todos tus datos esté disponible públicamente, lo que puede tener consecuencias desastrosas. El segundo escenario se da cuando necesitas compartir una instantánea no cifrada. En ese caso, el destinatario de la instantánea podría crear volúmenes a partir de la misma e iniciar una instancia con todos tus datos.

Sea cual sea el caso, debes cifrar tus instantáneas, lo que significa cifrar las instancias en el momento de su creación o crear una instantánea cifrada y, a continuación, un nuevo volumen raíz a partir de esa instantánea.

2. Instancias de backend en subredes públicas

Si tienes instancias que no requieren conectividad a Internet, como bases de datos o API simples, debes mantenerlas en subredes privadas. La conexión a Internet genera una amenaza constante que podría materializarse en cualquier momento, ya que nunca se sabe quién tiene acceso a la IP de tu instancia.

Para que una instancia se aloje en una subred privada, simplemente debes eliminar la asignación automática de las direcciones IPv4 e IPv6. Para ello, en la consola de VPC, ve a la pestaña Subred, escoge la subred de la instancia y desactiva esta opción:

3. AMI publicas o no cifradas

Si necesitas crear una imagen de máquina de Amazon (AMI), es posible que quieras compartirla con otra cuenta. En ese caso, deberás adoptar una serie de medidas para evitar brechas de seguridad.

En primer lugar, debes cifrar los volúmenes para que las AMI que incluyan volúmenes estén cifrada por defecto y no revelen ningún dato. En segundo lugar, debes ser prudente a la hora de conceder permisos a EC2, ya que esto podría incluir la configuración de la disponibilidad de las AMI como públicas, lo cual representa un riesgo si hay un actor malicioso dentro de la empresa o si algún servicio, como AWS Lambda, se ve comprometido.

Por último, recuerda que siempre que compartas AMI, debes hacerlo a través de la consola para evitar contratiempos que puedan exponerlas al público:

Los cuatro errores de configuración más frecuentes de IAM

1. Ausencia de autenticación multifactor y falta de rotación de claves

La autenticación multifactor (MFA) es vital y debería ser obligatoria para todas las entidades que se añadan a la gestión de identidades y accesos (IAM), especialmente los usuarios. Gracias a este mecanismo, se puede mitigar el robo de claves y se elimina una gran superficie de ataque. Para exigir este tipo de autenticación, ve a la pestaña Credenciales de seguridad en el usuario para el que quieres habilitarla y selecciónala:

También debes implementar la rotación de las claves de acceso para toda la cuenta. Aunque AWS no dispone de una forma automática de hacerlo, y sugiere que se configure manualmente, existen herramientas de código abierto que pueden automatizar y simplificar el proceso. Esto solo se aplica a los usuarios de IAM y no a los roles, ya que las claves de los roles expiran tras un tiempo predeterminado.

2. No utilizar roles

A través de la gestión de identidades y accesos (IAM), puedas dar permisos a los usuarios asociándoles directamente las directivas relevantes. Sin embargo, seguir este proceso constituye una mala práctica en infraestructuras grandes y críticas, ya que podrías estar dando permisos incorrectos a las personas equivocadas. Además, si olvidas eliminar los permisos, se quedan ahí para siempre.

Si recurres a los roles como método preferido para la concesión de permisos, las claves caducarán automáticamente, lo que hace que lidiar con el problema del robo de claves o los permisos excesivos sea mucho más manejable. Si muchos usuarios comparten privilegios comunes, puedes optar por utilizar grupos, pero procura no asociar directivas directamente a los usuarios.

3. Conceder demasiados privilegios

A la hora de conceder permisos, debes hacerlo de acuerdo con el principio del mínimo de privilegios. Si un usuario o un rol necesita acceso a un servicio, debes conocer las acciones específicas que tiene que realizar para hacer su trabajo y asignar esos privilegios a la entidad de IAM. Evita optar por el camino fácil y concederle acceso al servicio en su conjunto. Como hemos visto, hay conjuntos de permisos sencillos pero muy poderosos que, si se conceden, pueden acabar teniendo consecuencias desastrosas.

4. Conservar credenciales sin usar

En todo momento debes llevar un registro de las claves, usuarios activos y roles en toda la infraestructura. Si algún usuario está inactivo por cualquier motivo (por ejemplo, vacaciones, despido, etc.), puedes desactivar sus claves durante el tiempo necesario y eliminarlas si ha pasado un tiempo determinado.

Al hacerlo, no habrá claves con permisos "vagando" por tu entorno que puedan generarte un problema. Siempre es preferible tener que recrear un usuario que estar expuesto a posibles ataques internos.

Resumen

Modificar tu infraestructura puede salir mal por múltiples motivos. Por ello, es necesario hacerlo de forma cuidadosa para evitar poner en peligro los datos. Puedes mitigar el riesgo haciendo cambios para evitar los errores de configuración que acabamos de mencionar de forma gradual y consciente.

Otra opción es recurrir a CrowdStrike para obtener el nivel de seguridad que necesitas. AWS ha reconocido nuestra labor por haber obtenido la distinción de Detección y corrección de amenazas. CrowdStrike Falcon^® for AWS puede ayudarte a analizar y mitigar todos los problemas que hemos mencionado aquí y muchos más.