Résumé

  • RFC 5209 définit l’évaluation comme la collecte de posture pour un ensemble de capacités, suivie d’une comparaison avec une politique de conformité. Le verdict dépend donc de son périmètre, de sa règle et de son heure.
  • La réévaluation est une fonction centrale : un terminal jugé conforme peut changer, tout comme la politique qui le gouverne. L’exemple du pare-feu désactivé figure dans le RFC lui-même.
  • Le résultat, la décision d’autorisation et son application sur le réseau appartiennent à trois plans distincts. Un « conforme » global ne prouve ni l’installation d’une règle ni l’état présent du terminal.

Le passé simple d’un écran au présent

À 9 h, un ordinateur administré participe à une évaluation de posture. Le collecteur du pare-feu constate que la protection fonctionne ; celui des mises à jour relève le niveau attendu. Deux validateurs appliquent la version 42 de la politique. Le courtier serveur agrège leurs réponses et produit une décision globale conforme. Un système voisin autorise l’accès normal.

À 9 h 17, l’utilisateur coupe le pare-feu pour un essai. Le collecteur détecte le changement et le signale, mais le courtier client redémarre ; l’événement se perd. À 9 h 25, l’écran d’assurance demeure vert. Le dossier de 9 h est intact, la session s’est bien terminée, et le verdict initial était raisonnable.

Pourtant, l’écran ne décrit plus le terminal. Il a retiré la date d’une phrase exacte — « jugé conforme à 9 h selon ces observations et la politique 42 » — pour en fabriquer une autre : « conforme maintenant ».

Ce scénario est construit ; il ne décrit aucun produit ni incident réel. Mais son mécanisme vient directement de RFC 5209, qui explique qu’un système précédemment conforme peut cesser de l’être si l’utilisateur désactive une protection exigée. L’ancienne décision n’est pas fausse. Elle est devenue historique.

Ce que le mot évaluation limite

Publié en 2008 avec le statut Informational, RFC 5209 expose le problème NEA, son vocabulaire, un modèle de référence, des usages et des exigences destinées aux protocoles. Il ne décrit ni un produit universel ni un mécanisme unique couvrant toute la chaîne de contrôle.

Une assessment y est la collecte de posture pour « un ensemble » de capacités du terminal, afin que les validateurs appropriés les évaluent selon une politique. L’ensemble peut être incomplet. La posture est une configuration ou un état matériel ou logiciel pertinent pour la politique, non une copie exhaustive de la machine. Et l’évaluation introduit une règle locale, avec sa version et son propriétaire.

Le modèle distingue aussi les sens. Un Posture Attribute rapporte une configuration observée. Un Request Attribute demande une information. Un Result Attribute communique la décision. Un Remediation Attribute propose les étapes de correction. La demande n’atteste pas la réponse ; l’instruction n’atteste pas sa réalisation ; le résultat ne remplace pas l’observation.

Le texte dit qu’un Result Attribute indique normalement, à la fin de l’évaluation, si le terminal a été « considéré » conforme. Ce mot maintient la bonne distance : le verdict résulte d’entrées et d’une politique. Il ne devient pas une propriété métaphysique de l’appareil.

Des composants séparés, donc des autorités séparées

Le client NEA rassemble des Posture Collectors, un Posture Broker Client et des Posture Transport Clients. Le serveur comporte des Posture Validators, un Posture Broker Server et des Posture Transport Servers.

Le collecteur observe une ou plusieurs fonctions, fournit des attributs, reçoit des résultats ou des consignes et peut annoncer un changement qui justifie une nouvelle évaluation. Le courtier client tient le registre des collecteurs, distribue et regroupe les messages. Le transport porte le dialogue sur un canal fiable et protégé.

Le validateur applique la politique aux attributs d’une fonction, demande éventuellement des compléments, produit un résultat et une remédiation. Le courtier serveur dirige les messages vers les validateurs et calcule la décision globale. Le transport serveur maintient le canal.

Aucun de ces rôles ne voit tout. Un canal protégé ne prouve pas la présence de tous les collecteurs exigés. Un courtier peut agréger parfaitement quatre réponses sans observer la cinquième fonction. Un validateur peut appliquer correctement une règle à un attribut devenu ancien une minute plus tard.

La preuve opérationnelle doit donc conserver l’inventaire attendu, les composants inscrits, ceux qui ont répondu, les attributs et leurs heures, le validateur destinataire, la version de politique et le traitement explicite des absences.

L’absence de résultat négatif n’est pas un résultat positif

RFC 5792, qui spécifie PA-TNC, rend cette exigence de couverture concrète. Deux implémentations peuvent connaître des types d’attributs propriétaires différents tout en restant interopérables. Une demande non prise en charge peut provoquer une erreur ; selon les règles, un collecteur peut fournir tout, une partie ou aucun des attributs demandés. Certains champs représentent explicitement une donnée inconnue ou indisponible.

Cette souplesse permet l’évolution. Elle interdit en revanche de traiter le silence comme une inspection réussie. Si la politique exige cinq fonctions et que quatre collecteurs répondent, les quatre réussites ne font pas réussir la cinquième. Celle-ci peut être absente, non prise en charge, cachée par une règle de confidentialité, mal configurée ou inaccessible.

La politique locale reste libre : refuser, isoler, limiter l’accès, accepter pour un temps une assertion antérieure ou autoriser une exception identifiée. Mais accepter une lacune n’est pas observer un état sain. Le registre devrait dire « quatre sur cinq, exception approuvée jusqu’à 10 h », non réduire la situation à conforme=true.

Il faut au moins trois axes : le résultat observé, la couverture de preuve et la disposition politique. Leur compression en un booléen rend le tableau plus propre, mais la prochaine réévaluation plus aveugle.

Réévaluer, c’est redonner un présent au verdict

Après l’évaluation à la connexion, RFC 5209 présente la réévaluation comme un deuxième usage majeur. Les politiques et les terminaux évoluent. Outre la désactivation d’un pare-feu, il cite un correctif nouvellement publié : une version auparavant acceptée devient insuffisante lorsque la politique exige ce correctif.

Le signal peut partir du client. Un collecteur voit un changement et demande au courtier de relancer l’évaluation. Il peut aussi partir du serveur : un validateur apprend hors bande qu’une politique ou une menace a changé. Une implémentation peut encore se servir d’un calendrier, d’un accès à une application sensible ou d’une action administrative.

Dès lors, l’état du chemin de déclenchement fait partie de toute affirmation continue. Le collecteur surveillait-il le bon événement ? Le courtier a-t-il persisté le signal pendant son redémarrage ? La réévaluation a-t-elle été mise en file, lancée puis terminée ? La nouvelle politique a-t-elle atteint tous les validateurs ?

Un système qui conserve les évaluations réussies mais perd les déclencheurs manqués fabrique une mémoire asymétrique. Le vert subsiste ; ce qui devait le rendre caduc disparaît.

Les Assertion Attributes prévues par RFC 5209 ne changent pas cette logique. Une assertion datée et signée peut résumer une évaluation antérieure et être réutilisée pendant une période. C’est une optimisation. Elle doit rester liée au terminal, aux fonctions et politiques couvertes, à un émetteur, à une échéance et aux changements qui imposent une nouvelle mesure.

La cryptographie protège une phrase sans l’allonger

Le modèle prévoit des protections cryptographiques pour les messages et le transport ; la sécurité examine la modification, le rejeu, l’interception et le vol d’attributs. Sans résistance au rejeu, un ancien état conforme pourrait être présenté comme neuf.

Mais un message neuf reste limité à ce que son collecteur observe. L’authentification de l’émetteur ne transforme pas un capteur partiel en capteur exhaustif. L’intégrité d’un paquet ne garantit pas la santé du processus qui a produit la valeur. La cryptographie protège l’origine et le contenu selon un modèle de confiance ; elle ne crée pas les faits absents.

La chaîne utile est donc :

terminal et session liés → collecteurs attendus → attributs observés → courtier les livre → validateurs jugent → décision globale → autorisation → règle appliquée → changements surveillés → réévaluation terminée.

Chaque flèche change de responsable. Quand le reçu s’arrête, la certitude s’arrête aussi.

Le verdict n’actionne pas lui-même la barrière

RFC 5209 affirme que le résultat peut influencer une décision d’accès destinée à des mécanismes d’application. Il place toutefois ces mécanismes et leurs protocoles hors de son champ. La représentation et la transmission du résultat NEA aux technologies d’accès sont elles aussi hors périmètre.

Cette séparation protège la précision. NEA évalue la posture. Un service d’autorisation décide de l’effet sur l’accès. Un point d’application installe et maintient la règle. Le trafic observé montre ensuite son effet.

Un résultat conforme ne garantit donc pas un accès : une autre condition peut refuser. Inversement, un accès actif ne démontre pas que toutes les vérifications ont réussi : il peut être limité, exceptionnel ou fondé sur d’autres signaux. Une consigne de remédiation ne prouve pas que le correctif a été exécuté.

Pour attester l’application, il faut nommer le consommateur du verdict, la correspondance de décision, le terminal et la session, le point d’application, l’identifiant de règle, l’accusé d’installation, l’heure et l’effet observé. Sans ces données, le rapport doit s’arrêter au résultat d’évaluation.

Un reçu capable de parler au présent

Le dossier minimal contient l’identifiant d’évaluation et de session, le lien au terminal, le rattachement réseau, le déclencheur et les heures. Il compare les collecteurs et validateurs attendus, inscrits et répondants, avec leurs versions et empreintes de configuration. Il préserve demandes, attributs, heures d’observation, types non pris en charge, inconnues, omissions et erreurs.

Chaque décision fonctionnelle cite le validateur, la politique, les entrées, la règle et la raison. La décision globale cite sa méthode d’agrégation, ses exceptions et son traitement des inconnues. Une assertion réutilisée garde son périmètre, son émetteur, sa validité et ses conditions d’annulation.

Puis, seulement si les systèmes voisins produisent leurs propres preuves, on ajoute l’autorisation, la règle appliquée, l’exécution de la remédiation et la nouvelle mesure. Enfin viennent le dernier changement de posture, le dernier changement de politique, la dernière réévaluation, les déclencheurs échoués et l’âge actuel des preuves.

Dans le scénario, l’état utile devient : « réussi à 9 h ; pare-feu modifié à 9 h 17 ; déclencheur non livré ; conformité actuelle inconnue ; ancienne règle d’accès encore active ». Cette formulation est moins décorative, mais elle désigne immédiatement le travail à faire.

Dater le succès pour préserver sa valeur

Lire RFC 5209 avec précision n’affaiblit pas NEA. Le modèle organise utilement l’observation, l’échange, la validation, l’agrégation et la remédiation. RFC 5792, RFC 5793, RFC 6876 et RFC 7171 concrétisent différentes couches de cet échange.

La fragilité apparaît quand une couche d’assurance transforme une décision historique en identité permanente du terminal. Dépourvu de date, de couverture et de version de politique, le mot « conforme » prend un pouvoir symbolique : il peut contredire la machine en fonctionnement. L’observation actuelle du pare-feu est alors traitée comme une anomalie, au lieu que l’ancien dossier soit reconnu comme ancien.

Le code en cours d’exécution, l’inventaire actuel, la file de réévaluation, l’époque de politique et l’accusé d’application doivent primer. Le succès de 9 h n’a pas à être effacé ; il doit être daté.

À 9 h 25, la réponse honnête n’est pas nécessairement « non conforme ». C’est « non réévalué depuis un changement pertinent ; état actuel inconnu ». Une organisation capable d’afficher cette inconnue est mieux placée pour retrouver la conformité réelle.

Sources