Zusammenfassung

  • In SNMPv3 lokalisieren contextEngineID und contextName einen Bestand an Verwaltungsinformationen; securityName repräsentiert einen Prinzipal, und VACM entscheidet separat über dessen Lese-, Schreib- und Benachrichtigungsrechte an einzelnen Objekten.
  • Ein belastbarer Verwaltungsnachweis verbindet Protokollidentität, Kontext, Zugriffssicht und Antwort mit einer externen Änderungsfreigabe und mit Beobachtungen, dass der beabsichtigte Betriebszustand tatsächlich folgte.

Dieselbe OID kommt auf vielen Geräten vor. Informationen eines Geräts können in mehreren Kontexten erscheinen. Ein Proxy kann die Verbindung annehmen und die Antwort von einer anderen SNMP-Entität holen. Fasst eine Oberfläche all dies unter „SNMP-Ziel“ zusammen, lässt sich eine gültige Antwort dem falschen Asset zurechnen und ein authentisiertes Dienstkonto zum vermeintlichen menschlichen Genehmiger machen.

RFC 3411 erschien im Dezember 2002 als Standards-Track-Teil von STD 62. David Harrington verfasste ihn gemeinsam mit Randy Presuhn und Bert Wijnen. Diese gemeinsame Urheberschaft bleibt wichtig. Ebenso verteilt die Architektur selbst die Bedeutung: Engine, Prinzipal, Kontext, Sicherheitsverarbeitung und Zugriffskontrolle tragen eigene Namen, weil sie unterschiedliche Belege liefern.

Eine Engine ist kein Prinzipal

Eine SNMP Engine sendet und empfängt Nachrichten, verarbeitet Protokollmodelle, erbringt Sicherheitsdienste und ruft die Zugriffskontrolle auf. Innerhalb einer administrativen Domäne identifiziert snmpEngineID diese Engine und die zugehörige SNMP-Entität eindeutig. Außerhalb der Domäne endet die Zusicherung; andere Domänen können denselben Wert verwenden. Er ist weder weltweite Assetnummer noch Eigentumsnachweis.

Ein Prinzipal ist die Entität, in deren Namen ein Dienst erbracht wird. RFC 3411 stellt ihn durch securityName dar, eine lesbare, vom konkreten Security Model unabhängige Zeichenfolge. Das jeweilige Modell übersetzt seine eigene Kennung in diesen gemeinsamen Namen. Lesbarkeit macht daraus keinen Menschen. Dienstkonto, Rolle oder gemeinsam verwendete Betriebsidentität können ebenso darin stehen.

Damit entstehen drei Fragen: Welche Protokoll-Engine war beteiligt? Welchen Prinzipal hat das Security Model geliefert? Welche Person oder Organisation entschied die Änderung? EngineID und securityName beantworten die ersten beiden. Ein Arbeitsverhältnis, eine Freigabe, ein Auftrag oder der aktuelle Wille eines Menschen folgt daraus nicht.

Der Kontext adressiert Verwaltungsinformationen

Ein SNMP-Kontext ist eine Sammlung von Verwaltungsinformationen, auf die eine SNMP-Entität zugreifen kann. Er darf mehrere Geräte, einen Teil eines Geräts oder Teile mehrerer Geräte umfassen, wird aber als Teilmenge einer einzelnen SNMP-Entität definiert. Für ein bestimmtes Informationselement braucht die Architektur vier Koordinaten: contextEngineID, contextName, Objekttyp und Instanz.

Das Paar aus contextEngineID und contextName bezeichnet einen Kontext innerhalb der administrativen Domäne eindeutig. RFC 3411 erlaubt jedoch, dass mehrere unterschiedliche Paare denselben Kontext bezeichnen. Aliasse sind also möglich. Der Kontext ist ein Protokolllokator für einen Informationsraum, keine unveränderliche Seriennummer eines Geräts und keine Identität seines Betreibers.

Die scopedPDU schreibt die Trennung in die Nachricht: Sie enthält Kontext-Engine-ID, Kontextnamen und PDU. Diese Felder beantworten „wo liegen die Informationen?“. Sicherheitsparameter beantworten „in wessen Namen?“. Wer den Kontext als Akteur protokolliert, vermischt Ort und Identität, bevor die Autorisierung überhaupt entschieden hat.

Nachrichtensicherheit kommt vor der Sichtberechtigung

RFC 3414 definiert das User-based Security Model für SNMPv3. Es behandelt Nachrichtenauthentisierung, Vertraulichkeit, Zeitnähe und begrenzten Schutz vor Wiederholung. Integrität, Geheimhaltung und ein akzeptables Zeitfenster sind wertvolle, aber auf Nachricht und konfigurierte Schlüsselbeziehung begrenzte Nachweise.

Die Sicherheitsverarbeitung liefert dem Rest der Architektur Modell, Prinzipal und erreichtes Sicherheitsniveau. Sie wählt keine Verwaltungssicht. Eine erfolgreiche Authentisierung sagt noch nicht, ob der Prinzipal diese Operation an diesem Objekt in diesem Kontext vornehmen darf.

Diese Entscheidung übernimmt das View-based Access Control Model aus RFC 3415. VACM ordnet das Paar securityModel und securityName einer Gruppe zu. Sein Modul setzt ausdrücklich voraus, dass der Sicherheitsname bei Bedarf bereits authentisiert wurde, und authentisiert nicht erneut. Das vorgelagerte Ergebnis ist Eingang einer eigenständigen Richtlinie.

Die Richtlinie berücksichtigt außerdem Sicherheitsniveau, Kontext und Sichttyp. Lese-, Schreib- und Benachrichtigungssichten sind getrennt. Wer einen Schnittstellenzähler lesen darf, darf die Schnittstelle nicht zwangsläufig abschalten. Schreibrecht auf einem Teilbaum öffnet weder den gesamten MIB-Baum noch alle Benachrichtigungen. Die konkrete OID bleibt Teil der Prüfung.

Der Dienst isAccessAllowed benennt die Eingaben: securityModel, securityName, securityLevel, viewType, contextName und variableName. Seine Ergebnisse unterscheiden gewährten Zugriff von Zuständen wie noSuchContext oder notInView. Ein Logeintrag „authentisiert“ löscht gerade jene Angaben, die eine Ablehnung erklären.

Ein Proxy verlängert die Zuordnungskette

RFC 3413 beschreibt SNMP-Anwendungen einschließlich des optionalen Proxy Forwarder. Dieser kann Anfragen oder Benachrichtigungen für ein bestimmtes contextEngineID/contextName-Paar an eine andere SNMP-Entität weiterleiten. Die Engine am Transportende muss nicht der Ort sein, an dem die Verwaltungsinformation liegt.

Diese Indirektion verlangt Nachweise für beide Abschnitte: eingehender Transportpartner, übersetzter Sicherheitsprinzipal, empfangener Kontext, ausgewählte Proxyregel, ausgehendes Ziel mit Kontext, Korrelation beider Anfragen und Fehler auf jedem Weg. Eine über den Proxy zurückgegebene Response-PDU belegt eine verkettete Protokolltransaktion, keine direkte menschliche Bedienung des Zielgeräts.

Betreiber des Proxys, Eigentümer des Assets, Verwalter der Zugriffssichten und Auslöser der Automatisierung können verschiedene Parteien sein. Der Kontext transportiert Geltungsbereich durch diese Topologie, ohne die Verantwortlichkeiten zu einer Identität zu verschmelzen.

EngineID-Ermittlung ermittelt keinen Eigentümer

RFC 5343 ergänzt einen Mechanismus zur Ermittlung einer geeigneten Kontext-Engine-ID. Kennt eine Anwendung den Wert noch nicht, kann sie über einen festgelegten lokalen Wert die Kennung lernen, die in die begrenzte Anfrage gehört.

Das Ergebnis löst ein Problem der Protokolladressierung. Es zertifiziert nicht, dass die gefundene Engine das von einer Person gemeinte Asset repräsentiert, einer behaupteten Organisation gehört oder vom Prinzipal genutzt werden darf. Ermittlung, Inventarabgleich und Autorisierung behalten eigene Belege.

Eine geänderte EngineID ist deshalb ein Anlass zur Abstimmung, kein Beweis eines Angriffs. Austausch, Wiederherstellung, Neukonfiguration oder ein anderer Pfad sind ebenfalls möglich. Umgekehrt beweist eine stabile Kennung nicht, dass Eigentümer, Software, Richtlinie und berechtigte Personen gleich geblieben sind.

Protokollerfolg liegt noch vor dem realen Zustand

Bei einer Leseoperation belegt die Antwort, welchen Wert der Agent für Objekt und Kontext zu einem Zeitpunkt zurückgab. Ohne weitere Beobachtung beweist sie weder Aktualität des Sensors noch Übereinstimmung mit der physischen Welt. Bei einer Schreiboperation kann sie Annahme des SET belegen, nicht aber Betätigung, Persistenz nach Neustart, Konvergenz abhängiger Systeme oder ausbleibenden späteren Rollback.

Der vollständige Nachweis verbindet zwei Ebenen. Die SNMP-Ebene hält Endpunkt, Message Processing Model, Security Model, ursprüngliche Kennung, securityName, Sicherheitsniveau, Kontextpaar, OID und Instanz, Lese-/Schreib-/Benachrichtigungstyp, VACM-Gruppe und -Sicht, Proxyweg und Antwort fest. Die Governance-Ebene hält Genehmiger, erlaubtes Fenster, Zielzustand, Rollback-Bedingung und spätere Zustandsbeobachtung fest.

David Harringtons Architekturbeitrag verspricht nicht, dass jede Installation diese Kette bereits besitzt. Er bietet ein Vokabular, das Rollen auseinanderhält: Der Kontext lokalisiert Informationen, der Sicherheitsname repräsentiert einen Prinzipal, die Sicht entscheidet Protokollzugriff. Menschliche Autorität und betriebliche Folge benötigen weiterhin eigene Belege.

Quellen