تعدد المستأجرين في عملاء الذكاء الاصطناعي: عزل بيانات الاعتماد وفصل مساحات الأسماء و SOC 2

تعدد المستأجرين في عملاء الذكاء الاصطناعي هو الخاصية المعمارية لمنصة العملاء التي تعزل بيانات الاعتماد والذاكرة وسياق التنفيذ وسجلات التدقيق لكل مستأجر عن جميع المستأجرين الآخرين، مطبقة على مستوى البنية التحتية وليس من خلال اتفاقيات المطورين أو اتباع تعليمات العميل. على عكس تعدد المستأجرين في تطبيقات الويب، يحتفظ العملاء بمفاتيح API نشطة، ويتراكم لديهم ذاكرة دائمة بين الطلبات، وينفذون استدعاءات أدوات مصادق عليها: ثلاثة أبعاد تتجاوز عزل صفوف البيانات يجب تقسيمها لكل مستأجر لتلبية متطلبات OWASP LLM06 و SOC 2 CC6.1.

تعدد المستأجرين في عملاء الذكاء الاصطناعي هو الخاصية المعمارية لمنصة العملاء التي تضمن أن العملاء الذين يخدمون مستأجرين مختلفين لا يستطيعون الوصول إلى بيانات اعتماد بعضهم أو ذاكرتهم أو سياق تنفيذهم أو سجلات تدقيقهم، مطبقة على مستوى البنية التحتية من خلال نطاقات خزينة بيانات الاعتماد لكل مستأجر، وقوائم التحكم في الوصول (ACL) لمساحة أسماء اللوح الأسود، وعزل التنفيذ في الحاويات، وسجلات التدقيق المقسمة، بحيث يرث منتج SaaS B2B المبني على المنصة عزل المستأجر كضمان هيكلي وليس كمسؤولية مطور.

لماذا تعدد المستأجرين في العملاء أصعب من تطبيقات الويب

يعزل تعدد المستأجرين التقليدي في تطبيقات الويب شيئا واحدا: صفوف البيانات. أضف عمود tenant_id، وصفّي كل استعلام، وينتهي الأمر. يجب على تعدد المستأجرين في العملاء عزل ثلاثة أبعاد إضافية لم تضطر تطبيقات الويب لمعالجتها. الفشل في أي منها يشكل حدث تسرب بيانات عبر المستأجرين وفق OWASP LLM06 للكشف عن المعلومات الحساسة.

الأبعاد الثلاثة للعزل التي لم تكن لدى تطبيقات الويب

عزل بيانات الاعتماد: تطبيقات الويب تحدد هوية المستخدم عبر رمز الجلسة؛ الجلسة لا تملك وصولا دائما للخدمات الخارجية. العملاء يحتاجون إلى مفاتيح API حقيقية محددة النطاق للمستأجر. إذا شارك عميل المستأجر A وعميل المستأجر B مفتاح OpenAI واحدا، فإن الاستخدام المكثف للمستأجر A يتدهور هامش حد المعدل للمستأجر B؛ تشمل فاتورة المستأجر A استهلاك رموز المستأجر B؛ إلغاء المفتاح بعد اختراق المستأجر A يعطل المستأجر B أيضا؛ ولا يمكن تقسيم سجلات الاستخدام في لوحة تحكم المزود لكل مستأجر.

عزل الذاكرة: يتراكم لدى العملاء ذاكرة عمل (نافذة السياق)، وذاكرة دلالية (تضمينات مخزن المتجهات)، وحالة التنسيق (مدخلات اللوح الأسود) عبر التفاعلات. إذا لم يتم تقسيم أي من هذه المخازن لكل مستأجر، يمكن أن تظهر وثائق المستأجر A التي تم استرجاعها في سياق العميل أثناء مهمة ما، في سياق عميل المستأجر B أثناء مهمة ذات صلة دلاليا، دون الحاجة لأي إدخال خصومي.

عزل سجل التدقيق: لا يمكن تصدير سجل التدقيق المشترك حيث تختلط استدعاءات أدوات المستأجر A والمستأجر B إلى فريق الامتثال لدى المستأجر A دون الكشف عن سجلات المستأجر B. يتطلب SOC 2 CC6.1 أن يتمكن مدقق كل مستأجر من رؤية سجلاته الخاصة فقط.

Shared-Nothing مقابل Pool مقابل Bridge: ثلاثة نماذج لتعدد المستأجرين

نموذج الصومعة (Shared-Nothing): يحصل كل مستأجر على بنية تحتية مخصصة بالكامل. الحد الأقصى للعزل بأعلى تكلفة لكل مستأجر. مناسب للمستأجرين من المؤسسات ذوي متطلبات صارمة لإقامة البيانات والصناعات المنظمة.

نموذج التجمع (Pool): يتشارك جميع المستأجرين البنية التحتية مع تطبيق العزل فقط على مستوى طبقة التطبيق من خلال تصفية معامل tenant_id. أقل تكلفة، أضعف عزل. مناسب فقط لأعباء العمل منخفضة الحساسية بدون عملاء مؤسسيين.

نموذج الجسر (Bridge): بنية تحتية حوسبة مشتركة مع تطبيق العزل على مستوى مستوى التحكم. يحصل كل مستأجر على نطاق خزينة بيانات اعتماد مخصص ومساحة اسم ذاكرة مطبقة بواسطة قوائم التحكم في الوصول للبنية التحتية. هذا هو الافتراضي الموصى به لـ B2B SaaS. معمارية OpenLegion المستندة إلى المشروع هي تطبيق لنموذج الجسر.

OWASP LLM06: الكشف عن معلومات حساسة عبر المستأجرين

يصنف OWASP LLM Top 10 v1.1 تسرب البيانات عبر المستأجرين تحت LLM06 بخطورة عالية.

متجه هجوم التسرب عبر المستأجرين

1. يعالج عميل المستأجر A طلب دعم عملاء. يسترجع وثائق المنتج الداخلية وسجلات العملاء للمستأجر A في نافذة سياقه، ثم يدمج ويخزن المقاطع ذات الصلة في مخزن المتجهات المشترك.
2. يعالج عميل المستأجر B طلبا مماثلا دلاليا. يستعلم مخزن المتجهات المشترك؛ يُعيد الاستعلام مقاطع المستأجر A المضمنة كأقرب جيران K لأنها متشابهة موضوعيا ولا يوجد فهرس مقسم لكل مستأجر.
3. تظهر سجلات عملاء المستأجر A الداخلية في سياق عميل المستأجر B.

لا يلزم أي إدخال خصومي. التسرب هو فشل معماري.

للإطار الكامل بما في ذلك حقن الموجه (LLM01) انظر أمان عملاء الذكاء الاصطناعي ونموذج تهديد OWASP LLM Top 10.

تسرب الذاكرة: ذاكرة العمل ومخازن المتجهات وحالة اللوح الأسود

تتطلب ثلاثة أنواع من ذاكرة العميل كل منها معالجة عزل مستأجر منفصلة:

ذاكرة العمل (نافذة السياق): لا يجب أبدا مشاركة نافذة السياق الحالية للعميل عبر طلبات المستأجرين.

الذاكرة الدلالية (مخزن المتجهات): عند استخدام مخزن متجهات مشترك، يجب أن تتضمن كل عملية كتابة tenant_id كحقل بيانات وصفية إلزامي، ويجب أن يتضمن كل استعلام مرشح بيانات وصفية {tenant_id: current_tenant_id} محقونا على مستوى طبقة عميل التخزين.

حالة التنسيق (اللوح الأسود): يجب أن تستخدم حالة المفتاح-القيمة المشتركة عبر العملاء بادئات مفاتيح محددة النطاق للمستأجر، مثل projects/{tenant_id}/*.

عزل بيانات الاعتماد: تحديد نطاق الخزينة لكل مستأجر

تحديد نطاق بيانات الاعتماد لكل مستأجر: لماذا تفشل مفاتيح API المشتركة

أكثر خطأ شائع في بيانات اعتماد تعدد المستأجرين هو استخدام مفتاح API واحد لـ LLM لجميع المستأجرين. يفشل هذا بأربع طرق مميزة: مشاركة حد المعدل، وعدم إمكانية إسناد التكلفة، ونطاق الإلغاء، وكسر عزل التدقيق.

النمط الصحيح: يحصل كل مستأجر على مفتاح API الخاص به. لمعمارية الخزينة الكاملة انظر إدارة بيانات الاعتماد وأنماط تحديد نطاق الخزينة لكل مستأجر.

النمط المضاد لـ JWT: نطاق الرمز بدون إلغاء

ثلاثة تخفيفات، جميعها مطلوبة معا:

1. رموز قصيرة العمر: TTL بحد أقصى 300 ثانية (5 دقائق) لرموز استدعاء أدوات العميل.
2. سجل الإلغاء النشط: جدول معرفات الرموز الصالحة لكل مستأجر.
3. تدوير الرموز لكل مهمة: إصدار رمز جديد لكل مهمة عميل.

عزل التنفيذ: مساحات أسماء Kubernetes وحصص الموارد

مساحة الاسم لكل مستأجر: RBAC و NetworkPolicy و ResourceQuota

أربعة مكونات مطلوبة:

مساحة الاسم لكل مستأجر: تعمل pods العميل لكل مستأجر في مساحة اسم Kubernetes مخصصة.

RBAC مع ServiceAccounts محددة النطاق بمساحة الاسم: يحصل كل مستأجر على ServiceAccount مخصص مع RoleBindings محددة النطاق لمساحة اسمه الخاصة.

NetworkPolicy مع رفض افتراضي: تطبيق سياسة رفض جميع الدخول والخروج على كل مساحة اسم مستأجر بشكل افتراضي.

ResourceQuota مع LimitRange: تطبيق حدود CPU والذاكرة وعدد الـ pods لكل مساحة اسم.

لضوابط وضع الحماية على مستوى العملية انظر وضع حماية عملاء الذكاء الاصطناعي وعزل التنفيذ على مستوى العملية.

امتثال SOC 2 لمنصات العملاء متعددة المستأجرين

CC6.1: ضوابط الوصول المنطقي حسب تصنيف البيانات

يتطلب امتثال CC6.1 ثلاثة ضوابط محددة: نطاق خزينة بيانات الاعتماد لكل مستأجر، ومساحة اسم الذاكرة لكل مستأجر، وقسم سجل التدقيق لكل مستأجر.

يصنف مدققو SOC 2 مفاتيح API المشتركة المستخدمة عبر المستأجرين كإشكاليات CC6.1. للتعيين الكامل للضوابط انظر حوكمة عملاء الذكاء الاصطناعي وأطر امتثال SOC 2.

CC6.6: تقييد الوصول المميز للعملاء ذوي الصلاحيات المرتفعة

يتطلب امتثال CC6.6: المنع الهيكلي لاستدعاءات العملاء ذوي الصلاحيات المرتفعة عبر المستأجرين، وتعريفات صلاحيات العملاء المميزين القابلة للتدقيق، وسجلات التدقيق لكل استدعاء للإجراءات المميزة.

تقسيم سجل التدقيق لكل مستأجر

نمط مفتاح التخزين: audit/{tenant_id}/{year}/{month}/{day}/{agent_id}/{tool_call_id}.json

سياسة دلو S3 لكل مستأجر: بادئة دلو منفصلة مع سياسة موارد منفصلة لكل مستأجر.

سمات موارد OTLP: تضمين tenant_id كسمة مورد في كل سجل تسجيل OpenTelemetry.

مساحة عمل SIEM لكل مستأجر: في عمليات نشر SIEM المشتركة، تكوين فهارس أو مساحات عمل لكل مستأجر.

لتصميم سجل التدقيق الكامل انظر سجل تدقيق عملاء الذكاء الاصطناعي وسجلات الامتثال لكل مستأجر.

الأنماط المضادة: ما يجب تجنبه

النمط المضاد 1: معرف المستأجر في موجه العميل وليس في البنية التحتية

حقن tenant_id في موجه نظام العميل والاعتماد على العميل لتطبيق حدوده الخاصة هو النمط المضاد الأكثر شيوعا وخطورة. يفشل بسبب تجاوز حقن الموجه، وانجراف الهلوسة، وغياب التطبيق على البنية التحتية.

النمط المضاد 2: مخزن متجهات مشترك بدون مرشحات المستأجر

هذا هو متجه التسرب الرئيسي لـ OWASP LLM06. يتطلب الإصلاح حقل بيانات وصفية إلزامي tenant_id في كل عملية كتابة ومرشح بيانات وصفية محقون على مستوى طبقة عميل التخزين في كل استعلام.

النمط المضاد 3: مفتاح API LLM مشترك مع ادعاء المستأجر في الموجه

يفشل هذا النمط المضاد في CC6.1: مشاركة حد المعدل، وفشل إسناد التكلفة، ونطاق الإلغاء، وسجلات تدقيق المزود التي لا يمكن تقسيمها لكل مستأجر.

رأي OpenLegion: العزل من خلال المعمارية لا من خلال الاتفاقية

يطبق OpenLegion عزل المستأجر من خلال ثلاثة آليات على مستوى البنية التحتية لا يستطيع كود العميل تجاوزها: تحديد نطاق خزينة بيانات الاعتماد لكل مشروع، وقوائم التحكم في الوصول لمساحة اسم اللوح الأسود، والرسائل عبر مشاريع العملاء المحظورة بشكل افتراضي.

ضابط العزل	OpenLegion	LangChain / LangGraph	CrewAI	AutoGen	OpenAI Agents SDK
نطاق خزينة بيانات الاعتماد لكل مستأجر	مطبق من البنية التحتية	اتفاقية المطور	اتفاقية المطور	اتفاقية المطور	اتفاقية المطور
قوائم التحكم في الوصول لمساحة اسم اللوح الأسود	مطبق من البنية التحتية	غير متاح	غير متاح	غير متاح	غير متاح
الرسائل عبر مشاريع العملاء محظورة	محظور افتراضيا	غير متاح	غير متاح	غير متاح	غير متاح
سقف الميزانية لكل مستأجر (Zone 2)	مطبق من البنية التحتية	اتفاقية المطور	اتفاقية المطور	اتفاقية المطور	اتفاقية المطور
قسم التدقيق لكل مستأجر (WORM)	مطبق من البنية التحتية	اتفاقية المطور	اتفاقية المطور	اتفاقية المطور	اتفاقية المطور
مساحة اسم Kubernetes + ResourceQuota	مدار من المنصة	مدار ذاتيا	مدار ذاتيا	مدار ذاتيا	مدار ذاتيا

لطبقة البنية التحتية المستضافة انظر منصة عملاء الذكاء الاصطناعي المدارة مع ضمانات عزل المستأجر.

الأسئلة الشائعة

ما هو تعدد المستأجرين في عملاء الذكاء الاصطناعي؟

تعدد المستأجرين في عملاء الذكاء الاصطناعي هو الخاصية المعمارية لمنصة العملاء التي تضمن أن العملاء الذين يخدمون مستأجرين مختلفين لا يستطيعون الوصول إلى بيانات اعتماد بعضهم أو ذاكرتهم أو سياق تنفيذهم أو سجلات تدقيقهم، مطبقة على مستوى البنية التحتية وليس من خلال اتفاقيات المطورين. يختلف عن تعدد المستأجرين التقليدي في تطبيقات الويب في أنه يتطلب ثلاثة أبعاد عزل إضافية: تحديد نطاق خزينة بيانات الاعتماد لكل مستأجر، وتقسيم الذاكرة لكل مستأجر، وتقسيم سجل التدقيق لكل مستأجر.

ما هو OWASP LLM06 وكيف يؤثر على أنظمة العملاء متعددة المستأجرين؟

يصنف OWASP LLM Top 10 v1.1 LLM06 للكشف عن المعلومات الحساسة تسرب البيانات عبر المستأجرين بخطورة عالية: السيناريو الذي يعالج فيه العميل بيانات المستأجر A، ويخزن الوثائق المسترجعة في طبقة ذاكرة مشتركة دون تقسيم للمستأجر، ثم يعرضها في استجابة المستأجر B. لا يتطلب الهجوم أي إدخال خصومي. يتطلب التخفيف تقسيم الذاكرة لكل مستأجر على مستوى طبقة عميل التخزين، وتحديد نطاق بيانات الاعتماد لكل مستأجر، وأقسام سجلات التدقيق لكل مستأجر.

كيف تنطبق CC6.1 و CC6.6 من SOC 2 على منصات العملاء متعددة المستأجرين؟

يتطلب SOC 2 Type II CC6.1 تقييد الوصول المنطقي بناء على تصنيف البيانات؛ في نظام عملاء متعدد المستأجرين، حدود المستأجر هي حدود التصنيف الأساسية. تنطبق CC6.6 على العملاء ذوي صلاحيات الأدوات المرتفعة مثل كتابة قواعد البيانات أو استدعاءات API الخارجية؛ هؤلاء العملاء هم مستخدمون مميزون وظيفيا ويجب منعهم هيكليا من معالجة الطلبات خارج نطاق مستأجرهم المعين. سيتم في الغالب الإشارة إلى مفاتيح API المشتركة المستخدمة عبر المستأجرين كإشكاليات CC6.1.

ما هي ثغرة TTL لرمز JWT في أنظمة العملاء متعددة المستأجرين؟

عادة ما تنتهي صلاحية رموز الوصول JWT المستخدمة لسياق المستأجر في استدعاءات أدوات العميل بعد 3600 ثانية (ساعة واحدة)؛ إذا تم تخزين الرمز الصادر للمستأجر A بشكل غير صحيح، أو مشاركته بسبب خطأ في البنية التحتية، أو التقاطه في سجل تصحيح، يمكن استخدامه لإجراء استدعاءات مصادق عليها منسوبة للمستأجر A طوال مدة TTL دون اكتشاف. يتطلب التخفيف ثلاثة ضوابط مطبقة معا: رموز قصيرة العمر بحد أقصى 300 ثانية TTL، وسجل إلغاء نشط لكل مستأجر، وتدوير الرموز لكل مهمة.

كيف يعمل عزل مساحة اسم Kubernetes للعملاء متعددي المستأجرين؟

يوفر عزل مساحة اسم Kubernetes عزل التنفيذ من خلال أربعة مكونات: مساحة اسم مخصصة لكل مستأجر، و RBAC مع ServiceAccounts لكل مستأجر و RoleBindings محددة النطاق بمساحة الاسم، و NetworkPolicy مع رفض افتراضي وقائمة سماح صريحة للنقاط الخارجية المطلوبة فقط، و ResourceQuota مع حدود حوسبة لكل مساحة اسم. يعالج عزل مساحة الاسم البعد الحوسبي لتعدد المستأجرين ويجب دمجه مع تحديد نطاق بيانات الاعتماد لكل مستأجر وتقسيم الذاكرة.

ما هو النمط المضاد لمخزن المتجهات المشترك في أنظمة العملاء متعددة المستأجرين؟

استخدام مخزن متجهات مشترك بدون مرشحات مستأجر إلزامية لكل استعلام محقونة على مستوى طبقة عميل التخزين هو متجه التسرب الرئيسي لـ OWASP LLM06. يتطلب التطبيق الصحيح حقل بيانات وصفية tenant_id في كل عملية كتابة ومرشح بيانات وصفية محقون على مستوى طبقة عميل مخزن المتجهات في كل استعلام، وليس تمريره كمعامل من كود العميل. لمتطلبات الامتثال الصارمة، تطبق مساحات الأسماء لكل مستأجر أو الفهارس المنفصلة الحدود على مستوى عنوان التخزين.

كيف يطبق OpenLegion عزل المستأجر؟

يطبق OpenLegion عزل المستأجر من خلال ثلاثة آليات على مستوى البنية التحتية: تحديد نطاق خزينة بيانات الاعتماد لكل مشروع (يحل Zone 2 مقابض $CRED{} باستخدام سياق المشروع المصادق عليه من جلسة mesh وليس المعاملات المقدمة من العميل؛ حل بيانات الاعتماد عبر المشاريع مستحيل معماريا)، وقوائم التحكم في الوصول لمساحة اسم اللوح الأسود (العملاء لديهم صلاحيات القراءة والكتابة فقط لبادئة مفتاح مشروعهم، مطبقة من قبل مشرف mesh)، والرسائل عبر مشاريع العملاء المحظورة بشكل افتراضي.

ما هي نماذج المعمارية الثلاثة لتعدد المستأجرين لمنصات العملاء؟

تتمتع النماذج الثلاثة لتعدد المستأجرين بضمانات عزل وملامح تكلفة مختلفة: يمنح نموذج الصومعة (Shared-Nothing) كل مستأجر بنية تحتية مخصصة بالكامل؛ يشارك نموذج التجمع جميع البنية التحتية مع تطبيق العزل على طبقة التطبيق فقط؛ يشارك نموذج الجسر بنية التحتية الحوسبة بينما يطبق العزل على مستوى التحكم من خلال نطاقات خزينة بيانات الاعتماد لكل مستأجر وقوائم التحكم في الوصول لمساحة اسم الذاكرة. نموذج الجسر هو الافتراضي الموصى به لـ B2B SaaS.