Zusammenfassung

  • RFC 1447 indizierte einen Zugriffseintrag nach Ziel-, Subjekt-Partei und Ressourcenkontext; die erlaubten PDU-Klassen standen in einem eigenen Feld.
  • Ein bekannter oder authentisierter Absender war nur Eingangsdaten für die lokale Empfangsentscheidung, keine übertragbare Vollmacht.
  • Das spätere VACM änderte die Architektur, behielt aber die relationale Prüfung aus Principal, Kontext, Sicherheitsbedingung, Sichttyp und Einzelobjekt bei.

Die Matrix enthielt die Vollmacht

Die Party MIB erschien im April 1993 als Teil des ersten SNMPv2-Rahmens. Eine Party war dort keine natürliche Person, sondern eine konzeptionelle Ausführungsumgebung, die administrativ auf einen Teil der möglichen Operationen eines SNMPv2-Systems begrenzt war.

Ein System konnte mehrere Parties mit überlappenden oder getrennten Befugnissen realisieren. Es konnte eine entfernte Party lokal kennen, ohne sie selbst auszuführen. Der Identifikator öffnete damit einen Verwaltungsdatensatz; er verlieh keinen universellen Administratorrang.

RFC 1447 materialisierte diese Grenze in aclTable. Der Index bestand aus aclTarget, aclSubject und aclResources. Target bezeichnete die Party, die handeln sollte. Subject bezeichnete die anfragende Party. Resources verwies auf den SNMPv2-Kontext der verwalteten Objekte.

Erst für dieses Tripel gab aclPrivileges die erlaubten Kommunikationsklassen an. Berechtigung war keine Eigenschaft eines Subjekts, sondern eine gerichtete Beziehung mit Ort und Verb.

35 war eine Menge, keine Stufe

Die PDU-Klassen wurden additiv kodiert: Get 1, GetNext 2, Response 4, Set 8, GetBulk 32, Inform 64 und SNMPv2-Trap 128. Null bezeichnete die leere Menge. Der Standardwert 35 setzte sich aus Get, GetNext und GetBulk zusammen.

Die Zahl bildete keine Rangordnung. 43 ergänzte Set zur Lesegruppe; 4 erlaubte nur Response. Wer 35 als „vertrauenswürdig“ anzeigte, verlor Richtung, Ziel, Kontext und konkrete Operation. Selbst „Lesezugriff“ blieb nur eine Kurzform für die exakte Bitmenge.

Die Initialbeispiele führten getrennte Regeln für beide Richtungen. Eine Manager-Party durfte Leseanfragen an eine Agent-Party richten; der Rückweg konnte Response und Trap erlauben. Fragerecht erzeugte kein Antwortrecht, und ohne den Set-Wert entstand kein Schreibrecht.

Dass dieselben Parteien an beiden Zeilen beteiligt waren, vereinigte sie nicht. Rollenwechsel und Nachrichtenrichtung gehörten zur Policy.

Der Versand entschied nicht für den Empfänger

RFC 1445 wendete Zugriffskontrolle beim Empfang an, nicht beim Senden. Der Absender baute Quell-Party, Ziel-Party, Kontext und PDU zusammen und übergab die Nachricht dem Transport. Damit hatte er die aktuelle lokale Policy des Empfängers nicht ausgeführt.

Nach dem Eintreffen folgten getrennte Prüfungen. War das Ziel bekannt und lokal realisiert? War die Quelle bekannt? Bestand die Authentisierung unter den konfigurierten Protokollen? Existierte der Kontext? Gab es eine passende Zeile für Quelle, Ziel und Kontext? Enthielt sie die aktuelle PDU-Klasse?

Eine korrekt kodierte Nachricht konnte ein unbekanntes Ziel nennen. Ein bekanntes Ziel konnte eine unbekannte Quelle sehen. Eine authentische Quelle konnte einen fehlenden Kontext verlangen. Ein vorhandener Kontext konnte ohne ACL bleiben, eine ACL Get erlauben und Set verweigern.

Zwei Empfänger durften dasselbe Subjekt kennen und verschieden entscheiden, weil Ziel-Parties, Kontexte, Sichten und Regeln lokal waren. Der Sender kontrollierte den Wunsch, nicht die Autorisierung am anderen Ende.

Der Kontext hielt den Gegenstand in der Entscheidung

Ein SNMPv2-Kontext bezeichnete eine Sammlung verwalteter Ressourcen. Für lokale Ressourcen verwies er auf eine MIB-Sicht; für entfernte konnte er eine Proxy-Beziehung beschreiben. Dasselbe Subject-Target-Paar konnte deshalb in verschiedenen Kontexten unterschiedliche Rechte besitzen.

„Darf lesen“ blieb unvollständig, bis Ziel, Kontext und Sicht feststanden. Auch nach Zulassung der PDU-Klasse begrenzte die Sicht die tatsächlich zugänglichen Objekte.

Ein unsichtbares Objekt bewies folglich weder physische Nichtexistenz noch Ausschluss aus anderen Kontexten noch fehlende Rechte eines anderen Subjekts. Es dokumentierte eine lokale Entscheidung für genau diese Beziehung.

Die Zugriffsregel war selbst Betriebszustand

Zu einer ACL-Zeile gehörten aclStorageType und aclStatus. Sie konnte flüchtig, nichtflüchtig oder permanent gespeichert sein; RowStatus beschrieb ihren Lebenszyklus. Sichtbarkeit in der Tabelle bewies weder Aktivität noch Bestand nach Neustart noch Änderbarkeit.

Die allgemeine RowStatus-Geschichte ist anderswo erzählt. Für RFC 1447 ist wichtig, dass die Autorisierungsbeziehung selbst verwalteter Zustand war. Managementverkehr konnte jene Objekte ändern, die über späteren Managementverkehr entschieden.

Eine erfolgreiche Set-Antwort auf eine ACL-Spalte bewies noch nicht die Zulassung der nächsten Anfrage. Benötigt wurden Schreibwerte, Antwort, Zeilenstatus, aktive Abhängigkeiten und ein neuer Test auf der Empfangsseite. Persistenz verlangte eine weitere Beobachtung über den relevanten Neustart hinweg.

VACM wechselte das Schema, nicht das relationale Prinzip

Der ursprüngliche Party-Rahmen wurde Historic. RFC 2575 und später RFC 3415 definierten VACM für die modulare SNMP-Architektur. Sicherheitsmodell und securityName wurden einer Gruppe zugeordnet; Gruppe, contextName, Sicherheitsmodell und -stufe wählten einen Zugriffseintrag; Lesen, Schreiben oder Benachrichtigen wählte eine Sicht; der einzelne Variablenname wurde in dieser Sicht geprüft.

VACM unterschied fehlenden Kontext, fehlende Gruppe, fehlenden Zugriffseintrag, fehlende Sicht und ein Objekt außerhalb der Sicht. Sie konnten alle wie Ablehnung erscheinen, bezeichneten aber unterschiedliche fehlende Verknüpfungen.

Party MIB und VACM sind nicht dasselbe System. Kontinuität besteht in der Zurückhaltung: „Wer?“ beantwortet nicht „wo?“, „unter welcher Sicherheit?“, „mit welcher Operation?“ und „auf welchem Objekt?“.

Symbolische Policy war nicht der Effekt

Lu Hengs Running-Code-Primat trennt Spezifikation, Implementierung, Validierung, Einsatz und Nutzung. Seine Realitätsebenen trennen symbolische Autorität von ausführbarer Wirkung. RFC 1447 liefert dafür ein begrenztes historisches Beispiel.

Die Party-ID benannte. Die ACL formulierte lokale Policy. Die Empfangsverarbeitung setzte sie um. Die Antwort hielt ein Protokollergebnis fest. Ob Interface, Zähler oder Route sich wirklich änderten, verlangte eine weitere Beobachtung.

Eine bekannte Party bewies keine Autorisierung. Eine vorhandene Zeile bewies keine Aktivität. Ein zugelassenes Set bewies weder richtige Wirkung noch Dauer. Ein gelieferter Wert bewies keine semantische Richtigkeit. Auditierbarkeit entsteht, wenn keine dieser Ebenen für alle anderen sprechen darf.

Die Party MIB ist Geschichte. Ihre strengere Aussage bleibt: Autorität gehört in eine rekonstruierbare Beziehung, nicht als schmeichelndes Attribut an eine Identität.

Quellen