Aller au contenu principal

Appendix A. Guidelines for Model Designers (Annexe A. Directives pour les concepteurs de modèles)

Appendix A. Guidelines for Model Designers (Annexe A. Directives pour les concepteurs de modèles)​

Cette annexe fournit des directives pour les concepteurs de modèles de sécurité, de modèles de traitement des messages, de modèles de contrôle d'accès et d'applications SNMP. Ces directives sont informatives et visent à aider les implémenteurs à créer des composants qui fonctionnent correctement dans l'architecture SNMP.

A.1. Security Model Design Requirements (Exigences de conception du modèle de sécurité)​

Un modèle de sécurité doit fournir des mécanismes pour l'authentification, la confidentialité et la vérification de l'actualité. Cette section décrit les exigences pour les modèles de sécurité.

A.1.1. Threats (Menaces)​

Les modèles de sécurité doivent traiter les menaces suivantes:

  1. Modification des informations: Une entité non autorisée modifiant les messages en transit

    • Un modèle de sécurité doit fournir des services d'intégrité des données pour détecter une telle modification

  2. Mascarade: Une entité non autorisée assumant l'identité d'une entité autorisée

    • Un modèle de sécurité doit fournir des services d'authentification pour vérifier l'identité

  3. Modification du flux de messages: Réorganisation, retard ou rejeu de messages

    • Un modèle de sécurité doit fournir une vérification de l'actualité pour détecter de telles attaques

  4. Divulgation: Libération du contenu des messages à une entité non autorisée

    • Un modèle de sécurité peut éventuellement fournir des services de confidentialité par le chiffrement

A.1.2. Security Processing (Traitement de la sécurité)​

Un modèle de sécurité doit implémenter les primitives de service abstraites suivantes:

  1. generateRequestMsg: Appliquer un traitement de sécurité aux messages de requête et de notification sortants

    • Entrée: scopedPDU, paramètres de sécurité
    • Sortie: message sécurisé prêt pour la transmission
    • Traitement:
      • Appliquer l'authentification (si requis par le niveau de sécurité)
      • Appliquer le chiffrement (si requis par le niveau de sécurité)
      • Ajouter des paramètres de sécurité au message
      • S'assurer que le message est protégé selon securityLevel

  2. processIncomingMsg: Traiter la sécurité des messages entrants

    • Entrée: message reçu
    • Sortie: scopedPDU extraite, paramètres de sécurité
    • Traitement:
      • Vérifier l'authentification (si le message prétend être authentifié)
      • Déchiffrer le message (si le message est chiffré)
      • Vérifier l'actualité (pour empêcher les attaques par rejeu)
      • Extraire la scopedPDU
      • Mettre en cache l'état de sécurité si une réponse peut être nécessaire

  3. generateResponseMsg: Appliquer un traitement de sécurité aux messages de réponse sortants

    • Entrée: scopedPDU, état de sécurité en cache
    • Sortie: message de réponse sécurisé
    • Traitement:
      • Récupérer les paramètres de sécurité de l'état en cache
      • Appliquer le même niveau de sécurité que la requête
      • Appliquer l'authentification (si requis)
      • Appliquer le chiffrement (si requis)

A.1.3. Validate the security-stamp in a received message (Valider le tampon de sécurité dans un message reçu)​

Un modèle de sécurité doit valider que:

  1. L'authentification est valide: Si le message prétend être authentifié, vérifier le code d'authentification

    • Utiliser une vérification cryptographique appropriée (par exemple, vérification HMAC)
    • Rejeter les messages avec une authentification invalide

  2. Le message est actuel: Vérifier que le message n'est pas un rejeu

    • Vérifier les paramètres de timing du message
    • Maintenir un état pour détecter les rejeux
    • Rejeter les messages en dehors de la fenêtre temporelle

  3. La confidentialité est appliquée correctement: Si le message est chiffré, vérifier qu'il peut être déchiffré

    • Tenter le déchiffrement à l'aide de clés appropriées
    • Vérifier que le déchiffrement a réussi
    • Rejeter les messages qui ne peuvent pas être déchiffrés

  4. Le niveau de sécurité correspond aux exigences: Vérifier que la sécurité réellement appliquée correspond à ce qui a été demandé

    • Vérifier que les messages authNoPriv sont authentifiés mais non chiffrés
    • Vérifier que les messages authPriv sont à la fois authentifiés et chiffrés
    • Vérifier que les messages noAuthNoPriv ne sont ni authentifiés ni chiffrés

A.1.4. Security MIBs (MIB de sécurité)​

Un modèle de sécurité devrait définir un module MIB qui permet:

  1. Configuration des paramètres de sécurité: Utilisateurs, clés, protocoles d'authentification, protocoles de confidentialité
  2. Surveillance de la sécurité: Compteurs pour les échecs d'authentification, les erreurs de déchiffrement, etc.
  3. Configuration à distance: Mécanismes sécurisés pour configurer la sécurité à distance

Le modèle de sécurité basé sur l'utilisateur (USM) définit le SNMP-USER-BASED-SM-MIB à cette fin.

A.1.5. Cached Security Data (Données de sécurité en cache)​

Lors du traitement d'une requête entrante qui peut nécessiter une réponse, un modèle de sécurité doit mettre en cache les informations d'état de sécurité. Ces données en cache permettent de sécuriser la réponse en utilisant les mêmes paramètres de sécurité que la requête.

Les données de sécurité en cache incluent généralement:

  • Paramètres de sécurité de la requête
  • Clés utilisées pour l'authentification et/ou le chiffrement
  • Paramètres de timing
  • Tout autre état nécessaire pour générer une réponse

Le modèle de sécurité doit:

  1. Générer une securityStateReference: Un identifiant unique pour l'état en cache
  2. Retourner la securityStateReference: Au modèle de traitement des messages
  3. Récupérer l'état en cache: Lorsque generateResponseMsg est appelé
  4. Libérer l'état en cache: Après la génération de la réponse ou lorsqu'il est explicitement libéré

L'état en cache peut être implicitement libéré lorsque:

  • Une réponse a été générée avec succès
  • Une erreur se produit et aucune réponse ne sera envoyée
  • Un délai d'attente se produit

L'état en cache peut être explicitement libéré à l'aide de la primitive stateRelease.

A.2. Message Processing Model Design Requirements (Exigences de conception du modèle de traitement des messages)​

Un modèle de traitement des messages définit un format de message et les procédures de traitement des messages dans ce format. Cette section décrit les exigences pour les modèles de traitement des messages.

A.2.1. Receiving an SNMP Message from the Network (Réception d'un message SNMP du réseau)​

Lorsqu'un message est reçu du réseau, le répartiteur détermine quel modèle de traitement des messages doit le traiter (en fonction de la version ou du format du message). Le modèle de traitement des messages doit implémenter la primitive prepareDataElements.

Traitement prepareDataElements:

  1. Analyser le format du message: Extraire les divers composants du message

    • En-tête du message
    • Paramètres de sécurité
    • Scoped PDU ou charge utile

  2. Déterminer le modèle de sécurité: Identifier quel modèle de sécurité a été utilisé

    • Généralement indiqué dans l'en-tête du message

  3. Appeler le modèle de sécurité: Invoquer processIncomingMsg pour:

    • Vérifier l'authentification
    • Déchiffrer le message
    • Vérifier l'actualité
    • Extraire la scoped PDU

  4. Analyser la scoped PDU: Extraire:

    • contextEngineID
    • contextName
    • PDU

  5. Mettre en cache l'état si nécessaire: Si c'est une requête qui peut nécessiter une réponse:

    • Mettre en cache les informations nécessaires pour générer la réponse
    • Générer une stateReference
    • Associer la stateReference aux données en cache

  6. Retourner les éléments de données extraits: Retourner toutes les informations nécessaires au répartiteur:

    • messageProcessingModel
    • securityModel
    • securityName
    • securityLevel
    • contextEngineID
    • contextName
    • pduVersion
    • PDU
    • pduType
    • maxSizeResponseScopedPDU
    • stateReference
    • statusInformation

Gestion des erreurs:

Si une étape échoue, retourner des statusInformation d'erreur appropriées au répartiteur. Ne pas transmettre de messages malformés ou non authentifiés aux applications.

A.2.2. Sending an SNMP Message to the Network (Envoi d'un message SNMP au réseau)​

Lors de l'envoi d'un message, le répartiteur appelle soit prepareOutgoingMessage (pour les requêtes et les notifications) soit prepareResponseMessage (pour les réponses). Le modèle de traitement des messages doit implémenter ces primitives.

Traitement prepareOutgoingMessage:

  1. Créer une scoped PDU: Combiner contextEngineID, contextName et PDU

  2. Appeler le modèle de sécurité: Invoquer generateRequestMsg pour:

    • Appliquer l'authentification (si requis)
    • Appliquer le chiffrement (si requis)
    • Ajouter des paramètres de sécurité

  3. Créer le message: Emballer la charge utile sécurisée dans le format de message approprié

    • Ajouter l'en-tête du message
    • Ajouter l'identifiant de version ou de format
    • Ajouter les champs spécifiques au message

  4. Retourner le message complet: Retourner le message formaté prêt pour la transmission:

    • outgoingMessage
    • outgoingMessageLength
    • statusInformation

Traitement prepareResponseMessage:

Similaire à prepareOutgoingMessage, mais:

  1. Récupérer l'état en cache: Utiliser la stateReference pour récupérer les informations en cache

  2. Créer une scoped PDU: Combiner contextEngineID, contextName et PDU (de la requête originale)

  3. Appeler le modèle de sécurité: Invoquer generateResponseMsg avec:

    • La scoped PDU
    • La securityStateReference (pour utiliser les mêmes paramètres de sécurité que la requête)

  4. Créer le message de réponse: Emballer la charge utile sécurisée dans le format approprié

  5. Libérer l'état en cache: Après avoir créé avec succès la réponse, libérer l'état en cache

  6. Retourner la réponse complète: Retourner le message de réponse formaté

Gestion des erreurs:

Si une étape échoue, retourner des statusInformation d'erreur appropriées. Si une réponse ne peut pas être générée, s'assurer que l'état en cache est libéré.

A.3. Application Design Requirements (Exigences de conception des applications)​

Les applications SNMP utilisent les services du moteur SNMP pour exécuter des fonctions de gestion. Cette section décrit les exigences et les directives pour la conception des applications.

A.3.1. Applications that Initiate Messages (Applications qui initient des messages)​

Les applications qui initient des messages (Command Generators, Notification Originators) doivent:

  1. Déterminer la destination: Identifier le moteur SNMP cible

    • transportDomain
    • transportAddress
    • contextEngineID

  2. Déterminer les paramètres de sécurité:

    • securityModel
    • securityName
    • securityLevel

  3. Créer la PDU: Construire l'unité de données de protocole avec l'opération et les variables souhaitées

  4. Appeler sendPdu: Invoquer la primitive sendPdu du répartiteur avec:

    • Informations de destination
    • Paramètres de sécurité
    • contextEngineID et contextName
    • PDU
    • Drapeau expectResponse
    • sendPduHandle (pour corréler la réponse ultérieure)

  5. Gérer la réponse: Si expectResponse était TRUE, implémenter processResponsePdu pour recevoir la réponse

Directives:

  • Configurer les destinations: Utiliser des mécanismes de configuration (par exemple, SNMP-TARGET-MIB) pour gérer les informations de destination
  • Configurer la sécurité: Utiliser des mécanismes de configuration (par exemple, SNMP-USER-BASED-SM-MIB) pour gérer les paramètres de sécurité
  • Gérer les erreurs: Gérer correctement les erreurs statusInformation de sendPdu
  • Implémenter les délais d'attente: Si aucune réponse n'est reçue dans un délai raisonnable, gérer le délai d'attente
  • Implémenter les nouvelles tentatives: Envisager de retransmettre si aucune réponse n'est reçue

A.3.2. Applications that Receive Responses (Applications qui reçoivent des réponses)​

Les applications qui reçoivent des réponses doivent implémenter la primitive processResponsePdu.

Implémentation processResponsePdu:

  1. Corréler la réponse: Utiliser le sendPduHandle pour faire correspondre la réponse à la requête originale

  2. Vérifier statusInformation: Vérifier que le traitement du message a réussi

  3. Traiter la PDU: Extraire et traiter les données de réponse

    • Vérifier error-status et error-index
    • Extraire les liaisons de variables
    • Effectuer un traitement spécifique à l'application

Directives:

  • Gérer les erreurs: Vérifier les erreurs SNMP (par exemple, noSuchName, tooBig, genErr)
  • Gérer les exceptions: Vérifier les valeurs d'exception (noSuchObject, noSuchInstance, endOfMibView)
  • Gérer les erreurs de sécurité: Être préparé aux échecs d'authentification ou de confidentialité
  • Nettoyer l'état: Libérer toutes les ressources associées à la requête

A.3.3. Applications that Receive Asynchronous Messages (Applications qui reçoivent des messages asynchrones)​

Les applications qui reçoivent des messages asynchrones (Command Responders, Notification Receivers) doivent:

  1. S'enregistrer auprès du répartiteur: Appeler registerContextEngineID pour s'enregistrer pour:

    • Des valeurs contextEngineID spécifiques
    • Des types de PDU spécifiques

  2. Implémenter processPdu: Recevoir et traiter les PDU entrantes

    • Valider contextEngineID et contextName
    • Traiter la PDU selon la sémantique de l'application
    • Générer une réponse (si requis)

Implémentation processPdu:

  1. Valider le contexte: S'assurer que cette application est responsable du contextEngineID et contextName

  2. Vérifier le contrôle d'accès (si approprié): Appeler isAccessAllowed pour chaque variable dans la PDU

  3. Traiter la requête: Effectuer l'opération demandée

    • Pour GET: récupérer les valeurs des variables
    • Pour SET: modifier les valeurs des variables
    • Pour GETNEXT: trouver la variable lexicographiquement suivante
    • Pour GETBULK: récupérer plusieurs variables efficacement

  4. Construire la PDU de réponse (si requis): Créer une PDU de réponse avec les résultats

  5. Appeler returnResponsePdu (si requis): Renvoyer la réponse au demandeur

Directives:

  • Valider l'entrée: Valider soigneusement toutes les entrées pour prévenir les vulnérabilités de sécurité
  • Implémenter le contrôle d'accès: Appliquer un contrôle d'accès approprié à toutes les opérations
  • Gérer les erreurs avec élégance: Retourner des réponses d'erreur appropriées pour les requêtes invalides
  • Respecter maxSizeResponseScopedPDU: S'assurer que la réponse ne dépasse pas la limite de taille
  • Utiliser stateReference: Passer la stateReference de processPdu à returnResponsePdu sans modification

A.3.4. Applications that Send Responses (Applications qui envoient des réponses)​

Les applications qui envoient des réponses doivent utiliser la primitive returnResponsePdu.

Utilisation de returnResponsePdu:

  1. Utiliser les paramètres de processPdu: Transmettre:

    • messageProcessingModel
    • securityModel
    • securityName
    • securityLevel
    • contextEngineID
    • contextName
    • pduVersion
    • maxSizeResponseScopedPDU
    • stateReference

  2. Créer la PDU de réponse: Construire la PDU contenant les résultats

  3. Appeler returnResponsePdu: Invoquer la primitive returnResponsePdu du répartiteur

Directives:

  • Ne pas modifier les paramètres de sécurité: Utiliser les mêmes paramètres de sécurité que la requête
  • Respecter les limites de taille: S'assurer que la réponse tient dans maxSizeResponseScopedPDU
  • Gérer les erreurs: Si la réponse ne peut pas être envoyée, gérer l'erreur de manière appropriée
  • Libérer l'état: La stateReference sera libérée par le répartiteur après l'envoi de la réponse

A.4. Access Control Model Design Requirements (Exigences de conception du modèle de contrôle d'accès)​

Un modèle de contrôle d'accès détermine si l'accès à un objet géré doit être autorisé. Cette section décrit les exigences pour les modèles de contrôle d'accès.

Un modèle de contrôle d'accès doit implémenter la primitive isAccessAllowed.

Implémentation isAccessAllowed:

  1. Déterminer le principal: Identifier qui tente l'accès

    • Utiliser securityModel et securityName

  2. Déterminer le type d'accès: Identifier quel type d'accès est demandé

    • read: GET, GETNEXT, GETBULK
    • write: SET
    • notify: TRAP, INFORM

  3. Déterminer la cible: Identifier quel objet est accédé

    • variableName (OID)
    • contextName

  4. Appliquer la politique de contrôle d'accès: En fonction de la politique configurée, déterminer si l'accès doit être autorisé

  5. Retourner le résultat: Retourner autorisé ou refusé

Directives:

  • Définir une MIB: Définir un module MIB pour configurer la politique de contrôle d'accès
  • Prendre en charge la configuration à distance: Permettre la configuration de la politique via SNMP
  • Refus par défaut: Si aucune politique explicite n'autorise l'accès, refuser par défaut
  • Implémentation efficace: Le contrôle d'accès peut être appelé plusieurs fois par requête; implémenter efficacement
  • Politique cohérente: S'assurer que la politique est appliquée de manière cohérente

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

Dernière mise à jour le