Матеріал підготовлений на основі виступу провідного технічного спеціаліста ESET в Україні Нікіти Веселкова на «NG-CISO»

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

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

Least Privilege: фундамент контролю доступів

Модель Least Privilege є класичним підходом, який використовується підсвідомо кожним спеціалістом з безпеки. Її принцип простий — кожен користувач, сервіс і процес отримує мінімально необхідний доступ для виконання своїх задач. Ні більше, ні менше. У базовому вигляді ця модель присутня у більшості організацій, проте правильна реалізація вимагає системного підходу і побудови чіткої архітектури доступів.

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

Додатковий рівень контролю забезпечує модель на основі атрибутів. Атрибути доступу включають час, геолокацію, характеристики системи та платформи, мережу, специфічні параметри середовища. Наприклад, співробітники маркетингу можуть завантажувати файли тільки з певними розширеннями й тільки в певній директорії. Важливо при цьому дотримуватися балансу, адже надмірні обмеження можуть паралізувати роботу. Є приклади компаній, де новий співробітник не може отримати доступ до віртуальної машини без детального пояснення, які саме доступи йому потрібні і як він їх використовуватиме, що викликає первинний дискомфорт, але забезпечує високий рівень безпеки.

Концепції Just-in-Time Access та Just-Enough Access доповнюють модель. Перша передбачає надання доступу у визначені проміжки часу. Наприклад, фінансовий відділ може мати доступ до певних документів тільки в періоди фінансової звітності, в інший час доступ надається за окремим погодженням. Друга концепція означає надання користувачу стільки доступу, скільки йому мінімально потрібно, без спроб передбачити його майбутні потреби. Практика показує, що такий підхід рідко створює незручності, оскільки користувачі працюють у рамках стандартизованих процесів і звертаються за додатковим доступом лише за реальної необхідності.

Privileged Access Management є фундаментом реалізації принципу мінімальних привілеїв. Ці системи надають сховище для привілейованих облікових даних, автоматичну ротацію паролів, можливість адміністрування «точно вчасно», процеси затвердження доступу, запис сесій та повний аудит дій. Запис сесій дозволяє бачити всі команди, запуски програм, копіювання текстів під час роботи користувача, що критично важливо при розслідуванні інцидентів та аналізі робочих процесів.

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

Zero Trust: архітектура постійної перевірки

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

Згідно з дослідженнями Gartner, модель будується на п’ятьох базових принципах:

• Zero Trust є парадигмою, а не набором рішень. 
• Потрібно припускати наявність ворожих акторів всередині організації.
• Доступ має бути адаптивним на основі ризиків. 
• Необхідно встановлювати ідентичність кожного суб’єкта. 
• Доступ має бути обмеженим. 

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

Модель базується на шести основних категоріях, кожна з яких є критично важливою. 

Перша категорія — Identity, управління тим, хто запитує доступ, і чи є цей користувач або сервіс тим, за кого себе видає. Технологічно це реалізується через єдиний вхід до всіх корпоративних застосунків, багатофакторну автентифікацію, провайдерів ідентичності, умовний доступ та управління життєвим циклом користувачів. Організаційно це вимагає строгого процесу прийому та звільнення співробітників, коли під час звільнення доступ закривається миттєво, регулярного аудиту доступів, обмеження спільних облікових записів та заборони слабких факторів автентифікації. Особливо під час війни підтвердилося, що повідомлення через мобільних операторів легко перехопити спецслужбами.

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

Третя категорія — Network, контроль взаємодії між системами для мінімізації бокового переміщення зловмисника. Мережа є основним середовищем для lateral movement, коли після отримання доступу до однієї машини зловмисник переміщується між системами. Технологічно це вирішується через мікросегментацію мережі, де можуть бути створені сегменти навіть з однією машиною або з визначеними взаємозв’язками. Багато українських інфраструктур взагалі не сегментовані, що є великою проблемою. Організаційно потрібна відмова від плоских мереж та відмова від підходу «все всередині організації є довіреним». Це найбільша ментальна проблема фахівців, коли автоматично довіряють внутрішньому середовищу. Практика показує більше прикладів атак всередині мережі ніж тих, які комунікували із зовнішніми серверами.

Четверта категорія — Applications, контроль на рівні застосунків, включно з доступом, ролями, правами та контролем внутрішніх операцій. Найкращий підхід полягає в описанні дозволеного програмного забезпечення через вайт-лістинг і блокуванні всього іншого. У рамках цього списку потрібно описати поведінку кожного додатка — наприклад, архіватор може відкривати тільки документи з певних типів архівів, а графічний редактор не може встановлювати зовнішні мережеві з’єднання. Це можна робити вручну, але існують рішення для автоматизації на основі моніторингу активності процесів. Організаційно потрібні мінімальні ролі у кожному застосунку, документована модель та навчання розробників безпечному програмуванню.

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

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

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

Найпоширеніші помилки включають спробу впровадити Zero Trust одним продуктом, початок з мережі замість ідентичності, відсутність єдиного входу та каталогу даних. Коли компанії починають сегментувати мережу, не розуміючи, хто в ній працює, виникає каша, яку потім доводиться переробляти після опису ідентичностей і ролей. Інша проблема — надмірно жорсткі політики, які паралізують бізнес-процеси. Баланс між безпекою та зручністю критично важливий, оскільки надмірні обмеження призводять до обходу правил або звільнення співробітників.

Defense in Depth: багатошарова оборона

На відміну від попередніх моделей, Defense in Depth — це стратегія побудови безпеки як системи цибулі, багатошарової оборони. Якщо щось втратилося на периметрі, система ловить загрозу на рівні мережі. Якщо не заблокувалося в мережі — блокує в електронній пошті. Якщо пройшло через пошту, зупиняє на кінцевій точці. Таким чином, захист продовжується, поки не доходить до даних або критичного сервісу.

Модель традиційно будується за принципом концентричних кіл, де кожне коло представляє окремий рівень захисту. Зовнішній рівень — це безпека периметра з міжмережевими екранами, системами виявлення вторгнень та захистом від атак типу відмови в обслуговуванні. Далі йде безпека мережі з внутрішніми засобами контролю, сегментацією та моніторингом трафіку. Наступний рівень — безпека кінцевих точок з антивірусами нового покоління, системами виявлення та реагування, контролем пристроїв. Потім йде безпека додатків із захистом вебзастосунків та інтерфейсів програмування. Ближче до центру знаходиться рівень користувачів із навчанням, контролем доступів та моніторингом поведінки. У центрі розташовані самі дані із шифруванням, системами запобігання витоку, резервним копіюванням та класифікацією.

Практичний приклад демонструє роботу моделі при фішинговій атаці. Зловмисник відправляє лист зі шкідливим вкладенням, який спочатку блокується системою захисту електронної пошти на основі евристичного аналізу. Якщо цей захист вимкнено, лист потрапляє в пісочницю, де вкладення детонується і виявляється троян, після чого адміністратор бачить звіт про поведінку файлу. Якщо вимкнено і пісочницю, користувач відкриває документ, але захист від експлойтів на кінцевій точці блокує виконання шкідливих макросів. Якщо і цей захист обійдено, машина намагається комунікувати з командним сервером, але мережевий модуль блокує підозрілі з’єднання. Навіть якщо машина скомпрометована, поведінковий аналіз виявляє підозрілу активність — спроби крадіжки облікових даних, створення процесів, бокове переміщення — і блокує їх. 

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

Цей приклад чітко демонструє, як багатошаровість дозволяє зупинити атаку на різних етапах, навіть якщо один або кілька захистів відмовили. Кожен рівень вимагає від зловмисника додаткових зусиль, часу та ресурсів, сповільнюючи атаку та збільшуючи ймовірність її виявлення. Різні типи загроз краще виявляються на різних рівнях — мережеві атаки ловляться на периметрі, шкідливе програмне забезпечення — на кінцевих точках, витік даних — системами контролю інформації. Навіть якщо атака частково успішна, пошкодження обмежуються одним рівнем завдяки ізоляції між шарами.

Взаємозв’язок та практичне застосування

Три описані моделі не конкурують між собою — вони органічно доповнюють одна одну, створюючи комплексну систему захисту. Least Privilege закладає фундамент, забезпечуючи правильні доступи та права на базовому рівні. Zero Trust будує архітектуру поверх цього фундаменту, визначаючи, як ці доступи перевіряються та контролюються на всіх рівнях інфраструктури. Defense in Depth забезпечує глибину захисту, створюючи кілька незалежних рівнів контролю на випадок відмови одного з них.

Рекомендації щодо впровадження базуються на поступовості та прагматизмі. Починати варто з Least Privilege, оскільки це найпростіша та найефективніша відправна точка — навіть базова реалізація дає відчутні результати без значних інвестицій. Далі можна поступово додавати елементи Zero Trust, починаючи з управління ідентичністю через багатофакторну автентифікацію та єдиний вхід, потім додаючи контроль відповідності пристроїв, і лише потім переходячи до складнішої мікросегментації мережі. Defense in Depth з’являється природно в процесі впровадження різних типів захисту — коли організація має антивірус, міжмережевий екран та фільтрацію пошти, вона вже реалізує базову багатошаровість.

Критично важливо не переборщити з моделями. Намагання впровадити всі можливі фреймворки та підходи одночасно призводить до паралічу організації. Зазвичай це відбувається, коли приходить керівник служби безпеки з великою кількістю міжнародних сертифікацій і намагається впровадити все тут і зараз. Через кілька місяців такий керівник зазвичай звільняється, констатуючи, що нічого не працює. Натомість потрібно обирати те, що відповідає поточному рівню зрілості організації, впроваджувати поступово та не забувати про баланс із бізнесом.

Питання балансу з бізнесом є ключовим для успіху будь-якої моделі безпеки. Найкраща модель — та, яка дозволяє бізнесу функціонувати ефективно. Надмірні обмеження призводять до того, що співробітники або шукають способи обходу правил, або звільняються через дискомфорт. Є приклади організацій, де реалізовано максимально можливий Zero Trust, і нові співробітники спочатку здивовані тим, що для отримання доступу до віртуальної машини потрібно написати пояснення і чекати, поки зайняті відділи опрацюють запит. Проте після пояснення причин такі працівники розуміють важливість процедур і адаптуються до них.

Реалістичність впровадження Zero Trust у великих організаціях залежить від наявних ресурсів. Для організації на тисячу користувачів може знадобитися команда з кількох десятків спеціалістів для впровадження та підтримки. Проте починати можна з малого — навіть базова реалізація з багатофакторною автентифікацією, єдиним входом та політиками для пристроїв значно підвищує рівень безпеки. Найбільша компанія, для якої впроваджувався Zero Trust за участю експертів, налічувала чотири тисячі співробітників, і процес тривав понад два роки. При цьому вдалося максимально обмежити адміністраторів, але повністю охопити звичайних користувачів виявилося складніше через різноманітність їхніх робочих процесів та інструментів.

Переконати бізнес у необхідності інвестицій у безпеку найпростіше через демонстрацію співвідношення витрат і ризиків. Багатофакторна автентифікація є одним із найдешевших рішень на ринку, і показ її вартості в порівнянні з потенційними втратами від компрометації зазвичай переконує керівництво. Ефективно працює також демонстрація реальної атаки — наскільки легко скомпрометувати обліковий запис без додаткових факторів захисту. Найкращим аргументом, як завжди, є реальний інцидент, коли правоохоронці приходять розслідувати витік даних, після чого всі необхідні заходи впроваджуються без питань про бюджет.

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