Ciberataque a Rosstat: siete días sin publicar datos y qué enseña sobre continuidad
Rosstat confirmó un ciberataque coordinado contra sus servicios online entre el 29 de octubre y el 1 de noviembre. Una semana después, los sistemas siguen sin restaurarse y los informes económicos están retrasados hasta el 13 de noviembre.
Qué pasó con Rosstat y por qué importa
Rosstat es el servicio federal de estadísticas de Rusia: inflación, precios, población y actividad económica. De ahí salen las series que usan analistas, medios y empresas, y buena parte de ese trabajo se publica desde sus propios sistemas web.
Ataques coordinados entre el 29 de octubre y el 1 de noviembre
La agencia reconoció el ataque a sus servicios online en esa ventana, y Tom's Hardware sitúa los golpes a los servidores entre el 29 y el 31 de octubre. Dos grupos, Silent Crow y los Belarusian Cyber Partisans, se atribuyeron la operación: dicen haber entrado en la red interna, con acceso a unas 25.000 máquinas y 23 TB de datos, incluidos datos de bajas de la guerra.
Una semana después, los informes siguen retrasados
El 7 de noviembre Bloomberg reportó que los sistemas seguían caídos: los informes económicos están retrasados al menos hasta el 13 de noviembre, dos publicaciones semanales de precios se postergaron varias veces antes de salir y parte de lo ya publicado desapareció del sitio. Los plazos administrativos también se corrieron: los formularios P-1 y C-1 se pueden entregar hasta el 13.
Lee también
Los datos que sí están confirmados y los que no
Lo que la agencia reconoció
El ataque, la ventana de fechas, los retrasos y la extensión de plazos para las empresas. Eso está en su comunicación y en la prensa que la cita.
Lo que afirman los atacantes y la agencia niega
El volumen de 23 TB, el acceso a 25.000 equipos y los datos de bajas son afirmaciones de los atacantes. Rosstat admitió el ataque y negó el robo. Sin verificación independiente, esto se escribe como lo que es, un reclamo: un dato filtrado que nadie pudo contrastar no es un dato, es una versión.
Qué se rompe primero cuando una web de datos se cae
El calendario de publicación es el primer servicio que pierde el usuario
Quien consulta una serie estadística no necesita el servidor: necesita el dato del mes en la fecha en que lo esperaba. Si esa fecha pasa, el usuario se fue a otra fuente. Aquí hay dos relojes: el del sistema, que se mide con RTO (cuánto tardas en volver), y el del calendario, que se mide con RPO (cuántos datos puedes perder). Un RTO de dos días suena razonable hasta que el compromiso era semanal y la semana ya se consumió.
Los plazos administrativos se arrastran detrás del sistema caído
Cuando la web que recibe los formularios no funciona, el plazo legal se mueve con ella. El costo deja de ser un sitio caído: es un trámite de terceros reabierto.
Las tres decisiones que evitan una semana caído
Copias inmutables con una restauración que se prueba
Tener backup no es tener recuperación: la copia que nunca se restauró en un entorno limpio es una hipótesis. Copia inmutable u offline contra el cifrado por ransomware, y un ensayo de restauración con tiempo medido. Si no sabes cuánto tardas en volver, no tienes RTO, tienes una esperanza. La misma lógica sirve para el parcheo: una vulnerabilidad crítica sin autenticación no espera a que tengas tiempo libre.
Publicación en modo lectura desde estáticos
El último estado bueno se puede guardar en HTML y CSV estáticos. Cuando el sistema transaccional cae, se sirve ese snapshot en solo lectura con la fecha del corte visible, en lugar de un 503 durante una semana. El dato es viejo y se dice: el usuario prefiere un dato fechado a una pantalla de error.
Plan de comunicación con fecha, no con "estamos trabajando"
Un aviso con fecha concreta, del tipo "el informe sale el 13", reduce consultas y sostiene la confianza. Siete días de "estamos trabajando en ello" convierten un incidente técnico en un problema de reputación.
Conclusión
El ataque se contiene; la semana sin datos no se recupera. El daño grande no lo hizo el hack, lo hizo el calendario parado. Si mantienes sistemas que publican con fecha, revisa hoy tres cosas: cuándo probaste la última restauración, qué snapshot servirías si la base no responde y a quién le darías una fecha concreta. En el blog seguimos desarmando las noticias de infraestructura que terminan en tu servidor.
