De qué te protege cada copia
No todas las copias sirven para lo mismo.
| Qué ocurre | Copia en el mismo servidor | Copia fuera del servidor | Segunda copia que el servidor no puede borrar |
|---|---|---|---|
| Falla el disco o se pierde el servidor | No | Sí | Sí |
| Una actualización o un error estropea los datos | Sí | Sí | Sí |
| Alguien entra en el servidor y borra o cifra todo lo que encuentra | No | Depende de la clave que guarde el servidor | Sí, lo guardado antes de la intrusión |
El punto débil: la llave de las copias
La copia puede estar lejos y aun así estar al alcance del atacante.
Para subir una copia a otro sitio, el servidor necesita una clave de acceso, y a menudo esa clave sirve para todo: escribir, leer y borrar. Quien consiga entrar en el servidor puede hacerse con ella y llegar hasta las copias. Por eso muchos ataques de ransomware van a por ellas antes de cifrar nada: sin copias, pagar parece la única salida.
Guardarlas fuera del servidor sigue siendo imprescindible, pero no resuelve esto por sí solo.
Una segunda copia que el servidor no pueda borrar
La idea es sencilla: dar al servidor solo el permiso que necesita.
La segunda copia va a un almacenamiento separado, con otra credencial, y esa credencial solo permite crear ficheros nuevos. No deja leerlos, sobrescribirlos ni borrarlos. El borrado de las copias antiguas lo hace una regla del propio almacenamiento, no el servidor.
Si alguien entra en el servidor, podrá añadir ficheros, pero las copias ya guardadas siguen fuera de su alcance. Es la misma idea de la conocida regla 3-2-1 (tres copias de los datos, en dos soportes distintos y una de ellas en otro lugar), con una condición más: que una de esas copias quede fuera del alcance de quien controle el servidor.
Tampoco es magia. Las copias que se hagan después de la intrusión pueden estar afectadas. Lo que protege esta copia es lo guardado hasta entonces, y por eso importa cuánto tiempo se conserva: si la intrusión dura más que ese plazo, las copias buenas también caducan.
Cuánto tiempo guardarlas
Tres días de copias no sirven de mucho si el atacante lleva dos semanas dentro.
Cuando se descubre un ataque, hay que restaurar una copia de antes de que empezara, y no siempre es la última. Como punto de partida, conviene poder volver atrás al menos unas semanas. Un mes suele ser un mínimo razonable. Si los datos cambian mucho o la actividad depende de ellos, puede merecer la pena guardar más.
Una copia sin restaurar es una suposición
El día que la necesitas no es el mejor día para descubrir que falta algo.
Probar una copia es recuperarla en un entorno aparte y compararla con el original. A nosotros nos enseñó algo: la primera vez que lo hicimos, los datos estaban todos, pero la copia no incluía los índices de la base de datos, que son los que hacen que una aplicación responda rápido, y habría habido que recrearlos a mano. Lo corregimos y lo comprobamos de nuevo. Sin esa prueba lo habríamos descubierto en el peor momento.
Qué preguntarle a tu proveedor
Cinco preguntas que no deberían incomodar a nadie.
| Pregunta | Respuesta que quieres oír |
|---|---|
| ¿Dónde se guardan las copias? | Fuera del servidor donde está la web. |
| Si alguien entra en el servidor, ¿puede borrarlas? | Al menos una copia queda fuera de su alcance. |
| ¿Hasta cuándo puedo volver atrás? | Una cifra concreta, de varias semanas. |
| ¿Cuándo se probó a restaurar por última vez? | Una fecha y el resultado de la prueba. |
| ¿Qué incluye la copia? | Una lista clara de qué entra y qué no. |
Cómo lo hacemos nosotros
Lo que hacemos con las copias de las webs que alojamos.
Cada noche copiamos las bases de datos de las webs y aplicaciones que alojamos y las guardamos fuera del servidor. Y las hemos restaurado una a una para compararlas con los datos originales. Si esas copias se borran por error o por una regla mal aplicada, se pueden recuperar durante varias semanas. Contra quien se haga con la clave del servidor eso no basta, y por eso hacemos la segunda copia.
Es la que describimos en este artículo: va a un almacenamiento separado de Microsoft Azure, con una credencial que solo permite crear ficheros. Cubre las bases de datos; los ficheros de las aplicaciones no entran en ella. Las copias de seguridad van en la cuota anual de nuestro mantenimiento de páginas web. Las demás capas las contamos en qué debe tener un hosting seguro.
Si no tienes claro qué pasaría con tus copias, cuéntanoslo y lo miramos contigo.
Háblanos de tu web
