Kontekstuel Kryptering til LLM- og Vektordatabase-pipelines
En virksomheds AI-platform skulle aktivere LLM-drevne funktioner (chat, søgning, dokumentanalyse) samtidig med at sikre, at følsomme data — PII, finansielle optegnelser, sundhedsoplysninger — forblev krypteret gennem hele pipelinen, herunder når de blev gemt som vektor-embeddings i en vektordatabase.
Diskuter Dit Projekt
Udfordringen
Brug af LLM'er og vektordatabaser med følsomme data introducerede nye sikkerhedsrisici:
- Embedding-inversionsangreb — Forskning viste, at vektor-embeddings kunne reverse-engineer'es for at rekonstruere original tekst, hvilket afslører PII gemt i vektor DB'er
- LLM Kontekstlækage — Følsomme data sendt til LLM'er kunne optræde i svar til andre brugere, hvis ikke korrekt isoleret
- Overholdelseskrav — GDPR, HIPAA og SOC2 krævede kryptering i hvile og under transit, men vektordatabaser gemte matematiske repræsentationer, ikke traditionelle tekstfelter
- Søgefunktionalitet — Kryptering af tekst før embedding ødelagde semantisk betydning, hvilket gjorde lighedssøgning ubrugelig
- Nøglehåndtering — Krypteringsnøgler pr. tenant skulle roteres uden at re-embedde hele datasæt
- Revisionsspor — Hver adgang til dekrypterede følsomme data skulle logges for compliance
Vores Løsning
Vi implementerede en kontekstuel krypteringsarkitektur, der selektivt krypterer følsomme felter før lagring, samtidig med at bevare semantisk søgbarhed gennem en lagdelt tilgang — ved at kryptere PII i metadata og samtidig holde saneret, ikke-følsomt indhold tilgængeligt for embedding.
Arkitektur
- Krypteringsmotor: AES-256-GCM med krypteringsnøgler pr. tenant
- Nøglehåndtering: AWS KMS til nøglegenerering, rotation og adgangskontrol
- PII-detektering: NER-baseret (Named Entity Recognition) PII-klassifikator
- Vektordatabase: Milvus til lighedssøgning på sanerede embeddings
- LLM-lag: Saneret kontekst sendt til LLM, følsomme felter genindsat efter generering
- Revisionssystem: Hver dekrypteringshændelse logges med bruger, tidsstempel og formål
- Database: PostgreSQL til krypterede metadata
Kontekstuel Krypteringsstrategi
Dataklassificering
Før data sendes ind i pipelinen, klassificerer en PII-klassifikator hvert felt efter følsomhedsniveau:
- Meget Følsomme (f.eks. offentlige ID'er, finansielle kontonumre, medicinske ID'er) — Krypteret, aldrig embedded, aldrig sendt til LLM
- Følsomme PII (f.eks. fulde navne, e-mailadresser, telefonnumre) — Krypteret i hvile, erstattet med placeholder før embedding
- Kontekstuelle (f.eks. stillingsbetegnelser, firmanavne) — Krypteret i hvile, tilgængelig for embedding med samtykke
- Ikke-Følsomme (f.eks. produktbeskrivelser, offentlig information) — Gemt og embedded som-er
Krypteringslag
Lag 1: Feltniveaukryptering i hvileFølsomme felter krypteres med AES-256-GCM før lagring. Hver tenant får en dedikeret datakrypteringsnøgle (DEK) administreret gennem et nøglehierarki via AWS KMS. Skyggefælder gemmer søgbare hashes til nøjagtige matchopslag uden at kræve dekryptering.
Lag 2: Sanering før EmbeddingPII detekteres og erstattes med typebevarende placeholders, før tekst sendes til embedding-modellen. Dette bevarer semantisk betydning for lighedssøgning, samtidig med at identificerbare oplysninger fjernes. Den originale-til-placeholder-mapping gemmes krypteret sammen med vektor-posten.
Lag 3: Kontekstindsprøjtning efter LLM-genereringLLM'en modtager saneret kontekst med placeholders til generering af svar. Efter generering genindsætter systemet faktiske værdier fra krypteret lager i svaret. Dette forhindrer følsomme data i at komme ind i LLM-træningsdata eller blive cachelagret af udbyderen.
Vektordatabase-Sikkerhed
Samlingsdesign
Vektorsamlinger gemmer sanerede embeddings sammen med krypterede originale metadata. Tenant-isolation håndhæves via partitionsnøgler, hvor hver tenants metadata krypteres med deres egen nøgle. API-laget validerer tenant-ejerskab før enhver dekrypteringsoperation.
Nøglehåndtering & Rotation
Nøglehierarki
Et flerlags nøglehierarki anvendes: en masternøgle i AWS KMS ombryder nøglekrypteringsnøgler pr. tenant, som igen ombryder datakrypteringsnøgler pr. tenant, der bruges til feltniveaukryptering. Dette muliggør effektiv nøglerotation uden at genkryptere hele nøglekæden.
Nøglerotationsproces
- Ny DEK genereret — Ny datakrypteringsnøgle oprettet under den eksisterende nøglekrypteringsnøgle
- Nye Skrivninger — Alle nye data krypteret med den nye nøgle; den gamle nøgle forbliver gyldig for læsninger
- Baggrundsgenkryptering — Batchjob genkrypterer eksisterende poster med den nye nøgle
- Udfasning af gammel DEK — Når alle poster er migreret, markeres den gamle nøgle som inaktiv
- Revisionslog — Rotationshændelse logget med tidsstempler og antal berørte poster
Revision & Overholdelse
Dekrypterings-revisionslog
Hver dekrypteringshændelse registrerer hvem der anmodede om den, hvad der blev dekrypteret, hvornår, hvorfor (anmodningskontekst), og hvilken nøgle der blev brugt — hvilket giver et komplet compliance-spor.
GDPR Ret til Sletning
Systemet understøtter fuld datasletning på tværs af både den relationelle database og vektordatabasen, med valgfri nøglerotation for kryptografisk at sikre, at der ikke er nogen restadgang. Alle sletteoperationer logges i et GDPR-revisionsspor.
Nøglefunktioner
- Feltniveaukryptering — AES-256-GCM på følsomme felter, ikke hele poster
- PII-sanering — Placeholders bevarer semantisk betydning for embeddings
- Post-LLM Genindsprøjtning — Følsomme data sendes aldrig til LLM-udbydere
- Nøgler pr. tenant — Isolerede krypteringsnøgler med AWS KMS-håndtering
- Nøglerotation — Rotation uden nedetid med baggrundsgenkryptering
- Embedding-sikkerhed — Sanerede embeddings forhindrer inversionsangreb på PII
- Revisionsspor — Hver dekryptering logget til compliance-rapportering
- GDPR-overholdelse — Automatiseret sletning på tværs af krypterede lagre og vektor DB
Resultater
Teknologistak
caseStudyDetail.more Casestudier
Udforsk flere af vores tekniske implementeringer
AI-drevet fakturabehandling med OCR og QuickBooks-integration
En mellemstor virksomhed, der månedligt behandler hundredvis af leverandørfakturaer, havde brug for at eliminere manuel dataindtastning ved automatisk at udtrække fakturadata ved hjælp af AI/OCR og synkronisere dem direkte til QuickBooks for bogføring og sporing af betalinger.
Klient-side annonceindsættelse (CSAI) med SCTE-35-markørparsing og integration af afspillere på flere platforme
En videostreamingplatform skulle implementere klient-side annonceindsættelse (CSAI) på tværs af web-, mobil- og connected TV-apps – hvilket muliggjorde personaliserede annonceringer på enhedsniveau med fuld support for annonceinteraktion (klikbare overlays, følgebannere, skip-knapper), som server-side indsættelse ikke kan tilbyde.
Klar til at Transformere Din Virksomhed?
Lad os drøfte, hvordan vi kan anvende lignende løsninger til dine udfordringer.