Los clientes de Snowflake, un servicio estadounidense en la nube que ofrece almacenamiento y análisis de datos, sufrieron recientemente un violación masiva y pública de datos que, según algunos, podría ser la mayor de la historia. La filtración afectó a casi 170 organizaciones, entre ellas "casi todos" los clientes de la operadora de telefonía móvil AT&T, además de clientes de otras empresas como Ticketmaster y LendingTree.
Pero la brecha no es sólo devastadora para los clientes y empresas afectados. También es un excelente ejemplo de lo que puede ocurrir cuando se rompe el modelo de responsabilidad compartida en la nube. Veamos cómo.
Índice de contenidos
Transferencia segura de archivos en la nube
MASV es un servicio de transferencia segura de archivos con certificación ISO 27001/SOC 2 y verificación TPN (estado Gold Shield).
📣El modelo de responsabilidad compartida suele establecer una delimitación clara de las responsabilidades en materia de protección de datos y gestión de vulnerabilidades entre el cliente, por un lado, y el proveedor, por otro.
La responsabilidad del vendedor combinada con la responsabilidad del cliente. Suena sencillo, ¿verdad?
Sin embargo, el problema surge cuando los usuarios dan por sentado que su proveedor de nube se hará cargo de la seguridad de los datos, algo que en realidad no es responsabilidad del proveedor, o cuando no aprovechan las herramientas que éste ofrece. (como la aplicación de la autenticación multifactor (MFA), por ejemplo).
Cuando esto ocurre, el modelo de responsabilidad compartida en materia de seguridad se rompe. Y las probabilidades de que se produzca una violación de datos aumentan muchísimo.
La filtración de datos de AT&T: ¿Cómo ocurrió?
Esta filtración de datos parece ser el resultado directo de este tipo de ruptura del modelo de responsabilidad compartida en la nube.
De acuerdo con este modelo, y al igual que muchos servicios en la nube, Snowflake ha proporcionado tradicionalmente herramientas y capacidades de ciberseguridad, pero ha permitido a los usuarios gestionar su postura de seguridad por su cuenta. Por ejemplo, Snowflake proporcionaba herramientas de gestión de acceso como MFA, pero antes no exigía a sus usuarios que las aplicaran.
![La filtración de datos de Snowflake_ ¿Cómo ocurrió? Imagen de marcador de posición](https://massive.io/wp-content/uploads/2024/07/The-Snowflake-Data-Breach_-How-Did-It-Happen_.png)
FUENTE: Veredicto.es
Un breve declaración publicado por el proveedor de servicios en la nube reconoció que la brecha fue una "campaña dirigida a usuarios con autenticación de factor único (SFA)", añadiendo que las contraseñas de las cuentas Snowflake con SFA fueron "compradas previamente u obtenidas utilizando malware de robo de información."
Traducción: El malware de registro de pulsaciones de teclado (o similar) recopilaba las contraseñas de los usuarios, que luego se utilizaban para entrar en las cuentas inseguras de Snowflake y (como era de esperar) causar estragos en los datos que contenían. Pero lo triste es que si los administradores de las cuentas de Snowflake infectadas hubieran aplicado el control de acceso MFA entre sus usuarios -un requisito relativamente sencillo-, es casi seguro que esta infracción no se habría producido.
(TechCrunch ha informado recientemente de que ha visto "cientos" de supuestas credenciales de clientes de Snowflake, como la que se utilizó en este ataque, todavía disponibles en línea).
Como era de esperar, desde que se hizo pública la filtración, Snowflake ha anunciado un nueva política de autenticación que permite a los administradores forzar a todos los usuarios de Snowflake a usar MFA.
Lecciones para empresas (y usuarios) en la nube
Es importante que todos aprendamos de nuestros errores, y los servicios y usuarios de la nube pública no son diferentes.
Además de que los proveedores permitan a los administradores aplicar medidas de ciberseguridad sensatas como la AMF, hay otras valiosas lecciones sobre protección de datos que pueden extraerse de este incidente:
Aplicar MFA/2FA y otros valores predeterminados de seguridad razonables
Filtraciones de datos se han convertido en algo tan habitual que incluso la mayoría de los usuarios empresariales cotidianos son conscientes de la importancia del control de acceso con MFA o autenticación de dos factores (2FA). Los administradores deberían imponerlo siempre y los proveedores de la nube deberían ofrecer siempre esta opción.
Aunque la MFA provoca cierta fricción entre los empleados -hace poco cambié de ordenador y tuve que hacer unas 100 verificaciones de MFA en un par de horas mientras configuraba las cosas-, es capaz de detener muchos ciberataques en seco. Esa es la única razón para que no sea negociable.
Un servicio en la nube también debe proporcionar formación y asistencia a los clientes que activen la AMF en cuentas heredadas que estén conectadas a procesos automatizados, porque el paso de la AMF probablemente romperá esos procesos si la migración no se gestiona con cuidado.
Los proveedores de la nube también deberían aplicar otros valores predeterminados de seguridad, como la configuración automática de todos los recursos nuevos (como cubos de almacenamiento, bases de datos o máquinas virtuales) para bloquear todo acceso público (en lugar de estar abiertos al público por defecto).
Aunque este tipo de medidas añaden un poco de fricción al usuario final, también le obligan a emprender el camino hacia una mayor seguridad, en lugar de lo contrario.
Recopilar información sobre amenazas abiertas (OSINT)
Supervisar continuamente las amenazas en la web oscura y la Internet normal en nombre de los clientes y reaccionar ante cualquier indicador de una posible infracción. Se ha convertido en una tradición que usuarios descuidados expongan accidentalmente claves API en repositorios de código abierto, por ejemplo, como cuando este usuario publicó su Clave API de Stripe en GitHub (oops).
Las empresas de la nube deben vigilar los repositorios de código fuente abierto en busca de fugas de claves y ponerse en contacto con los clientes afectados si las descubren. Para ello, los proveedores pueden utilizar herramientas automatizadas como CrowdStrike.
Ofrezca herramientas para estar al tanto de posibles amenazas
Los proveedores de la nube también deberían ofrecer herramientas e integración con las principales plataformas de ciberseguridad para evaluar a los equipos de DevSecOps, estar al tanto de las posibles amenazas y dar a los usuarios más flexibilidad para seguir las mejores prácticas de ciberseguridad. Si los proveedores de la nube no ofrecen estos controles de seguridad, los administradores deben buscar estas herramientas de todos modos.
- Un ejemplo: Servicios como Splunk o Wiz pueden realizar una supervisión pasiva de todas las acciones dentro de una infraestructura en la nube, detectando automáticamente anomalías de uso que pueden ser un indicio inequívoco de una infracción, pero que de otro modo podrían pasar desapercibidas.
- Otro ejemplo: La rotación de claves API. Si un usuario quiere cambiar su clave API cada tres meses, por ejemplo, el proveedor debe proporcionarle un mecanismo para que pueda hacerlo sin incurrir en un tiempo de inactividad significativo del sistema. Eso significa ofrecer la posibilidad de generar varias claves API al mismo tiempo.
No dé las cosas por sentadas
Por fin, especialmente como cliente, nunca dé por sentado el modelo de responsabilidad compartida ni se duerma en los laureles.. A veces es fácil caer en la mentalidad de "es responsabilidad de la otra empresa", o asumir que si una herramienta de seguridad no es obligatoria, no es importante.
Los proveedores de servicios en la nube deben proporcionar tanta formación y documentación como sea posible para guiar a los usuarios hacia una postura de seguridad responsable, al tiempo que educan a sus propios empleados sobre las últimas amenazas a la seguridad y las mejores prácticas.
Y como usuario siempre debes seguir las mejores prácticas, leer la documentación y nunca dar por hecho que tu proveedor de infraestructura en la nube se va a encargar de algo hasta que lo veas por escrito.
MASV: un enfoque de seguridad por capas
Además de estar basado en la seguridad de AWS con un cifrado TLS 1.2 y AES-256 y estrictos controles de acceso, MASV mantiene a salvo todos los datos almacenados y transferidos a través de un sistema de gestión de la seguridad. enfoque de seguridad por capas que incluyen:
- Formación de los empleados en materia de seguridad y fuertes generadores internos de contraseñas.
- Seguridad de los productos incluido el escaneado periódico de códigos y las alertas automáticas para los inicios de sesión de los administradores.
- Protección del cliente como la aplicación obligatoria de contraseñas seguras y el fomento del uso obligatorio de AMF y generadores de contraseñas.
- Validación mediante auditorías de ciberseguridad realizadas por terceros y el cumplimiento de la normativa.
Regístrate en MASV y empiece gratis hoy mismo.
Infraestructura en nube Premium
MASV se ejecuta en una infraestructura en la nube de AWS altamente segura, por lo que tus archivos están siempre a salvo.