Sécurité

Ce chapitre décrit les protections que le code applique, avec le fichier qui les porte. Il sépare ce qui est en place de ce qui reste à faire. Il ne revendique aucune certification. À la fin, vous saurez quelles clés poser avant de passer en production et quelles protections reposent sur votre exploitation.

Principes

• Démarrage fermé. Sans déclaration explicite de développement (FORGE_DEV, ou NODE_ENV, ENVIRONMENT, RUST_ENV, APP_ENV valant development, dev, local ou test), forge-api applique la posture production. Le silence n'est jamais une autorisation.
• Cloisonnement par organisation. Les listes sont filtrées par organisation. Hors développement déclaré, forge-api refuse de démarrer sans FORGE_TENANT_STRICT à 1.
• Données hébergées dans l'UE. Le registre des connecteurs refuse un connecteur dont la résidence des données n'est pas dans l'UE ou auto-hébergée (connectors/README.md).

Secrets

• Dans le dépôt : aucun. Les fichiers .env sont ignorés par git. Le modèle .env.example ne porte que des gabarits.
• En production, un script génère les fichiers d'environnement sur la machine cible, avec des permissions restreintes, et n'imprime jamais les valeurs (script d'initialisation des secrets de l'hôte).
• OpenBao est facultatif. Si BAO_ADDR est posée, il surcharge les secrets d'exécution. Le service du fichier Compose tourne en mode développement ; la configuration de production est portée par l'unité de production du coffre.
• Journaux. Un filtre masque les clés d'API, jetons, clés privées et adresses e-mail avant l'écriture (filtre de rédaction du code).

Au démarrage de production, forge-api vérifie :

Le dépôt ne planifie pas de rotation automatique de l'ensemble des secrets : elle reste à organiser côté exploitation. Deux rotations manuelles existent : celle de la clé des données de santé (l'ancienne clé se pose dans PHI_AT_REST_KEY_PREVIOUS, lue en repli) et celle de la clé de l'agent de sauvegarde (route d'administration de la sauvegarde).

Authentification

Le second facteur n'est pas réservé aux administrateurs : il s'applique à tous les comptes tant que FORCE_2FA n'est pas désactivée.

Protection des requêtes

Chaque ligne nomme le composant du serveur qui porte la protection.

Chiffrement

En transit. Le proxy inverse du plan backend (Traefik) impose TLS 1.3 au minimum dans son option par défaut ; une option distincte, hors défaut, autorise TLS 1.2 pour les clients anciens. En posture production, la connexion de forge-api à PostgreSQL applique les paramètres TLS de la configuration.

Au repos. Ce que le code chiffre :

• les secrets TOTP, les identifiants de connecteurs et les secrets SSO, en AES-256-GCM, avec une clé dérivée par enregistrement depuis AT_REST_ENCRYPTION_KEY ;
• les colonnes de données de santé, avec PHI_AT_REST_KEY (crates/forge-db) ;
• la chaîne d'audit, chaînée par empreintes et signée avec AUDIT_SIGNING_KEY (crates/forge-audit).

Le dépôt n'établit pas de chiffrement transparent de PostgreSQL, de Qdrant ou de Valkey. Protégez le disque de l'hôte.

Intrusion et conteneurs

• Les services tournent sous Podman, sans Docker, avec des unités Quadlet utilisables sans droits administrateur.
• CrowdSec détecte les adresses abusives et prend des décisions de blocage. Le déploiement du plan backend l'installe.
• Falco (comportement à l'exécution) a une unité, retirée du déploiement depuis le 2026-09-19 en attendant une version compatible avec le noyau de l'hôte.
• Le contrôle mutuel par certificat (ZERO_TRUST_ENABLED) est décrit comme une ébauche dans le code, prête pour une intégration mTLS complète. Ne le comptez pas comme une protection.

Chaîne d'approvisionnement

• Un workflow construit l'image backend, l'analyse avec Trivy (gravité HIGH et CRITICAL, correctifs disponibles seulement) et la signe avec Cosign par clé (workflow de CI du dépôt). Il est dormant : aucun exécuteur n'y est encore rattaché, il ne tourne pas aujourd'hui.
• Un script analyse les images référencées par les fichiers Compose, et un autre génère un SBOM (scripts/ops/generate-sbom.sh). Ils se lancent à la main.

Bonnes pratiques d'exploitation

• N'exposez jamais PostgreSQL, Qdrant, Valkey ni OpenBao sur Internet.
• Posez ACCOUNT_HASH_SALT, AT_REST_ENCRYPTION_KEY, AUDIT_SIGNING_KEY, PHI_AT_REST_KEY et FORGE_STRICT_SECRETS (à 1) en production.
• Protégez /metrics par PROMETHEUS_BEARER_TOKEN.
• Gardez des permissions restreintes sur les fichiers d'environnement.
• Relisez les gabarits avant de coller une valeur réelle dans un ticket, un journal ou un message : ne publiez jamais de secret.

Signaler une vulnérabilité

Le serveur publie /.well-known/security.txt (crates/forge-api/src/router.rs). Écrivez à security@chatbotaurus.com ; la divulgation coordonnée est décrite dans Réponse aux incidents.

Documents juridiques

Le dossier docs/legal/ du dépôt contient les textes de référence : politique de confidentialité, conditions d'utilisation, accord de traitement des données, analyses d'impact, registre des traitements et attestation de résidence des données.

Voir aussi

• Variables d'environnement — défauts et règles de chaque variable citée dans ce chapitre
• Architecture de confiance zéro — statut de chaque contrôle selon les sept principes NIST
• SSO Authentik — parcours OIDC, refus de connexion et second facteur
• Réponse aux incidents — divulgation coordonnée, sévérités et phases quand une protection cède
• Conformité RGPD — obligations que ces mécanismes techniques mettent en œuvre