Daniel Allaire c98bc8393f Registre des flux : schéma meta/flux.yml + pilote (postgresql/metrique/nginx)

Couche accès du zéro-confiance (complète le chiffrement). Chaque rôle possède
ses flux (comme meta/empreinte) : sens/port/protocole/pair/chiffrement/raison.
Résolu par le plan (pair→IP) → génère les règles nftables (default deny) ET le
registre d'audit. Doc de conception + 3 pilotes validés (résolveur-démo).

Séquence : schéma+pilote (fait) → résolveur → remplir les rôles → générer +
registre → activer nftables prudemment (action destructive).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-05 09:41:42 -04:00

3 KiB

Raw Blame History

Registre des flux réseau — conception

But

Set-OPS tient un registre des flux (qui parle à qui, sur quel port, dans quel sens, pourquoi) pour deux usages :

Générer les règles nftables de chaque serveur — autoriser les flux déclarés, tout refuser d'autre (moindre privilège). Complète la couche chiffrement (TLS) par la couche accès.
Preuve d'audit — la matrice d'accès réseau documentée (source → dest : port : chiffrement : raison), exigée par un audit de sécurité et le label de certification.

Principe : le rôle possède ses flux

Comme meta/empreinte.yml (dimensionnement) est la propriété du rôle, roles/<rôle>/meta/flux.yml déclare les flux du logiciel. Le rôle sait sur quoi il écoute et à quoi il se connecte ; personne d'autre. Le registre global se dérive de l'ensemble des flux.yml des rôles présents sur un nœud.

Schéma de `meta/flux.yml`

flux:
  - sens: ingress          # ingress = ce rôle ÉCOUTE ; egress = ce rôle SE CONNECTE
    port: 5432             # entier ou liste [80, 443]
    protocole: tcp         # tcp | udp
    pair: [serveur_keycloak, serveur_forgejo]   # QUI — voir « Résolution du pair »
    chiffrement: tls-requis # tls-requis | tls | starttls | clair | n-a   (bonus audit)
    raison: "Connexions applicatives (verify-full)."   # lisible, pour l'audit

Résolution du `pair`

Valeur	Résout vers
un rôle/groupe (`serveur_prometheus`)	les IP des hôtes de ce groupe (via le plan)
`edge`	le(s) hôte(s) de l'edge (`serveur_nginx`)
`flotte`	tous les nœuds de l'instance
`externe`	hors flotte (frontière publique — géré à l'OPNsense, pas dans le nœud)
`localhost`	boucle locale — aucune règle inter-nœud (nftables autorise `lo`)
`expositions`	dérivé des `expose:` des applications (cas de l'edge → backends)

La résolution pair → IP réutilise le plan (registre IP/FQDN/zones) déjà en place.

Génération

Un résolveur (miroir de instancier) agrège, par serveur, les flux.yml de tous ses rôles (services + intégrations), résout les pair, et produit :

nftables : ruleset par serveur (allow des flux résolus, policy drop par défaut), consommé par le rôle nftables_baseline ;
le registre d'audit : docs/registre-flux.md (généré) + une cible make flux.

Activation prudente

Activer nftables = action destructive (peut couper l'accès) → confirmation explicite + déploiement graduel (garder l'accès SSH/Ansible, tester par nœud). nftables reste préparé mais non activé tant que le registre n'est pas complet et validé.

Séquence

✅ figer le schéma (ce doc) + piloter sur postgresql / client_metrique / nginx ;
le résolveur (agrégation → règles + registre) ;
remplir tous les rôles (large transcription du travail zéro-confiance déjà fait) ;
générer + registre d'audit ; puis activer nftables nœud par nœud.

3 KiB Raw Blame History