المدونة

Security9 min read

الوصول للقراءة فقط: لماذا لا يستطيع بوت الذكاء الاصطناعي لدينا إفساد بياناتك

عندما بدأنا بتقديم بوت الذكاء الاصطناعي لدينا لعملاء المؤسسات، كان السؤال الأول دائماً نفسه: ماذا يحدث إذا قام بتعديل بياناتنا؟ إنه قلق مشروع. لديك نسخة Odoo في الإنتاج تدير أعمالك بالكامل - المبيعات، المخزون، المحاسبة، الموارد البشرية. منح أداة ذكاء اصطناعي وصولاً لهذا النظام يبدو محفوفاً بالمخاطر. لذا صممنا البنية لجعل كتابة أو تحديث أو حذف أي شيء مستحيلاً فيزيائياً على البوت.

الأساس بسيط: يتصل البوت بـ Odoo عبر XML-RPC باستخدام حساب خدمة مخصص يحمل صلاحيات للقراءة فقط بشكل صارم. هذا ليس مفتاحاً برمجياً يمكننا تشغيله بالخطأ. مستخدم Odoo المخصص للبوت لديه صلاحيات وصول مخصصة على مستوى النموذج - صلاحيات قراءة للنماذج التي يوافق عليها العميل، وصفر صلاحيات كتابة/إنشاء/حذف على أي شيء. حتى لو كان في كودنا خطأ يحاول عملية كتابة، فإن طبقة التحكم بالوصول في Odoo نفسها سترفضه بخطأ AccessError.

ذهبنا أبعد من مجرد صلاحيات Odoo. طبقة تكامل البوت لا تحتوي على أي أساليب كتابة على الإطلاق. عميل XML-RPC الذي بنيناه يعرض فقط عمليات search_read و fields_get و read. لا يوجد أي استدعاء execute_kw للإنشاء أو الكتابة أو الحذف في أي مكان في قاعدة الكود. هذا دفاع بالعمق - حتى لو اخترق أحدهم طبقة التطبيق لدينا، فإن الأدوات اللازمة لتعديل البيانات ببساطة غير موجودة في الكود المنشور.

تخزين بيانات الاعتماد كان قراراً حاسماً آخر. تفاصيل اتصال Odoo لكل عميل - الرابط، اسم قاعدة البيانات، مفتاح API - مشفرة أثناء التخزين باستخدام AES-256-GCM. مفاتيح التشفير مخزنة بشكل منفصل عن البيانات المشفرة، متبعين نمط تشفير الظرف. نستخدم متجه تهيئة فريد لكل عملية تشفير، مما يعني أن بيانات اعتماد متطابقة لعميلين تنتج نصاً مشفراً مختلفاً تماماً.

مفاتيح API نفسها تستحق الاهتمام. نستخدم نظام مفاتيح API المدمج في Odoo بدلاً من تخزين كلمات المرور. يمكن إلغاء مفاتيح API فوراً من قبل العميل من لوحة إدارة Odoo الخاصة به دون الحاجة لإشراكنا إطلاقاً. إذا أراد العميل قطع وصول البوت، يحذف مفتاح API ويتوقف فوراً. لا تذكرة، لا انتظار، لا اعتماد علينا.

البيانات أثناء النقل محمية بـ TLS 1.3 لجميع الاتصالات بين خادم البوت لدينا ونسخ Odoo للعملاء. نفرض التحقق من الشهادة - دون تخطي فحوصات SSL حتى في التطوير. خادم البوت نفسه يعمل على VPS معزول من Hetzner بسطح هجوم أدنى: لا منافذ غير ضرورية مفتوحة، مصادقة عبر مفتاح SSH فقط، وتحديثات أمنية تلقائية.

سؤال نتلقاه من فرق تقنية المعلومات هو ما إذا كانت بيانات العميل تُستخدم لتدريب نماذج الذكاء الاصطناعي. الإجابة لا، والبنية تفرض ذلك. عندما يطرح مستخدم سؤالاً على البوت، نستعلم عن Odoo الخاص بالعميل للبيانات ذات الصلة، ونقوم بتنسيقها في prompt، ونرسلها إلى API الخاصة بـ Claude، ونعيد الإجابة. لا نحفظ نتائج الاستعلام بعد انتهاء جلسة المحادثة. لا نجمع بيانات للتدريب. شروط API الخاصة بـ Claude تنص صراحة على أن مدخلات ومخرجات API لا تُستخدم لتدريب النماذج.

سجل المحادثات نفسه مخزن في قاعدة بياناتنا بنفس تشفير AES-256-GCM المستخدم لبيانات الاعتماد. المحادثات مرتبطة بمستخدمي Telegram فرديين وتُحذف تلقائياً بعد 30 يوماً. يمكن للعميل طلب حذف فوري لجميع بيانات محادثاته، ويمكننا تنفيذ ذلك خلال دقائق.

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

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

للعملاء في القطاعات المنظمة، نقدم رداً تفصيلياً على استبيان أمني ويمكن ترتيب تدقيق فريقهم الأمني لقاعدة كودنا. قمنا بهذا ثلاث مرات حتى الآن، وأكد كل تدقيق أن بنية القراءة فقط حقيقية، وليست مجرد تسويق. أحد المدققين لاحظ تحديداً أن غياب أساليب الكتابة في قاعدة الكود غير معتاد - معظم الأنظمة تنفذ أساليب كتابة ثم تحاول حظرها على مستوى الصلاحية، وهو أمر أقل أماناً بطبيعته.

النتيجة العملية لكل هذا هي أن بوتنا عالج أكثر من 10,000 استعلام عبر نسخ Odoo للعملاء بدون أي حوادث بيانات. لا كتابات عرضية، لا تسريبات بيانات، لا وصول غير مصرح. بنية القراءة فقط ليست مجرد ميزة أمنية - إنها المبدأ التصميمي الأساسي للمنتج الذي يجعل اعتماد المؤسسات ممكناً.

هل تريد معرفة المزيد أو مناقشة كيف ينطبق هذا على أعمالك؟