Le NIST SP 800-207 est le document de référence sur l'architecture Zero Trust. Il ne prescrit aucun produit et ne fournit aucune liste de contrôle : il décrit des composants logiques, des variantes de déploiement et — point souvent négligé — les menaces propres à ce type d'architecture. Cette lecture retient ce qui sert directement à cadrer un programme.
Les trois composants logiques à retenir
Le document sépare la décision de son application. Cette séparation structure tout le reste.
- Le moteur de politiques (Policy Engine) prend la décision : accorder, refuser ou révoquer l'accès à une ressource pour un sujet donné. Il s'appuie sur la politique de l'organisation et sur des sources externes de renseignement.
- L'administrateur de politiques (Policy Administrator) exécute la décision : il établit ou interrompt le chemin de communication, et délivre les jetons ou identifiants de session.
- Le point d'application (Policy Enforcement Point) est le composant en ligne qui laisse effectivement passer ou coupe le flux, au plus près de la ressource.
Les deux premiers forment le point de décision ; le troisième est le point d'application. Cette distinction a une conséquence directe : le point de décision devient l'organe le plus sensible de l'architecture, puisqu'il commande tous les accès.
Autour de ces composants, le document énumère des sources d'information : système d'identité, gestion des terminaux, journaux d'activité, renseignement sur les menaces, exigences de conformité, infrastructure de clés publiques. La qualité de la décision dépend entièrement de la qualité de ces entrées.
L'algorithme de confiance : le cœur de la décision
C'est la partie la plus utile du document, et la moins reprise. Le NIST distingue plusieurs façons d'évaluer une demande d'accès.
| Approche | Fonctionnement | Avantage | Inconvénient |
|---|---|---|---|
| Fondée sur des critères | un ensemble d'exigences doit être satisfait pour accorder l'accès | décision explicable, reproductible, auditable | rigidité, mauvaise gestion des cas limites |
| Fondée sur un score | des attributs pondérés produisent une valeur comparée à un seuil | souplesse, prise en compte du contexte | décision difficile à expliquer, seuil délicat à régler |
| Singulière | chaque demande est évaluée isolément | simplicité de mise en œuvre | ignore les enchaînements suspects |
| Contextuelle | l'historique récent du sujet est pris en compte | détecte les séquences anormales | exige de conserver et corréler un état |
Le choix n'est pas anodin. Une approche par score offre de la finesse mais rend l'explication d'un refus difficile — problème réel lorsqu'un utilisateur légitime est bloqué, et lorsqu'un auditeur demande la justification d'une décision. Une approche contextuelle détecte des enchaînements qu'une évaluation isolée manque, au prix d'une gestion d'état. Ces arbitrages sont développés dans l'article consacré à l'authentification adaptative.
Les variantes de déploiement
Le document présente plusieurs manières d'appliquer la politique. Elles se combinent en pratique.
- Agent sur le terminal et passerelle devant la ressource. Le couple agent/passerelle établit un canal autorisé. Convient bien à un parc géré, moins aux terminaux non maîtrisés.
- Passerelle protégeant une enclave. Un groupe de ressources est placé derrière un point d'application unique. Utile pour les applications anciennes qui ne peuvent pas être modifiées, au prix d'une granularité plus grossière.
- Portail de ressources. Le point d'application est un portail auquel le sujet se connecte. Aucun composant à installer sur le terminal, mais visibilité réduite sur son état réel.
- Cloisonnement applicatif sur le terminal. Les applications autorisées s'exécutent dans un compartiment isolé. Bonne protection contre un poste partiellement compromis, mais dépendance à la compatibilité applicative.
Le critère de choix le plus discriminant est le degré de maîtrise du terminal. Un parc entièrement géré ouvre des options qu'un contexte de prestataires ou d'apport de matériel personnel n'autorise pas.
Les menaces que le document identifie lui-même
C'est la section la plus instructive pour un RSSI, car elle décrit les risques créés par l'architecture.
- Subversion du processus de décision. Le moteur et l'administrateur de politiques deviennent des cibles de très grande valeur. Leur configuration doit être surveillée et leurs modifications tracées comme des événements de sécurité majeurs.
- Déni de service ou interruption réseau. Si le point de décision est inaccessible, plus aucun accès n'est possible. La disponibilité devient un enjeu de sécurité à part entière.
- Identifiants volés et menace interne. Le document est explicite : une architecture Zero Trust complique le déplacement latéral, elle n'empêche pas un attaquant disposant d'identifiants valides d'accéder aux ressources autorisées à cette identité.
- Visibilité insuffisante sur le réseau. Le trafic chiffré et les flux non instrumentés limitent l'analyse.
- Stockage d'informations système et réseau. Les journaux et bases de configuration deviennent eux-mêmes des cibles, car ils cartographient l'organisation.
- Dépendance à des formats propriétaires. L'absence d'interopérabilité crée un risque d'enfermement, à considérer dès le choix des composants.
- Entités non humaines. Comptes de service, automates et agents logiciels sont des sujets à part entière, avec des modes d'authentification souvent plus faibles que ceux des personnes.
Ce que cela implique concrètement
Trois conclusions opérationnelles se dégagent.
La preuve d'identité est le prérequis, pas une brique parmi d'autres. Le document reconnaît lui-même que des identifiants valides suffisent à obtenir un accès. Tant que ces identifiants sont un secret rejouable ou une approbation obtenue par ingénierie sociale, la sophistication du moteur de politiques ne change pas l'issue. C'est précisément ce que vise le facteur cognitif : fournir au point de décision une preuve d'intention humaine plutôt qu'une valeur transmissible.
Le point de décision doit être traité comme un actif critique. Sauvegarde, supervision, séparation des rôles d'administration, revue des modifications de politique.
La granularité se conquiert progressivement. Commencer par une enclave sur un périmètre à forte valeur produit des résultats exploitables ; viser d'emblée une politique par ressource sur l'ensemble du système d'information conduit généralement à l'enlisement.
FAQ
Le NIST SP 800-207 est-il un référentiel d'audit ?
Non. C'est un document d'architecture décrivant des concepts, des composants et des variantes de déploiement. Il ne contient ni exigences numérotées ni critères de conformité opposables.
Faut-il un produit spécifique pour appliquer ces principes ?
Non. Le document est délibérément neutre. La plupart des organisations combinent des briques existantes — gestion des identités, gestion des terminaux, passerelles applicatives, journalisation — plutôt que d'acquérir une solution unique.
Décision par critères ou par score, que choisir ?
Les critères pour les décisions à forte portée juridique ou financière, où l'explicabilité prime. Le score pour moduler l'exigence sur les accès courants. Beaucoup d'architectures combinent les deux selon la ressource visée.
Comment traiter les comptes de service ?
Comme des sujets à part entière : inventaire, propriétaire identifié, portée d'accès minimale, rotation des secrets, et surveillance des usages hors du profil attendu. C'est souvent le point le plus faible d'une architecture par ailleurs solide.
Aller plus loin : prouver l'intention humaine derrière une requête · Zero Trust : principes et limites · PAM et accès à privilèges · authentification continue