mafate.io
Notre SaaS d'Encryption as a Service : une API de chiffrement souverain, hébergée en France, pour aider les entreprises à protéger leurs données sensibles. Produit complet, du serveur de chiffrement en Go jusqu'au dashboard, conçu et développé en interne.
L'histoire du projet
mafate.io est notre propre produit, né d'un constat brutal. En 2024 et 2025, une vague de fuites de données massives a frappé la France : France Travail, des établissements de santé, des systèmes de tiers-payant. Des dizaines de millions de personnes exposées. Le point commun de ces fuites, c'est que les bases concernées stockaient les données en clair. Une donnée chiffrée qui fuite reste illisible, une donnée en clair qui fuite est directement exploitable. On a construit mafate.io pour attaquer ce problème à la racine : rendre le chiffrement des données sensibles simple à déployer, même pour une équipe qui n'a pas d'expert en cryptographie en interne.
Le défi
Le cadre réglementaire se durcit au même moment. La directive européenne NIS2, transposée en droit français, élargit fortement le périmètre des organisations soumises à des obligations de cybersécurité : environ 15 000 entités concernées en France, contre quelques centaines auparavant. Avec DORA pour la finance et le RGPD pour les données personnelles, ces organisations doivent chiffrer leurs données sensibles, gérer et faire tourner leurs clés, puis le prouver à un auditeur. Les grandes plateformes comme AWS KMS ou Azure Key Vault couvrent une partie du besoin, mais ajoutent leur complexité et exposent les données au CLOUD Act américain. Réaliser cette chaîne correctement en interne (HSM, rotation, piste d'audit infalsifiable) demande une expertise rare. mafate.io répond à ce besoin en externalisant toute la chaîne derrière une API.
Défis techniques
- Envelope encryption stricte : générer une clé de données par opération, la wrapper dans le HSM, puis zéroiser la clé en clair en mémoire dès qu'elle a servi
- Provisioning déterministe de la clé maître dans le HSM, pour qu'un conteneur redéployé retrouve la même clé et garde les données déchiffrables
- Piste d'audit à chaîne HMAC : sérialiser les écritures par tenant (un worker dédié par tenant) pour garantir l'ordre et une chaîne linéaire, sans race condition
- Isolation multi-tenant stricte, appliquée sur chaque requête via le tenant_id injecté par la couche d'authentification
- Résilience de l'appel dashboard vers le serveur de chiffrement : retry exponentiel et circuit breaker pour ne jamais propager une panne transitoire
Ce qu'on a construit
- API REST de chiffrement et déchiffrement en AES-256-GCM avec envelope encryption : une clé de données aléatoire par opération, wrappée par une clé maître stockée dans le HSM
- Cycle de vie complet des clés : création, versionnage, rotation manuelle ou automatique planifiée, désactivation, politique de rotation par clé
- Clés API à permissions granulaires (chiffrer, déchiffrer, lire l'audit), avec expiration et allowlist d'adresses IP
- Piste d'audit infalsifiable : chaque entrée est chaînée par HMAC-SHA256 à la précédente, ce qui rend toute altération détectable
- Export de conformité : attestations NIS2, DORA et RGPD générées en CSV et JSON pour les auditeurs
- SDK prêts à l'emploi en Node, Python et Go, et un dashboard complet (facturation Stripe, SSO SAML, 2FA, webhooks, RBAC multi-utilisateur)
HSM matériel certifié FIPS 140-2
Prochaine étape : du HSM logiciel au module matériel certifié
Aujourd'hui, les clés maîtres vivent dans un HSM logiciel (SoftHSM2) piloté via le standard PKCS#11. La feuille de route mène au matériel certifié, sans changer une ligne du code applicatif grâce à l'abstraction PKCS#11 : le module est interchangeable. C'est ce qui permet à un client régulé (santé, banque, assurance) d'exiger un niveau de certification précis sans réécrire son intégration.
Ce que la certification matérielle apporte
- Interface HSM abstraite : le fournisseur (logiciel ou matériel) est un détail d'implémentation, l'API reste identique
- Étape staging : YubiHSM2, certifié FIPS 140-2 niveau 2
- Étape production : Thales Luna, certifié FIPS 140-2 niveau 3
- Clé maître marquée non-extractible : elle ne peut pas sortir du module, même pour un administrateur
- Provisioning déterministe : un conteneur éphémère reconstruit exactement la même clé au redémarrage, sans jamais perdre l'accès aux données chiffrées
Technologies concernées
Les partis pris techniques
- Le texte en clair ne touche jamais la base : seuls le chiffré, la clé wrappée et le vecteur d'initialisation sont persistés
- Clé maître non-extractible du HSM via le standard PKCS#11, avec provisioning déterministe pour survivre à un redéploiement de conteneur
- Cache de clés à deux niveaux (mémoire puis Redis chiffré) pour tenir la charge sans rappeler le HSM à chaque opération
- Déchiffrement jamais bloqué par le quota de facturation : verrouiller un client hors de ses propres données est traité comme une faute de disponibilité, comme le font AWS et GCP KMS
- Souveraineté assumée : société française, hébergement en France, hors périmètre du CLOUD Act
Stack technique
Un produit technique
à concevoir de bout en bout ?
SaaS, API, sécurité, infrastructure : on construit des produits complets, du back-end au déploiement. Parlons du vôtre.
Audit gratuit · Réponse sous 24h · Sans engagement