Cómo prevenir una fuga de datos de AWS Cloud Bucket


Los paquetes de AWS mal configurados han dado lugar a enormes violaciones de datos. Seguir un puñado de prácticas te ayudará a evitar que te conviertas en la próxima noticia.

(imagen de conceptualmotion, a través de Adobe Stock)

(imagen de conceptualmotion, a través de Adobe Stock)

Cuando se trata de servicios en la nube pública, está AWS de Amazon y luego están todos los demás. Con un estimado 39% de cuota de mercado, es un raro profesional de ciberseguridad que no se encontrará con AWS en algún momento de su carrera. Y no hay duda de que la protección de datos en AWS comienza con la comprensión de la seguridad del depósito.

Por la definición más straightforward, un cubo es un lugar para poner cosas. Puede pensar en un depósito como un directorio o una carpeta (según su punto de referencia), pero hay dos cosas clave que debe saber sobre cualquier depósito que cree. Primero, a diferencia de muchos recursos en la nube, existe un depósito algun lado – usted especifica la región geográfica donde se ubicará su cubo. Esto es importante si las regulaciones y jurisdicciones particulares son importantes para usted.

A continuación, hay un montón de formas de meter y sacar cosas de tu cubo. Esto hace que los depósitos sean increíblemente útiles, y también presenta los riesgos de seguridad más obvios para el uso del depósito.

Afortunadamente, desde Amazon y una serie de otras fuentes dispersas por World-wide-web, hay un puñado de prácticas cruciales que, si se siguen, evitarán que sus datos se salgan de su cubo y caigan en toda la world wide web.

El cuento precautorio
Catástrofes recientes de fuga de datos en la nube como la violación de Money One muestran que tanto los usuarios de la nube como los proveedores de servicios en la nube como AWS tienen roles que desempeñar en su propia seguridad.

Funds Just one «nos da un muy buen ejemplo de lo peligroso que puede ser un entorno de nube mal configurado», dijo John Burke, ingeniero senior de seguridad de TI para Iberia Lender, en un reciente seminario world wide web de Darkish Looking through. «Han sido un gran ejemplo de una empresa que está en la nube primero en todo lo que hacen … Así que son un buen ejemplo de lo que puedes hacer en la nube, pero también son un buen ejemplo de lo que hacen puede suceder si las cosas salen mal … La conclusión es que realmente hay que saber cómo está configurado todo esto para protegerlo correctamente «.

«El hecho de que las configuraciones incorrectas sean un problema del cliente no significa que los proveedores (del proveedor de servicios en la nube) no puedan desempeñar un papel allí», dice John Yeoh, vicepresidente de investigación de Cloud Safety Alliance. «¿Se están asegurando de que tengamos configuraciones predeterminadas y seguras? ¿Nos están dando notificaciones? Las campanas deberían sonar si tenemos información confidencial en una carpeta que está expuesta públicamente».

Afortunadamente, Amazon y otros proveedores de plataformas en la nube ahora están haciendo algunas de las cosas que sugiere Yeoh. Esto es lo que necesita saber sobre las oportunidades y las dificultades.

Público Significa Público
Si configura su primer bucket de Amazon y simplemente usa la configuración predeterminada, creará un lugar razonablemente seguro para dejar sus datos. De manera predeterminada, un depósito de S3 es privado: para permitir que cualquiera (o todos) accedan a sus datos, debe otorgarles explícitamente permiso para hacerlo. (Esto no siempre fue el valor predeterminado de AWS, pero fue una mejora realizada por la empresa por motivos de seguridad).

La cuestión es que, si desea otorgar acceso a un individuo, debe conocer una pieza clave de datos sobre ellos: debe conocer su ID de usuario dentro del entorno de AWS. «Bob de contabilidad» rara vez es una identificación de usuario válida, por lo que muchos usuarios simplemente configuran el permiso de acceso como «público» y esperan que ninguna persona (o proceso) mala encuentre y acceda a sus datos. La mayoría de nosotros habremos escuchado que la esperanza no es un plan. Es un maldita lista de handle de acceso deficiente (ACL) también.

Hay niveles de acceso «público» que pueden otorgarse, desde simples privilegios de lectura hasta la administración completa del depósito. Es una escala móvil de maldad desde una perspectiva de seguridad, pero incluso en su forma más básica, la lección es bastante clara: a menos que realmente quiera que alguien con un dispositivo informático pueda ver al menos sus datos, no configure el acceder al «público», y no permitir que nadie más lo haga tampoco.

«La autenticación moderna no es un straightforward cambio para habilitar», advirtió Burke. «Por lo tanto, la configuración debe hacerse correctamente o los actores malintencionados van a encontrar una manera de evitarlo». También recomendó habilitar la autenticación multifactor para instancias y aplicaciones en la nube donde sea que esté disponible.

Políticas, Políticas
Existen políticas que gobiernan el comportamiento humano y políticas que gobiernan el comportamiento del cubo. Comencemos mirando el primero y luego analicemos cómo pueden tener un impacto en el segundo.

Una de las grandes virtudes de AWS es la facilidad con la que se pueden crear y configurar depósitos y activos. Esta es una de sus mayores vulnerabilidades, también, porque las personas sin capacitación en seguridad (y poca conciencia de seguridad) pueden crear, configurar y administrar depósitos junto con los datos almacenados en ellos. Esos individuos necesitan políticas que los guíen hacia costas digitales seguras.

Una de las políticas más importantes es esta: lo público es público, lo privado es privado y nunca deben reunirse los dos. En la práctica, esto significa que cualquier objeto (datos) que se hará público debe estar en un depósito público. Cualquier objeto en un cubo privado debería ser privado. Pueden surgir problemas enormes cuando lo privado y lo público se mezclan y mezclan porque es muy fácil encontrar el objeto público accidental en esas circunstancias.

El siguiente paso debe ser una política sobre quién puede configurar cubos y colocar objetos en esos cubos. La clave aquí es que a las personas solo se les debe permitir pasar a un depósito S3 cuyos datos son responsables. No es realmente que la seguridad deba tener a un individuo fácil a quien culpar si algo sale mal, sino que cualquier persona que cree y llene un cubo debe sentir un sentido de responsabilidad sobre los datos y su destino.

Finalmente, debe haber revisiones basadas en políticas del etiquetado público / privado de objetos y cubos de forma standard. Ha habido demasiadas historias de cubos configurados como «públicos» para el desarrollo de aplicaciones world-wide-web o por razones de acceso de socios externos, que luego se dejaron en esa configuración después de que finalizó el proyecto, para sentirse cómodos con la concept de dejar una configuración en un estado no examinado. Las revisiones de estado obligatorias al closing de los proyectos y encuentros, y sobre una foundation de calendario typical, contribuirán en gran medida a limitar el daño del estado público no intencional.

La configuración importa
Y luego están las preguntas de cómo se configuran los cubos individuales y sus objetos. Comienza con cómo se configura el acceso y continúa desde allí. Dependiendo de las necesidades de su aplicación y organización, el acceso puede controlarse a través de políticas de depósito, gestión de identidad y acceso (políticas IAM) y ACL. Cada uno tiene su lugar, pero el objetivo debe ser simplificar la configuración tanto como sea posible. Mantenga públicos y privados por separado (ver arriba), use ACL cuando las poblaciones pequeñas necesiten acceso y use grupos siempre que sea posible. Esto ayudará a mantener la configuración de acceso lo más complicada posible.

Cuando tenga acceso resuelto, cifre el contenido del cubo. AWS ofrece tanto su propio cifrado como un sistema para administrar claves de cifrado externas. Cualquiera que elija, asegúrese de que una infracción de acceso no devolverá nada más que datos inútiles al atacante.

Y como con toda la información de datos y aplicaciones, mantenga un registro de cambios y acceso. AWS ofrece ambos tipos de registro a través de su servicio CloudTrail. Si bien un registro de transacciones completo podría volverse difícil de manejar rápidamente para un gran depósito público, los registros de cambios son imprescindibles para todos los depósitos y los registros de transacciones son críticos para los datos confidenciales almacenados en los depósitos. Ya sea que use un servicio de AWS como CloudWatch o un servicio externo para analizar los registros, tener la capacidad de rastrear cambios y actividades contribuirá en gran medida a limitar el daño que pueden causar los desafíos de configuración.

«Hay algunas compañías nuevas que están ayudando a las organizaciones a asegurarse de que sus entornos de nube y AWS estén protegidos y configurados correctamente», dijo Burke. También recomienda una mirada cercana a los agentes de seguridad de acceso a la nube (CASB) para obtener ayuda. «Los CASB lo ayudarán a usted y al equipo de seguridad a detectar cosas como ataques de rociado de contraseña, actividad anómala, intentos de inicio de sesión de países extranjeros u hostiles. También pueden ayudar a identificar otras aplicaciones en la nube, por lo que si sus empleados están usando aplicaciones en la nube que pueden o no ser sancionado … puedes usar un CASB para identificarlos «.

Contenido relacionado:

Curtis Franklin Jr. es editor sénior en Dark Studying. En este puesto, se centra en la cobertura de productos y tecnología para la publicación. Además, trabaja en programación de audio y video clip para Dim Studying y contribuye a actividades en Interop ITX, Black Hat, INsecurity y … Ver biografía completa

Más concepts





Enlace a la noticia primary