Modèles Bell-LaPadula, Biba et Clark-Wilson

Modèles Bell-LaPadula, Biba et Clark-Wilson

Bell-LaPadula, Biba et Clark-Wilson ne sont pas des recettes de configuration. Ce sont des modèles qui définissent précisément ce qu’un contrôle d’accès doit interdire pour préserver une propriété donnée, confidentialité ou intégrité. Leur valeur actuelle tient moins à leur âge qu’à la discipline qu’ils imposent : annoncer une garantie, puis accepter ce qu’elle casse.

Explication de la marmotte

Ces modèles ressemblent à un règlement qui décide qui peut consulter, modifier ou valider certains documents selon son rôle et leur sensibilité. Leur but est d’éviter qu’une information parte au mauvais endroit ou qu’une décision soit modifiée par une personne qui ne devrait pas pouvoir le faire.

→ Lire l’explication complète de la marmotte

Bell-LaPadula et la confidentialité par niveaux

Le modèle Bell-LaPadula protège la confidentialité dans un système où les sujets, généralement des utilisateurs ou processus, et les objets, généralement des fichiers ou ressources, reçoivent un niveau de sécurité. Une étiquette combine typiquement un niveau hiérarchique, tel que public, confidentiel ou secret, et des catégories compartimentées, par exemple PROJET-A ou RH.

Sa règle fondamentale est no read up : un sujet de niveau inférieur ne lit pas un objet de niveau supérieur. Un opérateur étiqueté Confidentiel ne peut donc pas lire une donnée Secret. Cette propriété est nommée propriété de sécurité simple.

La seconde règle est no write down : un sujet ne peut pas écrire vers un niveau inférieur. Un processus ayant lu un document Secret ne doit pas copier son contenu dans un fichier Public. C’est la propriété étoilée, souvent notée *-property. Elle traite le problème qui échappe aux contrôles fondés sur la seule lecture : un sujet autorisé à consulter une donnée peut encore l’exfiltrer en l’écrivant ailleurs.

Le compromis est brutal et il faut l’assumer : Bell-LaPadula protège le flux descendant de confidentialité, au prix d’une collaboration transversale pénible. Un analyste qui manipule plusieurs niveaux ne peut pas produire librement une synthèse moins classifiée. Il faut une procédure de déclassification, un processus distinct, une validation humaine et une trace d’audit. Ajouter un bouton « exporter en public » annule le modèle avec l’élégance habituelle d’une porte coupe-feu tenue ouverte par une cale.

Le modèle suppose aussi une hiérarchie fiable des étiquettes. Sans autorité capable d’attribuer, de modifier et de retirer ces étiquettes, la politique devient décorative. L’identité doit être authentifiée avant toute décision, puis ses attributs de sécurité doivent être portés jusqu’au point de contrôle. Les mécanismes d’identités et fédération fournissent une partie de cette chaîne, mais ils ne déterminent pas eux-mêmes le sens métier d’une classification.

Bell-LaPadula n’assure ni l’exactitude des données, ni la disponibilité, ni la loyauté du code exécuté. Un processus Secret compromis peut lire des données Secret conformément à la politique, puis les exfiltrer par un canal non étiqueté, une requête réseau autorisée ou une capture écran. Le modèle bloque des flux définis, pas la physique, les administrateurs omnipotents ou les applications qui confondent journal de diagnostic et dépotoir à secrets.

Biba et l’intégrité en sens inverse

Biba inverse la direction des flux pour protéger l’intégrité. Ici, le niveau ne mesure pas la sensibilité d’une information, mais le degré de confiance accordé à son origine. Une donnée produite par une chaîne de validation contrôlée porte une intégrité supérieure à un fichier reçu depuis une source non vérifiée.

Dans sa forme stricte, Biba impose no read down : un sujet de forte intégrité ne lit pas un objet de faible intégrité. Un processus qui applique une mise à jour système ne doit pas consommer directement une archive téléchargée sans validation. La seconde règle, no write up, interdit à un sujet de faible intégrité de modifier un objet de forte intégrité. Un navigateur compromis ne doit pas pouvoir remplacer un binaire signé ou une règle de sécurité.

Le compromis est l’inverse de Bell-LaPadula : Biba préserve la confiance des traitements élevés, mais rend l’ingestion de données externes laborieuse. C’est voulu. Toute entrée non fiable doit passer par une zone de validation, avec contrôle de format, vérification cryptographique si applicable, analyse métier, puis promotion explicite. Faire monter une donnée sans validation revient à coller une étiquette « certifié » sur un colis trouvé devant la porte.

Bell-LaPadula et Biba stricts ne se superposent pas sur la même échelle sans paralysie. Bell-LaPadula interdit la lecture vers le haut et l’écriture vers le bas. Biba interdit la lecture vers le bas et l’écriture vers le haut. Ensemble, lecture et écriture ne restent possibles qu’entre objets de niveau identique. Cette situation convient à quelques domaines très cloisonnés, pas à une plate-forme commerciale ordinaire.

La décision d’architecture doit donc séparer les dimensions. Utiliser une étiquette de confidentialité pour décider qui peut recevoir une information, et une étiquette d’intégrité, ou une chaîne de validation, pour décider quelles données peuvent influencer un traitement. Confondre les deux dans un unique champ niveau=3 fabrique des refus incompréhensibles et des exceptions permanentes. Une exception permanente est une règle de sécurité qui a démissionné, avec un ticket de changement en guise de certificat médical.

Les contrôles d’intégrité de Windows illustrent une adaptation pragmatique. Le mécanisme Mandatory Integrity Control, ou MIC, attribue des niveaux d’intégrité à certains processus et objets. Un processus à faible intégrité, tel qu’un contenu isolé, est empêché d’écrire vers des objets de niveau plus élevé. Ce n’est pas Biba complet : les lectures et les politiques détaillées dépendent aussi des listes de contrôle d’accès discrétionnaires, des jetons et des privilèges. L’inspiration est néanmoins nette : limiter l’influence ascendante, pas prétendre établir la vérité universelle.

Clark-Wilson, transactions et séparation des tâches

Clark-Wilson part d’un constat commercial : les entreprises manipulent rarement une hiérarchie militaire de documents, mais elles doivent empêcher une facture de devenir payée parce qu’un même compte a créé le fournisseur, validé la commande et lancé le virement. L’intégrité dépend alors moins d’un niveau global que de procédures autorisées.

Le modèle distingue les données contraintes, qui doivent rester cohérentes, des données non contraintes, qui viennent de l’extérieur et ne sont pas encore dignes de confiance. Une procédure de transformation certifiée est le seul chemin autorisé pour modifier une donnée contrainte. Une procédure de vérification contrôle que l’état global respecte les règles métier.

Concrètement, une application de paiement ne devrait jamais accorder une écriture directe sur la table des virements à un compte utilisateur ou à un service applicatif généraliste. Elle doit exposer une transaction atomique, par exemple soumettre_paiement, qui vérifie le montant, l’état de la commande, les approbations requises, l’identité du demandeur et l’absence de doublon. La base conserve ensuite une trace d’audit associant utilisateur, transaction et résultat.

Clark-Wilson impose également la séparation des tâches. Les droits sont attribués non seulement à des rôles, mais à des combinaisons de rôle et de transaction. Le compte qui initie une opération ne doit pas pouvoir l’approuver seul. Cette séparation doit être vérifiée côté serveur et dans le stockage transactionnel. La cacher dans une interface web est insuffisant : un appel direct à l’interface de programmation contourne un bouton aussi facilement qu’un courant d’air contourne une porte de saloon.

Ce modèle est celui à privilégier pour les processus métiers, les changements d’infrastructure sensibles et les opérations d’administration à impact financier ou réglementaire. Les règles doivent être versionnées avec le code, testées contre les chemins d’erreur, puis journalisées dans un système dont les opérateurs métiers ne peuvent pas réécrire l’historique. Les principes de gouvernance de la sécurité aident à définir les responsabilités, mais le contrôle doit vivre dans le mécanisme d’exécution, pas dans un diagramme qui dort dans un espace documentaire.

SELinux et contrôles modernes : héritage, pas magie

Security-Enhanced Linux, ou SELinux, combine principalement le contrôle d’accès obligatoire et l’isolation par types. Le contrôle d’accès obligatoire signifie qu’une politique centrale s’impose même si le propriétaire d’un fichier souhaite accorder un droit plus large. L’isolation par types associe des domaines aux processus et des types aux ressources, puis autorise explicitement leurs interactions.

Le mode Multi-Level Security, ou MLS, de SELinux implémente des contraintes de niveaux inspirées de Bell-LaPadula. Les sensibilités et catégories peuvent empêcher une lecture vers le haut ou une écriture vers le bas. Dans la majorité des déploiements, SELinux est cependant exploité surtout pour le confinement par types, non comme système complet de classification multi-niveaux. Dire que « SELinux est Bell-LaPadula » est donc faux. Dire qu’il n’en reprend rien l’est aussi.

Le prérequis opérationnel est une distribution dont le noyau, les bibliothèques de politique, les outils d’administration et les politiques installées sont compatibles. Le système de fichiers doit conserver les contextes de sécurité, généralement via des attributs étendus. Une restauration faite avec un outil qui ignore ces attributs restaure des fichiers accessibles avec de mauvaises étiquettes. Le service redémarre parfois. Le confinement, lui, est déjà parti prendre l’air.

Les politiques doivent être compilées, revues et déployées comme du code. Un passage brutal en mode bloquant sans observation préalable produit des indisponibilités, souvent attribuées à tort à « SELinux qui casse tout ». En réalité, la politique refuse ce qu’aucun flux légitime n’a décrit. Commencer par collecter les refus, les relier à un flux applicatif précis, puis ajouter l’autorisation minimale. Générer aveuglément des règles à partir des journaux transforme l’analyse de sécurité en distributeur automatique d’exceptions.

Exemple reproductible : observer une décision SELinux

Sur une distribution Linux avec SELinux activé et les outils installés, la commande suivante affiche le contexte du processus courant et celui d’un fichier système. Elle ne modifie aucune politique.

# Vérifier que SELinux est actif et connaître son mode d'application.
getenforce

# Afficher le contexte de sécurité du shell courant.
# Le troisième champ est généralement le domaine du processus.
id -Z

# Afficher le contexte stocké sur un fichier protégé.
# Un contexte inattendu après restauration signale souvent une perte d'attributs.
ls -Z /etc/shadow

Un refus observé dans les journaux doit être traité comme une décision de politique, pas comme une erreur applicative générique. Identifier d’abord le domaine source, le type cible, l’opération refusée et le flux métier attendu. Ensuite seulement, modifier l’étiquetage ou écrire une règle ciblée. Autoriser unconfined_t ou désactiver SELinux pour faire taire l’alerte revient à remplacer un disjoncteur par un fil de cuivre : le silence est garanti jusqu’au moment où il ne l’est plus.

Surface d’attaque, exploitation et reprise

Ces modèles présument un point de décision fiable. Un administrateur capable de modifier la politique, de relabelliser les objets ou de démarrer un noyau alternatif peut contourner les garanties. La séparation des privilèges d’administration est donc obligatoire : administration de la politique, administration système, exploitation applicative et audit ne doivent pas être réunis dans le même compte quotidien.

Les attaques fréquentes exploitent les chemins hors modèle : service réseau trop permissif, montage de volume avec mauvais contexte, sauvegarde qui perd les attributs de sécurité, conteneur exécuté avec des privilèges excessifs, ou journal d’audit accessible en écriture par le processus surveillé. Les fondations de l’architecture cyber doivent couvrir les frontières réseau, l’identité des services et le durcissement de l’hôte, car une étiquette locale ne corrige pas un accès distant ouvert à tous.

Une politique de sécurité est un actif de reprise. Sauvegarder la configuration, les modules locaux, les mappings de contextes, les identités et les journaux d’audit dans des emplacements distincts. Tester la restauration avec vérification explicite des contextes, pas seulement avec le redémarrage des services. Une sauvegarde qui restitue les octets mais pas leurs étiquettes est une reconstruction incomplète, ce qui est une manière polie de dire qu’elle échoue.

La rotation concerne surtout les identités d’administration, les clés de signature des paquets de politique et les certificats utilisés par les chaînes de déploiement. Toute modification de politique doit produire un événement corrélable avec le changement demandé, le paquet appliqué et l’identité qui l’a autorisé. Les modèles formels déterminent ce qui doit être interdit. La supervision détermine si quelqu’un a modifié la règle qui l’interdisait.

🐝 Ce qui arrive si on s’en passe

Sans propriété annoncée au préalable, il ne reste plus de référence permettant de qualifier un accès. Chaque autorisation se décide au cas par cas, ce qui rend impossible la rédaction d’un test de non régression : aucune assertion ne peut affirmer qu’un flux doit être refusé, donc une régression de droits passe pour un comportement normal. L’analyse d’un incident perd son point de comparaison, puisque distinguer une lecture légitime d’un détournement suppose de savoir ce qui était interdit. La revue de code se limite alors à vérifier que l’appel fonctionne, jamais qu’il respecte une invariante. Les demandes d’élargissement s’accumulent sans critère d’arbitrage, et la charge de preuve s’inverse : il faut démontrer qu’un accès nuit, au lieu de démontrer qu’il est nécessaire.

🦫 Explication de la marmotte 🍫

Ces modèles définissent des règles pour empêcher certains échanges entre personnes, programmes et données. Bell-LaPadula protège le secret. Chaque donnée reçoit un niveau de confidentialité. Une personne ou un programme ne peut pas lire une donnée classée plus haut que son autorisation. S’il a lu une donnée sensible, il ne peut pas la recopier dans une donnée moins protégée. Quand une information doit être rendue moins secrète, une décision séparée doit contrôler ce changement.

Biba protège la fiabilité des données. Une donnée venant d’une source peu fiable ne doit pas influencer directement un programme ou un fichier très fiable. Avant de monter en confiance, elle doit être vérifiée. Appliquer Bell-LaPadula et Biba de façon stricte bloque presque tous les échanges entre niveaux différents. Il faut donc séparer la confidentialité de la fiabilité plutôt que leur donner une seule étiquette.

Clark-Wilson protège surtout les opérations métier. Il interdit les modifications directes de certaines données. Seules des opérations prévues, contrôlées et enregistrées peuvent les changer. Il sépare aussi les rôles : la même personne ne doit pas pouvoir lancer et approuver seule une action sensible.

Des systèmes modernes reprennent ces idées. Certains empêchent un programme peu fiable de modifier des fichiers plus protégés. D’autres limitent quels programmes peuvent accéder à quels fichiers. Ces protections échouent si la politique est mal écrite, si un administrateur la modifie sans contrôle, ou si une sauvegarde restaure les fichiers sans restaurer leurs étiquettes de sécurité.

À lire aussi

• Sécurité par capacités contre ACLLa sécurité par capacités délègue des droits portables et restreints, en alternative au contrôle d'accès fondé sur des listes ACL.

Pages voisines

La citent

• Méthodes formelles TLA+ et Coq (Rocq), où elles valent leur coût
• Sécurité par capacités contre ACL

Modèles Bell-LaPadula, Biba et Clark-Wilson

Elle cite

• ⇄Lien dans les deux sens :Non-interférence et contrôle de flux d'information en pratique
• ⇄Lien dans les deux sens :DAC, MAC, RBAC, ABAC ou ReBAC : quel modèle choisir
• Mettre en œuvre les revues d’accès IGA et la SoD

⇄ : les deux pages se citent l’une l’autre.