Подрядчики с удалённым доступом: VPN, PAM, jump-host, запись сессий и контроль изменений

Почему эта тема стала критически важной для корпоративной безопасности в России

Почему подрядчик — самое слабое звено

Когда руководители ИБ-подразделений говорят о периметре безопасности, они обычно имеют в виду собственных сотрудников, корпоративные устройства и рабочие сети. Но периметр давно стал проницаемым — и прежде всего через внешних подрядчиков.

Компании отдают на аутсорс поддержку серверов, разработку ПО, обслуживание оборудования, 1С, CRM, промышленных систем. Каждый такой подрядчик получает удалённый доступ к инфраструктуре заказчика. При этом заказчик, как правило, не контролирует безопасность устройств подрядчика, не видит, что тот делает внутри системы, и не знает, кто из сотрудников подрядчика реально использует выданные учётные данные.

Результат закономерен: атаки через цепочку поставок и подрядчиков выросли в устойчивый глобальный тренд. По данным Positive Technologies, значительная часть ИТ-компаний становится жертвами именно потому, что выступает подрядчиком для организаций других отраслей — успешное проникновение в их инфраструктуру влечёт цепную реакцию атак на клиентов [5]. CyberArk в исследовании 2024 года утверждает, что 80% организаций столкнулись с нарушением конфиденциальности из-за атаки на цепочку поставок [6].

Эта статья — практический разбор инструментов и подходов, которые позволяют работать с подрядчиками, не теряя контроля над собственной инфраструктурой.

Почему VPN — это только начало, а не решение

Что VPN делает и чего не делает

VPN (Virtual Private Network) создаёт зашифрованный туннель между устройством подрядчика и корпоративной сетью. Это решает одну задачу: защищает трафик от перехвата в публичных сетях. Но сетевой доступ — не то же самое, что контролируемый доступ.

Классическая VPN-архитектура даёт подрядчику «ключ от квартиры», не указывая, в какую комнату он может войти и что ему там делать. После успешной аутентификации пользователь нередко оказывается в одной широкой подсети с критическими серверами, базами данных и системами управления. Если учётные данные подрядчика скомпрометированы — злоумышленник получает такой же доступ.

В ноябре 2025 года обновлённый отчёт по группировке Akira зафиксировал, что вымогатели получают доступ к VPN-продуктам через похищенные учётные записи или эксплуатацию уязвимостей, в том числе CVE-2024-40766, а сумма полученного выкупа к тому моменту превысила 244 миллиона долларов [7].

Типовые проблемы классического VPN для подрядчиков

Первая проблема — избыточный сетевой доступ. Подрядчик, которому нужен доступ к одному серверу 1С, нередко получает маршрут ко всей внутренней подсети.

Вторая проблема — нет контроля за действиями. VPN не записывает, что именно делал пользователь, какие команды выполнял, какие файлы копировал.

Третья проблема — проблема устройства. Домашний компьютер подрядчика может быть заражён инфостилером. VPN не проверяет состояние безопасности подключаемого устройства.

Четвёртая проблема — учётные данные живут долго. Логин и пароль, выданные подрядчику при заключении договора, нередко продолжают работать спустя годы после завершения работ.

Как отметил Александр Шилов из «К2 Кибербезопасность» на конференции AM Live в 2025 году, подрядчик работает с конфиденциальной информацией, поэтому удалённый доступ несёт больше угроз, чем в случае с обычным сотрудником: должен быть комплекс мер — шифрование, удостоверение личности, инспекция трафика [8].

Альтернатива: ZTNA вместо VPN

Zero Trust Network Access (ZTNA) — архитектурная модель, при которой пользователь получает доступ не к сети целиком, а к конкретному приложению или ресурсу. Принцип «никогда не доверяй, всегда проверяй» означает, что каждый запрос аутентифицируется и авторизуется заново, независимо от того, откуда он пришёл.

Для подрядчиков это принципиально важно: вместо широкого VPN-туннеля они получают доступ ровно к тем системам, которые необходимы для текущего контракта — и ни к чему больше. Один российский оператор связи внедрил ZTNA и перешёл от классического VPN к гранулярным политикам, при которых подрядчик видит только конкретные приложения, необходимые ему по контракту [9].

По прогнозам, мировой объём рынка ZTNA достигнет 52,2 млрд долларов США в 2025 году при среднегодовом темпе роста около 23% [10]. В России концепция интегрируется в правовое поле: ZTNA помогает соответствовать требованиям ФСТЭК и ФСБ, избегать штрафов за нарушения при несанкционированном доступе к критической инфраструктуре [10].

Jump-host и bastion-host: точка входа под контролем

Что это такое и зачем нужно

Jump-host (прыжковый хост, jump server) — специально выделенный сервер, через который организуется административный доступ к инфраструктуре. Вместо того чтобы позволять подрядчику подключаться напрямую к целевым системам, все соединения пропускаются через единый контролируемый узел [11].

Термин «bastion-host» (узел-бастион) появился в статье Маркуса Рэнума 1990 года о межсетевых экранах. Он описал бастионный хост как систему, определённую администратором как критическая точка обеспечения безопасности сети [12]. В современной практике термины часто используются как синонимы, хотя технически bastion-host — укреплённая, более строго настроенная версия jump-server, предназначенная для работы в производственных средах [13].

Что даёт jump-host

Консолидация точек входа — вместо нескольких десятков потенциальных векторов атаки остаётся один, хорошо защищённый и мониторируемый. Все соединения к внутренним системам маршрутизируются через него, что делает аудит возможным и управляемым.

Изоляция целевых систем — серверы во внутренней подсети не имеют публичных IP-адресов и не доступны напрямую из интернета. Подрядчик не знает и не может знать реальных адресов целевых систем.

Аудит и логирование — все SSH/RDP-сессии, проходящие через jump-host, могут быть зафиксированы. Это создаёт базу для расследования инцидентов.

Централизованное управление ключами — ротация SSH-ключей, управление пользователями и правами реализуется в одном месте, а не на каждом сервере отдельно [14].

Ограничения чистого jump-host

Сам по себе jump-host — это инфраструктурный компонент, а не система безопасности. Он не записывает содержимое сессий (только факт подключения), не управляет паролями и привилегиями, не анализирует поведение пользователя. Именно здесь в игру вступает PAM.

PAM: управление привилегированным доступом как основа контроля подрядчиков

Что такое PAM и зачем он нужен

Privileged Access Management (PAM) — класс решений для управления, мониторинга и защиты привилегированного доступа к критическим системам и данным. Привилегированными пользователями являются системные администраторы, аудиторы, специалисты ИБ и внешние подрядчики, управляющие системами удалённо [15].

PAM-система выступает прокси-сервером между пользователем и целевым ресурсом. Подрядчик аутентифицируется в PAM, а PAM самостоятельно устанавливает соединение с целевой системой — используя хранилище паролей, недоступное пользователю. Таким образом подрядчик никогда не узнаёт реальных учётных данных от серверов.

Ключевые функции PAM для контроля подрядчиков

Управление паролями и секретами. PAM хранит учётные данные в зашифрованном хранилище и автоматически ротирует их по расписанию. По оценкам рынка, чаще всего PAM-системы применяются именно для управления правами доступа и паролями — 36% использований [16].

Запись сессий. Каждая привилегированная сессия записывается: не только видео-снимки экрана, но и полный трафик. Это позволяет расследовать инциденты и доказывать факты нарушений. Мониторинг и запись действий администраторов — второй по распространённости сценарий применения PAM (29% использований) [16].

Контроль в реальном времени. PAM-система позволяет офицеру безопасности наблюдать за сессией в режиме реального времени и прерывать её при подозрительных действиях.

Контроль подрядчиков. Это третий по частоте сценарий применения PAM — 12% [16]. Система позволяет выдавать временный, строго ограниченный доступ, фиксировать все действия и автоматически отзывать доступ по завершении работ.

Интеграция с MFA. Дополнительная аутентификация подрядчика перед входом в PAM радикально снижает риск использования скомпрометированных учётных данных.

Кейс: как PAM выявил недобросовестного подрядчика

В практике ГК «Солар» был показательный случай: PAM-решение SafeInspect помогло выявить недобросовестное поведение компании-подрядчика. После переговоров о снижении бюджета в обслуживаемой системе произошла критическая авария. Анализ записей PAM-сессий показал, что подрядчик намеренно организовал инцидент, чтобы убедить заказчика в необходимости своих услуг [17].

Российский рынок PAM: что доступно сегодня

После ухода западных вендоров российский рынок PAM претерпел значительные изменения. Отечественные решения стали основным выбором для компаний — как в силу требований импортозамещения, так и из-за отсутствия технической поддержки иностранных систем [4].

Ключевые игроки российского рынка PAM в 2025 году:

1. Solar SafeInspect (ГК «Солар», входит в ПАО «Ростелеком») — одно из наиболее зрелых решений, сертифицировано ФСТЭК России по 4-му уровню доверия, включено в реестр отечественного ПО. Поддерживает три режима работы: бастион, сетевой мост и маршрутизатор [18].
2. Indeed PAM (Indeed) — программный комплекс для управления административным доступом и контроля действий привилегированных пользователей, поддерживает подключение через браузер или нативные приложения из любой точки мира [19].
3. BI.ZONE PAM — решение от BI.ZONE, ориентированное на защиту удалённого доступа сотрудников и подрядчиков на основе принципов нулевого доверия [20].
4. Innostage PAM и ряд других решений от российских интеграторов дополняют рынок.

Прогноз ГК «Солар» на 2025 год: российский PAM-рынок превысит 2 млрд рублей, ежегодно прирастая на 7% [21]. Мировой рынок PAM в 2024 году оценивается в 2,36 млрд долларов по данным Verified Market Reports и достигнет 6,72 млрд к 2033 году [4].

Запись сессий: доказательная база и операционный контроль

Зачем записывать сессии подрядчиков

Запись сессий привилегированных пользователей — не просто инструмент постфактумного расследования. Это операционный контроль, который влияет на поведение подрядчика уже в момент работы: знание о том, что сессия записывается, снижает вероятность как случайных ошибок, так и умышленных злоупотреблений.

С юридической точки зрения записи сессий — основа доказательной базы при возникновении споров с подрядчиком о том, кто и что изменил в системе. Это особенно важно при расследовании инцидентов, когда подрядчик может отрицать свою причастность.

С точки зрения регуляторных требований запись сессий привилегированных пользователей — одно из ожидаемых технических мер для организаций, попадающих под действие приказов ФСТЭК России [22].

Что и как записывать

Современные PAM-системы записывают не просто видеопоток с экрана. Solar SafeInspect, например, осуществляет полноценную запись всего трафика вместо снятия снимков с экрана и записи видео — это позволяет получить истинную картину произошедшего внутри привилегированной сессии без искажения и сжатия, а значит, собрать качественную доказательную базу по инциденту [23].

Помимо видеозаписи, системы фиксируют:

1. Точное время начала и окончания сессии с привязкой к учётной записи.
2. Все команды, введённые в командной строке (keylogging на уровне сессии).
3. Передачу файлов (копирование, скачивание).
4. Подключения к другим системам внутри сессии.
5. Попытки несанкционированных действий.

Хранение и доступ к записям

Записи сессий — это чувствительные данные. Они должны храниться в зашифрованном виде, с ограниченным доступом и чёткой политикой хранения. Важно определить, кто имеет право просматривать записи, при каких обстоятельствах и на какой срок они должны сохраняться.

Контроль изменений: что менял подрядчик и было ли это согласовано

Почему изменения от подрядчиков — отдельный риск

Подрядчики вносят изменения в ИТ-инфраструктуру — это суть их работы. Они устанавливают и обновляют ПО, меняют конфигурации, открывают порты, редактируют политики. Каждое такое действие потенциально влияет на безопасность и стабильность системы.

Согласно методологии ITIL 4, изменение — это добавление, видоизменение или удаление чего-либо, что может прямо или косвенно повлиять на ИТ-сервис [24]. С точки зрения результативной кибербезопасности изменения — это действия в ключевых системах, способные нарушить условия их безопасного функционирования [25].

Три типа изменений и их контроль

ITIL 4 выделяет три типа изменений:

Стандартные изменения — предзаранее авторизованные, задокументированные, регулярно повторяющиеся. Для них процедура согласования минимальна. Пример: плановое обновление антивирусных баз.

Нормальные изменения — требуют оценки рисков и авторизации через Совет по изменениям (CAB, Change Advisory Board). Подрядчик, планирующий изменить конфигурацию межсетевого экрана, должен пройти эту процедуру.

Экстренные изменения — требуют немедленных действий при критических инцидентах. Авторизуются через Экстренный совет по изменениям (ECAB) в упрощённом, но задокументированном порядке [25].

Как связать PAM и Change Management

Наиболее зрелая практика — интеграция PAM с системой управления изменениями. Это означает:

1. Подрядчик не может начать работу в PAM без активного согласованного запроса на изменение (RFC — Request for Change).
2. PAM-сессия автоматически связывается с конкретным RFC, что позволяет аудитору видеть, что именно делал подрядчик в рамках каждого задания.
3. Действия, выходящие за рамки согласованного RFC, могут фиксироваться как аномалия или требовать дополнительного подтверждения.
4. После завершения работ изменения проверяются и RFC закрывается с документированным результатом.

Такой подход позволяет избежать ситуации, когда подрядчик «заодно» делает что-то несогласованное — открывает лишний порт, создаёт дополнительный пользовательский аккаунт или изменяет политику безопасности.

Нормативный контекст: что требует регулятор

Приказ ФСТЭК № 239 в редакции 2024 года

Приказ ФСТЭК России № 239 от 25 декабря 2017 года об утверждении требований по обеспечению безопасности значимых объектов КИИ был существенно обновлён приказом № 159 от 28 августа 2024 года (вступил в силу с 5 ноября 2024 года). В числе новых требований — меры по устойчивости к DDoS и контролю удалённого доступа [22].

Ответственность за реализацию мер защиты лежит на владельце системы. Он может действовать сам или привлекать подрядчиков с лицензиями на защиту информации. Важно, чтобы всё было задокументировано и согласовано. Ключевые направления включают аутентификацию, контроль прав доступа, ведение журналов событий, управление конфигурациями [22].

Приказ ФСТЭК № 117 от апреля 2025 года

Новый приказ № 117, вступивший в силу в 2025 году, затрагивает операторов государственных информационных систем и усиливает требования к взаимодействию с подрядчиками. Согласно документу, подрядчики обязаны соблюдать политику безопасности заказчика, а все условия взаимодействия должны быть чётко прописаны в договорах [26].

Документ прямо указывает на PAM как на необходимый инструмент для управления привилегированными доступами администраторов и подрядчиков [26]. Также документ предусматривает включение в договоры и технические задания с подрядчиками требований по защите информации.

Штрафы: почему медлить опасно

Федеральный закон № 420-ФЗ от 30 ноября 2024 года внёс изменения в КоАП РФ и ввёл оборотные штрафы за повторные утечки персональных данных — до 1–3% годовой выручки компании. Минимальная сумма такого штрафа составляет 20 млн рублей, максимальная — 500 млн рублей [27]. Утечка через подрядчика не является основанием для освобождения от ответственности: оператор ПДн несёт ответственность за всех, кому предоставил доступ к данным.

Практические рекомендации: как выстроить защиту

Уровень 1. Сегментация и канал доступа

1. Выделите отдельный сегмент сети (VLAN) для подрядчиков — без прямого доступа к критическим системам.
2. Используйте VPN с проверкой устройства (NAC) или переходите на ZTNA для гранулярного контроля доступа.
3. Настройте доступ по принципу минимально необходимых привилегий: подрядчик видит только то, что нужно для конкретной задачи.
4. Определите временные окна доступа: подрядчик по обслуживанию бухгалтерского ПО не должен иметь доступ в 3 часа ночи.
5. Обязательно используйте MFA (многофакторную аутентификацию) для всех внешних подключений.

Уровень 2. Точка входа (jump-host)

1. Разверните выделенный jump-host или bastion-сервер как единую точку входа для всех подрядчиков.
2. Закройте прямые SSH/RDP-порты на целевых серверах от внешних сетей — доступ только через jump-host.
3. Настройте жёсткий hardening jump-host: минимальный набор сервисов, регулярные патчи, ротация ключей.
4. Интегрируйте jump-host с корпоративным каталогом (AD/LDAP) для единого управления учётными записями.
5. Настройте алерты на нестандартные паттерны подключений: необычное время, нетипичная географическая точка, слишком частые подключения.

Уровень 3. PAM-система

1. Внедрите PAM-систему с записью сессий для всех привилегированных подключений подрядчиков.
2. Используйте хранилище паролей PAM: подрядчик не должен знать реальных учётных данных от целевых систем.
3. Настройте автоматическую ротацию паролей после каждой сессии подрядчика.
4. Определите политики допустимых действий: PAM может блокировать команды, не соответствующие типу задачи.
5. Настройте оповещения для офицера безопасности при выполнении потенциально опасных команд.
6. Убедитесь, что выбранная PAM-система сертифицирована ФСТЭК (для КИИ и ГИС это обязательное требование).

Уровень 4. Контроль изменений

1. Внедрите обязательный процесс RFC для всех изменений, вносимых подрядчиком.
2. Свяжите PAM-сессии с RFC: без активного запроса на изменение сессия не открывается или открывается с отметкой «несанкционированная работа».
3. Ведите CMDB (Configuration Management Database) с историей изменений: что, когда, кем и в рамках какого RFC было изменено.
4. Проводите пострабочий аудит изменений (post-implementation review): были ли действия подрядчика ограничены заявленным объёмом работ?
5. Документируйте «baseline» системы до начала работ подрядчика — это позволит выявить несанкционированные изменения.

Уровень 5. Организационные меры

1. Пропишите требования ИБ в договорах с подрядчиками: соответствие политике безопасности, право аудита, требования к устройствам.
2. Проводите процедуру онбординга подрядчика: инструктаж, подписание NDA и соглашения о правилах работы.
3. Отзывайте доступ сразу после завершения работ — не «через неделю», а немедленно.
4. Проводите регулярный аудит активных учётных записей подрядчиков: многие из них «живут» в системах после завершения контрактов.
5. Включите подрядчиков в программу Security Awareness: они должны знать, что их действия мониторируются.

Типичные ошибки и как их избежать

Ошибка 1. Один VPN-аккаунт на несколько сотрудников подрядчика

Практика выдачи одного логина/пароля всей команде подрядчика полностью обнуляет возможность установить, кто именно совершил те или иные действия. Правило — один аккаунт на одного человека, всегда.

Ошибка 2. Доступ без временных ограничений

Учётная запись подрядчика не должна работать 365 дней в году. Настройте временные окна доступа, соответствующие реальному расписанию работ. Это снижает возможность использования скомпрометированных учётных данных в нерабочее время.

Ошибка 3. Не отзывать доступ после завершения контракта

Одна из наиболее распространённых проблем. После расторжения договора учётные данные подрядчика могут оставаться активными месяцами. Регулярный (минимум ежеквартальный) аудит активных аккаунтов — обязательная процедура.

Ошибка 4. Доверять подрядчику «потому что он проверенный»

Дмитрий Лебедев, выступивший на AM Live в 2025 году, указал: доступ для подрядчиков должен быть максимально строгим и безопасным — независимо от стажа отношений [8]. Принцип Zero Trust означает отсутствие доверия по умолчанию даже к многолетним партнёрам.

Ошибка 5. Отсутствие процедуры реагирования на инциденты с подрядчиком

Когда инцидент происходит, компании обнаруживают, что не знают: кто был подключён в момент инцидента, что именно делал, какой системой пользовался. Отсутствие записей сессий делает расследование крайне затруднённым, а в суде — невозможным.

Ошибка 6. Не разграничивать доступ по типам подрядчиков

Компания по уборке офиса и разработчик программного обеспечения — оба могут называться «подрядчиком», но уровень и характер их доступа к ИТ-инфраструктуре должны кардинально различаться.

Реальные инциденты: чему учит практика

«Ростелеком», январь 2025 года

21 января 2025 года группировка Silent Crow объявила о получении доступа к данным «Ростелекома». Компания подтвердила, что ранее фиксировала инциденты информационной безопасности у одного из своих подрядчиков, обслуживавших веб-ресурсы company.rt.ru и zakupki.rostelecom.ru [2]. По данным DLBI, в распоряжении хакеров оказалось 154 тысячи уникальных адресов электронной почты и 101 тысяча уникальных номеров телефонов [2].

Особенно показателен комментарий Минцифры: ИБ-специалисты «Ростелекома» не отвечали за системы подрядчика [28]. Это отражает типичную проблему: ответственность за безопасность инфраструктуры подрядчика де-факто не определена.

Тренд атак на цепочку поставок в 2024–2025 годах

По данным компании F6, атаки через цепочку поставок и подрядчиков сохраняют свою эффективность. В одном из задокументированных случаев две прогосударственные APT-группы одновременно находились в сети ИТ-подрядчика компании-цели, а одна из них атаковала ещё и клиентов жертвы [29]. Прогноз F6 на 2026 год: такие техники будут активно применять и вымогатели, и APT-группировки [29].

По данным Positive Technologies, IT-компании остаются под пристальным вниманием злоумышленников именно потому, что значительная часть из них выступает подрядчиками для организаций из других отраслей [5].

Будущее: как будет развиваться контроль подрядчиков

Слияние PAM и ZTNA

Рынок движется к интеграции: PAM-системы будут включать ZTNA-функционал, а ZTNA-решения — расширяться до управления привилегированным доступом. Российские вендоры уже движутся в этом направлении: BI.ZONE запустил BI.ZONE ZTNA в августе 2025 года, строя его на принципах нулевого доверия [20].

Поведенческий анализ и ИИ

Следующий шаг — не просто запись сессий, а автоматический анализ поведения. PAM-системы с функциями UEBA (User and Entity Behavior Analytics) смогут определять аномалии: подрядчик начинает скачивать данные в нетипичном объёме, работает в необычное время, обращается к ресурсам, которые никогда не использовал раньше.

Ужесточение регуляторных требований

Эксперты прогнозируют, что в 2024–2025 годах производители будут расширять функциональные возможности решений для удалённого доступа и внедрять технологии машинного обучения [17]. Регуляторное давление — через новые приказы ФСТЭК, оборотные штрафы за утечки ПДн — будет ускорять принятие этих решений компаниями.

Сквозная видимость: от сети до данных

Важный тренд — интеграция контроля доступа с контролем данных. Недостаточно знать, что подрядчик подключился и выполнил команды. Необходимо понимать, к каким данным он получил доступ, содержат ли они персональные данные, и соответствует ли это его полномочиям.

Как «Пятый фактор» помогает в контексте безопасности подрядчиков

Когда подрядчик получает доступ к корпоративным системам — базам данных, 1С, CRM, почте — возникает критический вопрос: к каким именно данным он имеет доступ? Содержат ли эти системы персональные данные клиентов или сотрудников? Был ли этот доступ учтён в реестре обработки ПДн?

Здесь возникает разрыв, который не закрывают ни VPN, ни PAM, ни jump-host: они контролируют факт подключения и действия, но не дают ответа на вопрос, какие именно ПДн оказались в зоне доступа подрядчика и изменилось ли это после последней проверки.

Именно эту задачу решает on-prem платформа «Пятый фактор» — система автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах (БД, хранилища, почта, AD/LDAP, CRM, 1С, API). Платформа работает с метаданными, структурой и агрегатами — без передачи и хранения «сырых» ПДн, что делает её безопасной для внедрения даже в организациях с высокими требованиями к конфиденциальности.

Практическая польза в контексте управления подрядчиками:

• Живая «карта ПДн» позволяет заранее понять, к каким системам с персональными данными получает доступ конкретный подрядчик, и принять обоснованное решение о необходимом уровне контроля.
• Автоматическое обнаружение новых полей, интеграций и источников позволяет оперативно выявлять случаи, когда подрядчик создал новые структуры с ПДн или подключил новый источник данных.
• Непрерывный мониторинг сокращает время аудита с недель до часов, что критически важно при подготовке к проверкам регулятора после инцидента с участием подрядчика.

Совместное использование PAM и «Пятого фактора» закрывает обе стороны риска: PAM контролирует, что делает подрядчик, а «Пятый фактор» обеспечивает актуальное понимание того, к каким данным он имел доступ.

Заключение: от разрозненных мер к системному подходу

Удалённый доступ подрядчиков — это не техническая проблема, требующая технического решения. Это организационный процесс, который должен включать:

1. Технические средства — VPN/ZTNA, jump-host, PAM, MFA, запись сессий.
2. Процессные инструменты — контроль изменений по ITIL, RFC, CAB, CMDB.
3. Организационные меры — договорные требования, онбординг, регулярный аудит доступа.
4. Регуляторное соответствие — требования ФСТЭК, ФЗ-152, КоАП (штрафы за утечки ПДн).

Ни один из этих элементов не работает эффективно в изоляции. Компании, которые ограничиваются только VPN, получают сетевой доступ без контроля действий. Компании, внедрившие PAM без процесса управления изменениями, теряют контекст: что конкретно и зачем менял подрядчик. Компании, уделившие внимание технике, но забывшие про договоры и онбординг, обнаруживают, что подрядчик не был обязан соблюдать никакие правила.

Инцидент с «Ростелекомом» в январе 2025 года и рост атак через цепочку поставок, зафиксированный F6 в отчёте за 2025 год, — это не случайности, а симптом системного пробела. Устранить его можно только системным подходом.

Источники

[1] BI.ZONE — BI.ZONE ZTNA (Zero Trust Network Access), TAdviser — https://www.tadviser.ru/index.php/Продукт:BI.Zone_ZTNA_(Zero_Trust_Network_Access)

[2] Habr — «Ростелеком»: утечка данных была в инфраструктуре подрядчика, январь 2025 — https://habr.com/ru/news/875312/

[3] TAdviser — Утечки данных в России — https://www.tadviser.ru/index.php/Статья:Утечки_данных_в_России

[4] Anti-Malware — Обзор рынка систем управления привилегированным доступом (PAM) — 2025 — https://www.anti-malware.ru/analytics/Market_Analysis/PAM-Market-2022

[5] Positive Technologies — Утечки конфиденциальных данных из организаций: второе полугодие 2024 года — https://ptsecurity.com/research/analytics/utechki-dannyh-aktualnye-ugrozy-vtorogo-polugodiya-2024-dlya-organizaczij/

[6] Innostage — Что такое PAM — система управления привилегированным доступом — https://innostage-group.ru/press/blog/review/chto-takoe-pam-sistema-upravleniya-privilegirovannym-dostupom/

[7] SecurityLab — $244 000 000 за шифрование. VPN-инфраструктура теперь — бесплатный банкомат для хакеров — https://www.securitylab.ru/news/566188.php

[8] Anti-Malware — Удалённый доступ в 2025: новые требования ФСТЭК России, Zero Trust и контроль подрядчиков — https://www.anti-malware.ru/analytics/Technology_Analysis/Remote-Access-in-2025-AM-Live

[9] SpectrumData — Zero Trust: что это, принцип модели нулевого доверия и внедрение — https://spectrumdata.ru/blog/proverka-soiskatelya/zero-trust-chto-eto-takoe-kak-rabotaet-printsip-nulevogo-doveriya-i-kak-vnedrit-ego-v-kompanii/

[10] Habr / USSC — Zero Trust Network Access: концепция, практика и российские реалии — https://habr.com/ru/companies/ussc/articles/939204/

[11] JumpCloud — What is a Jump Server / Bastion Host? Complete Technical Guide — https://jumpcloud.com/it-index/what-is-a-jump-server-bastion-host

[12] Wikipedia — Bastion host — https://en.wikipedia.org/wiki/Bastion_host

[13] Lunavi — Understanding Jumpboxes, Jump Servers, Bastion Hosts, and Azure Bastion — https://www.lunavi.com/blog/understanding-jumpboxes-bastion-hosts-and-azure-bastion

[14] Habr / RUVDS — Архитектура SSH. Узел-бастион и принцип нулевого доверия — https://habr.com/ru/companies/ruvds/articles/720244/

[15] IT Bastion — Что такое PAM — система управления привилегированным доступом — https://it-bastion.com/blog/chto-takoe-pam-sistema-i-zachem-ona-nuzhna/

[16] Anti-Malware — Solar SafeInspect совместим с системой MFASOFT SAS — https://www.anti-malware.ru/news/2025-10-08-111332/47622

[17] CNews — Привилегированный доступ: тренды угроз и прогноз рынка PAM-систем — https://safe.cnews.ru/news/line/2024-02-01_privilegirovannyj_dostup

[18] RT-Solar — PAM система Solar SafeInspect — https://rt-solar.ru/products/solar_safeinspect/

[19] iTPROTECT — Решения для контроля привилегированных пользователей (PAM-системы) — https://itprotect.ru/solutions/upravlenie-dostupom/pam/

[20] TAdviser — BI.Zone ZTNA (Zero Trust Network Access) — https://www.tadviser.ru/index.php/Продукт:BI.Zone_ZTNA_(Zero_Trust_Network_Access)

[21] Anti-Malware — К 2025 году объем рынка PAM в России может превысить 2 млрд рублей — https://www.anti-malware.ru/news/2024-02-01-114534/42728

[22] Kontour.Normativ — Приказ ФСТЭК РФ от 25.12.2017 N 239 — редакция от 28.08.2024 — https://normativ.kontur.ru/document?moduleId=1&documentId=481283

[23] ComNews — «Ростелеком-Солар» взял под контроль привилегированный доступ — https://www.comnews.ru/content/224902/2023-03-21/2023-w12/rostelekom-solar-vzyal-pod-kontrol-privilegirovannyy-dostup

[24] Habr / Positive Technologies — Данные на свободе: громкие утечки второй половины 2024 года — https://habr.com/ru/companies/pt/articles/894780/

[25] rezbez.ru — Рекомендации по контролю изменений в IT-инфраструктуре — https://rezbez.ru/article/rekomendaczii-po-kontrolyu-izmenenij-v-it-infrastrukture

[26] BI.ZONE — Приказ ФСТЭК России № 117: новый этап защиты информации в госсекторе — https://bi.zone/expertise/insights/prikaz-fstek-rossii-117-novyy-etap-zashchity-informatsii-v-gossektore/

[27] passwork.ru — Кибератаки 2025: статистика, векторы атак и главные уязвимости — https://passwork.ru/blog/kiberataki-2026/

[28] Interfax — Минцифры подтвердило, что не было утечки чувствительных данных абонентов «Ростелекома» — https://www.interfax.ru/digital/1003987

[29] SecurityLab — 767 млн украденных записей, 250 взломов и 27 новых APT-групп. Главное из отчета F6 — https://www.securitylab.ru/news/568827.php