הצפנה הקשרית עבור צינורות נתונים של LLM ומסדי נתונים וקטוריים

יישמנו ארכיטקטורת הצפנה הקשרית המצפינה באופן סלקטיבי שדות רגישים לפני אחסון תוך שמירה על יכולת חיפוש סמנטית באמצעות גישה שכבתית — הצפנת PII במטא נתונים תוך שמירה על תוכן מטוהר ולא רגיש זמין להטמעה.

ארכיטקטורה

• מנוע הצפנה: AES-256-GCM עם מפתחות הצפנה פר-דייר
• ניהול מפתחות: AWS KMS ליצירת מפתחות, רוטציה ובקרת גישה
• זיהוי PII: מסווג PII מבוסס NER (Named Entity Recognition)
• מסד נתונים וקטורי: Milvus לחיפוש דמיון על embeddings מטוהרים
• שכבת LLM: הקשר מטוהר נשלח ל-LLM, שדות רגישים מוזרקים מחדש לאחר יצירה
• מערכת ביקורת: כל אירוע פענוח מתועד עם משתמש, חותמת זמן ומטרה
• מסד נתונים: PostgreSQL עבור מטא נתונים מוצפנים

אסטרטגיית הצפנה הקשרית

סיווג נתונים

לפני שכל נתון נכנס לצינור הנתונים, מסווג PII מסווג כל שדה לפי רמת רגישות:

• רגיש במיוחד (לדוגמה, תעודות זיהוי ממשלתיות, מספרי חשבונות פיננסיים, מספרי זיהוי רפואיים) — מוצפן, אף פעם לא מוטמע, אף פעם לא נשלח ל-LLM
• PII רגיש (לדוגמה, שמות מלאים, כתובות דוא"ל, מספרי טלפון) — מוצפן במנוחה, מוחלף ב-placeholder לפני הטמעה
• הקשרי (לדוגמה, תארי עבודה, שמות חברות) — מוצפן במנוחה, זמין להטמעה בהסכמה
• לא רגיש (לדוגמה, תיאורי מוצרים, מידע ציבורי) — מאוחסן ומוטמע כפי שהוא

שכבות הצפנה

שכבה 1: הצפנה ברמת שדה במנוחה

שדות רגישים מוצפנים באמצעות AES-256-GCM לפני אחסון. כל דייר מקבל מפתח הצפנת נתונים (DEK) ייעודי המנוהל באמצעות היררכיית מפתחות דרך AWS KMS. שדות צל מאחסנים האשים ברי חיפוש עבור חיפושי התאמה מדויקים ללא צורך בפענוח.

שכבה 2: טיהור לפני הטמעה

PII מזוהה ומוחלף ב-placeholders השומרים על טיפוסים לפני שהטקסט נשלח למודל ההטמעה. זה שומר על משמעות סמנטית לחיפוש דמיון תוך הסרת מידע מזהה. מיפוי המקורי ל-placeholder מאוחסן באופן מוצפן לצד רשומת הווקטור.

שכבה 3: הזרקת הקשר לאחר יצירת LLM

ה-LLM מקבל הקשר מטוהר עם placeholders ליצירת תגובות. לאחר יצירה, המערכת מזריקה מחדש ערכים אמיתיים מאחסון מוצפן לתוך התגובה. זה מונע מנתונים רגישים להיכנס לנתוני אימון של LLM או להיטמן על ידי הספק.

אבטחת מסד נתונים וקטורי

עיצוב אוסף

אוספי וקטורים מאחסנים embeddings מטוהרים לצד מטא נתונים מקוריים מוצפנים. בידוד דיירים נאכף באמצעות מפתחות חלוקה, כאשר מטא הנתונים של כל דייר מוצפנים באמצעות המפתח שלו. שכבת ה-API מאמתת בעלות דייר לפני כל פעולת פענוח.

ניהול מפתחות ורוטציה

היררכיית מפתחות

נעשה שימוש בהיררכיית מפתחות רב-שכבתית: מפתח מאסטר ב-AWS KMS עוטף מפתחות הצפנת מפתח פר-דייר, אשר בתורם עוטפים מפתחות הצפנת נתונים פר-דייר המשמשים להצפנה ברמת שדה. זה מאפשר רוטציית מפתחות יעילה ללא הצפנה מחדש של כל שרשרת המפתחות.

תהליך רוטציית מפתחות

1. DEK חדש נוצר — מפתח הצפנת נתונים חדש נוצר תחת מפתח הצפנת המפתח הקיים
2. כתיבות חדשות — כל הנתונים החדשים מוצפנים עם המפתח החדש; המפתח הישן נשאר תקף לקריאות
3. הצפנה מחדש ברקע — עבודת אצווה מצפינה מחדש רשומות קיימות עם המפתח החדש
4. הוצאת DEK ישן משימוש — לאחר שכל הרשומות הועברו, המפתח הישן מסומן כלא פעיל
5. יומן ביקורת — אירוע רוטציה מתועד עם חותמות זמן וספירת רשומות מושפעות

ביקורת ותאימות

יומן ביקורת פענוח

כל אירוע פענוח מתעד מי ביקש זאת, מה פוענח, מתי, מדוע (הקשר הבקשה), ובאיזה מפתח נעשה שימוש — מספק נתיב תאימות מלא.

זכות למחיקה לפי GDPR

המערכת תומכת במחיקת נתונים מלאה הן במסד הנתונים היחסי והן במסד הנתונים הווקטורי, עם רוטציית מפתחות אופציונלית כדי להבטיח קריפטוגרפית שאין גישה שיורית. כל פעולות המחיקה מתועדות ביומן ביקורת GDPR.

תכונות עיקריות

1. הצפנה ברמת שדה — AES-256-GCM על שדות רגישים, לא על רשומות שלמות
2. טיהור PII — Placeholders שומרים על משמעות סמנטית עבור embeddings
3. הזרקה מחדש לאחר LLM — נתונים רגישים אף פעם לא נשלחים לספקי LLM
4. מפתחות פר-דייר — מפתחות הצפנה מבודדים עם ניהול AWS KMS
5. רוטציית מפתחות — רוטציה ללא השבתה עם הצפנה מחדש ברקע
6. בטיחות Embeddings — embeddings מטוהרים מונעים התקפות היפוך על PII
7. נתיב ביקורת — כל פענוח מתועד לדיווח תאימות
8. תאימות ל-GDPR — מחיקה אוטומטית על פני אחסונים מוצפנים ו-vector DB