التشفير السياقي لخطوط أنابيب LLM وقواعد بيانات المتجهات
احتاجت منصة AI للمؤسسات إلى تمكين الميزات المدعومة بـ LLM (الدردشة، البحث، تحليل المستندات) مع ضمان بقاء البيانات الحساسة — PII، السجلات المالية، المعلومات الصحية — مشفرة عبر خط الأنابيب بالكامل، بما في ذلك عند تخزينها كتضمينات متجهة في قاعدة بيانات متجهات.
ناقش مشروعك
التحدي
استخدام LLMs وقواعد بيانات المتجهات مع البيانات الحساسة أدى إلى مخاطر أمنية جديدة:
- هجمات عكس التضمين (Embedding Inversion Attacks) — أظهرت الأبحاث أنه يمكن عكس هندسة تضمينات المتجهات لإعادة بناء النص الأصلي، مما يكشف PII المخزنة في قواعد بيانات المتجهات
- تسرب سياق LLM (LLM Context Leakage) — يمكن أن تظهر البيانات الحساسة المرسلة إلى LLMs في استجابات لمستخدمين آخرين إذا لم يتم عزلها بشكل صحيح
- متطلبات الامتثال (Compliance Requirements) — تطلبت GDPR و HIPAA و SOC2 التشفير في وضع السكون وأثناء النقل، لكن قواعد بيانات المتجهات تخزن تمثيلات رياضية، وليست حقول نصية تقليدية
- وظيفة البحث (Search Functionality) — تشفير النص قبل التضمين أدى إلى تدمير المعنى الدلالي، مما جعل البحث عن التشابه عديم الفائدة
- إدارة المفاتيح (Key Management) — تطلبت مفاتيح التشفير لكل مستأجر تدويرًا دون إعادة تضمين مجموعات البيانات بالكامل
- مسار التدقيق (Audit Trail) — كل وصول إلى البيانات الحساسة التي تم فك تشفيرها تطلب تسجيلًا للامتثال
حلنا
قمنا بتطبيق بنية تشفير سياقية تقوم بتشفير الحقول الحساسة بشكل انتقائي قبل التخزين مع الحفاظ على قابلية البحث الدلالي من خلال نهج متعدد الطبقات — تشفير PII في البيانات الوصفية مع الحفاظ على المحتوى المنقح وغير الحساس متاحًا للتضمين.
الهندسة المعمارية
- محرك التشفير (Encryption Engine): AES-256-GCM مع مفاتيح تشفير لكل مستأجر
- إدارة المفاتيح (Key Management): AWS KMS لتوليد المفاتيح وتدويرها والتحكم في الوصول
- اكتشاف PII (PII Detection): مصنف PII يعتمد على NER (التعرف على الكيانات المسماة)
- قاعدة بيانات المتجهات (Vector Database): Milvus للبحث عن التشابه في التضمينات المنقحة
- طبقة LLM (LLM Layer): سياق منقح يُرسل إلى LLM، والحقول الحساسة يُعاد حقنها بعد التوليد
- نظام التدقيق (Audit System): كل حدث فك تشفير يتم تسجيله مع المستخدم، الطابع الزمني، والغرض
- قاعدة البيانات (Database): PostgreSQL للبيانات الوصفية المشفرة
استراتيجية التشفير السياقي
تصنيف البيانات
قبل دخول أي بيانات إلى خط الأنابيب، يقوم مصنف PII بتصنيف كل حقل حسب مستوى الحساسية:
- شديدة الحساسية (Highly Sensitive) (على سبيل المثال، الهويات الحكومية، أرقام الحسابات المالية، الهويات الطبية) — مشفرة، لا يتم تضمينها أبدًا، ولا تُرسل إلى LLM أبدًا
- PII حساسة (Sensitive PII) (على سبيل المثال، الأسماء الكاملة، عناوين البريد الإلكتروني، أرقام الهواتف) — مشفرة في وضع السكون، يتم استبدالها بعناصر نائبة قبل التضمين
- سياقية (Contextual) (على سبيل المثال، المسميات الوظيفية، أسماء الشركات) — مشفرة في وضع السكون، متاحة للتضمين بموافقة
- غير حساسة (Non-Sensitive) (على سبيل المثال، أوصاف المنتجات، المعلومات العامة) — تُخزن وتُضمّن كما هي
طبقات التشفير
الطبقة 1: التشفير على مستوى الحقل في وضع السكون (Field-Level Encryption at Rest)يتم تشفير الحقول الحساسة باستخدام AES-256-GCM قبل التخزين. يحصل كل مستأجر على مفتاح تشفير بيانات (DEK) مخصص يُدار من خلال تسلسل هرمي للمفاتيح عبر AWS KMS. تخزن الحقول الظل التجزئات القابلة للبحث عن عمليات البحث عن التطابق التام دون الحاجة إلى فك التشفير.
الطبقة 2: التنقيح قبل التضمين (Sanitization Before Embedding)يتم اكتشاف PII واستبدالها بعناصر نائبة تحافظ على النوع قبل إرسال النص إلى نموذج التضمين. هذا يحافظ على المعنى الدلالي للبحث عن التشابه مع إزالة المعلومات التعريفية. يتم تخزين تعيين الأصل إلى العنصر النائب مشفرًا بجانب سجل المتجه.
الطبقة 3: حقن السياق بعد توليد LLM (Context Injection After LLM Generation)يتلقى LLM سياقًا منقحًا مع عناصر نائبة لتوليد الاستجابات. بعد التوليد، يعيد النظام حقن القيم الفعلية من التخزين المشفر في الاستجابة. هذا يمنع البيانات الحساسة من الدخول في بيانات تدريب LLM أو تخزينها مؤقتًا بواسطة المزود.
أمان قاعدة بيانات المتجهات
تصميم المجموعة (Collection Design)
تخزن مجموعات المتجهات التضمينات المنقحة جنبًا إلى جنب مع البيانات الوصفية الأصلية المشفرة. يتم فرض عزل المستأجر عبر مفاتيح التقسيم، مع تشفير البيانات الوصفية لكل مستأجر باستخدام مفتاحه الخاص. تتحقق طبقة API من ملكية المستأجر قبل أي عملية فك تشفير.
إدارة وتدوير المفاتيح
التسلسل الهرمي للمفاتيح (Key Hierarchy)
يُستخدم تسلسل هرمي للمفاتيح متعدد المستويات: مفتاح رئيسي في AWS KMS يغلف مفاتيح تشفير المفاتيح لكل مستأجر، والتي بدورها تغلف مفاتيح تشفير البيانات لكل مستأجر المستخدمة للتشفير على مستوى الحقل. هذا يتيح تدويرًا فعالًا للمفاتيح دون إعادة تشفير سلسلة المفاتيح بأكملها.
عملية تدوير المفاتيح (Key Rotation Process)
- تم إنشاء DEK جديد (New DEK Generated) — تم إنشاء مفتاح تشفير بيانات جديد تحت مفتاح تشفير المفاتيح الحالي
- عمليات الكتابة الجديدة (New Writes) — جميع البيانات الجديدة مشفرة بالمفتاح الجديد؛ ويبقى المفتاح القديم صالحًا للقراءة
- إعادة التشفير في الخلفية (Background Re-encryption) — وظيفة دفعة تعيد تشفير السجلات الموجودة بالمفتاح الجديد
- إيقاف DEK القديم (Old DEK Retirement) — بمجرد ترحيل جميع السجلات، يتم وضع علامة على المفتاح القديم بأنه غير نشط
- سجل التدقيق (Audit Log) — يتم تسجيل حدث التدوير مع الطوابع الزمنية وعدد السجلات المتأثرة
التدقيق والامتثال
سجل تدقيق فك التشفير (Decryption Audit Log)
يسجل كل حدث فك تشفير من طلب ذلك، وماذا تم فك تشفيره، ومتى، ولماذا (سياق الطلب)، وأي مفتاح تم استخدامه — مما يوفر مسار امتثال كاملًا.
حق GDPR في المسح (GDPR Right to Erasure)
يدعم النظام حذف البيانات بالكامل عبر كل من قاعدة البيانات العلائقية وقاعدة بيانات المتجهات، مع تدوير اختياري للمفاتيح لضمان عدم وجود وصول متبقي من الناحية التشفيرية. يتم تسجيل جميع عمليات الحذف في مسار تدقيق GDPR.
الميزات الرئيسية
- التشفير على مستوى الحقل (Field-Level Encryption) — AES-256-GCM على الحقول الحساسة، وليس السجلات بأكملها
- تنقيح PII (PII Sanitization) — العناصر النائبة تحافظ على المعنى الدلالي للتضمينات
- إعادة الحقن بعد LLM (Post-LLM Re-injection) — البيانات الحساسة لا تُرسل أبدًا إلى مزودي LLM
- مفاتيح لكل مستأجر (Per-Tenant Keys) — مفاتيح تشفير معزولة مع إدارة AWS KMS
- تدوير المفاتيح (Key Rotation) — تدوير بدون توقف مع إعادة تشفير في الخلفية
- سلامة التضمين (Embedding Safety) — التضمينات المنقحة تمنع هجمات عكس التضمين على PII
- مسار التدقيق (Audit Trail) — كل عملية فك تشفير يتم تسجيلها لتقارير الامتثال
- امتثال GDPR (GDPR Compliance) — المسح التلقائي عبر المخازن المشفرة وقواعد بيانات المتجهات
النتائج
المكدس التقني
caseStudyDetail.more دراسات الحالة
استكشف المزيد من تطبيقاتنا التقنية
Kickly: منصة مشاريع مدعومة بـ AI للشركات الناشئة
Kickly هي منصة لإدارة المشاريع مدعومة بـ AI ومصممة خصيصًا للشركات الناشئة — تجمع بين أتمتة المهام الذكية، والتعاون الفريقي، وتتبع التقدم في الوقت الفعلي في منتج واحد.
منصة Catant لإدارة الموارد البشرية والقوى العاملة
Catant هي منصة معيارية لإدارة الموارد البشرية والقوى العاملة تساعد المؤسسات على إدارة الموظفين، الرواتب، الحضور، والامتثال من لوحة تحكم واحدة.
الأسئلة الشائعة
قامت MicrocosmWorks بتطوير مسار تشفير انتقائي يحدد ويشفر الكيانات الحساسة مثل الأسماء وأرقام الحسابات والبيانات الصحية داخل المستندات قبل دخولها إلى قاعدة بيانات المتجهات، مع الحفاظ على السياق الدلالي المحيط الذي تحتاجه LLM للاسترجاع والتوليد الهادف. أثناء وقت الاستعلام، يقوم النظام بفك تشفير الكيانات المحددة المطلوبة للاستجابة فقط، بما يتناسب مع مستوى وصول المستخدم الطالب، لكي لا ترى LLM أبدًا بيانات حساسة خام غير مصرح لها بعرضها.
MicrocosmWorks حلت هذه المشكلة عن طريق تشفير الكيانات الحساسة على مستوى الـ token أثناء حساب الـ embeddings على النص الأصلي غير المشفر، ثم تخزين النص المشفر جنبًا إلى جنب مع المتجهات الدلالية في قاعدة بيانات المتجهات. يسترجع البحث الأجزاء ذات الصلة دلاليًا باستخدام الـ embeddings عالية الجودة، وتُعيد طبقة فك التشفير بناء المحتوى الأصلي للمستخدمين المصرح لهم فقط، مما يحافظ على جودة البحث الكاملة مع حماية البيانات at rest.
قامت MicrocosmWorks بتصميم نهج التشفير السياقي لمعالجة متطلبات محددة في HIPAA وSOC 2 وGDPR وCCPA من خلال ضمان تشفير معلومات التعريف الشخصية ومعلومات الصحة المحمية عند السكون في الـ vector store ولا يتم فك تشفيرها إلا في الذاكرة أثناء معالجة الاستعلامات المصرح بها. يقوم النظام بإنشاء سجلات تدقيق غير قابلة للتلاعب لكل حدث فك تشفير، مما يلبي متطلبات مراقبة الوصول والمساءلة المشتركة بين أطر الامتثال هذه.
قامت MicrocosmWorks ببناء أداة ترحيل تعالج مجموعات قواعد بيانات Vector الحالية بشكل تدريجي، حيث تقوم بتشفير الكيانات الحساسة في أجزاء المستندات المخزنة مع الحفاظ على vector embeddings الخاصة بها، لذلك لا تحتاج إلى إعادة حساب الـ embeddings لمجموعة المستندات بأكملها. تعمل عملية الترحيل كعملية خلفية يمكن إيقافها مؤقتًا واستئنافها، ويتعامل الـ query pipeline بسلاسة مع كل من الأجزاء المشفرة وتلك التي لم يتم ترحيلها بعد خلال الفترة الانتقالية.
لقد قامت MicrocosmWorks بتحسين عمليات التشفير وفك التشفير لإضافة حوالي 15-30 مللي ثانية من الحِمل الإضافي لكل استعلام، وهو أمر لا يذكر مقارنة بوقت توليد LLM النموذجي الذي يتراوح من 500 مللي ثانية إلى 2 ثانية. يضيف اكتشاف الكيانات والتشفير أثناء الاستيعاب حوالي 100 مللي ثانية لكل جزء مستند، وهو أيضًا الحد الأدنى نظرًا لأن الاستيعاب عادةً ما يكون عملية دفعية. يستخدم النظام عمليات AES المسرّعة بواسطة الأجهزة ويخزّن مفاتيح فك التشفير مؤقتًا في الذاكرة لتقليل الحِمل التشفيري الإضافي.
مستعد لتحويل عملك؟
دعنا نناقش كيف يمكننا تطبيق حلول مشابهة لتحدياتك.