Zero Trust у середньому бізнесі: сегментація мережі, відповідність пристроїв і прагматичні дорожні карти замість маркетингових лозунгів

„Zero Trust“ на перший погляд виглядає як програма великого концерну. У багатьох компаніях середнього розміру це скоріше прагматична відповідь на зрослу реальність: віддалені філії, гібридні команди, доступи партнерів, хмарні сервіси, мобільні пристрої та паралельно з ними класичні серверні служби, ERP‑клієнти, файлові шари і спеціалізоване обладнання. Стара модель «всередині — довіряти, зовні — небезпечно» тут уже не спрацьовує — бо скомпрометований клієнт у внутрішній мережі часто знаходить занадто багато шляхів.

Zero Trust у середніх підприємствах означає тому насамперед: доступи не надаються автоматично за місцем у мережі, а визначаються на підставі ідентичності, стану пристрою (Gerätezustand, Device Compliance), контексту та мінімально необхідних прав. І: архітектуру будують так, щоб злом не перетворювався автоматично на масштабну пожежу.

Ця стаття відкидає модні словосполучення і зосереджується на трьох важелях, які на практиці дають найбільший ефект: сегментація мережі (хто куди може комунікувати?), Gerätezustand (Device Compliance) (який стан пристрою є передумовою?) та дорожні карти, що постачають у етапах, замість чекати ідеальної цільової картини. Фокус — на наслідках для експлуатації, адміністрації, корпоративного ПЗ, інтерфейсів і розгортання.

Що на практиці означає Zero Trust — і що ні

Щоб «Zero Trust» не стало проєкційною площиною, допомагає чітке робоче визначення. На практиці Zero Trust охоплює три принципи:

• Явна валідація: кожне рішення про доступ ґрунтується на сигналах (ідентичність, статус MFA, стан пристрою, ризик, чутливість цільової системи).
• Least Privilege (мінімально необхідні права): користувачі, сервіси й адміністратори отримують лише те, що їм реально потрібно для процесу — бажано з обмеженням по часу та з відстеженням.
• Assume Breach: архітектура та експлуатація виходять із того, що кінцева точка може бути скомпрометована. Мета — обмеження шкоди (containment), а не обіцянка «ми запобігаємо всьому».

Не мається на увазі: «усе заново», «тільки хмара», «ми повністю замінюємо LAN мікросегментацією» або «ми блокуємо все, поки бізнес‑підрозділи не здадуться». Zero Trust має працювати в повсякденності: сканери сканують, ERP‑клієнти працюють, інтерфейси функціонують, пакетні процеси запускаються вночі, і існує аварійний шлях для адміністрування.

Чому середні підприємства з Zero Trust часто просуваються швидше, ніж очікують

У середніх підприємствах шляхи прийняття рішень часто коротші, і менше одночасно конкуруючих ініціатив з безпеки. Водночас ресурси обмежені, а бізнес‑ПЗ має тривалі життєві цикли. Це поєднується, якщо заходи спрямовані на типові джерела ризику:

• Ланцюги шифрувальників (Ransomware‑Ketten): Phishing → скомпрометований клієнт → латеральний рух (наприклад SMB/RDP) → ідентичності/резервні копії/зберігання → шифрування.
• «Тіньові» доступи: забуті VPN‑акаунти, спільні сервісні облікові записи, партнерські доступи без відповідального власника, постійні права адміністратора.
• Legacy‑інтеграції: файлові шари як «інтеграційна шина», статичні IP‑білисті, відкриті порти без перевірки стану пристрою та без терміну дії.

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

Сегментація мережі як складова Zero‑Trust

Сегментація мережі — найвідчутніший вхід, оскільки вона безпосередньо обмежує латеральний рух. Йдеться про свідоме розділення областей систем, зазвичай через VLANs/VRFs (логічний поділ мережі на рівні комутаторів або маршрутизації) плюс правила фаєрвола між сегментами. Мета не в тому, щоб ізолювати кожну систему окремо, а створити зони з малою комунікацією, у яких доступні лише визначені протоколи та цілі.

Практичне цільове бачення: зони, що поєднують експлуатацію та безпеку

Реалістичне цільове бачення в організаціях зі сформованою інфраструктурою часто триступеневе і може бути розширене за потреби:

• Зона клієнтів: офісні клієнти, ноутбуки, мобільні пристрої. Звідси бажано не мати доступу до адміністративних протоколів і систем управління.
• Зона серверів/робочих навантажень: бізнес-додатки (ERP/CRM/портали), бази даних, інтеграційні сервіси, файлові сервіси. Доступ лише через визначені порти і бажано через шляхи додатків.
• Зона адміністрування/управління: ідентичність (наприклад Domain Controller/IdP), резервне копіювання, віртуалізація, моніторинг, управління мережею. Доступ лише з робочих станцій адміністраторів або через Bastion-Hosts, обмежено і протоколюється.

Це розділення не лише «мережеве». Воно є передумовою для того, щоб подальші контролі (Device Compliance, привілейований доступ, Service-to-Service-Absicherung) не були нівельовані плоскою Any-to-Any-доступністю.

Підводні камені: SMB, принтери/IoT та „тимчасово“ відкриті порти

Сегментація рідко зазнає невдач через комутатори або фаєрволи, натомість через невизначені потоки трафіку. Три типові патерни:

• SMB/Fileshares як інтеграційна шина: додатки записують файли в папки, партнери їх забирають, Excel-воркфлови звертаються до мережевих дисків. Сегментація змушує приймати рішення: які шляхи справді потрібні? Де доцільно перейти на SFTP/HTTPS, портали або Message Broker?
• Друк/Сканування/IoT: багатофункціональні пристрої, етикеткові принтери, сканери, виробниче обладнання часто спілкуються з кількома серверами. Такі пристрої мають бути в окремому сегменті з мінімальними, документованими винятками та чітким інвентарем.
• „Одного разу відкрито — завжди відкрито“: RDP, SQL-порти або WinRM відкривалися для проєкту і залишаються відкритими. Сегментація працює лише за наявності власників правил і терміну дії для винятків.

Сегментація зарекомендувала себе як програма змін: спочатку видимість (Netflow/Firewall-Logs), потім пілотні сегменти, а далі розгортання хвилями. Хто одразу запроваджує „Default Deny“ між усіма VLANs, спричиняє відмови та втрачає прийнятність.

Сегментація для корпоративного ПЗ, баз даних та інтеграцій

Для індивідуального корпоративного програмного забезпечення та процесно-орієнтованих рішень сегментація дає подвійний ефект: менший ризик і чіткіші експлуатаційні картини. Типові орієнтири:

• App-Server → База даних: лише необхідний порт БД, лише з визначених підмереж додатків; жодних клієнтських підключень безпосередньо до бази даних.
• Клієнти → Додаток: переважно HTTPS до веб-інтерфейсу або API, замість прямого доступу до внутрішніх сервісів або серверних файлових розшарувань.
• Інтеграційна зона: виділені системи для REST/SOAP/SFTP/Message Broker, з контрольованими шляхами в ERP/CRM і до партнерів.

Це робить видимими архітектурні питання, які інакше «ховаються» в мережі: fat clients, що безпосередньо звертаються до баз даних; пакетні процеси, яким потрібні адміністративні дозволи; або інтерфейси, що без чіткої відповідальності „просто працюють“.

Відповідність пристроїв: стан пристрою як передумова доступу

Другий важіль — відповідність пристроїв, оскільки кінцеві пристрої часто є точкою входу. «Compliance» тут означає не юридичну відповідність, а технічні мінімальні вимоги: стан патчів, шифрування (наприклад BitLocker/FileVault), активний захист від шкідливого ПЗ, стан брандмауера, Secure Boot та підтвердження того, що пристрій керується (MDM/Endpoint Management).

В Microsoft‑середовищах це часто реалізують за допомогою Intune/Endpoint Manager разом із Conditional Access. Conditional Access — це політики, які під час входу вирішують, чи дозволити доступ (наприклад лише з MFA і лише з пристроїв, що відповідають вимогам). У інших стеках подібне досягається через MDM, Identity Provider (IdP) та ZTNA/SSE‑рішення. Вирішальним є не інструмент, а операційно витримувана політика.

Політики, які витримують підтримку та експлуатацію

Часта причина незадоволення — надто жорсткі правила без диференційованих сценаріїв доступу. Практичним є багаторівневий підхід:

• Базовий: MFA для всіх; блокування невідомих пристроїв для критичних застосунків (адмін‑портали, фінанси, HR, віддалені підключення).
• Стандартний: доступ до центральних порталів і засобів співпраці лише з зареєстрованих пристроїв; незареєстровані пристрої — лише обмежено (наприклад web‑only), якщо платформа це підтримує.
• Високий: адмін‑доступ лише з виділених адмін‑робочих станцій (PAW, Privileged Access Workstation) з жорсткішими правилами відповідності і без локальних прав адміністратора для повсякденної роботи.

Важливо: «compliant» — це не постійний стан. Пристрої можуть втратити відповідність (відставання патчів, помилки шифрування, застаріла ОС). Zero Trust означає: не дискутувати, а контроловано понижувати рівень доступу. Приклад: доступ до порталу залишається можливим, VPN або доступ до зон управління блокуються до виконання виправлення.

BYOD, спеціальні пристрої та некеровані кінцеві точки

У середньому бізнесі часто бувають класи пристроїв, які неможливо керувати як стандартні ноутбуки: вимірювальні прилади, машинні ПК, термінальні системи, сканери, старі Windows‑версії для спеціального ПЗ. Це стає керованим, якщо ІТ визначить категорії пристроїв і зв’яже з ними права доступу:

• Керовані стандартні пристрої: повна відповідність через MDM/GPO, стандарт для інформаційної роботи та адміністрування.
• Обмежені пристрої: обмежено керовані; допускаються лише в ізольовані сегменти і лише до визначених цільових систем (наприклад виробнича мережа → інтеграційний шлюз).
• Некеровані/BYOD: доступ лише до обмежених сервісів (наприклад webmail/портал) з MFA і чіткими обмеженнями потоків даних.

Так із «непідтримувано» виходить на стабільний компроміс: спеціальні пристрої залишаються допустимими, але їхня зона дії обмежена, отже ризик керований.

NAC und 802.1X: Wenn das Netz nur noch bekannte Geräte zulässt

Відповідність пристроїв не закінчується при вході. Наступний крок — Network Access Control (NAC): пристроям надається доступ до мережі лише після підтвердження на комутаторі або в WLAN. 802.1X — стандартний механізм, при якому пристрій аутентифікується в мережі за допомогою сертифіката або ідентичності користувача. Для пристроїв без 802.1X часто застосовують MAB (MAC Authentication Bypass) — як виняток, менш безпечно, але іноді неминуче.

NAC дуже ефективний, але операційно вимогливий. Реальність така: багато винятків (принтери, IoT, гості, старі пристрої) — це норма. Проєкт NAC залишається контрольованим, якщо його впроваджувати поетапно:

• Пілот на одній локації або спочатку лише в корпоративному WLAN.
• Початок у режимі моніторингу/сповіщень, щоб вивчити реальний ландшафт пристроїв.
• Карантинна мережа для невідомих пристроїв з чіткими процесами Helpdesk і, де можливо, реєстрацією самообслуговування.

Додаткова користь: краща інвентаризація. NAC змушує до «правди про пристрої» й таким чином надає підґрунтя для сегментації, реагування на інциденти та рішень щодо життєвого циклу.

Ідентичності, ролі та сервісні акаунти: без гігієни IAM це лишається фрагментарним

Zero Trust часто розглядають як мережеву або кінцевочну (endpoint) проблему. Проте на практиці саме сторона ідентичностей вирішує питання точності та супроводжуваності. IAM (керування ідентичністю та доступом) охоплює логін, ролі/групи, процеси Joiner‑Mover‑Leaver та технічні облікові записи (Service Accounts).

Least Privilege у бізнес‑ПЗ: консолідувати ролі, відокремити адміністративні права

У ERP/CRM та порталах права часто виникають історично: нова функція — нова роль, потім знову виняток. Результат — накладні дозволи та нечітка відповідь на питання «хто що може?». Сумісним із Zero Trust це стає, коли ролі моделюються як бізнес‑функції (наприклад, «погодити рахунок», «змінювати основні дані», «запускати експорт») і технічні права адміністратора від них послідовно відокремлені.

Для експлуатації важливо, щоб ролі були підлягаючими ресертифікації: у фіксованих циклах відповідальні підтверджують, що доступи все ще необхідні. Це не обов’язково має бути бюрократично, але потребує чітких власників для кожної області даних.

Захистити сервісні акаунти та доступи через інтерфейси

Багато критичних доступів виконують не користувачі, а сервіси: інтеграційні джоби, ETL, партнерські інтерфейси, батч‑процеси, Windows-сервіси або Linux-сервіси. Типові ризики — статичні паролі, надмірні права, відсутність ротації та нечітка відповідальність. У контексті Zero Trust це означає:

• Окрема ідентичність для кожного сервісу: жодних спільних облікових записів для кількох джобів.
• Мінімальні права: наприклад, тільки право запису в SFTP‑inbox замість повного доступу до загального ресурсу.
• Професійне поводження з секретами: ключі/паролі не зберігати в конфігураційних файлах; планувати ротацію, призначити відповідальних.
• Мережеві шляхи відповідно до сегментації: інтеграційний сервіс звертається до чітко визначених цілей, а не «в усьому серверному середовищі».

Особливо для інтерфейсів Zero Trust стає частиною архітектурної роботи: API‑шлюз або інтеграційний проксі може централізувати автентифікацію, ліміти частоти та логування і зменшити хаотичний ріст. Це не замінює безпеку застосунку, але дає кращий контроль за експлуатацією.

Zero Trust у середньому бізнесі як дорожня карта: поставляти по етапах

Функціональна дорожня карта має дві властивості: вона дає помітні покращення за кілька тижнів і залишається придатною для наступних етапів розширення. На практиці себе виправдав фазовий підхід, оптимізований не на повноту, а на важелі ризику.

Фаза 0: зафіксувати критичні системи, потоки даних та зовнішні межі

Перед тим як блокувати й сегментувати, потрібно мінімум прозорості:

• Які системи критичні (ERP/DMS, бази даних, резервне копіювання, ідентичність, віртуалізація, інтеграційні сервери)?
• Які існують шляхи доступу (VPN, RDP/SSH, адмін‑інструменти, API, SMB, SFTP)?
• Які є зовнішні межі (партнери, локації, cloud‑тенанти, зовнішні доступи адміністраторів)?

Це не заклик створити ідеальну CMDB. Це робочий перелік, який надалі робить винятки, правила брандмауера та зони відповідальності життєздатними.

Phase 1: Укріплення ідентичності – MFA, аварійні доступи, розділення адміністраторських входів

Багато середовищ мають MFA, але налаштовано неякісно. Стійкі мінімальні стандарти такі:

• MFA для всіх користувачів, особливо для віддалених доступів та адміністративних інтерфейсів.
• Визначений аварійний доступ («Break Glass»): окремо захищений, контрольований і призначений лише для інцидентів.
• Розділення користувацьких і адміністраторських облікових записів, щоб фішинг не призводив автоматично до отримання привілеїв.

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

Phase 2: Примушення відповідності пристроїв насамперед для критичних цілей

Замість «всі пристрої одразу compliant» зазвичай ефективніше прив’язати правила до ключових активів:

• Адмін-портали (віртуалізація, резервне копіювання, мережеве управління) — лише з пристроїв, що відповідають вимогам.
• VPN — лише з пристроїв, що відповідають вимогам, або з сильно обмеженими цільовими мережами.
• Портали Finance/HR та експорт чутливих даних — лише з перевіркою пристрою й чіткими правилами сесій.

Це створює виправданий тиск на міграцію: хто потребує повного доступу, має підключити пристрій до системи управління. Одночасно ви не блокуєте одразу всі робочі місця.

Phase 3: Сегментація мережі в хвилях – спочатку захист резервного копіювання та управління

Якщо оперативно можна реалізувати лише одне правило сегментації, це часто таке: системи резервного копіювання та управління недоступні безпосередньо з клієнтської зони. Це потужний гальмівний блок проти ескалації рансомваре. Далі слідують серверні зони та визначена зона інтеграції.

Для кожної хвилі потрібен план відкату: що можна тимчасово відкрити в надзвичайному випадку, як це документується, хто знову закриває? Без цього механізму сегментація в повсякденній практиці поступово втрачає ефективність.

Phase 4: Privileged Access Management (PAM) und Admin-Workstations

PAM (Privileged Access Management) включає технології та процеси для обмеження привілейованих доступів: права Just-in-Time (тимчасові), шляхи погодження, ротація паролів/ключів та ведення журналів. Практичним входом для середнього бізнесу часто є:

• Виділені адмін-робочі станції (PAW) або бастіон-оточення для RDP/SSH.
• Жодних адміністративних дій з повсякденних ноутбуків.
• Runbooks та логи, які реально використовуються під час інциденту.

Це зменшує ймовірність того, що скомпрометований пристрій користувача слугуватиме трампліном у зону управління.

Операційна реальність: де Zero Trust працює (і як ним керувати)

Zero Trust не безкоштовний. Ті, хто відкрито це планує, згодом стикаються з меншою політичною опозицією. Типові наслідки для експлуатації:

Більше управління політиками та винятками

Спершу зростає кількість коригувань: політика відповідності занадто жорстка, на майданчику є спеціальне обладнання, служба все ж потребує з’єднання. Різниця між хаосом і прогресом — чіткий процес винятків: тимчасовий, з відповідальним власником, документований і регулярно перевіряний. Інакше Zero Trust швидко перетвориться знову на «Any-to-Any, бо було терміново».

Логування стає передумовою для усунення несправностей

Коли дозволи доступу приймаються залежно від контексту, логи повинні бути надійними: IdP- та логи автентифікації, статуси кінцевих точок, логи брандмауера/VPN і, по можливості, централізований аналіз (SIEM або консолідоване управління логами). Без логів запит «Чому користувач не заходить?» не відтворюється, і політики з часом розмиваються через фрустрацію.

Вплив на корпоративне програмне забезпечення: автентифікація, шляхи передачі даних, сертифікати

Багато систем не потрібно перебудовувати, але вони мають відповідати новим припущенням безпеки. Типові адаптації:

• SSO через OIDC/SAML замість локальних паролів там, де це доцільно. OIDC (OpenID Connect) — сучасний протокол для входу через IdP; SAML і далі поширений в Enterprise-SSO.
• API замість Fileshare, там, де сегментація інакше змусила б постійно вводити винятки.
• Захист сервіс–до–сервісу (наприклад mTLS): mTLS — це TLS з двосторонньою перевіркою сертифікатів, що дозволяє однозначно ідентифікувати також сервіс-викликача.

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

Вимірювати успіх, не тонути в метриках

Достатньо кількох показників, щоб зробити прогрес керованим:

• Частка керованих пристроїв (managed vs. unmanaged) та тренд.
• Доля compliant vs. non-compliant по групах пристроїв та найпоширеніші причини (оновлення, шифрування, AV).
• Зменшення плоских мережевих прав: кількість Any-to-Any правил між сегментами, кількість тимчасових винятків і їхній вік.
• Privileged Access: частка адміністративних входів, що йдуть з не-PAW-пристроїв; скорочення постійних прав адміністратора.
• Сигнали інцидентів: заблоковані доступи до зон управління, незвичні автентифікації, повторні виявлення шкідливого ПЗ.

Питання завжди: яка міра зменшує ризик вимірювано, не блокуючи роботу?

Підсумок: Zero Trust — це рішення щодо експлуатації, а не дискусія про інструменти

Zero Trust у середньому бізнесі працює, якщо його розглядати як поєднання архітектури, експлуатації та чіткої контролю доступу. Сегментація обмежує свободу пересування в мережі, Device Compliance підвищує бар’єр входу, а дорожня карта поетапно спочатку захищає ідентичність, резервні копії та управління. Важливо не допускати неформального розповсюдження винятків, а оперувати ними як тимчасовим, документованим процесом — і заздалегідь планувати вплив на корпоративне програмне забезпечення, інтерфейси та життєвий цикл сертифікатів/секретів.

Обговорити проєкт або ініціативу модернізації з Net-Base.