Snowflake acaba de dejar sin contraseña a las cuentas de servicio de toda su plataforma. No es un capricho: en 2024 entraron a 165 empresas usando credenciales robadas años antes que seguían siendo perfectamente válidas. Una de ellas venía de una infección de noviembre de 2020. Cuatro años después, todavía abría la puerta.
Es tentador leer esto como un problema de Snowflake y seguir de largo. Sería un error. En tu empresa hay usuarios que no son personas —los que usan el backup, el sistema de facturación para consultar la base, el script que sincroniza el e-commerce, el monitoreo, la integración con el banco— y casi con seguridad ninguno cambió su contraseña desde el día que se creó.
Qué hizo Snowflake
Snowflake está eliminando la autenticación por contraseña para las cuentas que usan las aplicaciones. Creó un tipo de usuario llamado SERVICE que, por diseño, no puede tener contraseña: su propia documentación lo dice sin vueltas y marca como obsoleto el tipo anterior. Las cuentas viejas tienen que migrar durante el segundo semestre de 2026.
En lugar de contraseña, esas cuentas tienen que autenticarse con alguno de estos métodos:
- Identidad federada de la carga de trabajo: el servicio se identifica por lo que es y dónde corre, sin ningún secreto guardado. Es la opción recomendada.
- OAuth externo: contra el proveedor de identidad que ya usa la empresa.
- Par de claves: sin contraseña, pero sigue habiendo un secreto de larga vida que alguien tiene que custodiar.
- Tokens de acceso programático: el reemplazo más directo, y por eso el que más tienta. Exige política de red asociada.
Lo interesante no es la lista. Es que la parte difícil de esta migración no es técnica.
El caso que los llevó hasta acá
En junio de 2024, Mandiant publicó el análisis de una campaña contra clientes de Snowflake. Los números son incómodos de leer:
- 165 organizaciones notificadas como potencialmente expuestas.
- 79,7% de las cuentas usadas por el atacante ya tenían la credencial filtrada antes del ataque, robada por programas que roban contraseñas de máquinas infectadas.
- La infección más antigua asociada a una credencial comprometida databa de noviembre de 2020.
- Hubo credenciales que siguieron siendo válidas durante cuatro años, sin rotación ni cambio.
Ninguna de esas cuentas tenía segundo factor. Ninguna de esas instancias tenía restricción de red. No hubo una vulnerabilidad exótica ni un exploit de día cero: hubo usuarios y contraseñas que funcionaban, y nadie del otro lado que se preguntara por qué.
Esto no es un problema de Snowflake
Cambiá "Snowflake" por cualquier cosa que tengas conectada y la historia se repite. Las cuentas de servicio viven en lugares que nadie mira:
- El archivo de configuración del servidor, con la clave escrita en texto plano.
- El sistema que hace los despliegues, con una credencial que puede tocar producción.
- La tarea programada que corre a las tres de la mañana desde hace seis años.
- El usuario que creó el proveedor que ya no trabaja con vos, y que nadie dio de baja.
- La integración con el banco, con la AFIP, con el marketplace, con el CRM.
- El equipo de monitoreo que tiene acceso de lectura a todo, "porque era más fácil".
Todas esas credenciales comparten tres características: no vencen, no tienen dueño y nadie las audita. Y a diferencia de la contraseña de una persona, cuando alguien se va de la empresa nadie las da de baja, porque no están asociadas a ninguna persona.
Las cuatro preguntas que casi nadie puede contestar
Cuando hacemos un relevamiento, este es el bloque que más incomoda. Sobre cada usuario que no es una persona:
- ¿Quién la creó y para qué? Si la respuesta es "estaba cuando llegué", ya tenés un problema.
- ¿Qué permisos tiene realmente? Casi siempre son más de los que necesita, porque se le dieron todos para que "funcione de una vez".
- ¿Cuándo se rotó por última vez? Si nunca, la credencial tiene la antigüedad del sistema.
- ¿Qué se rompe si la desactivo? El miedo a esta pregunta es exactamente lo que mantiene viva una contraseña de 2020.
Qué hacer, y en qué orden
No empieza por comprar nada. Empieza por hacer una lista.
- Inventario. Todos los usuarios que no son personas, en cada sistema: base de datos, nube, ERP, correo, backup, integraciones. Una planilla alcanza para arrancar.
- Dueño. Cada cuenta necesita una persona responsable, con nombre y apellido. Sin dueño, nadie va a decidir nunca si se puede apagar.
- Método de autenticación. Donde se pueda, sin secreto: identidad federada o roles temporales. Donde no, par de claves o token, guardados en un gestor de secretos y nunca en el código.
- Rotación con procedimiento. Una fecha y un instructivo escrito de cómo se cambia, probado al menos una vez. Rotar sin procedimiento es cómo se rompe producción un viernes.
- Mínimo privilegio. Bajar permisos de a poco y ver qué se queja. Es tedioso y es lo que más reduce el daño de una credencial filtrada.
- Restricción de red. Que la credencial solo sirva desde donde tiene que servir. En el caso de 2024, esto solo habría cortado buena parte del ataque.
- Alerta de uso raro. Que un acceso desde un país o un horario inusual genere un aviso, no una línea en un log que nadie lee.
Ninguno de estos siete puntos es difícil. Lo difícil es que no son de nadie: no entran en el proyecto de desarrollo, no entran en la compra de infraestructura y no aparecen hasta que hay un incidente.
El fondo del asunto
Snowflake no está resolviendo un problema de contraseñas. Está resolviendo un problema de operación: sistemas que se ponen en marcha y después quedan andando solos durante años, sin nadie que los mire.
Es exactamente lo que pasa con una plataforma en la nube cuando el proyecto termina y el equipo pasa a lo siguiente. Los servidores siguen funcionando, entonces parece que está todo bien. Hasta que se descubre que el backup no restaura, que el certificado venció el martes o que hay una credencial de hace cuatro años dando vueltas por internet.
Ese trabajo aburrido y constante —inventariar, rotar, parchear, monitorear, probar— es un servicio, no una tarea suelta. En Tecnicanet lo hacemos todos los días: mirá Soporte y operación de plataformas cloud, donde la gestión de secretos y el mínimo privilegio están en el abono, no en la lista de buenas intenciones.
Y si querés empezar por saber qué tenés, una auditoría tecnológica es el punto de partida: la lista de cuentas, permisos y accesos que hoy no está escrita en ningún lado.
Fuentes
- BleepingComputer — Snowflake ends service-account passwords. Now comes the hard part (26 de agosto de 2026).
- Documentación de Snowflake — Managing users: el tipo de usuario SERVICE no puede iniciar sesión con contraseña, y LEGACY_SERVICE está obsoleto.
- Mandiant / Google Cloud — UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion (10 de junio de 2024).