Sécurité

Conçu comme un coffre-fort, parce que c’en est un.

Un système de surveillance sait qui sont vos clients, où va leur argent et lesquels font l’objet de soupçons. Chaque couche de SpeculaPro est conçue en partant du principe que ces données ne doivent jamais fuiter et que chaque décision doit pouvoir être prouvée.

Protéger les données

Une défense en profondeur, à commencer par le lieu où résident les données.

Résidence des données

Hébergez SpeculaPro dans votre propre centre de données : les données de vos clients ne quittent jamais votre réseau. Ou choisissez le SaaS : votre espace de travail est rattaché à une seule région et aucune autre ne le servira.

Isolation dans la base de données

En SaaS, chaque table porte l’institution à laquelle elle appartient et la sécurité au niveau des lignes de PostgreSQL filtre chaque requête. Même un bogue de l’application ne peut pas renvoyer les lignes d’une autre institution.

Données personnelles chiffrées

Les numéros de pièce d’identité, les numéros de téléphone, les adresses e-mail et les identifiants de compte sont chiffrés en AES-256-GCM, avec une clé distincte pour chaque institution, dérivée de clés maîtresses renouvelables.

Rapprocher sans révéler

Pour repérer la même Ghana Card chez deux clients, SpeculaPro compare des empreintes à clé (index aveugles HMAC-SHA256), et non les numéros eux-mêmes. Une copie volée de la base de données ne permet pas de deviner les numéros de téléphone.

Besoin d’en connaître

Les données personnelles ne s’affichent en clair que pour les rôles qui en ont reçu l’autorisation, par exemple pour établir une déclaration. Tous les autres voient des valeurs masquées.

Des preuves en ajout seul

Les versions de règles approuvées sont figées, l’historique des dossiers ne peut être ni modifié ni supprimé, et un journal d’audit consigne les changements de configuration, les actions sur les dossiers et les accès.

Accès

La connexion est volontairement difficile à usurper.

Les personnes et les systèmes ne s’authentifient pas de la même façon, et les deux mécanismes sont conçus pour résister à une fuite de la base de données.

Personnes

  • Codes d’application d’authentification activés par défaut. Un mot de passe volé ne suffit pas à lui seul. Chaque code ne sert qu’une fois.
  • Mots de passe hachés avec argon2id, un algorithme conçu pour rendre les tentatives de devinette lentes et coûteuses.
  • Limitation des tentatives et verrouillage contre les essais répétés, avec le même message d’erreur pour chaque échec, afin que les attaquants n’apprennent rien.
  • Sessions courtes et révocables. Par défaut, déconnexion après 30 minutes d’inactivité et au bout de 12 heures au plus ; changer votre mot de passe ferme toutes les autres sessions.
  • Authentification unique (SSO) avec OIDC ou SAML, avec l’authentification multifacteur de votre fournisseur d’identité et des administrateurs de secours en cas de panne. Le provisionnement SCIM crée les comptes et désactive ceux des personnes qui partent depuis votre fournisseur d’identité, en fermant aussitôt leurs sessions.
  • Protection des données intégrée. Durée de conservation par type de données, dans le respect du minimum LBC fixé par chaque loi, gels juridiques, demandes de personnes concernées avec leurs délais légaux et une protection contre la divulgation, et registre des violations avec les délais de notification.
  • Double validation pour l’administration. L’attribution des rôles, les clés API, les webhooks, l’authentification unique et la politique de décision peuvent exiger l’approbation d’une seconde personne ; nul n’approuve sa propre modification, et chaque demande est conservée pour l’audit.
  • Accès du support uniquement avec votre accord. Sur le service hébergé, notre équipe de support ne peut consulter votre espace de travail qu’après l’approbation d’une demande par une personne que vous avez habilitée. L’accès est en lecture seule et limité dans le temps, vous pouvez le révoquer à tout moment, et chaque consultation figure dans votre journal d’audit.

Systèmes

  • Clés API à périmètre limité : l’une pour envoyer des données, l’autre pour demander des décisions. Une clé ne peut rien faire d’autre.
  • Affichées une seule fois, conservées sous forme d’empreinte. SpeculaPro ne peut pas révéler une clé après sa création, pas même à ses propres opérateurs.
  • Révocables à tout moment, avec effet sur tous les serveurs en moins de 5 secondes.
  • TLS mutuel et requêtes signées pour l’ingestion. Prévu

Contrôles

La double validation, imposée par la base de données.

La plupart des systèmes demandent au personnel de suivre une procédure initiateur-valideur. Avec SpeculaPro, c’est la base de données qui refuse tout le reste : le contrôle tient même face à un script erroné ou à un administrateur doté de droits excessifs.

ActionEffectuée parDoit être confirmée par
Modification d’une règleAuteur de règlesUn approbateur différent
ExemptionAnalysteUn approbateur différent, en général le MLRO
Clôture d’un dossier à risque élevéAnalysteUn second approbateur, lorsque la politique l’exige
Déclaration réglementaireAuteurUn approbateur différent

Transparence

Ce que nous affirmons, et ce que nous n’affirmons pas.

Cette page décrit la plateforme telle qu’elle est construite aujourd’hui ; le seul élément qui n’est pas encore disponible porte la mention « Prévu ». Nous ne revendiquons aucune certification que nous ne détenons pas. Si votre équipe de sécurité ou votre régulateur dispose d’un questionnaire, envoyez-le-nous. Nous y répondrons sans détour.

Prochaine étape

Venez avec votre équipe de sécurité.

Nous passerons en revue les flux de données, le chiffrement, la gestion des clés et les options d’hébergement avec les personnes qui devront les valider.