Zum Hauptinhalt springen

7. Sicherheitsüberlegungen

Das View-based Access Control Model bietet Zugriffskontrolle für SNMP-Protokollnachrichten. Es ermöglicht einem Sicherheitsadministrator, Zugriffsrechte für einzelne Benutzer oder Benutzergruppen zu konfigurieren, um unterschiedliche Zugriffsrechte auf verschiedene Teile der Verwaltungsinformationen in verschiedenen SNMP-Kontexten zu haben.

7.1. Empfohlene Praktiken​

Es wird EMPFOHLEN, dass Implementierer und Administratoren das View-based Access Control Model zur Kontrolle des Zugriffs auf Verwaltungsinformationen verwenden. Insbesondere:

  1. Es wird EMPFOHLEN, dass Implementierer die Fähigkeit für eine initial-minimum-secure-configuration wie in Anhang A beschrieben bereitstellen, mit einem securityName, der nur lokal verfügbar ist, und eingeschränkten Zugriffsrechten für diesen securityName.

  2. Es wird EMPFOHLEN, dass Administratoren Zugriffsrechte gemäß den Richtlinien in diesem Dokument konfigurieren und den in Anhang A beschriebenen empfohlenen Praktiken folgen.

  3. Es wird EMPFOHLEN, die vacmViewTreeFamilyTable zu verwenden, um separate Lese-, Schreib- und Benachrichtigungs-Views für jede Gruppe zu konfigurieren, und dass diese Views so restriktiv wie möglich sind, konsistent mit den Sicherheitsanforderungen des verwalteten Netzwerks.

7.2. Definieren von Gruppen​

Eine Gruppe ist eine Sammlung von Prinzipalen (identifiziert durch securityNames), die alle die gleichen Zugriffsrechte in Bezug auf Lesen, Schreiben und Empfangen von Benachrichtigungen über MIB-Objekte haben.

Die Verwendung von Gruppen ist administrativ bequem. Durch Definition von Gruppen und anschließende Zuweisung von Zugriffsrechten an Gruppen anstatt an einzelne Prinzipale können Administratoren die administrative Belastung reduzieren.

Allerdings sollten Administratoren Gruppen mit Vorsicht verwenden. Die Zuweisung eines securityName zu einer Gruppe gewährt diesem securityName effektiv alle Zugriffsrechte, die jedem Mitglied der Gruppe erlaubt sind. Insbesondere:

  1. Ein securityName sollte nur dann einer Gruppe zugewiesen werden, wenn der Sicherheitsadministrator vertraut, dass der mit diesem securityName verbundene Prinzipal die der Gruppe gewährten Zugriffsrechte nicht missbrauchen wird.

  2. Da der securityLevel noAuthNoPriv keine Authentifizierung bietet, sollte angenommen werden, dass alle Prinzipale mit securityLevel noAuthNoPriv dieselbe Identität haben und sollten dieselben (typischerweise sehr eingeschränkten) Zugriffsrechte erhalten.

7.3. Konformität​

Beachten Sie, dass die Konformität mit dem View-based Access Control Model keine Unterstützung für dynamische Änderung von Zugriffsrechten erfordert. Implementierungen können wählen, nur Lesezugriff auf die Konfigurationstabellen zu unterstützen oder nur Konfiguration über lokale Mechanismen wie eine Befehlszeilenschnittstelle oder Textdatei zu unterstützen. Die Verwendung von reinem Lesezugriff reduziert jedoch die Flexibilität und erhöht die administrative Belastung.

Es wird EMPFOHLEN, dass Implementierungen dynamische Änderung von Zugriffsrechten über SNMP unterstützen und dass sie das User-based Security Model [RFC3414] mit Authentifizierung und Privatsphäre für solche Änderungen verwenden.

7.4. Zugriff auf die SNMP-VIEW-BASED-ACM-MIB​

Es wird EMPFOHLEN, dass Implementierer die initial-minimum-secure-configuration oder die initial-semi-secure-configuration wie in Anhang A beschrieben konfigurieren, damit der Zugriff auf die SNMP-VIEW-BASED-ACM-MIB auf authentifizierte und autorisierte Benutzer beschränkt ist.

Insbesondere sollte der Zugriff auf die vacmSecurityToGroupTable, vacmAccessTable und vacmViewTreeFamilyTable eingeschränkt werden, da diese Tabellen die Zugriffsrechte auf alle Verwaltungsinformationen steuern. Nicht autorisierte Änderungen an diesen Tabellen könnten zu Folgendem führen:

  1. Dienstverweigerung durch Einschränkung legitimer Zugriffsrechte.
  2. Offenlegung sensibler Informationen durch Gewährung von Lesezugriff an nicht autorisierte Prinzipale.
  3. Änderung von Verwaltungsinformationen durch nicht autorisierte Prinzipale durch Gewährung von Schreibzugriff.

Daher wird EMPFOHLEN, dass:

  1. Lesezugriff auf diese Tabellen nur authentifizierten und autorisierten Benutzern gewährt wird.
  2. Schreibzugriff auf diese Tabellen nur authentifizierten und autorisierten Benutzern gewährt wird, die die Fähigkeit zur Neukonfiguration der Zugriffskontrolle benötigen.
  3. Bei Verwendung des User-based Security Model Authentifizierung und Privatsphäre für alle Zugriffe auf diese Tabellen verwendet werden.
Letztes Update am