Les pare-feux peuvent se situer entre réseaux, protéger un hôte individuel, filtrer le trafic cloud ou contrôler la communication entre workloads applicatifs.
Les décisions d'un pare-feu peuvent utiliser adresses, ports, protocoles, état de connexion, informations applicatives, identité ou autre contexte. Le résultat de sécurité dépend de l'emplacement du contrôle, du trafic qu'il peut inspecter, de la gouvernance des règles et de la bonne compréhension des communications requises.
En exploitation, la difficulté réside en général dans la politique plutôt que dans l'appliance : les règles s'accumulent jusqu'à ce que plus personne ne se souvienne du flux que chacune sert. Une gestion mature revoit les règles régulièrement, supprime les entrées masquées et expirées, relie chaque autorisation à une justification métier et à un responsable nommés, et traite les changements d'urgence comme temporaires jusqu'à une nouvelle revue.
Points clés
Objectif principalAppliquer quelles communications réseau sont autorisées à travers une frontière.
Bonne pratiquePartir des flux requis, utiliser le moindre privilège, documenter responsabilité et objectif, journaliser les décisions importantes et retirer les règles obsolètes.
Formes courantesFiltres de paquets, pare-feux stateful, proxys applicatifs, pare-feux d'hôte, contrôles cloud et pare-feux de workloads distribués.
Limite importanteUne connexion autorisée peut encore porter une attaque, et un pare-feu ne peut protéger ni le trafic qui le contourne ni l'activité qui ne franchit jamais sa frontière.