Консолідація ІТ-інфраструктури: ізоляція даних без дублювання ліцензій
При об'єднанні ІТ-інфраструктури кількох організацій виникає дилема: будувати окремі системи для кожного відомства чи створювати спільну платформу. Мультиорендність (multi-tenancy) усуває потребу в дублюванні інфраструктури, але вимагає суворої ізоляції даних та гнучкого налаштування прав для локальних адміністраторів без зупинки всієї системи.
Спроба об'єднати цифрові сервіси кількох відомств часто завершується або створенням десятків ізольованих копій інфраструктури, що спалює бюджети на ліцензії, або хаотичним злиттям баз даних, де один користувач бачить документи сусідньої організації. Вибір архітектури вимагає балансу між фізичною та логічною ізоляцією.
Три моделі зберігання даних у мультитенантних архітектурах
Проєктування спільної платформи для кількох організацій починається з вибору моделі збереження даних. Архітектурні концепції виділяють три основні підходи до організації баз даних: окрема база даних для кожного орендаря (database-per-tenant), окремі схеми в спільній базі даних (schema-per-tenant) та спільна база даних зі спільною схемою (shared database, shared schema).
Модель з окремими базами даних забезпечує найвищий рівень фізичної ізоляції. Проте вона є найбільш витратною з точки зору використання ресурсів та адміністрування. Модель з окремими схемами в межах однієї бази даних є компромісним варіантом, який знижує витрати на ліцензування, але зберігає логічний розподіл об'єктів.
Найбільш економічно ефективною є модель спільної бази даних зі спільною схемою. Логічне розділення даних різних орендарів у такій схемі забезпечується за допомогою технології Row-Level Security (RLS). RLS на рівні СКБД автоматично фільтрує рядки таблиць залежно від контексту сесії користувача. Проте RLS забезпечує саме логічне, а не фізичне розділення даних.
| Критерій порівняння | Окрема база даних (Database-per-tenant) | Окремі схеми (Schema-per-tenant) | Спільна база та схема з RLS (Shared database) |
|---|---|---|---|
| Рівень ізоляції | Максимальний (фізичний) | Середній (логічний на рівні схем) | Мінімальний (логічний на рівні рядків) |
| Ефективність використання ресурсів | Низька (високі витрати на ліцензії) | Середня (спільний інстанс СКБД) | Максимальна (оптимальне використання пулу) |
| Складність оновлення схеми даних | Висока (потрібна послідовна міграція всіх БД) | Середня (міграція схем у межах однієї БД) | Низька (одноразове оновлення спільної схеми) |
Застосування стандарту ISO/IEC 27017 для розмежування доступу
При проєктуванні мультитенантної архітектури для публічного або освітнього сектору орієнтиром безпеки виступає міжнародний стандарт ISO/IEC 27017. Цей стандарт надає рекомендації щодо засобів контролю безпеки інформації, які застосовуються до надання та використання хмарних послуг. Він описує методологічні вимоги та розмежування ролей між провайдером послуг і клієнтом.
Стандарт не містить готових технічних інструкцій чи готового коду для реалізації ізоляції. Він надає фреймворк для розподілу обов'язків. Технічна реалізація (RLS, RBAC) є відповідальністю архітектора, який має відобразити ці вимоги у коді, гарантуючи, що адміністратор платформи не має доступу до даних орендарів.
- Розподіл обов'язків Проєктування чіткої межі між адмініструванням платформи та керуванням даними конкретного орендаря.
- Логічне розмежування Застосування механізмів RLS для ізоляції даних різних організацій у спільному сховищі.
- Аудит дій користувачів Створення ізольованих журналів аудиту для кожного орендаря.
- Керування життєвим циклом Забезпечення процедури безпечного видалення даних організації при виході з платформи.
Чому Kubernetes Namespaces не захищають дані на рівні коду
Сучасні спільні платформи часто розгортають у контейнеризованих середовищах під керуванням Kubernetes. Використання просторів імен (Namespaces) та рольового доступу (RBAC) є стандартом для ізоляції ресурсів на рівні оркестрації. Вони розділяють обчислювальні ресурси різних організацій у межах одного фізичного кластера.
Проте Kubernetes Namespaces забезпечують ізоляцію лише на рівні оркестрації та керування (control plane). Вони не здатні захистити дані від витоку, якщо вразливість міститься в самому прикладному коді або якщо додаток використовує спільну базу даних без належного налаштування права доступу на рівні СКБД.
Стратегії боротьби з проблемою «галасливого сусіда»
У мультитенантних середовищах виникає проблема «галасливого сусіда» (noisy neighbor) — ситуація, коли одна організація через пікове навантаження споживає надмірну кількість ресурсів, що призводить до деградації продуктивності для інших користувачів платформи.
Для запобігання цьому явищу архітектори використовують комбінований підхід. На рівні бази даних впроваджують ліміти споживання ресурсів та обмежують кількість з'єднань у пулі для кожного орендаря. На рівні оркестрації Kubernetes застосовують квоти ресурсів (ResourceQuotas) для кожного простору імен, що обмежує максимальне споживання процесорного часу та пам'яті окремими контейнерами.
- Ліміти пулу з'єднань Обмеження максимальної кількості одночасних підключень до СКБД для кожного орендаря.
- Квоти процесорного часу Налаштування CPU limits у Kubernetes для запобігання монополізації обчислювальних потужностей.
- Обмеження пам'яті Встановлення Memory limits для контейнерів, щоб уникнути OOM-помилок у сусідніх сервісах.
- Пріоритезація трафіку Використання механізмів QoS для гарантованого обслуговування критичних запитів.
Динамічна конфігурація та адаптація патерну Tagged Storage для On-Premise
Для забезпечення гнучкості спільної платформи кожна організація повинна мати можливість налаштовувати власні бізнес-процеси без перезавантаження всієї системи. Для вирішення цього завдання використовують патерн Tagged Storage, який динамічно зберігає та оновлює конфігурації різних орендарів у реальному часі (zero-downtime).
У хмарних середовищах цей патерн реалізують за допомогою специфічних сервісів (наприклад, AWS Systems Manager Parameter Store). Проте для українського державного сектору використання публічних хмар часто обмежене. При перенесенні патерну Tagged Storage на власну інфраструктуру (on-premise) архітектори змушені розробляти власні аналоги хмарних сервісів для динамічної дистрибуції конфігурацій, використовуючи інструменти на кшталт Consul або Redis для централізованого зберігання параметрів орендарів.
Компанія IQusion розв'язує проблему консолідації інфраструктури за допомогою впровадження систем Megapolis.DocNet та Scriptum.DMS на базі вітчизняної low-code платформи UnityBase. Завдяки вбудованій підтримці Row-Level Security (RLS) та гнучкому розмежуванню доступу (RBAC, ACL), UnityBase забезпечує створення єдиних високопродуктивних платформ для багатьох організацій із суворою ізоляцією даних без необхідності дублювання ліцензій.
Поширені питання
Коли варто обрати модель schema-per-tenant замість shared database?
Модель schema-per-tenant є компромісним варіантом, коли потрібен вищий рівень логічної ізоляції, ніж RLS, але бюджет не дозволяє розгортати окремі бази даних. Вона підходить для організацій, які вимагають окремого резервного копіювання своїх даних, але готові ділити спільний інстанс СКБД.
Як практично вирішити проблему «галасливого сусіда» при консолідації систем?
Для вирішення проблеми «галасливого сусіда» на рівні бази даних впроваджують ліміти споживання ресурсів та обмежують кількість з'єднань у пулі для кожного орендаря. На рівні оркестрації Kubernetes використовують квоти ресурсів (ResourceQuotas) у межах окремих просторів імен (Namespaces).
Чому ізоляції на рівні Kubernetes Namespaces недостатньо для захисту даних?
Kubernetes Namespaces забезпечують ізоляцію виключно на рівні оркестрації та керування ресурсами кластера (control plane). Вони не захищають дані на рівні прикладного коду або баз даних, тому вимагають додаткового налаштування RLS або інших механізмів на рівні СКБД.
