# 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` (*installé et préparé, désactivé par défaut*) |
| Mises à jour | `unattended_upgrades` |
| SSH | `ssh_baseline` + `ssh_hardening` (clé d'abord, `PermitRootLogin no`…) |
| Moindre privilège | compte technique `ansible` + `sudo_ansible` (pas de root direct) |

Nuance importante : le **pare-feu** est *préparé mais pas activé* dans le template — on l'active sur
un **clone/serveur final** avec des règles adaptées à son rôle (couper l'accès à l'aveugle = un
risque). Prudence par conception.

---

## ③ 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`.