По данным BI.ZONE, почти треть инцидентов с шифрованием в России в 2025 году пришлась на атаки через подрядчика.

Не через FW-периметр, а через легитимный канал: учетку внешнего исполнителя, общую сеть, привилегии, выданные под задачу и оставшиеся навсегда. Это разбор-практикум: как избежать подобного с помощью модели Zero Trust и как строится  подрядный доступ, и как собрать такой контур у себя. Без теории ради теории — каждый слой идет с конкретными шагами, готовыми скриптами и проверкой, что у вас уже работает, а что нет. Материал для тех, кто проектирует или эксплуатирует доступ внешних исполнителей: ИБ-инженеров, архитекторов, системных администраторов.

Zero Trust для подрядного доступа строится по четырем слоям: Identity (кто подключается), Device (с какого устройства), Access (к чему и как) и Monitoring (что делал). Пройдем каждый слой по шагам: от IdP и MFA до Posture Check, ZTNA и VDI, PAM и мониторинга на SIEM, UEBA (User and Entity Behavior Analytics, аналитика поведения пользователей и сущностей) и SOAR, с кейсами, цифрами, схемами и двумя рабочими bash-скриптами для Linux.

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

Вводная ситуация

Представим гипотетическую ситуацию. Вечер пятницы, интегратору некоего сервиса срочно нужен доступ: критический патч, иначе утром сервис не поднимется. Самый быстрый способ — открыть корпоративную сеть и выдать root на сервере. Одно обновление, исполнитель сделает и отключится. Отключится же? 

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

Каждый шаг здесь в моменте выглядит обоснованным. Проблема не в конкретном решении, а в том, что у доступа нет трех вещей: срока жизни, привязки к задаче и наблюдаемости. Именно их и добавляет Zero Trust, и именно это мы соберем по слоям дальше.

Последние пару лет к Zero Trust заказчиков все чаще подталкивает не CISO, а CFO: ему надоело платить за просроченные договоры с подрядчиками, часы SOC «по факту» и аудиторские замечания по управлению правами. У безопасности появилась экономика, и она оказалась убедительнее риск-метрик.

Дальше по порядку: как изменилась картина атак, почему классические механизмы плохо защищают подрядный доступ и как пошагово собирается Zero-Trust-архитектура.

Часть первая. Бизнес-проблематика и концепция

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

Когда в компании говорят: «У нас проблема с подрядчиками», обычно имеют в виду три вещи: сроки, качество и оплату. Про кибербезопасность вспоминают реже, а зря.

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

Именно сочетание внутренних прав и внешнего контроля над машиной делает подрядчика самым привлекательным каналом атаки в 2026 году. Атакующему не нужно ломать ваш периметр. Ему достаточно купить учетку одного из ваших подрядчиков на теневом форуме.

Анатомия типичной атаки

Вот сценарий, который повторяется с минимальными вариациями:

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

Инфостилер собирает все подряд: сохраненные пароли в браузере, сессионные токены, ключи SSH, учетные данные к корпоративным сервисам. Потом передает это оператору, а тот выставляет на теневую площадку. Свежая корпоративная учетка стоит на черном рынке несколько тысяч рублей. Учетка с доступом в конкретную компанию дороже, но все равно недорого.

Злоумышленник заходит в корпоративную сеть. Внутри сети у него ровно те права, что были у легитимного подрядчика: доступ к тестовой среде, к продовой, иногда к мониторингу. Дальше разведка, боковое движение, поиск привилегированных учеток. В среднем между заражением и обнаружением проходит 258 дней по данным IBM Cost of a Data Breach Report 2024. Для атак с украденными учетками срок еще больше: 292 дня. То есть больше девяти месяцев атакующий сидит в вашей инфраструктуре — и никто не замечает.

Главный вывод этой схемы в том, что защита периметра вам не поможет. Атакующий вообще не пробивает периметр, он заходит через легитимный канал с легитимной учеткой. С точки зрения вашей инфраструктуры в этот момент подрядчик работает как обычно.

Что показывают отчеты за 2024–2025

Сначала общая картина того, что происходит в мире:

Доля атак через третью сторону удвоилась за 2024 год. По данным Verizon Data Breach Investigations Report 2025 (отчет самый консервативный по методологии), доля взломов через третью сторону выросла примерно с 15% в 2023 году до почти трети в 2024-м. Средний срок обнаружения инцидента — около 258 дней, для атак с украденными учетными данными — около 292 дней (IBM Cost of a Data Breach 2024). В большинстве web-атак задействованы именно украденные учетные записи, и атаки на периметр и корпоративные VPN в 2024 году выросли кратно.

Российские цифры параллельны мировым, но со своей спецификой, и для нашего контекста важнее:

Около трети инцидентов с шифрованием в России в 2025 году связаны с атаками через подрядчика, это удвоение по сравнению с 2024-м. Такую динамику фиксирует BI.ZONE DFIR в разборах реальных инцидентов (данные за первые три квартала 2025 года). Развернутая картина — в их «Ультимативном гайде по защите инфраструктуры от шифровальщиков и вайперов» и годовом отчете Threat Zone 2025.

Больше 40% российских компаний называют причиной инцидента третью сторону, и около 22% инцидентов проходят именно через цепочку поставок ПО: скомпрометированные зависимости, обновления, подрядный код. Цифры из квартального отчета Positive Technologies «Актуальные киберугрозы: IV квартал 2024 — I квартал 2025». Более свежий срез — за I полугодие 2025 года.

Количество зараженных инфостилерами систем в мире оценивается в 15 млн на конец 2024 года — именно это основной источник учеток, которые продаются на теневых площадках и потом используются атакующими для входа в корпоративные сети. Данные Kaspersky Digital Footprint Intelligence: годовой отчет по трендам даркнета показывает рост числа публикаций об утечках корпоративных баз на 40% за август — ноябрь 2024 года.

Прогноз на 2026 год от российских ИБ-компаний — рост успешных атак еще на 30–35%, с расширением фокуса с ИТ-сектора на финансы и ретейл.

Короткий вывод из всей этой статистики такой: именно подрядчик сегодня — самый вероятный вектор входа в вашу инфраструктуру. Не фишинг сотрудников, не 0-day в публичном сервисе, не подбор пароля. Именно учетка подрядчика, купленная за несколько тысяч рублей на теневом форуме. Все остальное в статье — про то, как эту дверь закрыть.

Отдельно добавим больше про российский контекст. После ухода западных вендоров (Cisco, Palo Alto, Okta, CyberArk) собирать Zero-Trust-стек приходится из отечественных компонентов. Это не недостаток, а возможность посмотреть новых вендоров: рынок ZTNA, IdP-, PAM- и SIEM-решений в РФ за 2023–2025 годы вырос существенно, появились зрелые продукты на замену. UserGate, Ideco, PT NGFW закрывают ZTNA. MaxPatrol SIEM, KUMA, R-Vision — SIEM-слой. VK Cloud и другие облачные провайдеры — инфраструктурная база для всего этого, включая готовый VDI, федеративные IdP, Managed-сервисы для SIEM. Собирать стек под ключ уже не нужно — все собирается из локального.

Zero Trust в кратком изложении

Термин появился не из маркетинга. Его ввел Джон Киндерваг из Forrester Research в 2010 году после серии атак, которые показали, что периметр больше не работает. В 2014 году Google опубликовал модель BeyondCorp, описание того, как они перестроили доступ к внутренним сервисам после атаки Operation Aurora 2009 года. В 2020 году NIST выпустил стандарт SP 800-207, закрепивший терминологию и архитектуру. В 2021-м атака на Colonial Pipeline через VPN-учетку без MFA остановила трубопровод на пять дней и стала точкой невозврата для регуляторов США.

Если коллега говорит вам: «Zero Trust — это новомодный маркетинг», покажите ему NIST 800-207. Стандарту пять лет, в США это базовое требование для государственных систем с 2021 года.

Определение Zero Trust укладывается в два предложения.

Никогда не доверяй. Проверяй каждый запрос.

Подразумевается недоверие всему: сети, устройству, даже валидной учетке. Каждый запрос — отдельная проверка.

На практике это означает три вещи.

• Личность. Кто это? Доказывается через корпоративный провайдер идентификации (IdP) и многофакторную аутентификацию на каждый запрос, а не один раз за рабочий день.

• Контекст. С какого устройства? Из какой сети? В какое время? Если подрядчик обычно заходит из Санкт-Петербурга в рабочие часы, а сейчас запрос пришел из Каира в три ночи, система должна это увидеть и реагировать.

• Минимальные права. Что разрешено сделать сейчас? Только под конкретную задачу, на ограниченное время. Не «есть доступ к проду всегда», а «есть доступ к таблице X на четыре часа под тикет № 12 345».

Как это работает на практике

Если развернуть определение в архитектуру, получается такой путь одного запроса от подрядчика до ресурса:

1. Подрядчик инициирует запрос. Пытается достучаться до конкретного приложения: CRM, базы, консоли мониторинга.

2. Запрос попадает на Identity-проверку: IdP и MFA. Здесь же федерация. Учетка может быть из IdP подрядной организации, доказательство через SAML- или OIDC-токен. Если токен валидный и MFA пройдена, идем дальше.

3. Дальше Device-проверка — Posture Check. Версия ОС, актуальность патчей, наличие EDR, шифрование диска. Если устройство не соответствует политике, не пускают.

4. Если первые две проверки прошли, запрос приходит на Policy Engine. Это сердце Zero Trust. Движок принимает решение на основе всех вводных: Identity ОК, Device ОК, контекст подходит, время рабочее, ресурс соответствует роли. Решение: разрешить, потребовать Step-up-аутентификации или отказать.

5. Если разрешено, подключение идет через ZTNA или VDI. Не открытие сетевого канала, а проксирование конкретного приложения. Подрядчик работает с приложением. Все действия пишутся.

6. Параллельно идет мониторинг. На каждом шаге события идут в SIEM. UEBA анализирует отклонения. SOAR может автоматически прервать сессию по правилам.

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

Что это дает бизнесу

На одном из воркшопов для ИБ-директоров меня спросили в лоб: «А как объяснить CFO, зачем тратить на это весь годовой бюджет ИБ, если „все и так работает“?» Отвечаю всегда одно и то же: покажите ему счет за последний аудит ФСТЭК и скажите, что в следующем году он вырастет в полтора-два раза. Потом покажите отчет SOC за квартал с инцидентами, которые разгребались вручную. Если CFO считает деньги, а не страхи, он одобрит бюджет. Вот четыре строки, которые он обычно видит.

Сокращение среднего срока обнаружения инцидента. При правильном мониторинге аномалии видны в течение часов, а не 258 дней. По IBM CODB, каждый дополнительный месяц обнаружения добавляет 8–12% к стоимости инцидента.

Автоматизация оффбординга. Подрядчик увольняется у себя, через федерацию закрывается у вас. Без ручной работы HR, без забытых учеток, без аккаунтов-призраков в AD.

Управляемый аудит. Проверка ФСТЭК, ЦБ или внутренний аудит закрываются выгрузкой отчета из системы, а не ручным сбором. Замечания по УПД обычно падают до нуля в течение полугода после внедрения.

Снижение нагрузки на SOC. Автоматическое реагирование через SOAR дает минус 100 дней к медианному времени локализации инцидента. Это цифра из IBM CODB для компаний с AI в SOC: 31% организаций получают статистически значимое ускорение.

Отдельно про регуляторику. ФСТЭК в последние два года фактически толкает отрасль к Zero Trust, даже если в методичках этот термин не звучит. Приказы №17, 21, 31 требуют сегментации, управления правами, журналирования всех действий привилегированных пользователей. 187-ФЗ и методички по КИИ 2025–2026 явно выделяют подрядчиков и третьих лиц как отдельный источник риска. ГОСТ Р 57580 для финсектора содержит требования к MFA и логированию, которые вне Zero-Trust-архитектуры не реализуются. Компании, которые начали движение к ZT в 2024 году, закрывают аудит в 2026-м быстрее и дешевле. Те, кто откладывал, получают замечания и продлевают сроки.

Стоимость внедрения зависит от размера. По моим наблюдениям в проектах:

• Малый бизнес (до 100 сотрудников, 10–30 подрядчиков): базовое закрытие за 2–3 месяца силами одного инженера ИБ. Корпоративный IdP с обязательной MFA, запрет локальных учеток подрядчикам, один процесс онбординга и оффбординга.

• Средний бизнес (100 – 1 000 сотрудников, 50–300 подрядчиков): 9–12 месяцев, команда 2–4 инженера плюс вендор. Федерация с подрядчиками, ZTNA вместо общего корпоративного VPN, PAM для привилегированных сессий, SIEM с корреляциями.

• Крупный бизнес (1 000+, сотни подрядных организаций): 18–24 месяца, выделенная команда от 10 человек. Полный стек IdP + ZTNA + VDI + PAM + SIEM + UEBA + SOAR, автоматизация Lifecycle через SCIM, интеграция с HR, программа третьих лиц (TPRM).

Если вендор обещает «Zero Trust за три недели» в крупной организации, это звоночек. Если внутренняя команда оценивает проект в пять лет, это другой звоночек, но уже про бюджет и внимание руководства.

На этом бизнес-часть заканчивается. Дальше техническая архитектура для тех, кто будет ее собирать. Если вы приняли решение: «Да, нам это нужно», читайте дальше. Если решили: «Нам пока не нужно», я понимаю. Но напомню цифры из начала: по прогнозам российских ИБ-компаний, в ближайший год значительная часть бизнеса столкнется с инцидентом через подрядчика. Вторая часть поможет хотя бы понять, что должна делать ваша команда, когда это случится.

Часть вторая. Техническая архитектура по слоям

Zero Trust состоит из четырех слоев контроля: Identity (кто подключается), Device (с какого устройства), Access (к чему и как), Monitoring (что делал). Слои внедряются параллельно, а не последовательно. Ниже по каждому слою: что внутри, как собирается, где типовые ошибки.

Слой Identity. Личность подрядчика

Identity — фундамент. Без него остальные слои строятся на песке.

У подрядчика есть собственная учетка в его корпоративном IdP, не в вашем. Вы никогда не создаете локальных учеток для подрядчиков в своем Active Directory или IdP. Это первое и главное правило.

Связь между IdP подрядной организации и вашим IdP строится через SAML- или OIDC-федерацию. Технически это означает, что ваш IdP доверяет токенам, подписанным IdP подрядчика, при условии корректного обмена метаданными и периодической ротации ключей.

Дальше MFA. Здесь важна не просто «двухфакторка», а фишинг-устойчивая модель. SMS не подходит: атаки типа SIM Swap массово успешно проводятся за сутки. TOTP лучше, но поддается MFA Fatigue-атакам. Рабочие варианты: FIDO2/WebAuthn (эталонное решение по NIST), Passkey (поддерживается всеми крупными IdP), аппаратный токен (для критичных сценариев).

Risk-based Authentication анализирует контекст запроса: геолокация, время, устройство, скорость изменения факторов. Если подрядчик обычно заходит с одного IP-диапазона в Санкт-Петербурге, а сейчас запрос пришел из Сербии через пять минут после предыдущей сессии в России, движок потребует Step-up MFA или откажет. Решение принимает не человек, а правила и ML-модель.

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

Частая ситуация. Подрядчик-интегратор работал с CRM банка около года. Уволился у себя, но его учетка в Active Directory заказчика осталась активной, никто не уведомил. Через какое-то время учетку продали на форуме. Заказчик обнаружил инцидент еще через несколько месяцев, когда увидел странные запросы к базе клиентов. Прямая причина: не было связки между HR подрядчика и IdP заказчика. Решение: SAML/OIDC-федерация плюс автоматический триггер на де-провижен. Технически работа на две недели для инженера, который умеет настраивать корпоративный IdP. Организационно — несколько месяцев согласования с юристами подрядчика по поводу передачи HR-событий. Это нормально, это стандартный срок.

Если хотя бы один подрядчик у вас логинится через локальную учетку в AD, это первое, что нужно убрать.

На конференции в прошлом году сисадмин крупной страховой подошел ко мне в кулуарах: «Мы три года внедряем PAM, а подрядчики все равно ходят под общими техническими учетками. Почему не работает?» Я ответил: «Потому что без IdP с федерацией PAM — это журнал событий, а не система доступа. Сначала фундамент, потом привилегии, а не наоборот». Он вернулся к команде и через полгода рассказал, что именно так и пошли: сначала федерация, потом MFA, потом PAM, и только тогда все встало на места.

Слой Device. Устройство подрядчика

Про Device у меня короткий рассказ и дальше конкретика.

Самый частый вопрос, который я слышу от технических директоров на этом слое: «А можно просто выдать подрядчикам наши ноутбуки?» Можно. Это самый безопасный вариант. Корпоративный ноутбук с MDM и EDR стоит в районе шестизначной суммы в год с учетом софта и обслуживания. Умножьте на количество ваших подрядчиков. Если итоговая сумма заметно меньше вашего годового бюджета ИБ, делайте. Если сравнима или больше, переходим к альтернативам.

Первая альтернатива — VDI. Подрядчик работает со своей машины, но подключается к виртуальному рабочему столу в вашем контуре. Все, что он видит, запускает и скачивает, происходит внутри виртуалки. Его локальная машина становится тонким клиентом без возможности копировать данные или ставить что-либо в ваш контур. Технически подходит любое VDI-решение — от On-Premise-продуктов (Termidesk, Basis.WorkPlace, Space) до облачных. Если нужен VDI без разворачивания инфраструктуры, есть Managed-варианты: например, Cloud Desktop на платформе VK Cloud позволяет подключить подрядчика к изолированному рабочему столу за минуты.

Вторая альтернатива — Posture Check со своей машины. Перед подключением агент проверяет состояние устройства: версия ОС не ниже N, критичные патчи установлены, диск зашифрован штатными средствами ОС, EDR работает и репортит в ваш SIEM, антивирусные базы не старше недели. Если все ОК, выдается ZTNA-доступ к разрешенным приложениям. Если что-то не так, перенаправление на VDI. Если и VDI не поднимается, отказ с сообщением пользователю: что именно не так и как чинить.

Именно эта развилка на три варианта — главная идея Device-слоя. Без среднего варианта (VDI) у вас бинарный выбор «свои/чужие», и подрядчик при малейшем несоответствии теряет возможность работать. С VDI покрываются 80% кейсов: подрядчик работает с любой машины, но ваши данные не покидают контур.

Кейс с контрпримером. Промышленное предприятие из числа крупных игроков отрасли, работа с АСУ ТП. Руководство ИБ запретило подрядчикам-интеграторам подключаться со своих ноутбуков: «Безопасность важнее удобства». Формально политика соответствовала 187-ФЗ. Интеграторы стали писать код у себя, тестировать на своем стенде и переносить готовые конфигурации через USB-носители в контур предприятия. Это создало дыру больше, чем оригинальная: неизвестный код с неизвестной машины заливался в продакшен в обход всех контролей. После внедрения VDI для подрядчиков за несколько месяцев: код пишется в VDI, тестируется там же, USB-носители не нужны. Стоимость VDI для команды интеграторов оказалась сравнима со средней корпоративной подпиской на софт. Стоимость потенциального инцидента в контуре АСУ ТП — остановка производства, штрафы регулятора, прямые потери. Порядок цен несопоставим.

Вывод простой: безопасность, которая заставляет людей изобретать обходы, — это не безопасность, а театр.

Слой Access. Сегментация, минимум прав, JIT

Access — это самый инструментальный слой. Здесь происходит замена классических технологий на Zero-Trust-альтернативы.

Четыре механики работают вместе.

Сегментация выносит третьих лиц в отдельную сетевую зону, изолированную от продакшена. Между зонами запрет по умолчанию, разрешения описаны явно. Технически это может быть VLAN с правилами межсетевого экрана, микросегментация на уровне гипервизора или Service Mesh с mTLS между микросервисами. Выбор зависит от инфраструктуры, принцип один: подрядчик физически не может достучаться до ресурсов, которые ему не нужны для работы.

ZTNA заменяет корпоративный VPN. Это главная замена во всей архитектуре. Сквозной VPN дает доступ ко всей сети, подрядчик видит сетевое окружение и может его сканировать. ZTNA дает доступ к конкретному приложению. Подрядчик подключается к брокеру, брокер по политике выдает тоннель к одному порту одного сервиса. Остальное даже не видно, как будто не существует.

Разница в модели доверия, а не в производительности. ZTNA на практике часто быстрее VPN, потому что трафик идет через распределенную сеть брокеров, а не через один концентратор.

Что есть на российском рынке. После ухода западных вендоров ZTNA-решения собирают в России из нескольких источников. Из сетевого оборудования с ZTNA-функциональностью — UserGate, Ideco NGFW с NAC-клиентом, PT NGFW от Positive Technologies. Из специализированных продуктов по управлению привилегированным доступом — BI.ZONE PAM, Solar inRights (SafeInspect), «АйТи Бастион» СКДПУ. VDI как дополнение к ZTNA — Termidesk, Basis.WorkPlace, Cloud Desktop на VK Cloud. Для большинства компаний вопрос не «есть ли российское решение», а «как собрать стек из нескольких продуктов и интегрировать их между собой». Это сделало архитектурную часть проекта дороже интеграции, но дешевле лицензий — баланс все равно в плюсе для заказчика.

Непопулярное мнение. Классическая корпоративная сеть в 2026 году — это не уязвимость, это технологический долг. Его можно годами латать, докручивать MFA, сегментировать сеть костылями, но фундаментальная модель «впустили внутрь, дальше доверяем» была придумана для эпохи, когда подрядчик приезжал в офис с флешкой. Если вы еще держите общих подрядчиков в корпоративной сети вы субсидируете черный рынок учеток. Мой тезис такой: в 2026 году доступ в корпоративную сеть допустим только для штатных сотрудников и только как транспорт. Любой подрядный доступ должен идти через ZTNA или VDI. Точка.

JIT-доступ ломает модель, при которой права копятся годами. Не «у подрядчика есть доступ к продовой базе всегда», а «подрядчик запросил доступ для задачи № 12 345, получил на четыре часа, автоматически закрылось». Продление через новый запрос. Никаких исключений без даты «смерти» в календаре.

PAM закрывает привилегированный доступ. Если подрядчик работает с root, с базой данных или с контроллером домена, это идет через PAM-систему. Брокер подставляет пароль без показа пользователю, пишет сессию (терминальную и SQL), может прервать сессию по алерту. Подрядчик не видит учетных данных, не может их скопировать, каждое действие фиксируется.

Что облако дает для Zero Trust из коробки

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

Сегментация. VPC (Virtual Private Cloud) с подсетями, группы безопасности на уровне виртуальных машин и контейнеров. Между подсетями запрет по умолчанию, разрешения описываются декларативно — через правила вида «из dev-subnet разрешен трафик на порт 5 432 только к такой-то группе баз». Для микросервисных архитектур сверху ложится Service Mesh с mTLS между сервисами, что дает уже L7-микросегментацию. Подрядчик-разработчик подключается через ZTNA к своей dev-подсети и физически не видит прод: маршрута туда нет на уровне сети.

IAM с разграничением по ресурсам. В классической инфраструктуре «доступ подрядчика» — это постоянная учетка с паролем или SSH-ключом, который живет годами. В облаке по-другому: под задачу выделяется отдельный проект с изолированным набором ресурсов либо подрядчик приглашается в существующий проект с ограниченной ролью. Набор разрешений и конкретные ресурсы (подсети, серверы, базы) описываются один раз и дальше управляются как код — Terraform, OpenTofu, все версионируется и ревьюится наравне с обычным кодом. После завершения работ доступ отзывается одной командой через IaC или через личный кабинет. Это и есть JIT на языке облачных платформ — «доступ на задачу, не на должность».

Журналирование. Платформенные Audit-логи на каждое API-действие. Кто, когда, с какого IP, какой вызов, с какими параметрами. Логи готовы к отгрузке в ваш SIEM через стандартные интеграции. Без этой телеметрии UEBA из предыдущего раздела просто не на чем работать.

Шифрование. TLS между пользователем и сервисом по умолчанию, шифрование дисков и бэкапов, управление ключами через KMS. Это не специфично для Zero Trust, но работает в его пользу: учетка подрядчика, скомпрометированная через инфостилер, не дает атакующему расшифрованный доступ к резервным копиям или к трафику между сервисами. Одной проверкой меньше при разборе инцидента.

Как это выглядит в жизни. Вернемся к интегратору АБС из начала статьи. В облачной модели его подключение собирается так: под задачу выделяется отдельный проект в облаке с нужным уровнем разрешений, в который интегратор приглашается. В проекте только те ресурсы, с которыми он должен работать: два сервера АБС в отдельной подсети. Группа безопасности разрешает входящий трафик от ZTNA-брокера только на нужные порты. Audit-логи пишутся с первой секунды в платформенный сервис и отгружаются в корпоративный SIEM. Вся конфигурация описана в Terraform-манифесте: после завершения работ PR с удалением ресурсов уходит в репозиторий, апплайнится через CI — и проект исчезает вместе с учетками. В следующий раз, когда интегратор попросит доступ, проект разворачивается заново из того же манифеста под новый тикет. Никаких постоянных учеток.

Что облако не закрывает: ZTNA-брокер для подрядного удаленного доступа, PAM-систему с записью сессий, UEBA-движок для поведенческой аналитики. Эти компоненты внешние, но интегрируются с облаком через стандартные протоколы: SAML/OIDC для аутентификации, SCIM для синхронизации пользователей, API для управления политиками. То есть собирать Zero Trust с нуля не приходится: платформа закрывает базовый периметр, специализированные системы наслаиваются сверху через документированные интерфейсы.

Что делать, если полноценного PAM еще нет. Минимальная гигиена на Linux-серверах, куда подрядчики ходят по SSH, — поставить TOTP на sudo. Подрядчик вводит пароль, потом шестизначный код из любого TOTP-совместимого приложения-аутентификатора. Инфостилер с его рабочей станции унесет пароль, но без второго фактора атакующий не получит root.

Скрипт ниже разворачивает TOTP на sudo для указанных пользователей, с бэкапом конфига PAM и режимом nullok на период миграции (пользователи без настроенного секрета продолжают работать без TOTP, пока не настроят).

Когда и как запускать. Это разовая настройка на каждом Linux-сервере, не в cron. Запускается один раз при вводе сервера в эксплуатацию или при первой волне подключения подрядчиков к существующему серверу. Сохраните скрипт как enable-sudo-otp.sh, сделайте исполняемым (chmod +x) и запустите от root с перечислением пользователей, которым нужен TOTP:

sudo ./enable-sudo-otp.sh ivanov_contractor petrov_devops

Скрипт сделает бэкап /etc/pam.d/sudo, добавит туда строку auth required pam_google_authenticator.so nullok и для каждого указанного пользователя сгенерирует TOTP-секрет с QR-кодом прямо в терминале. Подрядчик сканирует QR-код в свое приложение-аутентификатор, сохраняет Emergency-коды в безопасное место, подтверждает каждый вопрос установщика — готово. Со следующего вызова sudo система попросит код.

Флаг nullok на период миграции важен: пока вы обходите 50 серверов и собираете подрядчиков на настройку TOTP, те, у кого секрет еще не сгенерирован, продолжают работать по-старому. Когда все настроили, вручную уберите nullok из /etc/pam.d/sudo на каждом сервере. Удобно пройтись через Ansible-плейбук одной командой lineinfile.

#!/bin/bash

# enable-sudo-otp.sh — MFA на sudo через google-authenticator

# Запуск: sudo ./enable-sudo-otp.sh contractor1 contractor2

set -euo pipefail

[[ $EUID -ne 0 ]] && { echo "Нужен root"; exit 1; }

[[ $# -eq 0 ]] && { echo "Usage: $0 user1 [user2 ...]"; exit 1; }

SUDO_PAM=/etc/pam.d/sudo

BACKUP=/root/sudo-pam-backup-$(date +%Y%m%d-%H%M%S)

# 1) Пакет

if ! command -v google-authenticator &>/dev/null; then

    if command -v apt-get &>/dev/null; then

        apt-get update -q && apt-get install -y libpam-google-authenticator

    elif command -v dnf &>/dev/null; then

        dnf install -y epel-release && dnf install -y google-authenticator

    else

        echo "Не узнал пакетный менеджер"; exit 1

    fi

fi

# 2) Бэкап и активация PAM-модуля

[[ -f "$SUDO_PAM" ]] || { echo "Нет $SUDO_PAM. Установлен ли sudo?"; exit 1; }

cp "$SUDO_PAM" "$BACKUP"

if ! grep -q "pam_google_authenticator" "$SUDO_PAM"; then

    # nullok = пропускать пользователей без .google_authenticator (для миграции)

    sed -i '1i auth required pam_google_authenticator.so nullok' "$SUDO_PAM"

fi

# 3) Генерация TOTP-секрета и QR для каждого пользователя

for user in "$@"; do

    id "$user" &>/dev/null || { echo "Нет user $user"; continue; }

    HOME_DIR=$(getent passwd "$user" | cut -d: -f6)

    [[ -f "$HOME_DIR/.google_authenticator" ]] && continue

    # -t TOTP, -d запрет повторного кода, -r 3 -R 30 rate-limit,

    # -w 3 допуск по времени, -Q UTF8 QR в консоль

    su - "$user" -c "google-authenticator -t -d -f -r 3 -R 30 -w 3 -Q UTF8"

    chmod 400 "$HOME_DIR/.google_authenticator"

done

echo "Проверка: sudo -k && sudo -v  (должен запросить код)"

echo "Откат: cp $BACKUP $SUDO_PAM"

echo "Когда все настроили TOTP — убрать 'nullok' в $SUDO_PAM"

Что еще стоит сделать рядом — форвардить события pam_google_authenticator в SIEM через auditd или rsyslog. Каждая неудачная попытка TOTP — сигнал о том, что либо учетка компрометирована, либо подрядчик потерял телефон. В обоих случаях нужен ручной процесс восстановления, а не автоматический сброс.

Для массового разворачивания на парке серверов оберните скрипт в Ansible-роль или вашу систему управления конфигурацией (SaltStack, Puppet). Ручной обход SSH-сессий работает для 5 серверов, не для 50. Список подрядчиков, которым нужно включить TOTP, берите из вывода второго скрипта ниже (audit-contractors.sh) — там статус SUDO_NO_MFA у тех, кого надо обработать в первую очередь.

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

До Zero Trust: общая корпоративная сеть для всех, AD-учетки с паролями в таблице у тимлидов, логирование только на критичных серверах, HR не связан с деактивацией в ИТ, типичный отзыв доступа уволенного подрядчика — от одного до трех месяцев. 

После девяти месяцев внедрения: ZTNA плюс VDI для подрядчиков, корпоративный VPN только для штатных сотрудников, федерация с IdP подрядных организаций, PAM с записью для всего привилегированного, SIEM-корреляция и автоматические Response-сценарии.

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

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

Слой Monitoring. Что происходит

Про Monitoring расскажу на примере одного алерта. Это нагляднее, чем список компонентов.

Глубокая ночь. Подрядчик-разработчик из удаленного региона логинится в ваш IdP. Ничего необычного: он часто работает поздно. IdP пишет событие логина в SIEM. Через минуту тот же подрядчик подключается к ZTNA-брокеру и открывает доступ к Production-базе клиентов. Разрешенная операция по его профилю.

Здесь вступает UEBA. Поведенческий движок смотрит на профиль подрядчика: средний объем скачанных данных за сессию за последние 90 дней — около сотни мегабайт. Обычное время работы с продом — дневные часы. Текущая сессия: середина ночи, скачано уже несколько гигабайт за минуты. Отклонение от профиля по трем метрикам одновременно: время, объем, скорость.

UEBA генерирует алерт с высокой оценкой аномалии. Алерт попадает в SIEM, где коррелируется с другими событиями: неделю назад с этой учетки было несколько неудачных логинов с IP в соседней стране. Сам по себе факт неудачного логина — норма, люди ошибаются в паролях. В сочетании с текущей аномалией — признак компрометации.

SIEM отправляет Correlated Alert в SOAR. У SOAR есть правило: если аномалия UEBA выше порога плюс есть неудачные логины за последние две недели — блок учетки, отзыв всех сессий ZTNA, уведомление в SOC, Step-up MFA при следующем логине. Без участия человека в ту же минуту. Учетка заморожена, активные сессии ZTNA разорваны, данные больше не уходят.

SIEM отправляет Correlated Alert в SOAR. У SOAR есть правило: если аномалия UEBA > 0,9 плюс есть неудачные логины за последние 14 дней, блок учетки, отзыв всех сессий ZTNA, уведомление в SOC, Step-up MFA при следующем логине. Без участия человека в 2:48 ночи. Учетка заморожена, активные сессии ZTNA разорваны, данные больше не уходят.

Дежурный SOC получает пуш через минуту. Открывает консоль, видит историю: логин, начало скачивания, триггер UEBA, автоматический блок. Все уже сделано. Его задача — подтвердить или откатить. Он звонит подрядчику по номеру из договора (не из email-подписи, атакующий мог ее подменить). Подрядчик не отвечает. Эскалация в ИБ-руководство, запуск IR-процедуры.

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

Что здесь сработало:

1. Telemetry. IdP, ZTNA и SIEM писали события, без которых корреляция невозможна.

2. UEBA. Знала нормальное поведение подрядчика и увидела отклонение по трем метрикам.

3. SIEM-correlation. Сложила текущую аномалию с предыдущими неудачными логинами.

4. SOAR. Действовал автоматически за минуты, без человека.

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

Первые 15 минут инцидента

Отдельно практический Runbook для команд SOC. Когда срабатывает алерт, первые 15 минут определяют, будет ли это инцидент или локализованная история.

• 0–2 минуты. Триггер. Алерт от UEBA, звонок бизнес-владельца или уведомление от подрядчика. Фиксируем время, идентификатор инцидента, источник сигнала. Критично для последующего Forensics.

• 2–5 минут. Изоляция. SOAR замораживает учетку в IdP, рвет все активные сессии ZTNA и VDI, отзывает OAuth-токены. Доступ прекращен. Если делается вручную, не успеете.

• 5–8 минут. Проверка периметра. Логи SIEM за 72 часа: куда ходила учетка, какие данные скачивала, какие изменения делала. Собрали список затронутых систем.

• 8–12 минут. Подтверждение. Звоним подрядчику по номеру из договора. Не из подписи в email, не из телеграм-профиля: эти каналы атакующий мог подменить за час. Он на связи и объясняет активность, фиксируем, восстанавливаем. Нет — эскалация.

• 12–15 минут. Решение. Восстановление учетки со Step-up MFA и повышенным мониторингом или перевод в режим полного расследования: уведомление ИБ-руководства, запуск IR-процедуры, при необходимости эскалация в НКЦКИ, если вы субъект КИИ.

Этот Playbook можно распечатать и положить рядом с монитором дежурного SOC. Пятнадцать минут от алерта до принятия решения — реалистичная цель, если автоматизация на месте.

Типовые ошибки внедрения

Пять антипаттернов, которые я вижу почти в каждом проекте.

«Начнем с PAM, это главное». Нет. Без IdP и базовой гигиены MFA PAM будет стоять в углу. Это важный компонент, но без фундамента Identity он не работает.

«Купим ZTNA, и все решится». ZTNA без прописанных политик работает как виртуальная приватная сеть, только дороже и с вендорлоком. Политики пишутся под ваши роли и ресурсы. Это работа команды, не вендора.

«Подрядчики возмутятся, упростим для них». Уступки ломают модель. Сделали отдельный «упрощенный вход для партнеров» — через него будут приходить гости. Один раз настройте UX: SSO, Passkey, быстрый VDI. Сопротивление проходит за две недели, если не заставлять подрядчиков заводить пять паролей.

«У нас маленькая компания, это не для нас». Автоматизация атак сканирует IP-диапазоны. Ей все равно, десять у вас сотрудников или десять тысяч. Учетка в небольшой компании часто стоит дешевле и используется как плацдарм для атак на клиентов этой компании.

«Сделаем один раз и забудем». Права гниют за три месяца: увольняются люди, меняются роли, появляются новые системы. Zero Trust — это процесс, не проект. Нужен владелец с фамилией, календарем и KPI.

Любое «временное исключение» без даты «смерти» в календаре становится постоянным. Это закон, не наблюдение.

Идеальная картина мира

Когда все четыре слоя работают вместе, картина выглядит так:

Помните интегратора из начала статьи? В этой картине мира он заходит не в пятницу в 22:00 через общую корпоративную сеть с root-правами. Он заходит через федерацию своей подрядной организации. MFA на Passkey проходит за три секунды. Posture Check его машины говорит: «ОК, ноутбук в порядке». ZTNA выдает тоннель к одному приложению, системе АБС, на четыре часа под тикет в его Jira. PAM пишет каждую команду в терминале. SIEM собирает события. UEBA сравнивает с профилем: «Интегратор, пятница, вечер, работа с АБС, в норме». Алертов нет.

В понедельник утром у подрядчика в его компании начинается отпуск. HR-событие через IdP подрядчика приходит в ваш IdP. Через 30 секунд его учетка у вас деактивирована, активные сессии разорваны. Он ничего не помнит про этот процесс, потому что это не его работа. Вы ничего не делаете руками, потому что это автоматика.

Через три месяца его учетку пытаются использовать с теневого форума. Она уже не работает: нет токена федерации, нет Posture Check, нет ничего. Атакующий платит за мертвую учетку несколько тысяч рублей и списывает это как издержки.

Что видит подрядчик в этой картине. Один логин через его корпоративный аккаунт. Только нужные ему приложения. Доступ за минуты, без писем и тикетов. Ничего не помнит и не настраивает, все работает само.

Что видит CISO. Поименный учет всех подрядчиков, их устройств и действий. Автоматическая реакция на любой инцидент за минуты. Аудит ФСТЭК или ЦБ закрывается выгрузкой отчета. Отзыв доступа уволенного подрядчика без ручной работы.

Главный признак того, что Zero Trust работает, — о нем перестают разговаривать. Безопасность стала фоном, как электричество в розетке, а не препятствием для работы.

Сейчас в России такая картина собрана примерно у 10% компаний. Если у вас не так, впереди работа на 12–24 месяца с понятным планом и измеримыми метриками. Если уже так, поздравляю, вы один из десяти процентов.

Что делать на следующей неделе

Вот пять действий, которые можно начать сразу.

1. Выгрузить все активные подрядные учетки и их права из AD, IdP, приватной сетии всех остальных систем в одну таблицу

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

По Linux-серверам это быстрее всего сделать скриптом. Ниже — минимальная инвентаризация: кто есть, когда последний раз заходил, есть ли у него sudo, настроен ли TOTP. Запускается на каждом хосте, вывод в TSV, потом все сводится в одну таблицу через cat *.tsv | sort -u.

Два режима использования:

• Разовый аудит. Если вы только начинаете наводить порядок, достаточно один раз пройти по всем серверам, собрать TSV, свести в одну таблицу и сверить со списком договоров. Это то, что закрывает первый пункт из блока выше.

• Регулярный аудит через cron. Если порядок уже наведен, скрипт надо поставить в расписание: раз в неделю собирать свежий срез и сравнивать с предыдущим. Появилась новая учетка без договора — триггер. Появилась учетка со статусом STALE+SUDO_NO_MFA — триггер. Прописывается в /etc/cron.d/ примерно так:

0 3 * * 1 root /usr/local/bin/audit-contractors.sh > /var/log/zt-audit/$(date +\%Y-\%m-\%d).tsv

Это запускает скрипт каждый понедельник в три ночи, сохраняет отчет в /var/log/zt-audit/ с датой в имени. Логи потом забираются в SIEM стандартным Filebeat- или Rsyslog-агентом, там настраиваются алерты на изменения. В зрелой системе это один из источников данных для UEBA из предыдущего раздела.

Если SIEM пока нет, минимальная польза — отправлять TSV на почту ИБ-команде раз в неделю:

0 3 * * 1 root /usr/local/bin/audit-contractors.sh | mail -s "ZT audit $(hostname)" secteam@company.ru

Сохраните скрипт как /usr/local/bin/audit-contractors.sh, chmod +x, и дальше два варианта — разовый запуск вручную для инвентаризации или в cron для мониторинга.

#!/bin/bash

# audit-contractors.sh — инвентаризация учеток с shell-доступом

# Запуск: sudo ./audit-contractors.sh > audit-$(hostname)-$(date +%F).tsv

set -euo pipefail

INACTIVE_DAYS=30

SUDO_PAM=/etc/pam.d/sudo

NOW=$(date +%s)

printf "host\tuser\tuid\tshell\tlast_login\tdays_idle\tsudo\tmfa_on_sudo\tstatus\n"

while IFS=: read -r user _ uid _ _ _ shell; do

    # Только обычные пользователи (UID >= 1000) с интерактивным shell

    [[ $uid -lt 1000 ]] && continue

    [[ "$shell" =~ (nologin|false|sync|halt) ]] && continue

    # Последний логин. lastlog возвращает "**Never logged in**" для тех, кто не заходил.

    last_raw=$(lastlog -u "$user" 2>/dev/null | \

               awk 'NR==2 {for(i=4;i<=NF;i++) printf "%s ", $i; print ""}' | \

               sed 's/ *$//')

    if [[ -z "$last_raw" ]] || [[ "$last_raw" == "Never" ]]; then

        last_login="never"; days_idle="inf"

    else

        last_ts=$(date -d "$last_raw" +%s 2>/dev/null || echo 0)

        if [[ "$last_ts" -eq 0 ]]; then

            last_login="never"; days_idle="inf"

        else

            last_login=$(date -d "@$last_ts" +%Y-%m-%d)

            days_idle=$(( (NOW - last_ts) / 86400 ))

        fi

    fi

    # Есть ли sudo

    if groups "$user" 2>/dev/null | grep -qE "\b(sudo|wheel|admin)\b" || \

       grep -rE "^\s*$user\s+" /etc/sudoers /etc/sudoers.d/ 2>/dev/null | grep -q .; then

        sudo_flag="yes"

    else

        sudo_flag="no"

    fi

    # Настроен ли TOTP для sudo

    if grep -qE "pam_google_authenticator|pam_oath" "$SUDO_PAM" 2>/dev/null; then

        mfa_sudo="yes"

    else

        mfa_sudo="no"

    fi

    # Вердикт

    status="ok"

    [[ "$days_idle" != "inf" && "$days_idle" -gt $INACTIVE_DAYS ]] && status="STALE"

    [[ "$days_idle" == "inf" ]] && status="NEVER_USED"

    [[ "$sudo_flag" == "yes" && "$mfa_sudo" == "no" ]] && status="${status}+SUDO_NO_MFA"

    printf "%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\n" \

        "$(hostname)" "$user" "$uid" "$shell" \

        "$last_login" "$days_idle" "$sudo_flag" "$mfa_sudo" "$status"

done < /etc/passwd

На выходе вы получите таблицу со статусами вроде STALE+SUDO_NO_MFA — это худший случай, заброшенная учетка с привилегированными правами без второго фактора. Именно в нее придет атакующий, купивший учетку на форуме, если до вас не успеет прийти ФСТЭК с проверкой.

Как читать статусы. Скрипт выдает четыре возможных сочетания:

• ok — учетка активна, заходила недавно, либо без sudo, либо с MFA. Не трогаем.

• STALE — учетка не использовалась больше 30 дней. Проверить в системе учета договоров, нужна ли она. Если нет, деактивировать, не удалять (для Forensics).

• NEVER_USED — учетка создана, но ни разу не логинилась. Классический аккаунт-призрак. Почти всегда можно удалить.

• STALE+SUDO_NO_MFA или NEVER_USED+SUDO_NO_MFA — красный приоритет. Первые, к кому придет атакующий. Сначала отключить sudo, потом разбираться.

Рекомендую свести все TSV с серверов в одну Excel-таблицу и добавить колонку «связь с договором» — это и есть та сверка со списком договоров, о которой идет второй пункт ниже.

2. Сверить эту таблицу со списком актуальных договоров

В разнице будет ваша стартовая точка, с которой нужно будет начать работать.

3. Включить MFA там, где его еще нет

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

4. Принять решение на ИТ-комитете

Решите, продолжаете ли вы держать подрядчиков на общем корпоративном VPN или переводите на ZTNA либо VDI. Не откладывайте на квартал.

5. Назначить одного владельца процесса

С фамилией, календарем и KPI. Без человека, который отвечает, Zero Trust не взлетает.

После этих пяти шагов у вас уже другая стартовая позиция, чем была сегодня.

А в комментариях расскажите: на каком слое вы сейчас? Еще на общем корпоративном VPN, в середине миграции на ZTNA или уже живете с автоматическим оффбордингом через федерацию? Особенно интересно услышать от тех, кто проходил аудит ФСТЭК или ЦБ в 2025–2026: какие замечания получили по управлению правами подрядчиков и что пришлось перестраивать.