UA EN
Підтримка

Консолідація ІТ: як ізолювати організації у спільній платформі

Автор:

· Оновлено · 9 хв

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

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

Шість меж ізоляції, які не можна підміняти одна одною

  • Дані: окремий instance, logical database, schema, таблиці, рядки, файли й резервні копії мають різні межі доступу та відновлення.
  • Прикладна авторизація: автентифікована ідентичність повинна надійно визначати tenant context для кожного запиту, фонової задачі, export і звіту.
  • Workload і мережа: Namespace, RBAC та NetworkPolicy керують різними площинами Kubernetes і не замінюють захист даних.
  • Ресурси: CPU, пам’ять, I/O, з’єднання й concurrency потребують окремих бюджетів та спостережуваності.
  • Операції: backup, restore, видалення, retention, аудит і реагування на інциденти повинні зберігати tenant boundary.
  • Governance і комерційна модель: стандарти, законодавчі вимоги, контракти та ліцензії є окремим шаром, а не властивістю RLS чи Kubernetes.

Silo, bridge і pool: що саме відокремлює кожна модель

Для PostgreSQL AWS окремо описує silo, bridge з окремими logical databases, bridge з окремими schemas і pool зі спільними таблицями. Виділений instance або cluster створює найсильнішу межу для ресурсів і відмов. Окрема database у спільному instance залишається логічною конструкцією та ділить із сусідами CPU, I/O і failure domain. Schema-per-tenant відокремлює простір об’єктів у спільній database. Pool використовує спільну schema, tenant key і політики доступу до рядків.

Моделі можна комбінувати: більшість tenant’ів розмістити в pool, а високоризиковий або ресурсомісткий tenant — в окремому shard, database чи deployment stamp. Тому рішення приймають для конкретного workload і threat model.

Ілюстративне порівняння меж у мультитенантному сховищі
Модель Межа даних Що залишається спільним Операційні наслідки
Silo: instance або cluster для tenant Виділені database resources; за потреби — повний deployment stamp Залежить від хостингу: фізична інфраструктура, control plane або сервіси керування можуть бути спільними Сильніша межа ресурсів і відмов, але більше provisioning, patching, monitoring і витрат
Bridge: logical database або schema для tenant Окремі database чи schema objects у спільному instance Compute, I/O, instance lifecycle і часто backup/PITR boundary Потрібні tenant mapping, автоматизовані міграції та перевірена процедура export/restore
Pool: shared schema з tenant key і RLS Політики доступу до рядків та application-enforced tenant context Таблиці, schema rollout, compute, I/O і значна частина операцій Вища щільність ресурсів, але більший blast radius помилки policy або tenant context

RLS працює лише разом із надійним tenant context

Row-Level Security застосовує політики доступу до рядків на основі контексту, який система передає СКБД або серверному шару даних. Tenant ID не можна довіряти лише тому, що він надійшов у параметрі запиту: його пов’язують з автентифікованою ідентичністю та поширюють на всі downstream-виклики.

У PostgreSQL native RLS виконує database engine. Власник таблиці зазвичай обходить політики, якщо не ввімкнено FORCE ROW LEVEL SECURITY, а superuser і роль із BYPASSRLS обходять їх завжди. Якщо tenant context зберігається у session variable, connection pool має встановлювати й очищати його в контрольованій transaction boundary, інакше контекст попереднього запиту може потрапити до наступного.

Негативні тести мають охоплювати не лише звичайний UI, а й background jobs, імпорт, export, пошук, звіти, кеш, адміністративні операції, міграції та прямі інтеграції. Один непокритий шлях доступу руйнує всю логічну межу.

ISO/IEC 27017:2026 і привілейований доступ

ISO/IEC 27017:2026 надає guidance щодо впровадження засобів контролю безпеки для постачальників і користувачів cloud services. Він поширюється на public, private та hybrid cloud і допомагає визначити розподіл відповідальності. Стандарт не задає конкретної архітектури RLS, RBAC або Kubernetes: controls добирають за оцінкою ризиків і законодавчими, регуляторними та договірними вимогами.

Стандарт також не встановлює універсальної вимоги, за якою platform administrator ніколи не може мати доступу до tenant data. Привілейований доступ мінімізують, формально визначають і контролюють: least privilege, separation of duties, MFA, погодження, just-in-time або break-glass access і повний аудит дій. Audit records можуть бути фізично спільними, якщо мають tenant attribution, захист від несанкціонованої зміни, належний контроль доступу й retention.

Namespace — це область політик, а не готова security boundary

Kubernetes Namespace створює логічну межу для API-ресурсів і є областю застосування RBAC, ResourceQuota та NetworkPolicy. Сам по собі Namespace не виділяє CPU чи пам’ять, не захищає shared database і не ізолює мережу.

За відсутності NetworkPolicy pod’и за замовчуванням не ізольовані для ingress та egress. Політика спрацює лише тоді, коли network plugin її підтримує і виконує. Практичний baseline — default-deny ingress/egress, явні allow rules, окремі service accounts, мінімальні RBAC permissions, захист secrets і перевірка фактичної мережевої досяжності. Для ворожих tenant’ів або сильнішої compliance boundary можуть знадобитися виділені nodes, virtual control planes чи окремі clusters.

  • Namespace і RBAC: групують API-ресурси та обмежують дії identities у Kubernetes API.
  • NetworkPolicy: задає дозволений ingress/egress для pod’ів, якщо CNI забезпечує enforcement.
  • ResourceQuota і LimitRange: перший задає сукупний budget namespace, другий — default, minimum і maximum для окремих objects.
  • Requests і limits: перші декларують потребу для scheduling, другі задають верхню межу container resources, але не усувають усі сценарії node pressure.

Noisy neighbour, backup і життєвий цикл tenant

ResourceQuota обмежує сумарне споживання namespace, а container requests і limits впливають на scheduling та enforcement. Memory limit зменшує ризик неконтрольованого споживання одним workload, але не гарантує відсутності eviction або OOM на node. На рівні даних застосовують доступні в конкретному стеку tenant-aware connection pools, concurrency і query limits, workload management, CPU/I/O controls, rate limiting або виділення важких tenant’ів в окремі shards чи instances.

Ізоляція має працювати й під час відновлення. У PostgreSQL pg_dump може вибрати конкретну schema, але такий dump не обов’язково самодостатній через зовнішні залежності. Continuous archiving і PITR відновлюють database cluster, а не одну schema. Тому tenant-specific export, повний restore, point-in-time recovery, RPO/RTO та повернення даних у production потрібно тестувати як різні процедури.

  • Спостережуваність: збирати latency, errors, queueing, CPU, memory, I/O, connections і cost attribution у розрізі tenant.
  • Видалення та retention: визначити очищення primary storage, replicas, object storage, search indexes, caches, logs і backups відповідно до політики.
  • Ключі шифрування: окремий key per tenant застосовувати лише там, де це підтримує stack і виправдовує threat model або contract.
  • Відновлення: регулярно перевіряти backup integrity, tenant export/import, disaster recovery та відсутність міжtenantного змішування.

Tagged storage, on-premise і можливості UnityBase

Tagged storage approach, який AWS описав для multi-tenant configuration service, є конкретним technical how-to, а не універсальним стандартним pattern. У ньому key prefixes маршрутизують конфігурації між DynamoDB і Systems Manager Parameter Store. Оновлення без restart забезпечує не саме маркування ключів, а event-driven refresh через EventBridge і Lambda, cache invalidation та gRPC streaming.

В on-premise середовищі configuration service можна побудувати, наприклад, на Consul KV або іншому сховищі. Окремо потрібні authentication, tenant-scoped authorization, шифрування secrets, versioning, audit, rollback, backup і надійна доставка змін. Consul KV є базовим key-value store, а не прямим аналогом усіх можливостей Parameter Store. Для українського держсектору не слід виходити з припущення про загальну заборону public cloud: чинні правила передбачають закупівлю та використання cloud і data-centre services, а конкретне рішення залежить від категорії інформації, вимог до захисту, ризиків, безперервності, провайдера й договору.

UnityBase надає users, groups, roles, entity-level security, RLS, ACL/aclRls, attribute-level security та audit trail. Загальні entity mixins rls і aclRls додають server-side умови до ORM operations. Окремо документація UnityBase EE для PostgreSQL multitenancy описує native PostgreSQL RLS: tenant context передається через ub.tenantID під час connection context, а multitenancy instance має бути налаштований під non-owner database role. Owner-based administration instance бачить дані всіх tenant’ів, тому цей привілейований шлях потребує окремого контролю й аудиту. Ці механізми можуть підтримувати логічну tenant isolation для рішень на кшталт Megapolis.DocNet і Scriptum.DMS, але результат залежить від повноти policies, усіх access paths, database roles, privileged bypass і негативних тестів. Ліцензійний ефект визначають умови конкретної поставки.

Поширені питання

Коли обирати schema-per-tenant замість shared schema з RLS?

Schema-per-tenant може бути доречною, коли потрібні окремий простір об’єктів, tenant-specific розширення або зручніший логічний export. Вона не гарантує незалежного backup чи point-in-time restore: залежності між схемами, granularity резервування та процедуру відновлення потрібно перевіряти для конкретної СКБД.

Як зменшити ефект «галасливого сусіда» у спільній платформі?

На рівні Kubernetes поєднують ResourceQuota для сумарного бюджету namespace, requests і limits для контейнерів та, за потреби, LimitRange. На рівні даних застосовують tenant-aware пули з’єднань, concurrency і query limits, workload management та метрики за tenant. Важкі або критичні потоки іноді виносять в окремий shard чи instance.

Чому Kubernetes Namespace недостатньо для ізоляції tenant’ів?

Namespace групує API-ресурси й задає область для RBAC, ResourceQuota та NetworkPolicy, але сам не блокує мережевий трафік і не захищає спільну базу даних. Потрібні default-deny NetworkPolicy з CNI, який їх виконує, окремі service accounts, контроль workload і RLS або інша межа доступу до даних.

Джерела

Теги: #Хмарні рішення #UnityBase #Державний сектор #Системна інтеграція