Une imprimante, l’appareil d’un visiteur et le serveur de fichiers n’ont pas besoin d’emprunter les mêmes chemins réseau. Des zones clairement définies permettent de préciser qui a besoin de quel service. OPNsense peut contrôler les échanges entre elles ; une répartition pertinente commence par les processus de l’entreprise.
De l’inventaire des équipements aux flux de données autorisés
Une petite matrice des accès constitue un bon point de départ. Elle indique la zone de départ, le service nécessaire, la destination et la justification métier. Un poste peut avoir besoin d’une application métier sur un serveur. Un appareil invité a besoin d’Internet. L’administration d’un commutateur ne devrait être accessible que par un chemin prévu à cet effet.
Les zones sont ensuite mises en œuvre techniquement, par exemple avec des VLAN et des ports de commutateur adaptés. Le nom d’un VLAN ne constitue pas à lui seul une frontière de protection complète. Le trafic entre réseaux doit effectivement passer par le point de contrôle ; les routeurs supplémentaires, les ponts Wi-Fi oubliés et les doubles connexions réseau font partie des vérifications.
Chaque règle décrit un objectif précis
OPNsense utilise un filtre de paquets avec suivi d’état. Les règles s’examinent en tenant compte de l’interface, du sens, de l’ordre et des états des connexions existantes. Des alias réutilisables rendent les règles plus lisibles si leur contenu est clairement nommé et entretenu. Un alias appelé « Serveurs » ne remplace pas une définition documentée.
Une autorisation décrit autant que possible des destinations précises et les services nécessaires. Une règle de test initialement large reçoit un responsable et une échéance. Sinon, un diagnostic temporaire devient rapidement un accès permanent difficile à comprendre. Les changements sont plus faciles à évaluer lorsque la justification métier reste identifiable dans le commentaire de la règle.
Intégrer NAT, résolution de noms et IPv6
La traduction d’adresses et les règles d’accès remplissent des rôles différents. Une redirection publique nécessite une autorisation adaptée ; une adresse source modifiée ne dit pas si une application doit être accessible. DNS, DHCP, services de temps et chemins de retour doivent également rester adaptés à l’environnement après le découpage en zones.
IPv6 est explicitement vérifié. Une matrice d’accès pensée uniquement pour IPv4 peut oublier une seconde famille de protocoles active. Les interfaces d’administration, les connexions VPN et le trafic émis par le pare-feu lui-même nécessitent aussi leurs propres parcours de test. Les règles doivent représenter les connexions réellement exploitées.
Un petit pilote révèle les dépendances
Pour commencer, un groupe limité d’équipements avec un processus de travail connu convient bien. Les mêmes applications sont testées avant et après la séparation. Le compte rendu comprend aussi des accès volontairement refusés : les invités n’atteignent pas l’interface d’administration et un équipement technique ne peut pas accéder librement au réseau des serveurs.
DAXS relie la planification réseau aux commutateurs, au Wi-Fi, aux services des serveurs et à l’exploitation existante. Le résultat est une matrice d’accès facile à maintenir, avec des règles compréhensibles. Le nombre pertinent de zones dépend du besoin de protection, de la gestion des équipements et de la maintenabilité ; multiplier les VLAN n’est pas un objectif de qualité en soi.
Infrastructure et plateformes · Situer les mesures techniques de protection · Discuter d’un projet réseau
Sources : OPNsense : règles de pare-feu avec suivi d’état (lien externe) · OPNsense : traduction d’adresses réseau (lien externe)
