Lecciones aprendidas de las diez mayores caídas de entornos ‘cloud’

Le podrá sorprender o no, pero siempre he sido de pedir copias de seguridad independientes de todo. Así que hágame caso: tanto su copia de seguridad está albergada en su centro de datos, en un proveedor de IaaS como AWS, o en un proveedor de SaaS como Microsoft 365, haga copias de seguridad independientes. Sin embargo, no son pocos los que creen que debemos confiar en que los proveedores de la nube hacen lo correcto. ¿Qué podría pasar de malo?

Quince años de incidentes de pérdida de datos en la nube dan una idea bastante aproximada de lo grave que puede resultar una interrupción en la nube. En mi podcast, The Backup Wrap-up, hace poco repasamos diez catástrofes en la nube que tuvieron lugar en los últimos quince años. Aquí las tiene ordenadas de manera alfabética:

· Carbonite (2009): debido a la falta de redundancia y el uso de matrices de almacenamiento de consumo, Carbonite perdió los datos de copia de seguridad de miles de clientes en un incidente grave. En lugar de asumir su responsabilidad, culpó a su proveedor de almacenamiento.

· Code Spaces (2014): Un hacker accedió y borró todos los datos y copias de seguridad de clientes del entorno AWS de Code Spaces. Como resultado, la empresa quebró.

· Dedoose (2014): un fallo del servicio eliminó tanto la base de datos de investigación principal de Dedoose como sus copias de seguridad, que la compañía realizaba sólo de manera mensual. El resultado fue la pérdida de datos de más de un mes para muchos investigadores.

· KPMG (2020): un administrador cambió accidentalmente una política de retención de Microsoft Teams, lo que provocó la eliminación permanente de datos y archivos de chat de más de 145.000 empleados. Las políticas de retención nativas de Microsoft 365 no permitían la recuperación. De hecho, fueron la causa de la pérdida de datos.

· Musey/Moss (2019): Una startup eliminó accidentalmente la cuenta de Google de toda su organización, lo que supuso la pérdida instantánea de datos e IP por valor de más de un millón de dólares. Google no pudo restaurar los datos, ya que no existía ninguna copia de seguridad independiente.

· OVH (2021): un incendio destruyó los servidores de los centros de datos de OVH en Estrasburgo. Muchos clientes perdieron datos, ya que el servicio de copia de seguridad incluido de OVH almacenaba las copias de seguridad en los mismos centros de datos.

· Rackspace (2022): el entorno Exchange alojado de Rackspace sufrió un ataque de ransomware. La lentitud de los parches facilitó el ataque y la recuperación tardó meses, incluso con las copias de seguridad incluidas. Al final, Rackspace cerró el negocio de Exchange alojado.

· Salesforce (2019): Un script defectuoso otorgó a todos los usuarios de Salesforce permisos de modificación total hasta que se solucionó. Las copias de seguridad de Salesforce no permitían restaurar rápidamente los permisos adecuados, lo que demuestra la necesidad de copias de seguridad SaaS independientes.

· StorageCraft (2024): durante una migración a la nube, StorageCraft desmanteló por accidente un servidor antes de tiempo, lo que provocó la pérdida de los metadatos de copia de seguridad de los clientes e inutilizó sus copias de seguridad. El director general asumió toda la responsabilidad y trabajó para ayudar a los clientes a reeditar dichsd copias.

· UniSuper/Google Cloud (2024): Google borró por accidente todo el entorno de nube de UniSuper en todas las regiones debido a un error de configuración. Sin embargo, las copias de seguridad de terceros de UniSuper permitieron la recuperación completa en una semana.

Consejos

Dedíquese por un momento a reflexionar sobre las duras lecciones que se pueden extraer y aprender de todas estas historias de pérdida de datos e interrupción del negocio. Lo primero y más importante: la nube no es un reino mágico de redundancia infinita y copias de seguridad automáticas. No es más que el ordenador de otra persona y, como cualquier ordenador, las cosas pueden salir mal y saldrán mal. Lo hemos visto una y otra vez, desde el incendio del centro de datos de OVH hasta el ataque de ransomware de Rackspace. Sus datos están tan seguros como las precauciones que usted y su proveedor de nube tomen para protegerlos.

¿Cuál es la lección más importante? Haga copias de seguridad de sus datos en la nube. Y no me refiero sólo a confiar en los servicios de copia de seguridad integrados de su proveedor. Como vimos con Carbonite, StorageCraft y OVH, esas copias de seguridad pueden evaporarse junto con sus datos primarios si se produjera un desastre. Hay que seguir religiosamente la regla 3-2-1: conservar al menos tres copias de los datos, en dos soportes distintos, con una copia fuera de las instalaciones. Y en el contexto de la nube, “diferentes soportes” significa no almacenar todo en el mismo tipo de sistema; utilizar diferentes dominios de fallo. Además, “fuera del sitio” significa en una cuenta en la nube completamente separada o, incluso mejor, con un proveedor de copias de seguridad externo.

Pero no se trata sólo de tener copias de seguridad, sino de contar con el tipo adecuado de copias de seguridad. Tomemos como ejemplo el incidente de StorageCraft: se perdieron los metadatos de las copias de seguridad de los clientes durante una migración fallida a la nube, lo que las dejó inservibles. Esto subraya la importancia no sólo de hacer copias de seguridad de los datos primarios, sino también de mantener la integridad y la recuperabilidad de los datos de las copias de seguridad.

Otra dura realidad: los proveedores de SaaS tampoco son inmunes a la pérdida de datos. El fiasco de los permisos de Salesforce y la metedura de pata de la política de retención de equipos de KPMG demuestran que incluso los grandes nombres de SaaS pueden destruir accidentalmente sus datos. Y como vimos con Dedoose, a veces sus capacidades de recuperación son muy limitadas. Por eso es crucial realizar copias de seguridad de los datos de SaaS de forma independiente, utilizando una solución de terceros que le permita controlar las copias de seguridad y la recuperación.

Ahora, sé lo que algunos de ustedes pueden estar pensando: “Pero Curtis, mi proveedor de nube ofrece georredundancia y replicación multiregión. ¿No es suficiente?” Pregúntele a UniSuper cómo les funcionó. Google borró accidentalmente todo su entorno en la nube en varias regiones. Si no hubiera sido por las copias de seguridad de terceros de UniSuper, se habrían ido al garete.

Por último, hablemos del elemento humano. Muchos de estos desastres, como el hackeo de Code Spaces o el borrado de la cuenta Musey de Google, se debieron a errores humanos o a malas prácticas de seguridad. Es un duro recordatorio de que no importa lo sofisticada que sea su infraestructura en la nube, sus datos son tan seguros como su eslabón más débil. Eduque a su equipo, aplique controles de acceso y medidas de seguridad sólidas y tenga siempre, siempre, un plan de respuesta a incidentes probado.

Quiero reiterar algo que he dicho antes. En esta lista de diez desastres en la nube, sólo una empresa salió ilesa, y es la que tenía una copia de seguridad de terceros probada de sus datos en la nube. Si eso no basta para convencerte de que lo haga, no sé qué más le puedo decir.

La nube es una herramienta increíblemente poderosa, pero no es una bala de plata para la protección de datos. Confía, pero verifica. Haz copias de seguridad de tus datos como si tu negocio dependiera de ello, porque así es. Aprenda de las desgracias ajenas y no permita que su organización se convierta en otro cuento con moraleja. Recuerde que hay dos tipos de personas en este mundo: las que han perdido datos y las que los perderán. Asegúrese de estar preparado para cuando llegue ese día.

Source: Computerworld.es