Resumen
- Mandiant informó que cada incidente de la campaña de Snowflake que manejó directamente se debió a credenciales de clientes comprometidas y no encontró evidencia de que el acceso no autorizado se originara por una brecha en el entorno empresarial de Snowflake. Su informe de campaña está enhttps://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion.
- La campaña aún puso a prueba la responsabilidad del proveedor porque Snowflake controlaba las superficies de autenticación, los valores predeterminados del producto, la orientación de seguridad, la telemetría de la cuenta, las herramientas de políticas de red, las comprobaciones de Trust Center y los cambios posteriores a la campaña que ningún cliente individual podría crear por sí solo.
- La reparación verificable significa un cambio medible: MFA predeterminado para usuarios humanos en cuentas nuevas, reglas de contraseña más estrictas, desactivación automática de contraseñas filtradas, paquetes de evidencia para clientes, controles de origen de red y métricas de adopción que muestren la reducción de riesgos en toda la base instalada.
- La responsabilidad del cliente sigue siendo sustancial. Los clientes controlaban la creación de usuarios, concesión de roles, rotación de contraseñas, inscripción en MFA en cuentas existentes, acceso de contratistas, listas de permitidos de red, minimización de datos, privilegios de exportación y preparación para la investigación.
No se demostró que la plataforma estuviera comprometida; se demostró que la línea de base era permisiva
La primera disciplina es mantener el límite de la campaña exacto. El informe de Mandiant de junio de 2024 dijo que el acceso no autorizado en los incidentes que manejó provino de credenciales de clientes comprometidas y que no encontró evidencia de una brecha en el entorno empresarial de Snowflake. La guía para clientes de Snowflake, amplificada por CISA en source: cisa.gov, dirigió a los clientes a investigar el acceso de usuarios no autorizados y fortalecer los controles de identidad y red.
El registro revisado no establece una explotación de la plataforma Snowflake, un escape entre inquilinos o el robo de una credencial maestra del proveedor.
Ese hallazgo negativo es importante porque da forma a la respuesta inmediata. Un cliente no debe esperar un parche del proveedor si el problema activo es una credencial de usuario válida sin MFA, sin lista de permitidos de red y con amplios privilegios de rol. El cliente necesita rotar credenciales, desactivar cuentas, inspeccionar el historial de inicio de sesión y consultas, restringir las redes de origen, revisar roles, conservar registros y notificar a las personas afectadas o reguladores cuando sea necesario.
El error opuesto es decir que el proveedor no tenía responsabilidad porque el primer secreto pertenecía a los clientes. Snowflake operaba el punto final de autenticación que aceptaba esas contraseñas. Proporcionó la capacidad de MFA y eligió cuándo cambiar el comportamiento predeterminado. Expuso o retuvo campos de telemetría. Proporcionó controles de políticas de red y hallazgos de Trust Center. Podía ver señales entre clientes que ningún inquilino podía ver. Más tarde pudo construir protección contra contraseñas filtradas en el servicio. Eso es control real, incluso si el cliente era dueño de la cuenta.
La presentación anual del año fiscal 2025 de Snowflake en SEC source establece la posición de responsabilidad compartida de la empresa y describe las consecuencias legales, regulatorias y de reputación tras la actividad de 2024. Una presentación es una representación de la empresa, no un fallo. Sin embargo, es relevante porque la propia Snowflake reveló que la campaña afectó el riesgo comercial más allá de cualquier inquilino individual. La responsabilidad compartida se convirtió en un problema de empresa pública.
Por lo tanto, el enfoque del artículo no es "Snowflake comprometida" o "los clientes fracasaron solos". Es reparación verificable. Después de que una campaña explota un patrón previsible de acceso solo con contraseña, credenciales obsoletas de infostealer y restricciones de red faltantes, el proveedor y los clientes necesitan evidencia de que la próxima campaña similar tendrá menos credenciales viables, menos sesiones solo con contraseña, menos orígenes sin restricciones, mejores alertas y una entrega de evidencia más rápida.
La ruta de la campaña utilizó funciones ordinarias bajo identidad hostil
Mandiant describió una cadena práctica. Las credenciales habían sido robadas por malware infostealer de sistemas que no eran propiedad de Snowflake, incluidas máquinas de contratistas utilizadas para actividades personales en algunos casos. Esas credenciales seguían siendo válidas, a veces durante años. Las cuentas carecían de MFA. Las instancias de clientes carecían de listas de permitidos de red. Los atacantes se conectaron con clientes y herramientas estándar, realizaron reconocimiento, seleccionaron datos, prepararon resultados, comprimieron archivos y los recuperaron.
El patrón utilizó funcionalidad de base de datos compatible bajo identidad no autorizada.
Esa distinción es central para la reparación. El cifrado en reposo no fue la barrera decisiva. La documentación de cifrado de extremo a extremo de Snowflake en source: docs.snowflake.com describe el cifrado en reposo y en tránsito, pero también explica que los datos deben usarse durante las operaciones de tabla y pueden descargarse y descargarse por usuarios autorizados. Un atacante que satisface la autenticación de la cuenta y hereda un rol puede pedir al servicio resultados legibles. El cifrado no es un sustituto de la garantía de identidad, el diseño de roles, el control de exportación y la detección.
El control de acceso determinó el radio de explosión después del inicio de sesión. La descripción general del control de acceso de Snowflake en source: docs.snowflake.com describe roles, privilegios, propiedad y jerarquía. Una credencial robada asignada a un acceso estrecho es diferente de una asignada a amplios privilegios de lectura o administración de cuentas. Una cuenta de servicio construida para una canalización es diferente de un administrador contratista. El principio de mínimo privilegio no es un eslogan;
es la diferencia entre una sesión hostil que devuelve una vista y una sesión hostil que recorre las tablas principales del cliente.
La clasificación y el enmascaramiento de datos pueden reducir la consecuencia. La documentación de clasificación de datos sensibles de Snowflake en source: docs.snowflake.com conecta el descubrimiento de columnas sensibles con políticas de enmascaramiento y acceso a filas. Esto no prueba que los clientes afectados tuvieran tales controles. Muestra una ruta de reparación: los clientes deben identificar campos personales y regulados, exponer vistas en lugar de tablas sin procesar cuando sea posible, y separar los roles de exportación de los roles de lectura ordinarios.
La ruta de exfiltración observada también convierte la exportación en un control por derecho propio. Las descargas masivas son legítimas en una plataforma de datos. Apoyan análisis, copias de seguridad, procesamiento descendente y flujos de trabajo de modelos. Pero una sesión inusual que crea etapas temporales, exporta grandes resultados y los descarga desde un origen desconocido no es solo "una consulta". Es un evento de movimiento de datos. La reparación debería hacer que tales eventos sean medibles, atribuibles y, para conjuntos de datos de alto riesgo, interrumpibles.
La disponibilidad de MFA se convirtió en resultados de MFA
MFA estaba disponible antes de la campaña. Las cuentas exitosas en el informe de Mandiant carecían de él. Esa brecha es el corazón de la disputa de responsabilidad compartida. Un administrador de cliente podría habilitar MFA, y muchos no lo hicieron. Un proveedor puede decir con sinceridad que el control estaba disponible. Pero un proveedor que ve que muchas cuentas de alto valor aún están accesibles solo con contraseña no ha logrado el resultado de seguridad, solo ha hecho que la configuración esté disponible.
El anuncio de Snowflake de septiembre de 2024 en source: snowflake.com movió la postura del producto. Dijo que MFA sería exigido por defecto para usuarios humanos en cuentas creadas a partir de octubre de 2024 y que los usuarios de servicio no estarían sujetos a ese requisito específico. También anunció requisitos de contraseña más fuertes para contraseñas de usuario recién creadas y alteradas. Esta es una reparación significativa porque cambia la ruta predeterminada para cuentas futuras.
La distinción entre cuentas nuevas y existentes es igualmente significativa. Un valor predeterminado para cuentas futuras no elimina automáticamente todas las rutas solo con contraseña en la base instalada. Los clientes existentes pueden tener usuarios heredados, cuentas de servicio, contratistas, cuentas de emergencia y clientes más antiguos.
Un registro de reparación verificable debería, por lo tanto, medir directamente el riesgo heredado: número y proporción de usuarios humanos sin MFA, usuarios humanos privilegiados sin MFA, usuarios de contraseña con fechas de último inicio de sesión obsoletas, usuarios con credenciales expuestas conocidas, cuentas de servicio que usan contraseñas en lugar de autenticación de carga de trabajo más fuerte, y excepciones con propietarios comerciales y fechas de vencimiento.
La documentación de políticas de autenticación de Snowflake en source: docs.snowflake.com da a los administradores controles sobre métodos de autenticación, clientes, proveedores de identidad e inscripción en MFA. Su documentación de autenticación de par de claves en source: docs.snowflake.com ofrece a las cuentas de servicio una alternativa a las contraseñas estáticas. Estos controles imponen deberes a los clientes, pero también definen la superficie de reparación del proveedor: el producto debe facilitar los buenos patrones, hacer visibles las malas excepciones y hacer que la migración sea menos arriesgada.
La guía de identidad digital del NIST en source: pages.nist.gov ayuda a establecer el resultado. Las contraseñas no son resistentes a la repetición. Los métodos resistentes al phishing o criptográficamente vinculados reducen el valor de una contraseña robada. Para los clientes de Snowflake, eso significa que los administradores humanos deben pasar a través de identidad federada o MFA fuerte, mientras que los usuarios de servicio deben usar credenciales de carga de trabajo con ámbito que roten y puedan desactivarse sin suplantar a una persona.
El bloqueo de contraseñas filtradas hizo que la responsabilidad compartida fuera medible
La reparación más directa del proveedor después de una campaña de credenciales robadas no es una conferencia sobre la reutilización de contraseñas. Es hacer que las contraseñas robadas conocidas dejen de funcionar. El anuncio de Snowflake de diciembre de 2024 en source: snowflake.com dijo que desactivaría automáticamente las contraseñas detectadas en la dark web a través de un proceso que preserva la privacidad cuando se confirman como filtradas y aún válidas. Este control aborda la ventaja central de la campaña: las credenciales robadas mucho antes de 2024 seguían siendo aceptadas por el servicio.
La protección de contraseñas filtradas no elimina el deber del cliente. Los clientes aún necesitan seguridad en los endpoints, gobierno de contratistas, rotación de contraseñas, federación, diseño de usuarios de servicio y mínimo privilegio. Pero cambia la división del trabajo. Los clientes individuales a menudo no pueden ver el mercado global de infostealers tan bien como un proveedor de nube. Un proveedor puede comprar o recibir inteligencia de amenazas, comparar credenciales expuestas de manera controlada y desactivar una contraseña antes de que cada cliente la descubra de forma independiente.
Ese es el tipo de control a nivel de proveedor que convierte la responsabilidad compartida de una cláusula en un comportamiento del sistema.
La cuestión de evidencia es la adopción y el rendimiento. ¿Cuántas contraseñas filtradas válidas se encontraron? ¿Con qué rapidez se desactivaron? ¿Cuántas pertenecían a usuarios privilegiados? ¿Cuántas cuentas pasaron de contraseña a acceso de par de claves o federado? ¿Cuántos eventos de contraseña desactivada llevaron a fricción de soporte o soluciones inseguras? ¿Cuántos clientes todavía tienen excepciones? Sin métricas, la protección de contraseñas filtradas sigue siendo un buen anuncio. Con métricas, se convierte en una reparación verificable.
El compromiso Secure by Design de CISA en source: cisa.gov enmarca esta distinción. Pide a los fabricantes que vayan más allá de los controles opcionales hacia resultados medibles como MFA predeterminado y métricas de adopción. El anuncio de compromiso de Snowflake de julio de 2024 en source: snowflake.com colocó a la empresa dentro de ese compromiso público. El compromiso es voluntario y no un veredicto legal sobre la campaña. Es relevante porque identifica el tipo de evidencia que los clientes deben esperar después del evento.
La política de red era una segunda puerta
Mandiant identificó la falta de listas de permitidos de red como un factor recurrente. La documentación de políticas de red de Snowflake en source: docs.snowflake.com establece el valor predeterminado práctico: sin una política, los usuarios pueden conectarse desde cualquier computadora o dispositivo. Los clientes pueden restringir el acceso por ubicaciones de red permitidas o bloqueadas y usar patrones de conectividad privada para límites más fuertes.
El cliente es el actor mejor posicionado para conocer los orígenes legítimos: oficinas, VPN, cargas de trabajo en la nube, escritorios de contratistas gestionados y proveedores de integración aprobados. Snowflake no puede adivinar cada ruta válida sin interrumpir el servicio. Pero Snowflake controla si el acceso público sin restricciones es silencioso o visible. Un programa de reparación verificable debería informar qué cuentas carecen de políticas de red, qué usuarios privilegiados las evitan, si el acceso a etapas internas está cubierto y si las políticas coinciden realmente con los orígenes aprobados por el negocio.
Los controles de red no son suficientes por sí solos. Un atacante puede usar una VPN aprobada, comprometer una máquina de contratista que ya está dentro de una lista de permitidos, o robar un token después de la autenticación. Sin embargo, la defensa debe ser en capas. Una contraseña robada, sin MFA, sin restricción de red, rol amplio y exportación no monitoreada es una cadena. Romper cualquier eslabón puede importar. La reparación es el proceso de reducir el número de entornos de clientes donde todos los eslabones permanecen abiertos juntos.
El proveedor también debe hacer que la gestión de bloqueos sea segura. Los administradores pueden evitar las políticas de red porque temen bloquear a usuarios comerciales o trabajos de servicio. La simulación, la implementación por fases, los contactos de emergencia, las excepciones temporales y los registros claros reducen ese miedo. Cuanto mejor sea la ruta de migración, más difícil será tratar las políticas faltantes como ordinarias.
La telemetría es el límite de la evidencia
Después de una campaña de robo de datos, los clientes necesitan más que una garantía general. Necesitan saber quién inició sesión, desde dónde, con qué factor, usando qué cliente, bajo qué rol, qué consultas se ejecutaron, qué objetos se tocaron, qué datos se descargaron, qué etapas se utilizaron y cuántos datos se movieron. La documentación actual de Snowflake describe múltiples vistas que pueden apoyar ese trabajo.
LOGIN_HISTORY en source: docs.snowflake.com proporciona intentos de inicio de sesión con IP de origen, cliente, éxito e información de factor. QUERY_HISTORY en source: docs.snowflake.com proporciona actividad de consulta, usuario, rol, texto de consulta, tamaño de resultado, filas descargadas y bytes enviados a través de la red. ACCESS_HISTORY en source: docs.snowflake.com puede ayudar a reconstruir el acceso a objetos y columnas para ediciones elegibles.
La documentación de Trust Center en source: docs.snowflake.com describe comprobaciones de postura y detecciones para MFA, políticas de red, inicios de sesión de riesgo, direcciones IP inusuales y transferencias grandes.
Esas son capacidades. La capacidad no es prueba de preparación para la investigación. Los clientes deben tener derechos para consultar las vistas, exportarlas a un almacenamiento de seguridad duradero, comprender la latencia y retención, y correlacionarlas con datos del proveedor de identidad, endpoint y ticketing. Las diferencias de edición pueden cambiar la precisión del alcance a nivel de campo. Las vistas del proveedor pueden tener retrasos que importan para la contención activa. El texto de consulta solo puede no decirle a un equipo de privacidad qué individuos estaban representados a menos que el cliente tenga mapas de datos.
Por lo tanto, la reparación verificable debe incluir paquetes de evidencia. Cuando Snowflake notifica a un cliente potencialmente expuesto, el cliente debe recibir identificadores de cuenta, usuarios, marcas de tiempo, redes de origen, estado del primer y segundo factor, identificadores de cliente, identificadores de sesión y consulta, roles, objetos tocados, nombres de etapas, volumen de descarga, confianza y contención recomendada. Una etiqueta como "potencialmente expuesto" es aceptable como apertura, pero debe ir seguida de suficientes datos para que el cliente decida si la información personal estaba involucrada.
La intervención del proveedor también necesita autorización previa. Un proveedor de nube puede ver actividad sospechosa antes que el cliente, pero bloquear automáticamente una sesión puede interrumpir la producción. No actuar puede permitir el robo. La reparación debe definir umbrales para la suspensión temporal, contactos de emergencia del cliente, preservación de evidencia y anulación. Los clientes deben designar contactos de seguridad que puedan actuar a cualquier hora. Snowflake debe medir el tiempo desde la señal entre clientes hasta el aviso al cliente y el tiempo desde el aviso hasta la contención.
La localidad de datos se detuvo en el acceso
La elección de región de Snowflake puede importar para latencia, resiliencia, privacidad y adquisición. La documentación de regiones compatibles en source: docs.snowflake.com dice que una cuenta está alojada en una región y que los datos permanecen allí a menos que los usuarios los copien, muevan o repliquen explícitamente. También establece el límite clave: la elección de región no limita el acceso del usuario a Snowflake.
La campaña convirtió ese límite en un problema de soberanía. Las tablas de un cliente pueden haber estado almacenadas en una región aprobada. Una identidad válida aún podía conectarse desde otro lugar, consultar los datos, descargarlos a una etapa y copiarlos. La ubicación de la cuenta de origen no impidió el acceso remoto ni la exportación. El registro público de la campaña no establece los países de origen y destino para cada víctima, por lo que no se puede respaldar una conclusión legal transfronteriza universal. La lección arquitectónica sigue siendo: la localidad de almacenamiento no es localidad de acceso.
La guía de intercambio entre regiones de Snowflake en source: docs.snowflake.com advierte a los clientes que confirmen las restricciones legales y regulatorias antes de replicar datos a otra región o país. Esa guía se refiere al movimiento aprobado. La exportación impulsada por credenciales es diferente porque puede crear una copia no controlada fuera de la región seleccionada sin cambiar la región de la cuenta de origen. Un inventario de datos que registra solo la región de origen puede ser preciso y aún así incompleto después de una exportación.
Por lo tanto, la reparación de la soberanía de datos necesita cuatro capas: dónde se alojan los datos autorizados, qué identidades pueden conectarse desde qué dispositivos y jurisdicciones, qué funciones de movimiento pueden crear copias, y qué evidencia existe después de un incidente. Snowflake controla las ofertas de región, autenticación, herramientas de red, mecánicas de exportación y telemetría. Los clientes controlan la base legal, los campos de datos, las concesiones de roles, las aprobaciones de movimiento y el análisis de notificaciones. Ambas partes necesitan evidencia en su límite.
Los casos de clientes muestran consecuencias, no un recuento maestro único
La forma pública de la campaña fue influenciada por las divulgaciones de empresas afectadas. Cada registro debe mantenerse dentro de sus propios hechos.
La presentación de Live Nation de mayo de 2024 en SEC source dijo que la compañía identificó actividad no autorizada en un entorno de base de datos en la nube de terceros que contenía principalmente datos de Ticketmaster y que un actor criminal ofreció posteriormente a la venta supuestos datos de usuario de la compañía. La presentación no nombró a Snowflake ni proporcionó un recuento confirmado de personas afectadas.
La página de incidentes de Ticketmaster Canada en source: help.ticketmaster.ca describió una base de datos en la nube de terceros aislada, posibles campos para algunos compradores de boletos norteamericanos y el límite de que las cuentas de clientes de Ticketmaster no se vieron afectadas. El comisionado de privacidad de Canadá identificó más tarde a Snowflake como el proveedor de Ticketmaster en una sesión informativa parlamentaria en source: priv.gc.ca, al tiempo que indicó que la investigación seguía abierta y que Ticketmaster Canada seguía siendo el controlador bajo revisión.
La presentación de AT&T de julio de 2024 en SEC source describió el acceso no autorizado a un espacio de trabajo de AT&T en una plataforma de nube de terceros y la exfiltración de registros de interacciones de llamadas y textos. La presentación no nombró a Snowflake. Es útil para comprender un incidente divulgado de espacio de trabajo en la nube de terceros y sus límites de campo, no como atribución independiente.
Estos ejemplos no crean un recuento de personas en toda la campaña. Las aproximadamente 165 organizaciones potencialmente expuestas de Mandiant son una población de notificación, no un recuento confirmado de víctimas, recuento de registros o recuento de individuos afectados. Cada cliente tenía datos, roles, retención, regiones y deberes de notificación diferentes. La reparación verificable debe ayudar a cada cliente a delimitar sus propios hechos en lugar de hacer que un único número a nivel de plataforma haga todo el trabajo.
Una nota de tipografía para paquetes de evidencia
Cuando los clientes reciben evidencia de seguridad en la nube de alta gravedad, el diseño puede decidir si la persona adecuada actúa rápidamente. Una tabla de sesiones, factores, roles, objetos y transferencias debe ser legible bajo presión. El siguiente bloque de tipografía pertenece al cuerpo público porque el diseño de evidencia es parte de la reparación.
Para los clientes de Snowflake, la evidencia legible significa marcas de tiempo en una sola base temporal, etiquetas claras de usuario y rol, separación de la actividad confirmada de la sospecha, estado de MFA visible y enlaces directos entre consultas, etapas, volumen de transferencia y almacenes de datos afectados. Una exportación densa de registros puede ser completa pero inutilizable. Un paquete de evidencia conciso puede marcar la diferencia entre una decisión rápida de contención y un análisis de privacidad retrasado.
Responsabilidad por control práctico
Los atacantes controlaron la actividad criminal: usar credenciales robadas, ingresar a entornos de clientes, preparar datos, tomarlos e intentar venderlos o extorsionar. Ellos son responsables de esa conducta.
Los clientes controlaron muchas puertas fallidas. Crearon usuarios, asignaron roles, eligieron si los usuarios humanos podían iniciar sesión solo con contraseña, retuvieron credenciales obsoletas, permitieron el acceso de contratistas, dejaron algunas cuentas sin políticas de red, concedieron acceso a datos y gobernaron las exportaciones. Un cliente cuyo almacén de alto valor aceptó una contraseña antigua desde un origen desconocido sin MFA ni roles estrechos no puede trasladar toda la responsabilidad al proveedor.
Snowflake controló la línea base y las herramientas de reparación. Controló si los nuevos usuarios humanos tenían MFA por defecto, si las contraseñas filtradas se desactivaban del lado del proveedor, si las configuraciones de riesgo aparecían en Trust Center, qué campos de telemetría estaban disponibles, cómo se notificaba a los clientes, cómo se redactaban las guías y con qué rapidez se enviaban los controles posteriores a la campaña. Un proveedor que ve el mismo patrón en todos los inquilinos tiene el deber de reducir el patrón a escala, no solo decirle a cada cliente que lea el manual.
Los proveedores de identidad, contratistas y propietarios de endpoints controlaron condiciones adyacentes. Los dispositivos de contratistas utilizados entre clientes pueden propagar un incidente de infostealer a varios inquilinos en la nube. Los proveedores de identidad pueden imponer factores más fuertes y acceso condicional. Los endpoints gestionados pueden mantener las credenciales fuera de las máquinas personales. Esos actores importan, pero no borran los deberes del cliente y del proveedor sobre la cuenta de Snowflake en sí.
Los reguladores, aseguradoras y equipos de adquisición controlan los incentivos. La guía de cadena de suministro del NIST en source: csrc.nist.gov apoya la definición de requisitos de proveedor proporcionales a la criticidad. Para un almacén de datos, eso significa que los contratos y renovaciones deben solicitar métricas de adopción de MFA, respuesta a contraseñas filtradas, campos de paquetes de evidencia, garantías de retención, plazos de notificación, escalado de soporte y controles de movimiento regional. Un cuestionario de seguridad que pregunta solo si existe MFA es demasiado superficial después de esta campaña.
Lo que probaría una reparación duradera
El registro de reparación debe incluir al menos diez resultados.
Primero, todos los nuevos usuarios humanos usan MFA o acceso federado más fuerte por defecto, y la base instalada muestra una proporción creciente de cuentas humanas protegidas y humanas privilegiadas. Segundo, los usuarios de servicio se alejan de las contraseñas estáticas hacia credenciales de carga de trabajo con ámbito (par de claves, OAuth u otras) con rotación. Tercero, la protección de contraseñas filtradas informa eventos de desactivación confirmados y tiempo promedio para desactivar. Cuarto, la cobertura de políticas de red aumenta, especialmente para cuentas privilegiadas y etapas internas.
Quinto, los hallazgos de Trust Center no solo se muestran sino que se corrigen con propietarios de excepciones y fechas de vencimiento. Sexto, la retención y exportación de telemetría son suficientes para el descubrimiento tardío y el alcance de la privacidad. Séptimo, las detecciones de gran descarga y origen inusual se ajustan y se enrutan a personas que pueden actuar. Octavo, las notificaciones del proveedor incluyen evidencia concreta de sesión, consulta, rol, objeto y transferencia. Noveno, los clientes afectados pueden mapear consultas a personas y categorías de datos regulados.
Décimo, los contratos y revisiones de renovación de clientes incorporan evidencia en lugar de basarse en la redacción de responsabilidad compartida.
El litigio puede influir en el registro pero no debe reemplazar la evidencia de control. La orden de fase de alegatos en el litigio multidistrital de Snowflake en source: govinfo.gov permitió que ciertas alegaciones continuaran mientras se trataban bajo estándares procesales. Eso no es un hallazgo final de responsabilidad. Muestra que los tribunales pueden examinar los valores predeterminados del proveedor, la previsibilidad y la causalidad incluso cuando la historia pública comienza con credenciales de clientes.
El problema de la base instalada
Los valores predeterminados seguros son más efectivos en el momento de la creación. Son más difíciles en una base instalada donde los clientes ya tienen automatización, usuarios de servicio, contratistas, proveedores de identidad, clientes antiguos y cuentas de emergencia. El cambio de MFA predeterminado de Snowflake para cuentas nuevas fue un paso material, pero el riesgo de la campaña vivía en gran medida en cuentas existentes con hábitos existentes. Por lo tanto, la reparación verificable necesita una historia de migración para la base instalada, no solo una historia de cuentas nuevas.
El problema de la base instalada tiene varias capas. Primero, los usuarios humanos antiguos aún pueden autenticarse directamente con contraseñas porque la federación nunca se completó. Segundo, los usuarios privilegiados pueden tener excepciones porque los administradores temen el bloqueo. Tercero, los usuarios de servicio pueden estar mal clasificados como humanos o los humanos pueden usar credenciales de estilo de servicio. Cuarto, los contratistas pueden retener el acceso después de que termine un proyecto. Quinto, las cuentas inactivas aún pueden tener roles que alcancen datos sensibles.
Sexto, las integraciones pueden fallar si las reglas de contraseña o las políticas de red cambian repentinamente.
El proveedor puede reducir esta fricción sin hacerse cargo del inquilino del cliente. Puede mostrar a los administradores una lista priorizada de identidades de riesgo, divididas por privilegio y alcance de datos. Puede proporcionar políticas de prueba que muestren quién sería bloqueado por MFA o restricciones de red. Puede exigir propietarios de excepciones y fechas de vencimiento. Puede distinguir las cuentas de emergencia de las cuentas heredadas ordinarias. Puede proporcionar ayudas de migración para usuarios de servicio que se mueven a patrones de par de claves u OAuth.
Puede enviar avisos de producto repetidos vinculados al riesgo real en lugar de pancartas genéricas.
Los clientes entonces tienen que actuar. Un cliente que recibe un panel que muestra usuarios privilegiados solo con contraseña y los deja sin cambios durante meses posee ese riesgo residual. Un cliente que no puede decir si una cuenta de contratista sigue siendo necesaria posee una falla de gobierno de identidad. Un cliente que permite que una cuenta de servicio lea tablas enteras sin procesar porque "la canalización solía necesitarlo" posee un alcance de rol excesivo. La responsabilidad compartida se vuelve concreta cuando el proveedor muestra la evidencia y el cliente o remedia o registra una excepción responsable.
El registro de reparación debe separar tres estados: remediado, exceptuado y desconocido. Remediado significa que la condición de riesgo ha desaparecido. Exceptuado significa que un propietario de negocio la aceptó con controles compensatorios y una fecha de revisión. Desconocido significa que nadie ha tomado responsabilidad. Un programa maduro impulsa el recuento de desconocidos hacia cero. La tranquilidad pública a menudo omite esta distinción; la reparación verificable depende de ella.
La evidencia del cliente debe conectar registros técnicos con personas
Snowflake puede exponer una telemetría técnica rica, pero la respuesta de privacidad y legal requiere un puente desde los objetos técnicos hasta las personas y obligaciones. Un identificador de consulta, nombre de rol o ruta de etapa es solo el comienzo. El cliente debe saber qué tabla contenía qué campos personales, qué sujetos de datos estaban representados, qué reglas de país o estado aplican, qué deberes de notificación contractual existen y qué sistemas posteriores recibieron copias. Sin ese puente, el cliente puede saber que los bytes se fueron pero no saber a quién notificar.
Ese puente debe prepararse antes de un incidente. Los propietarios de datos deben mantener inventarios de campos para datos regulados, propósito comercial, período de retención, política de enmascaramiento y rutas de exportación aprobadas. Los equipos de seguridad deben saber dónde se retienen los registros de Snowflake fuera de la plataforma y por cuánto tiempo. Los equipos de privacidad deben poder solicitar una lista de tablas afectadas y recibir un mapeo a categorías de personas y campos. Los equipos legales deben saber qué regiones y contratos de clientes se adjuntan a esos registros.
La evidencia del proveedor puede facilitar esto. Si una notificación incluye los roles exactos, objetos, etapas y volumen, el cliente puede evitar una búsqueda amplia y lenta. Si el proveedor también etiqueta si MFA estaba presente, si la fuente era inusual y si la protección de contraseñas filtradas desactivó posteriormente la credencial, el cliente puede entender la causa y la contención. Si el proveedor da solo consejos generales, el cliente debe reconstruir la evidencia mientras el reloj para la notificación y la respuesta a extorsión ya está corriendo.
La campaña también expuso una cuestión de retención para la propia telemetría. Los historiales nativos pueden cubrir un año, pero las disputas legales, el descubrimiento tardío y las consultas regulatorias pueden extenderse más. Los clientes de alto riesgo deberían transmitir registros a un almacén de seguridad independiente con retención alineada con sus obligaciones. Un proveedor debe hacer que dicha exportación sea práctica y documentada. El cliente debe demostrar que funciona reconstruyendo periódicamente una ruta de acceso de muestra desde el inicio de sesión hasta la consulta y la categoría de datos.
La reparación no puede depender de la vergüenza del cliente
Después de una campaña de credenciales, es tentador tratar a los clientes sin MFA como la lección de la historia. Eso es parcialmente cierto y aún insuficiente. Avergonzar públicamente a los clientes no desactiva las contraseñas filtradas, rediseña los valores predeterminados ni entrega paquetes de evidencia. Incluso puede hacer que los clientes oculten configuraciones débiles hasta que un incidente obligue a la divulgación.
El mejor modelo es el endurecimiento progresivo. El proveedor comienza con visibilidad, luego valores predeterminados más fuertes, luego advertencias específicas, luego gobierno de excepciones y luego aplicación para categorías de riesgo donde la consecuencia lo justifica. Los clientes reciben tiempo y herramientas de migración, pero también pierden la capacidad de dejar brechas de alto riesgo invisibles. Los equipos de adquisición luego preguntan por métricas de adopción y recuentos de excepciones, no solo listas de características.
Este enfoque reconoce que las plataformas en la nube son sistemas operativos compartidos para datos comerciales. Un proveedor que hace un valor predeterminado más seguro puede aumentar brevemente la fricción del cliente, pero también reduce el grupo de objetivos disponibles para grupos criminales. Un cliente que acepta la aplicación puede necesitar actualizar scripts o identidades, pero gana una historia más sólida para reguladores, aseguradoras y sujetos de datos. La reparación funciona cuando ambas partes pueden señalar condiciones cambiadas, no mensajes cambiados.
La adquisición debe exigir telemetría de reparación
Un comprador de una plataforma de datos de alto valor debe tratar la telemetría posterior a la campaña como un requisito de adquisición. La pregunta no es solo si el proveedor ahora ofrece MFA, políticas de red, controles de contraseñas filtradas y hallazgos de Trust Center. La pregunta es si el comprador puede recibir evidencia de que esos controles están activos, completos y probados en la propia cuenta del comprador. La disponibilidad de características es lenguaje de proveedor. La cobertura de control es lenguaje operativo.
El registro de adquisición debe solicitar un informe de cobertura de identidad, incluidos usuarios humanos, usuarios privilegiados, usuarios de servicio, cuentas inactivas, contratistas externos, estado de federación, estado de MFA y excepciones de contraseña. Debe solicitar cobertura de red por cuenta, clase de usuario, etapas internas y endpoints privados. Debe preguntar si la protección de contraseñas filtradas está habilitada, qué avisos de evento produce y cómo se refleja una contraseña desactivada en los registros de auditoría.
Debe preguntar qué hallazgos de Trust Center están disponibles en el nivel contratado y durante cuánto tiempo se retiene el historial relevante.
Los términos de incidente deben ser igualmente concretos. Una cláusula de notificación genérica es débil después de esta campaña. Los clientes necesitan plazos para la notificación de alta gravedad, campos de evidencia que se incluirán, contactos de emergencia, escalado de soporte, preservación de registros y cooperación en el alcance de los sujetos de datos. Un cliente que posee datos personales regulados debe requerir paquetes de evidencia de muestra antes de la renovación, no después del robo.
Un ejercicio de simulación puede probar si el proveedor y el cliente pueden pasar de un inicio de sesión sospechoso a un análisis de campo afectado dentro del plazo necesario.
Esto no traslada todo el trabajo a Snowflake. El cliente debe mantener sus propios mapas, retener registros y conocer sus obligaciones de privacidad. Pero el proveedor controla muchos hechos necesarios para que el mapa sea utilizable. Un proceso de adquisición que pide solo certificaciones perderá el problema operativo. Un proceso que pide telemetría de reparación revelará si la responsabilidad compartida está lista para la próxima campaña.
La misma evidencia debe aparecer en las renovaciones. Si un cliente permanece en acceso pesado con contraseña un año después de la campaña, la renovación debe forzar una excepción nombrada o una migración financiada. Si un cliente no puede recibir detalle a nivel de ACCESS_HISTORY debido a la edición, la renovación debe documentar si esa limitación es aceptable para los datos almacenados. Si las políticas de red están ausentes, la renovación debe identificar claramente el bloqueador operativo. La reparación debe revisarse antes de que el apalancamiento desaparezca en otro término del contrato.
La evidencia de renovación también debe separar el cambio de plataforma del cambio de inquilino. Snowflake puede enviar un valor predeterminado más fuerte, pero la cuenta del cliente aún puede contener usuarios solo con contraseña, roles amplios, contratistas obsoletos y etapas no revisadas. El comprador debe pedir el libro de contabilidad de excepciones de la propia cuenta, no solo la hoja de ruta del producto del proveedor. Esa distinción evita una deriva familiar posterior al incidente: el proveedor anuncia un control, los clientes asumen que el riesgo se ha movido y la base instalada permanece materialmente expuesta.
Para los consejos directivos y equipos de privacidad, ese registro a nivel de inquilino es el puente entre la reparación técnica y la confianza legal. Una afirmación de que "MFA está disponible" no responde si la cuenta afectada lo usó. Una afirmación de que "las políticas de red existen" no responde si la credencial robada podía alcanzar datos desde un origen inusual. Una afirmación de que "la telemetría se retiene" no responde si la organización puede mapear consultas a campos regulados. La reparación verificable vive en esas respuestas específicas de la cuenta.
Qué no inferir
Un relato moderado debe evitar cuatro saltos. Primero, la campaña no prueba que la plataforma de producción de Snowflake fuera comprometida. Segundo, no prueba que cada organización notificada perdiera datos. Tercero, no prueba que cada cliente afectado tuviera los mismos campos, personas o deberes legales. Cuarto, los cambios de producto posteriores a la campaña no prueban por sí mismos negligencia antes de los cambios. Los productos de seguridad evolucionan después de incidentes por muchas razones, incluida una mejor inteligencia de amenazas y estándares cambiados.
Al mismo tiempo, la moderación no requiere silencio sobre el deber del proveedor. Un proveedor puede estar libre de un hallazgo de brecha de plataforma y aún ser responsable por el diseño predeterminado, la calidad de la telemetría y las advertencias entre clientes. Un cliente puede tener la culpa por controles de identidad débiles y aún necesitar los datos del proveedor para investigar. Una orden de litigio puede ser no definitiva y aún mostrar que el MFA predeterminado y la previsibilidad serán examinados. Una responsabilidad equilibrada mantiene todas esas proposiciones vivas a la vez.
La evaluación final es de alto impacto y alta confianza. La evidencia confirmada respalda una campaña de credenciales de clientes, no una brecha de la plataforma Snowflake. Pero la evidencia también muestra por qué los valores predeterminados del proveedor, la telemetría y la automatización de seguridad entre clientes son parte de la responsabilidad. La responsabilidad compartida es creíble solo cuando ambas partes pueden mostrar las puertas que cerraron. Después de esta campaña, la prueba de Snowflake no es si puede decir que existía MFA.
Es si menos contraseñas robadas pueden convertirse en sesiones, menos sesiones pueden alcanzar datos amplios, y más clientes pueden probar exactamente lo que sucedió antes de que los datos se fueran.