History

Daniel Allaire 3ea0c95492 Some checks are pending verifier / verifier (push) Waiting to run Details sauvegarde : l etat d un locataire quitte enfin sa propre flotte Chezlepro rangeait ses instantanes sur une VM DE SA PROPRE FLOTTE. Raser l ecosysteme pour le reconstruire, c etait raser le filet avec. Le site a son depot ; les neuf detenteurs d etat y deposent ; une restitution est sortie (annuaire LDAP lisible, hors flotte). Isolation par compte Unix, pas par convention : home 0700, cle exclusive, racine partagee a root en 0711 (traversable, non listable). Les deux refus constates. Le site heberge du chiffre : il ne peut ni lire ni ouvrir, d ou la verification deplacee chez le locataire qui detient la cle. Quatre defauts reveles par ce deuxieme usage : - la racine des depots ne peut etre le home de personne (StrictModes rendait Permission denied publickey pour un refus de CHEMIN) - la racine nie le TLD internal, et harden-below-nxdomain etendait ce non a toute la zone sans jamais interroger l autoritatif : aucun locataire ne pouvait nommer un service du site - le gabarit transporte des fichiers de durcissement perimes, et les machines du site ne recoivent jamais ssh_hardening - MaxStartups compte les connexions non authentifiees : un depot de site en voit la somme de ses locataires Constat non corrige : les machines du site ne sont pas durcies. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on		2026-09-01 22:16:20 -04:00
..
defaults	sauvegarde : l etat d un locataire quitte enfin sa propre flotte	2026-09-01 22:16:20 -04:00
meta	supervision : c'est le DEPOT qui dit ou en sont les sauvegardes	2026-08-11 21:39:05 -04:00
tasks	sauvegarde : l etat d un locataire quitte enfin sa propre flotte	2026-09-01 22:16:20 -04:00
templates	reconstruction d'un trait : 43 groupes, 0 echec, 37 minutes	2026-08-13 08:49:12 -04:00
README.md	docs : un README par rôle (12 manquants) + carte remise à l'état du code	2026-07-29 11:32:06 -04:00

README.md

serveur_backup

Cible des sauvegardes : héberge les dépôts restic (un sous-dossier par nœud source), servis en SFTP/SSH à un utilisateur restreint. Le pendant de client_backup.

Rôle

Crée l'utilisateur système restic et la racine des dépôts /srv/restic.
Sécurise cette racine (droits stricts).
Autorise la clé publique de sauvegarde dans son authorized_keys.

C'est tout : le rôle est délibérément minimal. Aucun démon, aucune logique de sauvegarde — tout se passe côté client (dumps, chiffrement, rétention).

Sécurité

Le chiffrement est fait par le client (restic) : ce nœud ne détient que des blocs chiffrés et n'a jamais le mot de passe des dépôts. Compromettre la cible ne donne pas accès aux données.

La clé privée correspondante vit dans la voûte, côté client_backup (vault_backup_ssh_privkey) ; seule la publique est déclarée ici.

Variables

Variable	Défaut	Rôle
`serveur_backup_utilisateur`	`restic`	Compte de dépôt
`serveur_backup_racine`	`/srv/restic`	Racine des dépôts
`serveur_backup_pubkey`	(vide — obligatoire)	Clé publique autorisée

Le rôle exige serveur_backup_pubkey (assertion) : sans elle, la cible serait déployée mais inaccessible.

Flux (`meta/flux.yml`)

22/tcp entrant depuis client_backup (SSH, clé dédiée). Aucun autre port.

Notes / limites

Hors-nœud, pas hors-site : la cible protège de la perte d'une VM, pas de la perte du cluster. Une copie hors-site reste à faire.
Dimensionner le disque en conséquence (meta/empreinte.yml : 64 Go par défaut) — c'est la ressource critique de ce nœud.
Le compte restic n'est pas confiné à un shell restreint (rrsync/ForceCommand) : durcissement possible si la cible venait à sortir du périmètre de confiance.

Prérequis

Couche services (avant les agents client_backup).