Résumé

  • Dans RFC 1447, une ligne d’accès était indexée par la partie cible, la partie sujet et le contexte de ressources ; les classes de PDU autorisées formaient une donnée distincte.
  • Connaître ou authentifier l’émetteur ne suffisait pas : l’autorisation était une décision locale prise à la réception d’une communication déterminée.
  • VACM remplaça ensuite l’architecture des parties, tout en conservant l’idée qu’un principal, un contexte, des conditions de sécurité, un type de vue et un objet devaient être évalués ensemble.

Le badge n’était pas la liste des portes

La Party MIB faisait partie du premier ensemble SNMPv2 publié en avril 1993. Le mot « partie » désignait un environnement d’exécution conceptuel, limité à un sous-ensemble d’opérations défini par l’administration. Une même entité SNMPv2 pouvait réaliser plusieurs parties, avec des périmètres qui se recoupaient ou non. Elle pouvait également connaître une partie distante sans l’exécuter localement.

L’identité servait donc à sélectionner une fiche administrative. Elle ne constituait pas une qualité générale appelée « administrateur » que tout équipement aurait dû reconnaître de la même manière.

RFC 1447 rendait cette prudence observable dans aclTable. L’index d’une ligne associait aclTarget, aclSubject et aclResources. La cible était la partie sollicitée pour réaliser l’opération ; le sujet, celle qui la demandait ; les ressources, le contexte SNMPv2 auquel portait la demande.

Ce n’est qu’après la sélection de ce triplet que aclPrivileges précisait les verbes permis. Une autorisation n’était pas un attribut accroché au sujet. C’était une relation orientée, située et limitée à certaines communications.

Un entier compactait des verbes, pas une hiérarchie

Les privilèges étaient codés par addition. Get valait 1, GetNext 2, Response 4, Set 8, GetBulk 32, Inform 64 et SNMPv2-Trap 128. Zéro désignait l’ensemble vide. La valeur par défaut, 35, réunissait Get, GetNext et GetBulk.

Trente-cinq n’était ni un grade moyen ni un score de confiance. Quarante-trois ajoutait Set au même ensemble de lecture ; quatre autorisait seulement Response. Pour comprendre la politique, il fallait décomposer le nombre et conserver le triplet auquel il appartenait.

Les exemples d’initialisation montraient aussi que le sens de circulation comptait. Une ligne pouvait autoriser un sujet côté gestion à adresser des requêtes de lecture à une cible côté agent. La ligne inverse permettait Response ou Trap. Le droit d’interroger ne créait pas automatiquement le droit de répondre, et aucun des deux ne créait le droit d’écrire.

Une interface qui résume 35 par « lecture » rend peut-être service. Une interface qui le résume par « fiable » fabrique une conclusion. Le mot ne dit plus vers quelle cible, dans quel contexte et pour quel type de message la décision valait.

L’envoi précédait la décision étrangère

RFC 1445 plaçait l’application du contrôle d’accès à la réception, non à l’émission. L’expéditeur construisait un message avec partie source, partie destination, contexte et PDU. Le fait de l’envoyer correctement ne consultait pas la base de politique de l’entité distante.

À l’arrivée, plusieurs épreuves restaient distinctes. La destination devait être connue et réalisée localement. La source devait figurer dans la base. L’authentification devait être évaluée selon les protocoles associés. Le contexte devait exister. Enfin, la base locale d’accès devait contenir la relation source–destination–contexte et inclure la classe du PDU reçu.

Une communication bien encodée pouvait ainsi nommer une cible inconnue. Une cible connue pouvait recevoir une source inconnue. Une source authentique pouvait demander un contexte absent. Un contexte connu pouvait ne posséder aucune ligne ACL correspondante. Une ligne pouvait autoriser Get tout en refusant Set.

Ces refus ne sont pas des variantes stylistiques d’un même « accès interdit ». Ils décrivent des ruptures différentes dans la chaîne de décision. Les confondre empêche de savoir quel administrateur, quelle table ou quelle hypothèse doit être corrigé.

Le contexte empêchait l’identité d’absorber le périmètre

Un contexte SNMPv2 identifiait une collection de ressources gérées. Pour des ressources locales, il renvoyait à une vue MIB ; pour des ressources distantes, il pouvait porter une relation de mandataire. Le même sujet et la même cible pouvaient donc disposer de droits différents selon le contexte.

« Peut lire » demeurait une phrase inachevée. Il fallait ajouter où, auprès de quelle cible et sur quel ensemble d’objets. Après l’admission de la classe de communication, la vue du contexte bornait encore les objets effectivement accessibles.

L’absence observée gardait elle aussi une portée limitée. Ne pas voir un objet dans un contexte ne prouvait ni son inexistence physique, ni son exclusion de tous les autres contextes, ni l’absence de droits d’un autre sujet. Le résultat concernait une relation, une entité réceptrice et un état administratif précis.

La règle d’accès était elle-même un état géré

La ligne ACL possédait un type de stockage et un RowStatus. Elle pouvait être volatile, non volatile ou permanente ; sa présence dans la table ne garantissait donc ni son activation, ni sa survie au redémarrage, ni sa possibilité de modification.

L’histoire générale de RowStatus appartient à une autre analyse. Ici, son rôle est de rappeler que la politique qui gouverne les futurs messages est elle-même une donnée d’exploitation. SNMP pouvait servir à modifier les objets administratifs qui décideraient du sort des demandes suivantes.

Un Set accepté sur une colonne ACL ne démontrait pas encore qu’une future requête serait admise comme prévu. Il fallait préserver les valeurs écrites, la réponse, l’état de la ligne, l’activité des vues et des contextes dépendants, puis exécuter une nouvelle observation côté réception. La persistance exigeait encore une vérification au-delà du redémarrage ou de la période pertinente.

VACM conserva les coordonnées en changeant de carte

L’architecture originelle fondée sur les parties devint historique. RFC 2575, puis RFC 3415, définirent VACM pour l’architecture modulaire de SNMP. Le modèle était différent : modèle de sécurité et securityName conduisaient à un groupe ; groupe, contextName, modèle et niveau de sécurité sélectionnaient une entrée ; le caractère lecture, écriture ou notification choisissait une vue ; chaque nom de variable était enfin testé dans cette vue.

VACM distinguait notamment l’absence de contexte, de groupe, d’entrée d’accès ou de vue, ainsi que l’objet hors vue. Là encore, « mauvais identifiants » aurait été un résumé faux. Le point manquant pouvait se trouver à plusieurs articulations.

Il ne faut pas présenter Party MIB et VACM comme deux versions identiques d’une table. Leur architecture et leur sécurité diffèrent. Ce qui demeure, c’est la discipline relationnelle : « qui ? » ne répond pas à « où ? », « comment ? », « pour quelle opération ? » ni « sur quel objet ? ».

La permission écrite ne produisait pas l’effet

La primauté du code en fonctionnement, chez Lu Heng, sépare spécification, implémentation, validation, déploiement et usage. Son analyse des couches de réalité distingue autorité symbolique et effet exécutable. La Party MIB illustre cette séparation à petite échelle.

Le nom de partie appartient à l’identité déclarée. La ligne ACL exprime une politique locale. Le traitement à la réception applique cette politique. La réponse est la trace d’un résultat protocolaire. Le changement réel d’un compteur, d’une interface ou d’une route exige une observation supplémentaire.

Une partie connue ne prouve donc pas l’autorisation ; une ligne présente ne prouve pas son activité ; un Set admis ne prouve ni l’effet voulu ni sa durée ; une valeur retournée ne prouve pas sa justesse métier. Ces limites ne diminuent pas les preuves. Elles empêchent chacune d’usurper le rôle des autres.

La Party MIB est historique. Son intuition reste moderne : l’autorité devient vérifiable lorsqu’elle conserve ses coordonnées, et dangereuse lorsqu’elle se réduit à un adjectif flatteur collé à une identité.

Sources