Mesures de sécurité

Cette page recense les mesures de sécurité effectivement en place dans la plateforme, et nomme celles qui ne le sont pas encore. Elle ne décrit aucune certification : aucune n'a été obtenue à ce jour.

Identité et accès

• mots de passe conservés sous forme d'empreinte argon2id ;
• second facteur obligatoire (codes temporaires TOTP) pour tout compte humain, avec protection contre le rejeu d'un code ; la clé de chaque compte est chiffrée au repos (AES-256-GCM), avec une clé conservée hors de la base ;
• sessions serveur révocables, dont seule l'empreinte est conservée ; verrouillage après échecs répétés, réponses identiques quelle que soit la cause d'un échec ;
• rôles en trois familles exclusives (configuration, décision, audit), aucune auto-élévation, vérification renforcée pour les actions sensibles ; les droits sont appliqués par le serveur.

Cloisonnement des institutions

Chaque institution dispose de son propre schéma de base de données, protégé par une sécurité au niveau des lignes activée et forcée, et d'un contexte porté par la transaction. L'application se connecte avec un rôle qui ne peut ni contourner ces règles, ni modifier le journal. L'isolation est éprouvée à chaque intégration, contrôle négatif compris. Voir Vue d'ensemble de l'architecture.

Journal d'audit

Chaque institution a sa propre chaîne d'audit : chaque événement est horodaté et chaîné au précédent par une empreinte SHA-256, dans la même transaction que l'opération qu'il trace. Le journal est en ajout seul : le rôle applicatif ne peut que lire et ajouter, et une garde de la base refuse toute modification ou suppression, y compris par le propriétaire des tables. Un vérificateur recalcule la chaîne et désigne le premier événement invalide. Les événements ne contiennent aucune saisie libre susceptible de porter une donnée personnelle.

Les consultations sont journalisées dans la même chaîne : toute lecture d'un dossier (fiche, évaluation, historique du demandeur, consentements, provenance) inscrit, dans la transaction même de la lecture, qui a consulté quel dossier et quelle vue ; une page de liste de travail inscrit le nombre de dossiers montrés. Aucune valeur lue n'est recopiée, et une lecture refusée ne laisse aucune trace.

Le niveau réel est nommé sans arrondi : le journal est à altération détectable, pas infalsifiable. Un acteur disposant des pleins droits sur la base qui réécrirait toute la fin de la chaîne en recalculant chaque empreinte produirait une chaîne cohérente, car aucune empreinte n'est encore ancrée hors de la base.

Surface web

L'interface et le portail sont servis avec des en-têtes stricts : politique de sécurité de contenu, HSTS, interdiction d'encadrement, nosniff, politique de référent et politique de permissions restrictives. Le jeton de session n'est jamais exposé au navigateur.

Secrets, dépendances et conteneurs

Aucun secret n'est versionné, et la détection porte sur le code comme sur son historique. Les dépendances sont auditées et leurs licences contrôlées à chaque intégration. Les conteneurs s'exécutent sous un utilisateur non privilégié ; la pile de référence monte leur système de fichiers en lecture seule, et l'installateur de paquets Python est retiré de l'image de l'API.

Ce qui est encore en construction

• chiffrement des échanges de bout en bout en production : il n'existe pas encore d'environnement de production ; seule la pré-production est servie en HTTPS, avec une base jointe en connexion chiffrée ;
• aucun chiffrement au niveau des champs des données de crédit ; seule la clé du second facteur est chiffrée ainsi ;
• aucun ancrage externe du journal ni horodatage par un tiers ;
• aucun audit de sécurité par un tiers indépendant n'a encore été conduit.