Pendant longtemps, le réseau du bureau a servi de raccourci. À l’intérieur, on accordait plus facilement la confiance. À l’extérieur, on ajoutait des contrôles. Avec les gens à la maison, les applications dans le cloud et les appareils qui circulent, cette séparation explique de moins en moins bien le risque.

Le NIST a publié en août la version finale de SP 800-207 sur l’architecture zero trust. Le principe n’est pas de considérer chaque collègue comme un attaquant. Il dit plutôt qu’aucune position réseau ne devrait donner une confiance générale et durable. Chaque demande vise une ressource précise; elle doit être autorisée avec des signaux actuels.

L’architecture distingue utilement le plan de décision du plan de circulation. Un moteur de politique évalue la demande. Un administrateur de politique établit ou retire la session selon cette décision. Un point d’application, placé devant la ressource, laisse passer le flux autorisé. Les données de l’application circulent ensuite par ce point; elles ne traversent pas nécessairement le moteur de décision lui-même.

Le moteur combine plusieurs sources : identité et groupes, état géré ou non de l’appareil, correctifs, niveau de risque de la connexion, sensibilité de la ressource et renseignements sur les menaces. L’authentification multifacteur réduit l’utilité d’un mot de passe volé, mais elle ne nettoie pas un portable infecté. Le chiffrement protège le transport, mais n’empêche pas un compte autorisé de télécharger trop de données. Chaque contrôle couvre une partie différente du chemin.

Le trajet d’une demande distante

Une personne qui veut ouvrir un rapport financier depuis la maison pourrait suivre cette séquence :

1. le navigateur authentifie la personne auprès du fournisseur d’identité avec un second facteur;
2. le service de gestion d’appareils fournit un état signé : appareil connu, disque chiffré, système à jour et protection active;
3. le moteur de politique compare ces signaux à la règle du rapport, qui exige un appareil conforme et un rôle financier;
4. le point d’application crée une session courte vers cette seule application, avec les droits minimaux;
5. les téléchargements inhabituels et les changements de risque alimentent la télémétrie; la session peut être réévaluée ou coupée.

Cette approche réduit le mouvement latéral. Accéder au rapport ne donne pas automatiquement une route vers toute la base, le serveur de fichiers et les outils d’administration. Les identités de services doivent suivre la même logique : un traitement nocturne reçoit un secret ou un certificat limité à son API et à sa durée, plutôt qu’un compte partagé administrateur.

Les pannes demandent de la nuance. Si le fournisseur d’identité devient indisponible, bloquer toutes les opérations peut être plus dommageable que le risque évité. Un accès d’urgence hors du chemin normal, très limité, surveillé et testé peut servir de reprise. Si le système de conformité de l’appareil tarde à répondre, la politique doit savoir s’il faut refuser, autoriser seulement une ressource peu sensible ou accepter un signal récent en cache. Ces décisions doivent être explicites; sinon, l’équipe les improvisera pendant l’incident.

Il faut aussi garder la sécurité utilisable. Demander un nouveau facteur à chaque clic pousse au contournement. Une session courte, liée à l’appareil et réévaluée quand le contexte change, concentre la friction sur les opérations risquées. À l’inverse, une règle trop large comme « tous les employés avec MFA » recrée simplement le vieux réseau interne sous une autre forme.

La mise en œuvre peut commencer sans grand soir : inventorier une application sensible, placer un point de contrôle devant elle, définir les signaux réellement disponibles, observer les décisions en mode rapport, puis activer progressivement les refus. Il faut mesurer les accès bloqués, les faux refus, les comptes trop privilégiés et les chemins qui contournent encore la politique.

L’identité prend beaucoup de place, mais elle ne remplace pas tout le périmètre. En 2020, le télétravail montre surtout qu’il faut construire un petit périmètre vérifiable autour de chaque ressource et de chaque session, puis être capable de le retirer dès que le contexte n’est plus acceptable.