Conformité & souveraineté

Le registre scellé alimente votre registre des incidents avec des événements horodatés (Loi 25).

Ce document distingue ce qui est livré de ce qui est prévu.

En clair

• La détection tourne sur votre serveur. Aucun envoi à un service central CrowdSec. Seules les métadonnées de sécurité utiles à votre console y remontent, détaillées ci-dessous.
• Ces métadonnées comprennent des adresses IP de visiteurs. Elles sont traitées chez l’hébergeur de la console. D’autres tiers ne les reçoivent que selon vos réglages : pool collectif, enrichissement de réputation, canaux d’alerte (mail, Slack, Discord, Teams, Google Chat, PagerDuty).
• Un registre d’incidents scellé. Une altération rétroactive d’une ligne scellée devient détectable. Le registre contient ce que les agents ont rapporté.
• Un rapport Loi 25 à produire depuis la console, avec une preuve d’intégrité.

Souveraineté : pas de Central API CrowdSec

La règle produit est simple et non négociable : aucun agent AtriShield ne communique avec le Central API CrowdSec (CAPI). Elle est appliquée à plusieurs niveaux (défense en profondeur) :

• Côté agent : tout appel cscli passe par un wrapper qui refuse la sous-commande capi.
• Service masqué : crowdsec_capi.service est masqué (systemctl mask --now, idempotent) à chaque synchronisation, pour empêcher tout ré-enrôlement.
• Identifiants vides : online_api_credentials.yaml est livré vide dans le bundle (url:"", login:"", password:"") et écrasé de façon atomique à chaque cycle.

Conséquence pratique : la détection s’appuie sur les règles livrées par votre console, exécutées sur votre serveur. Les résultats remontent à la console AtriShield, jamais à CrowdSec.

Résidence des données

• Sur votre serveur : trafic complet, journaux HAProxy, moteur de détection.
• Dans l’infrastructure de la console AtriShield : en base, registre d’incidents, alertes, passages de bons bots et d’IP de confiance, cloisonnés par organisation ; en mémoire, observations de trafic sur une fenêtre courte.
• Hébergement de la console : Beauharnois, au Québec. Durée de conservation : selon contrat.

Ce que l’agent transmet à la console

L’agent ne transmet pas le corps des requêtes. L’URL et la page d’origine sont transmises telles quelles, paramètres compris. Il transmet :

• Signal de vie : palier, version du bundle, faits système, versions de la pile, état de souveraineté, agrégats AppSec.
• Inventaire technique : nom d’hôte, système, noyau, paquets installés.
• Alertes et décisions du moteur local, lues à travers le tunnel ou envoyées à la console : adresse IP source, pays, scénario, nombre d’événements, dates, type et origine de décision ; hôte et User-Agent selon la version de la console.
• Observations par requête (Business et Enterprise) : adresse IP, méthode, URL demandée avec ses paramètres, hôte, statut, User-Agent, page d’origine, par lots, champs tronqués. Un paramètre d’URL qui contient une donnée personnelle est transmis tel quel.
• Touches de honeypot (Enterprise) : adresse IP, piège touché, User-Agent et empreinte du client selon la version.

Connexions de l’agent vers des tiers

• packagecloud.io et le hub CrowdSec, pour installer le moteur et ses règles. Ces connexions ne portent pas de données de trafic.
• Aucun appel au Central API de CrowdSec.

Options à activer

• Enrichissement de réputation externe : la console interroge AbuseIPDB avec votre clé, si votre équipe l’autorise. L’adresse IP interrogée est alors transmise à ce service.
• Pool collectif (Business et Enterprise) : échange d’adresses IP malveillantes entre organisations ayant donné leur accord.

Le registre d’incidents scellé

Chaque événement de sécurité est consigné dans le registre : type d’événement (décision, alerte, honeypot, bon bot, throttle, appsec), IP source, scénario, méthode/chemin HTTP, code de réponse, pays, horodatage. L’ingestion est déduplicante et l’IP source est validée.

Scellement

Le registre est rendu vérifiable a posteriori par un scellement de type arbre de Merkle chaîné :

• les événements sont scellés par lots, chaque sceau portant la racine de Merkle du lot, l’empreinte du sceau précédent et sa propre empreinte de sceau ;
• les empreintes sont calculées en HMAC-SHA256 avec des domaines séparés (leaf / node / seal) pour prévenir les attaques par pré-image ;

Vérification d’intégrité

Une opération de vérification recalcule, pour chaque sceau, la racine de Merkle et le chaînage, puis les compare aux valeurs stockées (comparaison à temps constant). Toute divergence (nombre d’événements, racine, chaînage) est rapportée (sceau concerné + motifs). Une modification rétroactive d’un événement casse la chaîne et devient détectable.

Loi 25 (Québec) : le rapport de conformité

La console produit un rapport de conformité Loi 25 structuré, par organisation et sur une période donnée. Le générateur est sans effet de bord (aucune écriture en base) : il lit les preuves et les agrège. Le rapport comporte quatre sections plus un bloc d’intégrité :

1. Registre des traitements : agents concernés, niveau d’offre, rétention.
2. Décisions automatisées : comptage des décisions (bans, throttle, challenge) sur la période.
3. Journal des bris : nombre d’événements, vérification de la chaîne d’audit et du sceau de Merkle.
4. Évaluation des facteurs relatifs à la vie privée (ÉFVP / PIA) : chiffrement, souveraineté, CAPI désactivé.

Le bloc d’intégrité atteste l’état vérifiable des preuves (chaîne d’audit recalculée, sceau de Merkle vérifié) et porte une empreinte HMAC-SHA256 du rapport (sceau du rapport lui-même).

Ce rapport est livré : le registre scellé, la vérification d’intégrité et l’agrégation Loi 25 existent dans le produit.

Ce qui alimente le registre

Livré. Le registre d’incidents est alimenté par les décisions de sécurité observées au bord : bans et alertes CrowdSec, blocages AppSec (OWASP / virtual-patch), touches de honeypot, bons bots, throttle. C’est un registre d’incidents de sécurité (WAF / IDS / IPS / pièges), scellé et vérifiable.

Bientôt. La détection automatique d’exfiltration de données personnelles (analyse pour repérer une fuite de renseignements personnels et alimenter automatiquement le registre des bris) n’est pas encore dans le produit. Aujourd’hui, le journal reflète les décisions du WAF et du moteur de détection au bord, pas une détection dédiée d’exfiltration PII. Cette capacité est prévue.

Technique

• Registre d’incidents : journal cloisonné par organisation, ingestion avec déduplication, validation de l’IP source.
• Scellement : arbre de Merkle chaîné, HMAC-SHA256 à domaines séparés (feuille, nœud, sceau), scellement par lots avec fenêtre de stabilisation et verrou de sérialisation.
• Vérification : recalcul de la racine, du chaînage et du comptage, comparaison à temps constant, rapport de défaillances par sceau.
• Loi 25 : rapport limité à votre organisation, sans écriture en base. Bloc d’intégrité : chaîne d’audit recalculée, sceau de Merkle vérifié, empreinte HMAC-SHA256 du rapport.
• Souveraineté CAPI : appels cscli filtrés, service CAPI masqué à chaque synchronisation, identifiants CAPI rendus vides dans le bundle et gérés par réconciliation.
• Détection automatique d’exfiltration de données personnelles : prévue, pas encore livrée. Le registre est alimenté par les décisions du pare-feu applicatif, de la détection et des honeypots.

Souveraineté & architecture

La configuration critique passe par un canal signé (bundle Ed25519, réconciliation, moindre privilège). Un tunnel chiffré relie aussi la console à l’agent.