Skip to main content

Comprender la seguridad y el cumplimiento de Amazon S3 en AWS

Escrito por

10 de mayo de 2019

0 minutos de lectura

Si tu organización usa Amazon Web Services (AWS) para la computación en la nube, es probable que Amazon S3, o Amazon Simple Storage Service, tenga mucho uso. Este servicio de almacenamiento de objetos fue uno de los primeros servicios en la nube que ofreció AWS (¡allá por 2006!) y su facilidad de uso, confiabilidad y escalabilidad lo han hecho sumamente popular.

Sin embargo, una configuración deficiente de tus recursos de S3 puede provocar incidentes graves de seguridad y cumplimiento. Las filtraciones de datos de alto perfil causadas por configuraciones incorrectas de S3 siguen apareciendo en las noticias, y es probable que haya más. Basta con una política de acceso o una configuración de cifrado incorrecta en un “bucket” de S3 para que los datos confidenciales terminen en manos de actores maliciosos.

Independientemente de cómo se redacte el titular, en todos estos casos la culpa fue del cliente de la nube, no de AWS. AWS tiene un historial impecable en el cumplimiento de su parte del Modelo de responsabilidad compartida para la seguridad en la nube, pero no puede evitar que te dispares en el pie con la configuración de S3 y que tu organización termine en las noticias.

Es probable que el cumplimiento normativo rija tu uso de Amazon S3

Si tu organización debe cumplir con normativas como HIPAA, PCI, SOC 2, GDPR o NIST 800-53, ten en cuenta que todas incluyen controles que rigen el uso y la configuración de S3 (y de muchos otros servicios de AWS que probablemente use tu organización). Si ninguna de estas normativas se aplica a tu organización o a tus cargas de trabajo, considera seriamente adoptar el AWS CIS Benchmark para guiar el uso seguro de AWS.

Mantén el control de acceso a tus buckets de Amazon S3

Muchas filtraciones de datos relacionadas con S3 se deben a políticas de acceso mal configuradas. Cuando se crea un bucket de S3, la política de acceso predeterminada es “privada”, pero esta puede cambiar, y suele cambiar, durante la vida útil del recurso. Los entornos en la nube cambian con el tiempo a medida que los desarrolladores actualizan aplicaciones e infraestructura y agregan servicios nuevos. Durante estas actualizaciones, las políticas de acceso pueden debilitarse o deshabilitarse sin querer.

Audita tus recursos de S3 y sus políticas de acceso para asegurarte de que estén configurados de forma segura, y registra cualquier cambio en estas configuraciones con CloudTrail. Para los buckets de S3 que contienen datos confidenciales, considera un producto como Fugue, que detecta (y puede corregir) cualquier “desviación” respecto de la configuración de referencia segura que estableciste, sin necesidad de código ni scripts adicionales.

El AWS CIS Benchmark ofrece un buen ejemplo de marco de cumplimiento que rige la configuración y el uso de S3. El control CIS 2.6 exige habilitar el registro de acceso a los buckets. El control 3.8 exige habilitar un filtro de métricas y una alarma para todos los cambios en las políticas de los buckets. Por último, debes asegurarte de que tus buckets de S3 con datos confidenciales no estén abiertos al público. En su lugar, crea una política de AWS IAM que permita el acceso al bucket solo a usuarios autorizados.

Usa el cifrado para proteger tus datos de Amazon S3

Es obligatorio mantener políticas de acceso seguras para tus recursos de Amazon S3, pero también debes asegurarte de que el cifrado esté siempre habilitado para impedir que alguien con acceso no autorizado pueda leer los datos. Una vez más, deberás auditar tus recursos de S3 para comprobar que el cifrado esté habilitado y usar registros para hacer seguimiento de cualquier cambio en esos recursos, incluidos los casos en que se deshabilite el cifrado.

Es probable que el marco de cumplimiento de tu organización también se aplique en este caso. Dos ejemplos son NIST 800-53 SC-13: Protección criptográfica, que exige que una organización implemente el cifrado cuando corresponda, y SOC 2 CC 6.1, que exige usar el cifrado como complemento de otras medidas para proteger los datos en reposo.

Entonces, ¡eres responsable de la seguridad y el cumplimiento de AWS!

Aunque cada organización es diferente, la responsabilidad por la seguridad de los datos críticos en AWS suele recaer en un ingeniero de seguridad en la nube, un ingeniero de DevOps, un analista de cumplimiento o un arquitecto de nube. A veces, algunas de estas personas, o todas, comparten la responsabilidad de la seguridad en la nube, por lo que la colaboración eficaz es imprescindible (a esto se le suele llamar “DevSecOps”).

Sin importar cuál sea tu función o cargo, si eres responsable de la seguridad y el cumplimiento de tu entorno de AWS, una parte importante de tu trabajo consiste en asegurarte de que los recursos críticos de S3 estén bien configurados y se mantengan así durante toda su vida útil.

Tarea n.º 1: Certifica que tus configuraciones de S3 cumplan con las políticas

Si aún no lo has hecho, debes certificar que la configuración de los recursos de S3 existentes en tu entorno de AWS cumpla con las políticas de seguridad y cumplimiento aplicables. Esto suele implicar una auditoría para determinar cómo están configurados tus recursos de S3, ya sea de forma manual con la consola de AWS o mediante una herramienta de auditoría.

Debes auditar todos tus entornos de AWS con regularidad y frecuencia. En el caso de los recursos críticos, conviene auditarlos de forma continua con una herramienta que los analice, valide su configuración según las políticas y genere informes sobre las infracciones de cumplimiento y tu postura general de seguridad. Asegúrate de poder detectar cualquier “desviación” respecto de la configuración original de S3 para determinar si el cambio infringe alguna política.

También tendrás que trabajar en estrecha colaboración con tus equipos de aplicaciones y DevOps para certificar que sus actividades (por ejemplo, implementar entornos nuevos o actualizar los existentes) cumplan con las políticas pertinentes. Como este proceso manual suele llevar mucho tiempo y es propenso a errores, tu equipo debería buscar formas de “integrar la seguridad desde el inicio” mediante la incorporación de verificaciones de políticas en etapas más tempranas del ciclo de vida de desarrollo de software (SLDC), cuando es más fácil, rápido y económico realizar correcciones.

Tarea n.º 2: Identifica y corrige los eventos de configuración incorrecta de Amazon S3

Muy bien, ya certificaste que tus recursos de AWS S3 cumplen con las políticas y están configurados de forma segura. ¡Excelente! Ahora viene la parte difícil: asegurarte de que sigan así.

La desviación de configuración en los recursos de infraestructura en la nube es un problema generalizado y, a menudo, riesgoso. Las configuraciones de los buckets de S3 se pueden modificar desde la consola de AWS y mediante una interfaz de programación de aplicaciones (API), que puede usarse con diversas herramientas de automatización adicionales. Es probable que descubras que las configuraciones de S3 (junto con las de otros servicios de AWS) cambian con frecuencia, a veces dejando de cumplir con las normas y creando vulnerabilidades de seguridad.

Necesitas una herramienta que analice tu entorno de AWS y te alerte sobre infracciones en la configuración de S3. Debes poder ignorar las alertas de los buckets de S3 que deban tener acceso público (como los que alojan sitios web estáticos) y, al mismo tiempo, marcar las configuraciones incorrectas de los que deban ser privados y estar cifrados. Las alertas deben ofrecer suficiente información sobre la configuración incorrecta para facilitar su corrección manual.

En el caso de los buckets críticos de S3 que contienen datos confidenciales, es imprescindible dejar atrás los procesos manuales y corregir automáticamente los eventos de configuración incorrecta cuando ocurran. Ningún proceso manual puede reducir el tiempo medio de corrección (MTTR) a un nivel seguro ante eventos críticos de configuración incorrecta, porque las amenazas que buscan explotar vulnerabilidades de la infraestructura en la nube, como los buckets de S3 mal configurados, también están automatizadas. Con el tiempo, descubrirás que la corrección automatizada ahorra mucho tiempo y que puedes aplicarla a más recursos de la nube.

Corrección automática de configuraciones incorrectas en AWS

Un método eficiente e integral para corregir automáticamente las configuraciones incorrectas en AWS es establecer una configuración de referencia que permita que tu infraestructura crítica de AWS se repare por sí sola. Con este enfoque, defines una configuración de referencia de infraestructura confiable que cumple con las políticas. Una vez establecida, detecta y revisa cualquier desviación respecto de esa configuración. En el caso de los recursos críticos, debes revertir automáticamente las desviaciones para restaurar la configuración de referencia establecida. Este método elimina la necesidad de predecir qué podría salir mal y crear listas de bloqueo, y ofrece un mecanismo para integrar la seguridad y el cumplimiento desde el inicio.

Fugue permite contar con una infraestructura en la nube que se repara por sí sola. Mira nuestro webinar para obtener más información.

Tarea n.º 3: Genera informes sobre los eventos de configuración incorrecta de AWS S3

Además de exigir informes periódicos de auditoría de cumplimiento y seguridad, la mayoría de las organizaciones solicita un informe por cada evento de configuración incorrecta que afecte a un recurso crítico como Amazon S3. Por lo general, estos informes deben incluir la siguiente información:

  • ¿Qué recurso se vio afectado (y en qué entorno)?

  • ¿Qué configuración cambió?

  • ¿Cuándo ocurrió la configuración incorrecta?

  • ¿Quién fue responsable de la configuración incorrecta?

  • ¿Qué política, si la hubo, se infringió con esta configuración incorrecta?

  • ¿Cuándo se detectó la configuración incorrecta?

  • ¿Cuándo se corrigió (y verificó) la configuración incorrecta?

  • ¿Quién corrigió la configuración incorrecta (o cómo se corrigió)?

  • ¿Qué se está haciendo para evitar que estos eventos de configuración incorrecta vuelvan a ocurrir?

Tendrás que recopilar muchos datos de registros para elaborar un informe de este tipo, así que la automatización también puede ayudar en este caso. En cuanto al último requisito, la corrección automatizada es la única manera de evitar que estos eventos de configuración incorrecta vuelvan a ocurrir.

Considera medir el tiempo medio de corrección (MTTR) de las configuraciones incorrectas en recursos críticos de la nube para hacer seguimiento de la resiliencia de tus medidas de seguridad en la nube. Un MTTR de muchas horas o días debe considerarse un riesgo inaceptable, teniendo en cuenta que las amenazas automatizadas buscan explotar este tipo de configuraciones incorrectas.

Una cosa más…

Si operas a gran escala en la nube y te importa la seguridad y el cumplimiento de tus entornos de infraestructura en la nube, Fugue puede ayudarte. Con Fugue, puedes:

  1. Validar el cumplimiento de tus entornos en la nube con diversos marcos de políticas, como HIPAA, PCI, SOC 2, NIST 800-53, ISO 27001 y GDPR.

  2. Obtener visibilidad completa de tus entornos en la nube y sus configuraciones mediante la creación de configuraciones de referencia de infraestructura en la nube y la detección de desviaciones.

  3. Protegerte contra las configuraciones incorrectas de la infraestructura en la nube, los incidentes de seguridad y las infracciones de cumplimiento con una infraestructura que se repara por sí sola.

  4. Integrar la seguridad y el cumplimiento de la infraestructura en la nube desde el inicio con la integración de CI/CD para ayudar a tus desarrolladores a trabajar rápido y de forma segura.

  5. Obtener visibilidad e informes continuos sobre el cumplimiento en toda la infraestructura de nube de tu empresa.

Seguridad de IaC diseñada para desarrolladores

Snyk protege tu infraestructura como código desde el ciclo de vida del desarrollo de software hasta el runtime en la nube con un motor unificado de políticas como código, para que todos los equipos puedan desarrollar, implementar y operar de forma segura.

Leer más

feature insights context
Blog

Los ataques autónomos ya están aquí. La defensa debe estar a su altura.

Los atacantes autónomos están reduciendo el tiempo disponible para defenderse. Descubre cómo el descubrimiento, la corrección, la validación y la prevención continuos pueden ayudar a los equipos de seguridad a seguirles el ritmo.

illustration hero ai
Blog

El huracán de la IA ha llegado

La IA está acelerando por igual la creación de software y los ciberataques. Los líderes deben proteger los agentes y el código desde el inicio, aplicar controles en tiempo de ejecución y validar las defensas de forma independiente.

feature insights context
Blog

¿La prevención es, en esencia, un problema ya resuelto?

La prevención en el código generado por agentes está resuelta desde el punto de vista arquitectónico, pero elegir controles que protejan la seguridad sin ralentizar el desarrollo sigue siendo el desafío.