Un badge ne devrait pas être un passe-partout

Au centre commercial « Les Arcades », chaque membre du personnel porte un badge. Le caissier de la parfumerie, l'agent d'entretien, le responsable de la bijouterie : tout le monde franchit la même entrée du personnel le matin. Une fois passé le portique, le réflexe naturel serait de penser que ces gens sont « à l'intérieur », donc de confiance.

C'est exactement le piège.

Le badge du caissier ouvre la porte du personnel. Il ne devrait pas ouvrir la réserve de la bijouterie, ni le local technique où passent les câbles de vidéosurveillance, ni le bureau du gestionnaire où dort le fichier clients. Pourtant, dans beaucoup d'organisations, c'est presque ce qui se passe : on vérifie une fois à l'entrée, et ensuite on laisse circuler.

L'idée centrale du Zero Trust tient en une phrase : être à l'intérieur n'est pas une preuve d'innocence. Chaque accès à une zone sensible se rejustifie, même pour un employé déjà badgé.

Ce billet déroule trois notions qui se renforcent et se confondent souvent dans le discours marketing. Le Zero Trust (ne faire confiance à personne par défaut, vérifier explicitement à chaque accès), le moindre privilège (n'accorder que le strict nécessaire, et seulement quand il le faut) et la réduction de la surface d'attaque (cartographier puis fermer ou cloisonner tout ce qui n'a pas à être exposé). On part du modèle qui dominait avant, le « château fort », pour comprendre pourquoi il craque, puis on voit comment ces trois principes prolongent la défense en profondeur vue dans le premier billet de la série.

Le château fort : un mur, et la confiance derrière

Pendant des années, la sécurité des systèmes d'information s'est pensée comme un château fort. Un gros mur (le pare-feu périmétrique), un pont-levis (le VPN d'accès), et derrière, un réseau interne où tout le monde se parle librement.

Le raisonnement était simple. Si tu es dans le réseau de l'entreprise, c'est que tu as passé le contrôle à l'entrée, donc on te fait confiance. Aux Arcades, cela revient à dire : tu as franchi le portique du personnel, tu peux donc te promener partout dans les coulisses.

Ce modèle a deux défauts qui le condamnent.

D'abord, le périmètre s'est dissous. Le télétravail, le cloud, les applications SaaS et les terminaux mobiles font que la donnée et les utilisateurs ne sont plus « dedans » ou « dehors ». Le mur entoure de moins en moins de choses utiles.

Ensuite, et c'est le plus grave, un attaquant qui franchit le mur une fois se retrouve en terrain conquis. Il passe d'une machine à l'autre sans rencontrer de nouveau contrôle. On appelle ça le déplacement latéral. Le braqueur qui s'est fait passer pour un livreur n'a eu à tromper qu'un seul vigile, à l'entrée. Ensuite, plus personne ne lui demande rien.

Le château fort confond périmètre et confiance. Il protège bien la frontière et très mal l'intérieur. Une seule intrusion suffit alors pour tout compromettre.

La réponse n'est pas de construire un mur plus haut. C'est de cesser de distribuer la confiance gratuitement une fois la frontière passée.

Zero Trust : vérifier explicitement, à chaque fois

Le Zero Trust renverse l'hypothèse de départ. Au lieu de « tout ce qui est à l'intérieur est de confiance », il pose « rien n'est de confiance par défaut, où que ce soit ». On ne supprime pas le mur, on arrête juste de croire qu'il suffit.

Le terme a été popularisé par Forrester, puis formalisé par le NIST dans la publication NIST SP 800-207, Zero Trust Architecture. Ce document est la référence à lire. Il décrit le Zero Trust non comme un produit à acheter, mais comme un ensemble de principes d'architecture.

Les principes de fond

Le NIST SP 800-207 énonce plusieurs idées directrices. Trois suffisent pour saisir l'esprit.

  • Vérifier explicitement. Chaque demande d'accès est authentifiée et autorisée à partir de plusieurs signaux : qui demande, depuis quel appareil, dans quel état, pour quelle ressource. Pas de laissez-passer hérité de la connexion précédente.
  • Raisonner par ressource, pas par réseau. L'unité protégée n'est plus « le réseau interne » mais chaque ressource individuelle (une application, une base, un service). La position réseau ne donne aucun droit en soi.
  • Accès par session, au plus juste. Un accès accordé l'est pour cette session, pour cette ressource, et rien de plus. La décision peut être réévaluée en continu.

Aux Arcades, cela se traduit ainsi : devant la réserve de la bijouterie, un lecteur de badge revérifie l'identité de l'employé, contrôle qu'il fait bien partie de l'équipe bijouterie, et n'ouvre que cette porte. Le même badge présenté devant le local technique sera refusé. Avoir franchi le portique d'entrée ne compte pour rien ici.

Qui décide, et avec quoi

Le modèle du NIST distingue deux organes. Le Policy Decision Point (PDP, le point de décision) évalue la demande au regard de la politique. Le Policy Enforcement Point (PEP, le point d'application) ouvre ou ferme l'accès en fonction de cette décision. Entre les deux circulent des signaux : identité vérifiée, posture de l'appareil, sensibilité de la ressource, contexte.

Le schéma suivant montre le parcours d'une seule requête.

flowchart TD A["Requête d'accès
utilisateur + appareil"] --> B{"Identité
vérifiée ?"} B -->|Non| R["Accès refusé"] B -->|Oui| C{"Appareil conforme
posture saine ?"} C -->|Non| R C -->|Oui| D{"Politique autorise
cette ressource ?"} D -->|Non| R D -->|Oui| E["Accès accordé
au moindre privilège
pour cette session"] E --> F["Réévaluation continue
du contexte"] F -->|Contexte dégradé| R classDef ok fill:#b5651d,stroke:#8a4d16,color:#f5f2ec classDef deny fill:#a0413e,stroke:#8a4d16,color:#f5f2ec classDef check fill:#ede9e1,stroke:#b5651d,color:#1a1a1a class A,E ok class R deny class B,C,D,F check

Trois portes successives, donc, avant le moindre accès : l'identité, l'état de l'appareil, la politique. Et même après, la décision n'est pas figée pour la journée.

Le tableau ci-dessous résume le glissement de modèle.

Critère Château fort (périmétrique) Zero Trust
Hypothèse de confiance Implicite une fois à l'intérieur Aucune par défaut, partout
Unité protégée Le réseau interne Chaque ressource, individuellement
Vérification Une fois, à l'entrée À chaque accès, en continu
Effet d'une intrusion Déplacement latéral facile Cloisonné, rejustification à chaque porte
Signaux de décision Adresse IP, position réseau Identité, appareil, posture, contexte
Étendue d'un accès Large et durable Minimal, limité à la session

La dernière ligne fait le pont avec la notion suivante. Vérifier à chaque porte ne sert à rien si, une fois la porte ouverte, on donne les clés de tout le bâtiment.

Le moindre privilège : juste ce qu'il faut, juste quand il faut

Le moindre privilège est le principe selon lequel un utilisateur, un service ou un processus ne reçoit que les droits strictement nécessaires à sa tâche, et rien de plus. Ce n'est pas une idée neuve : elle est documentée dès 1975 dans l'article fondateur de Saltzer et Schroeder, The Protection of Information in Computer Systems, sous le nom de least privilege.

Aux Arcades, le caissier de la parfumerie a besoin d'ouvrir sa caisse et d'accéder au stock de sa boutique. Il n'a aucune raison d'entrer dans la salle des coffres ni de consulter le fichier clients du centre. Lui donner ces accès « au cas où » ne lui rend aucun service et augmente les dégâts possibles le jour où son badge est volé ou copié.

Pourquoi ça réduit l'impact, pas la probabilité

Le moindre privilège n'empêche pas une intrusion. Il en limite le rayon d'explosion. Si un compte avec des droits minimaux est compromis, l'attaquant hérite de ces droits minimaux, pas des clés du royaume. C'est le complément direct du Zero Trust : l'un vérifie à chaque porte, l'autre fait en sorte que chaque porte ouverte donne accès au moins de choses possible.

Du droit permanent au droit éphémère

La version moderne du moindre privilège ajoute la dimension du temps : le juste-à-temps (just-in-time). Plutôt qu'un droit administrateur permanent qui dort dans un compte, on accorde l'élévation pour une fenêtre limitée, le temps d'une opération précise, puis on la retire.

Aux Arcades, c'est la différence entre confier au technicien une clé du local électrique pour toujours, et lui ouvrir la porte pour la durée de son intervention, sur demande tracée. La deuxième option laisse beaucoup moins de portes ouvertes en permanence.

Le moindre privilège ne réduit pas la probabilité d'une compromission. Il réduit sa gravité. C'est exactement le levier « impact » de l'équation du risque vue dans le premier billet de la série.

Concrètement, appliquer le moindre privilège passe par des rôles plutôt que des droits individuels, par la revue régulière des accès (qui a accès à quoi, et est-ce encore justifié ?), et par la chasse aux comptes dormants et aux privilèges accumulés au fil des années, ce qu'on appelle le privilege creep.

Réduire la surface d'attaque : fermer les portes inutiles

La surface d'attaque est l'ensemble des points par lesquels un attaquant peut tenter d'entrer ou d'agir : ports ouverts, services exposés, comptes, interfaces d'administration, dépendances, et même les humains. Plus elle est large, plus il y a de portes à surveiller, et plus il est probable que l'une d'elles soit mal fermée.

La réduire commence par une étape qu'on saute trop souvent : savoir ce qu'on a. Aux Arcades, le plan du centre et la signalétique disent où sont les entrées, les issues, les locaux techniques, les accès livraison. Sans ce plan, impossible de décider quelle porte fermer. En sécurité, c'est la cartographie des actifs et des flux : on ne protège bien que ce qu'on a recensé.

Trois leviers concrets

Une fois la cartographie en main, trois actions réduisent la surface.

  • Supprimer ce qui ne sert pas. Un service activé « par défaut » mais jamais utilisé, un compte de test oublié, une interface d'administration exposée sur Internet : autant de portes à condamner. C'est l'équivalent de murer une issue qui ne mène nulle part mais que n'importe qui pourrait pousser.
  • Cloisonner ce qui reste. La segmentation réseau découpe le système en zones qui ne communiquent que par des passages contrôlés, comme les rideaux de fer et les galeries cloisonnées du centre. Une compromission dans une zone ne se propage pas aux autres. C'est la traduction réseau de la défense en profondeur.
  • N'exposer que le nécessaire. Ce qui doit être joignable de l'extérieur est réduit au minimum et placé derrière des contrôles. Le reste reste interne.

Le lien avec les deux autres principes

Ces trois notions ne sont pas étanches, elles se chevauchent. Le moindre privilège réduit la surface d'attaque côté droits : moins de comptes peuvent faire moins de choses. Le Zero Trust réduit la surface exploitable côté réseau : il n'y a plus de zone « de confiance » béante où se déplacer librement. Et la cartographie alimente les deux : on ne peut accorder le juste privilège ni vérifier le bon accès que sur ce qu'on a d'abord recensé.

Réduire la surface d'attaque, c'est d'abord faire l'inventaire, ensuite condamner les portes inutiles, enfin cloisonner celles qui restent. On ne sécurise jamais ce qu'on ignore posséder.

Scénario réel : BeyondCorp, quand Google a supprimé son périmètre

L'exemple le plus documenté de bascule vers le Zero Trust est l'initiative BeyondCorp de Google. Son point de départ est une attaque réelle : l'opération Aurora, une campagne d'intrusion visant Google et d'autres entreprises, rendue publique par Google début 2010.

En réponse, Google a fait un choix radical, décrit dans une série d'articles publiés à partir de 2014. Le premier, BeyondCorp: A New Approach to Enterprise Security (Rory Ward et Betsy Beyer, revue ;login: de l'USENIX), pose le principe directeur : déplacer le contrôle d'accès du périmètre réseau vers les utilisateurs et les appareils individuels.

L'idée centrale de BeyondCorp est qu'aucun réseau n'est de confiance, pas même le réseau interne de l'entreprise. Concrètement, être connecté au réseau d'entreprise ne donne plus aucun privilège. L'accès à une application dépend de deux choses : l'identité de l'utilisateur (authentifiée) et l'état de l'appareil qui se connecte (un terminal connu, géré, dans une posture acceptable). La décision se prend à chaque requête, sur la base de ces signaux, par un moteur de politique central.

C'est, presque mot pour mot, l'architecture que le NIST formalisera plus tard dans le SP 800-207 : un point de décision, des signaux d'identité et d'appareil, un accès par ressource, plus de confiance accordée à la position réseau. Google a documenté la suite dans d'autres articles de la série, dont BeyondCorp: Design to Deployment at Google, qui détaillent le déploiement à l'échelle de l'entreprise.

Aux Arcades, la transposition est limpide : Google a cessé de considérer que « franchir le portique du personnel » valait autorisation. Désormais, chaque porte revérifie le badge et l'état de celui qui le présente, et l'entrée principale ne donne plus, à elle seule, aucun droit.

La leçon de BeyondCorp n'est pas qu'il faut un produit Zero Trust. C'est qu'on peut retirer la confiance accordée au réseau et la rebâtir sur l'identité et l'appareil, vérifiées à chaque accès.

Comment les trois principes se renforcent

Pris isolément, chacun de ces principes a une limite. Pris ensemble, ils se couvrent mutuellement.

Le Zero Trust sans moindre privilège vérifie soigneusement qui entre, puis donne accès à tout : la vérification ne sert à rien si la porte ouvre sur le bâtiment entier. Le moindre privilège sans Zero Trust restreint bien les droits, mais une fois la frontière franchie, plus personne ne revérifie : un compte volé reste un compte volé. Et les deux ensemble, sans réduction de la surface d'attaque, s'épuisent à garder des centaines de portes dont beaucoup n'avaient aucune raison d'exister.

L'ordre logique de mise en œuvre suit d'ailleurs ce raisonnement : cartographier d'abord (que protège-t-on, par où passe-t-on ?), réduire la surface ensuite (fermer et cloisonner), puis appliquer le moindre privilège (n'accorder que le nécessaire) et le Zero Trust (vérifier chaque accès restant). C'est une déclinaison directe de la défense en profondeur du premier billet : plusieurs couches qui se rattrapent, plutôt qu'un mur unique sur lequel tout repose.

Cette logique prolonge naturellement une démarche DevSecOps, où la sécurité est intégrée à chaque étape plutôt que posée en barrière finale. Vérifier les accès, limiter les droits et fermer les portes inutiles sont des pratiques qui se conçoivent dès la construction des systèmes, pas après.

Points clés

  • Le modèle « château fort » confond périmètre et confiance : il protège mal l'intérieur et facilite le déplacement latéral après une seule intrusion.
  • Le Zero Trust ne fait confiance à personne par défaut et vérifie explicitement chaque accès à partir de l'identité, de l'appareil et du contexte, formalisé par le NIST SP 800-207.
  • Le moindre privilège n'accorde que le strict nécessaire, idéalement juste-à-temps : il ne réduit pas la probabilité d'une compromission mais sa gravité.
  • La réduction de la surface d'attaque commence par la cartographie, puis ferme ce qui est inutile et cloisonne le reste.
  • Les trois se renforcent et prolongent la défense en profondeur : on cartographie, on réduit, on restreint, on vérifie.

Dans la série

Palier 1 : Connaître les lieux. Domaine : Fondations.

Pour aller plus loin