Résumé

  • Dans SNMPv3, contextEngineID et contextName situent un ensemble d’informations de gestion ; securityName représente un principal, puis VACM détermine séparément les objets que ce principal peut lire, écrire ou inclure dans une notification.
  • Une trace défendable relie l’identité protocolaire, le contexte, la vue d’accès et la réponse à une autorité de changement extérieure au protocole, puis à la preuve que l’état opérationnel attendu a bien suivi.

Une même interface peut être visible dans plusieurs contextes. Un même identifiant d’objet peut exister sur des équipements distincts. Un proxy peut répondre à une requête alors que l’information se trouve ailleurs. L’étiquette « cible SNMP » gomme ces différences et transforme facilement une réponse valide en attribution au mauvais actif — ou une requête authentifiée en approbation humaine imaginaire.

RFC 3411, publié sur le Standards Track en décembre 2002 dans STD 62, porte les noms de David Harrington, Randy Presuhn et Bert Wijnen. Cette attribution collective compte. Leur architecture ne multiplie pas les identifiants par goût du formalisme : moteur, principal, contexte, traitement de sécurité et contrôle d’accès sont séparés parce qu’ils établissent des faits différents.

Le moteur n’est pas le principal

Un moteur SNMP envoie et reçoit les messages, traite la version du protocole, applique les services de sécurité et appelle le contrôle d’accès. Dans un domaine administratif, snmpEngineID identifie sans ambiguïté ce moteur et l’entité SNMP qui le contient. La limite du domaine est essentielle : deux domaines différents peuvent employer la même valeur. Ce champ n’est donc ni un registre mondial des équipements ni un certificat de propriété.

Le principal est l’entité pour le compte de laquelle un service est fourni. RFC 3411 le représente par securityName, chaîne lisible indépendante du modèle de sécurité. Chaque modèle convertit son identifiant propre — par exemple un nom d’utilisateur — vers cette forme commune. Lisible par un humain ne signifie pas qu’elle désigne un humain : compte de service, rôle ou identité partagée peuvent occuper le champ.

Trois questions restent alors distinctes. Quel moteur protocolaire participe ? Quel principal le modèle de sécurité présente-t-il ? Quelle personne ou organisation a réellement décidé l’action ? Les deux premiers identifiants ne fournissent pas à eux seuls le ticket de changement, le mandat hiérarchique ni l’intention d’une personne au moment de la requête.

Le contexte désigne l’information gérée

Un contexte SNMP est une collection d’informations de gestion accessible par une entité SNMP. Il peut couvrir plusieurs équipements, une partie d’un équipement ou des parties de plusieurs équipements, mais il reste défini comme un sous-ensemble d’une seule entité SNMP. Pour désigner un élément précis, quatre coordonnées sont nécessaires : contextEngineID, contextName, le type d’objet et son instance.

Le couple contextEngineIDcontextName identifie sans ambiguïté un contexte dans le domaine administratif. RFC 3411 admet néanmoins que plusieurs couples différents puissent désigner le même contexte. Ces alias montrent la nature du champ : un repère dans un espace d’informations de gestion, non le numéro universel d’un actif et encore moins l’identité de son opérateur.

Le scopedPDU matérialise la distinction en regroupant l’identifiant de moteur de contexte, le nom du contexte et le PDU. Ces éléments répondent à « où se trouve l’information ? ». Les paramètres de sécurité répondent à « pour le compte de quel principal ? ». Confondre le contexte avec l’opérateur revient à fusionner où et qui avant même la décision d’accès.

La sécurité du message précède l’autorisation de la vue

RFC 3414 définit le User-based Security Model de SNMPv3. Il traite l’authentification du message, la confidentialité et l’actualité qui apporte une protection limitée contre le rejeu. Une signature valable, un message confidentiel et une fenêtre temporelle acceptable sont des reçus utiles, mais bornés.

Ce traitement ne choisit pas la vue de gestion. Il fournit au reste de l’architecture un modèle de sécurité, une représentation du principal et un niveau de sécurité atteint. La réussite cryptographique ne dit pas encore si ce principal peut exécuter cette opération sur cet objet, dans ce contexte.

RFC 3415 confie cette question au View-based Access Control Model. VACM associe le couple securityModelsecurityName à un groupe. Son module d’accès suppose explicitement que le nom de sécurité a déjà été authentifié selon le besoin et n’ajoute pas sa propre authentification. Il reçoit donc une preuve préalable sans la prendre pour sa décision finale.

Les droits varient ensuite selon le niveau de sécurité, le contexte et le type de vue. Les vues de lecture, d’écriture et de notification sont distinctes. Lire un compteur d’interface n’autorise pas à modifier son état. Écrire dans une branche ne donne pas accès à toutes les notifications. L’identifiant de l’objet reste un paramètre de la décision.

Le service isAccessAllowed rend l’enchaînement vérifiable. Il reçoit notamment securityModel, securityName, securityLevel, viewType, contextName et variableName. Ses résultats distinguent un accès accordé d’un objet hors vue (notInView) ou d’un contexte absent (noSuchContext). Un journal réduit à « authentifié » efface la raison exacte du refus.

Le proxy ajoute un trajet d’attribution

RFC 3413 décrit plusieurs applications SNMP, dont le Proxy Forwarder optionnel. Celui-ci peut transférer requête ou notification pour un couple contextEngineIDcontextName vers une autre entité SNMP. Le moteur qui termine le transport n’est donc pas nécessairement celui auprès duquel réside l’information.

Cette indirection demande une trace supplémentaire : pair de transport entrant, principal traduit, contexte reçu, règle de proxy retenue, destination et contexte sortants, corrélation de réponse et erreurs sur chaque segment. La réponse vue par le demandeur ne prouve pas qu’une personne non nommée a directement manipulé l’équipement situé derrière le proxy.

Elle révèle aussi les rôles que le seul contexte ne peut réunir. L’opérateur du proxy, le propriétaire de l’actif, l’équipe habilitée à le changer et l’individu à l’origine de la requête peuvent être quatre parties différentes. Le protocole transporte une portée ; il ne fabrique pas leur identité commune.

Découvrir un EngineID ne découvre pas un propriétaire

RFC 5343 ajoute un mécanisme de découverte de l’identifiant de moteur de contexte. Une valeur locale bien connue et une procédure dédiée permettent à l’application d’apprendre l’identifiant approprié lorsqu’elle ne le connaît pas encore.

Le résultat résout un problème d’adressage protocolaire. Il ne certifie ni que le moteur correspond à l’actif imaginé par l’utilisateur, ni que cet actif appartient à une organisation donnée, ni que le principal peut employer le contexte découvert. La découverte et l’autorisation gardent chacune leur reçu.

Une variation d’EngineID mérite donc une réconciliation : remplacement, restauration, reconfiguration, autre chemin ou anomalie restent possibles. Ce n’est pas en soi une preuve de compromission. À l’inverse, une valeur stable ne prouve pas que logiciel, propriétaire, politique et personnes autorisées n’ont pas changé.

La réponse réussie précède encore l’effet réel

Lors d’une lecture, la réponse établit la valeur renvoyée par un agent pour un objet et un contexte à un instant. Sans autre observation, elle n’établit pas la fraîcheur du capteur ni sa conformité à la réalité physique. Lors d’une écriture, elle peut établir l’acceptation protocolaire sans prouver l’actionnement, la persistance après redémarrage, la convergence d’un système dépendant ou l’absence d’un retour arrière ultérieur.

Le reçu complet traverse ainsi deux plans. Le plan SNMP conserve endpoint, modèle de message, modèle de sécurité, identifiant d’origine, securityName, niveau atteint, couple de contexte, objet, instance, type de vue, groupe et vue VACM, proxy et réponse. Le plan de gouvernance conserve approbateur, fenêtre autorisée, résultat attendu, condition de retour arrière et observation postérieure de l’état.

La contribution architecturale de David Harrington n’affirme pas que tout déploiement possède déjà cette chaîne. Elle fournit les mots qui empêchent un champ d’usurper la fonction d’un autre. Le contexte situe l’information, le nom de sécurité représente le principal et la vue décide l’accès protocolaire. L’autorité humaine et la conséquence opérationnelle exigent encore leurs propres preuves.

Sources