Audit, chiffrement et exploitation

Le socle inclut des primitives d'exploitation, mais ne confond pas code prêt à déployer et exploitation entièrement automatisée. Chaque projet confirme ses objectifs de disponibilité, de sauvegarde et de supervision.

Conserver une trace d'audit métier

L'audit trail peut enregistrer le tenant, l'acteur, l'action, le type d'entité, son identifiant, un message, un tag fonctionnel et la date. L'identifiant de l'acteur reste conservé même si son compte est supprimé.

La trace est écrite en base et dans les logs structurés. Elle peut alimenter une page administrateur paginée et filtrable, utile pour le support, la conformité et l'investigation.

Chiffrer les valeurs sensibles

Cryptonomicon fournit un chiffrement authentifié commun, avec AES-256-GCM par défaut ou ChaCha20-Poly1305. Les clés sont dérivées par HKDF à partir d'une clé maître, d'un sel et d'un contexte.

Cette primitive protège par exemple une clé de fournisseur stockée en base. Elle garantit confidentialité et détection d'altération pour les champs qui l'utilisent. Elle ne chiffre pas automatiquement toutes les tables, tous les fichiers ou les volumes de l'infrastructure.

Les mots de passe suivent un autre contrat : ils sont hachés avec Argon2 et ne sont jamais déchiffrables.

Corréler une requête de bout en bout

Les logs Pino sont structurés et enrichis avec un requestId, la route, l'action API, le tenant, l'utilisateur et, lorsque disponible, le projet ou la version. Le contexte est créé avant même le parsing du corps afin de conserver un identifiant de corrélation sur un JSON invalide.

Les erreurs HTTP suivent un catalogue de codes. Les erreurs serveur et les traitements hors requête peuvent être relayés vers le canal d'alerte configuré. Le tracing Datadog et les métriques runtime sont optionnels.

Cette base facilite le diagnostic, mais les SLO, dashboards et règles d'alerte restent à configurer selon l'environnement.

Déployer le runtime de base

L'application générée assemble généralement :

• un frontend servi derrière un point d'entrée public ;
• un backend API ;
• PostgreSQL ;
• les services additionnels réellement utilisés, par exemple RabbitMQ, Redis ou S3.

Le frontend relaie /api et /sso vers le backend. Le backend applique les migrations, initialise les données de sécurité et expose un health check. Les images Docker et les variables d'environnement fournissent une base portable vers le cloud ou l'on-premise.

01NavigateurLa session authentifiée de l'utilisateur

02FrontendSPA, assets statiques et proxy pour /api et /sso

03BackendAPI, autorisations, modules, jobs et health check

04Services de donnéesPostgreSQL, stockage et messagerie réellement utilisés

Checklist de mise en service

1. Construire les images frontend et backend dans la CI.
2. Vérifier les extensions PostgreSQL demandées par le projet.
3. Confirmer une sauvegarde restaurable.
4. Démarrer la base et vérifier sa santé.
5. Démarrer le backend et attendre le health check.
6. Démarrer le frontend et tester l'API via le proxy public.
7. Tester la connexion, une action autorisée, un refus et la persistance après redémarrage.
8. Vérifier logs, audit trail, métriques et alertes.