7. Considérations de sécurité

Le modèle de contrôle d'accès basé sur les vues fournit un contrôle d'accès pour les messages du protocole SNMP. Il permet à un administrateur de sécurité de configurer des droits d'accès pour des utilisateurs individuels ou des groupes d'utilisateurs afin d'avoir différents droits d'accès à différentes parties des informations de gestion dans différents contextes SNMP.

7.1. Pratiques recommandées

Il est RECOMMANDÉ que les implémenteurs et les administrateurs utilisent le modèle de contrôle d'accès basé sur les vues pour contrôler l'accès aux informations de gestion. Plus précisément :

1. Il est RECOMMANDÉ que les implémenteurs fournissent la capacité pour une configuration initial-minimum-secure comme décrit dans l'annexe A, avec un securityName qui n'est disponible que localement, et des droits d'accès restreints pour ce securityName.

2. Il est RECOMMANDÉ que les administrateurs configurent les droits d'accès selon les directives de ce document et qu'ils suivent les pratiques recommandées décrites dans l'annexe A.

3. Il est RECOMMANDÉ que la vacmViewTreeFamilyTable soit utilisée pour configurer des vues de lecture, d'écriture et de notification séparées pour chaque groupe, et que ces vues soient aussi restrictives que possible en cohérence avec les exigences de sécurité du réseau géré.

7.2. Définition des groupes

Un groupe est une collection de principaux (identifiés par securityNames), qui ont tous les mêmes droits d'accès en ce qui concerne la lecture, l'écriture et la réception de notifications concernant les objets MIB.

L'utilisation de groupes est administrativement pratique. En définissant des groupes puis en attribuant des droits d'accès aux groupes plutôt qu'aux principaux individuels, les administrateurs peuvent réduire le fardeau administratif.

Cependant, les administrateurs doivent utiliser les groupes avec prudence. L'attribution d'un securityName à un groupe accorde effectivement à ce securityName tous les droits d'accès autorisés à tout membre du groupe. En particulier :

1. Un securityName ne doit être attribué à un groupe que si l'administrateur de sécurité fait confiance que le principal associé à ce securityName n'abusera pas des droits d'accès accordés à ce groupe.

2. Étant donné que le securityLevel noAuthNoPriv ne fournit pas d'authentification, tous les principaux avec securityLevel noAuthNoPriv doivent être supposés avoir la même identité et doivent recevoir les mêmes droits d'accès (généralement très restreints).

7.3. Conformité

Notez que la conformité au modèle de contrôle d'accès basé sur les vues ne nécessite pas la prise en charge de la modification dynamique des droits d'accès. Les implémentations peuvent choisir de ne prendre en charge que l'accès en lecture seule aux tables de configuration, ou de ne prendre en charge la configuration que via des mécanismes locaux tels qu'une interface en ligne de commande ou un fichier texte. Cependant, l'utilisation d'un accès en lecture seule réduit la flexibilité et augmente le fardeau administratif.

Il est RECOMMANDÉ que les implémentations prennent en charge la modification dynamique des droits d'accès via SNMP, et qu'elles utilisent le modèle de sécurité basé sur l'utilisateur [RFC3414] avec authentification et confidentialité pour de telles modifications.

7.4. Accès à la SNMP-VIEW-BASED-ACM-MIB

Il est RECOMMANDÉ que les implémenteurs configurent la configuration initial-minimum-secure ou la configuration initial-semi-secure comme décrit dans l'annexe A, de sorte que l'accès à la SNMP-VIEW-BASED-ACM-MIB soit restreint aux utilisateurs authentifiés et autorisés.

En particulier, l'accès à la vacmSecurityToGroupTable, vacmAccessTable et vacmViewTreeFamilyTable doit être restreint, car ces tables contrôlent les droits d'accès à toutes les informations de gestion. Les modifications non autorisées de ces tables pourraient entraîner :

1. Un déni de service, en restreignant les droits d'accès légitimes.
2. La divulgation d'informations sensibles, en accordant un accès en lecture à des principaux non autorisés.
3. La modification d'informations de gestion par des principaux non autorisés, en accordant un accès en écriture.

Par conséquent, il est RECOMMANDÉ que :

1. L'accès en lecture à ces tables ne soit accordé qu'aux utilisateurs authentifiés et autorisés.
2. L'accès en écriture à ces tables ne soit accordé qu'aux utilisateurs authentifiés et autorisés qui nécessitent la capacité de reconfigurer le contrôle d'accès.
3. Lors de l'utilisation du modèle de sécurité basé sur l'utilisateur, l'authentification et la confidentialité soient utilisées pour tous les accès à ces tables.