Un attaquant modifie un binaire système : comment le détectez-vous, et que devient cette modification ? Sur un OS immuable, le système n'est pas retouché en place : on le remplace par une image complète, validée à l'avance, que l'on peut annuler en une bascule. Ce module, placé après le confinement des services, explique le mécanisme, situe les familles d'OS et ce que l'immuabilité ne garantit pas, puis prend NixOS comme terrain d'application : durcir par déclaration, revenir en arrière, lire un poste durci selon l'ANSSI et publié par la DINUM (Direction interministérielle du numérique).
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Expliquer le mécanisme d'un système en lecture seule avec mise à jour atomique
- Distinguer ce qu'une image immuable protège de ce qu'elle laisse inscriptible
- Choisir la famille d'OS immuable adaptée à un serveur, à un cluster ou à un poste
- Anticiper la gestion des données persistantes, qui fait échouer la plupart des premières mises en oeuvre
- Situer NixOS, dont l'approche déclarative diffère de celle des OS à images
Pourquoi ce module vient après « Confiner les services » ?
Section intitulée « Pourquoi ce module vient après « Confiner les services » ? »Les modules précédents de la formation durcissent un système que l'on garde et qui dérive : on pose des réglages, on contrôle, on corrige. Le module Confiner les services limite ce qu'un service compromis peut faire. Le présent module change de question : au lieu de surveiller une machine qui se modifie, on empêche qu'elle se modifie en dehors d'un déploiement. C'est une stratégie complémentaire, pas un remplacement, et elle s'appuie sur les mêmes mesures que NixOS permet de déclarer : sysctl, montages, SSH, PAM et pare-feu vus dans la formation, plus auditd et fail2ban, qui ont leur tutoriel à part.
Le fil du module est le suivant. La présente page pose le modèle mental. La page NixOS : c'est quoi, pour qui, et comment l'essayer montre ce que ce modèle apporte sur une distribution réelle et ce qu'il coûte. La page NixOS : durcir par déclaration applique en Nix les mesures déjà vues dans la formation, et y ajoute auditd, leçon du module Accès, et fail2ban, présenté dans son tutoriel. La page NixOS : rollback, générations et mode rescue traite le retour arrière et ses risques, et la page Sécurix lit un poste NixOS construit sur le guide ANSSI-BP-028.
Les pages NixOS supposent la base Nix (langage, options,
configuration.nix), expliquée dans la page Écrire une première configuration NixOS
de la formation Linux : lisez-la d'abord si services.nginx.enable = true; ne
vous dit rien.
Deux tutoriels d'installation, hors du plan de la formation, servent de support si vous voulez monter la machine : installer NixOS avec une flake minimale et NixOS dans WSL.
Pourquoi les OS immuables existent-ils ?
Section intitulée « Pourquoi les OS immuables existent-ils ? »Les systèmes traditionnels accumulent les modifications : paquets installés, fichiers de configuration édités, dépendances mises à jour. Cette dérive de configuration produit des machines uniques, difficiles à reproduire et à sécuriser, comme le détaille la page États de référence et dérive. Un OS immuable répond à ce problème par la reproductibilité : la même image, déployée partout, donne le même système.
La notion voisine d'infrastructure immuable (remplacer une machine plutôt que la modifier) est traitée côté IaC dans la page Infrastructure mutable ou immuable. Ici, l'immuabilité s'applique au système d'exploitation lui-même, à l'intérieur d'une machine.
Comment fonctionne un OS immuable ?
Section intitulée « Comment fonctionne un OS immuable ? »Quatre mécanismes se combinent, avec des variantes selon les OS. Aucun n'est absolu : retenez le principe, puis vérifiez ce que fait l'OS que vous visez.
Quelle partie du système est en lecture seule ?
Section intitulée « Quelle partie du système est en lecture seule ? »Le principe est de monter en lecture seule la partie du système qui contient
les programmes, de sorte qu'une retouche à chaud soit impossible ou
détectable. La partie concernée varie selon l'OS : sur Talos, c'est
la quasi-totalité du système de fichiers (seule une partition éphémère reste inscriptible) ; sur Fedora Silverblue et les OS bâtis sur
rpm-ostree, c'est surtout /usr, alors que /etc et /var restent
inscriptibles ; sur NixOS, seul /nix/store est en lecture seule, et
/etc est régénéré à chaque activation. Les répertoires de données
(/var, /home) restent presque toujours inscriptibles.
Comment se passe une mise à jour atomique ?
Section intitulée « Comment se passe une mise à jour atomique ? »Les mises à jour ne modifient pas le système en place. Une nouvelle image complète est préparée à côté de l'ancienne, puis le système bascule dessus, le plus souvent au redémarrage. Si la bascule échoue, l'ancienne version reste disponible : on parle de mise à jour atomique (tout ou rien). Certains OS gardent pour cela deux emplacements système en alternance, dits A/B : on écrit dans celui qui est inactif, puis on change d'emplacement actif. Le schéma suit une mise à jour, son retour arrière et le piège qui l'accompagne.
Comment revient-on en arrière ?
Section intitulée « Comment revient-on en arrière ? »Chaque version du système est conservée tant qu'on ne la supprime pas. En cas de problème, on redémarre sur la version précédente, sans restaurer de sauvegarde ni réinstaller. Sur NixOS, la bascule se fait même sans redémarrage. Cette rapidité a un revers : un retour arrière peut remettre en service une version déjà vulnérable, point détaillé dans la page de rollback citée plus haut.
Où vivent les données ?
Section intitulée « Où vivent les données ? »Les données persistantes (bases, journaux, fichiers utilisateur) sont stockées à part du système, ce qui permet de recréer celui-ci à l'identique sans les perdre. C'est aussi le point faible des premières mises en oeuvre : un retour arrière ne restaure pas les données, et une base laissée sur le mauvais volume disparaît avec l'image.
Qu'est-ce que l'immuabilité garantit, et que ne garantit-elle pas ?
Section intitulée « Qu'est-ce que l'immuabilité garantit, et que ne garantit-elle pas ? »L'immuabilité n'est pas une barrière absolue. Un attaquant qui obtient les droits root sur l'hôte peut, sur certains OS, remonter une partition en écriture, et il reste libre d'écrire dans les répertoires de données. Ce qu'elle apporte est plus précis : une modification faite sur le système est hors du chemin de mise à jour, donc elle disparaît à la prochaine bascule d'image, et elle se détecte par comparaison avec l'image de référence.
Autrement dit, un OS immuable réduit la surface d'attaque persistante et rend la dérive visible, mais il ne remplace ni le confinement des services, ni la gestion des secrets, ni la supervision. C'est pourquoi ce module suit les modules de durcissement au lieu de les remplacer.
Qui est concerné ?
Section intitulée « Qui est concerné ? »Un OS immuable ne se choisit pas pour ses qualités intrinsèques mais parce qu'il résout un problème que vous avez déjà. Cherchez dans ce tableau la ligne qui décrit votre quotidien : si aucune ne vous parle, le coût d'apprentissage ne sera pas rentabilisé. Le cas le plus courant reste celui de la ligne Ops / SRE, où la reproductibilité d'un parc de machines pèse plus lourd que la souplesse de modification.
| Profil | Besoin principal |
|---|---|
| Ops / SRE | Déployer des systèmes reproductibles et sécurisés |
| DevOps | Infrastructure immuable, rollback rapide |
| Équipe sécurité | Réduire la surface d'attaque, détecter la dérive |
| Architecte cloud | Standardiser les images de base |
Quelles familles d'OS immuables choisir ?
Section intitulée « Quelles familles d'OS immuables choisir ? »On distingue deux usages : les OS pour serveurs et conteneurs, et ceux pour postes de travail. Dans les deux cas, le modèle est celui d'une image remplacée en bloc, sauf NixOS, qui construit son système à partir d'une déclaration.
Pour serveurs et conteneurs
Section intitulée « Pour serveurs et conteneurs »Ces quatre systèmes partagent le modèle d'image immuable mais s'adressent à des
contextes différents. La colonne Usage est celle qui décide : trois d'entre
eux sont liés à une plateforme précise, et le seul réellement généraliste est
Flatcar. Talos pousse la logique le plus loin en supprimant le shell et
SSH, ce qui élimine une classe d'attaques mais impose de passer par son API et
talosctl pour tout diagnostic : le guide Déployer des clusters Kubernetes avec Talos Linux le met en pratique, et le cluster Talos sur Outscale le déploie dans le cloud.
| OS | Usage | Particularité |
|---|---|---|
| Talos | Kubernetes | API-only, pas de shell |
| Flatcar | Conteneurs | Successeur de CoreOS |
| Bottlerocket | AWS/EKS | Optimisé Amazon |
| RHCOS | OpenShift | Red Hat, intégré OCP |
Flatcar a deux billets de retour d'expérience sur le site : Os Immutable: Flatcar Linux l'installe et explique ses mises à jour, et Contrôler les mises à jour Flatcar avec Nebraska montre comment les piloter depuis un serveur interne.
L'hyperviseur n'est pas oublié : Incus OS est un système immuable sans shell dédié à Incus, que présente la page Incus OS : l'OS immuable dédié à Incus et dont les mises à jour A/B et le retour arrière sont décrits dans Incus OS : mises à jour A/B et rollback.
Pour postes de travail
Section intitulée « Pour postes de travail »Sur un poste de travail, l'immuabilité change surtout la façon d'installer des
logiciels : les applications passent par Flatpak (des applications isolées,
installées à part du système) ou par des conteneurs de développement, et les
paquets système par une superposition (rpm-ostree install, l'outil des images
Fedora) qui exige un redémarrage. Le bénéfice est le même que sur serveur,
un système qui revient à un état connu, mais la contrainte se ressent au
quotidien. Notez que les variantes bureau d'openSUSE MicroOS ont été renommées
en 2023 : Aeon pour GNOME, Kalpa pour Plasma.
| OS | Bureau | Base |
|---|---|---|
| Fedora Silverblue | GNOME | Fedora, rpm-ostree |
| Fedora Kinoite | KDE Plasma | Fedora, rpm-ostree |
| NixOS | Variable | Nix, déclaratif |
| openSUSE Aeon / Kalpa | GNOME / KDE Plasma | MicroOS, transactional-update |
Quelle est l'approche déclarative de NixOS ?
Section intitulée « Quelle est l'approche déclarative de NixOS ? »NixOS est un cas particulier : tout le système se définit dans des fichiers
de configuration. Le Nix Store (/nix/store/) est en lecture seule et chaque
modification crée une nouvelle génération, que l'on peut réactiver. Ce
n'est pas une image scellée : l'immuabilité vient du store et de la
régénération de /etc. Les pages NixOS de ce module montrent ce
que cela donne en pratique, et le billet NixOS pour administrer un cluster Talos air-gapped
raconte un poste d'administration NixOS qui pilote un cluster sur OS immuable.
Quels sont les pièges courants ?
Section intitulée « Quels sont les pièges courants ? »Ces erreurs ont un point commun : elles consistent à conserver ses habitudes d'administration sur un système qui ne les tolère plus. Les deux premières sont les plus coûteuses, parce qu'elles ne se manifestent pas immédiatement. Un système modifié à chaud fonctionne parfaitement jusqu'à la mise à jour suivante, qui efface silencieusement le correctif ; des données persistantes mal isolées ne posent aucun problème jusqu'au premier rollback, qui les emporte.
- Vouloir modifier le système « juste pour tester » : cela contourne le principe même de l'immuabilité
- Ignorer la gestion des données persistantes : les données d'un service restent le point difficile
- Sous-estimer la courbe d'apprentissage : NixOS ou Talos demandent un investissement initial
- Oublier les mises à jour : immuable ne veut pas dire « jamais mis à jour »
- Mélanger les approches : un système à moitié immuable perd les bénéfices des deux mondes
- Croire que « si ça compile, ça marche » sur NixOS : une configuration qui se construit sans erreur peut produire un système qui ne démarre pas
Quels OS explorer ensuite ?
Section intitulée « Quels OS explorer ensuite ? »Cette liste sert à choisir sur quoi investir votre temps de test, pas à comparer des fonctionnalités. Les quatre premiers sont des OS complets et maintenus par un éditeur ou une fondation ; Kairos est d'une autre nature, puisqu'il transforme une distribution existante en système immuable et s'adresse donc à ceux qui ne veulent pas changer de base.
- Talos, Kubernetes-native, API-only, sécurité maximale → talos.dev
- Flatcar, Successeur de CoreOS, focus conteneurs → flatcar-linux.org
- Bottlerocket, AWS, optimisé EKS → aws.amazon.com/bottlerocket
- Fedora Silverblue, Desktop immuable GNOME → silverblue.fedoraproject.org
- Kairos, Meta-distro, convertit d'autres distros en immuable → kairos.io
À retenir
Section intitulée « À retenir »- Immuable = reproductible : une image validée, déployée à l'identique.
- Rollback rapide : retour à l'état précédent en secondes, mais sans les données, et parfois vers une version déjà vulnérable.
- Surface d'attaque persistante réduite : une modification hors déploiement ne survit pas à la bascule suivante ; un attaquant root garde des marges, ce n'est pas une barrière absolue.
- La partie en lecture seule varie : la quasi-totalité du système de fichiers sur Talos, surtout
/usrsur rpm-ostree, seulement/nix/storesur NixOS. - Courbe d'apprentissage : investissement initial, gains sur le long terme, surtout sur un parc.