Один підрядник — один інцидент:
Уявіть, що ви перетворили свій офіс на фортецю: біометричні сканери на вході, озброєна охорона, камери спостереження в кожному кутку. Ви інвестуєте у безпечну архітектуру, сегментацію, SIEM, SOC — усе найкраще.
Але щодня надаєте доступ до критичної інфраструктури зовнішнім підрядникам — фактично передаєте їм ключі від головного входу й дозволяєте пересуватись без чітких обмежень, бо «їм же треба виконувати роботу». Звучить абсурдно?
VPN — «троянський кінь» цифрової епохи
Традиційна модель віддаленого доступу будується на довірі. Ми створюємо обліковий запис, відкриваємо VPN-тунель і вважаємо, що ситуація під контролем.
Звісно, доступ можна жорстко обмежити: сегментацією мережі, правилами фаєрвола, white-list за IP. Можна застосувати GPO, EDR або XDR, мінімізувати поверхню атаки й підʼєднати SOC до моніторингу. Усе це правильно. І це необхідно.
Але ці механізми працюють переважно в моделі «виявити та відреагувати». Фаєрвол обмежує маршрут. EDR фіксує підозрілу активність. SIEM створює інцидент. SOC може ізолювати хост.
Проте ключове питання лежить глибше: що саме відбувається всередині привілейованої сесії?
Якщо адміністратор із легітимними правами вносить зміни, система сприймає це як дозволену дію — доти, доки вона не порушує конкретне правило. Намір і контекст залишаються за межами мережевого контролю. Інцидент може бути зафіксований, але дія вже виконана.
Саме тому навіть у добре сегментованому середовищі виникає сліпа зона — не в мережі, а в моменті виконання привілейованих команд.
Є ще одна проблема, про яку рідко говорять відкрито — атрибуція.
У підрядників часто використовуються окремі адмінські облікові записи, інколи — спільні або сервісні. Коли стається інцидент, починається складний розбір: хто саме виконав зміну? Конкретний інженер? Його колега? Автоматичний скрипт? Чи зловмисник, що скористався скомпрометованими даними?
Без повної прозорості сесії відповідь перетворюється на припущення.
VPN сам по собі не є проблемою. Проблема — в моделі, де доступ надається наперед, а глибокий контроль з’являється лише після події. І справжній ризик полягає не в мережевому тунелі, а у відсутності керованості всередині нього.
Як CyberArk закриває головну діру у периметрі безпеки
Ми розібрались, що проблема класичної моделі доступу полягає не у VPN як такому, а у відсутності керованого посередника між користувачем і критичною системою.
Сучасна архітектура від CyberArk змінює саме цю точку. Вона не покращує VPN, а прибирає пряму довіру між підрядником і внутрішнім ресурсом. Кожен віддалений доступ проходить через повний контур Privileged Access Management — із перевіркою, брокеруванням сесії, контролем і аудитом.
Підрядник більше не підʼєднується до мережі напряму. Він не отримує VPN-клієнт і не знає пароля до цільової системи. Доступ відбувається через контрольований шлюз, який виступає проксі між користувачем і ресурсом. Пароль зберігається в сейфі PAM і підставляється автоматично — без розкриття. Його неможливо записати, переслати або використати повторно.
Це принципово інша модель: користувач отримує не мережу, а конкретну контрольовану сесію.
Другий ключовий елемент — доступ за потребою, а не наперед. Замість постійних облікових записів застосовується підхід Just-in-Time: доступ активується лише на час погодженої роботи. Після завершення сесії привілеї відкликаються автоматично, а за необхідності, облікові дані ротуються. Тимчасові доступи перестають бути «тимчасовими назавжди».
Але найсуттєвіша різниця — у контролі дій.
Від технології до моделі доступу: що змінюється для організації
У практичній площині це означає значно більше, ніж просто ще один інструмент віддаленого доступу.
Фактично змінюється сама модель взаємодії із зовнішніми користувачами.
У класичному підході компанія розширює власний периметр щоразу, коли підʼєднує нового підрядника. Кожен VPN-акаунт логічно стає частиною внутрішньої мережі: з’являються маршрути, винятки у фаєрволах, постійні облікові записи, накопичені привілеї. З часом зʼявляються десятки або сотні таких доступів, і керування ними перетворюється на операційний тягар. Видалення забутих акаунтів, ротація паролів, перевірка прав, розслідування дій — усе це реактивна робота, яка починається вже після виникнення ризику.
Модель із контрольованим брокеруванням сесій працює інакше. Периметр більше не розширюється під кожного нового користувача. Навпаки, він залишається стабільним, а всі зовнішні підʼєднання проходять через єдину керовану точку контролю. З точки зору архітектури, це ближче до принципів Zero Trust: жоден доступ не вважається довіреним лише тому, що користувач успішно автентифікувався. Довіра підтверджується щоразу — контекстом, політиками й обмеженнями конкретної сесії.
У результаті змінюється не лише рівень безпеки, а й керованість процесів. Зникають спільні облікові записи, спрощується атрибуція дій, аудит перестає бути складним розслідуванням, а стає звичайною перевіркою журналу сесій. Доступи не накопичуються роками, не «забуваються» після проєктів і не створюють прихованих шляхів усередину інфраструктури. Кожне підʼєднання має чітку мету, обмежений час життя й прозору історію.
Безпека без тертя: як змінюється щоденна робота команд
У традиційному сценарії кожен новий підрядник — це окремий процес: створення облікового запису, погодження доступів, відкриття сегментів, передавання паролів, подальша ротація та контроль, чи не залишився доступ активним після завершення робіт. Для адміністраторів це постійна ручна операційна робота, а для служби безпеки — нескінченні перевірки й аудит.
Контрольований Remote Access CyberArk спрощує ці процеси. Підрядник підʼєднується через браузер, проходить біометричну автентифікацію, обирає погоджену систему й одразу потрапляє в готову сесію без обміну паролями та додаткових налаштувань. Доступ видається автоматично відповідно до політики й так само автоматично відкликається після завершення роботи. Для команди це означає менше ручних операцій, менше винятків і менше людських помилок.
Для SOC і аудиту це ще помітніше. Замість збору логів із різних джерел і реконструкції подій постфактум, у розпорядженні вже є повна історія сесії: хто підʼєднувався, куди саме, коли й що робив. Розслідування інцидентів скорочується з годин до хвилин, а значна частина перевірок узагалі перестає бути необхідною.
У підсумку контрольований доступ стає не додатковим рівнем складності, а способом зменшити хаос навколо привілейованих облікових записів. Безпека перестає конфліктувати з операційною зручністю — вони починають працювати разом.
Як це влаштовано «під капотом»
Щоб ця модель не виглядала абстрактною концепцією, варто розуміти, як вона реалізується на рівні інфраструктури.
У вашому середовищі, Remote Access будується не як ще один VPN-сервер, а як окремий контрольований контур між зовнішнім користувачем і внутрішніми ресурсами. Замість прямого мережевого тунелю створюється точка брокерування сесій, через яку проходять усі підʼєднання. Фактично це шлюз, що приймає автентифікацію користувача, перевіряє політики доступу й лише після цього встановлює з’єднання із цільовою системою від свого імені.
З боку підрядника це виглядає максимально просто: він відкриває вебпортал, проходить автентифікацію через мобільний застосунок із багатофакторним підтвердженням, де доступ до застосунку додатково захищений біометрією пристрою, і бачить список систем, до яких має погоджений доступ.
Жодних VPN-клієнтів, маршрутів у внутрішню мережу чи локальних облікових даних на його пристрої не з’являється. Уся взаємодія відбувається на рівні окремої сесії — RDP, SSH або вебдоступу — яка проксіюється через шлюз.