Мова: Українська
У цій статті пояснюється, чому автономний сервер ActivityInfo не підтримує дворівневе розгортання.
Ми розробили наш автономний сервер як потужну, надійну та безпечну платформу, яку легко встановити та обслуговувати. Для цього ми використовуємо архітектуру з одним екземпляром. Такий дизайн найкраще підходить для організацій, особливо для тих, що мають обмежені ІТ-ресурси.
Багато ІТ-стандартів рекомендують дворівневу архітектуру, де застосунок розміщено на одному сервері, а база даних (наприклад, MySQL або PostgreSQL) — на іншому. Хоча ця модель підходить для багатьох застосунків, для ActivityInfo ми обрали інший дизайн. У цій статті пояснюється наш дизайн та способи захисту вашого розгортання на одному сервері.
Чому автономний сервер не використовує дворівневу архітектуру
Дворівнева архітектура може підвищити безпеку, розмістивши базу даних на окремій (віртуальній) машині за брандмауером. Однак ця модель зробила б ActivityInfo повільнішим і складнішим в обслуговуванні. Ми відмовилися від окремого сервера бази даних з двох причин:
Функції, що інтенсивно використовують дані, працюють повільно на окремих серверах
Багато функцій ActivityInfo, як-от сканер дублікатів записів, інтенсивно використовують дані. Вони працюють, виконуючи складні порівняння багатьох записів.
У дворівневій моделі застосунку довелося б завантажувати весь набір даних через мережу з сервера бази даних для виконання цього аналізу. Така велика передача даних створює затримку в мережі, що сповільнює роботу застосунку та використовує багато пропускної здатності. Продуктивність цих функцій була б набагато гіршою, особливо для клієнтів з великими базами даних.
Один сервер простіше обслуговувати
Ключова мета нашого автономного сервера — простота для команд, які не можуть виділити штатного співробітника для його управління. Налаштування з двома серверами вимагає конфігурації, моніторингу та обслуговування двох серверів, їхніх операційних систем, мережевих правил між ними та окремих облікових записів користувачів бази даних. Ця складність суперечить нашій меті створення рішення, що не потребує значного обслуговування, і підвищує ризик неправильної конфігурації.
Дизайн з одним сервером
Автономний застосунок ActivityInfo — це єдиний, самодостатній Java-застосунок. Цей єдиний процес включає в себе як веб-сервер, так і вбудований рушій бази даних SQLite.
Вбудована база даних — це бібліотека, яка є частиною застосунку ActivityInfo. Вся ваша база даних зберігається в одному файлі на тому ж сервері.
Ця модель з одним сервером має кілька переваг:
- Висока продуктивність: Застосунок безпосередньо взаємодіє з файлом своєї бази даних на локальному диску, тому доступ до даних є швидким. Це дозволяє уникнути мережевих затримок і забезпечує ефективну роботу складних, насичених даними функцій, таких як сканер дублікатів, навіть на великих наборах даних.
- Простота: Вам потрібно лише встановити, налаштувати, контролювати та створювати резервні копії одного компонента. Це зменшує складність і ймовірність помилок конфігурації.
- Надійність: Завдяки меншій кількості компонентів і відсутності мережевого з'єднання між застосунком та його даними, точок збою стає менше.
Порівняння з нашим хостинговим сервісом
Наш хостинговий сервіс на ActivityInfo.org використовує багаторівневу архітектуру. Цей сервіс підтримується повною командою інженерів та цілодобовим моніторингом, тому може дозволити собі бути більш складним. Ми використовуємо розширене, багаторівневе кешування, щоб подолати вплив багаторівневої архітектури на функції, що інтенсивно використовують дані. Перегляньте наш вебінар Представляємо автономну версію ActivityInfo для порівняння цих двох продуктів.
Захист вашого автономного сервера ActivityInfo
Архітектура з одним сервером може бути такою ж безпечною, як і дворівневе розгортання, якщо її правильно налаштувати. Якщо у вас немає штатної команди для управління вашим сервісом ActivityInfo, розгортання на одному сервері, ймовірно, буде більш безпечним, оскільки це знижує ризик помилки конфігурації.
Ось кроки, які ви можете зробити для захисту вашого автономного сервера:
- Дозволити доступ лише до портів 80 (http) та 443 (https). Це єдині порти, які прослуховує сервер ActivityInfo, а запити http (незахищені) будуть автоматично перенаправлені на https. SQLite є вбудованою системою баз даних і не підтримує мережеві з'єднання.
- Вимкніть доступ до сервера через SSH або RDP, або обмежте доступ через SSH до «бастіонного» хоста у вашій власній мережі.
- Оберіть мінімальну операційну систему для сервера ActivityInfo, таку як Alpine Linux, Ubuntu Minimal або ОС, оптимізовану для контейнерів від Google Cloud, щоб мінімізувати поверхню атаки (віртуальної) машини.
- Увімкніть автоматичні оновлення операційної системи.
- Розгляньте можливість розгортання брандмауера веб-застосунків (WAF) перед сервером ActivityInfo. Відомо, що WAF від Cloudflare добре працює з ActivityInfo.
Наведені вище пункти є важливими кроками, які слід зробити при розгортанні саме автономної версії ActivityInfo. Однак найважливіші ризики для будь-якої бази даних ActivityInfo походять від автентифікованих користувачів:
- Налаштуйте єдиний вхід (SSO), щоб зменшити ризик «втоми від паролів» і гарантувати, що співробітники втратять доступ до бази даних, коли покинуть вашу організацію.
- Налаштуйте ролі для ваших баз даних, дотримуючись принципу найменших привілеїв.