El problema de fondo
Connor Moucka no explotó una vulnerabilidad en Snowflake. Él y sus cómplices utilizaron credenciales legítimas de clientes, muchas de ellas con años de antigüedad, para acceder a más de 165 organizaciones que usan la plataforma. Lograron robar miles de millones de registros, incluidos los datos de llamadas y mensajes de casi todos los clientes inalámbricos de AT&T. Moucka se declaró culpable el 5 de agosto por fraude informático, fraude electrónico, robo de identidad agravado y conspiración.
La campaña expuso una falla de identidad conocida: las credenciales permanecieron válidas mucho después de haber sido expuestas, muchas cuentas afectadas no tenían activado un segundo factor y, a menudo, no había restricciones de red. Ahora Snowflake obliga a sus clientes a enfrentar esa deuda de identidad, centrándose en las identidades no humanas.
Las cuentas que aún usan contraseña
Pronto, todas las cuentas de servicio no podrán autenticarse con contraseña. El tipo de usuario LEGACY_SERVICE se está eliminando por completo, y las cuentas heredadas se migran al tipo SERVICE, que no puede almacenar contraseña. Snowflake ha implementado esta migración en tres fases: la primera (septiembre 2025-enero 2026) exigió segundo factor para usuarios humanos en Snowsight; la segunda (mayo-julio 2026) obligó a que los nuevos usuarios no humanos fueran de tipo SERVICE; la tercera (agosto-octubre 2026) requiere que las cuentas de servicio heredadas migren fuera de la autenticación por contraseña antes de su fecha límite específica.
Las cuentas restantes son las más antiguas, con más tiempo para que las credenciales se filtren o no se roten, para que los propietarios cambien de equipo y para que las dependencias pierdan documentación.
Paso 1: Construir el inventario ahora, no en octubre
Hay que responder tres preguntas para cada cuenta de servicio: ¿cuáles se autentican en Snowflake? ¿Quién es el propietario? ¿Qué se rompe cuando la contraseña deje de funcionar? Snowflake responde la primera: el esquema ACCOUNT_USAGE almacena la lista de usuarios por tipo de cuenta y el historial de inicio de sesión registra el cliente y la IP de origen durante 365 días. Así se obtienen las cuentas que siguen usando contraseña, cuándo se usaron por última vez y desde dónde.
Las otras dos preguntas son más complejas. Snowflake no sabe quién solicitó la cuenta, qué sistema depende de ella ni a quién llamar si falla. Esa información vive en la memoria de quien la configuró, en un ticket de 2022 o, probablemente, en ningún sitio. Un inventario hecho en octubre por la presión de una fecha límite no es gobernanza: captura un momento y comienza a degradarse al día siguiente.
Paso 2: Asignar un propietario a cada cuenta
El registro del propietario evita que la próxima cuenta de servicio quede sin revisar durante años. La propiedad no puede ser solo una línea en una hoja de cálculo. ¿Quién acepta la alerta cuando la autenticación falla a las 2 a.m.? Si la respuesta es “nadie”, la cuenta no tiene dueño y la pregunta ya no es cómo migrarla, sino si debería existir. Ser propietario implica responsabilidad tanto de desaprovisionar como de mantener disponible.
Cuando la propiedad no esté clara, usar una ventana de desactivación controlada antes de eliminar. Monitorear fallos, restaurar si es necesario y descomisionar solo después de validar dependencias.
Paso 3: Elegir un método por cuenta, no uno para todo
Snowflake ofrece cuatro métodos de autenticación sin contraseña para usuarios SERVICE, cada uno con costos operativos distintos:
- Federación de identidad de carga de trabajo: recomendado por Snowflake, sin secretos, pero requiere que la carga de trabajo se ejecute en un entorno que pueda presentar una identidad federable.
- OAuth externo: robusto, pero requiere experiencia para configurar un IdP de terceros como servidor de autorización.
- Autenticación por par de claves: sin contraseña en la solicitud, pero sigue siendo un secreto de larga duración y sin protección adicional; Snowflake recomienda políticas de red y rotación, pero no las exige.
- Tokens de acceso programático: el reemplazo más directo, con políticas de red y restricción de roles por defecto.
No limitarse a un solo método. La federación es el valor predeterminado correcto cuando la plataforma puede presentar una identidad. El par de claves o un token con alcance de rol es el respaldo cuando no se puede usar, comprometiendo la política de red y la rotación en el mismo cambio. Un secreto de larga duración migrado sin estas medidas pasará la fecha límite, pero es la misma falla de control en un nuevo formato.
Paso 4: Tratar la contraseña reemplazada como comprometida
Suponer que la credencial que se reemplaza ya está en un registro de infostealer. Mandiant y Snowflake encontraron que al menos el 79.7% de las cuentas usadas en la campaña UNC5537 tenían exposición previa de credenciales. La infección más temprana por infostealer vinculada a una de esas credenciales data de noviembre de 2020, lo que significa que esa contraseña seguía funcionando unos tres años y medio después de ser robada.
El corte invalida la contraseña en Snowflake, pero no elimina copias o reutilizaciones en almacenes de secretos, variables de CI, runbooks o endpoints. Buscar reutilización, revocar credenciales dependientes y reducir el alcance de rol durante el mismo cambio.
Los agentes de IA comprimen el mismo problema de ciclo de vida
La fecha límite de Snowflake es un avance del problema de gobernanza que los agentes de IA harán mucho más grande. Snowflake ya reconoce a los agentes de IA automatizados como un tipo de identidad SERVICE_AGENT. La etiqueta es nueva, pero las preguntas de control son familiares: ¿quién es el dueño del agente? ¿Qué identidad usa? ¿Qué puede acceder? ¿Cuándo debería terminar ese acceso?
Solicite una demostración técnica para ver cómo Token Security puede identificar identidades sin dueño, mapear dependencias ocultas y establecer controles de ciclo de vida antes de que la próxima fecha límite de la plataforma obligue a hacerlo.
Deja una respuesta