Daniel Allaire
716be304c5
Complète les 14 unités d'apprentissage au moule à 4 temps : Reverse-proxy, Courriel, Bases de données, Cache, Métriques & journaux, Supervision & impact, Virtualisation, Sécurité & durcissement, Infra as Code & idempotence, Liaisons (bindings, avec l'analogie NetScaler). Navigation complétée. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
75 lines
3.1 KiB
Markdown
75 lines
3.1 KiB
Markdown
# 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`.
|