Resumen de la publicación
Nine PBS, la estación de televisión pública de San Luis (Misuri), pasó cinco meses sin poder acceder a 50 TB con 70 años de su archivo histórico porque su proveedor de cloud storage, Open Source Storage, dejó de responder y le cortó el acceso de un día para el otro. Tuvo que judicializar el caso para que un juez le reconociera la propiedad de sus propios datos.
El caso me sirve de excusa para algo que vengo repitiendo hace años: el cloud no te exime de la regla 3-2-1 de backups, y un contrato sin cláusulas de salida verificables es un rehén esperando rescate. Acá va el análisis del caso, las preguntas que le tenés que hacer a cualquier proveedor y un checklist accionable para pymes y organizaciones argentinas.
Hay una fantasía muy instalada en IT: «lo subimos a la nube, ya está protegido». Y cada tanto la realidad se encarga de recordarnos que la nube es, literalmente, la computadora de otro.
El recordatorio de esta semana viene de la televisión pública de Estados Unidos, y es de manual: 50 terabytes de archivo histórico como rehenes, no de un ransomware, sino de un proveedor que simplemente dejó de atender el teléfono.
El caso: 70 años de archivo detrás de una puerta que nadie atiende
Nine PBS es la estación afiliada a PBS de San Luis, Misuri. Según reportó Ars Technica, guardaba con un proveedor llamado Open Source Storage (OSS) más de 50 TB y 11.000 archivos: cobertura de la pandemia, la gran inundación de 1993, la historia de East St. Louis. Setenta años de material que la propia estación describe como «único e irremplazable».
En febrero de este año, la estación intentó reunirse con OSS para renovar el contrato que vencía el 6 de marzo. OSS nunca respondió y, llegada la fecha, cortó el acceso sin aviso, ignorando la cláusula que le daba a Nine PBS 30 días para retirar sus datos tras la terminación del servicio.
Acá aparece el detalle que hace al caso tan instructivo. Los servidores con los datos no estaban en un edificio de OSS: estaban alojados en un datacenter de Iron Mountain en Denver, contratado por OSS. Cuando OSS quedó inoperante, Iron Mountain se negó a entregar el material con un argumento formalmente impecable: su cliente era OSS, los servidores son activos de OSS, y ella no tiene acceso a los datos ni contrato alguno con la estación.
Nine PBS terminó demandando a Iron Mountain el 28 de julio en un tribunal de Denver. Recién a mediados de agosto un juez reconoció que los datos son de la estación, prohibió borrarlos o modificarlos y ordenó a Iron Mountain cooperar con la recuperación, que igual va a requerir un tercero técnico que extraiga el material sin tocar datos de otros clientes de OSS.
Leelo de nuevo: hizo falta una demanda judicial y cinco meses para que alguien le confirme a una organización que es dueña de sus propios archivos. Y todavía no los recuperó.
Qué salió mal (spoiler: la tecnología, nada)
Lo primero que me llama la atención es que acá no falló ni un disco ni un datacenter. Los datos están intactos, físicamente sanos, en servidores que funcionan. Lo que falló es todo lo demás.
- Copia única en la nube. Por lo que se desprende del caso, buena parte de ese material no tenía otra copia accesible. Si la tuviera, esto sería una molestia contractual, no una amenaza existencial.
- Cadena de custodia invisible. Nine PBS contrató a OSS, pero sus datos vivían en infraestructura de Iron Mountain, con quien no tenía ningún vínculo legal. Cuando el eslabón del medio desapareció, la estación quedó sin interlocutor.
- Cláusula de salida sin garantía. El contrato tenía sus 30 días de gracia para retirar los datos. En los papeles, perfecto. Contra un proveedor que hace «ghosting» (que desaparece sin dar señales), una cláusula que nadie puede ejecutar vale lo mismo que nada.
- Señales de alarma ignoradas por diseño. Un proveedor que no te contesta para renovar un contrato ya te está contando cómo se va a portar cuando tengas un problema de verdad.
Y no es un caso aislado ni una rareza de la TV pública. En 2013, el pionero del cloud storage Nirvanix quebró y les dio a sus más de mil clientes dos semanas para llevarse los datos; algunos tenían ahí cerca de un petabyte, y era su única copia. En 2014, el servicio de hosting de código Code Spaces cerró en cuestión de horas cuando un atacante que tomó el control de su cuenta de AWS borró producción y backups juntos, porque los backups vivían en la misma cuenta.
Tres épocas distintas, tres causas distintas (quiebra, ataque, abandono) y exactamente la misma lección.
El cloud no deroga la regla 3-2-1
La regla 3-2-1 es vieja, aburrida y sigue vigente: tres copias de tus datos, en dos medios distintos, con al menos una fuera del sitio principal. Lo que muchos entendieron mal es que «lo subí a la nube» cuenta como cumplirla.
No cuenta. La nube es una de las copias, en uno de los medios, en uno de los sitios. Si es tu única copia, no tenés backup: tenés un único punto de falla con mejor marketing.
Desde mi punto de vista, el error de fondo es confundir dos riesgos que no se cubren igual. La durabilidad técnica (que no se rompa el disco) el proveedor la resuelve muy bien, mejor que vos. Pero el riesgo de acceso (que el proveedor quiebre, te bloquee, te ignore o cambie las condiciones) no lo cubre ningún porcentaje de nueves de durabilidad, porque el proveedor es justamente la fuente del riesgo.
Es el mismo razonamiento que apliqué cuando analizamos el caso de Tesco contra Broadcom: cuando dependés de un solo proveedor sin salida practicable, el problema no es técnico, es de poder de negociación. Con el storage es peor, porque lo que queda del otro lado del mostrador no es una licencia: son tus datos.
Las preguntas que le tenés que hacer a tu proveedor (antes de firmar)
Nada de esto es exótico ni caro de preguntar. Es incómodo, nomás, porque interrumpe la demo linda. Estas son las que yo haría hoy en cualquier contratación de storage o SaaS con datos críticos:
- ¿Cuál es el SLA de recuperación? No el de disponibilidad del servicio: el de devolución de MIS datos. ¿En cuánto tiempo, por qué canal y a qué costo de egreso me entregás todo?
- ¿En qué formato exporto? Si la respuesta es un formato propietario que solo lee su plataforma, la salida es teórica. Formatos abiertos y documentados, o no hay trato.
- ¿Dónde están físicamente los datos y quién más está en la cadena? Nine PBS aprendió a la fuerza que su contraparte real era una empresa con la que nunca firmó nada. Pedí que el contrato nombre a los subcontratistas de infraestructura y qué obligaciones asumen.
- ¿Qué pasa si quiebra, es adquirido o deja de responder? Para software existe el «escrow» (un depósito del código en manos de un tercero neutral que se libera si el proveedor desaparece); para datos, el equivalente es una réplica automática hacia una cuenta o ubicación que controlás vos.
- ¿La cláusula de salida se puede ejecutar sin su cooperación? Los 30 días de gracia de Nine PBS dependían de que OSS atendiera. Una salida real no depende de la buena voluntad del que se está yendo.
Checklist para pymes y organizaciones argentinas
Si gestionás IT en una pyme, una ONG, un colegio o un organismo, esto es lo que haría esta semana, en orden:
- Inventariá qué datos viven SOLO en un proveedor. Microsoft 365, Google Workspace, el ERP en la nube, el CRM, el NAS «que sincroniza». Todo lo que tenga una sola copia va a una lista roja.
- Aplicá 3-2-1 a la lista roja. Una segunda copia en otro proveedor o en un medio propio (un disco externo rotado ya es infinitamente mejor que nada), y que una copia esté fuera de la cuenta principal, con otras credenciales.
- Probá una restauración real por trimestre. Elegí un sistema, restauralo de punta a punta y medí cuánto tardaste. Backup que nunca se restauró es una hipótesis, no un backup.
- Ensayá la salida de tu proveedor principal. Exportá una muestra completa de datos hoy, con el contrato vigente y el proveedor contento. Si con todo a favor ya es doloroso, imaginate en conflicto.
- Revisá los contratos con las preguntas de arriba. Y si el proveedor es chico o poco conocido, agregá una: ¿quién me devuelve los datos si mañana no atienden más el teléfono?
- Documentá quién tiene las llaves. Credenciales, claves de cifrado y contactos del proveedor no pueden vivir en la cabeza de una sola persona ni en la bandeja de entrada de un ex empleado.
¿Podés irte mañana?
A Nine PBS un juez le acaba de dar una salida, y me alegro. Pero la salida buena no era esa: era la copia que tendría que haber existido en otro lado, la que convierte un proveedor desaparecido en un trámite en vez de en una demanda.
La pregunta que te dejo es la que me hago yo con cada servicio que contrato: si este proveedor deja de responderme hoy, ¿pierdo un servicio o pierdo mis datos? Si la respuesta honesta es la segunda, ya sabés qué hacer esta semana. Te leo en los comentarios.
