Sécurité du parc — note d'architecture¶

Ce que cette page dit, et ce qu'elle tait délibérément

Elle décrit les systèmes de sécurité, leurs liaisons et leurs flux. Elle ne donne aucune adresse IP, aucun nom d'hôte, aucun nom de compte, aucun FQDN de service. Les hôtes y sont désignés par leur rôle.

Ce choix n'est pas de la coquetterie : une page de documentation, même derrière l'authentification, finit par être copiée dans un ticket, une capture d'écran ou un presse-papier. Une architecture reste une architecture sans ses coordonnées ; une liste de FQDN publics, elle, est une carte d'attaque prête à l'emploi.

Les coordonnées vivent dans le vault privé et dans le coffre. Voir Lire un secret du coffre.

La même règle vaut pour les sous-pages de cette section, avec une clause de plus : aucun écart encore ouvert n'y figure. Elles décrivent l'architecture, les principes et la façon dont on les vérifie ; l'état du jour — ce qui est en cours, ce qui échoue — vit dans le vault privé et sur le tableau de conformité.

Le principe directeur¶

Le parc n'a pas de périmètre unique à défendre. Il a des couches qui échouent séparément : un attaquant qui franchit l'une doit encore franchir la suivante, et chaque franchissement laisse une trace dans un système que la couche précédente ne contrôle pas.

Quatre règles gouvernent l'ensemble :

Une seule autorité d'identité. Aucun service ne gère ses propres comptes s'il peut déléguer. Un départ, un mot de passe compromis, un second facteur : un seul endroit à toucher.
Ce qui détecte n'est jamais ce qui exécute. Les journaux d'un hôte partent ailleurs. Un hôte compromis peut mentir sur lui-même, pas effacer ce qui est déjà parti.
Le silence est un état suspect. Une sonde qui ne dit rien et une sonde morte produisent la même absence. Chaque chaîne de détection porte donc un témoin fonctionnel : pas un compteur qui dit « je suis en vie », mais un cas connu, injecté exprès, qui doit être détecté à chaque passage.
Prouver, pas déclarer. Chaque contrôle est mesuré par une sonde qu'on a vue échouer au moins une fois ; son verdict entre dans un registre qu'on ne peut pas réécrire sans que ça se voie, et le statut « conforme » se calcule à partir des preuves — il ne se saisit jamais. Voir Conformité et preuves.

La section en un coup d'œil¶

La défense du parc s'organise en quatre fonctions, et une cinquième qui les vérifie toutes :

flowchart LR
    classDef p fill:#0f766e,stroke:#0f766e,color:#fff
    classDef d fill:#7c2d12,stroke:#7c2d12,color:#fff
    classDef r fill:#9a3412,stroke:#9a3412,color:#fff
    classDef c fill:#1e40af,stroke:#1e40af,color:#fff
    classDef g fill:#3f3f46,stroke:#3f3f46,color:#fff

    prev["PRÉVENIR<br/>périmètre · identité · secrets<br/>chaîne d'approvisionnement · correctifs"]:::p
    det["DÉTECTER<br/>SIEM · exécution · réseau<br/>fichiers · vulnérabilités"]:::d
    rep["RÉPONDRE<br/>notification unique · réponse automatique<br/>investigation · registre d'incidents"]:::r
    cont["SURVIVRE<br/>sauvegardes immuables · restauration chronométrée<br/>clé maîtresse hors ligne"]:::c
    prouv["PROUVER<br/>catalogue de contrôles · sondes<br/>registre chaîné · ancre git"]:::g

    prev --> det --> rep --> cont
    prouv -.->|"mesure"| prev
    prouv -.->|"mesure"| det
    prouv -.->|"mesure"| rep
    prouv -.->|"mesure"| cont

Page	Ce qu'on y trouve
Cette page	L'architecture : les couches, leurs liaisons, leurs flux — et la prévention
Détection	Une question, un moteur : SIEM, exécution, réseau, fichiers, vulnérabilités — et leurs témoins
Réponse	Notification, réponse automatique bornée, investigation à chaud, registre d'incidents
Continuité	Niveaux de sauvegarde, immuabilité, exercice de restauration, clé maîtresse
Conformité et preuves	NIS2 et SOC 2 comme grille, contrôles, sondes, registre chaîné, audit
Licences	Ce qui déclenche une obligation, licences open source et source-available, modèles, contenus, règle par activité
Glossaire	Chaque terme, et ce qu'il désigne dans ce parc

Vue d'ensemble¶

flowchart TB
    classDef edge fill:#0f766e,stroke:#0f766e,color:#fff
    classDef det fill:#7c2d12,stroke:#7c2d12,color:#fff
    classDef id fill:#1e40af,stroke:#1e40af,color:#fff
    classDef data fill:#3f3f46,stroke:#3f3f46,color:#fff

    client["Client Internet"]

    subgraph perimetre["1 · Périmètre"]
        dns["DNS public<br/>zone déléguée au registrar"]
        nat["Routeur — NAT entrant<br/>un seul port ouvert"]
        edge["Proxy de bordure<br/>terminaison TLS · sur le NAS"]:::edge
        proxy["Proxy interne<br/>routage · en-têtes · journalisation"]:::edge
        ips["CrowdSec<br/>analyse des journaux → 403"]:::edge
    end

    subgraph identite["2 · Identité"]
        idp["Fournisseur d'identité<br/>OIDC · SAML · MFA"]:::id
        fa["forward_auth<br/>mur, sans identité applicative"]:::id
    end

    subgraph prive["3 · Réseau privé"]
        cp["Plan de contrôle VPN<br/>auto-hébergé sur le VPS"]:::edge
        mesh["Maillage WireGuard<br/>chiffré de bout en bout"]:::edge
        dnsf["Filtrage DNS<br/>listes + horizon dédoublé"]:::edge
    end

    subgraph contenu["4 · Contenu"]
        av["Moteur antivirus central<br/>un seul daemon, protocole INSTREAM"]:::det
        yara["Analyse statique profonde<br/>dépliage récursif · YARA"]:::det
        quar["Quarantaine partagée<br/>sur le NAS"]:::data
    end

    subgraph detection["5 · Détection et réponse"]
        siem["SIEM / XDR<br/>intégrité fichiers · CVE · MITRE"]:::det
        fleet["Collecte journaux + métriques"]:::det
        rt["Détection à l'exécution<br/>appels système · eBPF"]:::det
        ids["IDS réseau<br/>signatures sur le trafic"]:::det
        ar["Réponse automatique<br/>blocage à durée limitée"]:::det
        hub["Répartiteur d'alertes"]:::det
        chat["Messagerie d'équipe<br/>deux destinations"]:::det
        dfir["Investigation à chaud<br/>client sur chaque machine"]:::det
    end

    subgraph socle["6 · Socle"]
        coffre["Coffre de secrets"]:::data
        sops["Secrets chiffrés au repos<br/>dans le dépôt"]:::data
        backup["Dépôts de sauvegarde chiffrés<br/>ajout seul · copies hors site"]:::data
        smart["Santé des disques"]:::data
        preuve["Registre de preuves<br/>chaîné · ancré dans git"]:::data
    end

    client --> dns --> nat --> edge --> proxy
    proxy --> ips
    ips -->|"IP décidée"| proxy
    proxy --> idp
    proxy -.->|"dernier recours"| fa
    idp --> proxy

    mesh --- cp
    mesh --- dnsf

    av --> quar
    yara --> quar

    proxy --> siem
    av --> siem
    yara --> siem
    fleet --> siem
    siem --> hub --> chat
    smart --> hub
    rt -.->|"après mesure du bruit"| hub
    ids -.->|"après mesure du bruit"| hub
    siem -->|"identifiant de règle"| ar
    chat -.->|"enquête"| dfir

    coffre -.-> sops
    backup -.-> quar
    siem -.->|"sondes"| preuve
    backup -.->|"sondes"| preuve

Le schéma se lit de haut en bas, dans l'ordre où une requête hostile rencontre les défenses. Les couches 5 et 6 ont chacune leur page : Détection, Réponse, Continuité et Conformité et preuves.

1 · Périmètre et exposition¶

La chaîne d'entrée¶

Une requête venue d'Internet traverse quatre équipements avant d'atteindre un conteneur : le résolveur public, le routeur qui fait le NAT, un proxy de bordure hébergé sur le NAS, puis un proxy interne sur l'hôte Docker principal.

La bordure WAN n'est pas l'hôte Docker

C'est le point le plus contre-intuitif de l'architecture, et celui qui coûte le plus d'heures quand on l'oublie. Deux conséquences :

Tout filtrage L3 posé sur l'hôte Docker ne bloque rien venant d'Internet : l'adresse source qu'il voit est celle du proxy de bordure, jamais celle du client.
Interroger un service par son nom depuis le LAN ne teste pas le chemin WAN. La résolution est dédoublée : le même nom pointe ailleurs selon d'où on demande. Tester le WAN suppose de forcer la résolution vers l'adresse publique.

Détail du chemin complet : Chaîne reverse proxy et DNS et résolution.

Certificats¶

Les certificats sont émis par ACME en défi DNS-01, via l'API du registrar. Ce choix a une conséquence de sécurité directe : aucun enregistrement A public n'est nécessaire pour émettre un certificat. Un service peut donc être servi en TLS sur le LAN sans que son nom soit jamais publié dans une zone DNS publique — la transparence des certificats reste, elle, publique.

Détection et remédiation applicative¶

CrowdSec lit les journaux d'accès du proxy interne, décide, et fait appliquer sa décision par un module intégré au proxy, qui répond 403. Il consomme aussi une liste de blocage communautaire.

Il a été déployé après un audit de surface publique qui a compté 74 noms exposés et aucun système de détection d'intrusion. C'est la seule couche qui agit sur le contenu d'une requête HTTP ; en amont, le NAT ne sait rien du HTTP.

Ce que CrowdSec ne peut pas voir

Le proxy interne ne voit l'adresse réelle du client que si le proxy de bordure la transmet dans un en-tête, et que si le proxy interne fait confiance à cet en-tête. Une erreur de configuration à cet endroit ne produit aucune panne : elle fait simplement bannir la bordure, ou ne bannir personne. Le symptôme est un système qui a l'air de fonctionner.

2 · Identité et accès¶

Un fournisseur d'identité unique (Authentik) porte les comptes, les groupes, le second facteur et les sessions. Deux modes de branchement coexistent, et l'ordre de préférence est une règle, pas un goût :

Mode	Ce que le service apprend	Quand l'utiliser
OIDC / SAML natif	Identité, groupes, rôles, déconnexion propre	Par défaut, dès que le service le supporte
`forward_auth`	Rien. Un mur devant l'application	Dernier recours, pour un service sans notion de compte

Ne jamais poser les deux sur le même service

Le proxy d'authentification intercepte les chemins de rappel OAuth avant qu'ils n'atteignent l'application. Le résultat est une boucle de connexion produite par trois composants qui ont tous l'air sains — chacun fait exactement son travail. C'est un défaut qui ne se lit dans aucun journal d'erreur.

Le login local d'un service n'est fermé qu'après une première connexion fédérée réussie. L'ordre inverse enferme dehors.

3 · Réseau privé¶

Les hôtes ne se joignent pas par leurs adresses de LAN quand ils sortent du LAN. Un maillage WireGuard les relie, avec un plan de contrôle auto-hébergé posé sur le VPS public — donc sans dépendance à un service tiers pour l'appartenance au réseau.

Deux propriétés en découlent :

Un hôte hors du LAN parle au SIEM par l'adresse du maillage, jamais par une adresse locale qui n'existe pas pour lui. C'est une source d'erreur classique lors d'un enrôlement d'agent.
Le nom du plan de contrôle et le suffixe des machines doivent être deux domaines distincts. Un client prend le contrôle de la résolution du suffixe : un plan de contrôle qui vivrait dessous deviendrait injoignable depuis un nœud connecté. Le serveur refuse d'ailleurs de démarrer dans cette configuration.

Un filtrage DNS (listes de blocage, réécritures internes) sert le LAN et double la résolution : le même nom rend l'adresse interne à l'intérieur, l'adresse publique à l'extérieur.

Un appareil dans le sous-réseau annoncé

Activer l'acceptation des routes sur une machine déjà située dans le sous-réseau que le maillage annonce lui fait perdre l'accès au réseau. Le symptôme ressemble à une panne d'Internet ; la cause est une route apprise qui recouvre la route locale.

4 · Contenu : antivirus et analyse de fichiers¶

Un seul moteur, pour une raison qui n'est pas l'économie¶

Le parc fait tourner un unique daemon antivirus. Les autres machines n'installent aucun binaire, aucune base de signatures : elles envoient le contenu sur un canal dédié (protocole INSTREAM) et reçoivent un verdict.

Pourquoi un seul, et pourquoi un miroir privé

Le parc dispose d'une seule adresse IP publique. Plusieurs clients de mise à jour interrogeant le réseau de distribution des signatures depuis cette adresse finissent en limitation de débit, puis en liste noire.

Le symptôme n'est pas une erreur : c'est une base de signatures qui vieillit en silence. Un antivirus dont la base a trois mois répond, répond vite, et répond faux.

Un seul processus du parc sort donc vers Internet pour récupérer les signatures, deux fois par jour, et les sert à tout le monde depuis un miroir interne. Les autres ont l'accès Internet coupé par configuration.

Le client journalise, pas le serveur¶

En INSTREAM, le daemon ne reçoit qu'un flux d'octets : son propre journal dit qu'une signature a été trouvée dans « un flux », sans chemin ni machine. La seule partie qui détient l'information complète est le client. C'est donc lui qui écrit dans le journal système, au format exact qu'attend le décodeur du SIEM.

Conséquence pour le périmètre

Un moteur central est un service réseau : il ne voit que ce qu'on lui envoie. Un hôte sans client n'est pas « protégé » — il est absent du périmètre. La couverture se lit donc dans la liste des clients et de leurs zones surveillées, jamais dans l'état du daemon.

Détection : quarantaine, pas suppression¶

Un fichier détecté est déplacé en quarantaine sur un espace partagé du NAS, en droits restreints, avec une rétention. La suppression existe mais n'est pas le défaut, pour deux raisons mesurées sur ce parc :

des faux positifs réels ont déjà visé des fichiers sains (un livre numérique, des archives d'une application) ; une suppression aurait été sans recours ;
certaines zones surveillées sont synchronisées vers d'autres appareils : sortir un fichier de la zone propage sa disparition partout. Voulu pour une vraie menace, destructeur pour un faux positif.

Analyse statique profonde¶

Là où l'antivirus rend un verdict sur un fichier, un second moteur d'analyse statique fait ce que l'antivirus ne fait pas : il déplie récursivement (archive dans archive, document, objet embarqué, macro, exécutable) et passe des dizaines de scanners sur chaque objet extrait, dont un moteur de règles YARA avec plusieurs milliers de règles. Aucun code n'est exécuté : c'est de l'analyse statique, pas un bac à sable.

Un jeu de règles qui ne charge pas ne dit rien

Le moteur compile son répertoire de règles en un seul bloc. Une seule règle invalide invalide tout le jeu. Le conteneur reste alors en bonne santé apparente et ne détecte plus rien — panne parfaitement silencieuse.

Un compteur de règles chargées ne suffit pas à la voir : il dit combien de règles sont en mémoire, pas si elles reconnaissent encore quelque chose. Le témoin est une règle canari, placée parmi les autres, dont le déclenchement est exigé à chaque passage — c'est lui qui distingue « rien à signaler » de « plus rien ne fonctionne ». Voir Détection.

5 · Le poste de travail macOS¶

Le poste macOS est traité comme un hôte du parc, pas comme une exception.

Couche	Rôle
Agent SIEM	Intégrité des fichiers, contrôles de configuration, remontée au manager
Client antivirus	Envoi du contenu des zones à risque au moteur central, sur planification
Pare-feu sortant par processus	Little Snitch — chaque binaire demande l'autorisation de sortir
Énumérateur de persistance	KnockKnock, branché sur le moteur antivirus du parc

KnockKnock relié au moteur central¶

KnockKnock énumère tout ce qui se lance tout seul sur un Mac : agents et démons de démarrage, extensions de noyau, greffons d'autorisation, éléments de connexion, extensions de navigateur, tâches planifiées. C'est la question « qu'est-ce qui s'exécute sans que je le demande », qui est exactement la question qu'on pose après une compromission.

En l'état, l'outil interroge un service public de réputation par empreinte de fichier. Le parc utilise une version dérivée qui envoie le contenu au moteur antivirus interne à la place :

rien ne sort du réseau local, ni empreinte ni contenu ;
aucune clé d'API n'est nécessaire, donc aucune limitation de débit ;
le verdict porte sur le contenu réel du fichier, pas sur ce qu'un tiers a déjà vu.

Un pare-feu sortant par processus rend les pannes muettes

Sur ce poste, tout nouvel outil réseau est muet tant qu'aucune règle ne l'autorise, et l'échec ressemble exactement à une panne réseau : la connexion est retenue en attente d'une décision affichée dans une fenêtre — invisible pour une tâche planifiée ou une session distante.

D'où une règle de conception : une tâche sans interface passe par un interpréteur déjà autorisé, jamais par un binaire fraîchement installé. Une application interactive, elle, peut ouvrir sa propre connexion : quelqu'un est là pour répondre à la fenêtre.

Accès disque complet

L'énumération complète des points de persistance exige l'autorisation « accès disque complet », accordée par binaire et uniquement à la main, dans les réglages du système. Aucune commande ne peut l'accorder à distance — c'est une propriété du système d'exploitation, pas une limitation de l'outil.

Un audit partiel se signale comme partiel

L'énumérateur parcourt une vingtaine de catégories en série. Il suffit qu'un appel système reste bloqué en attente ininterruptible — un état où le processus ne répond plus ni à une demande d'arrêt ni à un arrêt forcé — pour qu'une seule catégorie emporte tout l'audit. Une tâche planifiée qui « tue puis relance » empile alors un processus de plus à chaque passage.

La règle retenue : une catégorie qui bloque est écartée explicitement, les autres s'exécutent, et la liste des catégories non parcourues part dans le corps de la notification. Un audit dont une partie n'a pas été parcourue n'est pas un audit vert — et « rien de détecté » ressemble trait pour trait à « pas regardé ».

6 · Détection, corrélation, alerte¶

Le SIEM¶

Un manager SIEM/XDR collecte les agents de tous les hôtes. Il apporte quatre choses que les journaux bruts ne donnent pas :

surveillance d'intégrité des chemins sensibles ;
contrôles de configuration contre des référentiels de durcissement ;
détection de vulnérabilités par corrélation entre paquets installés et bases CVE ;
corrélation et cartographie sur une matrice de techniques d'attaque.

Une seconde chaîne collecte journaux et métriques vers un moteur de recherche distinct. Les deux ne servent pas la même question : l'une répond « est-ce une attaque connue », l'autre « qu'est-ce qui s'est passé, minute par minute ».

Au-delà du SIEM¶

Le SIEM voit l'état des hôtes. Trois moteurs couvrent ce qu'il ne voit pas : Falco observe les appels système des conteneurs pendant leur exécution, Suricata applique des signatures au trafic réseau, et Velociraptor permet d'interroger toute la flotte pendant un incident. Leur rôle, leurs témoins et leurs limites de conception sont décrits dans Détection et Réponse.

Le chemin d'une détection¶

sequenceDiagram
    autonumber
    participant Z as Zone surveillée
    participant C as Client de scan
    participant M as Moteur antivirus
    participant J as Journal système
    participant A as Agent SIEM
    participant S as Manager SIEM
    participant H as Répartiteur d'alertes
    participant D as Zulip + Telegram

    Z->>C: fichier nouveau ou modifié
    C->>M: contenu, en INSTREAM
    M-->>C: verdict + signature
    Note over C: le serveur ignore le chemin<br/>et la machine : c'est le client<br/>qui détient le contexte
    C->>Z: mise en quarantaine
    C->>J: ligne au format attendu par le décodeur
    A->>J: lecture
    A->>S: événement
    S->>S: règle → niveau de sévérité
    S->>H: intégration filtrée par identifiant de règle
    H->>D: un envoi, deux destinations

Deux pièges dans cette chaîne, tous deux silencieux

Le filtre d'intégration. Il vise un identifiant de règle, jamais un groupe. Un filtre par groupe embarque des règles voisines et poste des doublons sur le même canal.

Le niveau de sévérité. Il décide de ce qui part. Un niveau trop haut fait poster deux fois par deux chemins différents ; un niveau trop bas fait taire la détection. Ce réglage se vérifie en provoquant volontairement une détection avec un fichier de test inoffensif, pas en relisant la configuration.

La notification¶

Toutes les alertes convergent vers un répartiteur unique : un émetteur poste une fois, le répartiteur duplique vers les destinations. Le jour où une destination change, seule la carte des canaux bouge — aucun émetteur n'est à retoucher. Le détail — et ce que le parc fait tout seul quand une règle le prévoit — est dans Réponse.

Une alerte qui se répète ne dit plus rien

Toute notification récurrente se pose avec une hystérésis et la durée de la série. Une alerte qui tombe toutes les heures depuis trois semaines n'est plus une alerte : c'est du bruit que l'œil filtre, et elle masque la vraie.

7 · Secrets¶

Où	Quoi	Propriété
Coffre auto-hébergé	Mots de passe, jetons, clés, notes	Source de vérité, déverrouillé par un service dédié
Fichiers chiffrés dans le dépôt	Variables d'environnement des stacks	Chiffrées au repos, versionnées, déchiffrables au déploiement
Analyse avant commit et avant envoi	Plusieurs détecteurs de secrets empilés sur chaque diff, puis tout l'historique en intégration continue	Bloque avant que le secret n'entre dans l'historique
Scan des hôtes	Secrets restés en clair sur les disques	Sévérité portée par les permissions du fichier

Trois règles qui ne se négocient pas :

Les fichiers d'environnement ne sont ni lus ni versionnés en clair.
Un secret ne transite jamais par une URL. La trace d'erreur d'un moteur de workflow journalise l'URL résolue, jetons compris — et cette trace survit à la rotation du secret.
Une valeur lue depuis le coffre passe par un tube, jamais par la ligne de commande : elle ne traverse ni la table des processus, ni l'historique du shell, ni la transcription d'une session assistée.

Procédure : Lire un secret du coffre.

8 · Chaîne d'approvisionnement¶

C'est la surface d'attaque qui a le plus bougé ces dernières années, et celle qu'aucun pare-feu ne couvre.

Quarantaine de versions. Aucune dépendance publiée depuis moins de sept jours n'est installée. C'est la seule défense qui aurait arrêté les compromissions de paquets largement diffusés de ces derniers mois : elles ont toutes été détectées et retirées en quelques heures à quelques jours. Le délai transforme une course en non-événement.

La quarantaine se règle à trois endroits différents

Les trois gestionnaires de paquets de l'écosystème portent ce réglage, mais avec trois unités et trois emplacements — l'un en jours, l'autre en minutes, le troisième en secondes ; l'un globalement à la machine, l'autre par dépôt seulement.

Conséquence pratique : un dépôt peut n'avoir aucune quarantaine, et rien ne le signale. Le fichier de configuration qui la pose fait donc partie du squelette d'un nouveau projet, au même titre que le fichier d'exclusion de versionnement.

Images figées par empreinte. Les images de conteneurs sont épinglées par leur condensat, pas par une étiquette. Une étiquette est un pointeur mutable : stable d'aujourd'hui n'est pas stable de demain, et rien dans le fichier de composition ne le montre.

Registre interne. Les images construites maison vivent dans un registre privé, et un miroir de registre absorbe les images publiques — ce qui supprime autant de dépendances directes à un service tiers au moment du démarrage.

Vulnérabilités connues et inventaire. Les images en service et les dépôts sont scannés chaque jour, et chaque trouvaille est triée selon trois axes — sévérité, exploitation constatée, exposition — plutôt que sur sa seule note. Chaque image en service a son SBOM. Détail : Détection.

9 · Correctifs et exposition matérielle¶

Correctifs. Les hôtes suivent une rotation de mises à jour non surveillées, étalée dans la nuit avec un décalage aléatoire par hôte. Les composants dont la mise à jour redémarre un service critique sont exclus volontairement et traités à la main.

Une montée de version majeure désactive les dépôts tiers

C'est arrivé sur ce parc : une montée de version du système a mis de côté les dépôts tiers, laissant trois mois sans mise à jour de sécurité sur les composants concernés — sans aucune erreur visible. Après toute montée majeure, la présence des dépôts se vérifie explicitement.

Disques. L'état SMART de tous les disques physiques est historisé et alerte avant la panne. Un point d'attention : les indicateurs constructeurs ne parlent pas tous la même langue, et un statut « en échec » peut n'être qu'une table de correspondance mal interprétée. Un remplacement se décide sur une tendance, jamais sur un seul relevé.

Sauvegardes. Chaque hôte pousse un dépôt chiffré vers le NAS, avec rétention, vérification d'intégrité et restauration par navigation. Le chiffrement est fait par le client, avant l'envoi : le serveur de dépôt ne détient pas les clés. Le dépôt refuse toute suppression venue des hôtes, des copies existent hors du site, et une restauration réelle est chronométrée régulièrement : voir Continuité.

10 · Les flux, sans les adresses¶

De	Vers	Canal	Objet
Client Internet	Proxy de bordure	HTTPS	Toute requête publique
Proxy de bordure	Proxy interne	HTTPS	Routage applicatif
Proxy interne	Fournisseur d'identité	HTTP interne	Authentification
Proxy interne	CrowdSec	API locale	Décision de blocage
Clients de scan	Moteur antivirus	TCP dédié, INSTREAM	Contenu à analyser
Processus de mise à jour	Distribution de signatures	HTTPS sortant	Seule sortie Internet de la chaîne antivirus
Agents	Manager SIEM	Canal chiffré de l'agent	Événements, intégrité, inventaire
Agents hors LAN	Manager SIEM	Idem, via le maillage	Idem
Manager SIEM	Répartiteur d'alertes	HTTP interne	Alertes filtrées par identifiant de règle
Répartiteur	Messagerie d'équipe	HTTPS sortant	Notification, deux destinations
Hôtes	Serveur de dépôt de sauvegarde	HTTPS interne	Données déjà chiffrées
Hôtes	Coffre de secrets	HTTPS interne	Lecture d'un secret, par tube
Détection à l'exécution	Fichier local, puis répartiteur	Local, puis HTTP interne	Événements d'appels système, notifiés après mesure du bruit
Point de convergence du trafic	IDS réseau	Écoute passive	Signatures appliquées au passage
Clients d'investigation	Serveur d'investigation	Canal chiffré, via le maillage hors LAN	Requêtes et résultats d'enquête
Lanceur de sondes	Registre de preuves	API authentifiée	Verdicts datés
Registre de preuves	Deux dépôts git distants	HTTPS sortant	Ancre quotidienne

Ce que cette architecture ne couvre pas¶

Une note d'architecture qui n'énumère que ses forces est une brochure. Les limites structurelles — celles qui tiennent aux choix d'architecture, pas à l'état du jour — en clair :

Le NAS est à la fois la bordure WAN, le stockage principal et le dépôt de sauvegarde. C'est un point de défaillance unique assumé, et c'est aussi la machine la plus exposée. C'est pourquoi le dépôt de sauvegarde y refuse toute suppression venue des hôtes, et pourquoi des copies existent hors du site.
Une seule adresse IP publique. Toute la chaîne de mise à jour de signatures en dépend, et un bannissement côté fournisseur dégrade la détection sans erreur visible.
Pas de bac à sable dynamique. L'analyse de fichiers est statique. Un binaire qui ne révèle son comportement qu'à l'exécution passe les deux moteurs.
La couverture antivirus est une liste de zones, pas une propriété d'hôte. Un répertoire nouvellement créé n'est pas surveillé tant que personne ne l'a ajouté.
Le poste macOS dépend d'autorisations accordées à la main (accès disque complet, règles de pare-feu sortant). Une réinstallation les perd toutes, en silence.
CrowdSec agit sur le HTTP. Un service exposé sur un autre protocole n'est couvert que par le filtrage réseau.