Conseils Oryon
Sauvegardes d’un serveur Linux : les points à documenter avec son prestataire
Checklist opérationnelle des éléments à cadrer avec votre prestataire pour définir rétention, chiffrement, outil (Borg/restic), automatisation et vérifications périodiques des sauvegardes d'un serveur Linux.
Ce document rassemble, section par section, les points opérationnels et contractuels à documenter avec un prestataire pour préparer des sauvegardes fiables et vérifiables d'un serveur Linux critique.
Il vise la formalisation du périmètre, le choix d'outil (Borg/restic) sur les critères décrits, la planification non interactive des jobs, les contrôles périodiques et les exigences de sécurité contractuelles.
Délimiter les éléments du système d’information à protéger
Lister les activités, services et données du système d’information à protéger et mettre cette liste à jour au moins une fois par an ou en cas de changement permet d’identifier les éléments métier à protéger. [1]
Lister et tenir à jour les équipements et applicatifs utilisés au sein du système d’information permet d’identifier les éléments techniques à protéger. [1]
Formaliser et maintenir à jour un dossier d'architecture technique du système d'information facilite le maintien en condition opérationnelle et de sécurité, notamment pour identifier rapidement quels équipements ou applicatifs sont affectés par un incident et limiter ses conséquences. [1]
Choisir entre Borg et restic, puis cadrer rétention et chiffrement
Chiffrer les données stockées au repos à l’aide d’algorithmes à l’état de l’art et assurer un cycle de vie sécurisé des clés de chiffrement réduit la vraisemblance qu’un attaquant récupère des données non chiffrées. [1]
BorgBackup et restic permettent des sauvegardes chiffrées et dédupliquées, couvrant l'initialisation de dépôts locaux ou distants, l'élagage des instantanés (retention pruning), la restauration de fichiers et l'automatisation via des timers systemd. [2]
Principales différences utiles au cadrage : Borg exige l'installation du binaire Borg sur le serveur distant tandis que restic est agnostique du backend (SFTP, S3, Backblaze B2, rclone) et n'exige pas de binaire serveur en mode SFTP ; si la cible est un bucket S3 ou un service cloud, preferer restic. [2]
Sans élagage, les dépôts de sauvegarde croissent sans limite ; Borg et restic permettent de conserver un nombre défini d’instantanés par fenêtre temporelle. [2]
Distinguer les prérequis de Borg des exemples d’automatisation avec restic
La commande « borg init --encryption=repokey-blake2 /mnt/backup/borg-repo » demande une phrase secrète ; il faut la conserver en lieu sûr, car sa perte entraîne la perte d’accès à toutes les archives. [2]
Pour un dépôt Borg distant, Borg doit être installé sur le serveur de destination et l'authentification SSH par clé est requise, car les invites par mot de passe empêchent les sauvegardes non interactives ; ce prérequis d'installation doit figurer dans le cadrage technique. [2]
Dans les scénarios automatisés, indiquer un fichier de passphrase (par ex. --password-file /root/.backup-passphrase placé en mode 600) évite les invites interactives lors des sauvegardes de chemins tels que /home, /etc ou /var/lib et doit être précisé dans la configuration sécurisée. [2]
L'automatisation via systemd se fonde sur la création d'une unité service et d'une unité timer par tâche de sauvegarde ; l'exemple fourni pour restic montre la structure à reproduire et peut être adaptée aux commandes et chemins de Borg. [2]
Documenter une restauration de fichiers Borg et les contrôles associés
Les opérations de restauration utiles à documenter incluent la liste des archives (borg list /mnt/backup/borg-repo), la consultation du contenu d'une archive spécifique et l'extraction d'un répertoire ; notez que borg extract supprime les barres obliques initiales, il faut donc exécuter l'extraction depuis le répertoire cible ou utiliser --strip-components. [2]
Borg et restic proposent des contrôles d’intégrité à exécuter périodiquement, au moins une fois par mois, ou en cas d’inquiétude concernant le matériel. [2]
Si le timer de sauvegarde ne se déclenche pas après le démarrage, vérifier qu’il est activé avec « systemctl is-enabled restic-backup.timer » et consulter « systemctl list-timers » pour connaître le prochain déclenchement. Si « borg prune » n’a pas libéré d’espace disque, exécuter « borg compact » après « borg prune » : Borg 1.2 sépare ces deux opérations. [2]
Fixer les exigences de sécurité du prestataire et les revoir
Vérifier au moins annuellement, ou en cas d'évolutions majeures de la menace, du contexte métier, technique ou organisationnel, que les politiques et procédures de sécurité sont à jour et pertinentes, et les mettre à jour si nécessaire. [1]
En cas de recours à un prestataire, fixer dès les clauses contractuelles, si possible, les exigences de sécurité à respecter ; lorsque ces exigences ne peuvent être définies a priori, documenter clairement les engagements de sécurité que le prestataire déclare tenir. [1]
Pour conclure
Utilisez ces sections comme checklist de cadrage pour préparer le cahier des charges ou le contrat d’infogérance : précisez les exigences de sécurité à respecter et, si elles ne peuvent être fixées à l’avance, identifiez les engagements du prestataire.
Planifiez une revue annuelle des politiques et procédures et demandez la preuve des contrôles périodiques (vérifications d'intégrité, état des timers, rapports de prune/compact) sans confondre ces contrôles avec une preuve de reprise fonctionnelle complète.