# 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

1. **Constate les couches** (sur n'importe quel nœud) :
   ```bash
   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
   ```
2. **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'`.
3. **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`.