Aller au contenu principal

1.6. Abstract Service Interfaces (Interfaces de service abstraites)

1.6. Abstract Service Interfaces (Interfaces de service abstraites)​

Le modèle de sécurité basé sur l'utilisateur est conçu pour s'intégrer à l'architecture SNMPv3 via des interfaces de service abstraites bien définies. Ces interfaces permettent à l'USM de fonctionner indépendamment des autres sous-systèmes tout en fournissant les services de sécurité nécessaires.

Security Model Interface (Interface de modèle de sécurité)​

L'USM implémente l'interface de modèle de sécurité définie dans la RFC 3411. Cette interface se compose de deux primitives principales:

1. generateRequestMsg (Générer un message de requête)​

Objectif (Purpose): Traiter un message SNMP sortant en ajoutant des informations liées à la sécurité.

Entrées (Inputs):

  • messageProcessingModel: La version SNMP (3 pour SNMPv3)
  • globalData: Informations d'en-tête de message global
  • maxMessageSize: Taille maximale de message prise en charge
  • securityModel: Identifiant du modèle de sécurité (3 pour USM)
  • securityEngineID: L'identifiant du moteur SNMP autorisé
  • securityName: Le principal au nom duquel le message est généré
  • securityLevel: Le niveau de sécurité souhaité (noAuthNoPriv, authNoPriv, ou authPriv)
  • scopedPDU: La charge utile du message à sécuriser

Sorties (Outputs):

  • securityParameters: Paramètres de sécurité spécifiques à l'USM (engineID, engineBoots, engineTime, userName, paramètres d'authentification, paramètres de confidentialité)
  • wholeMsg: Le message sécurisé complet prêt pour la transmission
  • statusInformation: Indication de succès ou d'erreur

Traitement (Processing):

  1. Valider les entrées
  2. Récupérer les clés d'authentification et de confidentialité de l'utilisateur
  3. Incrémenter et inclure engineBoots et engineTime
  4. Appliquer le protocole de confidentialité si securityLevel inclut la confidentialité
  5. Calculer le résumé d'authentification si securityLevel inclut l'authentification
  6. Assembler le message complet

2. processIncomingMsg (Traiter un message entrant)​

Objectif (Purpose): Traiter un message SNMP entrant en vérifiant les informations liées à la sécurité.

Entrées (Inputs):

  • messageProcessingModel: La version SNMP
  • maxMessageSize: Taille maximale de message prise en charge
  • securityParameters: Les paramètres de sécurité USM reçus
  • securityModel: Identifiant du modèle de sécurité
  • securityLevel: Le niveau de sécurité attendu
  • wholeMsg: Le message complet reçu
  • securityEngineID: L'identifiant du moteur autorisé (du message)

Sorties (Outputs):

  • securityName: Le principal authentifié
  • scopedPDU: La charge utile du message décryptée et vérifiée
  • maxSizeResponseScopedPDU: Taille maximale pour la réponse
  • securityStateReference: Référence pour générer des réponses
  • statusInformation: Indication de succès ou d'erreur

Traitement (Processing):

  1. Analyser securityParameters
  2. Vérifier que msgAuthoritativeEngineID correspond au moteur local (pour les répondeurs de commandes)
  3. Vérifier que userName existe dans usmUserTable
  4. Vérifier la fenêtre temporelle (engineBoots et engineTime)
  5. Décrypter le message si la confidentialité a été appliquée
  6. Vérifier le résumé d'authentification si l'authentification a été appliquée
  7. Extraire et retourner scopedPDU

Integration with Message Processing Subsystem (Intégration avec le sous-système de traitement des messages)​

Le sous-système de traitement des messages invoque l'USM via ces interfaces à des points spécifiques du traitement des messages:

Pour les messages sortants (For Outgoing Messages):

Application → Répartiteur → Traitement des messages → Modèle de sécurité (USM) → Transport

Pour les messages entrants (For Incoming Messages):

Transport → Répartiteur → Traitement des messages → Modèle de sécurité (USM) → Application

Interaction with Access Control (Interaction avec le contrôle d'accès)​

L'USM fournit le securityName authentifié au sous-système de contrôle d'accès (VACM), qui l'utilise pour déterminer l'autorisation:

  1. L'USM authentifie l'utilisateur et fournit securityName
  2. Le VACM utilise securityName, securityModel et securityLevel pour déterminer les droits d'accès
  3. Le VACM accorde ou refuse l'accès en fonction des politiques configurées

Cette séparation garantit que:

  • L'USM se concentre sur: "Qui êtes-vous?" (Authentification) et "Le message est-il intact?" (Intégrité)
  • Le VACM se concentre sur: "Que pouvez-vous faire?" (Autorisation)

Error Handling and Reports (Gestion des erreurs et rapports)​

Lorsque l'USM détecte une erreur de sécurité, il peut générer un Report-PDU:

Scénarios d'erreur courants (Common Error Scenarios):

  1. ID de moteur inconnu (Unknown Engine ID): Compteur usmStatsUnknownEngineIDs incrémenté

    • Utilisé pendant le processus de découverte
    • Le rapport contient l'engineID du moteur local

  2. Violation de fenêtre temporelle (Time Window Violation): Compteur usmStatsNotInTimeWindows incrémenté

    • Utilisé pendant la synchronisation temporelle
    • Le rapport contient les engineBoots et engineTime actuels

  3. Échec d'authentification (Authentication Failure): Compteur usmStatsWrongDigests incrémenté

    • Indique un mot de passe/clé incorrect ou une altération du message
    • Rapport envoyé au même niveau de sécurité que le message reçu

  4. Échec de déchiffrement (Decryption Failure): Compteur usmStatsDecryptionErrors incrémenté

    • Indique une clé de confidentialité incorrecte ou une corruption du message
    • Rapport envoyé au même niveau de sécurité que le message reçu

  5. Utilisateur inconnu (Unknown User): Compteur usmStatsUnknownUserNames incrémenté

    • Indique que userName n'est pas dans usmUserTable
    • Rapport envoyé sans authentification

Service Primitive Sequences (Séquences de primitives de service)​

Discovery Sequence (Séquence de découverte)​

1. L'application envoie une requête avec un engineID vide
2. L'USM génère un message avec securityLevel = noAuthNoPriv
3. Le moteur autorisé reçoit le message
4. L'USM détecte un engineID inconnu
5. L'USM génère un rapport avec usmStatsUnknownEngineIDs
6. L'application reçoit le rapport, apprend l'engineID

Time Synchronization Sequence (Séquence de synchronisation temporelle)​

1. L'application envoie une requête avec un engineID mis en cache, engineBoots/Time à zéro
2. L'USM génère un message authentifié
3. Le moteur autorisé reçoit le message
4. L'USM détecte une violation de fenêtre temporelle
5. L'USM génère un rapport avec usmStatsNotInTimeWindows et les valeurs temporelles actuelles
6. L'application reçoit le rapport, met à jour les valeurs temporelles mises en cache
7. L'application réessaie la requête originale avec le temps synchronisé

Authenticated Communication Sequence (Séquence de communication authentifiée)​

1. L'application envoie une requête
2. L'USM génère un message authentifié avec les engineBoots/Time actuels
3. L'USM calcule le résumé d'authentification
4. Le moteur autorisé reçoit le message
5. L'USM vérifie la fenêtre temporelle
6. L'USM vérifie le résumé d'authentification
7. L'USM extrait scopedPDU
8. L'application traite la requête
9. L'application génère une réponse
10. L'USM génère un message de réponse authentifié
11. Le moteur non autorisé reçoit la réponse
12. L'USM vérifie le résumé d'authentification
13. L'USM extrait scopedPDU
14. L'application traite la réponse

Asynchronous vs. Synchronous Operation (Opération asynchrone vs. synchrone)​

Les interfaces de service abstraites sont conçues pour prendre en charge les deux:

Opération synchrone (Synchronous Operation):

  • L'application attend la réponse
  • Typique pour le modèle générateur/répondeur de commandes

Opération asynchrone (Asynchronous Operation):

  • L'application n'attend pas
  • Typique pour le modèle initiateur/récepteur de notifications

L'USM ne dicte pas le modèle opérationnel; il fournit simplement des services de sécurité quelle que soit la manière dont l'application choisit de fonctionner.

Dernière mise à jour le