معماری امنیتی Odoo 19: ترکیب درست فایروال، 2FA، مجوزها و Web RBL

Odoo روی پنج وب‌سایت ما از اینترنت آزاد در دسترس است، و این یک استثنا نیست، بلکه حالت عادی است: هر کس یک پیشنهاد، یک فروشگاه یا یک ورود مشتری را راه‌اندازی کند، یک سرور عمومی دارد. یک گذرواژهٔ آسیب‌پذیر، یک فایل پیکربندی فراموش‌شده یا یک مجوز بیش‌ازحد گشاده‌دستانه کافی است تا از یک سرور عمومی، یک سرور بازِ همگان بسازد.

این مطلب نشان می‌دهد چگونه می‌توانید Odoo 19 را درست ایمن کنید — نه با یک اقدام تنها، بلکه با چند لایه که یکدیگر را تکمیل می‌کنند: فایروال و Reverse Proxy، ماژول متن‌باز ما Web RBL، احراز هویت دومرحله‌ای، سیاست گذرواژه و مجوزها — و اینکه هر یک از آن‌ها واقعاً کدام تلاش‌های حمله را می‌گیرد. در پایان یک راهنمای گام‌به‌گام آمده است که با آن می‌توان هر نصب Odoo شخصی را هم‌تراز کرد.

دفاع در عمق: چرا یک اقدام هرگز کافی نیست

هر اقدام امنیتی منفرد یک شکاف دارد. فایروال نمی‌بیند در فرم ورود Odoo چه می‌گذرد. یک گذرواژهٔ قوی اگر جای دیگری پیش‌تر دزدیده شده باشد، محافظت نمی‌کند. ساختار مجوزها در برابر مهاجمی که هنوز اصلاً وارد نشده، کمکی نمی‌کند. اصلی که این شکاف‌ها را می‌بندد دفاع در عمق (defense in depth) نام دارد: چند لایهٔ مستقل که هر کدام به‌تنهایی دور زدنی می‌بود — اما همه با هم نه.

نزد ما چهار لایه وجود دارد، هر کدام با وظیفه‌ای متفاوت:

• فایروال / Reverse Proxy — آنچه آشکارا مخرب است را پیش از آنکه اصلاً به سرور برسد دور نگه می‌دارد
• Web RBL — دو سو را به هم وصل می‌کند: Odoo از گزارش برنامهٔ خودش چیزی می‌آموزد که فایروال اصلاً نمی‌تواند ببیند، و آن را به فایروال بازمی‌گرداند
• خودِ Odoo — احراز هویت دومرحله‌ای، سیاست گذرواژه، مجوزها، مدیریت نشست
• پایگاه داده & عملیات — پشتیبان‌گیری، حفاظت از دسترسی به مدیریت، رازها بیرون از هر گزارشی

بخش‌های زیر هر لایه را جداگانه مرور می‌کنند.

لایهٔ 1: فایروال و Reverse Proxy

فایروال نخستین مرجعی است که یک درخواست را می‌بیند، و تنها مرجعی که می‌تواند مهاجم را از هر سرویس روی سرور دور نگه دارد — نه فقط از وب‌سایت، بلکه از سرور ایمیل، از دسترسی 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، Path Traversal، اجرای فرمان از طریق رابط‌های تازهٔ هوش مصنوعی
• دفاع در برابر ورود که فراتر از راه‌اندازی‌های مجدد می‌شمارد — برخلاف شمارندهٔ خودِ Odoo که در حافظهٔ کاری زندگی می‌کند
• امتیازدهی به هر نشانی از 0 تا 100، با دلیل به زبان ساده
• پیکربندی‌های نادرست (QNAP، Autodiscover، Synology) شناسایی می‌شوند و هرگز مسدود نمی‌شوند، چون مسدودسازی عیب را برطرف نمی‌کند، فقط پنهانش می‌کند
• فهرست‌های تهدید بیگانه مانند Spamhaus، FireHOL و گره‌های خروجی Tor، پیوسته تطبیق داده می‌شوند
• فهرست مجاز برای نشانی‌هایی که نباید هرگز مسدود شوند

برای این نوشته دو ویژگی به‌ویژه مهم‌اند، چون مستقیماً با فایروال و با ورود مرتبط‌اند.

فهرست کُند، فهرستی است که می‌توان به آن اعتماد کرد

فهرست مجاز — نشانی‌هایی که هرگز مسدود نمی‌شوند، مثلاً اتصال‌های شعبهٔ خودمان — معمولاً به‌ندرت تغییر می‌کند. درست همین ارزش آن است، نه کمبودش: وقتی یک فهرست آرام طی روزها به‌سختی حرکت می‌کند، هر تغییر نادر بی‌درنگ به چشم می‌آید. به‌روزرسانی خودکار روزانه نه به این دلیل وجود دارد که چیز زیادی تغییر می‌کند، بلکه برای این است که تغییر نادر لازم نباشد با دست دنبال شود — و درست همین نقطه‌ای است که آدم فراموشش می‌کند. یکی از پیکربندی‌های نادرست خودِ ما در ماه گذشته دقیقاً همین‌طور آشکار شد: نه با رخدادهای بسیار، بلکه با همان یکی که کسی آن را نمی‌شناخت، تا اینکه API وب 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 از هر کاربرِ بدون راز دومِ راه‌اندازی‌شده دست‌کم کد ایمیل را می‌طلبد، تا زمانی که برنامهٔ Authenticator را راه بیندازد.

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 در فایروال وارد کنید (در OPNsense/pfSense به‌صورت URL Table Alias، در HAProxy به‌صورت فایل ACL).

5. ایمن‌سازی خودِ فایروال

1. رابط مدیریت فایروال را فقط از شبکهٔ داخلی در دسترس قرار دهید، هرگز از همان نشانی عمومیِ وب‌سایت.
2. به‌روزرسانی‌های امنیتی خودکار برای نرم‌افزار فایروال را فعال کنید، در صورتی که سازنده ارائه می‌دهد.
3. پیکربندی TLS را بررسی کنید: فقط نسخه‌های پروتکل به‌روز، روش‌های رمزنگاری منسوخ را غیرفعال کنید.
4. در صورت وجود: یک فهرست اعتبار شناخته‌شده (مثلاً Spamhaus DROP) را مستقیماً روی فایروال وارد کنید — مستقل از Web RBL، چون فایروال به این ترتیب ترافیک به سرویس‌هایی را هم می‌بیند که Odoo هرگز به آن‌ها نمی‌رسد.

6. بستن مدیریت پایگاه داده

1. بررسی کنید که آیا /web/database/manager از بیرون در دسترس است — اگر بله، در پیکربندی Odoo list_db = False را تنظیم کنید یا مسیر را در سطح فایروال مسدود کنید.
2. گذرواژهٔ اصلی مدیریت پایگاه داده را بلند و تصادفی تنظیم کنید و در هیچ جایی که کس دیگری بتواند بخواند یادداشت نکنید.

7. بررسی پشتیبان، نه فقط راه‌اندازی آن

1. یک پشتیبان‌گیری خودکار و منظم راه‌اندازی کنید، جدا از سرور Odoo ذخیره‌شده.
2. دست‌کم یک بار واقعاً بازگردانی کنید و بررسی کنید که بازیابی کار می‌کند — پشتیبانِ بررسی‌نشده یک فرض است.

هیچ‌یک از این گام‌ها جایگزین دیگری نیست. هر که فقط یکی را اجرا کند، یک در را محکم کرده و بقیه را باز گذاشته است — هر که هر هفت را اجرا کند، دفاعی دارد که حتی وقتی یک لایه شکست بخورد هم می‌ماند.

آنچه این معماری جایگزینش نیست

هیچ‌یک از اقدامات شرح‌داده‌شده دقت را بی‌نیاز نمی‌کند. ماژولی که پروب‌های .env را رد می‌کند، یک فایل .env که اشتباهاً منتشر شده را بی‌خطر نمی‌سازد. احراز هویت دومرحله‌ای از کاربری که کدش را برای تماس‌گیرنده‌ای پای تلفن می‌خواند محافظت نمی‌کند. و فایروال جایگزین تصمیم دربارهٔ اینکه چه کسی واقعاً چه مجوزی لازم دارد نیست. معماری امنیتی شرایطی می‌آفریند که در آن یک خطای منفرد بلافاصله به یک رخداد تبدیل نشود — دقت را از دوش هیچ‌کس برنمی‌دارد.

پرسش‌های متداول

آیا یک گذرواژهٔ قوی برای ایمن‌سازی Odoo 19 کافی است؟

خیر. یک گذرواژه را می‌توان جای دیگری دزدید، کاملاً مستقل از کیفیتش، و آن‌گاه نزد هر سرویسی که همان گذرواژه را بپذیرد کار می‌کند. فقط ترکیب با احراز هویت دومرحله‌ای، یک فایروال پیش از آن و ساختار مجوزهای معقول، ایمن‌سازی‌ای می‌دهد که پس از گذرواژهٔ دزدیده‌شده هم می‌ماند.

چگونه احراز هویت دومرحله‌ای را در Odoo 19 فعال کنم؟

ماژول «Two-Factor Authentication (TOTP)» را از طریق مدیریت Apps نصب کنید، سپس در تنظیمات ← تنظیمات عمومی ← مجوزها اجبار را فعال کنید و میان «فقط کارکنان» و «همهٔ کاربران» انتخاب کنید. هر کاربر پس از آن عامل دوم خودش را با کد 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.