Chiffrement contextuel pour les pipelines de LLM et de bases de données vectorielles

Nous avons mis en œuvre une architecture de chiffrement contextuel qui chiffre sélectivement les champs sensibles avant le stockage tout en préservant la capacité de recherche sémantique grâce à une approche en couches — en chiffrant les PII dans les métadonnées tout en conservant le contenu assaini et non sensible disponible pour l'embedding.

Architecture

• Moteur de chiffrement : AES-256-GCM avec des clés de chiffrement par tenant
• Gestion des clés : AWS KMS pour la génération, la rotation et le contrôle d'accès des clés
• Détection des PII : Classificateur de PII basé sur le NER (Named Entity Recognition)
• Base de données vectorielle : Milvus pour la recherche de similarité sur des embeddings assainis
• Couche LLM : Contexte assaini envoyé au LLM, champs sensibles réinjectés après génération
• Système d'audit : Chaque événement de déchiffrement est journalisé avec l'utilisateur, l'horodatage et le but
• Base de données : PostgreSQL pour les métadonnées chiffrées

Stratégie de chiffrement contextuel

Classification des données

Avant que toute donnée n'entre dans le pipeline, un classificateur de PII catégorise chaque champ par niveau de sensibilité :

• Hautement sensible (par exemple, identifiants gouvernementaux, numéros de compte financier, identifiants médicaux) — Chiffré, jamais intégré, jamais envoyé au LLM
• PII sensibles (par exemple, noms complets, adresses e-mail, numéros de téléphone) — Chiffrées au repos, remplacées par des placeholders avant l'embedding
• Contextuel (par exemple, titres de poste, noms d'entreprise) — Chiffré au repos, disponible pour l'embedding avec consentement
• Non-sensible (par exemple, descriptions de produits, informations publiques) — Stocké et intégré tel quel

Couches de chiffrement

Couche 1 : Chiffrement au niveau du champ au repos

Les champs sensibles sont chiffrés avec AES-256-GCM avant le stockage. Chaque tenant obtient une clé de chiffrement de données (DEK) dédiée gérée via une hiérarchie de clés via AWS KMS. Les champs « shadow » stockent des hachages recherchables pour des recherches de correspondance exacte sans nécessiter de déchiffrement.

Couche 2 : Assainissement avant l'embedding

Les PII sont détectées et remplacées par des placeholders préservant le type avant que le texte ne soit envoyé au modèle d'embedding. Cela préserve la signification sémantique pour la recherche de similarité tout en supprimant les informations identifiables. Le mappage de l'original au placeholder est stocké chiffré aux côtés de l'enregistrement vectoriel.

Couche 3 : Injection de contexte après la génération par le LLM

Le LLM reçoit un contexte assaini avec des placeholders pour générer des réponses. Après la génération, le système réinjecte les valeurs réelles du stockage chiffré dans la réponse. Cela empêche les données sensibles d'entrer dans les données d'entraînement du LLM ou d'être mises en cache par le fournisseur.

Sécurité de la base de données vectorielle

Conception de la collection

Les collections de vecteurs stockent des embeddings assainis aux côtés des métadonnées originales chiffrées. L'isolation des tenants est assurée via des clés de partition, les métadonnées de chaque tenant étant chiffrées à l'aide de sa propre clé. La couche API valide la propriété du tenant avant toute opération de déchiffrement.

Gestion et rotation des clés

Hiérarchie des clés

Une hiérarchie de clés multi-niveaux est utilisée : une clé maîtresse dans AWS KMS enveloppe les clés de chiffrement de clés par tenant, qui à leur tour enveloppent les clés de chiffrement de données par tenant utilisées pour le chiffrement au niveau du champ. Cela permet une rotation efficace des clés sans rechiffrer toute la chaîne de clés.

Processus de rotation des clés

1. Nouvelle DEK générée — Nouvelle clé de chiffrement de données créée sous la clé de chiffrement de clé existante
2. Nouvelles écritures — Toutes les nouvelles données chiffrées avec la nouvelle clé ; l'ancienne clé reste valide pour les lectures
3. Rechiffrement en arrière-plan — Tâche par lots rechiffrant les enregistrements existants avec la nouvelle clé
4. Retrait de l'ancienne DEK — Une fois tous les enregistrements migrés, l'ancienne clé est marquée comme inactive
5. Journal d'audit — Événement de rotation journalisé avec horodatages et nombre d'enregistrements affectés

Audit et conformité

Journal d'audit de déchiffrement

Chaque événement de déchiffrement enregistre qui l'a demandé, ce qui a été déchiffré, quand, pourquoi (contexte de la requête) et quelle clé a été utilisée — fournissant une piste de conformité complète.

Droit à l'effacement GDPR

Le système prend en charge la suppression complète des données à la fois dans la base de données relationnelle et dans la base de données vectorielle, avec une rotation optionnelle des clés pour garantir cryptographiquement l'absence d'accès résiduel. Toutes les opérations de suppression sont enregistrées dans une piste d'audit GDPR.

Fonctionnalités clés

1. Chiffrement au niveau du champ — AES-256-GCM sur les champs sensibles, pas sur des enregistrements entiers
2. Assainissement des PII — Les placeholders préservent la signification sémantique pour les embeddings
3. Réinjection post-LLM — Les données sensibles ne sont jamais envoyées aux fournisseurs de LLM
4. Clés par tenant — Clés de chiffrement isolées avec gestion AWS KMS
5. Rotation des clés — Rotation sans interruption avec rechiffrement en arrière-plan
6. Sécurité des embeddings — Les embeddings assainis empêchent les attaques par inversion sur les PII
7. Piste d'audit — Chaque déchiffrement est journalisé pour les rapports de conformité
8. Conformité GDPR — Effacement automatisé sur les stockages chiffrés et la base de données vectorielle