La sécurité comme socle, jamais comme option
Le modèle Zero Trust structure l'identité, les politiques, les flux de données et les procédures du backoffice Animeo dès leur conception.
Zero Trust structurel
Le Zero Trust n'est pas une couche ajoutée devant le backoffice : il est le socle de son modèle d'identité, de son autorisation, de ses contrats de données et de ses procédures. Une connexion réussie, un réseau interne, un rôle administrateur ou la propriété d'un service ne créent jamais de confiance implicite.
| Principe | Application |
|---|---|
| Refus par défaut | Une action non déclarée, un attribut absent, un dossier invalide ou une dépendance de sécurité indisponible entraîne un refus. |
| Moindre privilège | Chaque décision porte sur une action, une ressource, un dossier, une finalité, un appareil et une durée déterminés. |
| Vérification continue | La session, l'appareil, le comportement et le niveau de risque sont réévalués ; l'authentification initiale ne suffit pas pour la suite. |
| Séparation des responsabilités | Les actions sensibles et procédures d'urgence appliquent le principe des quatre yeux ; personne ne peut valider sa propre opération. |
| Contrôle des données | Les données ne quittent jamais leur domaine sans projection autorisée et contrôle centralisé d'egress. |
Enrôlement et authentification du staff
Le backoffice possède son propre système d'identité, sans Discord, OAuth2 ou compte Animeo ordinaire. Les membres du staff s'authentifient avec une passkey fondée sur WebAuthn. Ils ne peuvent pas créer librement un compte : l'enrôlement nominatif suit une procédure contrôlée et n'accorde que les droits nécessaires à la mission.
Contrôles complémentairesAppareils de confiance, notifications, révision et révocation.
- Notification Web Push sur les appareils de confiance à chaque authentification, action sensible, accès à un utilisateur et anomalie de session.
- Révision périodique et à chaque changement de mission ; les droits temporaires expirent automatiquement.
- Récupération documentée sans réutiliser un canal compromis et sans abaisser le niveau d'authentification.
- Suspension immédiate sur signal de compromission, changement de rôle, appareil perdu ou départ du staff.
Une notification Web Push informe et permet de réagir ; elle ne remplace jamais, à elle seule, la preuve cryptographique exigée pour la seconde étape.
Autorisation ABAC et accès aux utilisateurs
- Dossier obligatoire : Le membre du staff rattache l'accès à un ticket utilisateur ou à un dossier interne autorisé : support, bug, audit, incident, obligation légale ou facturation.
- Décision dynamique : Le moteur ABAC évalue l'acteur, l'action, la ressource, la politique, le dossier, l'appareil, la session, le risque et la finalité.
- Projection minimale : La vue standard reçoit uniquement une projection masquée : un email n'affiche que ses premières et dernières lettres.
- Quatre yeux : Une action sensible applique le principe des quatre yeux : elle est demandée par une personne puis vérifiée ou validée par une seconde personne habilitée et indépendante.
- Audit : L'accès est écrit dans un journal immuable, y compris pour un administrateur, puis apparaît dans le rapport de transparence de l'utilisateur.
| Contrôle | Règle |
|---|---|
| Dossier | Obligatoire pour tout accès à une donnée personnelle ; ticket utilisateur ou procédure interne autorisée définissant la finalité, la cible et la durée. |
| Comptes visibles | Comptes actifs au cours des 14 derniers jours par défaut ; exception documentée et approuvée. |
| Emails | Masqués par défaut ; révélation exceptionnelle soumise à une intention auditée. |
| Identité et livraison | Nom, prénom, adresses et téléphone absents de la vue standard, y compris pour un administrateur ; consultation limitée aux champs nécessaires après seconde étape récente, dossier interne rattaché, motif, validation selon le principe des quatre yeux et audit. |
| IP et User-Agent | Jamais affichés sans dossier autorisé, contrôle renforcé, motif et journalisation ; le dossier peut relever d'un bug, d'un audit ou d'un incident interne. |
| Administrateurs | Soumis aux mêmes PEP et aux mêmes projections ; aucun rôle ne dispose d'un accès silencieux ou global. |
| Communication | Le staff ne révèle jamais à un utilisateur les données personnelles d'un autre membre, y compris pour confirmer ou infirmer une supposition. |
| Quatre yeux | Actions sensibles sur un compte ou une facture, exports, récupération d'accès, changement de politique et procédures d'urgence : demande et validation sont portées par deux personnes distinctes. |
| Urgence | Le break-glass reste borné, notifié et audité ; une révocation immédiate peut précéder la seconde revue lorsqu'attendre aggraverait l'incident. |
Cette règle est une application de la séparation des responsabilités selon l'OWASP. Une définition francophone du principe des quatre yeux est également disponible.
Source of Truth et data lineage déclaratif
Un catalogue déclaratif unique constitue la Source of Truth des données. Il décrit chaque champ, sa classification, sa finalité, sa source canonique, ses bases, caches, index, files, sauvegardes, répliques, projections, destinataires, durées et procédures d'effacement.
Les schémas de réponse, masquages, autorisations, audits, exports, suppressions et documents sont générés ou vérifiés depuis cette autorité. Des réconciliations automatiques détectent les stockages oubliés, les liens incohérents, les projections non déclarées et les divergences entre la politique et l'état observé.
Contrôles anti-divergenceComment une nouvelle source ou projection est empêchée de contourner le catalogue.
- La CI refuse un champ sans propriétaire, classification, finalité, audience, durée et stratégie d'effacement.
- Les inventaires des bases, caches, sauvegardes, index et flux sont rapprochés des déclarations versionnées.
- Une projection ne peut sélectionner un document complet : seuls les champs explicitement autorisés sont sérialisables.
- Les opérations de suppression produisent une preuve par stockage et signalent automatiquement les projections manquantes.
Contrôle centralisé des flux sortants
Le mécanisme distinct du data lineage est un contrôle d'egress avec fonctions DLP. Chaque sortie traverse un Policy Enforcement Point (PEP) qui applique la projection autorisée, le masquage, la minimisation, la validation de schéma et la politique du destinataire.
| Canal | Contrôle appliqué |
|---|---|
| API HTTP | Réponse construite depuis une projection autorisée ; champs inconnus ou non déclarés rejetés. |
| SSE et WebSocket | Catalogue d'événements versionné, audience vérifiée à chaque émission et données sensibles retirées avant diffusion. |
| Web Push et notifications | Contenu minimal sans secret ni donnée personnelle sensible ; le détail nécessite de rouvrir une session autorisée. |
| Exports et téléchargements | Intention, dossier, approbation, chiffrement, expiration et journalisation spécifiques. |
| Journaux et SIEM | Pseudonymisation, redaction des secrets, classification et rétention contrôlée avant ingestion. |
Un nouveau transport ne peut être raccordé au backoffice sans adopter le même point d'application. Il n'existe pas de chemin de sérialisation secondaire réservé aux administrateurs.
Chiffrement, infrastructure et chaîne logicielle
Les échanges sont chiffrés en transit et les stockages sont chiffrés au repos. Les clés sont séparées des données et administrées par le KMS / Vault de ZeroOS.
Protocoles et primitives cryptographiquesLes mécanismes employés selon le type de donnée et de transport.
| Usage | Protection |
|---|---|
| Échanges applicatifs | TLS pour protéger les données en transit. |
| Directs et lives | WebRTC avec DTLS-SRTP pour les médias et DTLS pour les canaux de données. |
| Chiffrement authentifié | AES-256-GCM et ChaCha20-Poly1305 selon le service et le profil de transport. |
| Pseudonymisation et intégrité | HMAC-SHA-256 avec clés dédiées et rotation ; HMAC ne remplace pas le chiffrement. |
| Stockage | Chiffrement au repos pour MongoDB, ClickHouse, Redis, NATS/JetStream et les objets MinIO, avec identités et clés séparées par service. |
Exécution et chaîne d'approvisionnementRuntime, registres, images et systèmes de stockage.
- Conteneurs : Les applications utilisent des images OCI exécutées par containerd.
- ZeroOS : ZeroOS orchestre les services, les identités d'exécution, la configuration et le KMS / Vault.
- ZeroBuilder : ZeroBuilder produit des images OCI hermétiques, signées et accompagnées de leur SBOM. Les builds démarrent sans capacité ni accès réseau et n'obtiennent que les permissions explicitement déclarées.
- Registres : ZeroRegistry est le registre NPM privé d'autorité. Verdaccio, utilisé historiquement, est maintenu comme composant distinct à compatibilité bornée et n'est pas la source d'autorité.
- Données : MongoDB porte les données métier ; ClickHouse l'analytique ; Redis les états éphémères ; NATS la messagerie ; et MinIO le stockage objet du CDN Animeo.
- Périmètre réseau : Cloudflare protège l'entrée réseau ; l'infrastructure principale est hébergée chez Hetzner à Nuremberg.
SIEM, détection et réponse continue
Le SIEM opérationnel s'appuie sur LogsCord, produit professionnel d'observabilité créé par le créateur d'Animeo. Les signaux d'identité, de politique, d'appareil, de session, de réseau et de sortie de données sont corrélés sans transformer l'observabilité en droit de regard illimité.
Les fonctions IDR et IDS analysent en continu les anomalies de session, la compromission possible du client, les nouveaux appareils, les échecs de seconde étape, les recherches séquentielles, les volumes atypiques et les changements de politique.
Les playbooks SOAR peuvent révoquer les sessions, suspendre une identité, retirer la confiance d'un appareil, invalider les intentions, isoler un service, préserver les preuves et ouvrir un incident. Chaque action automatique reste bornée, explicable et auditée.
Crise, révocation et voies hors bande
La capacité à retirer un accès est conçue pour survivre à la panne d'une dépendance normale. Un chemin de révocation d'urgence indépendant peut invalider toutes les sessions staff et faire appliquer le refus même si la base principale ne permet plus l'écriture attendue.
À l'inverse, une voie d'observation hors bande et en lecture seule permet aux personnes habilitées de consulter les signaux essentiels lorsque l'application, le réseau principal ou plusieurs services sont indisponibles. Les appareils utilisés sont pré-enrôlés, contrôlés et soumis à deux étapes.
Simulations de crise trimestriellesDes scénarios extrêmes vérifient que les contrôles restent utilisables lorsque les dépendances habituelles échouent.
- La base refuse l'écriture nécessaire à une révocation : le mécanisme d'urgence doit néanmoins invalider toutes les sessions staff.
- Le backoffice est le dernier service disponible : il doit encore permettre la révocation et exposer un état de sécurité minimal fiable.
- Le backoffice ou le réseau principal est indisponible pendant un incident Animeo : la télémétrie hors bande doit rester consultable.
- Une passkey et un appareil de confiance sont supposés compromis : récupération, suspension et rotation sont exécutées sans baisse de niveau.
- Les résultats, temps de détection, décisions, échecs et mesures correctives sont consignés puis rejoués.
Le principe des quatre yeux protège les procédures d'urgence et les actions sensibles, notamment sur un compte, une facturation, un export, une politique ou un accès privilégié. Une révocation qui réduit immédiatement les droits peut être déclenchée par l'automatisation ou un opérateur unique afin de ne jamais bloquer le confinement ; elle est alors notifiée et revue par une seconde personne.
Référentiels et niveau d'assurance
L'architecture est conçue en référence aux principes et recommandations ci-dessous. Cet alignement guide les contrôles et les revues, mais ne constitue ni une certification, ni une homologation, ni une attestation indépendante de conformité.
| Référentiel | Apport au modèle Animeo |
|---|---|
| NIST SP 800-207 — Zero Trust Architecture | Absence de confiance implicite, décision par ressource et session, politiques dynamiques et vérification continue. |
| NIST SP 1800-35 — Implementing a Zero Trust Architecture | Pratiques d'implémentation, gouvernance des identités, segmentation et intégration des contrôles. |
| ANSSI — Modèle Zero Trust | Réduction de la confiance implicite, analyse de risque et articulation avec la défense en profondeur. |
| ANSSI — Administration sécurisée des SI | Séparation du système d'administration, postes dédiés, journalisation et procédures opérateur. |
| OWASP — Zero Trust Architecture Cheat Sheet | Points d'application, policy-as-code, moindre privilège, contrôle des appareils, DLP et surveillance continue. |
Les revues sont conduites en interne par le créateur d'Animeo, architecte logiciel et praticien passionné de cybersécurité, avec une orientation blue team, conformité et conception d'architectures Zero Trust structurelles. Cette expertise interne n'est pas présentée comme un audit tiers ou une certification.
Signaler un problème
Signalez confidentiellement une vulnérabilité ou un incident à [email protected]. Incluez la surface concernée, l'impact possible et les étapes minimales de reproduction, sans accéder aux données d'un tiers.
Glossaire des termes techniques
Les termes soulignés en pointillés renvoient ici. Chaque définition explique concrètement ce que le terme signifie dans le contexte Animeo et fournit une source de référence.
- Zero Trust
- Aucun utilisateur, appareil ou service n'est cru uniquement parce qu'il est déjà connecté ou interne. Chaque accès est vérifié pour la ressource et le contexte concernés.NIST SP 800-207
- Principe des quatre yeux
- Une personne demande l'action sensible et une autre personne habilitée la contrôle ou la valide. Personne ne peut approuver seul sa propre opération.Wikipédia — Règle des quatre yeux
- Contrôle d'egress
- Le contrôle de ce qui sort d'un système. Chez Animeo, il retire ou masque les champs non autorisés avant une réponse API, une notification, un export ou un journal.NIST SP 800-207A
- OAuth 2.0
- Le protocole qui permet à Animeo d'obtenir une autorisation limitée auprès d'un fournisseur d'identité sans recevoir votre mot de passe chez ce fournisseur.MDN — Identité fédérée
- Passkey / WebAuthn
- Une connexion par clé cryptographique liée au site : l'appareil prouve l'identité sans transmettre de mot de passe réutilisable à Animeo.MDN — Web Authentication API
- Web Push
- Une notification transmise par le service Push du navigateur, même si Animeo n'est pas ouvert. Son contenu est volontairement minimal et ne contient pas de donnée sensible.MDN — Push API
- ABACAttribute-Based Access Control
- L'accès dépend d'attributs concrets — personne, action, donnée, appareil, risque, motif et durée — plutôt que du seul rôle « administrateur ».OWASP — Authorization Cheat Sheet
- PEPPolicy Enforcement Point
- La barrière technique qui applique réellement une décision de sécurité. Dans le backoffice Animeo, elle bloque toute sortie qui ne respecte pas la politique et la projection autorisée.NIST — Policy Enforcement Point
- Source of Truth
- Le registre de référence qui décrit où chaque donnée doit exister et quelles copies sont autorisées. Les autres systèmes doivent rester cohérents avec lui.Wikipedia — Single source of truth
- Data lineage
- La carte du parcours d'une donnée : origine, transformations, bases, caches, sauvegardes, destinataires et suppression. Animeo s'en sert pour détecter une copie oubliée ou incohérente.Wikipedia — Data lineage
- DLPData Loss Prevention
- Des règles destinées à empêcher qu'une donnée sensible sorte par erreur ou par abus, par exemple dans un export, une notification ou un journal.NIST — Data Loss Prevention
- SSEServer-Sent Events
- Un canal par lequel le serveur envoie des événements en continu au navigateur. Animeo y applique les mêmes filtres de données qu'aux réponses API.MDN — Server-sent events
- WebSocket
- Une connexion persistante permettant au navigateur et au serveur d'échanger en temps réel. Chaque événement Animeo reste autorisé et filtré avant son envoi.MDN — WebSocket API
- SIEMSecurity Information and Event Management
- Le système qui centralise et corrèle les événements de sécurité pour repérer un incident. Chez Animeo, cette fonction s'appuie sur LogsCord.CISA NICCS — Glossaire
- KMS / VaultKey Management System / coffre de secrets
- Le service séparé qui conserve les clés et secrets, contrôle qui peut les utiliser et organise leur rotation. Ils ne sont pas intégrés aux images Animeo.NIST — Key Management Guidelines
- TLSTransport Layer Security
- Le protocole qui chiffre une connexion en transit, par exemple entre votre navigateur et Animeo, afin d'empêcher sa lecture ou sa modification sur le trajet.NIST — TLS Guidelines
- WebRTC / DTLS-SRTP
- Les mécanismes de communication directe et de protection des médias en temps réel. Concrètement, un live n'est pas transporté en clair.IETF — WebRTC Security Architecture
- AES-256-GCM
- Un chiffrement authentifié : il rend la donnée illisible sans la clé et détecte aussi une modification du contenu chiffré.NIST SP 800-38D
- ChaCha20-Poly1305
- Une autre méthode de chiffrement authentifié utilisée selon le service ou l'appareil, avec le même objectif de confidentialité et d'intégrité.IETF — RFC 8439
- HMAC-SHA-256
- Une empreinte calculée avec une clé secrète. Animeo s'en sert notamment pour pseudonymiser ou vérifier l'intégrité, pas pour chiffrer une donnée.NIST — Message Authentication Codes
- OCIOpen Container Initiative
- Le standard utilisé pour emballer une application et ses dépendances dans une image exécutable de manière reproductible par un runtime de conteneurs.Open Container Initiative
- SBOMSoftware Bill of Materials
- L'inventaire versionné des composants et dépendances contenus dans une image. Animeo l'utilise pour contrôler ce qui est réellement déployé et retrouver une dépendance vulnérable.CISA — Software Bill of Materials
- IDRIdentity Detection and Response
- La surveillance des identités et des sessions pour détecter un compte ou appareil potentiellement compromis et déclencher une réponse adaptée.Wikipedia — Identity threat detection and response
- IDSIntrusion Detection System
- Un système qui analyse l'activité d'un réseau ou d'une application pour signaler rapidement des tentatives d'accès ou comportements suspects.NIST — Intrusion Detection System
- SOARSecurity Orchestration, Automation and Response
- Des procédures de réponse exécutables qui coordonnent des actions comme révoquer une session, isoler un service, préserver les preuves et ouvrir un incident.NIST — SOAR
