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.

Set-OPS

🏠 Accueil

Tu viens d'arriver

🔑 Reprendre l'écosystème

Unités d'apprentissage

Fondations

Communication

Données

Observabilité

Socle & méthode

Flotte & preuve

Opérations

Runbooks → dépôt docs/runbooks-exploitation.md

Repères

Glossaire
Référence technique → dépôt docs/