verifier / verifier (push) Has been cancelled

Details

documentation : la tournee des 74 documents, parce qu un balayage ne lit pas

La revision a commence par un balayage par motifs — chemins morts, cibles make
absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque
tout le reste : un motif ne voit que ce qui s exprime en motif.

make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait
au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par
AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus
haut. Il fallait lire pour la voir.

74 documents lus un par un. 66 corriges, 8 exacts.

CE QUI ETAIT FRANCHEMENT FAUX

AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre
des VM reelles. Elle a ete rasee et remontee depuis zero trois fois.
ecosysteme-chezlepro.md, le document montre a un client, portait la meme
phrase : il se sous-vendait gravement.

courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de
son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n
est construit alors qu il rapporte des mesures datees du role en fonctionnement.
hebergeur-exploitation.md disait rien n est fait d un depot qui existe.
filiation-emancipation.md se contredisait a deux ecrans de distance.

DES MODELES DECRITS D APRES UN MONDE ANTERIEUR

Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le
donnaient en exemple d integration FACULTATIVE — il est universel depuis le
2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID
a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki
qui avait raison.

CE QUI CASSE AU PREMIER ESSAI

Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le
FABRIQUE et le critere R2 de l epreuve d operateur independant.
preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait
detruite : raser derive du plan, il ne la detruira jamais — le risque est l
inverse. Un mot de passe d essai en clair dans un depot public.

DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME

P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d
un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux
declarations reelles : 12 annonces, 21 reels.

Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la
conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une
erreur ajoute l assurance a l erreur.

CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT

Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les
meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il
nomme existe. P29 tient les positions d authentification, personne ne tient les
habilitations.

make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q

2026-09-06 16:18:23 -04:00

4.1 KiB

Raw Blame History

Sécurité & durcissement

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

① Le concept (générique)

Sécuriser un système, ce sont quelques principes qui se combinent :

Défense en profondeur : plusieurs couches — si l'une cède, les autres tiennent.
Moindre privilège : chacun (compte, service) n'a que les droits nécessaires.
Réduction de la surface d'attaque : moins de services exposés = moins de portes.
Contrôle d'accès obligatoire (MAC) : le noyau confine chaque programme (AppArmor/SELinux).
Audit : tracer les événements sensibles pour pouvoir enquêter.
Anti-force-brute : bloquer les tentatives répétées (fail2ban).
Pare-feu : filtrer le trafic réseau.
Mises à jour : combler les failles connues, automatiquement.

Aucune de ces couches ne suffit seule. Ensemble, elles rendent l'intrusion coûteuse.

② Comment Set-OPS le fait

Le durcissement fait partie du socle — il tourne sur chaque nœud (via serveur_durci), pas en option :

Couche	Rôle Set-OPS
MAC	`apparmor`
Audit	`auditd`
Anti-force-brute SSH	`fail2ban_ssh`
Durcissement noyau	`sysctl_hardening`
Pare-feu	`nftables_baseline` — règles dérivées du registre des flux, pas écrites à la main
Mises à jour	`unattended_upgrades`
Journaux	`journald` (rétention, persistance)
Vidages mémoire	`core_dumps` (désactivés — un core peut contenir des secrets)
Paquets	`hardening_packages`
SSH	`ssh_baseline` + `ssh_hardening` (clé d'abord, `PermitRootLogin no`…)
Moindre privilège	compte technique `ansible` + `sudo_ansible` (pas de root direct)

Le groupe serveur_durci compose dix de ces rôles en un seul geste ; ssh_baseline et sudo_ansible viennent du socle serveur_debian, en amont.

Le pare-feu : préparé dans le gabarit, armé sur la flotte. nftables_baseline vaut false par défaut dans le rôle — couper l'accès à l'aveugle pendant la construction d'un gabarit serait un risque gratuit. Mais l'instance le met à true pour hotes_actifs : sur une machine réelle, le pare-feu tourne.

Et ses règles ne s'écrivent pas à la main. Chaque rôle déclare dans son meta/flux.yml ce qu'il écoute et ce à quoi il se connecte ; scripts/resoudre_flux.py en dérive le jeu de règles, en policy drop par défaut. Le même registre alimente le pare-feu de l'hyperviseur et la frontière OPNsense : trois couches qui ne peuvent pas se contredire, parce qu'elles descendent d'une seule décision. C'est la défense en profondeur du §① prise au mot — sans le coût habituel, qui est de tenir trois politiques cohérentes à la main.

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
AppArmor	SELinux · les security modules Linux
fail2ban / auditd / sysctl	outils standards de tout durcissement Linux
démarche par couches	CIS Benchmarks, ANSSI, guides d'OS — mêmes principes

Tu as appris la défense en profondeur, le moindre privilège, MAC, l'audit — pas « AppArmor ».

④ À toi de jouer

Constate les couches (sur n'importe quel nœud) :

aa-status | head            # AppArmor : profils chargés
systemctl is-active auditd fail2ban
sysctl net.ipv4.conf.all.rp_filter   # un durcissement noyau parmi d'autres

Moindre privilège : PermitRootLogin est à no, l'accès se fait par le compte ansible + clé SSH. Vérifie : sshd -T | grep -E 'permitrootlogin|passwordauthentication'.
Casse & répare (avec prudence, en lab). Assouplis un réglage sysctl, observe, puis remets-le. Tu sens que chaque ligne de durcissement ferme une porte précise.

Pour aller plus loin (dépôt)

Rôles du socle durci : roles/apparmor, auditd, fail2ban_ssh, sysctl_hardening, nftables_baseline, ssh_hardening, unattended_upgrades…
Actions destructives (SSH, pare-feu) exigent une confirmation explicite : voir CLAUDE.md/AGENTS.md.

4.1 KiB Raw Blame History