Le hardening Linux désigne l'ensemble des actions de configuration et de durcissement visant à réduire la surface d'attaque d'un système Linux en production. Pour un débutant en 2026, un hardening de base couvre 10 domaines et prend 2-4 heures sur un serveur Ubuntu ou Debian standard : patch management (unattended-upgrades), utilisateurs et sudo (pas de root direct), SSH (clés uniquement, fail2ban), firewall (ufw ou nftables deny par défaut), kernel parameters (sysctl sécu), systemd hardening (services durcis), file system (partitions, permissions), logging et audit (auditd, journald), MAC (AppArmor ou SELinux), désactivation des services inutiles. Les référentiels standardisés sont les CIS Benchmarks (par distribution), le guide ANSSI Hygiène informatique, NIST SP 800-123, DISA STIG. Les outils d'audit dominants 2026 sont Lynis (gratuit, 2-5 min de scan, score sur 100), OpenSCAP (profils de conformité CIS/STIG/ANSSI) et Chef InSpec. Contrairement à une idée reçue, le hardening Linux reste central en 2026 avec Kubernetes : les nodes K8s sont des Linux hosts dont la sécurité conditionne la plateforme entière (voir Container escape : explication). Cet article détaille les 10 domaines avec commandes concrètes pour un débutant, les 7 actions prioritaires premiers 2-4 heures, les outils d'audit, un playbook Ansible type, et les erreurs classiques à éviter.
1. Modèle de menace : pourquoi hardener un serveur Linux
Avant les actions techniques, comprendre les menaces qu'on cherche à contrer.
1.1 Les 5 vecteurs d'attaque dominants 2026
| Vecteur | Description | Impact typique |
|---|---|---|
| SSH brute-force | Botnets scannant Internet pour tenter des credentials faibles | Accès shell initial |
| CVE kernel non patché | Exploitation d'une vulnérabilité kernel publique | Privilege escalation local |
| Services exposés vulnérables | Services sur ports publics avec CVE ou config par défaut | RCE (Remote Code Execution) |
| Misconfiguration | sudo trop permissif, permissions fichiers laxistes | Escalade de privilèges |
| Supply chain | Paquet installé depuis source non-trusted | Backdoor persistante |
1.2 Chiffres marquants 2024-2026
- IBM Cost of a Data Breach Report 2024 : breaches via CVE non patchée = 4,17 M$ moyen.
- Verizon DBIR 2024 : 180 % de hausse de l'exploitation de vulnérabilités comme vecteur initial en 2023-2024.
- Shodan Q3 2024 : environ 3 millions de serveurs SSH exposés publiquement, dont 15-25 % encore vulnérables à des credentials faibles.
- CVE kernel Linux : environ 100-150 CVE publiées par an touchant le kernel upstream, plus sévères en privilège escalation.
2. Les 7 actions prioritaires (2-4 heures pour un débutant)
Séquence ordonnée couvrant 80 % du risque pour un débutant.
2.1 Action 1 — Mises à jour et patch management automatique
Ubuntu / Debian
# Mise à jour complète immédiate
sudo apt update && sudo apt upgrade -y
sudo apt autoremove -y
# Activation unattended-upgrades (security uniquement)
sudo apt install -y unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
# Vérification config (doit inclure les lignes -security)
sudo cat /etc/apt/apt.conf.d/50unattended-upgrades | grep -E "security|Unattended"
# Logs
tail -f /var/log/unattended-upgrades/unattended-upgrades.logRHEL / Rocky / AlmaLinux
sudo dnf update -y
sudo dnf install -y dnf-automatic
# Configuration security uniquement
sudo sed -i 's/^upgrade_type.*/upgrade_type = security/' /etc/dnf/automatic.conf
sudo sed -i 's/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf
# Activation du timer
sudo systemctl enable --now dnf-automatic.timerRésultat attendu : patches sécurité appliqués automatiquement sous 24 h, sans intervention manuelle, sans risque de casse majeure (security updates sont audités upstream).
2.2 Action 2 — Utilisateur non-root avec sudo
Création du user et désactivation du login root
# Création user avec sudo
sudo adduser alice
sudo usermod -aG sudo alice # Debian/Ubuntu
# sudo usermod -aG wheel alice # RHEL/Rocky
# Vérifier l'accès
su - alice
sudo whoami # doit renvoyer root
# Désactiver le login root (après avoir validé sudo pour alice)
sudo passwd -l root
# Auditer /etc/sudoers et /etc/sudoers.d/
sudo visudo -c
sudo cat /etc/sudoers.d/*Règle d'or : jamais alice ALL=(ALL) NOPASSWD: ALL sauf contexte très spécifique. Préférer des sudoers précis par commande autorisée.
2.3 Action 3 — SSH hardening
Vecteur d'attaque numéro un. 90 % du risque vient de la configuration SSH par défaut laxiste.
Configuration /etc/ssh/sshd_config recommandée débutant 2026
# Éditer la config SSH
sudo tee -a /etc/ssh/sshd_config.d/99-hardening.conf << 'EOF'
# Désactiver l'authentification par mot de passe
PasswordAuthentication no
KbdInteractiveAuthentication no
# Désactiver login root direct via SSH
PermitRootLogin no
# Limiter les users autorisés SSH
AllowUsers alice bob
# Limiter les tentatives par connexion
MaxAuthTries 3
# Timeout session SSH
ClientAliveInterval 300
ClientAliveCountMax 2
LoginGraceTime 30
# Protocoles et algorithmes modernes
Protocol 2
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
# Désactiver tunnels et X11 forwarding si non utilisés
X11Forwarding no
AllowTcpForwarding no
GatewayPorts no
PermitTunnel no
EOF
# Tester la config avant de reload
sudo sshd -t
# Reload sans couper les sessions existantes
sudo systemctl reload sshdGénérer une clé SSH ed25519 côté client et la déployer
# Côté laptop admin
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_serveur
# Déployer la clé sur le serveur
ssh-copy-id -i ~/.ssh/id_ed25519_serveur.pub alice@serveur
# Tester la connexion
ssh -i ~/.ssh/id_ed25519_serveur alice@serveurInstaller fail2ban contre brute-force
sudo apt install -y fail2ban
sudo tee /etc/fail2ban/jail.d/sshd.local << 'EOF'
[sshd]
enabled = true
port = 22
maxretry = 3
findtime = 10m
bantime = 24h
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd2.4 Action 4 — Firewall par défaut deny
ufw (Uncomplicated Firewall) Ubuntu
sudo apt install -y ufw
# Deny par défaut en entrée, allow en sortie
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Autoriser SSH (port 22)
sudo ufw allow 22/tcp
# Autoriser les services nécessaires (exemple web)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# Activer
sudo ufw enable
sudo ufw status verbosenftables (successeur moderne iptables, natif depuis Debian 10, Ubuntu 20.04)
# Exemple de config nftables minimal
sudo tee /etc/nftables.conf << 'EOF'
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
iif lo accept
ct state established,related accept
ct state invalid drop
ip protocol icmp accept
tcp dport 22 accept
tcp dport { 80, 443 } accept
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}
EOF
sudo systemctl enable --now nftables
sudo nft list ruleset2.5 Action 5 — Désactiver les services non nécessaires
# Lister les services actifs
sudo systemctl list-units --type=service --state=running
# Identifier les services non nécessaires (CUPS, Avahi, Bluetooth sur serveur, snapd si non utilisé)
sudo systemctl disable --now cups.service 2>/dev/null
sudo systemctl disable --now avahi-daemon.service 2>/dev/null
sudo systemctl disable --now bluetooth.service 2>/dev/null
# Lister les ports en écoute
sudo ss -tulpn
# Chaque port ouvert doit être justifié. En cas de doute : disable.2.6 Action 6 — Audit initial avec Lynis
# Installation
sudo apt install -y lynis
# Ou depuis upstream pour version récente
cd /opt && sudo git clone https://github.com/CISOfy/lynis
cd lynis && sudo ./lynis audit system
# Le rapport donne un score (Hardening index) sur 100 et une liste de warnings et suggestions priorisées
# Score cible initial : 70+
# Score cible sous 1 mois : 80+
# Score cible production mature : 85+
# Log complet
less /var/log/lynis.log
less /var/log/lynis-report.dat2.7 Action 7 — Logging et audit initial
journald systemd hardening
# Persistance des logs entre reboots
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
# Configuration rétention
sudo tee -a /etc/systemd/journald.conf << 'EOF'
SystemMaxUse=2G
SystemKeepFree=500M
MaxRetentionSec=30day
ForwardToSyslog=yes
Compress=yes
EOFauditd pour les événements sécurité
sudo apt install -y auditd audispd-plugins
sudo systemctl enable --now auditd
# Règles de base (loguer les commandes sudo, modifs /etc, tentatives d'escalade)
sudo tee /etc/audit/rules.d/hardening.rules << 'EOF'
# Fichiers d'authentification
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
# SSH config
-w /etc/ssh/sshd_config -p wa -k sshd
# Commandes privilégiées
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=-1 -k root-cmd
EOF
sudo augenrules --load
sudo systemctl restart auditd
# Consulter les events
sudo ausearch -k identity -ts today3. Les 3 domaines intermédiaires (phase 2, semaines 2-4)
Après les 7 actions prioritaires, montée en maturité progressive.
3.1 Kernel parameters via sysctl
Paramètres kernel pour durcir le comportement réseau et mémoire.
sudo tee /etc/sysctl.d/99-hardening.conf << 'EOF'
# Protection ICMP redirect
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
# Protection source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
# SYN cookies contre SYN flood
net.ipv4.tcp_syncookies = 1
# Protection Martian packets (log)
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
# Ignorer ICMP echo broadcasts (smurf attack)
net.ipv4.icmp_echo_ignore_broadcasts = 1
# ASLR kernel
kernel.randomize_va_space = 2
# Protection hardlinks et symlinks contre race conditions
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2
# Désactiver coredumps setuid (evite fuite d'infos)
fs.suid_dumpable = 0
# Restreindre dmesg aux privileged
kernel.dmesg_restrict = 1
# Restreindre ptrace (empêche ptrace across UID arbitraire)
kernel.yama.ptrace_scope = 1
# Kexec désactivé (un attaquant root pourrait loader un autre kernel)
kernel.kexec_load_disabled = 1
# Désactiver unprivileged user namespaces si non utilisés (containers rootless)
# kernel.unprivileged_userns_clone = 0
EOF
sudo sysctl --system3.2 AppArmor (Ubuntu/Debian) ou SELinux (RHEL)
AppArmor : vérifier qu'il est actif, garder en enforce.
sudo aa-status
# Résultat attendu : profiles are in enforce mode
# Si en mode complain, passer en enforce
sudo aa-enforce /etc/apparmor.d/*SELinux sur RHEL : garder en enforcing.
sudo getenforce # doit renvoyer Enforcing
sudo setenforce 1 # si permissive, passer enforcing
sudo sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config3.3 Systemd hardening des services custom
Pour les services applicatifs déployés (ex : une API Node.js ou Python en systemd), durcir l'unit file.
# /etc/systemd/system/myapi.service
[Unit]
Description=My Secure API
After=network.target
[Service]
Type=simple
User=myapi
Group=myapi
WorkingDirectory=/opt/myapi
ExecStart=/opt/myapi/venv/bin/python app.py
Restart=on-failure
RestartSec=5s
# Hardening systemd
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ReadWritePaths=/opt/myapi/data /var/log/myapi
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectKernelLogs=true
ProtectControlGroups=true
ProtectClock=true
ProtectHostname=true
ProtectProc=invisible
ProcSubset=pid
RestrictNamespaces=true
RestrictRealtime=true
RestrictSUIDSGID=true
LockPersonality=true
MemoryDenyWriteExecute=true
SystemCallFilter=@system-service
SystemCallFilter=~@privileged @resources
CapabilityBoundingSet=
AmbientCapabilities=
PrivateDevices=true
PrivateNetwork=false
[Install]
WantedBy=multi-user.targetAudit du durcissement d'un service :
systemd-analyze security myapi.service
# Donne un score (lower = better) et liste les propriétés manquantes4. Les référentiels standardisés à connaître
4.1 CIS Benchmarks (Center for Internet Security)
Le référentiel de facto pour le hardening Linux dans l'entreprise. Disponible gratuitement en PDF sur cisecurity.org/benchmark.
- CIS Ubuntu Linux 22.04 LTS Benchmark (mise à jour régulière, v2.0.0 2024).
- CIS Red Hat Enterprise Linux 9 Benchmark.
- CIS Debian Linux 12 Benchmark.
- CIS Amazon Linux 2023 Benchmark.
Structure : 2 niveaux (Level 1 server / workstation, Level 2 renforcé). Chaque contrôle numéroté (ex 5.2.1) avec description, audit, remédiation, justification.
Automatisation : OpenSCAP fournit des profils CIS Level 1 et Level 2 scannables en CLI.
4.2 ANSSI Guide d'hygiène informatique
Guide français officiel en 42 règles, version 2024 téléchargeable sur ssi.gouv.fr. Plus concis que CIS, couvre les pratiques fondamentales applicables à toute infrastructure française.
Cible : OIV, OSE, EE/EI sous NIS 2, mais applicable universellement.
4.3 NIST SP 800-123 Guide to General Server Security
Guide US généraliste, moins prescriptif que CIS mais excellent pour comprendre le pourquoi derrière chaque pratique.
4.4 DISA STIG (Security Technical Implementation Guide)
Le plus strict (US Department of Defense). Environ 300-400 contrôles pour RHEL 9 STIG. Overkill pour la plupart des contextes mais référence pour environnements haute sensibilité.
5. Outils d'audit détaillés
5.1 Lynis (recommandé débutant)
Score cible par niveau de maturité
| Niveau | Hardening Index | Durée typique |
|---|---|---|
| Installation par défaut Ubuntu/Debian | 50-60 | — |
| Après quick wins 2-4h débutant | 70-75 | J+1 |
| Après hardening intermédiaire 2 semaines | 80-85 | Semaine 2-4 |
| Production mature conforme CIS L1 | 85-90 | Mois 2-6 |
| Haute sensibilité CIS L2 ou STIG | 90+ | Chantier dédié |
Interprétation des findings : Warning = action prioritaire, Suggestion = à traiter en second temps. Ne pas chercher le score 100 (certaines suggestions ne s'appliquent pas à tous les contextes).
5.2 OpenSCAP
# Installation
sudo apt install -y libopenscap8 openscap-scanner ssg-base
# Sur RHEL : sudo dnf install -y openscap-scanner scap-security-guide
# Lister les profils disponibles
oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml
# Scan avec profil CIS Level 1 Server
sudo oscap xccdf eval \
--profile xccdf_org.ssgproject.content_profile_cis_level1_server \
--results /tmp/ssg-results.xml \
--report /tmp/ssg-report.html \
/usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml
# Ouvrir le rapport HTML
xdg-open /tmp/ssg-report.html5.3 Chef InSpec (automation CI)
Framework de tests de conformité scriptables, idéal en CI.
# example.rb - test InSpec basique
control 'ssh-01' do
impact 1.0
title 'SSH root login must be disabled'
describe sshd_config do
its('PermitRootLogin') { should eq 'no' }
end
end
control 'ssh-02' do
impact 1.0
title 'SSH PasswordAuthentication must be disabled'
describe sshd_config do
its('PasswordAuthentication') { should eq 'no' }
end
endExécution : sudo inspec exec example.rb.
6. Playbook Ansible type
Pour industrialiser le hardening sur plusieurs serveurs.
# hardening.yml - playbook Ansible minimal
- hosts: linux_servers
become: true
tasks:
- name: Apt update and upgrade
apt:
update_cache: yes
upgrade: dist
autoremove: yes
- name: Install security packages
apt:
name:
- unattended-upgrades
- fail2ban
- ufw
- auditd
- apparmor
- apparmor-utils
state: present
- name: Enable unattended-upgrades
systemd:
name: unattended-upgrades
enabled: yes
state: started
- name: Configure sshd hardening
blockinfile:
path: /etc/ssh/sshd_config.d/99-hardening.conf
create: yes
mode: "0644"
block: |
PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3
ClientAliveInterval 300
X11Forwarding no
notify: reload sshd
- name: Deploy hardened sysctl
copy:
dest: /etc/sysctl.d/99-hardening.conf
content: |
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.tcp_syncookies = 1
kernel.randomize_va_space = 2
kernel.yama.ptrace_scope = 1
fs.protected_symlinks = 1
fs.protected_hardlinks = 1
notify: reload sysctl
- name: Configure UFW
ufw:
state: enabled
policy: deny
logging: "on"
- name: Allow SSH
ufw:
rule: allow
port: "22"
proto: tcp
- name: Enable fail2ban
systemd:
name: fail2ban
enabled: yes
state: started
- name: Enable auditd
systemd:
name: auditd
enabled: yes
state: started
handlers:
- name: reload sshd
systemd:
name: sshd
state: reloaded
- name: reload sysctl
command: sysctl --systemPour production, des rôles Ansible existants : dev-sec/ansible-collection-hardening (projet communautaire maintenu depuis 2014), OpenSCAP Ansible content.
7. Checklist débutant 30 contrôles
checklist_hardening_linux_debutant = {
# Patch management
"mises_a_jour_immediates": "apt upgrade ou dnf update exécuté",
"unattended_upgrades_actif": "Mises à jour sécurité automatiques activées",
"reboot_apres_kernel": "Reboot planifié si mise à jour kernel",
# Utilisateurs et sudo
"user_non_root": "User non-root créé avec sudo",
"root_login_disabled": "passwd -l root appliqué",
"sudoers_audite": "sudoers propre, pas de NOPASSWD abusif",
# SSH
"ssh_password_auth_off": "PasswordAuthentication no",
"ssh_root_login_off": "PermitRootLogin no",
"ssh_key_ed25519": "Clé SSH ed25519 déployée",
"fail2ban_actif": "fail2ban activé sur sshd",
"ssh_max_auth_tries": "MaxAuthTries 3",
# Firewall
"firewall_deny_default": "Firewall policy deny par défaut",
"firewall_ports_justifies": "Chaque port ouvert justifié",
# Kernel sysctl
"sysctl_hardening_deploy": "99-hardening.conf déployé",
"aslr_active": "kernel.randomize_va_space = 2",
"ptrace_scope": "kernel.yama.ptrace_scope = 1",
# MAC
"apparmor_selinux_enforce": "AppArmor ou SELinux en enforce/enforcing",
# Services
"services_inutiles_off": "CUPS, Avahi, Bluetooth désactivés si non utilisés",
"ports_ecoute_audits": "ss -tulpn review, chaque port justifié",
# Logging
"auditd_actif": "auditd installé et running",
"journald_persistent": "journald logs persistants configurés",
"retention_logs_30j": "Retention logs 30 jours minimum",
# Systemd hardening services custom
"services_no_new_privs": "NoNewPrivileges=true sur services applicatifs",
"services_private_tmp": "PrivateTmp=true sur services applicatifs",
# File system
"permissions_sensitive_files": "chmod 600 /etc/shadow, /etc/gshadow",
"tmp_noexec_option": "Montage /tmp avec noexec,nosuid,nodev si possible",
# Audit outils
"lynis_score_70": "Score Lynis supérieur à 70",
"openscap_cis_l1_scan": "Scan OpenSCAP CIS Level 1 exécuté",
# Documentation
"runbook_baseline": "Runbook baseline documenté en markdown",
"changes_tracked_git": "Config /etc trackée en Git (etckeeper ou Ansible)",
}
# Viser 25 plus sur 30 en débutant8. Erreurs classiques à éviter
Erreur 1 — Désactiver SELinux ou AppArmor
Le pattern toxique numéro un. Solution : passer en permissive temporairement pour debugger, générer les policies manquantes, repasser en enforce.
Erreur 2 — Changer le port SSH vers 2222 comme "sécurité"
Security by obscurity inutile. Les scanners modernes testent tous les ports en quelques heures. Garder SSH 22 avec auth clés + fail2ban + MaxAuthTries 3 est supérieur au changement de port.
Erreur 3 — Ajouter 100 règles iptables custom
Les règles complexes deviennent vite non maintenables et introduisent des failles. Préférer nftables ou ufw simple, quelques règles claires et documentées.
Erreur 4 — Oublier la revue régulière
Un serveur hardené en J0 dérive en 6 mois (nouveaux services installés, patches manqués, règles ajoutées à la volée). Scan Lynis mensuel + revue Git config + audit trimestriel minimum.
Erreur 5 — Hardening sans backups testés
Un hardening agressif peut casser des applications ou bloquer l'accès admin. Toujours tester sur staging, snapshotter avant, documenter les rollbacks.
Erreur 6 — Ignorer les containers sur le node
Hardener le host mais laisser les containers en privileged annule une grande partie du bénéfice. Voir Container escape : explication pour la complémentarité.
Erreur 7 — Confondre hardening et conformité
Un score Lynis 90 n'est pas équivalent à une certification ISO 27001 ou SOC 2. Le hardening contribue à la conformité mais ne la remplace pas (processus, documentation, revues formelles exigés).
Points clés à retenir
- Hardening Linux = réduction de surface d'attaque par configuration, couvre 10 domaines (patch, users, SSH, firewall, sysctl, systemd, FS, logs, MAC, services).
- Les 7 actions prioritaires 2-4 heures débutant : mises à jour + unattended-upgrades, user non-root + sudo + désactivation login root, SSH clés + fail2ban + PermitRootLogin no, firewall deny par défaut, désactivation services inutiles, audit Lynis initial, logging auditd.
- Patch management est l'action numéro un absolue : un serveur non patché depuis 6 mois est plus vulnérable qu'un serveur mal hardené mais patché en 48h.
- Référentiels 2026 : CIS Benchmarks (par distribution, dominant), ANSSI Guide Hygiène informatique (France), NIST SP 800-123, DISA STIG (haute sensibilité).
- Outils d'audit : Lynis (gratuit, score sur 100, accessible débutant), OpenSCAP (profils CIS/STIG), Chef InSpec (tests scriptables en CI).
- Scores Lynis cibles : 70+ après 2-4h, 80+ sous 1 mois, 85+ production mature, 90+ CIS L2 ou STIG.
- Jamais désactiver AppArmor/SELinux : utiliser permissive puis audit2allow au lieu de disabled.
- Industrialisation Ansible : rôles communautaires
dev-sec/ansible-collection-hardeninget OpenSCAP Ansible content. - Nodes Kubernetes = Linux hosts : hardening OS reste fondamental même en environnement cloud native (voir Container escape : explication).
Pour aller plus loin
- Container escape : explication — complémentarité hardening host et sécurité container.
- Least privilege : définition — principe structurant appliqué à sudo, IAM, RBAC.
- CI/CD sécurisée : définition — hardening des pipelines qui déploient sur ces serveurs.
- Roadmap DevSecOps — hardening Linux au niveau 1 Socle IT et niveau 2 DevOps core.
- Devenir DevSecOps sans expérience — pillar DevSecOps avec contexte marché.







