بنية أمان Odoo 19: الجمع الصحيح بين جدار الحماية و2FA والصلاحيات وWeb RBL

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

يبيّن هذا المقال كيف تؤمّن Odoo 19 على الوجه الصحيح — لا بإجراء واحد، بل بـعدة طبقات يكمّل بعضها بعضًا: جدار الحماية والوكيل العكسي (Reverse Proxy)، ووحدتنا مفتوحة المصدر Web RBL، والمصادقة الثنائية، وسياسة كلمات المرور، والصلاحيات — وأي محاولات هجوم تصدّها كل واحدة منها فعليًا. وفي الختام دليل خطوة بخطوة يمكن من خلاله تطبيق ذلك على أي تثبيت Odoo خاص بك.

الدفاع المتعمق: لماذا لا يكفي إجراء واحد أبدًا

كل إجراء أمني بمفرده فيه ثغرة. فجدار الحماية لا يرى ما يحدث داخل نموذج تسجيل الدخول في Odoo. وكلمة المرور القوية لا تحمي إذا سُرقت أصلًا في مكان آخر. وهيكل الصلاحيات لا ينفع أمام مهاجم لم يسجّل دخوله بعد. والمبدأ الذي يسدّ هذه الثغرات يُسمّى الدفاع المتعمق (defense in depth): عدة طبقات مستقلة، يمكن تجاوز كل واحدة منها على حدة — لكن لا يمكن تجاوزها كلها معًا.

لدينا أربع طبقات، ولكل منها مهمة مختلفة:

• جدار الحماية / الوكيل العكسي — يُبعد كل ما هو ضار بوضوح قبل أن يصل إلى الخادم أصلًا
• Web RBL — يربط الطرفين: يتعلم Odoo من سجل التطبيق الخاص به ما لا يستطيع جدار الحماية رؤيته أصلًا، ثم يعيده إليه
• Odoo نفسه — المصادقة الثنائية، وسياسة كلمات المرور، والصلاحيات، وإدارة الجلسات
• قاعدة البيانات & التشغيل — النسخ الاحتياطي، وحماية الوصول إلى الإدارة، وإبقاء الأسرار خارج أي سجل

وتستعرض الأقسام التالية كل طبقة على حدة.

الطبقة 1: جدار الحماية والوكيل العكسي

جدار الحماية هو أول جهة ترى الطلب، والوحيدة القادرة على إبعاد المهاجم عن كل خدمة على الخادم — لا عن الموقع فحسب، بل أيضًا عن خادم البريد والوصول عبر VPN وواجهة الإدارة الخاصة. وما يُفعَّل هنا عمليًا يعتمد على الشركة المصنِّعة، لكن الأشكال الأساسية هي نفسها في OPNsense وpfSense وHAProxy وFortiGate وSophos وCheck Point:

قوائم RBL: الطريقة القياسية لتوزيع السمعة

تعني RBL اختصار Real-time Blackhole List، وهو مصطلح من عالم البريد: عنوان واحد في كل سطر، يمكن جلبه عبر HTTP، ويُعاد تحميله بانتظام. ويستطيع عمليًا كل جدار حماية قراءة قائمة كهذه وبناء قواعد منها — OPNsense وpfSense باسم URL Table Alias، وHAProxy كملف ACL، وFortiGate باسم External Block List، وPalo Alto باسم External Dynamic List، وCisco وSophos وJuniper وMikroTik بأسماء خاصة للمبدأ نفسه.

وهنا بالضبط تدخل وحدتنا الخاصة — وهنا بالضبط تبدأ الطبقة الثانية.

الطبقة 2: Web RBL — الجسر بين التطبيق وجدار الحماية

جدار الحماية يرى الحزم، لا منطق التطبيق. فهو لا يعلم أن طلبًا إلى /xmlrpc/2/common هو محاولة تسجيل دخول، ولا أن عشرين مسارًا مختلفًا في أربع عشرة ثانية يعني ماسحًا، ولا أن عنوانًا خمّن للتو كلمة مرور بنجاح. كل ذلك لا يعرفه إلا Odoo نفسه. Web RBL، وحدتنا الخاصة مفتوحة المصدر (AGPL-3)، تجعل هذه المعرفة قابلة للاستخدام — لـ Odoo نفسه، وكذلك، حين تُوزَّع كقائمة RBL، لجدار الحماية الذي يسبقه.

قوائم التهديدات تُطابَق باستمرار، ولكل منها مستواها الخاص.

ملخص موجز لما هو موصوف بالتفصيل في المقال السابق:

• التعرّف على الأنماط في المسارات: ملفات .env ومجلدات .git وملفات الإعدادات ومسابير WordPress وPHP واجتياز المسارات وتنفيذ الأوامر عبر واجهات الذكاء الاصطناعي الجديدة
• الدفاع عن تسجيل الدخول الذي يحسب عبر إعادات التشغيل — على خلاف عدّاد Odoo نفسه الذي يعيش في الذاكرة العاملة
• تقييم كل عنوان من 0 إلى 100، مع تعليل بنص واضح
• الإعدادات الخاطئة (QNAP وAutodiscover وSynology) يتم التعرّف عليها ولا تُحظر أبدًا، لأن الحظر لا يعالج العطل بل يخفيه فقط
• قوائم تهديدات خارجية مثل Spamhaus وFireHOL وعُقد خروج Tor، تُطابَق باستمرار
• قائمة السماح للعناوين التي ينبغي ألا تُحظر أبدًا

وفي هذا المقال خاصيتان بالغتا الأهمية، لأنهما ترتبطان مباشرة بجدار الحماية وبتسجيل الدخول.

القائمة الراكدة قائمة يمكن الوثوق بها

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

تسجيل الدخول هو المكان الذي لا يراه جدار الحماية

يستطيع جدار الحماية حظر عنوان ما. لكنه لا يستطيع أن يعرف هل نجح تسجيل الدخول، فضلًا عن أن يعرف هل جاء من عنوان كان قبل لحظات يبحث عن بيانات دخول. أما Web RBL فيعرف: فدرجة تقييم تتجاوز حدًّا قابلًا للضبط تمنع تسجيل الدخول كليًا، وتسجيل الدخول الناجح من عنوان مشبوه يُبلَّغ عنه — وهذا هو الحلقة الواصلة بالطبقة التالية.

الطبقة 3: تأمين Odoo نفسه

المصادقة الثنائية: سرٌّ ثانٍ لا يمكن إعادة استخدامه

أكبر مشكلة في كلمات المرور ليست جودتها بل إعادة استخدامها. فكلمة مرور سُرقت من خدمة أخرى تعمل لدينا بالقدر نفسه ما دامت هي ذاتها. وتواجه المصادقة الثنائية (2FA، وتسمى أيضًا TOTP) ذلك بسرٍّ ثانٍ: رمز من ستة أرقام يتغير كل ثلاثين ثانية، ويُحسب من سرٍّ لا يعرفه سوى هاتفك الذكي. وهكذا لا تعود كلمة المرور المسروقة وحدها كافية.

يأتي Odoo 19 Community بهذه الميزة مدمجة — كوحدة قابلة للتثبيت باسم Two-Factor Authentication (TOTP)، مع خيار احتياطي عبر البريد الإلكتروني. ويُعدّها كل مستخدم لنفسه عبر رمز QR، باستخدام أي تطبيق مصادقة (Authenticator) شائع:

الإعداد: امسح رمز QR، وأكّد الرمز المكوَّن من ستة أرقام مرة واحدة، وانتهى الأمر.

لكن هذا وحده لا يفيد إلا من يُعدّه لنفسه — والتجربة تُظهر أنهم يبقون أقلية دون إلزام. ولذلك يوفّر Odoo سياسة إلزام: إما للموظفين فقط (المستخدمين الداخليين) أو للجميع، بمن فيهم مستخدمو البوابة. وبدون سرٍّ ثانٍ مُعَدّ، لا يمرّ أحد من نموذج تسجيل الدخول دون أن يؤكّد على الأقل برمز يصله بالبريد الإلكتروني.

سياسة كلمات المرور: الحد الأدنى للطول ليس أمرًا بديهيًا

دون وحدة إضافية لا يعتمد Odoo Community على أي حد أدنى لطول كلمات المرور — فيمكن للمستخدم تعيين كلمة مرور من ثلاثة أحرف إن لم يمنعه أحد. ووحدة Password Policy الخاصة تسدّ هذه الثغرة بالتحديد: حدّ أدنى للطول يُفرَض من جهة الخادم، لا مجرد اقتراح في المتصفح. ومن يريد أكثر — مدة صلاحية إلزامية، أو سجلًا يمنع إعادة الاستخدام — فيحتاج لذلك وحدة من OCA أو من طرف ثالث؛ فنسخة Community مقتصدة عن قصد.

الصلاحيات: لا يصل إلا من يحتاج

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

يتحمّل مبدآن معظم العبء:

ويمكن التحقق من الأمرين في الواجهة نفسها التي تُعدّ فيها المصادقة الثنائية:

نظرة عامة واحدة، وأربع أدوات: كلمة المرور، والعامل الثاني، ومفاتيح API، والأجهزة المسجّل دخولها.

الجلسات والأجهزة: من مسجّل دخوله الآن

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

الطبقة 4: قاعدة البيانات والتشغيل

الطبقة الرابعة هي الأقل ظهورًا وفي الوقت نفسه الأقل قابلية للتسامح، لأن الخطأ هنا قد يُبطل كل ما بُني قبلها.

• نسخ احتياطية منتظمة ومفحوصة، تُحفظ بمعزل عن الخادم نفسه. فالنسخة الاحتياطية التي لم تُستعَد قط تخمين، لا نسخة احتياطية.
• لا مكان للأسرار في أي ملف سجل. كلمات المرور ومفاتيح API وبيانات التراخيص — من يكتب إضافات خاصة به ينبغي أن يعاملها كما يعامل كلمة المرور الرئيسية نفسها: لا تُدوَّن في أي مكان، حتى «لأغراض تصحيح الأخطاء فقط».
• أبقِ الوحدات محدَّثة، ولا سيما وحدات الأطراف الثالثة. فالوحدات الإضافية الحرة (OCA وغيرها) تتأخر بطبيعتها عن إصدارات Odoo الجديدة؛ ويستحق الأمر قبل كل تثبيت نظرة على ما يأتي معها تلقائيًا من تبعيات.

مسار تسجيل الدخول في مجمله

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

خمسة مواضع يمكن أن ينتهي فيها طلب ضار قبل أن يبلغ هدفه الفعلي — وموضع واحد فقط يجتازها فيه المستخدم المخوَّل كلها.

سيناريوهات الهجوم وطرق التصدي لها

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

خطوة بخطوة: تأمين تثبيت Odoo الخاص بك

الترتيب التالي هو الذي كنا سنتبعه بأنفسنا — من الأكبر تأثيرًا إلى أدق الإعدادات.

1. إلزام المصادقة الثنائية

1. إن لم تكن مثبّتة بعد: افتح التطبيقات (Apps)، وابحث عن «Two-Factor Authentication» وثبّتها (وعند تعدد المواقع يُنصح أيضًا بـ «Two-Factor Authentication by Mail» كخيار احتياطي).
2. افتح الإعدادات ← الإعدادات العامة ← الصلاحيات.
3. فعّل «إلزام المصادقة الثنائية».
4. اختر السياسة: «الموظفون فقط» للمستخدمين الداخليين، أو «جميع المستخدمين» إذا أردت أن تشمل أيضًا مستخدمي البوابة (العملاء الذين لديهم وصول).
5. احفظ. ومنذ محاولة تسجيل الدخول التالية يطلب Odoo من كل مستخدم لم يُعدّ سرًّا ثانيًا رمز البريد الإلكتروني على الأقل، إلى أن يُعدّ تطبيق المصادقة.

2. تحديد حد أدنى لطول كلمات المرور

1. افتح التطبيقات (Apps)، وابحث عن «Password Policy» وثبّتها.
2. افتح الإعدادات ← الإعدادات العامة ← الصلاحيات.
3. اضبط «الحد الأدنى لطول كلمة المرور» — اثنا عشر حرفًا قيمة ابتدائية معقولة.
4. احفظ. تسري القاعدة من الآن على كل تعيين أو تغيير جديد لكلمة المرور، ولا تسري بأثر رجعي على كلمات المرور الحالية.

3. مراجعة الصلاحيات

1. افتح الإعدادات ← المستخدمون & الشركات ← المستخدمون.
2. افتح كل مستخدم على حدة وراجع التبويب الخاص بحقوق الوصول لكل تطبيق: هل يحتاج هذا الشخص فعلًا إلى «مدير» أو «مسؤول»، أم يكفيه «مستخدم»؟
3. تحقق بوجه خاص: من لديه حق الوصول إلى «الإعدادات» نفسها؟ ينبغي أن تكون مجموعة صغيرة جدًا.
4. لكل ربط خارجي (المحاسبة، سكربتات خاصة، تسجيل الأوقات) أنشئ في تبويب «أمان الحساب» للمستخدم التقني المعني مفتاح API خاصًا به، بدلًا من تسليم كلمة مرور المستخدم.

4. تثبيت Web RBL ومراقبته قبل التفعيل الفعلي

1. نزّل الوحدة من github.com/Alex0176/odoo-web-rbl وضعها في مسار الإضافات (Addon) وثبّتها.
2. راقب بضعة أيام: تُظهر القائمة Web RBL ← التحليل الأنماط التي تعمل فعليًا.
3. وبعد ذلك فقط فعّل web_rbl.sperren_aktiv (الإعدادات ← التقني ← معاملات النظام) — ومن هنا تُرفض المسابير المكتشفة فعليًا.
4. اربط قائمة الحظر في جدار الحماية كقائمة RBL عبر العنوان المحمي برمز Token المذكور في الوحدة (في OPNsense/pfSense باسم URL Table Alias، وفي HAProxy كملف ACL).

5. تأمين جدار الحماية نفسه

1. اجعل واجهة إدارة جدار الحماية متاحة من الشبكة الداخلية فقط، ولا تتيحها أبدًا عبر العنوان العام نفسه الذي يُتاح به الموقع.
2. فعّل تحديثات الأمان التلقائية لبرنامج جدار الحماية، إن كانت الشركة المصنِّعة تقدّمها.
3. افحص إعداد TLS: إصدارات البروتوكول الحديثة فقط، وعطّل طرق التشفير القديمة.
4. إن كان ذلك متاحًا: اربط قائمة سمعة معروفة (مثل Spamhaus DROP) مباشرة على جدار الحماية — بمعزل عن Web RBL، لأن جدار الحماية يرى بذلك أيضًا الحركة نحو خدمات لا يصل إليها Odoo أبدًا.

6. إغلاق إدارة قاعدة البيانات

1. تحقق مما إذا كان /web/database/manager متاحًا من الخارج — وإن كان كذلك، فاضبط list_db = False في إعدادات Odoo أو احظر المسار على مستوى جدار الحماية.
2. اضبط كلمة المرور الرئيسية لإدارة قاعدة البيانات طويلة وعشوائية، ولا تدوّنها في أي موضع يمكن لأي شخص آخر قراءته.

7. فحص النسخ الاحتياطي، لا مجرد إعداده

1. أعدّ نسخًا احتياطيًا تلقائيًا ومنتظمًا، يُحفظ بمعزل عن خادم Odoo.
2. استعد النسخة فعليًا مرة واحدة على الأقل وتحقق من نجاح الاستعادة — فالنسخة الاحتياطية غير المفحوصة تخمين.

لا تغني أي من هذه الخطوات عن غيرها. فمن طبّق واحدة فقط منها فقد قوّى بابًا وترك كل الأبواب الأخرى مفتوحة — أما من طبّق السبع كلها فلديه دفاع يصمد حتى عند فشل طبقة واحدة.

ما لا تغني عنه هذه البنية

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

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

هل تكفي كلمة مرور قوية لتأمين Odoo 19؟

لا. فكلمة المرور قد تُسرق في مكان آخر، بصرف النظر تمامًا عن جودتها، وتعمل عندئذ لدى كل خدمة تقبل كلمة المرور نفسها. ولا يتحقق تأمين يصمد حتى بعد سرقة كلمة مرور إلا بالجمع بين المصادقة الثنائية وجدار حماية أمامها وهيكل صلاحيات سليم.

كيف أفعّل المصادقة الثنائية في Odoo 19؟

ثبّت الوحدة «Two-Factor Authentication (TOTP)» من إدارة التطبيقات، ثم فعّل الإلزام ضمن الإعدادات ← الإعدادات العامة ← الصلاحيات واختر بين «الموظفون فقط» و«جميع المستخدمين». بعد ذلك يُعدّ كل مستخدم عامله الثاني الخاص عبر رمز QR.

ما قائمة RBL، ولماذا يحتاج إليها Odoo؟

RBL (Real-time Blackhole List) قائمة عناوين يمكن جلبها عبر HTTP ويستطيع عمليًا كل جدار حماية قراءتها. ولا يأتي Odoo نفسه بقائمة كهذه — ووحدتنا Web RBL تسدّ هذه الثغرة، إذ تتعرف على حركة الهجوم من سجل التطبيق الخاص بها وتعيدها كقائمة RBL إلى جدار الحماية الذي يسبقها.

هل Odoo 19 Community مؤمَّن بما يكفي دون وحدات إضافية؟

ليس بالكامل. فدون وحدة Password Policy لا يوجد حد أدنى لطول كلمات المرور، ودون Two-Factor Authentication لا يوجد عامل ثانٍ، ودون وحدة مثل Web RBL لا يتعرف Odoo لا على محاولات الاستكشاف ولا على محاولات تسجيل الدخول المتكررة عبر إعادة تشغيل. ويمكن إضافة الأربعة جميعها مجانًا.

التوافر

يتوفر Web RBL علنًا بموجب ترخيص AGPL-3، ويعمل لدينا في بيئة الإنتاج على خمسة مواقع:

github.com/Alex0176/odoo-web-rbl

الوصف الوظيفي الكامل بجميع الأنماط والتقييم وقوائم التهديدات موجود في المقال السابق: Web RBL – قائمة حظر لحركة الهجوم على مواقعنا الخاصة.

يسعدنا تلقي الأسئلة والملاحظات وتقارير الأخطاء — ويفضَّل أن تكون على هيئة Issue في GitHub.