Zum Hauptinhalt springen

3. Elements of the Architecture (Elemente der Architektur)

3. Elements of the Architecture (Elemente der Architektur)​

Dieser Abschnitt beschreibt die Elemente, aus denen die SNMP-Architektur besteht. Die Architektur ist um das Konzept einer SNMP-Engine herum konzipiert, die Dienste für eine oder mehrere SNMP-Anwendungen bereitstellt.

3.1. The Naming of Entities (Die Benennung von Entitäten)​

Mehrere Arten von Entitäten werden innerhalb der Architektur identifiziert:

  • SNMP-Engine: Eine Implementierung der in dieser Architektur definierten Dienste. Eine SNMP-Engine bietet Nachrichtenverarbeitung, Sicherheit und Zugriffskontrolldienste.

  • SNMP-Entität: Eine SNMP-Engine plus eine oder mehrere SNMP-Anwendungen. Eine SNMP-Entität kann als Agent, Manager oder beides fungieren.

  • SNMP-Agent: Eine SNMP-Entität, die Zugriff auf Verwaltungsinformationen bietet. Ein Agent läuft typischerweise auf einem verwalteten Gerät.

  • SNMP-Manager: Eine SNMP-Entität, die SNMP-Anfragen initiiert und SNMP-Antworten und Benachrichtigungen verarbeitet. Ein Manager läuft typischerweise auf einer Verwaltungsstation.

3.1.1. SNMP engine (SNMP-Engine)​

Eine SNMP-Engine ist eine Implementierung der SNMP-Nachrichtenverarbeitung, Sicherheit und Zugriffskontrolldienste. Eine SNMP-Engine wird eindeutig durch eine snmpEngineID identifiziert.

3.1.1.1. snmpEngineID​

Die snmpEngineID ist ein OCTET STRING, der eine SNMP-Engine eindeutig identifiziert. Die snmpEngineID wird administrativ zugewiesen und sollte so gewählt werden, dass sie über alle SNMP-Engines im Netzwerk eindeutig ist.

Das Format der snmpEngineID ist so konzipiert, dass die Eindeutigkeit gewährleistet ist. Es umfasst typischerweise eine Unternehmensnummer und zusätzliche identifizierende Informationen wie eine MAC-Adresse, IP-Adresse oder einen administrativ zugewiesenen Wert.

Die snmpEngineID erfüllt mehrere wichtige Zwecke:

  1. Sie identifiziert die SNMP-Engine, die eine Nachricht gesendet hat
  2. Sie identifiziert die SNMP-Engine, deren verwaltete Objekte zugegriffen werden
  3. Sie dient als Schlüssel für Sicherheitsinformationen
  4. Sie dient als Schlüssel für lokalisierte Sicherheitsparameter
3.1.1.2. Dispatcher (Dispatcher)​

Der Dispatcher ist verantwortlich für:

  1. Empfangen von Nachrichten aus dem Netzwerk und Bestimmen der Nachrichtenversion
  2. Routing von Nachrichten zum geeigneten Message Processing Model
  3. Routing von PDUs zur geeigneten SNMP-Anwendung
  4. Senden von Nachrichten an das Netzwerk

Der Dispatcher bietet abstrakte Service-Schnittstellen zu Anwendungen und zu Subsystemen der SNMP-Engine.

3.1.1.3. Message Processing Subsystem (Message Processing Subsystem)​

Das Message Processing Subsystem ist verantwortlich für die Vorbereitung von Nachrichten zur Übertragung und für die Extraktion von Daten aus empfangenen Nachrichten.

Das Message Processing Subsystem kann mehrere Message Processing Models enthalten. Jedes Message Processing Model definiert ein Nachrichtenformat und die Verfahren zur Verarbeitung dieses Nachrichtenformats.

3.1.1.3.1. Message Processing Model (Message Processing Model)​

Ein Message Processing Model definiert ein Nachrichtenformat und die Verfahren zur Verarbeitung dieses Nachrichtenformats. Verschiedene Message Processing Models können innerhalb einer einzelnen SNMP-Engine koexistieren.

Standard Message Processing Models umfassen:

  • SNMPv1: Definiert in RFC 3584
  • SNMPv2c: Definiert in RFC 3584
  • SNMPv3: Definiert in RFC 3412

Jedes Message Processing Model wird durch einen eindeutigen messageProcessingModel-Wert identifiziert.

3.1.1.4. Security Subsystem (Security Subsystem)​

Das Security Subsystem bietet Sicherheitsdienste wie Authentifizierung, Vertraulichkeit und Aktualitätsprüfung.

Das Security Subsystem kann mehrere Security Models enthalten. Jedes Security Model definiert eine Reihe von Sicherheitsprotokollen und die Verfahren zu deren Anwendung.

3.1.1.4.1. Security Model (Sicherheitsmodell)​

Ein Security Model definiert eine Reihe von Sicherheitsprotokollen und die Verfahren zu deren Anwendung auf SNMP-Nachrichten. Verschiedene Security Models können innerhalb einer einzelnen SNMP-Engine koexistieren.

Standard Security Models umfassen:

  • User-based Security Model (USM): Definiert in RFC 3414, bietet Authentifizierung und Vertraulichkeit unter Verwendung symmetrischer Kryptographie
  • Community-based Security Model: Verwendet mit SNMPv1 und SNMPv2c, definiert in RFC 3584

Jedes Security Model wird durch einen eindeutigen securityModel-Wert identifiziert.

3.1.1.4.2. Security Protocol (Sicherheitsprotokoll)​

Ein Security Protocol ist ein spezifischer kryptographischer Algorithmus, der von einem Security Model verwendet wird. Beispielsweise unterstützt das User-based Security Model mehrere Authentifizierungsprotokolle (HMAC-MD5-96, HMAC-SHA-96) und mehrere Vertraulichkeitsprotokolle (CBC-DES, CBC-AES).

3.1.2. Access Control Subsystem (Access Control Subsystem)​

Das Access Control Subsystem bestimmt, ob eine bestimmte SNMP-Operation erlaubt werden sollte. Es trifft diese Entscheidung basierend auf der Identität des Benutzers, der Art der Operation und dem verwalteten Objekt, auf das zugegriffen wird.

Das Access Control Subsystem kann mehrere Access Control Models enthalten. Jedes Access Control Model definiert eine Richtlinie zur Durchführung von Zugriffskontrollentscheidungen.

3.1.2.1. Access Control Model (Zugriffskontrollmodell)​

Ein Access Control Model definiert eine Richtlinie zur Bestimmung, ob der Zugriff auf ein verwaltetes Objekt gewährt werden sollte. Verschiedene Access Control Models können innerhalb einer einzelnen SNMP-Engine koexistieren.

Das Standard-Zugriffskontrollmodell ist das View-based Access Control Model (VACM), definiert in RFC 3415.

Jedes Access Control Model wird durch einen eindeutigen accessControlModel-Wert identifiziert.

3.1.3. Applications (Anwendungen)​

SNMP-Anwendungen nutzen die Dienste der SNMP-Engine, um Verwaltungsfunktionen auszuführen. Eine SNMP-Entität kann mehrere Anwendungen enthalten.

3.1.3.1. SNMP Manager (SNMP-Manager)​

Ein SNMP-Manager ist eine SNMP-Entität, die SNMP-Anfragen initiiert und SNMP-Antworten und Benachrichtigungen verarbeitet. Ein Manager enthält typischerweise die folgenden Arten von Anwendungen:

  • Command Generator: Initiiert Get-, GetNext-, GetBulk- und Set-Operationen
  • Notification Receiver: Empfängt Trap- und InformRequest-Operationen

Ein Manager kann auch eine Proxy Forwarder-Anwendung enthalten, die SNMP-Nachrichten an andere SNMP-Entitäten weiterleitet.

3.1.3.2. SNMP Agent (SNMP-Agent)​

Ein SNMP-Agent ist eine SNMP-Entität, die Zugriff auf Verwaltungsinformationen bietet. Ein Agent enthält typischerweise die folgenden Arten von Anwendungen:

  • Command Responder: Antwortet auf Get-, GetNext-, GetBulk- und Set-Operationen
  • Notification Originator: Initiiert Trap- und InformRequest-Operationen

Ein Agent kann auch eine Proxy Forwarder-Anwendung enthalten, die SNMP-Nachrichten an andere SNMP-Entitäten weiterleitet.

Ein Agent enthält Instrumentierung, die Software ist, die Zugriff auf die tatsächlichen verwalteten Objekte bietet. Die Instrumentierung übersetzt zwischen SNMP-Operationen und den Operationen, die zum Zugriff auf die zugrunde liegenden verwalteten Objekte erforderlich sind.

3.2. The Naming of Identities (Die Benennung von Identitäten)​

Die Architektur unterscheidet zwischen Entitäten (die Implementierungen sind) und Identitäten (die Benutzer oder Principals repräsentieren).

3.2.1. Principal​

Ein Principal ist ein Benutzer oder System, in dessen Namen eine SNMP-Nachricht gesendet oder empfangen wird. Der Principal ist die ultimative Autoritätsquelle für eine SNMP-Operation.

3.2.2. securityName​

Ein securityName ist eine für Menschen lesbare Zeichenkette, die einen Principal repräsentiert. Es ist der sicherheitsmodellunabhängige Identifikator für einen Benutzer.

Der securityName wird vom Access Control Subsystem verwendet, um zu bestimmen, ob eine Operation erlaubt werden sollte. Verschiedene Security Models können unterschiedliche Formate zur Darstellung des Principals verwenden, aber alle müssen in der Lage sein, einen securityName zu erzeugen, der vom Access Control Subsystem verwendet werden kann.

3.2.3. Model-dependent security ID (Modellabhängige Sicherheits-ID)​

Eine modellabhängige Sicherheits-ID ist die Security Model-spezifische Darstellung eines Principals. Beispielsweise ist die modellabhängige Sicherheits-ID im User-based Security Model ein userName.

Das Security Model ist verantwortlich für die Übersetzung zwischen der modellabhängigen Sicherheits-ID und dem securityName.

3.3. The Naming of Management Information (Die Benennung von Verwaltungsinformationen)​

Verwaltungsinformationen sind in Sammlungen verwandter Objekte organisiert. Die Architektur bietet Mechanismen zum Benennen und Identifizieren dieser Sammlungen.

3.3.1. An SNMP Context (Ein SNMP-Kontext)​

Ein SNMP-Kontext ist eine Sammlung von Verwaltungsinformationen, auf die eine SNMP-Entität zugreifen kann. Eine SNMP-Entität kann Zugriff auf mehrere Kontexte haben.

Die Verwendung von Kontexten ermöglicht es einem einzelnen SNMP-Agenten, Verwaltungsinformationen von mehreren Geräten oder Subsystemen darzustellen. Beispielsweise könnte ein Proxy-Agent Verwaltungsinformationen von mehreren Geräten darstellen, wobei die Informationen jedes Geräts in einem separaten Kontext sind.

Kontexte werden durch eine contextEngineID und einen contextName identifiziert.

3.3.2. contextEngineID​

Die contextEngineID identifiziert eindeutig eine SNMP-Entität, die eine Instanz eines Kontexts mit einem bestimmten contextName realisieren kann. Dies ist typischerweise die snmpEngineID der SNMP-Engine, die Zugriff auf die Verwaltungsinformationen hat.

3.3.3. contextName​

Der contextName wird verwendet, um einen Kontext zu benennen. Es ist eine für Menschen lesbare Zeichenkette.

Zusammen identifizieren die contextEngineID und der contextName eindeutig eine Sammlung von Verwaltungsinformationen.

3.3.4. scopedPDU​

Ein scopedPDU ist ein PDU, der contextEngineID- und contextName-Felder enthält. Dies ermöglicht es dem PDU zu identifizieren, auf welchen Kontext die Operation angewendet wird.

Das scopedPDU wird in SNMPv3-Nachrichten verwendet. Es besteht aus:

  • contextEngineID
  • contextName
  • PDU (die tatsächliche Protocol Data Unit)

3.4. Other Constructs (Andere Konstrukte)​

3.4.1. maxSizeResponseScopedPDU​

Das maxSizeResponseScopedPDU ist die maximale Größe eines scopedPDU, das in einer Antwortnachricht gesendet werden kann. Dies wird während des Nachrichtenaustausches ausgehandelt und wird verwendet, um das Senden von Nachrichten zu vermeiden, die für die empfangende Entität zu groß sind, um sie zu verarbeiten.

3.4.2. Local Configuration Datastore (Lokaler Konfigurationsdatenspeicher)​

Der Local Configuration Datastore (LCD) ist ein konzeptionelles Repository von Konfigurationsinformationen. Er enthält Informationen, die von der SNMP-Engine benötigt werden, wie Sicherheitsparameter und Zugriffskontrollregeln.

Der LCD wird typischerweise unter Verwendung verwalteter Objekte implementiert, auf die mit SNMP zugegriffen und die modifiziert werden können. Die spezifischen verwalteten Objekte sind in verschiedenen MIB-Modulen definiert, wie SNMP-FRAMEWORK-MIB, SNMP-USER-BASED-SM-MIB und SNMP-VIEW-BASED-ACM-MIB.

3.4.3. securityLevel​

Das securityLevel gibt das Sicherheitsniveau an, das auf eine SNMP-Nachricht angewendet wird. Drei Sicherheitsniveaus sind definiert:

  1. noAuthNoPriv: Keine Authentifizierung und keine Vertraulichkeit
  2. authNoPriv: Authentifizierung aber keine Vertraulichkeit
  3. authPriv: Sowohl Authentifizierung als auch Vertraulichkeit

Das securityLevel wird von der Anwendung beim Senden einer Nachricht spezifiziert und vom Security Subsystem beim Empfang einer Nachricht bestimmt.

Letztes Update am