Saltar a contenido

Continuidad: sobrevivir cuando todo lo demás falla

Traducción automática del original francés.

La prevención, la detección y la respuesta pueden fallar. En ese caso, lo que queda es poder reconstruir. Por lo tanto, la pregunta de esta sección no es "¿ha funcionado la copia de seguridad?", sino "¿podré reconstruir, y en qué tiempo?". Estas dos preguntas tienen respuestas diferentes.

Los términos técnicos se refieren al glosario.

Cuatro niveles de copia de seguridad

flowchart LR
    classDef src fill:#3f3f46,stroke:#3f3f46,color:#fff
    classDef bk fill:#1e40af,stroke:#1e40af,color:#fff
    classDef off fill:#0f766e,stroke:#0f766e,color:#fff

    subgraph hotes["Hôtes du parc"]
        h["Hôtes de conteneurs · machines virtuelles<br/>hôte GPU · serveur hors site"]:::src
    end

    cli["Client de sauvegarde par hôte<br/>restic · chiffré AVANT l'envoi"]:::bk
    rest["Serveur de dépôt, sur le NAS<br/>ajout seul : aucune suppression<br/>depuis les hôtes"]:::bk
    snap["Instantanés du NAS"]:::bk
    rep["Réplication hors site"]:::off
    o1["Fournisseur hors site n° 1"]:::off
    o2["Fournisseur hors site n° 2"]:::off
    git["Configuration et décisions<br/>git, deux dépôts distants"]:::off

    h --> cli --> rest
    rest --> snap
    snap --> rep
    rep --> o1
    rep --> o2
    h --> git
Nivel Contra qué protege
1 · Copia cifrada por el usuario Pérdida de un host, eliminación, corrupción de la aplicación
2 · Instantáneas del NAS Error humano en el almacenamiento, corrupción del propio repositorio
3 · Dos copias fuera del sitio, en dos proveedores distintos Pérdida de todo el sitio — desastre, robo, ransomware que afecta al NAS
4 · git en dos repositorios remotos Pérdida de la configuración, archivos de composición, decisiones

El cifrado se realiza por el usuario, antes de enviarlo: ninguno de los servidores de copia de seguridad posee las claves de los datos que guarda. Cada host tiene su propio cliente, su repositorio y su plan de recuperación; se planifica la verificación de la integridad de los repositorios.

La inmutabilidad: la cuestión del ransomware

Un [ransomware](glossaire.md#rancongiciel moderno no solo cifra los datos: busca las copias de seguridad, junto con los accesos que encuentra en la máquina comprometida. Por lo tanto, la pregunta clave es:

¿Quién toma un host puede también destruir sus copias de seguridad?

El concepto que se refiere es la [inmutabilidad](glossaire.md#immuabilite: una copia de seguridad que no se puede modificar ni eliminar desde el host original.

  • El servidor de respaldo funciona de forma independiente. Un cliente puede crear nuevos respaldos; no puede eliminarlos ni modificarlos. La eliminación de los respaldos antiguos se realiza mediante otros accesos.
  • Fuera del sitio, la inmutabilidad es garantizada por el propio proveedor: ya sea mediante el bloqueo de objetos glossaire.md#object-lock, o mediante la creación de respaldos que los accesos de replicación no pueden alcanzar.

Cómo verificarlo: intentándolo

La inmutabilidad no se lee en una configuración. Se demuestra mediante los accesos que realmente tiene el host: se intenta eliminar un respaldo y se espera que se rechace. Una sonda repite este gesto regularmente. Una respuesta positiva (la eliminación ha tenido éxito) es un fallo en la comprobación, no un éxito en la prueba.

Por qué 'fresco' no es suficiente

Las comprobaciones de frescura responden a la pregunta "¿ha realizado la copia de seguridad?". Un ransomware crea copias de seguridad frescas: del contenido cifrado, en un momento específico, sin errores. Solo la inmutabilidad y un ejercicio de restauración con datos antiguos responden a la pregunta "¿podré recuperar?".

Recuperar de verdad: el ejercicio cronometrado

Un respaldo que nunca se ha restaurado es una hipótesis. El [ejercicio de restauración] glossaire.md#exercice lo convierte en una acción:

  1. elegir un conjunto representativo: una base de datos, archivos, caché;
  2. crear una nueva máquina virtual desechable, que nunca haya tenido contacto con el conjunto;
  3. restaurar desde los respaldos, sin copiar nada de la máquina original;
  4. cronometrar hasta que la API de la aplicación responda normalmente;
  5. determinar la antigüedad de los datos recuperados;
  6. destruir la máquina.

Le premier exercice a donné un RTO de l'ordre de trois minutes, et un RPO d'environ une journée — près de deux dans le pire cas, selon le moment de la panne par rapport à la dernière sauvegarde. Ce sont des chiffres mesurés, pas des objectifs recopiés d'un plan.

Chaque exercice est consigné dans un registre. Une sonde passe au rouge si le dernier Más de 90 días: una restauración probada realizada hace un año no garantiza que las restauraciones actuales funcionen de la misma manera.

El RTO medido es un mínimo, no el de una situación catastrófica

Las variables de entorno de un stack nunca se escriben explícitamente: están cifradas en el repositorio, y se descifran en memoria al arrancar. Al restaurarse desde la copia de seguridad, vuelven a aparecer en forma de un enlace a un archivo que ya no existe.

Restaurar una pila requiere, por lo tanto, dos cosas más que la copia de seguridad: la caja de secretos, y la clave que la descifra. El ejercicio se llevó a cabo con la clave disponible. Su valor es para un incidente ordinario; no es válido para un incidente en el que la clave hubiera desaparecido junto con el resto. De ahí la siguiente sección.

La clave maestra — el único escenario de pérdida total

Todos los secretos de las pilas están cifrados con una única clave maestra. Perder la clave privada significa perder todos los secretos — incluso en el historial de Git, donde las versiones cifradas permanecen para siempre y se vuelven ilegibles para siempre.

Y la dependencia es circular: la caja de secretos es en sí misma una pila. Recuperar la clave de una caja que ya no se puede iniciar debido a la falta de clave es un bucle cerrado.

La solución es una copia fuera de línea: en papel, conservada fuera de la pila, sin ninguna conexión de red.

Una copia que nunca se haya revisado no es mejor que no tener ninguna copia. Sin embargo, volver a leer una clave privada es exponerla. El kit de verificación resuelve ambas situaciones:

  • Un secreto de prueba, cifrado para la clave maestra y con control de versiones;
  • Un script que lee la clave desde la entrada estándar — nunca como argumento, nunca en la pantalla, nunca en un archivo — intenta descifrar el secreto de prueba y devuelve pass o fail;
  • Probado en ambas direcciones: una clave falsa devuelve fail, la verdadera devuelve pass, incluyendo la entrada manual desde el papel.

El ejercicio completo se realiza en un sistema iniciado desde una unidad USB, sin conexión a la red, directamente desde la hoja. Está documentado, fechado, y la confirmación expira: un programa lo detecta cuando falta.

Lo que tienen en común estas opciones

  • Probar la propiedad, no la configuración. La inmutabilidad se comprueba intentando eliminar; la restauración se comprueba restaurando.
  • Cifrar lo más cerca posible de los datos. El cliente cifra; los servidores almacenan bytes que no saben leer.
  • Identificar las dependencias circulares antes de que ocurra el problema. La clave en la caja fuerte, la caja fuerte en el parque, el parque detrás de la clave: este es el tipo de bucle que solo se descubre intentando empezar desde cero.

Para leer después

Dernière vérification de cette page : 2026-09-11