UnityBaseDefense — не теоретичний проєкт і не результат маркетингового брифу. Це інженерна відповідь на цілком конкретні події останнього десятиліття, які змусили світ переглянути базові уявлення про довіру до інформаційних систем.
На початку 2010-х кібербезпека перестала бути дисципліною про «віруси на робочих станціях». Окремі інциденти показали, що йдеться про системний ризик для критичної інфраструктури держав.
У 2010 році Stuxnet продемонстрував, що складна шкідлива програма може фізично пошкодити промислове обладнання — газові центрифуги збагачення урану в Ірані. Це був перший публічний приклад, коли кіберзброя досягла наслідків у фізичному світі. До цього моменту галузь промислової автоматизації трималася на припущенні, що ізольована мережа — достатній захист. Stuxnet показав, що це припущення помилкове.
У 2013 році витоки колишнього підрядника АНБ США сформували нове розуміння: масові сервіси автентифікації, корпоративні директорії, протоколи маршрутизації — все це потенційні точки компрометації. Виявилось, що навіть стандартизовані механізми криптографічного захисту можуть мати закладки на рівні специфікації.
У 2015–2016 роках атаки на українську енергетичну інфраструктуру — спочатку на «Прикарпаттяобленерго», потім на «Укренерго» — стали першими публічно задокументованими випадками успішного відключення електромережі через кібератаку. Це довело: загроза не теоретична, не лабораторна, а реалізована на критичній інфраструктурі європейської країни.
Кожен з цих випадків став точкою, після якої архітектурні припущення «довіреного периметру» вже не можна було обстоювати.
Через скомпрометоване оновлення українського бухгалтерського пакету M.E.Doc шкідлива програма поширилась світом. Maersk втратив операції контейнерної логістики в усіх портах. Merck зупинив виробництво вакцин. Збитки FedEx, Mondelez, Reckitt Benckiser. Сумарні оцінки — понад $10 млрд. Урок: легітимний канал постачання ПЗ став вектором атаки. Довіра до цифрового підпису виявилась недостатнім бар'єром.
У березні–червні 2020 року атакуючі впровадили зловмисний код у цифрово підписані оновлення SolarWinds Orion — продукту моніторингу IT-інфраструктури. 18 000+ організацій встановили оновлення, включно з федеральними агенціями США. Витрати постраждалих компаній — у середньому 11% річної виручки. Урок: підрядник з legitimate digital signature — це нова поверхня атаки. «Trusted vendor» більше не означає «безпечно».
У грудні 2021 в Apache Log4j виявили CVE-2021-44228 — змога виконати довільний код через звичайний log-запис. Бібліотека була вбудована в мільйони застосунків, від мінорних SaaS-сервісів до AWS, Apple iCloud, Steam. Тиждень — і атаки на повну ширину інтернету. Урок: сучасний застосунок — це не код одного вендора, а супутній ланцюг сотень open-source залежностей. Безпека периметра нічого не значить, якщо вразливість всередині самого застосунку.
Уразливість у MOVEit Transfer — комерційному рішенні для безпечного передавання файлів. Атакуюча група Clop проексплуатувала її проти 2 600+ організацій, включно з державними агентствами США, університетами, медичними мережами, банками. Понад 90 мільйонів людей постраждали від витоку персональних даних. Урок: «secure file transfer solution» сам по собі може стати вектором атаки. Жоден продукт не уникне ролі цілі — питання лише в тому, чи готова архітектура мінімізувати наслідки.
Спільний знаменник. Жоден з цих інцидентів не був результатом «слабкого паролю» чи «відсутнього антивірусу». Усі — результат архітектурних припущень про довіру: до постачальника, до цифрового підпису, до open-source залежності, до «корпоративного периметру». Саме ці припущення Zero Trust як парадигма пропонує відмінити.
Стандарти йшли за реальністю, а не навпаки. Те, що практики вважали правильним архітектурним підходом, поступово ставало законом.
Перший формальний стандарт Zero Trust від Національного інституту стандартів США. Сім тенетів: усі джерела даних — ресурси; уся комунікація захищена; доступ — per-session; рішення про доступ — динамічне; цілісність активів моніториться; автентифікація і авторизація — на кожен запит; стан безпеки збирається і використовується.
Cybersecurity and Infrastructure Security Agency формалізує модель зрілості Zero Trust. П'ять стовпів: Identity, Devices, Networks, Applications & Workloads, Data. Чотири рівні: Traditional → Initial → Advanced → Optimal. Стає референсом для федеральних агенцій США та практик за межами США.
Європейський Союз приймає директиву 2022/2555 — наступник NIS1 (2016). Article 21 — 10 обов'язкових заходів управління кіберризиками. Покриває 18 критичних секторів. Штрафи до €10 млн або 2% річного обороту. Чинна з 18.10.2024.
Регламент 2024/2847 вводить обов'язкові вимоги до кібербезпеки для всіх продуктів з цифровими елементами на ринку ЄС. Чинний з 10.12.2024, повна дія з 11.12.2027. CE-маркування за результатами compliance assessment стає обов'язковим.
Український вимір. Паралельно з міжнародними процесами розвивається національна нормативна база — НД ТЗІ 2.5-004-99 (критерії оцінювання, сім рівнів гарантій Г-1…Г-7), НД ТЗІ 2.7-010-09 (методика оцінювання), НД ТЗІ 3.6-006-24 (новий базовий профіль безпеки, 2024). Український рівень Г-3 у міжнародному вимірі відповідає EAL 4 за ISO/IEC 15408 (Common Criteria).
Команда, яка зараз розвиває UnityBaseDefense, працює над захищеними інформаційними системами національного масштабу понад двадцять років. За цей час було реалізовано низку проєктів, де базові вимоги — не «зручний інтерфейс», а одночасна підтримка 50 000+ одночасних користувачів, гранулярна авторизація на рівні окремого поля запису, незмінний журнал дій, шифрування даних у БД, ЕЦП на критичних транзакціях.
Цей досвід почав формуватись задовго до того, як з'явились такі терміни як «Zero Trust» чи «assume breach». Першими викликами були не атаки супротивника, а суто інженерні обмеження: як зробити систему працездатною на каналі 64 Кбіт/с, як забезпечити одночасну роботу з трьома різними СКБД (MS SQL, Oracle, DB2), як побудувати клієнт, що працює однаково на Windows, Linux, macOS і мобільних пристроях. Відповіді на ці питання — stateless-архітектура, тонкий клієнт, абстракція над БД — згодом виявились саме тими архітектурними рішеннями, які стандарти Zero Trust сформулюють у 2020 році.
У 2010-х команда отримувала експертні висновки Держспецзв'язку — спершу на рівні Г-2, згодом Г-3. У міжнародній практиці це відповідає рівню EAL 4 за Common Criteria — рівню, на якому оцінюються комерційні продукти безпеки рівня enterprise. Це не було самоціллю — це було побічним наслідком чесного інженерного підходу: коли система проєктується для роботи з даними обмеженого доступу, вимоги до неї ставлять не маркетологи, а нормативний документ і експерт регулятора.
До 2020 року, коли NIST опублікував SP 800-207, у команди вже було накопичено п'ять років практики розробки систем за принципами, які стандарт лише формалізував. Це не означає, що команда «винайшла Zero Trust раніше за NIST» — це означає, що інженерна потреба була настільки очевидною з реальних проєктів, що рішення приходили природним шляхом, без посилань на доктринальні документи.
Більшість сучасних реалізацій Zero Trust — це надбудова над застосунком: ZTNA, IAM, Identity-Aware Proxy, Privileged Access Management. Це корисні інструменти, але вони відповідають на питання «як впустити правильного користувача до застосунку», а не на питання «як застосунок поводиться зі своїми даними після того, як користувач уже всередині».
Інциденти останнього десятиліття — SUNBURST, Log4Shell, MOVEit — мали одну спільну рису: атакуючий уже був усередині периметра. Або через довірений канал оновлень, або через вбудовану open-source залежність, або через продукт, якому організація довіряла за визначенням. Жодна ZTNA-надбудова цього не зупиняє.
Звідси інженерний висновок: безпека має бути властивістю самого застосунку, а не зовнішнього шару. Кожен запит, навіть якщо він уже «всередині», має бути автентифікованим і авторизованим. Кожна транзакція, що змінює стан, має бути потенційно підписана ЕЦП. Кожен запис у БД має нести персоналізовану належність користувачу. Кожна дія має фіксуватися в незмінному журналі, який атакуючий не може відредагувати, навіть отримавши адміністративні права.
Саме ці принципи закладені в архітектуру UnityBaseDefense — не як «модулі безпеки», а як базові інваріанти платформи. Не можна побудувати на UnityBaseDefense застосунок, у якому користувач якось «опиняється всередині» і отримує неконтрольовану свободу дій. Така свобода технічно неможлива через сам спосіб, у який платформа обробляє запити.
UnityBaseDefense — це інженерна спроба зробити «довіряти за замовчуванням» технічно неможливим на рівні платформи. Не складно. Не дорого. Не за бажанням. А неможливо.
Дивіться, як принципи з цієї історії втілені в архітектурі платформи і регуляторних відповідностях.