Isolation
Sécurité
Cloisonnement qui empêche un processus, un conteneur, une machine virtuelle ou un locataire d'accéder aux ressources des autres (mémoire, fichiers, réseau, temps processeur). Le but : qu'une compromission ou un plantage reste confiné à son propre périmètre.
Niveaux de cloisonnement : Du plus léger au plus étanche : processus séparés par le noyau, conteneurs (namespaces, cgroups), machines virtuelles sous hyperviseur, puis machines physiques distinctes. Chaque cran ajoute de l'étanchéité, et du coût.
Ce qui fuit quand même : Les canaux auxiliaires (cache partagé, Spectre, Meltdown) traversent les cloisons logicielles en mesurant des temps d'accès. Un conteneur partage le noyau de l'hôte : une seule faille noyau suffit pour en sortir.
Pièges courants : Lancer en root, monter le socket Docker, ouvrir les capabilities « pour que ça marche » : chaque option rogne la cloison. Vingt ans de métier apprennent qu'un conteneur privilégié n'isole plus grand-chose, à part la conscience tranquille de la personne qui l'a déployé.
Homonyme transactionnel : En base de données, le I d'ACID désigne l'isolation des transactions concurrentes, réglée par des niveaux (Read Committed, Repeatable Read, Serializable). On y retrouve la même idée de non-interférence, à un autre étage de la pile.
Ce qui arrive si on s'en passe
Sans isolation, tout ce qui s'exécute sur un même hôte partage un seul périmètre : un processus compromis peut lire la mémoire, les fichiers et les secrets de ses voisins (clés, jetons, variables d'environnement), intercepter leur trafic réseau et agir avec leurs droits. Un locataire peut atteindre les données d'un autre locataire hébergé sur la même infrastructure. Une faille exploitée dans un seul composant ouvre alors l'accès à l'ensemble, ce qui retire tout effet au moindre privilège. Un programme qui épuise la mémoire, le disque ou le temps processeur prive aussi les autres de ressources et peut faire tomber tout l'hôte. Après un incident, aucune frontière ne permet de délimiter ce qui a été touché : la remise en état impose de considérer l'hôte entier comme suspect.
Explication de la marmotte
Imagine un immeuble où chaque appartement a ses propres murs, sa porte et son compteur d'eau. Si un voisin fait brûler son dîner ou laisse déborder son bain, le problème reste chez lui : la fumée et l'eau ne passent pas chez toi. En informatique, c'est pareil. Plusieurs programmes tournent sur le même ordinateur, et on construit des murs invisibles entre eux. Si l'un plante ou se fait pirater, il ne peut ni lire tes fichiers ni casser les autres programmes. Plus les murs sont épais, plus c'est sûr, mais plus ça coûte de place et d'énergie.
Où ce terme est utilisé
- Isolation multi-locataire face à un locataire hostile (11 occurrences)
- Rowhammer, Spectre et Meltdown, mécanismes et contre-mesures (8 occurrences)
- Spectre et Meltdown : exécution spéculative et fuite par cache (8 occurrences)
- La politique de même origine : ce que le navigateur cloisonne vraiment (7 occurrences)
- Évasion de VM et isolation matérielle des hyperviseurs (6 occurrences)
- Hyperviseur Type 1 ou Type 2 : lequel choisir (6 occurrences)
- Isolation des conteneurs Docker : namespaces, cgroups et évasions (6 occurrences)
- Comment isoler les clés dans un HSM multi-tenant (5 occurrences)
- Docker ou Podman en auto-hébergement : root, rootless, isolation (5 occurrences)
- JavaScript et SQL côté web, ce qu'il faut savoir des deux langages (5 occurrences)