Daniel Allaire
3ea0c95492
Some checks are pending
verifier / verifier (push) Waiting to run
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
59 lines
3.4 KiB
YAML
59 lines
3.4 KiB
YAML
---
|
|
# Cible des sauvegardes : héberge les dépôts restic (un sous-dossier par nœud source).
|
|
# Les clients y accèdent en SFTP/SSH avec la clé de sauvegarde. Chiffrement côté client (restic).
|
|
serveur_backup_utilisateur: "restic"
|
|
serveur_backup_racine: "/srv/restic"
|
|
# Clé PUBLIQUE de sauvegarde autorisée (la privée est dans la voûte, côté client_backup).
|
|
serveur_backup_pubkey: ""
|
|
|
|
# CE DÉPÔT PEUT-IL OUVRIR CE QU'IL GARDE ?
|
|
#
|
|
# `true` chez un écosystème : il garde SES dépôts, il en détient le mot de passe, il
|
|
# peut donc constater ce qui est réellement arrivé — et c'est le seul à le pouvoir,
|
|
# puisqu'un nœud sait qu'il a lancé sa sauvegarde sans savoir qu'elle a abouti.
|
|
#
|
|
# `false` chez le dépôt d'un site : restic chiffre CHEZ LE CLIENT, avec un mot de passe
|
|
# qui reste dans la voûte du locataire. Le site héberge des octets qu'il ne peut ni
|
|
# lire ni ouvrir. Ce n'est pas une lacune : c'est ce qui rend l'hébergement mutualisé
|
|
# acceptable. La vérification a alors lieu chez le locataire, qui détient la clé.
|
|
#
|
|
# `serveur_backup_site` met cette valeur à `false` et dit pourquoi.
|
|
serveur_backup_verification_locale: true
|
|
|
|
# --- Vérification des dépôts et rapport passif vers Icinga ---
|
|
# Le dépôt est le SEUL à voir ce qui est réellement arrivé. Un nœud sait qu'il a lancé sa
|
|
# sauvegarde ; il ne sait pas qu'elle a abouti. D'où la vérification ici, et pas là-bas.
|
|
# Toutes les 4 h, pas une fois par jour : la vérification doit renouveler le `ttl` bien
|
|
# avant qu'il n'expire, sinon un simple retard du timer se lirait comme une sauvegarde
|
|
# perdue. Elle est peu coûteuse (lecture des métadonnées restic).
|
|
serveur_backup_verification_horaire: "*-*-* 00/4:00:00"
|
|
|
|
# Seuils d'âge. Le critère « n'emporte rien » ne se règle pas ici : il se mesure en
|
|
# NOMBRE DE FICHIERS dans l'instantané (zéro = rien emporté), ce qui est exact, alors
|
|
# qu'un seuil en octets signalait à tort un export LDIF de 2,3 Ko.
|
|
serveur_backup_age_warn_h: 26
|
|
serveur_backup_age_crit_h: 50
|
|
|
|
# `ttl` du résultat passif : au-delà, Icinga périme le service de lui-même — c'est ce qui
|
|
# fait que le SILENCE alerte. 6 h pour une vérification toutes les 4 h : une exécution peut
|
|
# être manquée sans fausse alerte, deux ne le peuvent pas.
|
|
serveur_backup_ttl_icinga: 21600
|
|
|
|
# AC à opposer au pair en appelant l'API Icinga. C'est celle d'ICINGA, pas step-ca :
|
|
# Icinga refuse de servir un certificat qu'il n'a pas émis (il renouvelle tout ce qui
|
|
# expire sous 30 jours, nos certificats vivent 24 h). Domaine de confiance fermé, pair
|
|
# authentifié malgré tout — ce qui était le vrai enjeu.
|
|
serveur_backup_icinga_ca_source: "/var/lib/icinga2/ca/ca.crt"
|
|
serveur_backup_ca_verification: "/etc/setops/icinga-ca.crt"
|
|
|
|
# Compte d'API Icinga (portée : uniquement process-check-result sur « sauvegarde: * »).
|
|
serveur_backup_icinga_utilisateur: "setops-depot"
|
|
serveur_backup_icinga_motdepasse: "{{ vault_icinga_api_depot | default('') }}"
|
|
serveur_backup_icinga_hote: "{{ (groups['serveur_icinga'] | default([]) | first) | default('') }}"
|
|
|
|
# Nœuds dont un instantané est ATTENDU : ceux qui portent client_backup ET détiennent
|
|
# réellement de l'état. Même règle que `client_backup_jobs`, même source que P36.
|
|
serveur_backup_noeuds_attendus: >-
|
|
{{ (client_backup_groupes_etat | default([]) | map('extract', groups)
|
|
| select('defined') | flatten | unique | list)
|
|
| intersect(groups['client_backup'] | default([])) }}
|