Architecture de confiance zéro
Le zero trust tient en une phrase : aucune requête n'est crue sur sa seule provenance réseau. Ce chapitre décrit les principes retenus et les composants qui les portent. Il ne décrit pas la topologie réelle de l'hébergement : elle ne se publie pas. À la fin, vous saurez lire le statut de chaque contrôle (câblé, optionnel, prévu) et ce qui reste à votre charge.
Ce que ce chapitre affirme, et ce qu'il n'affirme pas
La grille de lecture est celle de la norme NIST SP 800-207, qui pose sept principes pour une architecture zero trust. C'est une grille, pas une certification : aucun organisme tiers n'a évalué Chatbotaurus contre ce référentiel.
Chaque ligne ci-dessous porte un statut :
- Câblé : le code existe et s'exécute par défaut.
- Optionnel : le code existe, un réglage de l'opérateur l'active.
- Prévu : une décision ou un chantier est tracé, rien n'est livré.
Identité : qui parle
| Contrôle | Statut | Détail |
|---|---|---|
| Jeton de session signé, algorithme épinglé | Câblé | Le serveur refuse un jeton dont l'algorithme n'est pas celui attendu. |
| Signature post-quantique du jeton (ML-DSA-65, FIPS 204) | Optionnel | Une seconde signature est ajoutée au jeton classique quand FORGE_PQC_ENABLED=1. Sans ce réglage, le jeton reste classique. |
| Canal hybride X25519 + ML-KEM-768 (FIPS 203) vers la passerelle MCP | Optionnel | Activé par FORGE_PQC_CHANNEL_ENABLED côté passerelle. |
| Second facteur (TOTP, WebAuthn, codes de secours) | Câblé | Par défaut (FORCE_2FA vaut true), la connexion par mot de passe exige un second facteur : TOTP si enrôlé, sinon code par courriel. L'obligation d'enrôler le TOTP par rôle est un réglage de déploiement : FORGE_MFA_REQUIRED_ROLES ou FORGE_MFA_TOTP_REQUIRED. Un compte créé par le SSO n'a pas de second facteur applicatif : Authentik le porte en amont. |
| Authentification fédérée (OIDC) | Câblé, avec repli | Voir le chapitre SSO Authentik. |
L'état réel des primitives cryptographiques se lit sur le point d'entrée GET /api/v1/crypto/status. Il répond selon l'environnement, jamais selon une affirmation figée.
Réseau : segmentation en deux plans
Le déploiement sépare deux plans, chacun dans son propre réseau de conteneurs :
- le plan de la plateforme (backend, base, coffre de secrets, observabilité) ;
- le plan des outils du client (passerelle et serveurs MCP).
Le principe : un compromis d'un plan ne donne pas un accès direct à l'autre. Le pont entre les deux peut être coupé pendant un incident. Les ports internes sont liés à la boucle locale de l'hôte ; sur le plan de la plateforme, seuls l'ingress et le service temps réel publient sur toutes les interfaces. Le détail des adresses, des ports et des règles n'est pas publié.
Un fichier de règles nftables existe pour le plan client. Son application effective sur chaque hôte relève de l'opérateur.
Application : ce que chaque requête traverse
La pile de couches du serveur API est documentée dans le code et verrouillée par un test. Dans l'ordre d'entrée :
- identifiant de requête ;
- en-têtes de sécurité ;
- détection d'énumération (blocage automatique de l'adresse) ;
- limiteur par compte, puis limiteur par adresse sur les chemins d'authentification ;
- vérification mTLS / SPIFFE, optionnelle ;
- refus des domaines de cloud hors UE (huit domaines) ;
- cloisonnement par organisation au niveau de la base (RLS PostgreSQL) ;
- limiteur de débit, jeton anti-CSRF, délai maximal par requête.
Figure 6 : les huit couches que traverse chaque requête avant le handler.
La couche mTLS est désactivée par défaut (ZERO_TRUST_ENABLED). Quand elle est active, elle n'accepte l'identité du client que si un proxy de confiance l'a posée (ZERO_TRUST_TRUST_PROXY) : sans cette précaution, un en-tête forgé suffirait. Elle est donc à ranger en Optionnel, pas en défense par défaut.
L'autorisation combine des rôles (RBAC) et des politiques Cedar. Les politiques sont lues dans policies/. En posture de production, l'absence ou l'invalidité de ces fichiers refuse le démarrage. Seule une posture de développement explicite tolère un moteur absent, et dans ce cas les gardes Cedar laissent passer. Les gardes Cedar sont appelées par handler : toutes les routes ne passent pas par elles.
Appareil : le conteneur
Un « appareil » est ici un conteneur Podman sans privilège.
- Le conteneur du backend s'exécute sans nouveaux privilèges, avec toutes les capacités retirées sauf celle de lier un port, une limite de processus et de mémoire, et un
/tmpen mémoire sans exécution. - Les images sont épinglées (tag, parfois empreinte).
- Un workflow analyse l'image du backend avec Trivy (gravité haute et critique) et la signe avec Cosign. Il est dormant : aucun exécuteur n'y est rattaché, il ne tourne pas aujourd'hui.
- Des profils seccomp et AppArmor sont maintenus dans le dépôt. Leur application sur chaque service n'est pas établie par le dépôt : ne pas la tenir pour acquise.
Données : classer et chiffrer
Le classificateur de données distingue cinq niveaux : public, interne, personnel, sensible (article 9 du RGPD) et restreint.
| Donnée | Protection |
|---|---|
| Identifiants de services externes | AES-256-GCM au repos, valeur jamais renvoyée (masquée en lecture) |
| Mots de passe | Argon2id |
| Secret TOTP | chiffré au repos |
| Journal d'audit | XChaCha20-Poly1305 sur le puits chiffré |
| Secrets de déploiement | sops + age, puis OpenBao à l'exécution (chapitre OpenBao et secrets) |
Le mode « compute » de la surface FHE est une enveloppe AES-256-GCM. Ce n'est pas du chiffrement homomorphe. Le chiffrement homomorphe est sur la feuille de route, pas dans le produit.
Visibilité : voir ce qui se passe
- Journal d'audit chaîné (SHA-256), vérifiable à la demande par un administrateur (
/audit/verify: 200 vérifiée, 409 rompue, 503 indéterminée). - Métriques de l'API au format Prometheus (
/metrics, accès protégé). VictoriaMetrics et VictoriaLogs existent dans le plan de développement ; aucune unité de production ne les déploie et rien ne les alimente par défaut. L'export de la chaîne d'audit vers VictoriaLogs est optionnel (FORGE_SIEM_ENABLED=1). - Beszel (supervision de l'hôte) et CrowdSec (blocage des adresses malveillantes en bordure) sont déployés par le plan de la plateforme.
- Falco (sécurité d'exécution) a une unité Quadlet, retirée du déploiement le 2026-09-19 : il n'est pas déployé. Les outils SIEM et IDS retirés (spec 98) ne font plus partie du plan.
- Il n'y a ni SIEM temps réel ni centre de supervision 24/7. L'émetteur SIEM du code est dormant.
Automatisation
- La rotation des secrets se fait par OpenBao, sur procédure opérateur. Il n'y a pas de rotation automatique des certificats mTLS livrée.
- Le révoquement d'un jeton compromis passe par une liste de refus des jetons.
- Les gardes du dépôt (gates) s'exécutent avant chaque commit : elles font échouer la livraison quand une exigence n'est plus tenue.
Lacunes assumées
- Pas de test d'intrusion indépendant à ce jour. Le modèle de menaces est un modèle de bureau, écrit par l'équipe qui a écrit le code.
- mTLS entre services : optionnel, désactivé par défaut.
- Application des profils seccomp / AppArmor : non démontrée par le dépôt.
- Pas de supervision humaine 24/7.
Voir aussi
- Modèle de menaces — actifs, frontières de confiance et menaces que ces contrôles doivent couvrir
- Réponse aux incidents — comment ces contrôles servent à détecter, confiner et notifier un incident
- OpenBao et secrets — les deux paliers de gestion des secrets et leur rotation
- SSO Authentik — authentification fédérée OIDC, repli par mot de passe et second facteur
- Conformité NIS2 — exigences de gestion des risques que cette architecture doit satisfaire