الفصل 10 — تصميم بنى LLM آمنة

المقال العاشر من الجولة الفصلية لـ LLM Primer VII: أمان الذكاء الاصطناعي. الفصل الذي يُعامل البنية اختصاصَ الأمن الأوّل — لأن أأمن تكوين لمكوّن احتمالي هو ما يُقيَّد نصفُ قطر انفجاره بالبنية، لا بضبط النفس للمكوّن.

لماذا يوجد هذا الفصل

سمّت فصول الأقسام الأولى إلى الثالث التهديدات والدفاعات جانبَ النموذج. يمشي الفصل 10 على البنية حول النموذج — حدود العزل، وطبقات التحقق، ومحرّكات السياسات، وعقود API، ومبادئ الثقة الصفرية التي تمنح النظام خصائصه البنيوية. الفرضية لم تتغيّر عن هندسة الأمن السابقة: افترض الاختراق، واحتوِ الضرر، واجعل الاختراق مقروءاً. الجديد أن المكوّن المطلوب احتواؤه هو مُنسِّق مقود باللغة الطبيعية يمكن أن تصل تعليماته عبر أيّ قناة مُدخل. تنتقل أنماط البنية من العصور السابقة؛ خصوصياتُ تطبيقها على LLM هي حيث يعمل هذا الفصل عمله.

10.1 العزل يحدّ نصف قطر الانفجار

حدّ العزل درزٌ متعمَّد لا يمكن لمكوّن على أحد جانبيه التأثير مباشرة على مكوّن على الآخر دون المرور عبر واجهة مضبوطة. السبب الأمني للعزل أن ضرر الاختراق مُقيَّد بما يمكن للمكوّن المُخترَق بلوغه عبر واجهاته المشروعة. لأنظمة LLM أهمّ سؤال عزل بين النموذج وكل ما يستطيع النظام الوصول إليه. نموذجٌ يعمل في عملية بوصولٍ غير مُقيَّد لنظام الملفات، ووصولٍ غير مُقيَّد للشبكة، وأداة تنفيذ shell بلا قائمة سماح، له نصف قطر انفجار كبير. نموذجٌ عمليتُه في صندوق رمليّ بمجموعة syscall معرَّفة، ووصولُ شبكته عبر وكيل خروج بقوائم سماح على مستوى النطاق، وأدواتُه تُستدعى عبر رموز قدرة تُصدرها الشيفرة المحيطة لكل طلب، له نصف قطر أصغر بكثير. يمتدّ النمط إلى تنفيذ الشيفرة — أدوات صندوق رمليّ مثل التي تستخدمها OpenAI وAnthropic لبيئات مُفسّر الشيفرة تُشغّل الشيفرة المُولَّدة في VMs عابرة من gVisor أو Firecracker — وإلى التصفّح، حيث تعمل متصفّحات headless في فضاءات شبكة معزولة بلا وصول إلى نقاط النهاية الداخلية. العزل قرار تصميم يُتَّخذ قبل أيّ هجوم محدّد، وهو أرخص استثمار أمني لكل وحدة اختزال نصف قطر انفجار يعرضه الميدان.

10.2 التحقق طبقي، والسياسة مُعلَنة

نقطة تحقق واحدة نقطة فشل واحدة. تُركّب نقاط نهاية LLM الإنتاجية عادةً خمس طبقات بين طلب العميل والاستجابة. المصادقة تتحقّق من اعتماد الحساب. التحقق من الطلب يفحص الطلب ضدّ مُخطَّط API — الأنواع، والمدى، والأطوال، ومجموعات الأحرف. تقييم السياسة يسأل إن كان الحساب الموثّق والطلب المُتحقّق منه وحالة النظام الحالية يُسمحون بهذا الفعل. استدعاء النموذج يعمل بتوجيه النظام، ومُدخل المستخدم المُتحقّق منه، وقائمة الأدوات المُنطاقة بما تسمح به السياسة، وقيود المُخرج. تصفية المُخرج تفحص الاستجابة من محتوى ينبغي عدم إرجاعه — أسرار مُسرَّبة، ومحتوى محظور، واستدعاءات أدوات غير آمنة — قبل إرسالها. ينمو منطق السياسة مع الزمن، وإن تفرّق عبر شيفرة التطبيق، يُصبح اتّحاد شروط كثيرة يصعب فحصها أو اختبارها أو تطويرها. التقى الميدان على فصل السياسة عن الشيفرة. Open Policy Agent (OPA)، مشروع CNCF، يُقيّم سياسات مكتوبة بـ Rego. AWS Cedar، أُصدر في 2023، لغة تخويل مُركَّزة بخصائص تحقق شكلية. كلاهما جاهز للإنتاج؛ الاختيار عادةً محاذاة تنظيمية. تُصبح السياسات آثاراً مُصدَّرة وقابلة للمراجعة، وسياسة الأمن الفعّالة للنظام دائماً قابلة للقراءة في مكان واحد.

10.3 الثقة الصفرية مُطبَّقة على استدعاءات النموذج

API هو العقد بين نظام LLM وطالبيه. تصميم API الآمن اختصاصُ تشكيل العقد لتصمد ثوابته أمام اتّصال طالبين خصوميين. المُخطَّطات الصريحة للمُدخل — أنواع صارمة، ومدى، وقوائم سماح مُعدَّدة — كلفتها قليلة وتحدّ من الثقة الضمنية التي يضعها API في الطالب. استجابات الخطأ المُهيكلة التي لا تُسرّب حالة داخلية تتجنّب جمع الاستخبارات الذي تُتيحه الأخطاء المُبهمة. مفاتيح idempotency، ومعرّفات الطلبات، والإصدار يمنحون النظام رصداً لسلوك الطالب دون طلب حالة إضافية. نموذج الثقة الصفرية، المُعلَن في ورقة Google BeyondCorp 2014 والمُشكَّل رسمياً في NIST SP 800-207 في 2020، يمدّ المبدأ: لا يُوثَق طالب بحكم موقعه الشبكي. كل طلب يُصادَق، ويُخوَّل ضدّ سياسة صريحة، ويُقيَّم ضدّ الجهاز والسياق، ويُسجَّل. مُطبَّقاً على أنظمة LLM يُصبح استدعاء النموذج نفسه حساباً — طلب من النموذج إلى أداة لاحقة يُصادَق حساباً باسم النموذج، يحمل هوية الإنسان الذي يعمل النموذج بالنيابة عنه، ويُخوَّل ضدّ سياسة تعرف كلا الهويتين. رموز القدرة بنطاق ضيّق وTTL قصير هي ما يجعل ذلك تركيبياً. النتيجة أن توجيهاً مُخترَقاً لا يستطيع التصعيد إلى اختراق كامل للنظام لأن قدرات النموذج نفسها مُقيَّدة برموز أصدرتها الشيفرة المحيطة لطلب محدّد.

ما يُمهّد له الفصل 10

البنية بلا رؤية تفشل بلا رؤية. يفحص الفصل 11 طبقة الرصد التي تُحوّل الدفاعات البنيوية إلى نظام يمكن تشغيله — ماذا يُسجَّل حين يكون LLM في الحلقة، وكيف تُهيكَل التغذية عن بُعد لتخدم التنبيه في الوقت الحقيقي، والتحقيق بعد الوقوع، وتخطيط السعة، والامتثال، والتقييم المستمرّ من السجلات نفسها. تُوفّر أعراف OpenTelemetry GenAI الدلالية، التي بدأت توحيد spans وسمات LLM المخصّصة في 2024، الأساس المستقل عن المورّد. تجلس التنفيذات المحدّدة — Langfuse، وHelicone، وArize Phoenix، وDatadog LLM Observability — فوقها بمقايضات مختلفة. يعالج الفصل 12 بُعد الهوية والوصول — OAuth، وmTLS، وRBAC مقابل ABAC، وعزل تعدّد المستأجرين، وحدود المعدّل، وضوابط الحوكمة المؤسّسية التي تجعل النظام قابلاً للاستخدام في بيئات منظّمة.

التالي — الفصل 11: الرصد والتسجيل والاستجابة للحوادث. ماذا يُسجَّل بأعراف OpenTelemetry GenAI، وكيف تُكتشف أنماط الإساءة، وكيف يُدار الاستجابة للحوادث بشكل NIST لنظام إخفاقاته احتمالية.