Conservation des données et chaîne de preuves en ajout seul

La chaîne de preuves en ajout seul (append-only) et un calendrier de suppression de contenu de type RGPD ne sont pas en conflit, car la chaîne ne stocke jamais, au départ, de contenu supprimable.

Le chiffrement des segments remplace l’occultation ; la chaîne reste en ajout seul

• evidence_events est réellement en ajout seul, imposé au niveau de la base de données et pas seulement par le code applicatif : des règles de base de données transforment les UPDATE/DELETE sur la table en opérations sans effet, et un trigger contrôle le previous_hash de chaque nouvelle ligne par rapport au hash de la ligne précédente à l’insertion (intégrité de la chaîne de hachage, contrôlée à l’écriture).
• Les segments de données personnelles sont chiffrés, et non occultés. Chaque segment détecté par les détecteurs pii_scan (BSN, IBAN, carte, e-mail, téléphone, date de naissance, adresse postale) est remplacé dans les copies persistées par un jeton ⟦pii:v1:<TYPE>:<keyset_id>:<base64url(nonce‖ciphertext‖tag)>⟧, le texte environnant restant lisible. Les jetons sont chiffrés avant que l’événement ne soit haché et écrit, de sorte que le jeton chiffré fait partie des données de preuve hachées.
• Les synthèses de preuves enregistrent quel motif ou quelle expression a correspondu et peuvent afficher le jeton (les tableaux de bord montrent des pastilles [Encrypted Email]) ; la transcription brute ou le texte brut de l’expression ne circule jamais en clair.
• Conséquence : l’effacement ne nécessite jamais de toucher à une seule ligne evidence_events. L’opérateur détruit une clé de données via POST /v1/pii/shred ou POST /v1/calls/{id}/pii/shred, et les jetons existants deviennent illisibles sans modification. La chaîne de hachage, ainsi que l’ancrage d’horodatage Merkle/RFC-3161 construit par-dessus, restent intacts et à détection d’altération, que les clés existent ou non.

Les identités et le matériel de clé sont stockés enveloppés ; seuls les jetons sont conservés dans les preuves

• Identités : chaque valeur distincte en clair (un nom, un e-mail, un numéro de téléphone) est suivie comme une identité distincte dans pii_identities, avec sa propre clé de données aléatoire de 32 octets. La valeur en clair elle-même n’est jamais conservée ni journalisée — seul son lookup (HMAC-SHA256 du type et du hash client) est stocké, ce qui permet au tenant de la retrouver sans valeur en clair.
• Enveloppement des clés : les clés de données sont enveloppées avec la K_wrap du tenant (issue du trousseau du tenant dans Secrets Manager) en AES-256-GCM avant d’être écrites dans pii_identities.wrapped_key. La clé enveloppée ne peut être déchiffrée que par le tenant ; la destruction d’une identité met sa clé enveloppée à NULL, ce qui rend les données de cette identité définitivement inaccessibles.
• Jeux de clés : les jetons sont chiffrés sous des clés de contenu dérivées des identités impliquées dans l’appel. Chaque ensemble distinct d’identités reçoit un court keyset_id dans pii_keysets. Détruire n’importe quelle identité d’un jeu de clés rend illisible chaque jeton chiffré sous ce jeu de clés.
• L’effacement est cryptographique : aucune tâche d’arrière-plan ne recherche les lignes expirées. À la place, l’opérateur (ou le tenant via l’API) appelle POST /v1/pii/shred avec le hash client d’un identifiant. Le service trouve l’identité, met sa clé enveloppée à NULL et publie une éviction sur le pub/sub Redis. Les jetons existants deviennent [ERASED_<TYPE>] à l’ouverture, et la chaîne de preuves montre un événement PII_SHREDDED qui prouve quand l’effacement a eu lieu.

Délai d’effacement : quand les données deviennent-elles réellement irrécupérables ?

Bascule valable pour la suite uniquement ; les enregistrements sont exclus

• Bascule : à compter de cette version, le chiffrement est activé par défaut pour les nouveaux appels et tous les segments détectés sont chiffrés. Les appels démarrés avant cette version peuvent contenir des segments en clair dans leurs preuves (ces lignes sont hachées dans la chaîne et ne peuvent pas être modifiées) ; ils ne peuvent pas être chiffrés rétroactivement.
• Enregistrements : les enregistrements audio sont stockés dans S3 avec le chiffrement SSE-S3 et le versionnement, assortis d’un verrou de cycle de vie de 7 jours et de politiques de conservation distinctes. Ils ne sont pas couverts par le crypto-shredding dans cette version ; l’effacement de l’identité d’un appelant n’efface pas l’enregistrement. Ce point est suivi pour un jalon futur.
• Noms : les identités de nom n’existent que si le tenant les fournit sous forme de hash à l’initialisation de l’appel ou via l’API de lien d’identité. Les noms prononcés pendant une conversation ne sont pas détectés automatiquement ; l’effacement d’un nom est donc plus limité que celui d’un e-mail ou d’un numéro de téléphone — il n’efface que les identités que le tenant a enregistrées, et non chaque mention dans l’appel. La documentation de l’API traite de cette limite.

Le crypto-shredding assure un effacement immédiat ; les enregistrements sont un sujet distinct

À compter de cette version, le crypto-shredding est le principal mécanisme d’effacement au titre de l’article 17 du RGPD pour les données personnelles présentes dans les preuves. Il réalise l’effacement immédiatement :

• Le tenant (ou l’opérateur) appelle POST /v1/pii/shred avec le hash client d’un identifiant.
• Le service trouve l’identité, met sa clé enveloppée à NULL et publie une éviction sur le pub/sub Redis.
• En 60 secondes, les jetons existants chiffrés sous cette identité deviennent illisibles.
• Un espace réservé [ERASED_<TYPE>] est renvoyé à toute tentative de déchiffrement ultérieure, et la chaîne de preuves montre un événement PII_SHREDDED.

Les enregistrements restent un sujet distinct, suivi pour un jalon futur :

• Les enregistrements d’appels (fichiers audio dans S3) ne sont pas couverts par ce jalon.
• Ils sont stockés avec le chiffrement SSE-S3 et le versionnement, assortis d’un verrou de cycle de vie de 7 jours et de politiques de conservation distinctes.
• L’effacement de l’identité d’un appelant n’efface pas l’enregistrement.
• Une version future mettra en œuvre :
  • Un runbook pour la suppression hors bande des enregistrements.
  • Une éventuelle intégration future du cycle de vie des enregistrements avec la destruction des identités (nécessite des décisions d’architecture sur les E/S de stockage).