Конфігурація системи¶

Цей документ описує базові кроки для налаштування Odoo у продакшені або на сервері, доступному з інтернету. Він йде після встановлення і зазвичай не потрібен для систем розробки, які не доступні з інтернету.

Попередження

Якщо ви налаштовуєте публічний сервер, обов’язково перевірте наші рекомендації щодо Безпека!

dbfilter¶

Odoo - це мультиорендна система: одна система Odoo може запускати та обслуговувати кілька екземплярів баз даних. Вона також дуже налаштовувана, причому налаштування (починаючи з модулів, що завантажуються) залежать від «поточної бази даних».

Це не проблема під час роботи з бекендом (веб-клієнтом) як авторизованого користувача компанії: базу даних можна вибрати під час входу, а налаштування завантажити потім.

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

Це одна з цілей --db-filter: він визначає, як базу даних слід вибирати на основі імені хоста (домену), що запитується. Значення є регулярним виразом, можливо з динамічно вставленим іменем хоста (%h) або першим субдоменом (%d), через який здійснюється доступ до системи.

Для серверів, що розміщують кілька баз даних у продакшені, особливо якщо використовується website, dbfilter повинен бути встановлений, інакше низка функцій не працюватиме правильно.

Приклади конфігурації¶

Показувати лише бази даних з іменами, що починаються з „mycompany“

у файлі конфігурації встановіть:

[options]
dbfilter = ^mycompany.*$

Показувати лише бази даних, що відповідають першому піддомену після www: наприклад, база даних «mycompany» буде показана, якщо вхідний запит надійшов на www.mycompany.com або mycompany.co.uk, але не для www2.mycompany.com або helpdesk.mycompany.com.

у файлі конфігурації встановіть:

[options]
dbfilter = ^%d$

Примітка

Встановлення належного --db-filter є важливою частиною захисту вашого розгортання. Після того, як він правильно працює і відповідає лише одній базі даних для кожного імені хоста, настійно рекомендується заблокувати доступ до екранів менеджера баз даних і використовувати параметр запуску --no-database-list, щоб запобігти перерахуванню ваших баз даних і заблокувати доступ до екранів керування базами даних. Див. також security.

PostgreSQL¶

За замовчуванням PostgreSQL дозволяє з’єднання лише через сокети UNIX і петлеві з’єднання (з «localhost», тієї ж машини, на якій встановлено сервер PostgreSQL).

Сокет UNIX підходить, якщо ви хочете, щоб Odoo і PostgreSQL виконувалися на одній машині, і це налаштування за замовчуванням, коли хост не вказано, але якщо ви хочете, щоб Odoo і PostgreSQL виконувалися на різних машинах 1, йому потрібно буде прослуховувати мережеві інтерфейси 2, або:

Приймати лише петлеві з’єднання та використовувати SSH-тунель між машиною, на якій працює Odoo, і тією, на якій працює PostgreSQL, а потім налаштувати Odoo для підключення до його кінця тунелю
Приймати з’єднання до машини, на якій встановлено Odoo, можливо через ssl (докладніше див. Налаштування з’єднання PostgreSQL), а потім налаштувати Odoo для підключення через мережу

Приклад конфігурації¶

Дозволити tcp-з’єднання на localhost
Дозволити tcp-з’єднання з мережі 192.168.1.x

у /etc/postgresql/<ВАША ВЕРСІЯ POSTGRESQL>/main/pg_hba.conf встановити:

# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
host    all             all             192.168.1.0/24          md5

у /etc/postgresql/<ВАША ВЕРСІЯ POSTGRESQL>/main/postgresql.conf встановити:

listen_addresses = 'localhost,192.168.1.2'
port = 5432
max_connections = 80

Налаштування Odoo¶

За замовчуванням Odoo підключається до локального postgres через сокет UNIX через порт 5432. Це можна змінити за допомогою параметрів бази даних, коли ваше розгортання Postgres не є локальним і/або не використовує налаштування за замовчуванням.

Пакетні інсталятори автоматично створять нового користувача (odoo) і встановлять його як користувача бази даних.

Екрани керування базами даних захищені налаштуванням admin_passwd. Це налаштування можна встановити лише за допомогою файлів конфігурації і просто перевіряється перед внесенням змін до бази даних. Його слід встановити на випадково згенероване значення, щоб треті сторони не могли використовувати цей інтерфейс.
Усі операції з базами даних використовують параметри бази даних, включаючи екран керування базами даних. Щоб екран керування базами даних працював, потрібно, щоб користувач PostgreSQL мав право createdb.
Користувачі завжди можуть видаляти бази даних, якими вони володіють. Щоб екран керування базами даних був повністю нефункціональним, користувача PostgreSQL потрібно створити з no-createdb, а база даних повинна належати іншому користувачеві PostgreSQL.

Попередження
користувач PostgreSQL не повинен бути суперкористувачем

Приклад конфігурації¶

підключитися до сервера PostgreSQL на 192.168.1.2
порт 5432
використовуючи обліковий запис користувача „odoo“,
з „pwd“ як паролем
фільтруючи лише бази даних з іменем, що починається з „mycompany“

у файлі конфігурації встановіть:

[options]
admin_passwd = mysupersecretpassword
db_host = 192.168.1.2
db_port = 5432
db_user = odoo
db_password = pwd
dbfilter = ^mycompany.*$

SSL між Odoo та PostgreSQL¶

Починаючи з Odoo 11.0, ви можете примусово використовувати ssl-з’єднання між Odoo та PostgreSQL. В Odoo параметр db_sslmode контролює ssl-безпеку з’єднання зі значенням, обраним з „disable“, „allow“, „prefer“, „require“, „verify-ca“ або „verify-full“

Документація PostgreSQL

Вбудований сервер¶

Odoo включає вбудовані HTTP, cron та live-chat сервери, що використовують багатопотоковість або багатопроцесність.

Багатопотоковий сервер — це простіший сервер, що використовується насамперед для розробки, демонстрацій та завдяки сумісності з різними операційними системами (включно з Windows). Новий потік створюється для кожного нового HTTP-запиту, навіть для тривалих з’єднань, таких як websocket. Також створюються додаткові демонічні cron-потоки. Через обмеження Python (GIL) він не використовує апаратні ресурси найкращим чином.

Багатопотоковий сервер є сервером за замовчуванням, також для docker-контейнерів. Він вибирається, якщо не вказувати параметр --workers або встановити його значення 0.

Багатопроцесний сервер — це повноцінний сервер, що використовується насамперед для продакшену. Він не підлягає тому самому обмеженню Python (GIL) щодо використання ресурсів і тому використовує апаратні ресурси найкращим чином. Пул воркерів створюється при запуску сервера. Нові HTTP-запити ставляться в чергу операційною системою, поки не з’являться готові воркери для їх обробки. Додатковий event-driven HTTP-воркер для live chat створюється на альтернативному порті. Також створюються додаткові cron-воркери. Налаштовуваний процес-збирач відстежує використання ресурсів і може завершувати/перезапускати збійні воркери.

Багатопроцесний сервер вмикається за бажанням. Він вибирається встановленням параметра --workers на ненульове ціле число.

Примітка

Оскільки він сильно налаштований для Linux-серверів, багатопроцесний сервер недоступний на Windows.

Розрахунок кількості воркерів¶

Емпіричне правило: (#CPU * 2) + 1
Cron-воркерам потрібен CPU
1 воркер ~= 6 одночасних користувачів

розрахунок обсягу пам’яті¶

Ми вважаємо, що 20% запитів є важкими запитами, тоді як 80% є простішими
Важкий робочий процес, коли всі обчислювані поля добре спроектовані, SQL-запити добре спроектовані, … як очікується, споживає близько 1 ГБ оперативної пам’яті
Легший робочий процес у тому самому сценарії, як очікується, споживає близько 150 МБ оперативної пам’яті

Необхідна RAM = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

LiveChat¶

У багатопроцесному режимі виділений робочий процес LiveChat автоматично запускається і прослуховує --gevent-port. За замовчуванням HTTP-запити продовжуватимуть надходити до звичайних HTTP-процесів замість LiveChat. Необхідно розгорнути проксі перед Odoo та перенаправити вхідні запити, чий шлях починається з /websocket/, до робочого процесу LiveChat. Також необхідно запустити Odoo у режимі --proxy-mode, щоб він використовував справжні заголовки клієнта (такі як ім’я хоста, схема та IP) замість заголовків проксі.

Приклад конфігурації¶

Сервер з 4 процесорами, 8 потоками
60 одночасних користувачів
60 користувачів / 6 = 10 <- теоретична кількість необхідних робочих процесів
(4 * 2) + 1 = 9 <- теоретична максимальна кількість робочих процесів
Використаємо 8 робочих процесів + 1 для cron. Також використаємо систему моніторингу для вимірювання навантаження процесора та перевіримо, чи воно між 7 і 7,5.
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3 ГБ оперативної пам’яті для Odoo

у файлі конфігурації:

[options]
limit_memory_hard = 1677721600
limit_memory_soft = 629145600
limit_request = 8192
limit_time_cpu = 600
limit_time_real = 1200
max_cron_threads = 1
workers = 8

HTTPS¶

Чи до неї здійснюється доступ через веб-сайт/веб-клієнт чи веб-сервіс, Odoo передає інформацію для автентифікації у відкритому вигляді. Це означає, що безпечне розгортання Odoo має використовувати HTTPS3. Завершення SSL може бути реалізоване через практично будь-який проксі-сервер завершення SSL, але вимагає наступного налаштування:

Увімкніть режим проксі Odoo. Це слід вмикати лише тоді, коли Odoo знаходиться за зворотним проксі
Налаштуйте проксі-сервер завершення SSL (приклад завершення Nginx)
Налаштуйте саме проксіювання (приклад проксіювання Nginx)
Ваш проксі-сервер завершення SSL також повинен автоматично перенаправляти незахищені з’єднання на безпечний порт

Приклад конфігурації¶

Перенаправлення http-запитів на https
Проксіювання запитів до odoo

у файлі конфігурації встановіть:

proxy_mode = True

у /etc/nginx/sites-enabled/odoo.conf встановіть:

#odoo server
upstream odoo {
  server 127.0.0.1:8069;
}
upstream odoochat {
  server 127.0.0.1:8072;
}
map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

# http -> https
server {
  listen 80;
  server_name odoo.mycompany.com;
  rewrite ^(.*) https://$host$1 permanent;
}

server {
  listen 443 ssl;
  server_name odoo.mycompany.com;
  proxy_read_timeout 720s;
  proxy_connect_timeout 720s;
  proxy_send_timeout 720s;

  # SSL parameters
  ssl_certificate /etc/ssl/nginx/server.crt;
  ssl_certificate_key /etc/ssl/nginx/server.key;
  ssl_session_timeout 30m;
  ssl_protocols TLSv1.2;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
  ssl_prefer_server_ciphers off;

  # log
  access_log /var/log/nginx/odoo.access.log;
  error_log /var/log/nginx/odoo.error.log;

  # Redirect websocket requests to odoo gevent port
  location /websocket {
    proxy_pass http://odoochat;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

  # Redirect requests to odoo backend server
  location / {
    # Add Headers for odoo proxy mode
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_redirect off;
    proxy_pass http://odoo;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

  # common gzip
  gzip_types text/css text/scss text/plain text/xml application/xml application/json application/javascript;
  gzip on;
}

Посилення HTTPS¶

Додайте заголовок Strict-Transport-Security до всіх запитів, щоб запобігти надсиланню браузерами звичайних HTTP-запитів до цього домену. Вам потрібно буде постійно підтримувати робочий HTTPS-сервіс з дійсним сертифікатом для цього домену, інакше ваші користувачі бачитимуть попередження безпеки або взагалі не зможуть отримати до нього доступ.

Примусово використовуйте HTTPS-з’єднання протягом року для кожного відвідувача в NGINX за допомогою рядка:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

Додаткову конфігурацію можна визначити для cookie session_id. Можна додати прапорець Secure, щоб забезпечити, що він ніколи не передається через HTTP, і SameSite=Lax, щоб запобігти автентифікованій CSRF.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

Odoo як застосунок WSGI¶

Також можна підключити Odoo як стандартний застосунок WSGI. Odoo надає основу для сценарію запуску WSGI як odoo-wsgi.example.py. Цей сценарій слід налаштувати (можливо, після копіювання з каталогу налаштування), щоб правильно встановити конфігурацію безпосередньо в odoo.tools.config, а не через командний рядок або файл конфігурації.

Однак сервер WSGI надаватиме лише основну HTTP-кінцеву точку для веб-клієнта, веб-сайту та API веб-служби. Оскільки Odoo більше не контролює створення воркерів, він не може налаштувати воркери cron або livechat

Воркери Cron¶

Для обробки завдань cron потрібно запустити один із вбудованих серверів Odoo поруч із сервером WSGI. Цей сервер має бути налаштований лише на обробку cron, а не HTTP-запитів, використовуючи параметр командного рядка --no-http або налаштування файла конфігурації http_enable = False.

На Linux-подібних системах рекомендується використовувати багатопроцесний сервер замість багатопоточного для кращого використання обладнання та підвищеної стабільності, тобто використовуючи параметри командного рядка --workers=-1 і --max-cron-threads=n.

LiveChat¶

Для правильної роботи функції живого чату потрібен WSGI-сервер, сумісний з gevent. Цей сервер повинен мати можливість обробляти багато одночасних з’єднань тривалої дії, але не потребує великої потужності обробки. Усі запити, шлях яких починається з /websocket/, слід направляти на цей сервер. Для всіх інших запитів слід використовувати звичайний WSGI-сервер (на основі потоків/процесів).

Сервер cron Odoo також можна використовувати для обслуговування запитів живого чату. Просто видаліть параметр командного рядка --no-http із сервера cron і переконайтеся, що запити, шлях яких починається з /websocket/, направляються на цей сервер, або на --http-port (багатопоточний сервер), або на --gevent-port (багатопроцесний сервер).

Обслуговування статичних файлів і вкладень¶

Для зручності розробки Odoo безпосередньо обслуговує всі статичні файли та вкладення у своїх модулях. Це може бути не ідеально з точки зору продуктивності, і статичні файли зазвичай мають обслуговуватися статичним HTTP-сервером.

Обслуговування статичних файлів¶

Статичні файли Odoo розташовані в папці static/ кожного модуля, тому статичні файли можна обслуговувати, перехоплюючи всі запити до /MODULE/static/FILE і шукаючи потрібний модуль (і файл) у різних шляхах додатків.

Рекомендується встановити заголовок Content-Security-Policy: default-src 'none' для всіх зображень, що доставляються веб-сервером. Це не є суворо обов’язковим, оскільки користувачі не можуть змінювати/вставляти вміст у папку static/ модулів, а наявні зображення є остаточними (вони не завантажують нові ресурси самостійно). Однак це хороша практика.

Використовуючи наведену вище конфігурацію NGINX (https), слід додати наступні блоки map і location для обслуговування статичних файлів через NGINX.

map $sent_http_content_type $content_type_csp {
    default "";
    ~image/ "default-src 'none'";
}

server {
    # the rest of the configuration

    location @odoo {
        # copy-paste the content of the / location block
    }

    # Serve static files right away
    location ~ ^/[^/]+/static/.+$ {
        # root and try_files both depend on your addons paths
        root ...;
        try_files ... @odoo;
        expires 24h;
        add_header Content-Security-Policy $content_type_csp;
    }
}

Фактичні директиви root і try_files залежать від вашої інсталяції, зокрема від вашого --addons-path.

Example

Припустимо, що Odoo встановлено через debian-пакети для Community та Enterprise, і що --addons-path має значення '/usr/lib/python3/dist-packages/odoo/addons'.

Параметри root та try_files мають бути:

root /usr/lib/python3/dist-packages/odoo/addons;
try_files $uri @odoo;

Припустимо, що Odoo встановлено з вихідних кодів, що обидва git-репозиторії Community та Enterprise було клоновано відповідно в /opt/odoo/community та /opt/odoo/enterprise, і що --addons-path має значення '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'.

Параметри root та try_files мають бути:

root /opt/odoo;
try_files /community/odoo/addons$uri /community/addons$uri /enterprise$uri @odoo;

Обслуговування вкладень¶

Вкладення — це файли, що зберігаються в файловому сховищі, доступ до яких регулюється Odoo. До них неможливо отримати прямий доступ через статичний веб-сервер, оскільки для цього потрібно виконати кілька запитів до бази даних, щоб визначити, де зберігаються файли та чи може поточний користувач отримати до них доступ.

Проте після того, як файл буде знайдено та права доступу перевірено Odoo, рекомендується обслуговувати файл за допомогою статичного вебсервера замість Odoo. Щоб Odoo делегувало обслуговування файлів статичному вебсерверу, необхідно ввімкнути та налаштувати розширення X-Sendfile (apache) або X-Accel (nginx) на статичному вебсервері. Після налаштування запустіть Odoo з прапорцем CLI --x-sendfile (цей універсальний прапорець використовується як для X-Sendfile, так і для X-Accel).

Примітка

Розширення X-Sendfile для apache (та сумісних веб-серверів) не потребує додаткового налаштування.
Розширення X-Accel для NGINX потребує такого додаткового налаштування:
```
location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
    add_header Content-Security-Policy $upstream_http_content_security_policy;
    add_header X-Content-Type-Options nosniff;
}
```
Якщо ви не знаєте шлях до файлового сховища, запустіть Odoo з параметром --x-sendfile і перейдіть до URL /web/filestore безпосередньо через Odoo (не переходьте до URL через NGINX). Це створить попередження, повідомлення якого міститиме необхідну конфігурацію.

Безпека¶

Для початку майте на увазі, що захист інформаційної системи — це безперервний процес, а не одноразова операція. У будь-який момент ви будете захищені настільки, наскільки захищена найслабша ланка у вашому середовищі.

Тому не сприймайте цей розділ як остаточний перелік заходів, які запобігатимуть усім проблемам безпеки. Він призначений лише як зведення перших важливих речей, які ви маєте обов’язково включити до свого плану дій із безпеки. Решта буде виходити з найкращих практик безпеки для вашої операційної системи та дистрибутива, найкращих практик щодо користувачів, паролів та керування контролем доступу тощо.

Під час розгортання сервера з доступом до інтернету обов’язково врахуйте такі питання, пов’язані з безпекою:

Завжди встановлюйте надійний пароль суперадміністратора та обмежте доступ до сторінок керування базами даних одразу після налаштування системи. Див. Безпека менеджера бази даних.
Оберіть унікальні логіни та надійні паролі для всіх облікових записів адміністраторів у всіх базах даних. Не використовуйте „admin“ як логін. Не використовуйте ці логіни для повсякденних операцій, лише для контролю/керування інсталяцією. Ніколи не використовуйте стандартні паролі на кшталт admin/admin, навіть для тестових/промміжних баз даних.
Не встановлюйте демонстраційні дані на серверах з доступом до інтернету. Бази даних з демонстраційними даними містять стандартні логіни та паролі, які можна використати для входу у ваші системи та створення значних проблем, навіть у промміжних/тестових системах.
Використовуйте відповідні фільтри баз даних (--db-filter), щоб обмежити видимість ваших баз даних відповідно до імені хоста. Див. dbfilter. Ви також можете використовувати -d, щоб надати власний список доступних баз даних (через кому) для фільтрування, замість того щоб система отримувала їх усі з бекенду бази даних.
Коли ваші параметри db_name та dbfilter налаштовані та відповідають лише одній базі даних для кожного імені хоста, слід встановити параметр конфігурації list_db у значення False, щоб повністю заборонити перелік баз даних та заблокувати доступ до екранів керування базами даних (це також доступно як параметр командного рядка --no-database-list)
Переконайтеся, що користувач PostgreSQL (--db_user) не є суперкористувачем, а ваші бази даних належать іншому користувачеві. Наприклад, вони можуть належати суперкористувачеві postgres, якщо ви використовуєте виділеного непривілейованого db_user. Див. також Налаштування Odoo.
Підтримуйте інсталяції в актуальному стані, регулярно встановлюючи останні збірки через GitHub або завантажуючи останню версію з https://www.odoo.com/page/download або http://nightly.odoo.com
Налаштуйте сервер у багатопроцесному режимі з відповідними обмеженнями, що відповідають вашому типовому використанню (пам’ять/CPU/тайм-аути). Див. також Вбудований сервер.
Запустіть Odoo за веб-сервером, що забезпечує завершення HTTPS з дійсним SSL-сертифікатом, щоб запобігти перехопленню незашифрованих повідомлень. SSL-сертифікати недорогі, і існує багато безкоштовних варіантів. Налаштуйте веб-проксі для обмеження розміру запитів, встановіть відповідні тайм-аути, а потім увімкніть параметр режим проксі. Див. також HTTPS.
Якщо вам потрібно дозволити віддалений SSH-доступ до ваших серверів, переконайтеся, що встановлено надійний пароль для всіх облікових записів, а не лише для root. Наполегливо рекомендується повністю вимкнути автентифікацію на основі пароля та дозволити лише автентифікацію за відкритим ключем. Також розгляньте можливість обмеження доступу через VPN, дозволивши лише довірені IP-адреси у брандмауері та/або запустивши систему виявлення атак методом підбору, таку як fail2ban або еквівалентну.
Розгляньте можливість встановлення відповідного обмеження швидкості на вашому проксі або брандмауері, щоб запобігти атакам методом підбору та атакам відмови в обслуговуванні. Див. також Блокування атак методом підбору для конкретних заходів.

Багато мережевих провайдерів надають автоматичне пом’якшення для розподілених атак відмови в обслуговуванні (DDOS), але це часто є додатковою послугою, тому вам слід проконсультуватися з ними.
Коли це можливо, розміщуйте ваші загальнодоступні демонстраційні/тестові/підготовчі екземпляри на інших машинах, ніж продуктивні. І застосовуйте ті самі заходи безпеки, що й для продуктивних.
Якщо ваш загальнодоступний сервер Odoo має доступ до чутливих внутрішніх мережевих ресурсів або служб (наприклад, через приватну VLAN), впровадьте відповідні правила брандмауера для захисту цих внутрішніх ресурсів. Це гарантує, що сервер Odoo не може бути використаний випадково (або в результаті зловмисних дій користувача) для доступу або порушення роботи цих внутрішніх ресурсів. Зазвичай це можна зробити, застосувавши вихідне правило DENY за замовчуванням на брандмауері, а потім лише явно авторизувавши доступ до внутрішніх ресурсів, до яких серверу Odoo потрібен доступ. Контроль доступу до IP-трафіку Systemd також може бути корисним для реалізації мережевого контролю доступу для кожного процесу.
Якщо ваш загальнодоступний сервер Odoo знаходиться за брандмауером веб-додатків, балансувальником навантаження, прозорою службою захисту від DDoS (як CloudFlare) або подібним пристроєм мережевого рівня, ви можете уникнути прямого доступу до системи Odoo. Зазвичай важко зберегти в таємниці IP-адреси кінцевих точок ваших серверів Odoo. Наприклад, вони можуть з’являтися в журналах веб-сервера під час запиту публічних систем або в заголовках електронних листів, надісланих з Odoo. У такій ситуації ви можете налаштувати брандмауер так, щоб кінцеві точки не були загальнодоступними, окрім як з конкретних IP-адрес вашого WAF, балансувальника навантаження або проксі-служби. Постачальники послуг, такі як CloudFlare, зазвичай підтримують публічний список своїх діапазонів IP-адрес для цієї мети.
Якщо ви розміщуєте кількох клієнтів, ізолюйте дані та файли клієнтів один від одного за допомогою контейнерів або відповідних технік «ізоляції».
Налаштуйте щоденні резервні копії ваших баз даних і даних сховища файлів та скопіюйте їх на віддалений архівний сервер, який недоступний з самого сервера.
Розгортання Odoo на Linux настійно рекомендується замість Windows. Якщо ви все ж вирішите розгорнути на платформі Windows, слід провести ретельний огляд посилення безпеки сервера, що виходить за межі цього посібника.

Блокування атак методом підбору¶

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

Записи журналу матимуть таку форму.

Невдалий вхід:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login failed for db:db_name login:admin from 127.0.0.1

Успішний вхід:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login successful for db:db_name login:admin from 127.0.0.1

Ці журнали можуть бути легко проаналізовані системою запобігання вторгненням, такою як fail2ban.

Наприклад, наступне визначення фільтра fail2ban повинно відповідати невдалому входу:

[Definition]
failregex = ^ \d+ INFO \S+ \S+ Login failed for db:\S+ login:\S+ from <HOST>
ignoreregex =

Це можна використовувати з визначенням jail для блокування атакуючої IP-адреси на HTTP(S).

Ось як це може виглядати для блокування IP-адреси на 15 хвилин, коли виявлено 10 невдалих спроб входу з тієї самої IP-адреси протягом 1 хвилини:

[odoo-login]
enabled = true
port = http,https
bantime = 900  ; 15 min ban
maxretry = 10  ; if 10 attempts
findtime = 60  ; within 1 min  /!\ Should be adjusted with the TZ offset
logpath = /var/log/odoo.log  ;  set the actual odoo log path here

Безпека менеджера бази даних¶

Налаштування Odoo згадує admin_passwd побіжно.

Це налаштування використовується на всіх екранах керування базами даних (для створення, видалення, резервного копіювання або відновлення баз даних).

Якщо екрани керування взагалі не повинні бути доступні, слід встановити параметр конфігурації list_db у False, щоб заблокувати доступ до всіх екранів вибору та керування базами даних.

Попередження

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

У виробничих системах операції керування базами даних завжди повинні виконуватися системним адміністратором, включаючи створення нових баз даних та автоматичне резервне копіювання.

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

Якщо екрани керування повинні бути доступні лише з певного набору машин, використовуйте функції проксі-сервера для блокування доступу до всіх маршрутів, що починаються з /web/database, за винятком (можливо) /web/database/selector, який відображає екран вибору бази даних.

Якщо екран керування базою даних має залишатися доступним, налаштування admin_passwd необхідно змінити з його значення за замовчуванням admin: цей пароль перевіряється перед дозволом операцій зміни бази даних.

Його слід зберігати безпечно та генерувати випадковим чином, наприклад.

$ python3 -c 'import base64, os; print(base64.b64encode(os.urandom(24)))'

який генерує 32-символьний псевдовипадковий друкований рядок.

Скидання головного пароля¶

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

Див. також

Обліковий запис Odoo.com

Під час створення нової локальної бази даних генерується випадковий головний пароль. Odoo рекомендує використовувати цей пароль для захисту бази даних. Цей пароль реалізовано за замовчуванням, тому для будь-якого локального розгортання Odoo є безпечний головний пароль.

Попередження

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

Головний пароль вказується у конфігураційному файлі Odoo (odoo.conf або odoorc (прихований файл)). Головний пароль Odoo потрібен для зміни, створення або видалення бази даних через графічний інтерфейс користувача (GUI).

Знаходження конфігураційного файлу¶

Спочатку відкрийте конфігураційний файл Odoo (odoo.conf або odoorc (прихований файл)).

Конфігураційний файл розташований за адресою: c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf

Залежно від того, як Odoo встановлено на машині Linux, конфігураційний файл розташований в одному з двох місць:

Встановлення пакету: /etc/odoo.conf
Встановлення з вихідних кодів: ~/.odoorc

Зміна старого пароля¶

Після відкриття відповідного файлу змініть старий пароль у файлі конфігурації на тимчасовий пароль.

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

Далі змініть рядок головного пароля admin_passwd = $pbkdf2-sha… на admin_passwd = newpassword1234, наприклад. Цей пароль може бути будь-яким, головне — тимчасово його зберегти. Переконайтеся, що змінили всі символи після =.

Example

Рядок виглядає так: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

Змінений рядок виглядає так: admin_passwd = newpassword1234

Змініть рядок головного пароля за допомогою наступної команди Unix, описаної нижче.

Підключіться до терміналу сервера Odoo через протокол Secure Shell (SSH) і відредагуйте файл конфігурації. Щоб змінити файл конфігурації, введіть наступну команду: sudo nano /etc/odoo.conf

Після відкриття файлу конфігурації змініть рядок головного пароля admin_passwd = $pbkdf2-sha… на admin_passwd = newpassword1234. Цей пароль може бути будь-яким, головне — тимчасово його зберегти. Переконайтеся, що змінили всі символи після =.

Example

Рядок виглядає так: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

Змінений рядок виглядає так: admin_passwd = newpassword1234

Важливо

Важливо, щоб пароль було змінено на інший, а не запущено нове скидання пароля додаванням крапки з комою ; на початку рядка. Це забезпечує безпеку бази даних протягом усього процесу скидання пароля.

Перезапуск сервера Odoo¶

Після встановлення тимчасового пароля необхідно перезапустити сервер Odoo.

Щоб перезапустити сервер Odoo, спочатку введіть services у рядок Пошук Windows. Потім виберіть програму Служби і прокрутіть вниз до служби Odoo.

Далі клацніть правою кнопкою миші на Odoo і виберіть Запустити або Перезапустити. Ця дія вручну перезапускає сервер Odoo.

Перезапустіть сервер Odoo, ввівши команду: sudo service odoo15 restart

Примітка

Змініть число після odoo відповідно до конкретної версії, на якій працює сервер.

Використання веб-інтерфейсу для повторного шифрування пароля¶

Спочатку перейдіть до /web/database/manager або http://server_ip:port/web/database/manager у браузері.

Примітка

Замініть server_ip на IP-адресу бази даних. Замініть port на номер порту, через який доступна база даних.

Далі натисніть Встановити головний пароль і введіть раніше обраний тимчасовий пароль у поле Головний пароль. Після цього введіть Новий головний пароль. Новий головний пароль буде захешовано (або зашифровано) після натискання кнопки Продовжити.

На цьому етапі пароль успішно скинуто, і захешована версія нового пароля тепер з’являється у файлі конфігурації.

Див. також

Для отримання додаткової інформації про безпеку бази даних Odoo дивіться цю документацію: Безпека менеджера бази даних.

Підтримувані браузери¶

Odoo підтримує останню версію таких браузерів.

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

1: щоб декілька інсталяцій Odoo використовували одну базу даних PostgreSQL або щоб надати більше обчислювальних ресурсів обом програмам.
2: технічно інструмент на кшталт socat можна використовувати для проксіювання UNIX-сокетів через мережі, але це здебільшого для програмного забезпечення, яке можна використовувати лише через UNIX-сокети
3: або бути доступним лише через внутрішню комутовану мережу пакетів, але це вимагає захищених комутаторів, захисту від ARP spoofing і виключає використання WiFi. Навіть у захищених комутованих мережах пакетів рекомендується розгортання через HTTPS, а можливі витрати знижуються, оскільки «самопідписані» сертифікати легше розгорнути в контрольованому середовищі, ніж в інтернеті.