« Il suffit d’ajouter les autorisations nécessaires et de placer un deny à la fin. »
Sans zones, propriétaire, ordre, journalisation et test fonctionnel, une règle peut être trop large ou inutilisable.
01Observe les zones
lab=/tmp/soria-hardening-network-workloads-$USER
bash module5-opnsense-wireguard-workloads.sh setup "$lab"
column -s, -t "$lab/source/network/zones.csv"Le scénario sépare WAN, DMZ, USERS, SERVERS, MGMT, WG_ADMIN et K8S_WORKLOADS. Chaque zone possède une politique par défaut restrictive et un propriétaire.
02Lis la matrice de flux
column -s, -t "$lab/source/network/flow-matrix.csv"Chaque flux autorisé relie source, destination, protocole, port, raison métier, propriétaire, journalisation, état, test fonctionnel et rollback.
Un flux any → any, une zone inconnue ou un champ de preuve absent rend la politique bloquante.
03Utilise des aliases
column -s, -t "$lab/source/opnsense/aliases.csv"Les aliases évitent la répétition des adresses et rendent les règles plus lisibles. Les fixtures portent SYNTHETIC — DO NOT IMPORT : elles ne sont pas un export OPNsense.
04Génère la cible
bash module5-opnsense-wireguard-workloads.sh run "$lab"
column -s, -t "$lab/output/opnsense-policy-target.csv"Les règles spécifiques précèdent le refus final de chaque zone. La politique est stateful dans son intention : le retour d’un flux autorisé n’exige pas une règle symétrique artificielle.
05Vérifie l’ordre
column -s, -t "$lab/output/opnsense-rule-order.csv"Une règle d’autorisation placée après le refus final est inaccessible. Une règle large placée avant une restriction peut la neutraliser. Le test négatif NEG-02 vérifie cette erreur.
06Préserve les fonctions
cat "$lab/output/functional-test-report.csv"Les tests représentés préservent HTTPS public, DNS, le flux frontal–application, l’administration WireGuard et les flux Kubernetes requis.
07Observe le delta
column -s, -t "$lab/output/opnsense-delta.csv"Le delta compare une politique initiale trop large à une cible restrictive. Il ne prouve pas qu’OPNsense a chargé ou appliqué ces règles.
08Prépare le rollback
La restauration réelle exige sauvegarde de configuration, fenêtre de changement, accès console ou secours, critères d’arrêt et vérification des states. Le lab ne simule que le retour exact des fixtures.
Défends la politique cible
Présente zones, aliases, règles, ordre, refus finaux, journalisation, tests métier, exceptions et rollback. Distingue ce que la CI prouve de ce qui exige un pare-feu autorisé.
✓À retenir
Une politique restrictive part d’une matrice de flux justifiée, applique les règles sur la zone d’origine, ordonne le spécifique avant le refus et conserve une preuve fonctionnelle.