הצפנה הקשרית עבור צינורות נתונים של LLM ומסדי נתונים וקטוריים
פלטפורמת AI ארגונית נדרשה להפעיל תכונות מבוססות LLM (צ'אט, חיפוש, ניתוח מסמכים) תוך הבטחת נתונים רגישים — PII, רשומות פיננסיות, מידע רפואי — יישארו מוצפנים לאורך כל הצינור, כולל כאשר הם מאוחסנים כ-vector embeddings במסד נתונים וקטורי.
דון בפרויקט שלך
האתגר
שימוש ב-LLMs ובמסדי נתונים וקטוריים עם נתונים רגישים הציג סיכוני אבטחה חדשים:
- התקפות היפוך Embeddings — מחקר הראה ש-vector embeddings ניתנים להנדסה לאחור כדי לשחזר טקסט מקורי, ובכך לחשוף PII המאוחסן ב-vector DBs
- דליפת הקשר מ-LLM — נתונים רגישים שנשלחו ל-LLMs עלולים להופיע בתגובות למשתמשים אחרים אם לא יבודדו כראוי
- דרישות תאימות — GDPR, HIPAA, ו-SOC2 דרשו הצפנה במנוחה ובתעבורה, אך מסדי נתונים וקטוריים אחסנו ייצוגים מתמטיים, לא שדות טקסט מסורתיים
- פונקציונליות חיפוש — הצפנת טקסט לפני הטמעה הרסה משמעות סמנטית, והפכה את חיפוש הדמיון לבלתי שימושי
- ניהול מפתחות — מפתחות הצפנה פר-דייר נדרשו לרוטציה ללא הטמעה מחדש של מערכי נתונים שלמים
- נתיב ביקורת — כל גישה לנתונים רגישים מוצפנים נדרשה לתיעוד לצורך תאימות
הפתרון שלנו
יישמנו ארכיטקטורת הצפנה הקשרית המצפינה באופן סלקטיבי שדות רגישים לפני אחסון תוך שמירה על יכולת חיפוש סמנטית באמצעות גישה שכבתית — הצפנת 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 עוטף מפתחות הצפנת מפתח פר-דייר, אשר בתורם עוטפים מפתחות הצפנת נתונים פר-דייר המשמשים להצפנה ברמת שדה. זה מאפשר רוטציית מפתחות יעילה ללא הצפנה מחדש של כל שרשרת המפתחות.
תהליך רוטציית מפתחות
- DEK חדש נוצר — מפתח הצפנת נתונים חדש נוצר תחת מפתח הצפנת המפתח הקיים
- כתיבות חדשות — כל הנתונים החדשים מוצפנים עם המפתח החדש; המפתח הישן נשאר תקף לקריאות
- הצפנה מחדש ברקע — עבודת אצווה מצפינה מחדש רשומות קיימות עם המפתח החדש
- הוצאת DEK ישן משימוש — לאחר שכל הרשומות הועברו, המפתח הישן מסומן כלא פעיל
- יומן ביקורת — אירוע רוטציה מתועד עם חותמות זמן וספירת רשומות מושפעות
ביקורת ותאימות
יומן ביקורת פענוח
כל אירוע פענוח מתעד מי ביקש זאת, מה פוענח, מתי, מדוע (הקשר הבקשה), ובאיזה מפתח נעשה שימוש — מספק נתיב תאימות מלא.
זכות למחיקה לפי GDPR
המערכת תומכת במחיקת נתונים מלאה הן במסד הנתונים היחסי והן במסד הנתונים הווקטורי, עם רוטציית מפתחות אופציונלית כדי להבטיח קריפטוגרפית שאין גישה שיורית. כל פעולות המחיקה מתועדות ביומן ביקורת GDPR.
תכונות עיקריות
- הצפנה ברמת שדה — AES-256-GCM על שדות רגישים, לא על רשומות שלמות
- טיהור PII — Placeholders שומרים על משמעות סמנטית עבור embeddings
- הזרקה מחדש לאחר LLM — נתונים רגישים אף פעם לא נשלחים לספקי LLM
- מפתחות פר-דייר — מפתחות הצפנה מבודדים עם ניהול AWS KMS
- רוטציית מפתחות — רוטציה ללא השבתה עם הצפנה מחדש ברקע
- בטיחות Embeddings — embeddings מטוהרים מונעים התקפות היפוך על PII
- נתיב ביקורת — כל פענוח מתועד לדיווח תאימות
- תאימות ל-GDPR — מחיקה אוטומטית על פני אחסונים מוצפנים ו-vector DB
תוצאות
מחסנית טכנולוגית
caseStudyDetail.more מקרי בוחן
גלה עוד מהיישומים הטכניים שלנו
עיבוד חשבוניות מבוסס AI עם OCR ושילוב QuickBooks
עסק בגודל בינוני שעיבד מאות חשבוניות ספק בחודש נזקק לביטול הזנת נתונים ידנית על ידי חילוץ אוטומטי של נתוני חשבוניות באמצעות AI/OCR וסנכרונם ישירות ל-QuickBooks לצורך הנהלת חשבונות ומעקב תשלומים.
הזרקת פרסומות בצד הלקוח (CSAI) עם ניתוח סמני SCTE-35 ושילוב נגן מרובה פלטפורמות
פלטפורמת הזרמת וידאו נזקקה ליישם הזרקת פרסומות בצד הלקוח (CSAI) על פני יישומי אינטרנט, מובייל וטלוויזיות חכמות — המאפשרת חוויות פרסום מותאמות אישית ברמת המכשיר עם תמיכה מלאה באינטראקציה עם פרסומות (שכבות-על ניתנות ללחיצה, באנרים נלווים, כפתורי דילוג) שאותן הזרקה בצד השרת אינה יכולה לספק.
שאלות נפוצות
MicrocosmWorks פיתחה צינור הצפנה סלקטיבי שמזהה ומצפין ישויות רגישות כמו שמות, מספרי חשבון ונתוני בריאות בתוך מסמכים לפני שהם נכנסים למאגר הנתונים הווקטורי, תוך שמירה על ההקשר הסמנטי הסובב שה-LLM זקוק לו לאחזור וייצור משמעותיים. בזמן שאילתה, המערכת מפענחת רק את הישויות הספציפיות הדרושות לתגובה, בהתאם לרמת הגישה של המשתמש המבקש, כך שה-LLM לעולם אינו רואה נתונים רגישים גולמיים שאינו מורשה לחשוף.
MicrocosmWorks פתרו זאת על ידי הצפנת ישויות רגישות ברמת הטוקן, תוך כדי חישוב הטמעות על הטקסט המקורי הלא מוצפן, ולאחר מכן אחסון הטקסט המוצפן לצד הווקטורים הסמנטיים במסד הנתונים הווקטורי. החיפוש מאחזר קטעים רלוונטיים סמנטית באמצעות ההטמעות האיכותיות, ושכבת הפענוח משחזרת את התוכן המקורי רק עבור משתמשים מורשים, תוך שמירה על איכות חיפוש מלאה והגנה על נתונים במנוחה.
MicrocosmWorks תכננה את גישת ההצפנה הקונטקסטואלית כדי לתת מענה לדרישות ספציפיות ב-HIPAA, SOC 2, GDPR ו-CCPA, על ידי הבטחה ש-PII ו-PHI מוצפנים at rest ב-vector store ומפוענחים רק בתוך הזיכרון במהלך עיבוד שאילתות מורשה. המערכת מייצרת audit logs חסינים מפני שיבוש של כל אירוע פענוח, אשר עומד בדרישות ניטור הגישה והאחריותיות המשותפות למסגרות תאימות אלו.
MicrocosmWorks בנתה כלי שירות להעברה שמעבד אוספי מסדי נתונים וקטוריים קיימים באופן מצטבר, מצפין ישויות רגישות בנתחי מסמכים מאוחסנים תוך שמירה על הטמעות וקטוריות שלהם, כך שאינך צריך לחשב מחדש הטמעות עבור כל הקורפוס שלך. ההעברה מתבצעת כתהליך רקע שניתן להשהות ולחדש, וצינור השאילתות מטפל בצורה חלקה בנתחים מוצפנים וגם בנתחים שטרם הועברו במהלך תקופת המעבר.
MicrocosmWorks ביצעה אופטימיזציה לפעולות ההצפנה והפענוח כדי להוסיף כ-15-30ms של תקורה לכל שאילתה, וזה זניח בהשוואה לזמן יצירת LLM טיפוסי של 500ms-2s. זיהוי והצפנת ישויות במהלך הקליטה מוסיפים כ-100ms לכל פיסת מסמך, וגם זה מינימלי מכיוון שקליטה היא בדרך כלל תהליך אצווה. המערכת משתמשת בפעולות AES מואצות חומרה ומטמנת מפתחות פענוח בזיכרון כדי למזער את התקורה הקריפטוגרפית.
מוכן לשנות את העסק שלך?
בואו נדון כיצד נוכל ליישם פתרונות דומים לאתגרים שלך.