2. Elemente des Modells

Dieser Abschnitt enthält Definitionen zur Realisierung des Zugriffskontr olldienstes, der vom View-based Access Control Model bereitgestellt wird.

2.1. Gruppen

Eine Gruppe ist eine Menge von null oder mehr <securityModel, securityName>-Tupeln, in deren Namen auf SNMP-Verwaltungsobjekte zugegriffen werden kann. Eine Gruppe definiert die Zugriffsrechte, die allen securityNames gewährt werden, die zu dieser Gruppe gehören. Die Kombination aus securityModel und securityName wird höchstens einer Gruppe zugeordnet. Eine Gruppe wird durch einen groupName identifiziert.

Das Access Control-Modul geht davon aus, dass der securityName bereits nach Bedarf authentifiziert wurde und bietet keine weitere eigene Authentifizierung.

Das View-based Access Control Model verwendet securityModel und securityName als Eingaben für das Access Control-Modul, wenn es aufgerufen wird, um Zugriffsrechte zu prüfen. Es bestimmt den groupName als Funktion von securityModel und securityName.

2.2. securityLevel

Für Mitglieder einer Gruppe können unterschiedliche Zugriffsrechte für verschiedene Sicherheitsstufen definiert werden, d.h. noAuthNoPriv, authNoPriv und authPriv. Der securityLevel identifiziert die Sicherheitsstufe, die bei der Prüfung von Zugriffsrechten angenommen wird. Siehe das SNMP Architecture-Dokument [RFC3411] für eine Definition von securityLevel.

Das View-based Access Control Model erfordert, dass der securityLevel als Eingabe an das Access Control-Modul übergeben wird, wenn es zur Prüfung von Zugriffsrechten aufgerufen wird.

2.3. Kontexte

Ein SNMP-Kontext ist eine Sammlung von Verwaltungsinformationen, auf die eine SNMP-Entität zugreifen kann. Ein Verwaltungsinformationselement kann in mehr als einem Kontext existieren. Eine SNMP-Entität kann potenziell auf viele Kontexte zugreifen. Details zur Benennung von Verwaltungsinformationen finden Sie im SNMP Architecture-Dokument [RFC3411].

Das View-based Access Control Model definiert eine vacmContextTable, die die lokal verfügbaren Kontexte nach contextName auflistet.

2.4. MIB-Views und View-Familien

Aus Sicherheitsgründen ist es oft wertvoll, die Zugriffsrechte einiger Gruppen auf nur eine Teilmenge der Verwaltungsinformationen in der Verwaltungsdomäne beschränken zu können. Um diese Fähigkeit bereitzustellen, erfolgt der Zugriff auf einen Kontext über eine "MIB-View", die einen bestimmten Satz verwalteter Objekttypen (und optional die spezifischen Instanzen von Objekttypen) innerhalb dieses Kontexts detailliert beschreibt. Zum Beispiel gibt es für einen bestimmten Kontext typischerweise immer eine MIB-View, die Zugriff auf alle Verwaltungsinformationen in diesem Kontext bietet, und oft gibt es andere MIB-Views, von denen jede eine Teilmenge der Informationen enthält. Der für eine Gruppe erlaubte Zugriff kann also durch die Verwendung von MIB-Views auf nur eine Teilmenge der Verwaltungsinformationen in diesem Kontext beschränkt werden.

Eine MIB-View wird als Sammlung von View-Subtrees definiert, wobei jeder View-Subtree ein Subtree im verwalteten Objektraum ist. Jeder View-Subtree wird durch den OBJECT IDENTIFIER der Wurzel des Subtrees zusammen mit einer Bitstring-Maske identifiziert. Die Bitstring-Maske ermöglicht es, den View-Subtree so zu definieren, dass einzelne Zweige des Subtrees eingeschlossen oder ausgeschlossen werden.

Eine Familie von View-Subtrees wird als die Menge aller MIB-Views definiert, die durch einen Satz verwandter View-Subtrees definiert werden können.

2.4.1. View-Subtree

Ein View-Subtree ist die Menge aller MIB-Objektinstanzen, die ein gemeinsames MIB-Objekttyp-OBJECT IDENTIFIER-Präfix haben. Der MIB-Objekttyp-OBJECT IDENTIFIER zusammen mit dem Instanzidentifikator für eine bestimmte Objektinstanz bildet den OBJECT IDENTIFIER-Namen für diese Objektinstanz.

Ein View-Subtree wird durch den OBJECT IDENTIFIER-Wert identifiziert, der das längste allen MIB-Objekttypen innerhalb dieses Subtrees gemeinsame OBJECT IDENTIFIER-Präfix ist. Wenn der Objekttyp keine Instanzen hat (z.B. eine Tabelle), dann ist der View-Subtree, der diesem Objekttyp entspricht, ein einzelner Zweig. Wenn der Objekttyp Instanzen hat, dann ist der View-Subtree, der diesem Objekttyp entspricht, ein Zweig, der die Menge aller Instanzen dieses Objekttyps ist. Wenn der Objekttyp eine Tabelle ist, dann ist der View-Subtree, der dieser Tabelle entspricht, ein Zweig, der alle Instanzen aller Spaltenobjekttypen dieser Tabelle enthält, d.h. alle Tabelleneinträge.

2.4.2. ViewTreeFamily

Eine Familie von View-Subtrees (viewTreeFamily) ist die Menge aller View-Subtrees, die bei der Definition einer MIB-View eingeschlossen (oder ausgeschlossen) würden.

Eine viewTreeFamily wird als Kombination aus einem View-Subtree (einem Subtree-Wert) zusammen mit einer Bitstring-Maske (einem Maskenwert) und einer Angabe definiert, ob der View-Subtree in eine MIB-View eingeschlossen oder aus ihr ausgeschlossen werden soll. Ein Familienmitglied ist die Menge von MIB-Objektinstanzen, die in einem bestimmten View-Subtree sind. Wenn der Maskenwert null Länge hat, dann ist das Familienmitglied identisch mit dem View-Subtree-Wert, d.h. ein einzelner View-Subtree. Wenn die Maske nicht null Länge hat, dann wird der View-Subtree-Wert mit dem Maskenwert gemäß dem folgenden Algorithmus kombiniert, um die Menge der Familienmitglieder zu bestimmen:

Für jeden möglichen OBJECT IDENTIFIER-Wert X, der durch Ersetzen 
der maskierten Bits des View-Subtree-Werts gebildet werden könnte:
    Wenn die maskierten Bits in X alle null sind,
        dann ist X ein Familienmitglied,
        sonst ist X kein Familienmitglied.

2.5. Zugriffsrichtlinie

Die VACM-Zugriffsrichtlinie wird durch eine Menge von Einträgen in der vacmAccessTable definiert. Jeder Eintrag in dieser Tabelle definiert Zugriffsrechte für eine bestimmte Kombination von:

• einer Gruppe (identifiziert durch groupName)
• einem Kontext (identifiziert durch contextName, möglicherweise unter Verwendung von Wildcarding über die Felder contextPrefix und contextMatch)
• einem securityModel
• einem securityLevel

Für jede solche Kombination definiert der Eintrag, welche MIB-Views für Lese-, Schreib- und Benachrichtigungszugriffsoperationen verwendet werden sollen. Jede solche MIB-View wird durch ihren viewName identifiziert.