Sécurité, architecture et résilience de LogsCord

Version 1.0 — 12 août 2026

LogsCord traite des événements Discord susceptibles de contenir des données sensibles pour l’administration et la sécurité d’une communauté : messages supprimés ou modifiés, événements de modération, changements de rôles, activité vocale, événements d’audit et autres données nécessaires à l’investigation d’un incident.

Notre modèle de sécurité repose sur un principe simple :

> Aucun composant ne doit disposer de plus de privilèges, de données ou de connectivité réseau que ce qui est strictement nécessaire à sa fonction.

La sécurité de LogsCord repose sur plusieurs couches indépendantes :

• isolation des composants ;
• segmentation réseau ;
• moindre privilège ;
• identifiants temporaires ;
• contrôle des accès ;
• chiffrement ;
• protection de la façade Internet ;
• sauvegardes immuables ;
• validation régulière des restaurations ;
• mécanismes empêchant la réapparition de données personnelles supprimées après restauration.

Cette page décrit les principales mesures techniques appliquées par LogsCord.

Pour des raisons de sécurité, certains détails ne sont volontairement pas publiés, notamment les adresses IP, identifiants d’infrastructure, seuils de détection, règles firewall détaillées, secrets, procédures d’accès d’urgence et paramètres pouvant faciliter une attaque.

1. Principes de sécurité

Moindre privilège

Chaque service dispose uniquement des permissions nécessaires à sa fonction.

Un collecteur de logs peut, par exemple, insérer des événements dans la base de données sans disposer d'un accès général permettant de relire l'historique enregistré, de supprimer des événements ou d'administrer la base.

À l'inverse, une API de recherche peut lire certaines données nécessaires à une investigation sans disposer des permissions d'un collecteur.

Séparation des responsabilités

La collecte, le stockage, la recherche, le temps réel, la façade Internet, la gestion des secrets et les mécanismes de sauvegarde sont assurés par des composants distincts.

La compromission d'un composant ne doit donc pas automatiquement donner accès à l'ensemble du système.

Segmentation réseau

Les communications internes sont explicitement autorisées selon les besoins de chaque composant.

Un service n'est pas autorisé à initier une connexion vers un autre service simplement parce qu'ils appartiennent à la même infrastructure.

Secrets temporaires

Lorsque cela est possible, les services n'utilisent pas de mots de passe permanents.

Des identifiants de courte durée sont générés automatiquement et expirent même s'ils ne sont pas explicitement révoqués.

Défense en profondeur

Aucune mesure n'est considérée comme suffisante à elle seule.

Un contrôle d'accès applicatif est complété par des permissions au niveau de la base, des restrictions réseau, des secrets temporaires, du chiffrement et des mécanismes de surveillance.

2. Principaux services et technologies

Le KMS est exploité directement par LogsCord sur une infrastructure bare metal dédiée et durcie. Il utilise un TPM 2.0 physique comme racine matérielle de confiance et les clés racines protégées par le TPM sont configurées comme non exportables.

LogsCord n'utilise pas ClickHouse Cloud pour le stockage principal décrit sur cette page.

Les serveurs bare metal concernés sont exploités dans le Data Center Park Hetzner de Nuremberg, en Allemagne.

3. Collecte des événements Discord

3.1 Collecteurs

Les événements sont reçus par des collecteurs spécialisés.

La majorité des événements provient passivement du Gateway Discord. Discord utilise son Gateway pour transmettre en temps réel aux applications les événements concernant les serveurs auxquels elles sont connectées.

Certains événements nécessitent cependant une collecte active.

LogsCord peut notamment interroger certaines ressources de l'API Discord pour reconstruire un contexte qui n'est pas directement fourni par un événement Gateway, par exemple dans le cadre des invitations ou de certains événements d'audit.

Les opérations actives sont limitées aux données nécessaires aux fonctionnalités activées.

3.2 Sharding

Les collecteurs sont répartis en plusieurs shards.

Chaque shard fonctionne dans un processus distinct et dans un environnement conteneurisé distinct.

Cette architecture permet :

• de répartir la charge provenant du Gateway Discord ;
• de limiter l'impact d'une défaillance ;
• de réduire le périmètre d'une éventuelle compromission ;
• d'éviter qu'un collecteur compromis dispose automatiquement du contrôle des autres collecteurs.

3.3 Permissions minimales

Un collecteur ne dispose pas d'un compte ClickHouse général.

Ses identifiants sont générés par le système de gestion des secrets de LogsCord et disposent d'une durée de validité maximale de 24 heures.

Ces identifiants donnent uniquement accès aux opérations nécessaires à l'ingestion.

En particulier, un collecteur n'a pas besoin d'un droit général de lecture sur l'historique ClickHouse.

Le renouvellement des identifiants est automatisé.

La compromission temporaire d'un collecteur ne transforme donc pas automatiquement ce composant en outil de consultation de l'historique enregistré.

4. Chemin d'ingestion

Après validation et normalisation, un événement peut suivre deux chemins distincts selon les fonctionnalités nécessaires.

mermaidflowchart LR
    Discord["Discord Gateway / API"] --> Collector["Collecteur"]
    Collector --> Validation["Validation<br/>et normalisation"]

    subgraph Persistence["Stockage durable"]
        CH[("ClickHouse")]
    end

    subgraph Realtime["Diffusion temps réel"]
        Decision{"Consommateur<br/>abonné ?"}
        Broker["Message Broker"]
        API["API temps réel"]
        Client["Client autorisé"]
    end

    Validation --> CH
    Validation --> Decision
    Decision -->|Oui| Broker
    Decision -->|Non| Stored["Stockage uniquement"]
    Broker --> API
    API -->|SSE| Client

Stockage persistant

L'événement est transmis à ClickHouse afin de devenir interrogeable par les fonctions de recherche, de timeline et d'investigation de LogsCord.

Temps réel

Lorsqu'au moins un consommateur est abonné au flux temps réel concerné, une copie de l'événement est également transmise au message broker.

Le broker transmet alors l'événement au composant API responsable du temps réel.

L'API peut ensuite distribuer les événements autorisés au client via Server-Sent Events (SSE).

ClickHouse et le broker temps réel remplissent donc deux fonctions différentes :

• ClickHouse constitue le stockage durable et interrogeable ;
• le broker transporte les événements nécessaires à leur diffusion immédiate.

Une interruption du flux temps réel ne modifie pas les règles de conservation du stockage durable.

5. ClickHouse et isolation des données

LogsCord utilise ClickHouse comme moteur de stockage analytique de ses événements.

ClickHouse est particulièrement adapté aux grands volumes d'événements append-oriented et aux recherches analytiques effectuées sur des périodes importantes.

5.1 Multi-tenancy

Les données sont associées à leur tenant et cette identité doit être conservée tout au long du chemin d'accès.

LogsCord adapte le niveau d'isolation au volume et à l'offre concernée.

Les architectures possibles comprennent notamment :

• une table partagée avec identification explicite du tenant ;
• des politiques d'accès au niveau des lignes ;
• des tables distinctes ;
• des bases distinctes.

Les environnements à forte volumétrie peuvent bénéficier d'un niveau d'isolation renforcé afin de limiter les interactions de charge entre tenants.

Les clients Pro générant plus de 30 000 événements par jour peuvent notamment être concernés par cette architecture renforcée.

Quel que soit le modèle physique retenu, l'identité du tenant reste une propriété obligatoire du contrôle d'accès.

5.2 Environnements Enterprise

Les environnements Enterprise nécessitant un niveau de disponibilité supérieur disposent de trois réplicas de données.

La réplication et les sauvegardes remplissent volontairement des fonctions différentes.

La réplication protège principalement contre certaines défaillances de nœuds et contribue à la continuité du service.

Elle ne remplace pas une sauvegarde : une suppression accidentelle, une corruption logique ou une opération administrative erronée peut également être répliquée.

Les sauvegardes restent donc indépendantes des réplicas.

6. API de recherche

L'API LogsCord peut effectuer les recherches nécessaires directement dans ClickHouse.

Comme pour les collecteurs, ses identifiants de base de données sont régulièrement renouvelés.

Les permissions accordées à l'API sont différentes de celles accordées aux collecteurs.

Cette séparation permet notamment qu'un credential destiné à l'insertion ne devienne pas automatiquement un credential permettant l'investigation, et inversement.

Les autorisations applicatives sont vérifiées avant d'exposer les données correspondant à une requête.

7. Isolation réseau interne

L'infrastructure applique une politique réseau restrictive.

Les communications ne sont pas ouvertes de manière générale entre tous les services.

Elles sont autorisées selon la direction et la fonction nécessaires au fonctionnement du système.

mermaidflowchart LR
    subgraph Ingestion["Zone d'ingestion"]
        Collector["Collecteur"]
    end

    subgraph Data["Zone de données"]
        CH[("ClickHouse")]
        Broker["Message Broker"]
    end

    subgraph Access["Zone d'accès"]
        API["API LogsCord"]
    end

    Collector -->|INSERT uniquement| CH
    Collector -->|Événements autorisés| Broker
    Broker -->|Temps réel| API
    API -->|Requêtes autorisées| CH

    Policy["Politique par défaut<br/>tout autre flux est bloqué"]
    Policy -.-> Collector
    Policy -.-> CH
    Policy -.-> API

Le fait que l'API puisse interroger ClickHouse ne signifie donc pas que ClickHouse doit pouvoir initier une connexion vers l'API.

Cette séparation réduit les possibilités de déplacement latéral après la compromission d'un composant.

8. Sécurité des conteneurs

Les services applicatifs sont conteneurisés lorsque leur fonction s'y prête.

Les conteneurs sont exécutés avec les capacités système minimales nécessaires.

L'objectif est qu'une compromission applicative reste confinée autant que possible au service concerné et ne fournisse pas automatiquement un contrôle sur l'hôte ou sur les autres composants.

Les permissions réseau sont également définies en fonction du rôle du conteneur.

La simple appartenance à un réseau interne n'accorde pas un droit général de communication avec les autres services.

Les secrets nécessaires au fonctionnement d'un conteneur sont fournis avec le périmètre et la durée de vie nécessaires à sa fonction plutôt que d'être partagés globalement entre les services.

9. Façade Internet : Cloudflare

Les applications publiques de LogsCord ne sont pas directement exposées comme des services d'origine traditionnels.

LogsCord utilise Cloudflare Tunnel pour relier sa façade publique à son infrastructure.

Le modèle repose sur des connexions établies depuis l'origine vers le réseau Cloudflare plutôt que sur l'ouverture classique de ports entrants vers l'application.

mermaidflowchart LR
    User["Utilisateur"] --> CF["Cloudflare"]

    subgraph Edge["Protection en périphérie"]
        CF --> Security["WAF / DDoS / Rulesets"]
    end

    subgraph Origin["Accès à l'origine"]
        Tunnel["Cloudflare Tunnel<br/>connexion initiée depuis l'origine"]
        Infra["Infrastructure LogsCord"]
    end

    Security --> Tunnel
    Tunnel --> Infra

Cette architecture réduit l'exposition directe des services applicatifs.

Cloudflare traite nécessairement le trafic qui transite par sa façade dans la mesure nécessaire à l'acheminement et à l'application de ses protections.

Les conséquences relatives aux traitements de données et aux transferts internationaux sont décrites séparément dans la Politique de confidentialité et le DPA de LogsCord.

10. WAF et Rulesets

LogsCord utilise les fonctions de filtrage Cloudflare afin d'appliquer des règles de sécurité avant qu'une requête n'atteigne les services applicatifs.

Ces règles peuvent notamment appliquer des actions de blocage ou de challenge lorsque certaines conditions sont réunies.

Elles complètent les protections DDoS fournies par Cloudflare.

Les expressions complètes, seuils et signatures utilisés par LogsCord ne sont pas publiés afin de ne pas faciliter leur contournement.

11. Détection indépendante des attaques

LogsCord maintient également une couche de détection indépendante de la façade Cloudflare.

Un système externe de surveillance réseau, isolé des principaux services applicatifs et connecté au réseau privé approprié, observe les indicateurs nécessaires à la détection de comportements anormaux.

En cas d'attaque suffisamment caractérisée, ce système peut utiliser l'API Cloudflare afin de renforcer temporairement le filtrage appliqué au trafic.

Cette couche complète, mais ne remplace pas, les mécanismes natifs de protection DDoS et de WAF de Cloudflare.

12. Hetzner Robot et firewall d'infrastructure

Les serveurs dédiés sont également protégés au niveau de l'infrastructure Hetzner.

Hetzner Robot permet notamment la gestion des serveurs dédiés et de leur firewall.

Le firewall Hetzner pour Dedicated Root Servers est appliqué au niveau du port de switch et permet de filtrer le trafic selon les règles configurées.

LogsCord automatise certaines opérations d'infrastructure en utilisant l'API Hetzner Robot.

Ces contrôles sont indépendants des règles Cloudflare et des politiques réseau des conteneurs.

L'architecture de défense peut ainsi être représentée comme suit :

mermaidflowchart LR
    Internet["Internet"]

    subgraph Edge["Périphérie"]
        Cloudflare["Cloudflare<br/>WAF / DDoS / Rulesets"]
        Tunnel["Cloudflare Tunnel"]
    end

    subgraph Infrastructure["Infrastructure"]
        Firewall["Firewall Hetzner"]
        Network["Politique réseau interne"]
        Container["Conteneur isolé"]
    end

    subgraph Application["Application et données"]
        Service["Service LogsCord"]
        ACL["Contrôles d'accès aux données"]
    end

    Internet --> Cloudflare
    Cloudflare --> Tunnel
    Tunnel --> Firewall
    Firewall --> Network
    Network --> Container
    Container --> Service
    Service --> ACL

13. Chiffrement des données

LogsCord distingue :

• le chiffrement des données actives ;
• le chiffrement des communications ;
• le chiffrement des sauvegardes ;
• le chiffrement du journal de replay des opérations de confidentialité.

Les communications sensibles utilisent des canaux chiffrés lorsque les composants traversent une frontière réseau qui le nécessite.

Les sauvegardes disposent d'une protection supplémentaire et indépendante.

Les mécanismes cryptographiques particulièrement sensibles utilisent le KMS interne de LogsCord.

14. Sauvegardes ClickHouse

Les sauvegardes ClickHouse sont écrites vers un stockage objet compatible avec l'API S3 fourni par Hetzner Object Storage.

ClickHouse prend en charge les opérations de sauvegarde et restauration vers un endpoint S3 ainsi que les sauvegardes incrémentales dépendant d'une sauvegarde de base.

L'Object Storage n'est pas utilisé comme base de production principale.

Il constitue un environnement séparé destiné à la conservation des sauvegardes.

15. Chiffrement des sauvegardes : AES-256-GCM

Avant leur conservation durable, les sauvegardes LogsCord sont protégées par AES-256-GCM.

AES-GCM est un mode de chiffrement authentifié : il protège la confidentialité du contenu et permet également de détecter une modification non autorisée du ciphertext ou des données authentifiées associées.

Les clés nécessaires au déchiffrement sont gérées séparément du stockage contenant les sauvegardes.

Une personne disposant uniquement d'un accès aux objets S3 ne doit donc pas disposer automatiquement des moyens permettant de lire leur contenu.

16. Immutabilité avec S3 Object Lock

Les buckets de sauvegarde utilisent S3 Object Lock.

Pour les sauvegardes devant être considérées comme immuables, LogsCord utilise le mode Compliance.

Dans ce mode, la période de rétention appliquée à un objet ne peut pas être raccourcie avant son échéance.

Cette protection vise notamment à empêcher qu'une compromission des identifiants de sauvegarde, une erreur administrative ou un logiciel malveillant puisse simplement supprimer immédiatement les sauvegardes encore protégées.

17. Conservation des sauvegardes

Les sauvegardes standards sont conservées pendant une fenêtre de 90 jours.

À l'expiration de leur période Object Lock, elles deviennent éligibles à la suppression par les politiques de cycle de vie du stockage.

Lorsque le versioning et Object Lock sont utilisés, LogsCord tient également compte des versions non courantes afin qu'une ancienne version ne reste pas récupérable simplement parce que l'objet courant a été supprimé.

LogsCord surveille donc également l'expiration des versions susceptibles de contenir les données sauvegardées.

18. Fréquence des sauvegardes

Pour l'infrastructure standard :

Une sauvegarde incrémentale contient les changements nécessaires par rapport à sa sauvegarde de base.

La sauvegarde de base correspondante doit donc rester disponible tant qu'une sauvegarde incrémentale qui en dépend reste récupérable.

19. Sauvegardes Enterprise

Les clients Enterprise peuvent disposer d'une politique de sauvegarde renforcée.

Cette politique peut comprendre :

• un point de sauvegarde quotidien ;
• trois réplicas de données ;
• des objectifs de reprise adaptés aux engagements contractuels du client.

L'existence de trois réplicas ne remplace pas les sauvegardes S3 immuables.

Les deux mécanismes sont volontairement indépendants.

20. Une sauvegarde n'est valide que si elle peut être restaurée

LogsCord ne considère pas la simple présence d'objets dans un bucket comme une preuve suffisante de l'existence d'une sauvegarde exploitable.

Une sauvegarde peut être présente mais être incomplète, contenir une chaîne incrémentale cassée ou présenter un problème qui n'apparaîtrait qu'au moment d'une restauration.

LogsCord réalise donc des tests réguliers de restauration.

La création réussie d'un fichier ou le statut BACKUP_CREATED n'est pas, à lui seul, le critère final de validation.

21. Validation mensuelle des sauvegardes incrémentales

Lors de chaque cycle mensuel, LogsCord ne teste pas uniquement la nouvelle sauvegarde complète.

Le système vérifie également que la chaîne de sauvegardes incrémentales du cycle précédent permet effectivement de reconstruire le même état logique qu'une sauvegarde complète.

L'objectif est de vérifier que les sauvegardes incrémentales ne sont pas seulement créées, mais réellement restaurables.

22. Full backup de contrôle et branche incrémentale de contrôle

Lors du cycle mensuel de validation, deux chemins de sauvegarde représentent le même état logique des données.

mermaidflowchart TB
    Watermark["Watermark logique commun"]

    subgraph FullPath["Chemin de contrôle complet"]
        Full["Full backup"] --> RestoreFull["Restauration A"]
    end

    subgraph IncrementalPath["Chemin incrémental"]
        Incremental["Sauvegarde de base<br/>+ chaîne incrémentale"] --> RestoreIncremental["Restauration B"]
    end

    Watermark --> Full
    Watermark --> Incremental
    RestoreFull --> Compare["Comparaison de l'état logique"]
    RestoreIncremental --> Compare
    Compare --> Validation["Validation du cycle"]

L'objectif est d'obtenir le même ensemble de données par deux chemins :

1. restauration de la sauvegarde complète ; 2. restauration de la chaîne constituée de la sauvegarde de base et de ses incrémentales successives.

23. Watermark de cohérence

Les sauvegardes sont réalisées sur une base qui peut continuer à recevoir des événements.

Deux commandes de sauvegarde lancées à quelques instants d'intervalle peuvent donc observer des écritures différentes.

LogsCord ne compare par conséquent pas naïvement deux archives en supposant qu'elles représentent exactement le même état.

Le système définit un watermark logique commun pour le test.

La comparaison porte sur l'état que les deux restaurations sont censées avoir en commun jusqu'à ce watermark.

Cela évite de déclarer une sauvegarde défectueuse simplement parce qu'un événement légitime est arrivé entre deux opérations de sauvegarde.

24. Comparaison du contenu restauré

Les fichiers constituant une sauvegarde complète et une sauvegarde incrémentale sont structurellement différents.

Ils ne sont donc pas comparés octet par octet.

Les données restaurées sont comparées.

Selon la table et le type de données, les contrôles peuvent notamment comprendre :

• le nombre de lignes correspondant au même watermark ;
• les bornes minimales et maximales des identifiants ou séquences d'ingestion ;
• la présence des partitions attendues ;
• les volumes par partition ou période ;
• des empreintes déterministes calculées sur le contenu logique ;
• la cohérence des métadonnées et schémas nécessaires à la restauration.

Les empreintes sont calculées sur une représentation déterministe des données afin qu'une différence de disposition physique des parts ClickHouse ne soit pas considérée comme une différence fonctionnelle.

Le but est de vérifier que :

> les deux chemins de restauration reconstruisent le même état logique de la base.

25. Résultat d'un test de sauvegarde

Une chaîne n'est considérée comme validée que lorsque :

• la sauvegarde est accessible ;
• son déchiffrement réussit ;
• son intégrité cryptographique est vérifiée ;
• ClickHouse réussit la restauration dans un environnement isolé ;
• la chaîne incrémentale complète peut être résolue ;
• le journal de replay des opérations de confidentialité peut être appliqué ;
• les contrôles de cohérence terminent avec succès ;
• la restauration incrémentale correspond à la restauration complète pour le même watermark.

Un échec à l'une de ces étapes produit une alerte et empêche le test d'être déclaré réussi.

26. Environnement de restauration isolé

Une sauvegarde restaurée n'est jamais immédiatement considérée comme une base de production valide.

La restauration est d'abord effectuée dans un environnement isolé.

mermaidflowchart LR
    Backup["Sauvegarde"] --> Decrypt["Déchiffrement"]

    subgraph Isolated["Environnement de restauration isolé"]
        Restore["Restauration ClickHouse"] --> Replay["Replay confidentialité"]
        Replay --> Integrity["Contrôles d'intégrité"]
        Integrity --> Validation["Validation"]
    end

    Decrypt --> Restore
    Validation --> Access["Autorisation de remise à disposition"]

Une base restaurée ne doit pas devenir accessible aux API normales avant que les opérations de suppression et de modification nécessaires aient été réappliquées.

27. Problème particulier du droit à l'effacement

Une sauvegarde correctement conçue doit être résistante aux modifications accidentelles.

Cette immutabilité crée cependant une difficulté particulière pour les données personnelles.

Une donnée peut avoir été enregistrée dans une sauvegarde puis supprimée de la production à la suite d'une demande d'effacement.

Modifier rétroactivement chaque sauvegarde historique détruirait en partie l'intérêt d'une sauvegarde immuable et serait particulièrement coûteux pour un stockage analytique.

À l'inverse, restaurer naïvement cette sauvegarde ferait réapparaître une donnée qui avait déjà été supprimée.

LogsCord utilise donc un mécanisme de replay des opérations de confidentialité.

28. Journal de replay des suppressions et modifications

Lorsqu'une opération pertinente modifie l'état attendu d'une donnée personnelle, l'opération nécessaire à sa reproduction est ajoutée à un journal dédié.

Cela concerne notamment les opérations destinées à garantir qu'après restauration :

• une donnée effacée reste effacée ;
• une donnée expurgée reste expurgée ;
• une rectification pertinente reste appliquée.

Le journal est append-only.

Une entrée existante n'est pas modifiée pour réécrire l'historique.

L'opération nécessaire est enregistrée lorsqu'elle est exécutée, puis les entrées sont regroupées et scellées dans des segments journaliers.

Ainsi, la périodicité de 24 heures concerne le scellement du segment, et non l'attente de 24 heures avant de mémoriser une suppression.

29. Minimisation du journal de replay

Le journal de replay n'est pas conçu comme un deuxième journal des demandes RGPD.

Il ne cherche pas à conserver :

• l'identité de la personne ayant demandé une opération ;
• la justification détaillée de la demande ;
• son adresse e-mail ;
• les conversations associées à son traitement.

Il contient uniquement les informations techniques nécessaires pour reproduire l'état attendu de la base lors d'une restauration.

Conceptuellement, il enregistre :

> appliquer telle opération à telle donnée ou tel ensemble de données

et non :

> telle personne a effectué telle demande pour telle raison.

Lorsque les identifiants techniques contenus dans ce journal restent susceptibles d'être rattachés à une personne, LogsCord traite néanmoins ce journal comme une donnée pseudonymisée et lui applique les protections correspondantes.

30. Chiffrement du journal de replay

Chaque segment journalier du journal de replay est chiffré indépendamment avec AES-256-GCM.

La gestion des clés nécessaires à ce mécanisme est assurée par le KMS interne de LogsCord.

Le KMS est hébergé sur une infrastructure bare metal dédiée et durcie, séparée des principaux systèmes de stockage et de traitement.

Sa racine de confiance repose sur un TPM 2.0 physique.

Les clés racines protégées par le TPM sont configurées comme non exportables.

Les applications ordinaires n'obtiennent donc pas une copie de ces clés. Elles utilisent uniquement les opérations expressément exposées par le KMS.

Le stockage d'un segment de replay et le système permettant l'utilisation des clés correspondantes restent ainsi dans des périmètres de sécurité distincts.

31. Architecture du KMS

LogsCord exploite son propre service de gestion de clés afin de conserver le contrôle direct sur le cycle de vie du matériel cryptographique sensible.

Le KMS est exécuté sur un serveur bare metal dédié, distinct de l'infrastructure applicative principale.

Le serveur fait l'objet de mesures de durcissement spécifiques et son accès réseau est limité aux composants et opérations nécessitant effectivement l'utilisation du service.

Une puce TPM 2.0 physique fournit la racine matérielle de confiance.

Les clés racines du KMS sont protégées par le TPM et configurées comme non exportables.

mermaidflowchart LR
    subgraph Trust["Racine de confiance"]
        TPM["TPM 2.0 physique"] --> Root["Clés racines<br/>non exportables"]
    end

    subgraph KeyService["Service de gestion des clés"]
        KMS["KMS interne<br/>bare metal dédié"]
    end

    Apps["Applications autorisées"] -->|Requête authentifiée| KMS
    Root --> KMS
    KMS -->|Opérations cryptographiques autorisées| Data["Stockages chiffrés"]

Cette architecture vise notamment à empêcher qu'une compromission du stockage applicatif, du stockage objet ou d'une sauvegarde fournisse simultanément les clés racines nécessaires au déchiffrement.

Le KMS n'est pas présenté comme un HSM certifié et LogsCord ne revendique pas de certification FIPS ou équivalente pour ce composant.

L'objectif est de décrire précisément les garanties effectivement fournies :

• infrastructure physique dédiée ;
• TPM matériel ;
• clés racines non exportables ;
• séparation des responsabilités ;
• contrôle explicite du cycle de vie des clés.

32. Hiérarchie des clés

LogsCord évite d'utiliser directement une même clé racine pour chiffrer de grandes quantités de données.

Le système utilise une hiérarchie de clés.

Les clés racines protégées par le TPM servent à protéger le matériel cryptographique utilisé par les différents mécanismes de LogsCord.

Les données, notamment les segments du journal de replay, sont chiffrées avec des clés de chiffrement dédiées.

Ces clés peuvent elles-mêmes être protégées par des clés de chiffrement de clés rattachées à la racine de confiance du KMS.

mermaidflowchart LR
    TPM["TPM 2.0 physique"] --> Root["Clé racine<br/>non exportable"]
    Root -->|Protège| KEK["Clé de chiffrement<br/>de clés — KEK"]
    KEK -->|Enveloppe| DEK["Clés de données<br/>dédiées — DEK"]
    DEK -->|AES-256-GCM| Data["Données chiffrées"]

Cette séparation permet notamment d'appliquer des politiques de rotation et de destruction différentes selon la catégorie de données sans devoir remplacer la racine de confiance matérielle.

33. Rotation et cycle de vie des clés du journal

Le journal de replay est segmenté par périodes de 24 heures.

Chaque segment est associé à du matériel cryptographique distinct afin de limiter le périmètre affecté par la compromission éventuelle d'une clé.

Les clés nécessaires au déchiffrement restent utilisables uniquement aussi longtemps qu'une sauvegarde récupérable peut encore nécessiter le replay du segment correspondant.

La durée de vie d'une clé n'est donc pas déterminée uniquement par son âge.

Avant sa destruction, LogsCord vérifie qu'aucune sauvegarde encore récupérable ne dépend des opérations protégées par cette clé.

Une fois cette condition remplie, le matériel cryptographique correspondant est détruit conformément à la politique de gestion des clés.

34. Destruction des clés et effacement cryptographique

Lorsqu'une clé arrive définitivement en fin de vie, LogsCord déclenche sa destruction.

Pour les clés protégées par la racine matérielle du KMS, cette destruction vise à rendre impossible toute nouvelle opération permettant de récupérer les données précédemment protégées.

Les clés racines conservées dans le TPM sont non exportables.

Les mécanismes de sauvegarde et de restauration du KMS sont conçus de manière à ne pas permettre la réapparition d'une clé dont la destruction définitive a déjà été enregistrée.

Cette propriété est particulièrement importante pour le journal de replay : restaurer un état ancien du KMS ne doit pas permettre de contourner un effacement cryptographique intervenu après cet état.

La destruction des clés fait donc partie du cycle de reprise du KMS lui-même et est vérifiée avant qu'un système restauré puisse redevenir opérationnel.

35. Séparation du stockage et des clés

LogsCord sépare les données chiffrées des systèmes chargés de protéger les clés permettant de les déchiffrer.

mermaidflowchart LR
    TPM["TPM 2.0<br/>clés racines non exportables"] --> KMS["KMS interne"]
    KMS -->|Opérations cryptographiques| Services["Services autorisés<br/>sans accès aux clés racines"]

    subgraph Storage["Stockages séparés du KMS"]
        Active["Données actives chiffrées"]
        S3["Sauvegardes chiffrées<br/>Hetzner Object Storage"]
        Replay["Journal de replay chiffré"]
    end

    Services -->|Ciphertext| Active
    Services -->|Ciphertext| S3
    Services -->|Ciphertext| Replay

Cette séparation signifie notamment que :

• compromettre un bucket de sauvegarde ne suffit pas à obtenir les clés ;
• compromettre un serveur applicatif ne doit pas donner accès aux clés racines ;
• disposer d'un ciphertext ne donne pas automatiquement accès au mécanisme de déchiffrement ;
• les applications utilisent le KMS au travers d'opérations autorisées plutôt qu'en manipulant directement les clés racines.

36. Accès aux sauvegardes

Les sauvegardes ne constituent pas une base secondaire destinée à la consultation normale.

Elles sont utilisées pour :

• la reprise après incident ;
• les tests de restauration ;
• les opérations techniques autorisées.

La possibilité de déclencher une restauration est limitée aux personnes habilitées par LogsCord.

Les credentials utilisés pour accéder au stockage, au système de clés et aux environnements de restauration sont séparés autant que possible des credentials applicatifs habituels.

Un serveur applicatif ordinaire ne doit pas avoir besoin de pouvoir restaurer arbitrairement une sauvegarde historique.

L'accès aux données sauvegardées et l'accès au système de gestion des clés sont volontairement séparés.

Une restauration nécessitant du matériel cryptographique protégé par le KMS doit suivre la procédure d'autorisation prévue à cet effet.

Les services applicatifs ordinaires ne disposent pas directement des clés racines du KMS.

37. Restauration et replay obligatoire

Lorsqu'une restauration réelle est nécessaire, la base restaurée est placée dans un état isolé.

Avant toute remise à disposition :

1. LogsCord identifie le point temporel représenté par la sauvegarde ; 2. les segments de replay pertinents postérieurs à ce point sont récupérés ; 3. leurs clés sont obtenues via le processus autorisé ; 4. leur authenticité est vérifiée ; 5. les suppressions et rectifications sont rejouées ; 6. le résultat de chaque opération est contrôlé ; 7. un contrôle final confirme que le replay est complet.

Seulement après validation, la base peut être promue ou reconnectée aux services autorisés.

Une restauration ne peut donc pas simplement être suivie d'une remise en production immédiate.

38. Exemple de restauration après effacement

Un membre demande l'effacement d'un ensemble de données le 10 août.

Ces données existaient encore dans une sauvegarde créée le 1er août.

La production est correctement nettoyée le 10 août, mais la sauvegarde du 1er août reste volontairement immuable pendant sa période de rétention.

Si une restauration du 1er août devient nécessaire le 20 août :

mermaidflowchart LR
    Backup["Sauvegarde du 1er août"] --> Restore["Restauration isolée"]

    subgraph Privacy["Reconstitution de l'état de confidentialité"]
        Replay["Replay du 2 au 20 août"] --> Delete["Réapplication de la suppression<br/>du 10 août"]
    end

    Restore --> Replay
    Delete --> Checks["Contrôles de complétude et d'intégrité"]
    Checks --> Clean["Base restaurée<br/>sans la donnée supprimée"]
    Clean --> Access["Remise à disposition autorisée"]

La restauration d'une sauvegarde antérieure ne doit donc pas annuler une suppression déjà exécutée.

39. Gestion des incidents liés aux sauvegardes

Les situations suivantes sont considérées comme des anomalies devant être investiguées :

• échec d'une sauvegarde programmée ;
• chaîne incrémentale incomplète ;
• objet attendu absent du stockage ;
• échec de déchiffrement ;
• échec de vérification AES-GCM ;
• restauration ClickHouse impossible ;
• divergence entre restauration complète et incrémentale ;
• échec de replay d'une opération de confidentialité ;
• présence inattendue d'une version S3 au-delà de sa fenêtre de conservation ;
• échec de destruction d'une clé arrivée en fin de vie.

Une sauvegarde présentant une anomalie n'est pas considérée comme validée simplement parce que les autres sauvegardes du cycle sont présentes.

40. Ce que garantit notre stratégie de sauvegarde

La stratégie est conçue pour répondre à plusieurs catégories de risques.

41. Interface producteur et accès aux données émises

LogsCord met à la disposition du développeur une interface producteur distincte du canal d'ingestion et de MCP.

Cette interface permet au développeur de consulter les données émises par ses propres collecteurs, dans les limites définies ci-dessous.

Elle ne donne aucun accès aux données d'un autre producteur.

41.1 Accès du producteur aux données émises

Le fait qu'une donnée ait été émise par un bot, une application ou un service ne confère pas à son développeur un droit illimité sur les données personnelles qu'elle contient.

L'accès dépend du contexte du log, des finalités déclarées, du rôle juridique effectivement exercé et des documents applicables.

L'interface producteur est cloisonnée par :

• producteur ;
• application ;
• contexte de log.

Elle est soumise aux règles suivantes :

• seuls les comptes nominatifs expressément habilités par le développeur peuvent y accéder ;
• l'accès doit être limité aux besoins d'exploitation, de diagnostic, de sécurité, de support ou de conformité de l'application concernée ;
• le développeur doit sélectionner le contexte ou le serveur concerné avant de consulter des données détaillées ;
• les champs sensibles et contenus personnels peuvent être masqués, expurgés ou rendus inaccessibles lorsqu'ils ne sont pas nécessaires à la finalité poursuivie ;
• les accès, recherches, consultations et exports autorisés sont tracés afin de permettre leur contrôle ;
• les droits doivent être retirés lorsqu'ils ne sont plus nécessaires.

Dans un contexte de serveur Discord, le développeur ne peut consulter des données personnelles détaillées que dans la mesure nécessaire à la fourniture, au support ou à la sécurité de son service, et conformément au rôle qui lui est attribué par la Politique de confidentialité, le DPA ou tout autre accord applicable.

Lorsqu'un accès intervient pour répondre à une demande de support, celle-ci doit être rattachée au serveur concerné et documentée.

La consultation simultanée de données personnelles détaillées provenant de plusieurs serveurs est interdite par défaut.

Une analyse transversale ne peut porter que sur des données agrégées ou effectivement anonymisées, sauf lorsqu'un incident de sécurité documenté justifie une investigation limitée, proportionnée, tracée et réservée aux personnes spécialement habilitées.

Dans un contexte applicatif, le développeur peut consulter les événements de sa propre application pour les finalités déclarées de fonctionnement et de sécurité.

Cet accès reste soumis aux principes de minimisation, de limitation de la conservation, de confidentialité et de traçabilité.

L'interface producteur ne peut pas être utilisée pour :

• surveiller les membres d'un serveur ;
• constituer des profils sans rapport avec le service fourni ;
• revendre les données ;
• créer une base parallèle ;
• détourner les informations vers une finalité incompatible.

42. Webhooks externes et rapports d'incidents

Les mécanismes d'émission externe de LogsCord, notamment les webhooks destinés aux rapports d'incidents, de sanctions ou d'événements de sécurité, constituent un canal distinct de l'interface producteur.

Ils ne doivent pas être considérés comme un mécanisme d'accès général à la base LogsCord.

Un rapport transmis à un système externe doit être limité aux informations nécessaires à la finalité du rapport.

Les données contenues dans un rapport peuvent notamment dépendre :

• du type d'incident ;
• du contexte du serveur ;
• de la sanction concernée ;
• des données nécessaires à l'identification de l'événement ;
• des paramètres de l'intégration ;
• des finalités déclarées du traitement.

Les mécanismes d'émission doivent appliquer les mêmes principes de minimisation et de contrôle d'accès que les autres interfaces de LogsCord.

Un webhook externe ne confère donc pas à son destinataire un droit général de consultation des données LogsCord.

43. Services tiers et responsabilité

Les principaux prestataires techniques pouvant intervenir dans le fonctionnement de l'infrastructure sont documentés dans la Politique de confidentialité et, lorsque cela est applicable, dans la liste des sous-traitants ultérieurs associée au DPA de LogsCord.

La présence d'un prestataire dans l'architecture ne lui donne pas automatiquement le droit de réutiliser les données à ses propres fins.

Les rôles juridiques, catégories de données concernées et mécanismes applicables aux transferts internationaux sont décrits dans les documents de confidentialité plutôt que dans cette seule page de sécurité.

44. Limites et transparence

Aucune architecture ne permet de garantir l'absence absolue d'incident.

Notre objectif est de :

1. réduire la probabilité d'une compromission ; 2. limiter son impact lorsqu'elle survient ; 3. détecter les anomalies ; 4. permettre une reprise contrôlée ; 5. vérifier que les sauvegardes sont effectivement restaurables.

Certaines mesures ne sont volontairement pas détaillées publiquement, notamment :

• les adresses et topologies internes exactes ;
• les seuils de détection anti-DDoS ;
• les expressions complètes des Rulesets ;
• les règles firewall détaillées ;
• les mécanismes d'accès d'urgence ;
• les identifiants de ressources ;
• les secrets ;
• certains paramètres cryptographiques non nécessaires à l'évaluation publique du système.

Cette limitation ne signifie pas que ces éléments ne sont pas documentés en interne.

45. Architecture globale

La collecte et le traitement des événements peuvent être résumés ainsi :

mermaidflowchart LR
    Discord["Discord"] --> Gateway["Discord Gateway"]

    subgraph Collect["Collecte"]
        Gateway --> Collectors["Collecteurs<br/>shardés et conteneurisés"]
    end

    subgraph Storage["Stockage et temps réel"]
        CH["ClickHouse<br/>stockage durable"]
        Broker["Message Broker<br/>temps réel"]
    end

    Collectors --> CH
    Collectors --> Broker

    subgraph API["Accès applicatif"]
        APIService["API LogsCord"]
        Client["Client"]
    end

    CH --> APIService
    Broker --> APIService
    APIService -->|SSE| Client

    Internet["Internet"] --> CF["Cloudflare<br/>WAF / DDoS / Rulesets"]
    CF --> Tunnel["Cloudflare Tunnel"]
    Tunnel --> APIService

La façade Internet est séparée du chemin de traitement interne :

mermaidflowchart LR
    Internet["Internet"]

    subgraph Edge["Façade publique"]
        CF["Cloudflare"] --> Security["WAF / DDoS / Rulesets"]
        Security --> Tunnel["Cloudflare Tunnel"]
    end

    subgraph Internal["Infrastructure privée"]
        Firewall["Firewall d'infrastructure"] --> Network["Segmentation réseau"]
        Network --> Services["Services LogsCord"]
        Services --> ACL["Contrôles d'accès aux données"]
    end

    Internet --> CF
    Tunnel --> Firewall

46. Architecture des sauvegardes et de la reprise

Le chemin de sauvegarde peut être représenté de manière synthétique :

mermaidflowchart LR
    CH[("ClickHouse")] --> Backup["Sauvegarde"]

    subgraph Protection["Protection et conservation"]
        Encrypt["Chiffrement<br/>AES-256-GCM"] --> S3["Hetzner Object Storage"]
        S3 --> Lock["S3 Object Lock<br/>Compliance"]
    end

    subgraph Recovery["Reprise contrôlée"]
        Restore["Restauration isolée"] --> Replay["Replay confidentialité"]
        Replay --> Verify["Vérification"]
        Verify --> Production["Remise à disposition"]
    end

    Backup --> Encrypt
    Lock --> Restore

Les sauvegardes sont indépendantes des réplicas de production.

Le KMS reste lui-même séparé du stockage des données :

mermaidflowchart LR
    TPM["TPM 2.0"] --> Root["Clés racines<br/>non exportables"]
    Root --> KMS["KMS interne"]
    KMS -->|Opérations autorisées| Crypto["Services cryptographiques"]

    subgraph Encrypted["Stockages chiffrés séparés"]
        Backups["Sauvegardes<br/>AES-256-GCM"]
        Replay["Journal de replay<br/>AES-256-GCM"]
    end

    Crypto -->|Ciphertext| Backups
    Crypto -->|Ciphertext| Replay

47. Résumé

LogsCord applique une architecture de sécurité reposant sur plusieurs niveaux indépendants :

• moindre privilège pour les composants et credentials ;
• collecteurs shardés et isolés ;
• séparation ingestion / recherche / temps réel ;
• segmentation réseau ;
• conteneurs avec capacités minimales ;
• Cloudflare en façade ;
• Cloudflare Tunnel pour limiter l'exposition directe ;
• firewall d'infrastructure Hetzner ;
• ClickHouse multi-tenant avec isolation adaptée au contexte ;
• réplication pour les environnements nécessitant une disponibilité renforcée ;
• sauvegardes S3 séparées de la production ;
• AES-256-GCM pour les sauvegardes et le journal de replay ;
• S3 Object Lock Compliance pour l'immutabilité ;
• tests réguliers de restauration ;
• validation par comparaison des chemins de restauration ;
• environnement de restauration isolé ;
• journal de replay des suppressions et rectifications ;
• KMS interne sur bare metal dédié ;
• TPM 2.0 physique comme racine matérielle de confiance ;
• clés racines non exportables ;
• séparation du stockage des données et du système de gestion des clés ;
• contrôle et traçabilité des accès producteur.

Cette architecture ne prétend pas rendre LogsCord invulnérable.

Elle vise à faire en sorte qu'une compromission d'un composant ne fournisse pas automatiquement le contrôle des autres, qu'un accès au stockage ne fournisse pas automatiquement les clés, qu'une sauvegarde ne soit pas considérée comme fiable sans restauration vérifiée et qu'une restauration historique ne puisse pas annuler silencieusement une opération de confidentialité déjà exécutée.

48. Niveau de preuve et transparence

Les mécanismes décrits dans ce document correspondent à l'architecture et aux mesures de sécurité mises en œuvre par LogsCord. Leur fonctionnement, leurs configurations et leurs procédures d'exploitation sont documentés dans un référentiel interne qui n'est pas publié intégralement, notamment afin de ne pas exposer d'informations susceptibles de faciliter une attaque.

LogsCord publie progressivement des éléments techniques complémentaires dans sa page Articles. Le lecteur est notamment encouragé à consulter les publications portant le tag Devlog, qui présentent de manière plus détaillée certains choix d'architecture, mécanismes effectivement mis en place, diagrammes, protocoles de test et résultats de benchmark. Un benchmark n'est interprétable qu'avec son périmètre, sa méthodologie, sa date et ses conditions d'exécution ; ces éléments doivent accompagner les résultats publiés.

LogsCord publie également plusieurs projets open source. Leur code, leur documentation, leurs tests et leur historique permettent d'apprécier publiquement certaines pratiques d'ingénierie et le niveau de rigueur recherché par LogsCord. Ces projets ne constituent cependant pas une reproduction de l'infrastructure privée et ne prouvent pas, à eux seuls, l'implémentation d'un contrôle déterminé sur la plateforme LogsCord.

Registre synthétique des derniers contrôles

Le tableau suivant présente la date de la dernière vérification réalisée par LogsCord pour les principaux contrôles décrits dans ce document. Il constitue un état daté : un résultat positif confirme le contrôle au moment du test, mais ne constitue pas une garantie permanente ni une validation indépendante.

Les différentes sources de preuve doivent donc être interprétées selon leur portée :

À la date de cette version, aucun audit de sécurité indépendant de l'ensemble de la plateforme LogsCord n'a été réalisé. LogsCord ne présente donc ni ce document, ni ses devlogs, ni ses projets open source comme un rapport d'audit, une certification ou une validation indépendante. Ils constituent des éléments de transparence qui peuvent être complétés, dans un cadre approprié et sous réserve des exigences de confidentialité et de sécurité, par des preuves internes ciblées telles que des rapports de restauration, résultats de tests, relevés de configuration ou procédures de contrôle.

49. Références techniques

Les documentations officielles suivantes décrivent les capacités et le fonctionnement général des services et standards tiers sur lesquels s'appuie l'architecture présentée. Elles permettent de comprendre les mécanismes techniques cités et de vérifier que les fonctionnalités correspondantes existent chez leurs éditeurs.

LogsCord

• Articles LogsCord — articles techniques, diagrammes, devlogs et benchmarks publiés par LogsCord ; les publications concernées peuvent être retrouvées au moyen du tag Devlog.
• Organisation GitHub LogsCord — projets, documentations et historiques publics permettant d'examiner certaines pratiques d'ingénierie de LogsCord.
• Documents et manuels LogsCord — versions publiques des documents, politiques et manuels mis à disposition par LogsCord.

Discord

• Discord Gateway — connexions WebSocket, réception des événements, intents, reprise de session et sharding.
• Discord API Reference — ressources et opérations de l'API HTTP Discord.

ClickHouse

• Backup and restore in ClickHouse — sauvegardes et restaurations, destinations S3 compatibles, sauvegardes complètes et incrémentales, opérations synchrones ou asynchrones et suivi des résultats.
• Multi tenancy — table partagée avec tenant_id, contrôle d'accès fondé sur les rôles, row policies et modèles d'isolation alternatifs.
• Access control and account management — utilisateurs, rôles, privilèges et contrôle d'accès SQL.

Cloudflare

• Cloudflare Tunnel — connexions établies depuis l'origine, publication d'applications sans exposition directe traditionnelle de l'origine et acheminement du trafic par le réseau Cloudflare.
• Cloudflare Web Application Firewall — filtrage des requêtes Web et API au moyen de règles et de rulesets.
• Cloudflare DDoS Protection — règles gérées de détection et d'atténuation des attaques DDoS.
• Cloudflare Ruleset Engine — création, déploiement et gestion de règles et rulesets, notamment au moyen de l'API Cloudflare.

Hetzner

• Hetzner Object Storage — documentation générale du stockage objet compatible S3.
• Object Lock: Retention — activation d'Object Lock et modes Governance ou Compliance.
• Versioning — conservation et gestion des versions d'objets.
• Applying lifecycle policies — expiration des objets, des versions non courantes, des marqueurs de suppression et des uploads multipart incomplets.
• Firewall for Dedicated Root Servers — firewall stateless configuré au niveau du port de switch pour les serveurs gérés dans Robot.
• Robot interfaces — administration manuelle ou automatisée au moyen de l'interface Webservice Robot.
• Data centers and connection — localisation et caractéristiques générales des Data Center Parks Hetzner, dont Nuremberg.

Cryptographie et gestion des clés

• NIST SP 800-38D — GCM and GMAC — définition de GCM comme mode de chiffrement authentifié avec données associées.
• NIST SP 800-88 Rev. 2 — Guidelines for Media Sanitization — principes de sanitisation, dont l'effacement cryptographique et la destruction du matériel cryptographique pertinent.
• Trusted Computing Group — TPM 2.0 Library — architecture, structures et commandes de la spécification TPM 2.0.

50. Contact et signalement de sécurité

Pour toute question relative à la sécurité de LogsCord ou pour signaler une vulnérabilité, un comportement suspect, une exposition de données ou tout autre incident potentiel, contactez [email protected].

Les modalités de signalement de sécurité à jour sont publiées dans le fichier security.txt. Les chercheurs, utilisateurs et partenaires sont invités à consulter ce document avant de transmettre un signalement.

Les documents, politiques et manuels publics de LogsCord sont également disponibles dans le dépôt LogsCord/logscord-manuals.