Passa al contenuto principale

7. Considerazioni sulla sicurezza

Il modello di controllo degli accessi basato su viste fornisce il controllo degli accessi per i messaggi del protocollo SNMP. Consente a un amministratore di sicurezza di configurare i diritti di accesso per singoli utenti o gruppi di utenti per avere diversi diritti di accesso a diverse parti delle informazioni di gestione in diversi contesti SNMP.

7.1. Pratiche consigliate​

Si RACCOMANDA che gli implementatori e gli amministratori utilizzino il modello di controllo degli accessi basato su viste per controllare l'accesso alle informazioni di gestione. In particolare:

  1. Si RACCOMANDA che gli implementatori forniscano la capacità per una configurazione initial-minimum-secure come descritto nell'appendice A, con un securityName disponibile solo localmente e diritti di accesso limitati per quel securityName.

  2. Si RACCOMANDA che gli amministratori configurino i diritti di accesso secondo le linee guida di questo documento e che seguano le pratiche consigliate descritte nell'appendice A.

  3. Si RACCOMANDA che la vacmViewTreeFamilyTable venga utilizzata per configurare viste di lettura, scrittura e notifica separate per ciascun gruppo, e che queste viste siano il più restrittive possibile coerentemente con i requisiti di sicurezza della rete gestita.

7.2. Definizione dei gruppi​

Un gruppo è una raccolta di principali (identificati da securityNames), che hanno tutti gli stessi diritti di accesso per quanto riguarda la lettura, la scrittura e la ricezione di notifiche relative agli oggetti MIB.

L'uso dei gruppi è amministrativamente conveniente. Definendo gruppi e quindi assegnando diritti di accesso ai gruppi piuttosto che ai singoli principali, gli amministratori possono ridurre il carico amministrativo.

Tuttavia, gli amministratori dovrebbero usare i gruppi con cautela. L'assegnazione di un securityName a un gruppo concede effettivamente a quel securityName tutti i diritti di accesso consentiti a qualsiasi membro del gruppo. In particolare:

  1. Un securityName dovrebbe essere assegnato a un gruppo solo se l'amministratore di sicurezza confida che il principale associato a quel securityName non abuserà dei diritti di accesso concessi a quel gruppo.

  2. Poiché il securityLevel noAuthNoPriv non fornisce autenticazione, tutti i principali con securityLevel noAuthNoPriv dovrebbero essere considerati avere la stessa identità e dovrebbero ricevere gli stessi diritti di accesso (tipicamente molto limitati).

7.3. Conformità​

Si noti che la conformità al modello di controllo degli accessi basato su viste non richiede il supporto per la modifica dinamica dei diritti di accesso. Le implementazioni possono scegliere di supportare solo l'accesso in sola lettura alle tabelle di configurazione, o di supportare la configurazione solo tramite meccanismi locali come un'interfaccia a riga di comando o un file di testo. Tuttavia, l'uso dell'accesso in sola lettura riduce la flessibilità e aumenta il carico amministrativo.

Si RACCOMANDA che le implementazioni supportino la modifica dinamica dei diritti di accesso tramite SNMP, e che utilizzino il modello di sicurezza basato sull'utente [RFC3414] con autenticazione e privacy per tali modifiche.

7.4. Accesso alla SNMP-VIEW-BASED-ACM-MIB​

Si RACCOMANDA che gli implementatori configurino la configurazione initial-minimum-secure o la configurazione initial-semi-secure come descritto nell'appendice A, in modo che l'accesso alla SNMP-VIEW-BASED-ACM-MIB sia limitato agli utenti autenticati e autorizzati.

In particolare, l'accesso alla vacmSecurityToGroupTable, vacmAccessTable e vacmViewTreeFamilyTable dovrebbe essere limitato, poiché queste tabelle controllano i diritti di accesso a tutte le informazioni di gestione. Le modifiche non autorizzate a queste tabelle potrebbero comportare:

  1. Negazione del servizio, limitando i diritti di accesso legittimi.
  2. Divulgazione di informazioni sensibili, concedendo l'accesso in lettura a principali non autorizzati.
  3. Modifica delle informazioni di gestione da parte di principali non autorizzati, concedendo l'accesso in scrittura.

Pertanto, si RACCOMANDA che:

  1. L'accesso in lettura a queste tabelle sia concesso solo agli utenti autenticati e autorizzati.
  2. L'accesso in scrittura a queste tabelle sia concesso solo agli utenti autenticati e autorizzati che richiedono la capacità di riconfigurare il controllo degli accessi.
  3. Quando si utilizza il modello di sicurezza basato sull'utente, l'autenticazione e la privacy siano utilizzate per tutti gli accessi a queste tabelle.
Ultimo aggiornamento il