Le terme zero trust apparaît maintenant sur tellement de fiches de produits qu’on pourrait croire qu’il vient avec une licence annuelle et un bouton pour tout activer.

Ça ne fonctionne évidemment pas comme ça.

L’idée existe depuis des années et reste bonne : le fait d’être sur le « bon » réseau ne devrait pas donner une confiance générale. Chaque demande vise une ressource et doit être évaluée selon l’identité, l’appareil, le contexte et les droits réellement nécessaires.

Une demande, une décision de politique

Prenons une personne qui ouvre l’application financière. L’accès peut suivre cette chaîne :

1. le fournisseur d’identité vérifie le mot de passe et le second facteur;
2. il émet un jeton signé avec l’utilisateur, le groupe, l’heure et l’audience;
3. la passerelle vérifie la signature, l’expiration et que le jeton vise bien cette application;
4. un service de posture confirme que l’appareil est géré, chiffré et à jour;
5. le moteur de politique compare le contexte à une règle;
6. le point d’application autorise seulement l’action demandée et journalise la décision.

La décision peut être exprimée ainsi :

autoriser lecture_factures si
  identité.authentifiée == vrai
  ET identité.rôle contient "comptabilité"
  ET appareil.géré == vrai
  ET appareil.chiffrement == actif
  ET risque_session < seuil

exiger MFA à nouveau si
  action == "modifier_compte_bancaire"

La passerelle est un policy enforcement point : elle bloque ou laisse passer. Le moteur de politique prend la décision avec des signaux provenant de l’identité, de l’appareil et de la ressource. Les règles doivent être versionnées, testées et compréhensibles; une décision impossible à expliquer devient vite un billet de support permanent.

Le jeton ne donne pas tous les droits

Un jeton signé prouve qu’un fournisseur reconnaît une identité et certaines affirmations. Il ne devrait pas être accepté par n’importe quel service. Le champ d’audience limite le destinataire, l’expiration réduit la durée d’un vol de jeton et les portées indiquent les opérations permises.

Pour un service qui appelle une API, j’utiliserais une identité de travail distincte plutôt qu’un compte humain partagé. Son jeton pourrait porter orders.read sans orders.write. La base ou l’API vérifie encore l’autorisation sur la ressource précise; être arrivé depuis un sous-réseau interne ne suffit plus.

La segmentation réduit ensuite le chemin disponible. Le poste d’un utilisateur n’a pas besoin d’ouvrir directement le port de la base. Il atteint la passerelle applicative; seule l’identité du service atteint la base. Si le poste est compromis, l’attaquant ne peut pas simplement balayer tout le réseau et réutiliser la position comme preuve.

Commencer par les chemins qui existent

Le gros de la job est l’inventaire. Je prendrais une application importante et tracerais :

utilisateurs/groupes → méthode d’authentification → application/API
                    → comptes de service → bases/files/partages
                    → journaux → propriétaire de chaque droit

Chaque droit doit avoir une raison, une date de revue et un moyen de retrait. Un rôle « AdminTemp » créé pour un incident ne devrait pas vivre trois ans. L’accès juste-à-temps peut l’accorder pour une durée courte après approbation, puis le retirer automatiquement.

Les vieilles applications compliquent le changement. Certaines ne comprennent que l’authentification intégrée au réseau ou un mot de passe fixe. Une passerelle peut les protéger temporairement, mais le compte partagé derrière reste un risque. Le plan doit distinguer la compensation à court terme de la vraie modernisation.

Prévoir la panne de l’identité

Centraliser la décision rend le fournisseur d’identité critique. S’il tombe, refuser toute demande protège les données mais peut arrêter les opérations. Autoriser tout le monde transforme la panne en brèche. Je définirais des comptes de secours très limités, conservés hors du chemin normal, protégés fortement et testés avec une alerte immédiate sur leur usage.

Les autres cas à tester sont concrets :

• appareil conforme qui devient non conforme pendant une session;
• jeton volé puis révoqué avant son expiration;
• horloge décalée qui fait refuser des jetons valides;
• règle trop stricte qui bloque toute une équipe;
• journal indisponible au moment d’une décision sensible;
• compte de service sans propriétaire dont le secret expire.

Vérifier chaque demande ne veut pas dire interrompre chaque clic. Une session récente sur un appareil sain peut lire une ressource ordinaire sans nouveau défi. Une action sensible ou un signal inhabituel demande une preuve supplémentaire. Si le chemin normal devient trop pénible, les gens cherchent un raccourci; la politique doit donc mesurer sécurité et utilisabilité.

Je vois le zero trust comme une direction d’architecture appliquée ressource par ressource. Je commencerais par une application, ses identités, ses appels de service et ses droits réels. Quand chaque accès passe par une politique testable et qu’un compte compromis ne peut atteindre que le strict nécessaire, on a retiré un morceau de confiance implicite. Aucun autocollant sur une boîte ne fait ce travail à notre place.