Architecture

Sécurité & conformité


Piste d'audit inviolable, séparation des tâches, KYC/AML — le niveau exigé par votre métier.

La sécurité est posée dans le modèle de données, pas ajoutée à la fin. Dans un système financier, la question n'est pas seulement « qui peut entrer », mais « que peut-on prouver six mois plus tard ».

L'immuabilité imposée par la base, pas par la discipline

REVOKE UPDATE, DELETE ON journal_entries, postings FROM amtm_app;

Une écriture ne peut pas être modifiée, ni effacée. Pas parce que le code s'en abstient — parce que la base refuse. Un bug applicatif, une erreur de manipulation ou une intervention malveillante ne peuvent physiquement pas corrompre l'historique. Une correction est une contre-passation : l'erreur et sa correction restent toutes deux visibles.

Piste d'audit à chaînage cryptographique

Chaque ligne du journal d'audit intègre le hachage de la précédente :

hash = sha256( prev_hash ‖ seq ‖ horodatage ‖ acteur ‖ action ‖ données )

Toute modification a posteriori d'une ligne casse la chaîne et devient détectable. Un auditeur externe peut vérifier l'intégrité de la totalité de l'historique sans nous faire confiance, et sans nous demander quoi que ce soit.

Séparation des tâches

  • RBAC granulaire : rôle × agence × plafond. Un caissier ne voit que sa caisse.
  • Celui qui saisit ne valide pas. Au-delà d'un seuil paramétrable, double validation obligatoire.
  • Chaque compte est nominatif. Aucun compte partagé, jamais — c'est la première faille de ce type d'exploitation.
  • Sessions expirantes, déconnexion forcée à distance, journal des connexions.

Le cloisonnement est dans la base

ALTER TABLE postings ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON postings
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

Même si le code applicatif se trompe, la base ne rend pas les lignes d'un autre client. C'est ce qui rend la revente à d'autres sous-agents défendable devant un tiers.

KYC / AML

  • Identifiants secondaires obligatoires dès la saisie : nom seul ne suffit pas. Date de naissance, nationalité et pièce d'identité sont ce qui permet de confirmer ou d'écarter un candidat, avec une justification documentée.
  • Filtrage flou des listes de sanctions : phonétique, translittération, alias — le filtrage sur nom exact rate trop de vrais positifs.
  • Rescreening automatique de la base existante à chaque mise à jour de liste, pas seulement un contrôle à l'entrée.
  • Surveillance : règles de seuils, détection de fractionnement, corridors à risque, génération et suivi des déclarations de soupçon.

Continuité

Chiffrement TLS partout, chiffrement au repos des pièces d'identité, secrets hors du code, sauvegardes WAL avec restauration à un instant précis.

Les objectifs ne sont pas des intentions, ils sont chiffrés et engagés dans la proposition :

EngagementValeurCe que cela veut dire
RPOmoins de 5 minutesLa quantité de données perdues au pire d'un sinistre. Le standard des systèmes bancaires critiques se situe entre une et cinq minutes.
RTOmoins de 1 heureLe délai avant reprise du service. Mesuré lors d'un exercice réel, chronomètre remis.
Disponibilité99,5 %Soit 3 h 39 d'indisponibilité tolérées par mois. C'est un budget d'erreur : il se consomme, il se mesure, et quand il est épuisé on arrête de livrer des fonctionnalités pour rétablir la fiabilité.
Une sauvegarde jamais restaurée n'est pas une sauvegarde. L'exercice de restauration est testé et chronométré avant la mise en production, et le résultat vous est remis par écrit.

Ce que nous prouvons avant le lancement

  • Rapport de test d'intrusion (méthodologie OWASP)
  • Rapport de test de charge
  • Rapport de restauration : durée mesurée, données vérifiées
  • Vérification de l'intégrité de la chaîne d'audit sur un jeu de données de recette