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

У цьому документі описано основні кроки для налаштування Odoo у production або на сервері з доступом до Інтернету. Він іде за installation і, як правило, не є необхідним для систем розробки, які не доступні в Інтернеті.

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

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

dbfilter¶

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

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

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

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

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

Зразки конфігурації¶

Показати лише бази даних, назви яких починаються з „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 на локальному хості
Дозволити підключення TCP з мережі 192.168.1.x

у /etc/postgresql/9.5/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/9.5/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 must not бути суперкористувачем

Зразки конфігурації¶

підключитися до сервера PostgreSQL на 192.168.1.2
порт 5432
використовуючи обліковий запис користувача „odoo“,
з „pwd“ як пароль
фільтрація лише db з назвою, що починається з „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-сервери, що використовують або багатопотоковість, або багатопроцесорність.

Для production використання рекомендується використовувати багатопроцесорний сервер, оскільки він підвищує стабільність, дещо краще використовує обчислювальні ресурси, його можна краще контролювати та обмежувати ресурси.

Багатопроцесорність увімкнена шляхом налаштування ненульової кількості робочих процесів, кількість робочих процесів має базуватися на кількості ядер у машині (можливо, з деяким місцем для робочих процесів cron залежно від того, скільки роботи cron передбачено)
Обмеження робочих місць можна налаштувати на основі конфігурації апаратного забезпечення, щоб уникнути виснаження ресурсів

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

багатопроцесорний режим наразі недоступний у Windows

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

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

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

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

Необхідна оперативна пам’ять = #worker * ((light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

LiveChat¶

У багатопроцесорному режимі автоматично запускається спеціальний робочий LiveChat, який слухає порт longpolling, але клієнт не підключається до нього.

Натомість ви повинні мати проксі-сервер, який переспрямовує запити, URL-адреса яких починається з /longpolling/ на порт longpolling. Інші запити мають надсилатися на звичайний порт HTTP

Щоб досягти цього, вам потрібно буде розгорнути зворотний проксі перед Odoo, наприклад nginx або apache. При цьому вам потрібно буде переслати ще кілька http-заголовків до Odoo та активувати proxy_mode у конфігурації Odoo, щоб Odoo читав ці заголовки.

Зразки конфігурації¶

Сервер з 4 процесорами, 8 потоками
60 одночасних користувачів
60 користувачів / 6 = 10 <- необхідна теоретична кількість воркерів
(4 * 2) + 1 = 9 <- теоретична максимальна кількість воркерів
Ми будемо використовувати 8 воркерів + 1 для cron. Ми також використаємо систему моніторингу для вимірювання навантаження на ЦП і перевіримо, чи воно знаходиться між 7 і 7,5.
RAM = 9 * ((0,8*150) + (0,2*1024)) ~= 3Gb RAM для 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;
}

# 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;

  # Add Headers for odoo proxy mode
  proxy_set_header X-Forwarded-Host $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;

  # 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 longpoll requests to odoo longpolling port
  location /longpolling {
    proxy_pass http://odoochat;
  }

  # Redirect requests to odoo backend server
  location / {
    proxy_redirect off;
    proxy_pass http://odoo;
  }

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

Odoo як програма WSGI¶

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

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

Воркери Cron¶

Щоб запустити завдання cron для розгортання Odoo як програми WSGI, потрібно

Класичний Odoo (запускається через odoo-bin)
Підключено до бази даних, у якій потрібно запускати завдання cron (через odoo-bin -d)
Які не варто виставляти в мережу. Щоб переконатися, що запускачі cron недоступні в мережі, можна повністю вимкнути вбудований HTTP-сервер за допомогою odoo-bin --no-http або налаштування http_enable = False у файлі конфігурації

LiveChat¶

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

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

Рішення для підтримки живого livechat/motifications у програмі WSGI:

Розгорніть потокову версію Odoo (замість префоркінгу на основі процесу) і перенаправляйте на цей Odoo лише запити на URL-адреси, що починаються з /longpolling/. Це найпростіше, і URL-адреса longpolling може подвоїтися як екземпляр cron .
Розгорніть Odoo з подіями через odoo-gevent і проксі-запити, починаючи з /longpolling/ to порту longpolling.

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

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

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

Безпека¶

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

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

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

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

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

Блокування атак Brute Force¶

У розгортаннях з інтернетом атаки brute force на паролі користувачів є дуже поширеними, і не слід нехтувати цією загрозою для серверів 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 =

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

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

[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, щоб заблокувати доступ до всіх екранів вибору та керування базами даних.

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

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

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

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

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

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

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

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

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

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

Odoo підтримує всі основні настільні та мобільні браузери, доступні на ринку, за умови, що вони підтримуються їхніми видавцями.

Ось підтримувані браузери:

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

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

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

Примітка

Починаючи з Odoo 13.0, підтримується ES6. Тому підтримку IE припинено.

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

Edit on GitHub