Модель нульової довіри (Zero Trust) остаточно перетворилася з теоретичної концепції на обов'язковий архітектурний стандарт для забезпечення стійкості публічного та корпоративного секторів. Традиційний підхід до кібербезпеки, заснований на захисті зовнішнього периметра, виявився нездатним протистояти сучасним цільовим атакам. Згідно з Cisco Cybersecurity Readiness Index 2025, оцінка зрілості організацій тепер базується на п'яти ключових стовпах, серед яких Identity Intelligence (інтелектуальна ідентифікація) та Machine Trustworthiness (довіра до пристроїв) є першочерговими факторами.
Головна проблема полягає в тому, що багато ІТ-керівників досі плутають базове впровадження двофакторної автентифікації (MFA) із комплексною перебудовою архітектури безпеки. На практиці ж, якщо зловмисник компрометує один обліковий запис, у традиційній моделі він часто отримує можливість безперешкодного переміщення мережею через відсутність динамічного контролю доступу. Справжній перехід до Zero Trust вимагає оцінки поточної зрілості інфраструктури та послідовного впровадження контролю на рівні ідентичностей і безпосередньо даних.
Чому модель зрілості CISA стала еталоном для українського B2G та Enterprise
Оцінка готовності інфраструктури потребує структурованого підходу. Модель зрілості Zero Trust від CISA пропонує чіткий шлях міграції. Цей фреймворк ідеально узгоджується з оновленим стандартом NIST Cybersecurity Framework (CSF) 2.0, який ввів нову функцію «Govern» (Управління). Згідно з нею, кібербезпека є фундаментальною частиною корпоративного управління та оцінки ризиків, а не просто технічним завданням.
Для українських підприємств (Enterprise) та державних установ (B2G) критично важливо розпочати перебудову з двох фундаментальних стовпів: Identity (Ідентифікація) та Data (Дані). Перехід від базового («Traditional») стану до високого рівня зрілості («Advanced» або «Optimal») передбачає відмову від статичних правил на користь динамічної верифікації кожного запиту з дотриманням принципу мінімальних привілеїв (Least Privilege).
Стовп 1: Identity (Ідентифікація) — від простого пароля до безперервної верифікації контексту
У моделі Zero Trust ідентичність стає центром управління доступом. Стандарт NIST SP 800-63 (Digital Identity Guidelines) визначає чіткі рівні гарантії автентифікації (AAL), наголошуючи, що використання стійких до фішингу багатофакторних методів є базовою вимогою для критичних систем.
Проте просунута зрілість вимагає більшого. Замість одноразової перевірки на вході впроваджуються динамічні політики умовного доступу (Conditional Access). Система аналізує контекст кожного запиту перед наданням доступу:
- Стан пристрою: чи відповідає робоча станція політикам безпеки (встановлені оновлення, активний антивірус).
- Мережевий контекст: чи не є запит аномальним за локацією або часом.
- Управління життєвим циклом: автоматизація онбордингу та миттєве відкликання прав при звільненні для уникнення «завислих» доступів, які збільшують радіус ураження.
Стовп 2: Data (Дані) — чому шифрування каналу недостатньо і як працює Row-Level Security (RLS)
Традиційний захист даних обмежується шифруванням під час передачі та на дисках. Це не рятує від зловмисника або інсайдера з легітимними правами. Щоб досягти рівня зрілості «Advanced» та «Optimal», захист необхідно інтегрувати безпосередньо в архітектуру прикладного ПЗ.
- Row-Level Security (RLS): Механізм, що обмежує доступ до конкретних рядків бази даних. Навіть маючи доступ до таблиці, користувач бачить лише ті записи, які необхідні йому для виконання посадових обов'язків.
- Access Control Lists (ACL): Гранульовані списки контролю доступу на рівні окремих файлів або об'єктів системи.
- Динамічний контроль: Надання прав доступу в реальному часі на основі контексту (чутливість даних, статус документа, рівень допуску співробітника).
Архітектурний підхід замість «коробкових» рішень: роль платформи UnityBase у побудові Zero Trust
Впровадження Zero Trust — це вибір правильного технологічного фундаменту. Жоден «коробковий» продукт не зробить організацію сумісною з цією моделлю без архітектурних змін. Системи документообігу, державні реєстри та корпоративні портали мають проектуватися з урахуванням концепції «безпека за замовчуванням».
Прикладом такого архітектурного підходу є low-code платформа UnityBase (спільна розробка компаній консорціуму Intecracy Group, де ключовим розробником виступає InBase). Вона є full-stack JavaScript платформою для enterprise-застосунків, де безпека закладена на рівні єдиної доменної моделі метаданих. Системи, побудовані на цій платформі (наприклад, Megapolis.DocNet або Scriptum), використовують її вбудовані механізми:
- RLS та атрибутний контроль доступу: Правила обмеження даних за рядками декларуються у метаданих і застосовуються на рівні ORM-шару, блокуючи несанкціонований доступ незалежно від способу звернення до системи.
- Наскрізний аудит (Audit Trail): Детальне логування читання та зміни даних, що є обов'язковим для своєчасного виявлення аномальної поведінки.
Локальне розгортання (On-Premises) як критична вимога для Defence та критичної інфраструктури
Для українських установ сектору оборони та критичної інфраструктури публічні хмарні сервіси часто не відповідають жорстким регуляторним вимогам. Повний контроль над місцем зберігання даних і трафіком робить розгортання On-Premises не просто альтернативою, а необхідністю.
Для високонавантажених систем та проектів із підвищеними вимогами безпеки офіційна документація UnityBase рекомендує комерційні редакції Enterprise (EE) або Defence (DE). Редакція Defence, зокрема, надає розширені можливості автентифікації на базі ключів, підтримку інтеграції з сервісами статусів сертифікатів (CRL/OCSP) та інструменти контролю цілісності серверних модулів. Це дозволяє організаціям будувати суверенну інфраструктуру Zero Trust локально, не покладаючись на зовнішні хмарні сервіси.
Шкала оцінки зрілості Zero Trust за напрямками Identity та Data (CISA Framework)
| Напрямок (Pillar) | Рівень Traditional | Рівень Advanced | Рівень Optimal |
|---|---|---|---|
| Identity | Паролі або статичний MFA; обмежена інтеграція між сховищами облікових записів; ручний онбординг. | Контекстно-залежний MFA (локація, пристрій); інтегровані IDP (Identity Providers); автоматизований життєвий цикл облікових записів. | Безперервна динамічна верифікація кожного запиту; аналіз поведінки користувача (UEBA) в реальному часі; безпарольна автентифікація. |
| Data | Дані зберігаються у незашифрованому вигляді або шифруються лише на диску; доступ регулюється широкими мережевими правами. | Шифрування даних під час передачі та зберігання; доступ регулюється на рівні файлів/таблиць за допомогою ACL. | Динамічний доступ до даних на основі контексту; гранульоване розмежування на рівні рядків (RLS/ABAC); автоматичне маркування та класифікація даних. |
Послідовна оцінка ІТ-середовища за цими критеріями допомагає архітекторам безпеки виявити вразливі місця і спланувати міграцію. Zero Trust — це безперервний процес управління ризиками, який потребує надійних технологічних інструментів та грамотної архітектури.
Поширені питання
Як оцінити рівень зрілості ІТ-інфраструктури за моделлю CISA?
Оцінка проводиться за п'ятьма стовпами (Identity, Devices, Networks, Applications, Data) шляхом порівняння поточних засобів контролю зі шкалою CISA. Для досягнення зрілості необхідно перейти від статичного захисту периметра до динамічної верифікації кожного запиту і контексту.
Яка різниця між рольовим доступом (RBAC) та динамічним доступом на рівні рядків (RLS)?
RBAC визначає загальні дозволи (наприклад, право читати таблицю 'Контракти' для ролі 'Менеджер'). RLS працює на більш гранульованому рівні, обмежуючи доступ до конкретних рядків цієї таблиці. Завдяки RLS менеджер зможе бачити лише ті контракти, які належать його підрозділу, що зменшує ризики при компрометації облікового запису.
Чи можна побудувати Zero Trust архітектуру на базі on-premises рішень без використання хмарних сервісів Microsoft чи Google?
Так, модель Zero Trust не прив'язана до публічних хмар. Суверенна архітектура будується локально (On-Premises) з використанням платформ, що підтримують гранульований контроль доступу, RLS, наскрізний аудит та інтеграцію із захищеними провайдерами ідентифікації (наприклад, використовуючи редакції Enterprise або Defence платформи UnityBase).
Коментар експерта