Aller au contenu

Audit

Analysez l'état du réseau, recherchez dans les configurations et surveillez le comportement des équipements sans impacter la production, grâce au module Audit.

Compliance

Le module Compliance vérifie que l'état opérationnel des équipements respecte vos exigences. Vous décrivez une exigence sous forme de règle, Avalon l'exécute sur les équipements choisis et produit un rapport de conformité, planifiable et suivi dans le temps.

Une règle se construit visuellement en reliant des blocs. Elle ne modifie jamais la configuration : la conformité est en lecture seule.

Vue d'ensemble

Vue d'ensemble de la conformité
Liste des règles de conformité avec leur dernier résultat et les actions disponibles.

La page Compliance Rules liste vos règles ; créez-en une avec New rule. Chaque règle propose ces actions :

  • Edit (crayon) : ouvrir la règle dans le constructeur.
  • Trend : afficher la tendance de conformité de la règle dans le temps.
  • Duplicate : dupliquer la règle pour la décliner.
  • Run : lancer l'audit sur une sélection d'équipements.
  • Delete : supprimer la règle.

En dessous, le panneau Reports conserve l'historique des exécutions. Chaque rapport propose Show (affichage détaillé), export PDF et Excel, et suppression ; Delete all vide tout l'historique.

Le constructeur de règles

Une règle est un graphe orienté : les données circulent le long des liens, des sources (à gauche) vers les assertions (à droite). Dès qu'un bloc est raccordé à un bloc amont, il reçoit automatiquement la sortie de ce dernier et la transforme selon son rôle. Vous n'exécutez rien manuellement : Avalon parcourt le graphe dans l'ordre au moment de l'audit.

Constructeur de règles de conformité
Composition d'une règle : sources à gauche, assertions à droite.

Chaque bloc a un rôle précis :

Bloc Rôle
Source D'où viennent les données : un template de collecte (lues sur l'équipement, connexion requise) ou une source de la base de données Avalon (Device, Device Ports), sans connexion.
Scope Restreint les équipements audités selon leurs attributs d'inventaire (modèle, version, type d'équipement...). Les scopes sont évalués en premier : un équipement hors périmètre est écarté sans connexion (quand l'inventaire suffit à le déterminer) et n'entre pas dans le calcul des taux de conformité.
Filter Restreint les lignes d'une source selon la valeur d'un champ (ex : ne garder que les ports trunk).
Join Fusionne deux sources sur un champ commun (ex : interface) pour croiser leurs colonnes.
Assertion L'exigence à vérifier : un champ, un opérateur, une valeur et un Quantifier.
Display Choisit les colonnes affichées dans le rapport.

Raccordement des blocs

Chaque type de bloc accepte un nombre d'entrées défini, et certains sont obligatoires pour qu'une règle soit valide :

Bloc Entrées Sortie Obligatoire
Source Aucune (point de départ) Oui Oui, au moins une
Scope Une seule Non Non (aucun, un ou plusieurs)
Filter Une seule Oui Non
Join Deux ou plus Oui Non (uniquement pour croiser des sources)
Assertion Une seule Non Oui, au moins une
Display Une seule Non Non
  • Une même Source peut alimenter plusieurs blocs en aval : le même jeu de données sert alors à plusieurs branches (ex : une source de trust vérifiée par deux assertions différentes).
  • Scope, Filter, Assertion et Display n'acceptent qu'une seule entrée : un second lien vers le même bloc est refusé.
  • Vous pouvez (et devez, si besoin) placer plusieurs blocs Scope. Un équipement doit satisfaire tous les scopes pour entrer dans le périmètre (ET logique) : pratique pour combiner des critères, par exemple un modèle précis et un type d'équipement donné.
  • Un Scope n'a pas de sortie : une Source (éventuellement filtrée) l'alimente et sa branche s'arrête là. Il sert uniquement à sélectionner les équipements audités ; il n'est donc jamais relié à un Join ni à une Assertion, qui ont leurs propres sources.
  • Un Join ne sert que si vous croisez au moins deux sources sur un champ commun.

Assertion et Quantifier

L'assertion porte sur les lignes qui lui parviennent. Le Quantifier définit la règle de succès :

  • ALL : toutes les lignes doivent satisfaire la condition.
  • EXISTS : au moins une ligne doit la satisfaire.
  • NONE : aucune ligne ne doit la satisfaire.

Sources de données

Trois familles de sources sont disponibles :

  • Templates de collecte : les données lues sur l'équipement via un template de collecte (Switchports, VLANs, NAC, DHCP Snooping, DAI, MAC Address Table, Hardware...). La collecte nécessite une connexion à l'équipement. La liste complète et le détail des champs figurent sur la page Templates de collecte.
  • Device : une ligne par équipement issue de l'inventaire (hostname, modèle, version, type d'équipement...). Aucune connexion requise, la source peut donc servir de scope.
  • Device Ports : une ligne par port issue de l'inventaire. Expose notamment le champ is_managed_uplink : vrai pour les ports trunk (l2_8021q) reliés à un commutateur managé situé en amont (vers le cœur) ou sur un lien horizontal. Les agrégats sont remontés sous le nom de leur interface d'agrégation.

Origine des champs

Dans les sélecteurs, chaque champ affiche sa source entre parenthèses (ex : Trust State (DAI Trust)) pour savoir d'où vient l'attribut vérifié.

Opérateurs

Opérateur Signification Exemple
EQUALS / NOT_EQUALS Égal / différent, insensible à la casse et aux espaces. trusted EQUALS yes : le port de confiance DHCP snooping est bien positionné.
CONTAINS / NOT_CONTAINS La valeur trouvée contient / ne contient pas la sous-chaîne indiquée. Opérateur de texte, pas d'ensemble. version CONTAINS 17.09
CONTAINS_ALL Toutes les valeurs attendues sont présentes dans la liste trouvée. snooping_vlans CONTAINS_ALL [VLANs du tenant] : le snooping couvre bien l'intégralité des VLANs déclarés.
CONTAINS_ANY La liste trouvée et la liste attendue ont au moins une valeur commune. access_vlan CONTAINS_ANY loopback_detection_vlans : le VLAN du port fait partie de ceux protégés contre les boucles.
IN / NOT_IN La valeur trouvée fait partie / ne fait pas partie de la liste fournie, comparée élément par élément. access_vlan IN 10, 20 : le port d'accès est sur un VLAN autorisé.
MATCHES / NOT_MATCHES Correspond / ne correspond pas à une expression régulière, insensible à la casse. ip_address MATCHES 192.168.25[4,5] : une IP en 192.168.254 ou 192.168.255.
EXISTS / NOT_EXISTS Le champ est renseigné / vide. Accompagné d'une valeur, teste sa présence sur l'équipement. vlan_id EXISTS 10 : l'équipement déclare bien le VLAN 10.
GT / GTE / LT / LTE Comparaison numérique. Sur un champ de type liste, porte sur le nombre d'éléments. local_ports_names GT 1 : l'agrégat compte plus d'un membre. cpu_usage LT 80.

Les opérateurs de comparaison numérique ne sont proposés que sur les champs de type nombre ou liste, ils ne peuvent donc pas être appliqués par erreur à un texte libre.

CONTAINS ne convient pas aux listes

CONTAINS teste une sous-chaîne. Sur une liste de VLANs, 10 serait trouvé dans 100, 101 ou 1000, et la règle passerait à tort. Pour raisonner sur un ensemble, utilisez CONTAINS_ALL ou CONTAINS_ANY, qui comparent valeur par valeur.

Plages de VLANs

Seuls CONTAINS_ALL et CONTAINS_ANY développent les plages : 10,20,30-32 est compris comme 10, 20, 30, 31, 32.

C'est ce qui permet, sur HP Comware, de vérifier une configuration du type enable vlan 1 3 10 100 to 4094 sans énumérer les milliers de VLANs concernés. Un port en VLAN 3000 est reconnu comme couvert alors que 3000 n'apparaît nulle part dans la configuration.

IN compare aux éléments littéraux de la liste et ne développerait pas la plage.

Deux comportements à connaître

CONTAINS_ALL avec une liste attendue vide est considéré non conforme, pour qu'une règle incomplète ne passe jamais silencieusement.

Un champ absent vaut zéro pour les comparaisons numériques : cpu_usage LT 80 serait vrai sur un équipement dont la donnée n'a pas pu être collectée. Combinez avec EXISTS pour distinguer une valeur nulle d'une donnée manquante.

Comparer à une valeur ou à un autre champ

Une assertion compare le champ choisi soit à une valeur saisie, soit à un autre champ de la même ligne. Le sélecteur Value / Field bascule entre les deux modes, qui sont exclusifs.

Le mode Field sert quand les deux termes de la comparaison sont des données relevées sur l'équipement, et non une valeur de référence connue à l'avance.

C'est le cas de la détection de boucle : la liste des VLANs protégés varie d'un port à l'autre, on ne peut donc pas la saisir dans la règle. L'assertion compare alors deux champs de la ligne jointe, access_vlan d'un côté et loopback_detection_vlans de l'autre.

Jointures et éléments manquants

Un Join croise deux sources (ou plus) sur un champ commun (ex : interface). Le comportement actuel :

  • Si une branche est filtrée (ex : les uplinks de Device Ports filtrés sur is_managed_uplink), elle définit l'ensemble testé. Les autres sources s'y greffent sur la clé : leurs colonnes sont ajoutées quand la clé correspond, laissées vides sinon. Une clé présente uniquement dans une source non filtrée est ignorée.
  • Si aucune branche n'est filtrée, seules les clés présentes dans toutes les sources sont conservées (intersection).

Ainsi, un uplink sans trust garde sa ligne avec la colonne de trust vide : l'assertion trusted == yes échoue et il ressort non-conforme.

Équipements non évalués

Une collecte peut échouer pour des raisons passagères : commande en timeout, lecture partielle sur un équipement chargé. Avalon réessaie automatiquement, jusqu'à trois tentatives espacées de deux secondes, avant de renoncer. La plupart des échecs se résorbent ainsi et l'équipement est réellement audité.

Si la collecte échoue malgré les tentatives, ou si l'équipement est injoignable, il est marqué non évalué et exclu du calcul des taux, puis compté à part dans le rapport.

Pourquoi l'exclusion plutôt qu'un échec

Une source vide est conforme par construction, puisqu'aucune ligne ne contredit l'assertion. Si une collecte en échec était traitée comme une source vide, l'équipement ressortirait conforme alors que rien n'a pu être vérifié, et l'erreur passerait inaperçue.

En l'excluant, le rapport distingue trois populations : les équipements conformes, les non conformes, et ceux sur lesquels la question n'a pas pu être posée.

Les équipements hors périmètre (écartés par le Scope) sont également exclus des taux, et comptés séparément.

Le rapport présente deux taux complémentaires :

  • le taux de conformité, calculé par équipement : la proportion d'équipements évalués qui satisfont toutes les assertions ;
  • le taux de conformité global, pondéré par le nombre de lignes vérifiées : la proportion de ports ou d'éléments conformes sur l'ensemble des équipements évalués. Un équipement avec deux ports en défaut sur cinquante y pèse différemment que dans le premier taux.

Planification, rapports et tendance

  • Planification : une règle peut être exécutée périodiquement et envoyer un e-mail récapitulatif (la configuration SMTP doit être faite au préalable).
  • Rapports : chaque exécution produit un rapport consultable, exportable en PDF et Excel. Le rapport documente la règle telle qu'auditée (définition figée au moment de l'exécution) et présente les résultats par assertion, avec le taux de conformité par équipement et global.
  • Tendance : l'évolution de la conformité est tracée dans le temps depuis le premier rapport de la règle.
Rapport de conformité - synthèse
Rapport de conformité : définition de la règle et synthèse globale.
Rapport de conformité - détail
Résultats par équipement et détail par assertion.

Cas d'usage : DHCP snooping et Dynamic ARP Inspection (DAI)

Objectif : vérifier que le trust est positionné sur les bons ports (les liens vers les autres commutateurs) et que le snooping et la DAI couvrent les VLANs utilisateurs. Une même règle porte les deux features, via plusieurs assertions.

Règle DHCP snooping et DAI
La règle complète : trust des uplinks et couverture des VLANs, pour le snooping et la DAI.

1. Le trust est sur les bons ports

  1. Source Device Ports.
  2. Filter : is_managed_uplink EQUALS true (ne garde que les liens montants et horizontaux).
  3. Join sur interface avec DHCP Snooping Trust et DAI Trust.
  4. Deux assertions (Quantifier ALL) : trusted EQUALS yes et trust_state EQUALS Trusted.

2. Le snooping et la DAI couvrent les VLANs déclarés

  1. Source DHCP Snooping → assertion snooping_vlans CONTAINS_ALL [VLANs du tenant].
  2. Source DAI → assertion dai_vlans CONTAINS_ALL [VLANs du tenant].

(Quantifier ALL pour les deux.)

Un port de confiance mal configuré ressort en Non-compliant, un équipement conforme en Compliant.

Agrégats de liens

Le trust s'applique sur l'agrégat. Avalon remonte automatiquement les ports physiques membres sous le nom de leur interface d'agrégation, aussi bien côté ports que côté sortie équipement, pour que la jointure tombe juste.

Data gathering

Récupérez des données d'état opérationnel (données non-configuration) de vos équipements en temps réel. Générez des rapports à l'échelle du réseau : tables d'adresses MAC, voisins CDP, VLANs, compteurs d'interface, etc.

Collecte de données

Interface Data Gathering
Interface de collecte de données avec filtres et historique des rapports.

Le formulaire de collecte vous permet de configurer votre requête :

  1. Data : Sélectionnez un ou plusieurs types de données à collecter (ex : Switchports, MAC Address Table, NAC).
  2. Sites : Sélectionnez les sites à interroger.
  3. Quick select devices : Sélection rapide par type d'équipement.
  4. Devices : Sélection fine des équipements individuels.
  5. Send results to : (Optionnel) Sélectionnez un ou plusieurs destinataires pour recevoir le rapport par email. La configuration SMTP doit être effectuée au préalable.
  6. Report mode : Le mode de regroupement du rapport (Per service ou Per device).
  7. Fetch data : Lance la collecte sur les équipements sélectionnés.

Rapports

Chaque collecte génère un rapport consultable dans la section Reports. Un rapport contient :

  • Report ID : Identifiant unique du rapport.
  • Inventory : Nombre d'équipements et de services interrogés.
  • Start time : Date et heure de lancement, avec la durée d'exécution.
  • Status : Résultat de la collecte (success, error).

Actions disponibles :

  • Show results : Affiche les résultats détaillés du rapport.
  • Export : Télécharge les données au format CSV/Excel.
  • Supprimer : Supprime le rapport de l'historique.
  • Delete all : Vide tout l'historique des rapports du tenant. Le bouton se trouve dans les icônes du panneau Reports, en haut à droite, et reste inactif tant qu'aucun rapport n'existe. L'action est irréversible et une confirmation est demandée.

Visualisation des résultats

Résultats Data Gathering
Résultats d'un rapport avec filtrage et pagination.

La section Results offre deux perspectives pour analyser les données. Vous pouvez basculer entre elles en utilisant les boutons Services et Devices :

  • Services : Regroupe les données par type de collecte. Idéal pour les audits globaux (ex : "toutes les interfaces VLAN de tout le site").
  • Devices : Regroupe les données par équipement. Idéal pour les vérifications ciblées sur un équipement spécifique.

Un champ Pattern permet de filtrer les résultats affichés.

Templates de collecte disponibles

Avalon fournit d'origine une série de templates (VLANs, Switchports, MAC Address Table, Hardware, NAC, DHCP Snooping, DAI...), utilisables ici en collecte comme dans les règles de Compliance.

Le détail de chaque template et de ses colonnes est décrit sur la page Templates de collecte.

Explore configurations

Recherchez des lignes de configuration spécifiques à travers des centaines de fichiers de sauvegarde sans avoir à les ouvrir individuellement.

Utilisation

  • Pattern : Entrez une chaîne de texte ou une Regex (ex : telnet, password 7, 192.168.1.1).
  • Scope : Sélectionnez les sites ou types d'équipements à rechercher.
Résultats de recherche de configuration
Recherche de l'utilisation de 'telnet' à travers les sauvegardes de configuration du site.

Résultats

Le tableau affiche le statut de correspondance pour chaque équipement.

  • Pattern match : Indique si la chaîne a été trouvée.
  • Download : Vous pouvez télécharger le fichier de configuration spécifique directement depuis cette vue.

Compare configurations

L'outil Compare affiche un « Diff » visuel entre deux fichiers de configuration.

Utilisation

  • Validation de changements : Comparer le running-config d'un équipement à deux dates différentes (ex : "Avant" vs "Après" maintenance).
  • Standardisation : Comparer les configurations de deux équipements similaires (ex : ACCESS-1-1a vs ACCESS-1-1b).
Diff de configuration
Comparaison visuelle mettant en évidence les ajouts (vert) et suppressions (rouge).

Indicateurs visuels

  • Vert Lignes présentes dans le fichier de droite mais absentes dans celui de gauche (Ajouts).
  • Rouge Lignes présentes dans le fichier de gauche mais absentes dans celui de droite (Suppressions).

Devices logs

Recherchez dans les messages Syslog exportés par les équipements vers Avalon, depuis une interface centralisée.

Utilisation

Vous pouvez affiner la recherche en utilisant :

  • Pattern : Recherche par mot-clé (ex : link-flap, OSPF, user-login).
  • Time Window : Date de début et date de fin.
  • Scope : Sites ou Équipements spécifiques.
Recherche dans les journaux d'équipements
Vue historique des messages syslog correspondant à un motif spécifique.

Mail alerts

Devices logs convient aux investigations historiques ; Mail alerts assure une surveillance proactive. Configurez Avalon pour envoyer une notification par email dès qu'un motif de log précis est détecté.

Créer une alerte

  1. Alert Type : Actuellement prend en charge Device Logs.
  2. Alert name : Un nom descriptif pour l'alerte.
  3. Recipient / Send to : Sélectionnez l'adresse email à notifier.
  4. Pattern : La Regex ou chaîne à surveiller (ex : root, fan fail).
  5. Devices to watch : Définissez quels équipements surveiller.
Création d'une alerte mail
Configuration d'une alerte proactive pour les changements de topologie STP.

Exemple d'email

Lorsqu'elle est déclenchée, l'email donne le contexte nécessaire au dépannage : l'IP de l'équipement, le motif correspondant et la ligne de log brute.

Mail déclenché par alerte STP
Mail déclenché par changement de Root STP.