- Un incendio en la sala de servidores del National Information Resources Service (NIRS) en Daejeon provocó la pérdida total de los datos de la nube G-Drive del gobierno
- Se borraron de forma permanente archivos de trabajo individuales de unos 750 mil funcionarios públicos
- La ausencia de respaldo externo debido a una arquitectura de almacenamiento de gran capacidad y bajo rendimiento fue una debilidad crítica
- Algunos ministerios, en especial el Ministry of Personnel Management, sufrieron daños graves, y la recuperación es limitada
- Se amplían las críticas al sistema de gestión de datos y crecen las exigencias para evitar que vuelva a ocurrir
Resumen del incidente de pérdida del sistema de almacenamiento en la nube del gobierno por el incendio en el NIRS
- Un incendio ocurrido el 27 de septiembre en el edificio principal del National Information Resources Service (NIRS) en Daejeon destruyó el sistema de almacenamiento en la nube G-Drive del gobierno
- Según el Ministry of the Interior and Safety, se eliminaron todos los archivos de trabajo que 750 mil funcionarios públicos habían guardado de manera individual
Daños e impacto
- El incendio se originó en la sala de servidores del quinto piso del centro y causó daños críticos a 96 sistemas de información esenciales para las operaciones del gobierno central y a la plataforma G-Drive
- G-Drive, introducido en 2018, obligaba a los funcionarios a guardar todos los documentos de trabajo en la nube en lugar de hacerlo en sus PC personales
- La estructura ofrecía alrededor de 30 GB de capacidad por persona
Falta de respaldos y causa de la pérdida permanente de datos
- Fue diseñado como un sistema que no realizaba respaldos externos debido a una arquitectura de almacenamiento de gran capacidad y bajo rendimiento
- Esta limitación estructural hizo imposible la recuperación de los datos tras el incendio
Diferencias en los daños por institución
- La magnitud de los daños varía según la institución
- El Ministry of Personnel Management sufrió el mayor impacto porque exigía almacenar todos los documentos en G-Drive
- Algunas instituciones, como la Office for Government Policy Coordination, sufrieron daños relativamente menores
Esfuerzos de recuperación y límites
- Durante el último mes, cada ministerio ha llevado a cabo una recuperación limitada usando datos alternativos, como archivos guardados en PC personales, correos electrónicos, documentos oficiales y registros impresos
- Algunos documentos generados mediante aprobación e informes oficiales también estaban guardados en el sistema Onnara, por lo que existe la posibilidad de recuperar parte de los datos cuando ese sistema sea restaurado
Cuestionamientos al sistema de gestión de datos
- Aunque la mayoría de los sistemas suelen respaldarse diariamente en equipos separados dentro del centro y en instalaciones remotas de respaldo, G-Drive tenía la inusual vulnerabilidad estructural de ser incapaz de realizar respaldos externos
- A raíz de este incidente, aumentan las críticas al sistema de seguridad y gestión de datos del gobierno y se plantea la necesidad de medidas para evitar que se repita
1 comentarios
Comentarios en Hacker News
Me da rabia que no hubiera respaldos, pero quisiera saber más sobre la situación antes de exigir responsabilidades de verdad.
Recuerdo que cuando fui mi primer responsable de computación en 1990~1991, mi mentor me dijo: "Tu trabajo es verificar que los respaldos funcionen; todo lo demás es extra".
En ese entonces el sistema de respaldo en cinta ya estaba saturado, así que empezamos a replicar los datos críticos entre dos sitios con un módem de 14400bps, y cada mes dejaba notas pidiendo un sistema de respaldo que sí funcionara, pero la empresa lo ignoró por costos.
Cuando falló el disco duro del servidor, parecía un problema de baleros; abrí la carcasa del disco y giré el plato con el dedo para mantenerlo vivo unas semanas más. Hice que el gerente lo viera con sus propios ojos para mostrarle qué tan grave era el problema. Al final compraron un disco nuevo, pero no me autorizaron otro adicional para hacer mirroring.
Un mes después de que renuncié, el servidor volvió a fallar y trataron de echarme la culpa, pero mi reemplazo encontró el montón de notas que yo había dejado y pudo aclarar la situación.
Me gustó que al final del artículo dijera claramente:
En realidad, la tecnología LLM se desarrolló originalmente con fines de traducción.
La investigación surgió por la necesidad de crear modelos que pudieran manejar contexto, y luego terminó siendo útil en muchas otras áreas.
En traducción, la tecnología basada en LLM ya lleva más de 5 años usándose con muy buen rendimiento.
Yo he traducido así durante años; incluso antes de los LLM, entre idiomas que domino me salía mucho más rápido pasar primero por traducción automática y luego corregir, que traducir todo desde cero.
(Que la traducción automática sea o no un LLM no cambia mucho el flujo real del trabajo de traducción.)
Sigo pensando que produce resultados completamente inútiles.
Ver este texto sobre cómo la IA me quitó mi trabajo de traductor
Comparto este enlace relacionado.
La cronología da escalofríos.
El mismo día en que ocurrió el incendio era justamente cuando iba a comenzar una inspección gubernamental en sitio relacionada con hackeos de China/Corea del Norte.
Cita de este artículo:
Ver este tipo de cronologías hace que a uno se le quiten las ganas de decir lo correcto y enfrentar al poder.
Dan ganas de simplemente borrar los archivos, tirar el equipo y largarse en autobús a otra ciudad a buscar otro trabajo.
Viéndolo de forma positiva, en lo técnico es muy probable que sí hubiera respaldos (ver sección 1.3).
El problema es el rumor de que esos respaldos están en Corea del Norte o en China.
Qué impacto.
No es lo más importante de este artículo, pero no entiendo por qué incluso los autores siguen defendiendo Proton aunque hasta sus propias cuentas hayan sido suspendidas.
Y eso pese a testimonios de gente vinculada a los servicios de inteligencia coreanos advirtiendo que Proton no es seguro.
Aunque técnicamente fuera perfecto, demuestra que no es una empresa con una brújula moral tan firme como muchos creen.
Supongo que por un tiempo estarán agachando la cabeza los funcionarios que decían que no se podía confiar en AWS/GCP/Azure comerciales.
"El Ministerio del Interior y Seguridad explicó que la mayoría de los sistemas del centro de datos de Daejeon se respaldan a diario en equipos separados dentro del mismo centro y en instalaciones de respaldo físicamente apartadas, pero que, por la estructura de G-Drive, no es posible hacer respaldos externos".
Me parece una situación verdaderamente absurda.
No creo que el problema aquí haya sido negarse a usar empresas extranjeras.
Lo demente fue imponer el uso de almacenamiento externo y aun así no haber hecho realmente los respaldos.
Un incendio es un riesgo básico que se contempla desde el principio, y cuesta creer una gestión tan deficiente que ni siquiera preparó eso.
Estoy de acuerdo en que operar un sistema así de importante sin respaldos fue una barbaridad.
Aun así, sigo pensando que no es apropiado que datos importantes del gobierno estén en una nube extranjera.
Si hubieran usado la nube, la redundancia habría sido fácil de construir, pero esa no era la única opción.
El problema era que el concepto de diseño estaba mal desde el inicio y la estructura no tenía una verdadera duplicación operativa.
Una solución simple para esto habría sido tener un sitio secundario de respaldo con
snapmirrorentre variosnetapp,o usar soluciones open source como
ZFSoDRBD.Hoy existen suficientes alternativas de este tipo al alcance de cualquiera.
La gente cree que estas empresas jamás pierden datos, pero hasta un rayo ha destruido centros de datos (nota relacionada).
Desde la perspectiva del gobierno, los datos no deberían residir en un entorno administrado por una empresa privada de otro país.
Ese es un tema completamente distinto del problema de los respaldos.
En realidad es todavía peor.
Según otros artículos, el volumen total de datos de G-Drive era de 858 TB.
El cálculo es un poco ridículo, pero con AWS S3 todo el respaldo completo habría costado unos 20 mil dólares al mes.
Si lo hubieran bajado a “Glacier deep archive”, habría costado apenas 900 dólares mensuales.
Sí había respaldos, pero todos estaban en la misma sala de servidores (artículo 1, artículo 2).
No se debe tomar como promedio real que cada persona usaba 30 GB.
En la práctica, es muy probable que el uso promedio estuviera más cerca de 0.3 GB.
Dejando de lado los comentarios del artículo, no está del todo claro si de verdad no había ningún respaldo.
Parece seguro que no existía un respaldo "externo", pero sí podría haber habido uno "interno".
Si el sistema no permitía respaldos externos y concentraba todos los datos en un solo lugar, eso también lo convertía en blanco de ataques externos; y por experiencia sé que internamente muchas veces había instalaciones de respaldo físico como un
fire vault(caja fuerte ignífuga o antiexplosión).Claro, si de verdad ni siquiera existía eso, entonces fue un error enorme.
Como referencia, incluso hay artículos académicos de hace décadas que muestran que este tipo de infraestructura de archivado era posible (paper del proyecto de IBM).
Lo curioso es que hace unas semanas pasó algo parecido en Nepal.
Manifestantes incendiaron algunos edificios del gobierno y con ello también se perdió la infraestructura de TI; al final casi todos los datos electrónicos desaparecieron.
Me pregunto si el resultado habría sido distinto si esos documentos hubieran existido en formato analógico.
La ventaja de los datos electrónicos es que se pueden respaldar, pero tampoco creo que la situación hubiera sido mejor si todo hubiera funcionado solo en papel.
¿Serían patriotas anti-autoritarios?
Algo parecido también pasaba en la película Blade Runner.
Hace unos días el sitio de solicitud de GKS (Beca del Gobierno de Corea para Estudiantes Extranjeros) estuvo caído durante varios días, y ahora impacta saber que en realidad se perdieron todos los datos.
Siento que este es justamente el momento de construir un sistema de sitio web mejor.
Mucha información muy importante en Corea desapareció de golpe, y se volvió un tema fuerte en la comunidad; mucha gente lo está comentando.
Estoy seguro de que una parte considerable de datos valiosos desapareció por completo, pero al mismo tiempo me hace sonreír imaginar que en el área administrativa esté circulando un aviso tipo: "Si hay alguien de shadow IT que estuviera operando aunque fuera de manera no oficial una base de datos espejo, puede reportarlo ahora y no se le pedirá ninguna responsabilidad".
Yo mismo en el pasado hice respaldos aparte, aunque fueran no oficiales, cuando el original de los datos realmente críticos cambiaba todo el tiempo o el servidor se apagaba o se descomponía o se corrompía.
Mucha gente dice que el problema fue negarse a usar nubes de EE. UU., pero no creo que ese sea el punto central.
Según el contexto, operar infraestructura propia puede ser una decisión perfectamente razonable.
Pero en un caso como este, el mayor problema fue sacrificar la "disponibilidad" en nombre de la seguridad y la privacidad.
El riesgo de perder datos por desastres físicos (incendios, terremotos) o por errores humanos siempre existe.
Un sistema que no puede prevenir ese tipo de riesgo jamás debería ponerse en producción.
Según la explicación del Ministerio del Interior y Seguridad, la mayoría de los sistemas del centro de datos de Daejeon sí tienen respaldos en otros lugares, pero G-Drive, por su estructura, no permite respaldos externos.
Es decir, conocían ese riesgo y decidieron asumirlo, y este es el resultado.