Comprenez le risque lié aux politiques. Posez vos questions sur les politiques en langage courant. Demander une démo →
Published:
Un accès temporaire ne doit pas devenir une politique de pare-feu permanente
Découvrez pourquoi les accès pare-feu temporaires survivent à leur raison d’être et comment propriétaires, justification, dates d’expiration et revues permettent de garder sous contrôle les règles à durée limitée.
by FireMon
Un accès temporaire a tendance à devenir permanent.
Une règle est créée pour un projet, un prestataire, une migration ou une demande urgente. À ce moment-là, chacun sait pourquoi elle existe. Quelques mois plus tard, ce contexte est bien plus difficile à retrouver.
Qui l’a demandée ? Qui l’a approuvée ? Quel besoin métier justifiait-elle ? Cet accès est-il toujours nécessaire ?
Sans ces informations, même une règle de pare-feu techniquement valide devient difficile à évaluer.
C’est pourquoi une gestion efficace des politiques ne se limite pas à savoir ce qu’une règle autorise. Les équipes doivent également savoir pourquoi la règle existe et qui en est responsable.
Documenter le contexte tant que la décision est récente
Dans la vidéo ci-dessus, Rob Rodriguez, Senior Director of Global Field Engineering chez FireMon, montre comment les équipes peuvent documenter le contexte métier d’une règle de pare-feu directement dans Security Manager.
Ce contexte peut inclure des informations telles que :
- Justification métier
- Unité opérationnelle
- Propriétaire de la règle
- Demandeur et approbateur
- Informations de gestion des changements
- Date de la prochaine revue
- Date d’expiration
L’exemple présenté par Rob porte l’intitulé « Temp Access », ce qui met en lumière un problème courant de gestion des politiques.
Un accès temporaire peut être nécessaire. Le risque apparaît lorsqu’aucun mécanisme clair ne permet de déterminer quand cet accès doit prendre fin.
Une date d’expiration ou une revue planifiée crée un point de contrôle. Plutôt que de compter sur la mémoire d’une personne plusieurs mois après la demande initiale, la politique elle-même porte les informations nécessaires pour réexaminer la décision.
Faciliter l’évaluation ultérieure des règles
La configuration technique indique ce que fait une règle de pare-feu.
La documentation indique pourquoi elle existe.
Cette distinction devient d’autant plus importante que les environnements s’étendent et que les équipes évoluent.
L’ingénieur qui examine une règle six mois après sa création n’a peut-être pas participé à la demande initiale. Le propriétaire de l’application a pu changer de fonction. Le projet a pu se terminer. La relation avec le prestataire a pu prendre fin.
Sans propriétaire ni justification métier, l’équipe doit reconstituer l’historique de la règle avant de pouvoir décider si l’accès reste approprié.
Documenter ces informations dès le départ simplifie considérablement les revues futures.
Au lieu de demander « quelqu’un sait-il à quoi sert cette règle ? », les équipes disposent d’une finalité documentée, d’un propriétaire et d’un calendrier de revue.
Fixer une date de fin aux accès temporaires
Les règles temporaires méritent une attention particulière, car leur finalité initiale est souvent liée à un événement ou à une période spécifique.
Il peut s’agir d’une fenêtre de maintenance, d’une migration, d’une phase de tests, d’une intervention d’un tiers ou d’un besoin métier à court terme.
Si la règle est créée sans date d’expiration ni processus de revue, l’accès peut perdurer bien après la disparition du besoin initial.
Un meilleur processus relie la règle technique à son cycle de vie métier.
Lorsqu’un accès est associé à un propriétaire, à une justification et à une date de revue, les équipes disposent d’une base claire pour se demander s’il doit être maintenu.
Cela ne signifie pas supprimer automatiquement chaque règle temporaire à l’échéance. Cela signifie créer un point de revue délibéré plutôt que de laisser l’accès se prolonger indéfiniment par défaut.
Faire des règles de pare-feu des décisions encadrées
La politique de pare-feu est plus simple à gérer lorsque les règles sont traitées comme des décisions métier, et non comme de simples objets de configuration.
FireMon aide les équipes à relier la politique technique aux informations de propriété, de justification et de revue nécessaires pour gérer cet accès dans la durée.
Résultat : une traçabilité plus claire des raisons d’être de chaque accès et une méthode plus concrète pour déterminer s’il reste nécessaire.
Car la question n’est pas seulement de savoir si une règle fonctionne aujourd’hui. Elle est de savoir si l’organisation comprendra encore cet accès, en assumera la responsabilité et en aura besoin demain.
Intégrez le contexte métier à la gestion des politiques de pare-feu. Découvrez comment FireMon Security Manager aide les équipes à comprendre, documenter et gouverner la politique de sécurité dans des environnements complexes.
Questions fréquentes
Un accès temporaire devient permanent lorsque la règle est créée sans propriétaire, sans justification métier, sans date d’expiration ni date de revue. Au moment de la création, chacun sait pourquoi elle existe. Quelques mois plus tard, le demandeur a pu quitter son poste et le projet se terminer. Si personne ne peut dire si l’accès reste nécessaire, la règle demeure par défaut.
Lorsqu’un accès temporaire s’éternise, une règle de pare-feu peut être techniquement valide tout en restant difficile à évaluer. Les équipes voient ce qu’elle autorise, mais ni pourquoi elle existe ni qui en est responsable ; l’accès peut donc perdurer bien après la disparition du besoin initial. Les personnes chargées de la revue doivent alors reconstituer l’historique de la règle avant de décider si l’accès reste approprié.
Un accès temporaire au pare-feu répond généralement à un événement ou à une période spécifique. Les cas les plus courants sont un projet, une fenêtre de maintenance, une migration, une phase de tests, l’intervention d’un tiers ou d’un prestataire, une demande urgente ou un besoin métier à court terme. Comme le besoin est lié à cet événement, le cycle de vie de la règle doit l’être également, avec une date de revue ou de fin.
Documentez la justification métier, l’unité opérationnelle, le propriétaire de la règle, le demandeur et l’approbateur, les informations de gestion des changements, la date de la prochaine revue et la date d’expiration. En consignant ces éléments pendant que la décision est récente, la personne qui effectuera la revue partira d’une finalité et d’un propriétaire documentés plutôt que d’avoir à reconstituer l’historique. FireMon Security Manager permet aux équipes d’enregistrer ce contexte métier directement sur la règle de pare-feu.
Une date d’expiration ou une revue planifiée crée un point de contrôle qui ne dépend pas de la mémoire de la demande initiale. À l’échéance, le propriétaire et la justification de la règle donnent à l’équipe une base claire pour décider si l’accès doit être maintenu, modifié ou supprimé. Sans ce point de contrôle, un accès temporaire se prolonge généralement indéfiniment par défaut.
Pas nécessairement. FireMon recommande de traiter la date d’expiration comme un point de revue délibéré, et non comme un déclencheur de suppression automatique. Certains accès peuvent rester légitimement nécessaires, et les supprimer sans vérification pourrait perturber l’activité. L’objectif est que chaque règle temporaire fasse l’objet d’une décision explicite, plutôt que de subsister faute d’examen.
Commencez par quatre questions : qui a demandé cette règle ? Qui l’a approuvée ? Quel besoin métier justifiait-elle ? Ce besoin existe-t-il toujours ? Vérifiez ensuite si le propriétaire, l’application, le projet ou la relation avec le prestataire ont changé. Si la règle documente sa justification, son propriétaire et sa date de revue, l’équipe peut répondre rapidement, sans devoir demander si quelqu’un sait à quoi elle sert.
Recherchez une solution qui associe un contexte métier à chaque règle : justification, unité opérationnelle, propriétaire, demandeur et approbateur, informations de gestion des changements, dates de revue et dates d’expiration. Elle doit permettre de traiter les règles comme des décisions métier encadrées, dotées d’un cycle de vie, et non comme de simples objets de configuration. FireMon Security Manager permet de documenter ce contexte sur les règles de pare-feu, afin que les équipes réexaminent les accès temporaires sur la base d’un historique clair.