Архітектура безпеки Odoo 19: як правильно поєднати міжмережевий екран, 2FA, права доступу та Web RBL

Odoo на наших п’яти вебсайтах доступний з відкритого інтернету, і це не виняток, а звичайна ситуація: хто надає пропозицію, інтернет-магазин чи вхід для клієнтів, має публічний сервер. Одного вразливого пароля, забутого файлу конфігурації або надто щедрого права доступу досить, щоб публічний сервер став відкритим.

Ця стаття показує, як правильно захистити Odoo 19 — не одним заходом, а кількома шарами, що доповнюють один одного: міжмережевий екран і зворотний проксі, наш модуль з відкритим кодом 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, обхід шляху (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-код, у будь-якому поширеному застосунку-автентифікаторі:

Налаштування: відсканувати QR-код, один раз підтвердити шестизначний код — готово.

Але це допомагає лише тим, хто налаштовує його сам, а досвід показує, що без примусу таких залишається меншість. Тому Odoo має політику примусового застосування: або лише для працівників (внутрішніх користувачів), або для всіх, включно з користувачами порталу. Без налаштованого другого секрету ніхто більше не проходить повз форму входу, не підтвердивши принаймні кодом з електронної пошти.

Політика паролів: мінімальна довжина — не самоочевидність

Без додаткового модуля Odoo Community не покладається на жодну мінімальну довжину паролів — користувач може задати пароль із трьох символів, якщо йому ніхто не завадить. Власний модуль Password Policy закриває саме цю прогалину: мінімальна довжина, яка примусово застосовується на стороні сервера, а не лише пропонується в браузері. Хто хоче більше — примусовий термін дії, історію проти повторного використання — потребує для цього модуля OCA або сторонього; у версії Community це свідомо зроблено мінімалістичним.

Права доступу: доступ отримує лише той, кому він потрібен

Odoo із коробки розділяє три рівні: користувачі порталу (лише власний портал клієнта чи постачальника), внутрішні користувачі (бекенд, із правами для кожного застосунку) та адміністратори (необмежений доступ разом із технічними налаштуваннями). Найчастіша помилка — не надто слабкий пароль, а надто щедро надана роль адміністратора: хто має лише створювати рахунки, тому не потрібен доступ до системних налаштувань.

Два принципи несуть більшу частину навантаження:

Обидва пункти можна перевірити в тому самому вікні, де налаштовується двофакторна автентифікація:

Один огляд, чотири важелі: пароль, другий фактор, ключі API, пристрої, з яких виконано вхід.

Сесії та пристрої: хто зараз увійшов

У тому самому вікні також видно, з яких пристроїв зараз виконано вхід в обліковий запис, — і можна вийти з одного або з усіх одразу. Після втраченого ноутбука чи підозри на скомпрометований пароль це найшвидший дієвий крок: сесія завершується негайно, незалежно від того, чи пароль уже змінено.

Шар 4: база даних і експлуатація

Четвертий шар — найменш помітний і водночас найнепробачніший, бо помилка тут може звести нанівець усе збудоване раніше.

• Регулярні, перевірені резервні копії, що зберігаються окремо від самого сервера. Копія, яку жодного разу не відновлювали, — це припущення, а не копія.
• Секрети не місце в жодному файлі журналу. Паролі, ключі API, ліцензійні дані — хто пише власні розширення, має поводитися з ними так само, як із головним паролем: ніде не записувати, навіть «лише для налагодження».
• Тримати модулі актуальними, зокрема й особливо сторонні модулі. Вільні додаткові модулі (OCA та інші) природно відстають від нових версій Odoo; перед кожним встановленням варто подивитися, які залежності підтягуються автоматично.

Шлях входу в цілому

Чотири шари діють не послідовно в окремих кімнатах, а на тому самому запиті, ступінь за ступенем. Найнаочніше це видно на прикладі входу:

П’ять місць, де шкідливий запит може обірватися, не досягнувши справжньої мети, — і лише одне, де законний користувач проходить їх усі.

Сценарії атак і протидія їм

Наведена нижче таблиця співвідносить реальні шаблони атак із шарами, які їх справді зупиняють. Кілька з них — не теорія, а наші власні спостереження за сімнадцять днів реального трафіку на наших п’яти вебсайтах.

Крок за кроком: захист власного встановлення Odoo

Наведена нижче послідовність — та, у якій ми діяли б самі, — від найбільшого ефекту до найтоншого налаштування.

1. Примусово ввімкнути двофакторну автентифікацію

1. Якщо ще не встановлено: відкрийте Застосунки, знайдіть «Two-Factor Authentication» і встановіть (за кількох вебсайтів додатково рекомендується «Two-Factor Authentication by Mail» як резервний варіант).
2. Відкрийте Налаштування → Загальні налаштування → Дозволи.
3. Увімкніть «Примусова двофакторна автентифікація».
4. Виберіть політику: «Лише працівники» для внутрішніх користувачів, «Усі користувачі», якщо потрібно охопити й користувачів порталу (клієнтів із доступом).
5. Збережіть. З наступної спроби входу Odoo вимагатиме від кожного користувача без налаштованого другого секрету щонайменше код з електронної пошти, доки він не налаштує застосунок-автентифікатор.

2. Встановити мінімальну довжину паролів

1. Відкрийте Застосунки, знайдіть «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)» через керування застосунками, потім у Налаштування → Загальні налаштування → Дозволи ввімкніть примусове застосування та виберіть між «Лише працівники» та «Усі користувачі». Після цього кожен користувач налаштовує власний другий фактор через 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.