عزل الجهات وتشفير الأسرار في منصة مشتركة

لماذا تحمل منصة المساعدين متعددة المستأجرين مخاطر أكبر من تطبيق SaaS عادي؟

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

والمساعد نفسه يضيف خطرا ثانيا: خطوته التالية يختارها نموذج يقرأ نصوصا غير موثوقة كرسائل البريد والتذاكر وصفحات الويب. وتسمي قائمة OWASP لأهم مخاطر تطبيقات النماذج اللغوية هذه الحالة «الصلاحية المفرطة» (Excessive Agency): إجراءات ضارة يطلقها مخرج نموذج مُتلاعَب به أو خاطئ ببساطة، وأصلها وظائف أكثر من اللازم أو صلاحيات أوسع من اللازم أو استقلالية زائدة.

• قراءة بيانات جهة أخرى: شرط تصفية واحد منسي يعيد جلسات عميل آخر أو تذاكره أو ذاكرته.
• كشف بيانات الاعتماد: أسرار موصلات تعيدها واجهة برمجية، أو تُكتب في السجلات، أو توضع حيث يستطيع النموذج تكرارها.
• ثغرات التفويض على مستوى الكائن: معرّف يؤخذ من الطلب ويُستخدم دون التحقق من مالكه (OWASP API1:2023).
• الصلاحية المفرطة: وكيل تعرّض لحقن تعليمات ويستطيع الإرسال أو الحذف أو الاتصال دون إنسان في الحلقة.
• الفشل الصامت: لا يوجد سجل تدقيق يبيّن أي هوية أطلقت أي إجراء.

أين يجب فرض عزل البيانات بين الجهات؟

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

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

كيف تفرض Botify نطاق الجهة في طبقة البيانات؟

تستخدم بوتيفاي جداول مشتركة مع حارس مدمج في عميل قاعدة البيانات Prisma. تتيح امتدادات الاستعلام في Prisma اعتراض كل عملية على كل نموذج بيانات، وتستخدم Botify ذلك لرفض أي قراءة أو تحديث أو حذف أو عدّ أو تجميع على بيانات تخص جهة ما إذا لم يقيّد شرطُ التصفية الجهةَ، ورفض أي إنشاء لا يحدد الجهة في بياناته. الرفض خطأ صريح في موضع الاستدعاء، فيظهر الخلل أثناء التطوير والاختبار لا في بيانات عميل.

يبحث الفحص عن الجهة في أي مكان داخل شجرة الشروط لا في المستوى الأعلى فقط، لأن الاستعلامات الحقيقية تحصر الجهة داخل فروع AND وOR أو في مفاتيح فريدة مركبة أو في شروط العلاقات، والحارس الذي يقبل شكلا واحدا سيدفع المطورين إلى تعطيله. والعميل غير المحمي متاح فقط كخيار صريح للترحيلات وتهيئة البيانات ومهام المنصة. كما تُخزَّن الاتصالات وبيانات الاعتماد لكل جهة على حدة، فتخضع للحارس نفسه.

الحارس في طبقة التطبيق لا يرى إلا الاستعلامات التي تمر عبر العميل. أما استعلامات SQL الخام وأدوات التقارير والوصول المباشر إلى قاعدة البيانات فتحتاج إلى ضوابطها الخاصة، وهنا تكمّله آليات قاعدة البيانات مثل أمان مستوى الصفوف في PostgreSQL والأدوار المقيدة.

كيف يجب أن تشفّر المنصة بيانات اعتماد الموصلات؟

استخدم تشفيرا موثّقا. نمط Galois/Counter Mode مع AES، المحدد في معيار NIST SP 800-38D، يشفّر السر وينتج وسم مصادقة، فيُكتشف أي عبث بالنص المشفر عند فك التشفير بدلا من إنتاج بيانات فاسدة قد يثق بها جزء من الشيفرة. ويتطلب GCM قيمة nonce فريدة لكل عملية تشفير بالمفتاح نفسه، والنهج المعتاد هو توليد قيمة عشوائية جديدة بطول 96 بت لكل عملية.

يقبل GCM أيضا «بيانات مصادَقة إضافية» (AAD): سياق لا يُشفَّر لكنه يدخل في وسم المصادقة. تشفّر Botify كل بيانات اعتماد الموصلات بـ AES-256-GCM وتجعل الـ AAD مكوّنا من الجهة المالكة ومعرّف بيانات الاعتماد ونوعها. فإذا نسخ أحدهم بيانات اعتماد مشفرة إلى صف جهة أخرى، أو غيّر نوعها، يفشل التحقق من الوسم ويفشل فك التشفير. وقبل فك التشفير يتحقق المستودع كذلك من أن الـ AAD المخزّن يشير إلى الصف نفسه الذي قُرئ منه.

• تسجيل الخوارزمية في الغلاف المشفر، ليمكن تغييرها لاحقا دون تخمين.
• تسجيل إصدار المفتاح في الغلاف، ليُختار المفتاح الصحيح عند القراءة.
• قيمة nonce عشوائية بطول 96 بت لكل عملية تشفير، تُخزَّن بجانب النص المشفر.
• تخزين وسم المصادقة والتحقق منه عند كل فك تشفير.
• ربط النص المشفر بالجهة وبيانات الاعتماد ونوعها عبر الـ AAD.

كيف تدوّر مفاتيح التشفير دون توقف الخدمة؟

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

المفاتيح ذات الإصدارات تزيل هذا الخطر. تحتفظ حلقة مفاتيح Botify بعدة إصدارات أحدها نشط؛ تُشفَّر الأسرار الجديدة بالإصدار النشط، وتبقى الإصدارات الأقدم متاحة فقط لقراءة ما شفّرته. ثم تعيد حلقة عمل في الخلفية تشفير الأغلفة القديمة بالمفتاح النشط على دفعات صغيرة لكل جهة. ولا تنجح إعادة الكتابة إلا إذا كان الصف ما زال يحمل إصدار المفتاح الذي قُرئ به، فلا يُكتب فوق تدوير متزامن لبيانات الاعتماد. وعندما لا يبقى أي غلاف يستخدم إصدارا قديما يمكن حذف ذلك المفتاح.

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

لماذا يجب ألّا تُعاد الأسرار أبدا عبر الواجهة البرمجية؟

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

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

ماذا يعني مبدأ أقل صلاحية لأدوات المساعدون؟

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

تصنّف Botify كل أداة بمستوى خطر (قراءة، أو كتابة، أو حذف، أو إرسال خارجي) وبنمط موافقة. أدوات القراءة كالبحث في Gmail أو تشغيل بحث في Splunk تعمل مباشرة. أما إرسال بريد أو إنشاء بلاغ في ServiceNow أو إجراء مكالمة هاتفية فينتظر دائما موافقة بشرية. وتُترك كثير من عمليات الكتابة، كأرشفة البريد أو تصنيفه، لسياسة الجهة. ويُتحقق من الهوية والأدوار قبل تشغيل أي أداة، وتنضم خوادم MCP التي تسجلها الجهة إلى الكتالوج نفسه تحت السياسات نفسها.

ماذا يجب أن يسجّل سجل التدقيق في منصة ذكاء اصطناعي؟

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

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