Один подрядчик — один инцидент:
Представьте, что вы превратили свой офис в крепость: биометрические сканеры на входе, вооруженная охрана, камеры наблюдения на каждом углу. Вы инвестируете в безопасную архитектуру, сегментацию, 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 или веб-доступа — которая проксируется через шлюз.