Aller au contenu principal

3. Elements of the Architecture (Éléments de l'architecture)

3. Elements of the Architecture (Éléments de l'architecture)​

Cette section décrit les éléments qui composent l'architecture SNMP. L'architecture est conçue autour du concept d'un moteur SNMP, qui fournit des services à une ou plusieurs applications SNMP.

3.1. The Naming of Entities (Le nommage des entités)​

Plusieurs types d'entités sont identifiés dans l'architecture:

  • Moteur SNMP: Une implémentation des services définis dans cette architecture. Un moteur SNMP fournit des services de traitement des messages, de sécurité et de contrôle d'accès.

  • Entité SNMP: Un moteur SNMP plus une ou plusieurs applications SNMP. Une entité SNMP peut agir comme un agent, un gestionnaire ou les deux.

  • Agent SNMP: Une entité SNMP qui fournit un accès aux informations de gestion. Un agent s'exécute généralement sur un périphérique géré.

  • Gestionnaire SNMP: Une entité SNMP qui initie des requêtes SNMP et traite les réponses et notifications SNMP. Un gestionnaire s'exécute généralement sur une station de gestion.

3.1.1. SNMP engine (Moteur SNMP)​

Un moteur SNMP est une implémentation des services de traitement des messages, de sécurité et de contrôle d'accès SNMP. Un moteur SNMP est identifié de manière unique par un snmpEngineID.

3.1.1.1. snmpEngineID​

Le snmpEngineID est une OCTET STRING qui identifie de manière unique un moteur SNMP. Le snmpEngineID est attribué administrativement et doit être choisi pour être unique parmi tous les moteurs SNMP du réseau.

Le format du snmpEngineID est conçu pour garantir l'unicité. Il comprend généralement un numéro d'entreprise et des informations d'identification supplémentaires telles qu'une adresse MAC, une adresse IP ou une valeur attribuée administrativement.

Le snmpEngineID remplit plusieurs objectifs importants:

  1. Il identifie le moteur SNMP qui a émis un message
  2. Il identifie le moteur SNMP dont les objets gérés sont accédés
  3. Il sert de clé pour les informations de sécurité
  4. Il sert de clé pour les paramètres de sécurité localisés
3.1.1.2. Dispatcher (Répartiteur)​

Le répartiteur est responsable de:

  1. Recevoir les messages du réseau et déterminer la version du message
  2. Router les messages vers le modèle de traitement des messages approprié
  3. Router les PDU vers l'application SNMP appropriée
  4. Envoyer les messages au réseau

Le répartiteur fournit des interfaces de service abstraites aux applications et aux sous-systèmes du moteur SNMP.

3.1.1.3. Message Processing Subsystem (Sous-système de traitement des messages)​

Le sous-système de traitement des messages est responsable de la préparation des messages pour la transmission et de l'extraction des données des messages reçus.

Le sous-système de traitement des messages peut contenir plusieurs modèles de traitement des messages. Chaque modèle de traitement des messages définit un format de message et les procédures pour traiter ce format de message.

3.1.1.3.1. Message Processing Model (Modèle de traitement des messages)​

Un modèle de traitement des messages définit un format de message et les procédures pour traiter ce format de message. Différents modèles de traitement des messages peuvent coexister au sein d'un seul moteur SNMP.

Les modèles de traitement des messages standard incluent:

  • SNMPv1: Défini dans RFC 3584
  • SNMPv2c: Défini dans RFC 3584
  • SNMPv3: Défini dans RFC 3412

Chaque modèle de traitement des messages est identifié par une valeur messageProcessingModel unique.

3.1.1.4. Security Subsystem (Sous-système de sécurité)​

Le sous-système de sécurité fournit des services de sécurité tels que l'authentification, la confidentialité et la vérification de l'actualité.

Le sous-système de sécurité peut contenir plusieurs modèles de sécurité. Chaque modèle de sécurité définit un ensemble de protocoles de sécurité et les procédures pour les appliquer.

3.1.1.4.1. Security Model (Modèle de sécurité)​

Un modèle de sécurité définit un ensemble de protocoles de sécurité et les procédures pour les appliquer aux messages SNMP. Différents modèles de sécurité peuvent coexister au sein d'un seul moteur SNMP.

Les modèles de sécurité standard incluent:

  • Modèle de sécurité basé sur l'utilisateur (USM): Défini dans RFC 3414, fournit l'authentification et la confidentialité en utilisant la cryptographie symétrique
  • Modèle de sécurité basé sur la communauté: Utilisé avec SNMPv1 et SNMPv2c, défini dans RFC 3584

Chaque modèle de sécurité est identifié par une valeur securityModel unique.

3.1.1.4.2. Security Protocol (Protocole de sécurité)​

Un protocole de sécurité est un algorithme cryptographique spécifique utilisé par un modèle de sécurité. Par exemple, le modèle de sécurité basé sur l'utilisateur prend en charge plusieurs protocoles d'authentification (HMAC-MD5-96, HMAC-SHA-96) et plusieurs protocoles de confidentialité (CBC-DES, CBC-AES).

3.1.2. Access Control Subsystem (Sous-système de contrôle d'accès)​

Le sous-système de contrôle d'accès détermine si une opération SNMP particulière doit être autorisée. Il prend cette décision en fonction de l'identité de l'utilisateur, du type d'opération et de l'objet géré accédé.

Le sous-système de contrôle d'accès peut contenir plusieurs modèles de contrôle d'accès. Chaque modèle de contrôle d'accès définit une politique pour prendre des décisions de contrôle d'accès.

3.1.2.1. Access Control Model (Modèle de contrôle d'accès)​

Un modèle de contrôle d'accès définit une politique pour déterminer si l'accès à un objet géré doit être accordé. Différents modèles de contrôle d'accès peuvent coexister au sein d'un seul moteur SNMP.

Le modèle de contrôle d'accès standard est le modèle de contrôle d'accès basé sur les vues (VACM), défini dans RFC 3415.

Chaque modèle de contrôle d'accès est identifié par une valeur accessControlModel unique.

3.1.3. Applications​

Les applications SNMP utilisent les services du moteur SNMP pour exécuter des fonctions de gestion. Une entité SNMP peut contenir plusieurs applications.

3.1.3.1. SNMP Manager (Gestionnaire SNMP)​

Un gestionnaire SNMP est une entité SNMP qui initie des requêtes SNMP et traite les réponses et notifications SNMP. Un gestionnaire contient généralement les types d'applications suivants:

  • Générateur de commandes: Initie les opérations Get, GetNext, GetBulk et Set
  • Récepteur de notifications: Reçoit les opérations Trap et InformRequest

Un gestionnaire peut également contenir une application de transmetteur proxy, qui transmet les messages SNMP à d'autres entités SNMP.

3.1.3.2. SNMP Agent (Agent SNMP)​

Un agent SNMP est une entité SNMP qui fournit un accès aux informations de gestion. Un agent contient généralement les types d'applications suivants:

  • Répondeur de commandes: Répond aux opérations Get, GetNext, GetBulk et Set
  • Générateur de notifications: Initie les opérations Trap et InformRequest

Un agent peut également contenir une application de transmetteur proxy, qui transmet les messages SNMP à d'autres entités SNMP.

Un agent contient l'instrumentation, qui est le logiciel qui fournit un accès aux objets gérés réels. L'instrumentation traduit entre les opérations SNMP et les opérations nécessaires pour accéder aux objets gérés sous-jacents.

3.2. The Naming of Identities (Le nommage des identités)​

L'architecture distingue les entités (qui sont des implémentations) et les identités (qui représentent les utilisateurs ou les principaux).

3.2.1. Principal​

Un principal est un utilisateur ou un système au nom duquel un message SNMP est envoyé ou reçu. Le principal est la source ultime d'autorité pour une opération SNMP.

3.2.2. securityName​

Un securityName est une chaîne lisible par l'homme représentant un principal. C'est l'identificateur indépendant du modèle de sécurité pour un utilisateur.

Le securityName est utilisé par le sous-système de contrôle d'accès pour déterminer si une opération doit être autorisée. Différents modèles de sécurité peuvent utiliser différents formats pour représenter le principal, mais tous doivent être capables de produire un securityName pouvant être utilisé par le sous-système de contrôle d'accès.

3.2.3. Model-dependent security ID (ID de sécurité dépendant du modèle)​

Un ID de sécurité dépendant du modèle est la représentation spécifique au modèle de sécurité d'un principal. Par exemple, dans le modèle de sécurité basé sur l'utilisateur, l'ID de sécurité dépendant du modèle est un userName.

Le modèle de sécurité est responsable de la traduction entre l'ID de sécurité dépendant du modèle et le securityName.

3.3. The Naming of Management Information (Le nommage des informations de gestion)​

Les informations de gestion sont organisées en collections d'objets connexes. L'architecture fournit des mécanismes pour nommer et identifier ces collections.

3.3.1. An SNMP Context (Un contexte SNMP)​

Un contexte SNMP est une collection d'informations de gestion accessible par une entité SNMP. Une entité SNMP peut avoir accès à plusieurs contextes.

L'utilisation de contextes permet à un seul agent SNMP de représenter les informations de gestion de plusieurs périphériques ou sous-systèmes. Par exemple, un agent proxy peut représenter les informations de gestion de plusieurs périphériques, les informations de chaque périphérique étant dans un contexte séparé.

Les contextes sont identifiés par un contextEngineID et un contextName.

3.3.2. contextEngineID​

Le contextEngineID identifie de manière unique une entité SNMP qui peut réaliser une instance d'un contexte avec un contextName particulier. Il s'agit généralement du snmpEngineID du moteur SNMP qui a accès aux informations de gestion.

3.3.3. contextName​

Le contextName est utilisé pour nommer un contexte. C'est une chaîne lisible par l'homme.

Ensemble, le contextEngineID et le contextName identifient de manière unique une collection d'informations de gestion.

3.3.4. scopedPDU​

Un scopedPDU est un PDU qui inclut les champs contextEngineID et contextName. Cela permet au PDU d'identifier à quel contexte l'opération s'applique.

Le scopedPDU est utilisé dans les messages SNMPv3. Il se compose de:

  • contextEngineID
  • contextName
  • PDU (l'unité de données de protocole réelle)

3.4. Other Constructs (Autres constructions)​

3.4.1. maxSizeResponseScopedPDU​

Le maxSizeResponseScopedPDU est la taille maximale d'un scopedPDU qui peut être envoyé dans un message de réponse. Ceci est négocié pendant l'échange de messages et est utilisé pour éviter d'envoyer des messages trop volumineux pour que l'entité réceptrice puisse les traiter.

3.4.2. Local Configuration Datastore (Magasin de données de configuration local)​

Le magasin de données de configuration local (LCD) est un référentiel conceptuel d'informations de configuration. Il contient les informations nécessaires au moteur SNMP, telles que les paramètres de sécurité et les règles de contrôle d'accès.

Le LCD est généralement implémenté en utilisant des objets gérés qui peuvent être accédés et modifiés en utilisant SNMP. Les objets gérés spécifiques sont définis dans divers modules MIB, tels que SNMP-FRAMEWORK-MIB, SNMP-USER-BASED-SM-MIB et SNMP-VIEW-BASED-ACM-MIB.

3.4.3. securityLevel​

Le securityLevel indique le niveau de sécurité appliqué à un message SNMP. Trois niveaux de sécurité sont définis:

  1. noAuthNoPriv: Pas d'authentification et pas de confidentialité
  2. authNoPriv: Authentification mais pas de confidentialité
  3. authPriv: Authentification et confidentialité

Le securityLevel est spécifié par l'application lors de l'envoi d'un message et est déterminé par le sous-système de sécurité lors de la réception d'un message.

Dernière mise à jour le