Architecture de sécurité

2. Chiffrement au repos et en transit

Les coordonnées réelles, emails et numéros, sont chiffrées par la couche applicative en AES-256-GCM avant toute écriture en base : le moteur de stockage ne reçoit jamais de clair. Le schéma est à enveloppe. Les clés de chiffrement des données sont elles-mêmes chiffrées par des clés maîtres versionnées, conservées dans un gestionnaire de secrets dédié, avec dépositaires identifiés et valeurs de contrôle (KCV) consignées permettant de vérifier la validité d'une clé sans l'exposer.

En transit, TLS est imposé sur les sauts sortants et MTA-STS est publié. Le relai applique SPF, DKIM et DMARC, ainsi que SRS et une chaîne ARC.

• Chiffrement applicatif AES-256-GCM au repos, en amont de l'écriture
• Enveloppe DEK/KEK, clés maîtres versionnées, KCV consignées
• TLS imposé, MTA-STS publié, SPF/DKIM/DMARC, SRS et ARC sur le relai

3. Cloisonnement par construction

L'isolation entre marchands ne repose pas sur une règle applicative susceptible d'être contournée par un défaut de code, mais sur la structure des données. Les index de recherche sont des empreintes HMAC dérivées par marchand : la corrélation entre deux bases est impossible par construction, non simplement interdite.

Le moteur de base ajoute deux garanties. La sécurité au niveau des lignes (RLS) est active et les privilèges sont révoqués (REVOKE) sur les tables sensibles, qui n'exposent aucun chemin d'accès client direct ; les lectures transitent par des routes serveur vérifiant la session et l'appartenance. Certaines tables probatoires sont en écriture unique (append-only) au niveau du moteur : elles ne peuvent être ni modifiées ni effacées, y compris par notre propre code applicatif.

• Index de recherche HMAC dérivés par marchand, corrélation inter-marchands impossible par construction
• RLS active et privilèges révoqués sur les tables sensibles, accès par routes serveur contrôlées
• Tables probatoires en écriture unique au niveau du moteur

4. Journal probatoire de consentement

Chaque consentement est horodaté par l'horloge de la base, non forgeable depuis l'application. La preuve conserve le texte réellement affiché à la personne, recopié et versionné, ainsi que la surface et le canal concernés. Le consentement email et le consentement téléphone sont distincts et se révoquent séparément : la finalité est portée par chaque ligne du journal, et la révocation s'applique par finalité au niveau du rail d'envoi.

Tout déchiffrement d'une coordonnée est journalisé avec son motif ; les accès aux index font l'objet d'une revue hebdomadaire, avec une conservation de 24 mois. L'adresse IP de la requête n'est jamais utilisée pour suivre une personne : elle sert uniquement à la sécurité (anti-abus, limitation de débit éphémère, preuve de consentement) et est conservée 12 mois.

• Consentement horodaté par la base, texte affiché versionné, surface et canal enregistrés
• Journal des déchiffrements avec motif, revue hebdomadaire, conservation 24 mois
• IP réservée à la sécurité et à la preuve, jamais au suivi, conservation 12 mois

5. Résistance à l'énumération et à l'observation

La route publique de collecte est conçue pour ne pas se comporter en oracle : ni son contenu ni son temps de réponse ne permettent de déterminer si une adresse est déjà cliente d'un marchand. La réponse est constante, le chemin d'exécution égalisé, les budgets d'appel bornés et surveillés.

En amont, une garde d'entrée refuse toute adresse appartenant à nos propres domaines de relai, avant traitement : le chaînage d'un alias vers un autre alias est impossible.

• Route de collecte non-oracle : réponse et latence constantes, aucun aveu d'appartenance
• Budgets d'appel bornés et alertés
• Garde d'entrée contre le chaînage d'alias

6. Contrôle d'accès et gestion des secrets

L'accès à l'espace marchand impose un second facteur TOTP : aucun chemin de session ne l'ignore. Les messages d'échec d'authentification sont uniformes et ne révèlent pas l'existence d'un compte ; la limitation de débit s'applique à l'authentification et les cookies de session sont durcis.

Les secrets d'exploitation sont générés dans le gestionnaire de secrets, déposés manuellement, et ne transitent jamais par un canal de conversation. Leurs valeurs diffèrent entre environnements.

• Double facteur TOTP obligatoire, aucune session sans second facteur
• Messages d'échec uniformes, limitation de débit, cookies durcis
• Secrets distincts par environnement, jamais transmis par un canal de discussion

7. Intégration continue et méthode de preuve

Neuf barrières bloquantes s'exécutent sur chaque changement : tests, analyse statique, détection de secrets, rejeu depuis zéro des invariants de sécurité, parmi d'autres. Un changement qui affaiblit une garantie ne peut pas être fusionné.

La méthode de validation repose sur la panne-témoin : chaque protection est accompagnée d'un test qui échoue lorsqu'on la retire, de sorte que le succès du test atteste la protection au lieu de la supposer.

• Neuf barrières d'intégration continue bloquantes par changement
• Chaque protection livrée avec le test qui échoue en son absence
• Invariants de sécurité rejoués depuis zéro à chaque intégration

8. Surveillance et disponibilité

La surveillance est organisée en trois étages dont l'alerte ne dépend jamais du système surveillé : un battement de vie émis vers un tiers indépendant, dont le silence déclenche l'alerte (dead man's switch) ; une sonde interne rendant un verdict ; un signalement d'échec immédiat par le système d'initialisation. La chaîne d'alerte a été éprouvée en conditions réelles.

La doctrine de panne est explicite : une panne dégrade la disponibilité, jamais la confidentialité. Aucun mode dégradé n'expose une coordonnée réelle, et aucune panne ne bloque une commande ou une expédition. La procédure de rotation d'urgence d'une clé (révocation, re-chiffrement, ré-émission des alias) a été exécutée en conditions réelles sur environnement de test, et le runbook corrigé à l'issue de l'exercice.

• Surveillance à trois étages, alerte indépendante du système surveillé
• Panne : la disponibilité cède, la confidentialité tient
• Rotation d'urgence de clé exécutée en conditions réelles, runbook validé

9. Continuité et réponse à incident

Un séquestre technique conserve, hors de l'infrastructure de production, un dépôt chiffré dont la clé est détenue par un mandataire externe. Sa libération n'intervient qu'en cas de défaillance constatée et sert exclusivement à la période de bascule, durant laquelle chaque personne choisit ce que devient sa coordonnée ; aucune remise en bloc n'a lieu.

En cas de violation de données, le marchand est notifié sous 48 heures ; la procédure de réponse alignée sur le délai de 72 heures imposé à l'autorité a été passée à blanc. Les inscriptions non confirmées sont purgées à 7 jours. Les durées de conservation sont publiées dans la politique de confidentialité.

• Séquestre de continuité hors production, clé chez un mandataire externe, libération sur défaillance constatée
• Notification du marchand sous 48 h, procédure de réponse exercée à blanc
• Purge des inscriptions non confirmées à 7 jours, durées de conservation publiées

11. Ressources et signalement

Prestataires par pays : page Sous-traitants. Données conservées et durées : politique de confidentialité. Contrat de traitement : DPA. Relation directe avec la personne protégée : la page du « i ».

Signaler une vulnérabilité : security@ncripted.com. Les modalités de contact sont également publiées dans notre fichier /.well-known/security.txt.