Durcir un système n’est pas une collection de recettes disparates : c’est une démarche qui répond à quatre enjeux distincts, qu’il faut traiter dans l’ordre pour ne pas se perdre dans les détails avant d’avoir posé les fondations.
Quatre enjeux, un seul fil conducteur
Le premier enjeu est business : identifier les menaces réelles, en formalisant un modèle de risque (threat model) qui répond à la question « que cherche-t-on à éviter, et par quel biais ? ». Le second est gouvernance : définir une politique de sécurité (security policy) destinée à réduire ces risques identifiés. Le troisième relève de l’architecture et de l’implémentation : quelles options s’offrent pour appliquer concrètement cette politique sur le système cible, et quelles adaptations la faisabilité, le coût et l’utilisabilité imposent-elles ? Le quatrième, enfin, est la correction assurantielle — la validation continue que ce qui a été mis en œuvre tient réellement ses promesses.
Modéliser la menace
Un modèle de menace identifie les biens à protéger, les adversaires probables, les menaces envisageables — ce qui serait tenté —, les vecteurs d’attaque — la façon dont cela serait tenté —, et les limites du système, y compris les partis pris de confiance qu’on accepte d’assumer.
Un modèle de menace pour un opérateur cloud
On cherche à protéger les centres de données contre des cyberattaquants — étatiques, individuels, concurrents —, notamment pour prévenir une intrusion visant l’intégrité, la disponibilité ou la confidentialité des données. Une telle compromission peut survenir si des systèmes de contrôle et d’administration sont exposés et insuffisamment sécurisés, ou si un prestataire faillit à ses obligations de conformité.
Deux modèles de politique de sécurité
Multilevel Security (MLS)
Le Multilevel Security applique le modèle d’accès obligatoire Bell-LaPadula, qui étiquette sujets (processus, utilisateurs) et objets (fichiers, périphériques) selon des niveaux de sécurité. Chaque niveau combine une sensibilité hiérarchique (non classifié, confidentiel, secret, top secret) et, éventuellement, une catégorie non hiérarchique, répondant au principe du « besoin d’en connaître ».
Deux propriétés garantissent la confidentialité : le « no read up » (Simple Security Property), qui interdit à un sujet de lire un objet de niveau supérieur au sien, et le « no write down » (*-Property), qui l’empêche d’écrire vers un objet de niveau inférieur — afin qu’une information classifiée ne puisse jamais « descendre » vers un niveau moins protégé. L’objectif est unique : éviter toute fuite de données. Ce modèle, principalement employé dans les environnements militaires et gouvernementaux, s’implémente notamment dans SELinux ou les Solaris Trusted Extensions.
Multilateral Security
Le Multilateral Security répond à une préoccupation différente : compartimenter les données pour restreindre l’accès à des sous-ensembles d’information spécifiques, sans nécessairement suivre une hiérarchie de secret. Le mécanisme repose sur des étiquettes qui séparent l’information par groupe ou domaine, garantissant que la compromission d’un secteur n’entraîne pas celle de l’ensemble du système.
Confiance, surface d’attaque et moniteur de référence
Confiance (Trust)
Un système ou un composant est dit de confiance s’il peut, par sa seule défaillance, mettre en péril la politique de sécurité.
Surface d'attaque
La somme des vulnérabilités, chemins d’accès et méthodes — les vecteurs d’attaque — qu’un adversaire peut exploiter pour accéder illégitimement à un système.
Le moniteur de référence (reference monitor) est le composant chargé de contrôler tous les accès aux ressources — un arbitre externe qui ne fait confiance à personne, et ne se fie qu’à une liste de permissions explicite (souvent une ACL). Pour être réellement sécurisé, un tel moniteur doit satisfaire trois garanties : la médiation complète (chaque opération sensible est interceptée et vérifiée, sans exception) ; l’inviolabilité (le moniteur et sa base de règles sont protégés contre toute modification par un processus non fiable) ; et la vérifiabilité (le mécanisme reste assez petit et simple pour être analysé et testé rigoureusement). Sous Linux, le framework LSM (Linux Security Modules) définit précisément cette interface, derrière laquelle SELinux ou AppArmor implémentent la logique de décision.
La base de confiance (TCB)
Trusted Computing Base
Ensemble des composants — matériels, logiciels, humains — dont le fonctionnement correct suffit à garantir l’application de la politique de sécurité. La compromission d’un seul d’entre eux suffit à ouvrir une brèche.
WARNING
Le TCB doit rester aussi petit que possible : chaque composant qui y entre devient, par définition, un point de défaillance critique.
L’exemple de gVisor illustre cette logique de réduction. Ce sandbox open-source compatible Linux minimise la possibilité d’exploitation directe de l’API système par les applications, ainsi que l’exploitabilité indirecte — l’enchaînement d’exploits via un composant sandbox lui-même bogué. Ses concepteurs rappellent une évidence trop souvent oubliée : « a sandbox is not a substitute for a secure architecture ». J’y reviens plus en détail dans la note sur les hyperviseurs et la virtualisation.
La complexité, ennemie silencieuse
Une fonctionnalité peut exiger de la complexité pour être implémentée — mais cette complexité augmente mécaniquement la surface d’attaque. Le noyau Linux, à titre d’illustration, compte 81 500 fichiers et 36 millions de lignes de code ; pourtant, un système Linux courant n’en exploite probablement que 5 à 10 %1. Chaque ligne de code non utilisée reste, malgré tout, une surface potentielle d’exploitation.
Les trois principes généraux
Trois principes structurent, en définitive, toute démarche de durcissement sérieuse : minimiser le système à ce qui est strictement nécessaire ; appliquer le principe de moindre privilège, en compartimentant les tâches et en n’accordant à chaque entité que le minimum d’autorisations requis pour agir ; et déployer une défense en profondeur, en sécurisant les configurations par défaut et en superposant plusieurs couches de contrôle indépendantes, de sorte qu’une seule défaillance ne suffise jamais à tout compromettre.
Footnotes
-
Greg Kroah-Hartman, Linux Kernel Security, Linux Foundation. ↩