Le saviez-vous ? Automatisez la documentation des règles avec FireMon

Une règle de pare-feu indique quel trafic elle filtre et quelle action elle applique. En revanche, elle ne dit généralement pas qui a encore besoin de cet accès, pourquoi il a été approuvé, ni quelle demande de changement l'a autorisé. Lorsque ces informations n'existent que dans un ticket ou dans la mémoire d'une personne, une simple revue de règles se transforme en enquête.

FireMon Security Manager dispose d'une fonctionnalité méconnue qui facilite la recherche de ce contexte : l'auto-documentation. Si vos équipes utilisent un format homogène dans les commentaires des règles de pare-feu, FireMon peut lire ces commentaires lors de la récupération de la policy et renseigner les champs de documentation de règle correspondants. Les administrateurs évitent ainsi de saisir deux fois les mêmes informations, règle après règle.

Transformer un commentaire de règle en champs exploitables

Supposons qu'un ingénieur ajoute ce commentaire à une règle de pare-feu dans l'outil d'administration de l'équipement :

own: Payments Team; ccn: CHG-4821; jst: Approved connection for payment processing;

Les modèles de correspondance par défaut de FireMon reconnaissent own, ccn et jst comme le propriétaire, le numéro de contrôle de changement et la justification métier. Lorsque Security Manager récupère la policy, il associe les valeurs reconnues à cette règle sous forme de documentation structurée. FireMon exécute l'auto-documentation à chaque révision de policy qu'il traite. L'exemple est donné à titre d'illustration : les valeurs doivent correspondre aux modèles configurés dans votre environnement.

Cette distinction a son importance. Un commentaire en texte libre est utile lorsque vous consultez déjà la règle. Les champs structurés, eux, vous permettent de filtrer et d'effectuer des recherches sur l'ensemble des règles pour répondre à des questions telles que : quelles règles relèvent de l'équipe Paiements ? Lesquelles sont associées à un numéro de change précis ? Quelles règles ne comportent pas de justification métier ? Security Manager rend les champs de documentation correspondants disponibles dans ses filtres et ses recherches SIQL lorsque le filtrage est activé.

La documentation reste associée à la règle, indépendamment de son numéro ou de ses révisions. Si la position de la règle change dans la policy, le contexte documenté ne dépend pas de cette position.

Commencer par un workflow reproductible

Il n'est pas nécessaire de documenter toutes les règles d'un coup. Un point de départ pragmatique consiste à traiter un petit ensemble de règles nouvelles ou récemment modifiées :

1. Choisissez les champs utiles. Le propriétaire, le numéro de contrôle de changement et la justification métier constituent de bons points de départ. Les dates d'expiration peuvent également s'avérer précieuses pour les accès temporaires.
2. Vérifiez les modèles de correspondance. Dans Administration, examinez les champs Rule Documentation et les modèles qui extraient les valeurs des commentaires. FireMon fournit des modèles par défaut et les administrateurs peuvent configurer des champs supplémentaires si nécessaire.
3. Appliquez le format convenu dans les commentaires de règle. Demandez aux ingénieurs de saisir les marqueurs de champ et les valeurs de manière homogène dans leur outil d'administration d'équipement. Assurez-vous que l'équipement ou la station de management conserve ces commentaires et que vos équipes peuvent les récupérer.
4. Contrôlez le résultat après récupération. Ouvrez un exemple de règle dans Security Manager et vérifiez sa Rule Documentation. Filtrez ou recherchez ensuite le propriétaire ou le numéro de changement afin de confirmer que l'information est exploitable au-delà de cette seule règle.

L'objectif est d'assurer un transfert fiable entre le processus de changement et l'enregistrement de la règle. Lorsqu'un ingénieur doit décider si une ancienne exception est encore nécessaire, le propriétaire et le motif initial sont déjà rattachés à la règle. Lorsqu'un auditeur doit remonter d'une règle au changement approuvé, le numéro de changement est disponible dans la vue policy. Les dates de prochaine revue documentées peuvent également alimenter des rapports identifiant les règles à réexaminer.

Maintenir les contrôles humains

L'auto-documentation extrait les informations que vos équipes fournissent. Elle ne détermine pas si une justification métier est toujours valable ni si le propriétaire désigné est toujours responsable. Définissez qui maintient les commentaires source et examinez les champs renseignés dans le cadre de votre processus habituel de changement et de recertification.

Si vous personnalisez un modèle de correspondance, testez-le avant de le déployer largement. Commencez par un petit échantillon de commentaires et validez les résultats avant d'étendre le format à l'ensemble des équipements.

Pour les administrateurs de pare-feu, il s'agit d'un changement modeste au bénéfice réel : le contexte saisi lors d'un changement devient une documentation de règle consultable tout au long de la gestion des policies. Il devient ainsi plus simple d'investiguer sur un accès, de réexaminer des règles anciennes et d'expliquer pourquoi une règle existe, sans avoir à reconstituer son historique de zéro.

Découvrez FireMon Security Manager et voyez comment une documentation de règle consultable facilite les revues de policies de pare-feu.