Vai al contenuto

Continuità – sopravvivere quando tutto il resto fallisce

Traduzione automatica dell'originale francese.

La prevenzione, il rilevamento e la risposta possono fallire. In questo caso, ciò che rimane è la possibilità di ricominciare. Pertanto, la domanda posta in questa sezione non è "il backup è andato a buon fine?", ma piuttosto "sarò in grado di ripartire, e in quanto tempo?" – due domande che non hanno la stessa risposta.

I termini tecnici si riferiscono al glossario.

Quattro livelli di backup

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
Livello Contro cosa protegge
1 · Backup crittografato per host La perdita di un host, la cancellazione, la corruzione dell'applicazione
2 · Snapshot del NAS Un errore umano nello storage, la corruzione del repository stesso
3 · Due copie in sedi separate, presso due fornitori diversi La perdita dell'intero sito – incidenti, furti, attacchi ransomware che colpiscono il NAS
4 · Clonazione su due repository remoti La perdita della configurazione, dei file di configurazione, delle decisioni

La crittografia viene effettuata dal cliente, prima dell'invio: nessuno dei server di backup possiede le chiavi dei dati che conserva. Ogni host ha il proprio cliente, il proprio… dépôt et son plan de rétention ; la vérification d'intégrité des dépôts est planifiée.

L'immuabilité — la question du rançongiciel

Un rançongiciel moderne ne se contente pas de chiffrer les données : il cherche les sauvegardes, avec les accès qu'il trouve sur la machine compromise. La question qui compte est donc :

Celui qui prend un hôte peut-il aussi détruire ses sauvegardes ?

La propriété visée s'appelle l'immuabilité : une sauvegarde qu'on ne peut ni modifier ni supprimer depuis l'hôte sauvegardé.

  • Il server di backup opera solo in scrittura. Un utente può creare nuovi snapshot; non può eliminarli né modificarli. La cancellazione degli snapshot precedenti avviene, invece, con altri accessi.
  • Al di fuori del sito, l'immutabilità è garantita dal fornitore stesso, tramite un meccanismo di blocco dell'oggetto, o tramite snapshot a cui gli accessi di replica non possono accedere.

Come verificarlo: provando

L'immutabilità non si legge da una configurazione. Si verifica attraverso: si tenta di eliminare uno snapshot, e si attende un rifiuto. Un sistema di monitoraggio esegue regolarmente questa operazione. Una risposta positiva (l'eliminazione ha avuto successo) è un fallimento del controllo, non un successo del test.

Perché 'fresco' non basta

I controlli di freschezza rispondono alla domanda: "La copia di backup è stata eseguita?". Un ransomware crea copie di backup fresche, contenenti dati crittografati, al momento esatto, senza errori. Solo l'immutabilità e un esercizio di ripristino datato rispondono alla domanda: "Posso riprendere?".

Ripristinare veramente: l'esercizio cronometrato

Un backup che non è mai stato ripristinato è solo un'ipotesi. L'esercizio di ripristino lo trasforma in un'azione concreta:

  1. scegliere un ambiente rappresentativo – un database, file, cache;
  2. creare una nuova macchina virtuale usa e getta, che non ha mai interagito con l'ambiente;
  3. ripristinare solo dai backup, senza copiare nulla dalla macchina originale;
  4. cronometrare fino a quando l'API dell'applicazione non risponde normalmente;
  5. determinare l'età dei dati ripristinati;
  6. distruggere la macchina.

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 periodo di oltre 90 giorni: un ripristino eseguito un anno fa non dice nulla riguardo alle soluzioni odierne.

Il RTO misurato è un limite inferiore, non quello di una situazione disastrosa

Le variabili ambientali di uno stack non vengono mai scritte in modo esplicito: sono criptate nel repository e decriptate in memoria all'avvio. Ripristinate dal backup, quindi, tornano sotto forma di un collegamento a un file che non esiste più.

Per ottenere un backup completo, è quindi necessario due elementi in più rispetto al semplice backup: la "cassetta segreta" e la chiave di decrittazione. L'esercizio è stato condotto utilizzando la chiave disponibile. Il suo valore è quello di un evento ordinario; non è valido in caso di un incidente in cui la chiave sarebbe andata persa insieme al resto. Da qui la sezione successiva.

La chiave principale – l'unico scenario di perdita totale

Tutti i segreti dei stack sono crittografati con una sola chiave. Perdere la propria chiave privata significa perdere tutti i segreti – anche nelle versioni salvate in Git, dove le versioni crittografate rimangono per sempre e diventano illeggibili.

E la dipendenza è circolare: la "cassetta segreta" è a sua volta un altro stack. Recuperare la chiave da una cassetta che non si riesce più ad avviare a causa della mancanza della chiave è un ciclo chiuso.

La soluzione è una copia offline: su carta, conservata al di fuori del parco, senza alcun collegamento di rete.

Una copia che non viene più letta non è migliore di una sua assenza. Tuttavia, rileggere una chiave privata significa esporla. Il kit di verifica risolve entrambi i problemi:

  • un segreto di test, crittografato per la chiave principale e versionato;
  • uno script che legge la chiave dall'ingresso standard — mai come argomento, mai sullo schermo, mai in un file — tenta di decrittare il segreto di test e restituisce pass o fail;
  • testato in entrambe le direzioni: una chiave errata restituisce fail, quella corretta restituisce pass, compresi quelli inseriti manualmente dal foglio.

L'intero esercizio viene eseguito su un sistema avviato da una chiavetta USB, con la rete disattivata, direttamente dal foglio. È attestato, datato e l'attestazione scade: un programma lo richiama quando non lo trova.

Cosa hanno in comune queste scelte

  • Testare la proprietà, non la configurazione. L'immutabilità si verifica cercando di eliminare; il ripristino si verifica ripristinando.
  • Crittografare il più vicino possibile ai dati. Il client crittografa; i server conservano byte che non sanno leggere.
  • Individuare le dipendenze circolari prima del disastro. La chiave nella cassaforte, la cassaforte nel parco, il parco dietro la chiave: questo è il tipo di ciclo che si scopre solo cercando di ricominciare da zero.

Da leggere successivamente

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