Déployer des nœuds de sauvegarde air-gapped dans le centre de données : conception réseau, matériel et synchronisation

Les nœuds de sauvegarde Air‑Gapped — c’est‑à‑dire des serveurs de sauvegarde ou des systèmes de stockage isolés physiquement ou logiquement du réseau de production — sont une mesure éprouvée pour contrer les ransomwares, le mouvement latéral et la compromission du réseau. Ce document pratique décrit comment planifier de tels nœuds dans le centre de données, quel matériel et quelles topologies réseau sont pertinents, comment réaliser techniquement une synchronisation sécurisée et quelles particularités il convient de considérer pour les bases de données MySQL. Public cible : administrateurs, ingénieurs systèmes, opérateurs et pRESTataires IT techniques.

Pourquoi des nœuds de sauvegarde Air‑Gapped ? Risques et objectifs opérationnels

Un air‑gap signifie qu’un système n’a pas de chemin réseau routinier vers le réseau de production. En pratique de la sauvegarde, on distingue deux variantes : une séparation physique (pas de câble réseau, échange de médias) ou une transmission unidirectionnelle logique (diode de données matérielle (Data Diode) ou fenêtres de transfert strictement contrôlées). L’objectif est de réduire la surface d’attaque et de conserver un jeu de données final intact que les logiciels malveillants présents sur le réseau de production ne peuvent pas atteindre.

Il est important de définir clairement les objectifs opérationnels : s’agit‑il du Recovery Time Objective (RTO), du Recovery Point Objective (RPO), de la conformité ou de l’intégrité forensique ? Les air‑gaps aident surtout pour l’intégrité et la conformité, mais dégradent en général le RTO/RPO par rapport aux répliques en ligne.

Conditions préalables et liste de vérification du projet

Avant la phase de conception, vous devez vérifier les prérequis organisationnels et techniques. Les points minimaux suivants doivent figurer sur la checklist :

• Définir les objectifs de récupération (RTO/RPO) et les durées de conservation.
• Quelles données doivent être protégées ? (bases de données de production, sauvegardes de configurations, certificats)
• Budget pour le matériel, la rotation des médias et, le cas échéant, les appliances Data‑Diode.
• Processus opérationnels : qui connecte physiquement les médias, qui signe/vérifie les manifestes ?
• Plan de tests pour des exercices réguliers de RESTauration.

Conception réseau : topologies pour les nœuds de sauvegarde Air‑Gapped

Il existe trois topologies pragmatiques :

1) Nœuds physiquement isolés avec échange de médias

Les serveurs de sauvegarde sont installés localement dans le centre de données, mais n’ont pas de routage L2/L3 permanent vers le réseau de production. Les données sont transférées hors ligne via des médias interchangeables (disques durs chiffrés, bandes LTO). Avantage : isolation très élevée. Inconvénient : processus manuels, RTO plus long.

2) Transmission unidirectionnelle logique avec diode de données ou appliance unidirectionnelle

La diode de données matérielle est un dispositif qui laisse physiquement passer les données dans une seule direction (plus simplement : optique). En alternative, il est possible de configurer routeurs/ACLs de manière à n’autoriser l’initiation de connexions que vers un sous‑réseau donné. Avantage : transferts automatisables, réduction du travail manuel. Limite : coûts plus élevés, dépendance au fabricant de l’appliance et à la sécurité de son firmware.

3) Nœuds connectés temporairement, fortement contrôlés (fenêtres de transfert)

L’air‑gap n’est ouvert que temporairement : le câble réseau est relié physiquement ou les règles de pare‑feu sont modifiées pour une fenêtre définie. Les transferts sont chiffrés, suivis d’une ré‑isolation immédiate et de vérifications des signatures. Adapté lorsque l’automatisation est nécessaire sans diode de données (Data Diode). Risque : erreurs humaines lors de la ré‑isolation.

Planification des segments réseau et des pare‑feu

Définissez au minimum trois segments : réseau de production, Transfer‑DMZ (si présente) et Air‑Gapped‑Zone. Utilisez des ACL (listes de contrôle d’accès), des VLAN (réseaux locaux virtuels) et la séparation physique des ports de commutateur. Une règle simple : aucune connexion entrante du réseau de production vers l’Air‑Gapped‑Zone. Testez les règles avec Netcat ou tcpdump avant la mise en production.

Matériel: serveurs, stockage et choix des médias

Les décisions matérielles influencent la disponibilité, l’intégrité et les coûts d’exploitation. Critères de sélection :

• Format : serveurs 1U/2U ou bibliothèque de bandes dédiée selon le volume.
• Type de stockage : archives sur HDD (économique, grande capacité), SSD (pour tests de RESTauration rapides), bandes LTO (durables, adaptées au hors‑ligne).
• Redondance : pour les nœuds Air‑Gapped, RAID est souvent suffisant ; pour les bandes, misez sur la rotation des médias et des copies hors site.
• Chiffrement : chiffrement matériel sur les médias ou chiffrement côté hôte avant le transfert.

Veillez à un marquage des médias traçable et à un stockage sécurisé : contrôles d’accès, enregistrements CCTV et signatures.

Synchronisation: Verfahren, Werkzeuge und Integritätsprinzipien

La question centrale est : comment les données parviennent‑elles de manière fiable et vérifiable vers le nœud isolé ? Méthodes courantes avec avantages et inconvénients :

• rsync / rclone via un lien unidirectionnel : flexible, granulaire, prend en charge les sommes de contrôle. Nécessite une connexion réseau (ou une diode de données).
• Réplication au niveau bloc (ZFS send/receive, btrfs send) : efficace pour de grands volumes de données avec cohérence par snapshot.
• Rotation de médias physique (scp/disque dur physique, bandes LTO) : très isolée, mais lente et manuelle.
• Percona XtraBackup / sauvegardes cohérentes MySQL : nécessaire pour les dumps MySQL et les sauvegardes incrémentales (voir la section MySQL ci‑dessous).

Exemple: rsync über kontrolliertes Fenster

rsync est éprouvé en pratique pour la synchronisation de fichiers. Important : utilisez des sommes de contrôle et générez un manifeste sha256 pour chaque lot de transfert.

# Auf der Produktionsseite: Backup vorbereiten und Manifest erstellen
rsync -aH --delete /var/lib/appdata/ /staging/backupdir/
find /staging/backupdir -type f -print0 | xargs -0 sha256sum > /staging/backupdir/manifest.sha256
gpg --detach-sign --armor /staging/backupdir/manifest.sha256

Après le transfert vers l’Air‑Gapped‑Zone, vérifiez les sommes de contrôle et la signature GPG.

# Auf Air-Gapped-Node: Integritätsprüfung
gpg --verify manifest.sha256.asc manifest.sha256
sha256sum -c manifest.sha256

Signaturen und unveränderliche Manifeste

Signez toujours les manifestes avec une clé hors ligne ou une clé dont la partie secrète n’est pas présente sur le réseau de production. Cela empêche un attaquant de manipuler les manifestes dans la chaîne de transfert.

MySQL‑Spezifika: Konsistenz, Tools und typische Stolperfallen

MySQL (incl. MariaDB) impose des exigences particulières : vous avez besoin de sauvegardes de base de données cohérentes garantissant la cohérence applicative lors du RESTore. Concepts importants : positions de binlog (binlog = write‑ahead‑log), GTID (Global Transaction ID) pour un positionnement réplicable, et méthodes de quiescence (snapshot LVM ou stratégies de verrouillage).

Option A: Percona XtraBackup (empfohlen für große InnoDB‑Datenbanken)

Percona XtraBackup permet des sauvegardes incrémentielles et non bloquantes des bases de données InnoDB. Processus : XtraBackup crée une copie de fichiers + le journal de transactions (redo) et fournit un point de cohérence qui doit être préparé avant le RESTore avec xtrabackup –prepare.

# Volles Backup mit xtrabackup
xtrabackup --backup --target-dir=/backup/xtrabackup/full --datadir=/var/lib/mysql --user=xbackup --password='secret'
# Inkrementelles Backup
xtrabackup --backup --incremental --target-dir=/backup/xtrabackup/inc1 --incremental-basedir=/backup/xtrabackup/full

Erreurs typiques : préparation incomplète, métadonnées binlog/GTID manquantes ou permissions oubliées lors de la copie des fichiers système InnoDB. Testez régulièrement les procédures de RESTauration dans un environnement de test isolé.

Option B: mysqldump / Logical Backups

mysqldump est simple et portable, mais génère de gros dumps et peut poser des problèmes pour le RTO sur des bases de données très volumineuses. Pour InnoDB, utilisez –single-transaction, qui permet une lecture de snapshot cohérente (sans verrous) tant qu’aucune opération DDL n’est en cours.

# Konsistenter mysqldump für InnoDB
mysqldump --single-transaction --routines --events --triggers --databases appdb > appdb.sql
# Binlog-Position abfragen
mysql -e "SHOW MASTER STATUSG"

Avec mysqldump, tenez compte des positions du binlog ou des GTID afin de pouvoir effectuer, après RESTauration, une récupération point-in-time (PITR).

Prüfschritte und RESTore‑Übungen für MySQL

• Documentez la procédure de RESTauration et testez-la une fois par trimestre.
• Après RESTauration, vérifier : nombre de tables, sommes de contrôle (pt-table-checksum ou outils équivalents), tests smoke de l’application.
• Vérifiez les droits utilisateurs, l’état du binlog et la configuration de réplication après la RESTauration.

Konkrete RESTore‑Schritte für XtraBackup

Un chemin de RESTauration typique après transfert vers un système air-gapped :

# Vorbereitung des Backups
xtrabackup --prepare --target-dir=/backup/xtrabackup/full
# Stoppen des MySQL-Dienstes
systemctl stop mysql
# Kopieren in datadir (Achtung: Dateirechte)
rsync -aH /backup/xtrabackup/full/ /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
# MySQL starten
systemctl start mysql

Si –prepare échoue, examinez les journaux de xtrabackup pour identifier des redo‑Logs manquants ou des dépendances incrémentales.

Betrieb: Runbooks, Transferprozeduren und Automatisierung

De bons Runbooks sont au cœur de l’exploitation. Un Transfer‑Runbook décrit en détail :

1. Conditions préalables : médias disponibles, clés de signature, responsables.
2. Étape par étape : démarrage de la sauvegarde, création du manifeste, signature, démarrage du transfert, vérifications post‑transfert, ré‑isolation.
3. Monitoring et journalisation : syslog/logs centraux, entrée d’audit indiquant qui a connecté des médias et quand.
4. Plan de secours : que faire si le manifeste échoue ? (p. ex. relancer le transfert ou utiliser une copie antérieure sur média).

Automatisierungsbeispiel: kontrolliertes Transferfenster

Automatisez l’ouverture/fermeture des règles de pare‑feu via API ou gestion de configuration (Ansible/Chef). Exécutez avant l’ouverture des contrôles pré‑vol automatisés (vérification d’intégrité, contrôle des quotas).

Integrität, Signaturen und Auditing

L’intégrité doit être assurée à trois niveaux : intégrité des fichiers (Checksums), intégrité du transfert (TLS, Data‑Diode) et authenticité (GPG‑Signaturen). En complément, générez des logs d’audit retraçant les mouvements physiques des médias et les actions des utilisateurs.

# Manifest erstellen und signieren (Beispiel)
find /backupdir -type f -print0 | xargs -0 sha256sum > manifest.sha256
gpg --default-key backup-admin --detach-sign --armor manifest.sha256

Monitoring, Alerting und automatische Sanity‑Checks

Surveillez les métriques suivantes : heure du dernier transfert réussi, nombre de fichiers vérifiés, résultat de la vérification sha256, capacité disponible des médias. Intégrez des alertes (p. ex. via Prometheus Alertmanager ou RZ‑Monitoring) pour les transferts manquants ou les manifestes défectueux.

Exemple : script de vérification simple pour nœud air‑gapped

Ce script regroupe la vérification d’intégrité et le comptage de fichiers, et renvoie des codes de sortie pour les systèmes de supervision.

#!/bin/bash
MANIFEST=/var/airgap/manifest.sha256
MANIFESTSIG=/var/airgap/manifest.sha256.asc
BACKUPDIR=/var/airgap/data
# Signatur prüfen
if ! gpg --verify "$MANIFESTSIG" "$MANIFEST" >/dev/null 2>&1; then
  echo "GPG verification failed" >&2
  exit 2
fi
# Checksums prüfen
if ! sha256sum -c "$MANIFEST" >/dev/null 2>&1; then
  echo "Checksum mismatch" >&2
  exit 2
fi
# Dateizahl prüfen
FILECOUNT=$(find "$BACKUPDIR" -type f | wc -l)
if [ "$FILECOUNT" -lt 10 ]; then
  echo "Too few files: $FILECOUNT" >&2
  exit 2
fi
echo "OK: $FILECOUNT files verified"
exit 0

Pièges typiques et comment les éviter

• Confiance en une seule méthode : combinez Checksums + signatures + audit physique.
• Erreurs humaines lors de la ré‑isolation : automatisez la ré‑isolation lorsque possible ou exigez le principe de double contrôle (deux personnes).
• Absence de tests de RESTauration : sans tests réguliers, vous ne savez pas si les sauvegardes sont réellement exploitables.
• Gestion des clés : ne conservez jamais les clés privées dans des systèmes productifs en ligne ; utilisez un HSM hors ligne ou des clés séparées en air‑gap.
• Documentation insuffisante : les runbooks et les responsabilités doivent être à jour et accessibles.

Planification de la capacité, débit et aspects de performance

Planifiez la capacité non seulement selon le volume actuel, mais en fonction des fenêtres de RESTauration et de la croissance. Facteurs influençant le RTO :

• Débit d’écriture de la source (durée du job de sauvegarde)
• Débit de transfert (réseau ou taux de streaming sur bande)
• I/O de RESTauration sur la cible (à quelle vitesse les données peuvent être RESTaurées)

Exemple : une data‑diode à 1 Gbit/s dispose théoriquement d’environ 125 Mo/s. Après overhead, protocoles et chiffrement, comptez réalistiquement 80–90 Mo/s dans de bonnes conditions. Pour plusieurs téraoctets, cela représente de nombreuses heures ; documentez ces fenêtres temporelles dans votre runbook.

Déduplication, compression et stratégies de stockage

La déduplication et la compression réduisent le volume de données, mais peuvent impacter le chemin de RESTauration et la compatibilité. Les stockages avec déduplication exigent en règle générale des outils de RESTauration spécialisés ; dans un contexte air‑gapped, de nombreuses équipes privilégient des formats simples et portables (tar, flux compressés) pour la conservation à long terme. Si vous utilisez la déduplication, testez impérativement des RESTaurations complètes depuis des stockages dédupliqués.

Gestion des clés, HSM et exigences forensiques

Pour les signatures et le chiffrement, les secrets ne doivent jamais se trouver dans le réseau de production en ligne. Options :

• Clés GPG hors ligne sur un laptop air‑gapped
• HSM (Hardware Security Module) ou Cloud‑HSM avec contrôles d’accès RESTreints
• Validation à deux personnes basée sur smartcard/token pour les signatures critiques

Documentez la rotation des clés, la conservation et les journaux d’accès aux clés. Pour la préservation des preuves forensiques, une chaîne de possession (chain of custody) traçable est essentielle : qui a déplacé et vérifié quel support et quand.

Liste de vérification pratique pour le dépannage

Si un transfert échoue ou si la vérification du manifeste renvoie des erreurs, procédez de manière systématique :

1. Vérifiez les fichiers journaux (rsync/xtrabackup/gpg/syslog).
2. Comparez le nombre de fichiers et la taille totale entre la source et la destination.
3. Vérifiez les empreintes des clés GPG par rapport à une liste de confiance.
4. Si –prepare échoue avec XtraBackup : vérifiez que tous les redo‑logs requis sont présents et que les sauvegardes incrémentielles ont été correctement chaînées.
5. Si les supports sont défectueux : tentez une copie bit à bit (dd) et l’analyse des secteurs défectueux ; cataloguez le support défaillant pour les audits.

Migration et mise en place progressive

Un passage complet vers des nœuds air‑gapped est lourd sur le plan opérationnel. Parcours progressif recommandé :

1. Pilote avec un faible volume de données (données de configuration, bases de données moins critiques).
2. Automatisation de la création et de la signature des manifestes.
3. Mise en place d’un moniteur de healthcheck et d’exercices de RESTauration trimestriels.
4. Montée en charge vers des volumes plus importants et ajustement des objectifs RTO/RPO.

Conclusion finale

Les nœuds de sauvegarde air‑gapped constituent un élément efficace d’une stratégie de sauvegarde globale, en particulier lorsque l’intégrité et la protection contre la manipulation sont prioritaires. Ils exigent toutefois de la discipline dans les processus, une gestion robuste des clés et des supports, ainsi que des tests de RESTauration réguliers. Sur le plan technique, les Data‑Diodes, les fenêtres de transfert contrôlées et la rotation physique des supports offrent différents compromis entre automatisation, coût et isolation — choisissez la solution qui correspond à vos objectifs RTO/RPO et à votre équipe d’exploitation.

Concentrez-vous opérationnellement sur des manifestes vérifiables, des clés de signature gérées hors ligne, des runbooks documentés et des essais de RESTauration réguliers. Ainsi, vous évitez les pièges les plus courants et vous assurez que vos nœuds de sauvegarde air‑gapped réagiront de manière fiable en cas d’incident.

Pour ce sujet, l’Air Gap et la conception du réseau de sauvegarde sont également importants. Cet article situe ces aspects de manière claire et montre ce qui compte au quotidien.