Kontekstwal na Pag-encrypt para sa Mga Pipeline ng LLM at Vector Database

Nagpatupad kami ng isang arkitektura ng kontekstwal na pag-encrypt na selektibong nag-e-encrypt ng mga sensitibong field bago imbakin habang pinapanatili ang semantic searchability sa pamamagitan ng isang layered approach — nag-e-encrypt ng PII sa metadata habang pinapanatili ang nalinis, hindi sensitibong content na available para sa embedding.

Arkitektura

• Encryption Engine: AES-256-GCM na may per-tenant encryption keys
• Pamamahala ng Key: AWS KMS para sa key generation, rotation, at access control
• PII Detection: NER-based (Named Entity Recognition) PII classifier
• Vector Database: Milvus para sa similarity search sa mga nalinis na embeddings
• LLM Layer: Ang nalinis na konteksto ay ipinadala sa LLM, ang mga sensitibong field ay muling ipinasok pagkatapos ng generation
• Audit System: Ang bawat decryption event ay na-log na may user, timestamp, at layunin
• Database: PostgreSQL para sa encrypted metadata

Estratehiya ng Kontekstwal na Pag-encrypt

Klasipikasyon ng Data

Bago pumasok ang anumang data sa pipeline, isang PII classifier ang nagkakategorya sa bawat field ayon sa sensitivity level:

• Lubhang Sensitibo (hal., government IDs, financial account numbers, medical IDs) — Naka-encrypt, hindi kailanman na-embed, hindi kailanman ipinadala sa LLM
• Sensitibong PII (hal., full names, email addresses, phone numbers) — Naka-encrypt at rest, pinalitan ng placeholder bago mag-embedding
• Kontekstwal (hal., job titles, company names) — Naka-encrypt at rest, available para sa embedding na may pahintulot
• Hindi Sensitibo (hal., product descriptions, public information) — Nakaimbak at na-embed nang ganoon

Mga Layer ng Encryption

Layer 1: Field-Level Encryption at Rest

Ang mga sensitibong field ay naka-encrypt na may AES-256-GCM bago imbakin. Ang bawat tenant ay nakakakuha ng nakatalagang data encryption key (DEK) na pinamamahalaan sa pamamagitan ng key hierarchy sa AWS KMS. Nag-iimbak ang mga shadow field ng mga searchable hash para sa exact-match lookups nang hindi nangangailangan ng decryption.

Layer 2: Sanitization Bago Mag-Embedding

Ang PII ay nade-detect at pinalitan ng type-preserving placeholders bago ipadala ang teksto sa embedding model. Pinapanatili nito ang semantic meaning para sa similarity search habang tinatanggal ang makikilalang impormasyon. Ang original-to-placeholder mapping ay nakaimbak na naka-encrypt kasama ng vector record.

Layer 3: Context Injection Pagkatapos ng LLM Generation

Ang LLM ay tumatanggap ng nalinis na konteksto na may placeholders para sa pagbuo ng mga tugon. Pagkatapos ng generation, muling ipinasok ng system ang aktwal na values mula sa encrypted storage sa tugon. Pinipigilan nito ang sensitibong data na pumasok sa LLM training data o ma-cache ng provider.

Seguridad ng Vector Database

Disenyo ng Koleksyon

Nag-iimbak ang mga vector collection ng nalinis na embeddings kasama ng naka-encrypt na orihinal na metadata. Ang paghihiwalay ng tenant ay ipinapatupad sa pamamagitan ng partition keys, kung saan ang metadata ng bawat tenant ay naka-encrypt gamit ang sarili nitong key. Bine-validate ng API layer ang pagmamay-ari ng tenant bago ang anumang operasyon ng decryption.

Pamamahala at Pag-ikot ng Key

Hierarchy ng Key

Isang multi-level key hierarchy ang ginagamit: isang master key sa AWS KMS ang nagwa-wrap ng per-tenant key encryption keys, na siya namang nagwa-wrap ng per-tenant data encryption keys na ginagamit para sa field-level encryption. Nagbibigay-daan ito sa mahusay na key rotation nang hindi muling nag-e-encrypt ng buong key chain.

Proseso ng Pag-ikot ng Key

1. Bagong DEK Nabuod — Bagong data encryption key na ginawa sa ilalim ng umiiral na key encryption key
2. Mga Bagong Pagsusulat — Lahat ng bagong data ay naka-encrypt gamit ang bagong key; ang lumang key ay nananatiling valid para sa reads
3. Background Re-encryption — Ang batch job ay muling nag-e-encrypt ng umiiral na records gamit ang bagong key
4. Pagre-retiro ng Lumang DEK — Kapag nailipat na ang lahat ng records, ang lumang key ay mamarkahang inactive
5. Audit Log — Ang rotation event ay na-log na may timestamps at affected record counts

Audit at Pagsunod

Decryption Audit Log

Ang bawat decryption event ay kinukuha kung sino ang nag-request nito, ano ang na-decrypt, kailan, bakit (request context), at anong key ang ginamit — nagbibigay ng kumpletong compliance trail.

Karapatan ng GDPR sa Pagbubura

Sinusuportahan ng system ang buong data deletion sa relational database at vector database, na may opsyonal na key rotation upang cryptographically tiyakin na walang natitirang access. Ang lahat ng deletion operation ay na-log sa isang GDPR audit trail.

Mga Pangunahing Feature

1. Field-Level Encryption — AES-256-GCM sa mga sensitibong field, hindi sa buong records
2. PII Sanitization — Ang mga placeholder ay nagpapanatili ng semantic meaning para sa embeddings
3. Post-LLM Re-injection — Ang sensitibong data ay hindi kailanman ipinadala sa mga LLM provider
4. Per-Tenant Keys — Nakahiwalay na encryption keys na may pamamahala ng AWS KMS
5. Key Rotation — Zero-downtime rotation na may background re-encryption
6. Embedding Safety — Ang nalinis na embeddings ay pumipigil sa inversion attacks sa PII
7. Audit Trail — Ang bawat decryption ay na-log para sa compliance reporting
8. Pagsunod sa GDPR — Awtomatikong pagbubura sa buong encrypted stores at vector DB