Nube digital con candados abiertos y flujos de datos filtrándose

Snowflake y Ticketmaster: Por qué tu proveedor SaaS no va a salvar tus datos

Este artículo forma parte de la serie Ciberseguridad y Resiliencia.

En 2024, un actor conocido como UNC5537 accedió a los datos de más de un centenar de organizaciones —entre ellas Ticketmaster, Santander y operadores de telecomunicaciones— utilizando una plataforma de datos en la nube como puerta de entrada. La reacción inmediata del mercado fue culpar a Snowflake. La realidad técnica era mucho más incómoda: no hubo brecha en la plataforma. Las credenciales simplemente estaban robadas.

Ese matiz cambia por completo la responsabilidad y, sobre todo, la lección. El incidente no fue un fallo de un proveedor, fue la consecuencia acumulada de años de higiene de identidad descuidada en las empresas afectadas.

El problema: El mito de la seguridad delegada

La nube introdujo una comodidad peligrosa: la sensación de que «si está en el proveedor, el proveedor lo protege». El modelo de responsabilidad compartida existe desde el primer día, pero en la práctica se ha convertido en una zona gris donde nadie revisa la configuración.

El proveedor garantiza la seguridad de la nube: la infraestructura, la disponibilidad, el cifrado en reposo. El cliente sigue siendo responsable de la seguridad en la nube: quién entra, con qué credenciales, desde dónde y con qué permisos. Y en la mayoría de las organizaciones, esa segunda mitad del contrato no tiene dueño.

El mecanismo: Credenciales huérfanas y ausencia de MFA

El ataque no requirió ninguna técnica avanzada. Los actores utilizaron credenciales obtenidas previamente mediante infostealers instalados en equipos no gestionados. A partir de ahí, encontraron tres condiciones que convertían un incidente menor en una catástrofe:

  • Cuentas sin MFA: una contraseña filtrada era suficiente para entrar.
  • Credenciales obsoletas o huérfanas: accesos de empleados que ya no estaban, o de integraciones que nadie recordaba, sin rotación desde años atrás.
  • Ausencia de restricciones de red: el acceso era válido desde cualquier IP del mundo, sin listas de permitidos ni detección de ubicación anómala.

El resultado es un blast radius desproporcionado: una única credencial administrativa daba acceso al almacén de datos completo de la organización.

La decisión: Higiene de identidad y mínimo privilegio real

La respuesta no es cambiar de proveedor, es asumir la parte del contrato que nunca se auditó. Cuatro medidas concretas tienen un impacto inmediato:

  1. MFA obligatorio y federación con SSO: eliminar cuentas locales y contraseñas estáticas. Si una identidad no puede pasar por el proveedor de identidad corporativo, no debería existir.
  2. Inventario de identidades, incluidas las no humanas: auditar credenciales de servicio, integraciones y accesos heredados. Revocar al salir un empleado es tan importante como darle acceso al entrar.
  3. Restricciones de red y detección de sesiones anómalas: limitar el acceso a rangos corporativos o VPN, y alertar cuando una sesión aparece desde una geolocalización imposible.
  4. Principio de mínimo privilegio aplicado a datos: segmentar el acceso por dominio y evitar cuentas con permisos globales sobre el almacén completo.

La lección: La seguridad es tuya, siempre

La lección de Snowflake y Ticketmaster es que contratar un servicio no transfiere el riesgo. El proveedor te entrega controles; activarlos es tu trabajo. Y los controles que fallaron aquí no eran exóticos: eran MFA, rotación de credenciales y límites de red, exactamente lo que llevamos veinte años recomendando.

Los datos en el SaaS siguen siendo tus datos. Deberían auditarse con el mismo rigor que si estuvieran en tu propio centro de datos y con la misma desconfianza con la que tratarías a cualquier usuario remoto. La comodidad de la nube no es una excusa para delegar la responsabilidad; es una razón más para verificar la configuración.