Zum Hauptinhalt springen

Appendix A. Guidelines for Model Designers (Anhang A. Richtlinien für Modellentwickler)

Appendix A. Guidelines for Model Designers (Anhang A. Richtlinien für Modellentwickler)​

Dieser Anhang bietet Richtlinien für Entwickler von Sicherheitsmodellen, Message Processing Models, Access Control Models und SNMP-Anwendungen. Diese Richtlinien sind informativ und sollen Implementierer bei der Erstellung von Komponenten unterstützen, die innerhalb der SNMP-Architektur ordnungsgemäß funktionieren.

A.1. Security Model Design Requirements (Anforderungen an das Design von Sicherheitsmodellen)​

Ein Sicherheitsmodell muss Mechanismen für Authentifizierung, Vertraulichkeit und Aktualitätsprüfung bereitstellen. Dieser Abschnitt beschreibt die Anforderungen an Sicherheitsmodelle.

A.1.1. Threats (Bedrohungen)​

Sicherheitsmodelle müssen die folgenden Bedrohungen adressieren:

  1. Informationsänderung: Eine nicht autorisierte Entität, die Nachrichten während der Übertragung verändert

    • Ein Sicherheitsmodell muss Datenintegritätsdienste bereitstellen, um solche Änderungen zu erkennen

  2. Maskerade: Eine nicht autorisierte Entität, die die Identität einer autorisierten Entität annimmt

    • Ein Sicherheitsmodell muss Authentifizierungsdienste zur Überprüfung der Identität bereitstellen

  3. Nachrichtenstrom-Änderung: Neuordnung, Verzögerung oder Wiederholung von Nachrichten

    • Ein Sicherheitsmodell muss Aktualitätsprüfungen bereitstellen, um solche Angriffe zu erkennen

  4. Offenlegung: Freigabe von Nachrichteninhalten an eine nicht autorisierte Entität

    • Ein Sicherheitsmodell kann optional Vertraulichkeitsdienste durch Verschlüsselung bereitstellen

A.1.2. Security Processing (Sicherheitsverarbeitung)​

Ein Sicherheitsmodell muss die folgenden abstrakten Service-Primitiven implementieren:

  1. generateRequestMsg: Sicherheitsverarbeitung auf ausgehende Anfrage- und Benachrichtigungsnachrichten anwenden

    • Eingabe: scopedPDU, Sicherheitsparameter
    • Ausgabe: gesicherte, übertragungsbereite Nachricht
    • Verarbeitung:
      • Authentifizierung anwenden (falls vom Sicherheitsniveau gefordert)
      • Verschlüsselung anwenden (falls vom Sicherheitsniveau gefordert)
      • Sicherheitsparameter zur Nachricht hinzufügen
      • Sicherstellen, dass die Nachricht gemäß securityLevel geschützt ist

  2. processIncomingMsg: Sicherheit eingehender Nachrichten verarbeiten

    • Eingabe: empfangene Nachricht
    • Ausgabe: extrahierte scopedPDU, Sicherheitsparameter
    • Verarbeitung:
      • Authentifizierung überprüfen (wenn die Nachricht behauptet, authentifiziert zu sein)
      • Nachricht entschlüsseln (wenn die Nachricht verschlüsselt ist)
      • Aktualität prüfen (um Replay-Angriffe zu verhindern)
      • scopedPDU extrahieren
      • Sicherheitszustand zwischenspeichern, falls Antwort erforderlich sein könnte

  3. generateResponseMsg: Sicherheitsverarbeitung auf ausgehende Antwortnachrichten anwenden

    • Eingabe: scopedPDU, zwischengespeicherter Sicherheitszustand
    • Ausgabe: gesicherte Antwortnachricht
    • Verarbeitung:
      • Sicherheitsparameter aus zwischengespeichertem Zustand abrufen
      • Gleiches Sicherheitsniveau wie Anfrage anwenden
      • Authentifizierung anwenden (falls erforderlich)
      • Verschlüsselung anwenden (falls erforderlich)

A.1.3. Validate the security-stamp in a received message (Sicherheitsstempel in einer empfangenen Nachricht validieren)​

Ein Sicherheitsmodell muss Folgendes validieren:

  1. Authentifizierung ist gültig: Wenn die Nachricht behauptet, authentifiziert zu sein, Authentifizierungscode überprüfen

    • Geeignete kryptografische Überprüfung verwenden (z.B. HMAC-Überprüfung)
    • Nachrichten mit ungültiger Authentifizierung ablehnen

  2. Nachricht ist aktuell: Überprüfen, dass die Nachricht kein Replay ist

    • Nachrichtentiming-Parameter prüfen
    • Zustand zur Erkennung von Replays aufrechterhalten
    • Nachrichten außerhalb des Zeitfensters ablehnen

  3. Vertraulichkeit ist korrekt angewendet: Wenn die Nachricht verschlüsselt ist, überprüfen, dass sie entschlüsselt werden kann

    • Entschlüsselung mit geeigneten Schlüsseln versuchen
    • Erfolgreiche Entschlüsselung überprüfen
    • Nachrichten ablehnen, die nicht entschlüsselt werden können

  4. Sicherheitsniveau entspricht Anforderungen: Überprüfen, dass die tatsächlich angewendete Sicherheit mit der angeforderten übereinstimmt

    • Prüfen, dass authNoPriv-Nachrichten authentifiziert, aber nicht verschlüsselt sind
    • Prüfen, dass authPriv-Nachrichten sowohl authentifiziert als auch verschlüsselt sind
    • Prüfen, dass noAuthNoPriv-Nachrichten weder authentifiziert noch verschlüsselt sind

A.1.4. Security MIBs (Sicherheits-MIBs)​

Ein Sicherheitsmodell sollte ein MIB-Modul definieren, das Folgendes ermöglicht:

  1. Konfiguration von Sicherheitsparametern: Benutzer, Schlüssel, Authentifizierungsprotokolle, Vertraulichkeitsprotokolle
  2. Überwachung der Sicherheit: Zähler für Authentifizierungsfehler, Entschlüsselungsfehler usw.
  3. Fernkonfiguration: Sichere Mechanismen für die Remote-Konfiguration der Sicherheit

Das User-based Security Model (USM) definiert die SNMP-USER-BASED-SM-MIB für diesen Zweck.

A.1.5. Cached Security Data (Zwischengespeicherte Sicherheitsdaten)​

Bei der Verarbeitung einer eingehenden Anfrage, die möglicherweise eine Antwort erfordert, muss ein Sicherheitsmodell Sicherheitszustandsinformationen zwischenspeichern. Diese zwischengespeicherten Daten ermöglichen es, die Antwort mit denselben Sicherheitsparametern wie die Anfrage zu sichern.

Zwischengespeicherte Sicherheitsdaten umfassen typischerweise:

  • Sicherheitsparameter aus der Anfrage
  • Für Authentifizierung und/oder Verschlüsselung verwendete Schlüssel
  • Timing-Parameter
  • Alle anderen für die Generierung einer Antwort benötigten Zustände

Das Sicherheitsmodell muss:

  1. Eine securityStateReference generieren: Ein eindeutiger Identifikator für den zwischengespeicherten Zustand
  2. Die securityStateReference zurückgeben: An das Message Processing Model
  3. Den zwischengespeicherten Zustand abrufen: Wenn generateResponseMsg aufgerufen wird
  4. Den zwischengespeicherten Zustand freigeben: Nachdem die Antwort generiert wurde oder wenn explizit freigegeben

Der zwischengespeicherte Zustand kann implizit freigegeben werden, wenn:

  • Eine Antwort erfolgreich generiert wurde
  • Ein Fehler auftritt und keine Antwort gesendet wird
  • Ein Timeout auftritt

Der zwischengespeicherte Zustand kann explizit mit dem stateRelease-Primitiv freigegeben werden.

A.2. Message Processing Model Design Requirements (Anforderungen an das Design von Message Processing Models)​

Ein Message Processing Model definiert ein Nachrichtenformat und die Verfahren zur Verarbeitung von Nachrichten in diesem Format. Dieser Abschnitt beschreibt die Anforderungen an Message Processing Models.

A.2.1. Receiving an SNMP Message from the Network (Empfangen einer SNMP-Nachricht aus dem Netzwerk)​

Wenn eine Nachricht aus dem Netzwerk empfangen wird, bestimmt der Dispatcher, welches Message Processing Model sie verarbeiten soll (basierend auf der Nachrichtenversion oder dem Format). Das Message Processing Model muss das prepareDataElements-Primitiv implementieren.

prepareDataElements-Verarbeitung:

  1. Nachrichtenformat analysieren: Die verschiedenen Komponenten aus der Nachricht extrahieren

    • Nachrichtenheader
    • Sicherheitsparameter
    • Scoped PDU oder Payload

  2. Sicherheitsmodell bestimmen: Identifizieren, welches Sicherheitsmodell verwendet wurde

    • Normalerweise im Nachrichtenheader angegeben

  3. Sicherheitsmodell aufrufen: processIncomingMsg aufrufen, um:

    • Authentifizierung zu überprüfen
    • Nachricht zu entschlüsseln
    • Aktualität zu prüfen
    • Scoped PDU zu extrahieren

  4. Scoped PDU analysieren: Extrahieren:

    • contextEngineID
    • contextName
    • PDU

  5. Zustand bei Bedarf zwischenspeichern: Wenn dies eine Anfrage ist, die eine Antwort erfordern könnte:

    • Zur Generierung der Antwort benötigte Informationen zwischenspeichern
    • Eine stateReference generieren
    • Die stateReference mit den zwischengespeicherten Daten verknüpfen

  6. Extrahierte Datenelemente zurückgeben: Alle notwendigen Informationen an den Dispatcher zurückgeben:

    • messageProcessingModel
    • securityModel
    • securityName
    • securityLevel
    • contextEngineID
    • contextName
    • pduVersion
    • PDU
    • pduType
    • maxSizeResponseScopedPDU
    • stateReference
    • statusInformation

Fehlerbehandlung:

Wenn ein Schritt fehlschlägt, geeignete Fehler-statusInformation an den Dispatcher zurückgeben. Fehlerhafte oder nicht authentifizierte Nachrichten nicht an Anwendungen weitergeben.

A.2.2. Sending an SNMP Message to the Network (Senden einer SNMP-Nachricht an das Netzwerk)​

Beim Senden einer Nachricht ruft der Dispatcher entweder prepareOutgoingMessage (für Anfragen und Benachrichtigungen) oder prepareResponseMessage (für Antworten) auf. Das Message Processing Model muss diese Primitive implementieren.

prepareOutgoingMessage-Verarbeitung:

  1. Scoped PDU erstellen: contextEngineID, contextName und PDU kombinieren

  2. Sicherheitsmodell aufrufen: generateRequestMsg aufrufen, um:

    • Authentifizierung anzuwenden (falls erforderlich)
    • Verschlüsselung anzuwenden (falls erforderlich)
    • Sicherheitsparameter hinzuzufügen

  3. Nachricht erstellen: Die gesicherte Payload im entsprechenden Nachrichtenformat verpacken

    • Nachrichtenheader hinzufügen
    • Versions- oder Formatidentifikator hinzufügen
    • Nachrichtenspezifische Felder hinzufügen

  4. Vollständige Nachricht zurückgeben: Die formatierte, übertragungsbereite Nachricht zurückgeben:

    • outgoingMessage
    • outgoingMessageLength
    • statusInformation

prepareResponseMessage-Verarbeitung:

Ähnlich wie prepareOutgoingMessage, aber:

  1. Zwischengespeicherten Zustand abrufen: Die stateReference verwenden, um zwischengespeicherte Informationen abzurufen

  2. Scoped PDU erstellen: contextEngineID, contextName und PDU kombinieren (aus ursprünglicher Anfrage)

  3. Sicherheitsmodell aufrufen: generateResponseMsg mit folgenden Parametern aufrufen:

    • Die scoped PDU
    • Die securityStateReference (um dieselben Sicherheitsparameter wie die Anfrage zu verwenden)

  4. Antwortnachricht erstellen: Die gesicherte Payload im entsprechenden Format verpacken

  5. Zwischengespeicherten Zustand freigeben: Nach erfolgreicher Erstellung der Antwort den zwischengespeicherten Zustand freigeben

  6. Vollständige Antwort zurückgeben: Die formatierte Antwortnachricht zurückgeben

Fehlerbehandlung:

Wenn ein Schritt fehlschlägt, geeignete Fehler-statusInformation zurückgeben. Wenn eine Antwort nicht generiert werden kann, sicherstellen, dass der zwischengespeicherte Zustand freigegeben wird.

A.3. Application Design Requirements (Anforderungen an das Anwendungsdesign)​

SNMP-Anwendungen nutzen die Dienste der SNMP-Engine, um Verwaltungsfunktionen auszuführen. Dieser Abschnitt beschreibt Anforderungen und Richtlinien für das Anwendungsdesign.

A.3.1. Applications that Initiate Messages (Anwendungen, die Nachrichten initiieren)​

Anwendungen, die Nachrichten initiieren (Command Generators, Notification Originators), müssen:

  1. Ziel bestimmen: Die Ziel-SNMP-Engine identifizieren

    • transportDomain
    • transportAddress
    • contextEngineID

  2. Sicherheitsparameter bestimmen:

    • securityModel
    • securityName
    • securityLevel

  3. PDU erstellen: Die Protocol Data Unit mit der gewünschten Operation und Variablen erstellen

  4. sendPdu aufrufen: Das sendPdu-Primitiv des Dispatchers mit folgenden Parametern aufrufen:

    • Zielinformationen
    • Sicherheitsparameter
    • contextEngineID und contextName
    • PDU
    • expectResponse-Flag
    • sendPduHandle (um spätere Antwort zu korrelieren)

  5. Antwort behandeln: Wenn expectResponse TRUE war, processResponsePdu implementieren, um die Antwort zu empfangen

Richtlinien:

  • Ziele konfigurieren: Konfigurationsmechanismen (z.B. SNMP-TARGET-MIB) verwenden, um Zielinformationen zu verwalten
  • Sicherheit konfigurieren: Konfigurationsmechanismen (z.B. SNMP-USER-BASED-SM-MIB) verwenden, um Sicherheitsparameter zu verwalten
  • Fehler behandeln: statusInformation-Fehler von sendPdu ordnungsgemäß behandeln
  • Timeouts implementieren: Wenn keine Antwort innerhalb einer angemessenen Zeit empfangen wird, Timeout behandeln
  • Wiederholungen implementieren: Erneute Übertragung in Betracht ziehen, wenn keine Antwort empfangen wird

A.3.2. Applications that Receive Responses (Anwendungen, die Antworten empfangen)​

Anwendungen, die Antworten empfangen, müssen das processResponsePdu-Primitiv implementieren.

processResponsePdu-Implementierung:

  1. Antwort korrelieren: sendPduHandle verwenden, um die Antwort der ursprünglichen Anfrage zuzuordnen

  2. statusInformation prüfen: Überprüfen, dass die Nachrichtenverarbeitung erfolgreich war

  3. PDU verarbeiten: Antwortdaten extrahieren und verarbeiten

    • error-status und error-index prüfen
    • Variable Bindings extrahieren
    • Anwendungsspezifische Verarbeitung durchführen

Richtlinien:

  • Fehler behandeln: Auf SNMP-Fehler prüfen (z.B. noSuchName, tooBig, genErr)
  • Ausnahmen behandeln: Auf Ausnahmewerte prüfen (noSuchObject, noSuchInstance, endOfMibView)
  • Sicherheitsfehler behandeln: Auf Authentifizierungs- oder Vertraulichkeitsfehler vorbereitet sein
  • Zustand bereinigen: Alle mit der Anfrage verbundenen Ressourcen freigeben

A.3.3. Applications that Receive Asynchronous Messages (Anwendungen, die asynchrone Nachrichten empfangen)​

Anwendungen, die asynchrone Nachrichten empfangen (Command Responders, Notification Receivers), müssen:

  1. Beim Dispatcher registrieren: registerContextEngineID aufrufen, um sich für Folgendes zu registrieren:

    • Spezifische contextEngineID-Werte
    • Spezifische PDU-Typen

  2. processPdu implementieren: Eingehende PDUs empfangen und verarbeiten

    • contextEngineID und contextName validieren
    • PDU gemäß Anwendungssemantik verarbeiten
    • Antwort generieren (falls erforderlich)

processPdu-Implementierung:

  1. Kontext validieren: Sicherstellen, dass diese Anwendung für die contextEngineID und den contextName verantwortlich ist

  2. Zugriffskontrolle prüfen (falls zutreffend): isAccessAllowed für jede Variable in der PDU aufrufen

  3. Anfrage verarbeiten: Die angeforderte Operation ausführen

    • Für GET: Variablenwerte abrufen
    • Für SET: Variablenwerte ändern
    • Für GETNEXT: Lexikografisch nächste Variable finden
    • Für GETBULK: Mehrere Variablen effizient abrufen

  4. Antwort-PDU erstellen (falls erforderlich): Eine Antwort-PDU mit Ergebnissen erstellen

  5. returnResponsePdu aufrufen (falls erforderlich): Die Antwort an den Anforderer zurücksenden

Richtlinien:

  • Eingabe validieren: Alle Eingaben sorgfältig validieren, um Sicherheitslücken zu verhindern
  • Zugriffskontrolle implementieren: Geeignete Zugriffskontrolle auf alle Operationen anwenden
  • Fehler angemessen behandeln: Geeignete Fehlerantworten für ungültige Anfragen zurückgeben
  • maxSizeResponseScopedPDU respektieren: Sicherstellen, dass die Antwort die Größenbeschränkung nicht überschreitet
  • stateReference verwenden: Die stateReference unverändert von processPdu an returnResponsePdu übergeben

A.3.4. Applications that Send Responses (Anwendungen, die Antworten senden)​

Anwendungen, die Antworten senden, müssen das returnResponsePdu-Primitiv verwenden.

returnResponsePdu-Verwendung:

  1. Parameter von processPdu verwenden: Folgendes durchreichen:

    • messageProcessingModel
    • securityModel
    • securityName
    • securityLevel
    • contextEngineID
    • contextName
    • pduVersion
    • maxSizeResponseScopedPDU
    • stateReference

  2. Antwort-PDU erstellen: Die PDU mit Ergebnissen erstellen

  3. returnResponsePdu aufrufen: Das returnResponsePdu-Primitiv des Dispatchers aufrufen

Richtlinien:

  • Sicherheitsparameter nicht ändern: Dieselben Sicherheitsparameter wie die Anfrage verwenden
  • Größenbeschränkungen respektieren: Sicherstellen, dass die Antwort in maxSizeResponseScopedPDU passt
  • Fehler behandeln: Wenn die Antwort nicht gesendet werden kann, den Fehler angemessen behandeln
  • Zustand freigeben: Die stateReference wird vom Dispatcher nach dem Senden der Antwort freigegeben

A.4. Access Control Model Design Requirements (Anforderungen an das Design von Access Control Models)​

Ein Access Control Model bestimmt, ob der Zugriff auf ein verwaltetes Objekt erlaubt werden sollte. Dieser Abschnitt beschreibt die Anforderungen an Access Control Models.

Ein Access Control Model muss das isAccessAllowed-Primitiv implementieren.

isAccessAllowed-Implementierung:

  1. Principal bestimmen: Identifizieren, wer den Zugriff versucht

    • securityModel und securityName verwenden

  2. Zugriffstyp bestimmen: Identifizieren, welcher Zugriffstyp angefordert wird

    • read: GET, GETNEXT, GETBULK
    • write: SET
    • notify: TRAP, INFORM

  3. Ziel bestimmen: Identifizieren, auf welches Objekt zugegriffen wird

    • variableName (OID)
    • contextName

  4. Zugriffskontrollrichtlinie anwenden: Basierend auf der konfigurierten Richtlinie bestimmen, ob Zugriff erlaubt werden sollte

  5. Ergebnis zurückgeben: Erlaubt oder verweigert zurückgeben

Richtlinien:

  • MIB definieren: Ein MIB-Modul zur Konfiguration der Zugriffskontrollrichtlinie definieren
  • Fernkonfiguration unterstützen: Konfiguration der Richtlinie über SNMP ermöglichen
  • Standardmäßig verweigern: Wenn keine explizite Richtlinie den Zugriff erlaubt, standardmäßig verweigern
  • Effiziente Implementierung: Zugriffskontrolle kann viele Male pro Anfrage aufgerufen werden; effizient implementieren
  • Konsistente Richtlinie: Sicherstellen, dass die Richtlinie konsistent angewendet wird

Das in RFC 3415 definierte View-based Access Control Model (VACM) ist eine Beispielimplementierung.

Letztes Update am