«Советы по внедрению Zero Trust обычно сводятся к списку технологий: SASE, ZTNA, микросегментация. Но в российских компаниях, особенно с госрегуляторами за спиной, сначала нужно пробиться через бюрократию и внутреннее сопротивление. Этот чек-лист — не про то, что купить. Это про то, что перестать терпеть в вашей ИТ-инфраструктуре прямо сейчас».
Почему чек-лист готовности важнее схемы развёртывания
Любой крупный вендор или интегратор готов продать вам набор технологий под маркой Zero Trust: шлюзы, агенты, средства анализа поведения. Конфигурацию можно скопировать из документации, но политику ответсвенности за доступ — нет. Внедрение превращается в фасад, если правила не соблюдаются предсказуемо и повсеместно, а лишь создают дополнительный слой сложности поверх старых уязвимостей.
Типичный сценарий: начинают с шлюза удалённого доступа (ZTNA), закрывая «парадный вход». При этом забывают, что у команды разработки для отладки остаётся старый VPN-сервер 2015 года выпуска, а в бухгалтерии сисадмин по старой дружбе открыл проброс портов на 1С напрямую из интернета. Получается двойная система: новая — для отчётов, старая — для реальной работы. Два набора логов, две точки входа и нулевое доверие со стороны сотрудников, которые быстро находят путь наименьшего сопротивления.
Готовность к Zero Trust, это не абстракция, а набор измеримых организационно-технических показателей. Например, процент автоматизации в жизненном цикле учётных записей, наличие актуальной и полной инвентаризации активов или формализованные сценарии взаимодействия с бизнес-подразделениями при изменении доступа. Если решения о правах доступа принимаются по звонку, а новые устройства появляются в сети без ведома ИБ, никакие технологии не исправят ситуацию.
Инфраструктура: что нужно пересчитать перед trust
Базовое условие — полная видимость. Многие российские компании учитывают серверы и ноутбуки, но упускают из виду сотни других сетевых устройств. IP-камеры, программируемые логические контроллеры (ПЛК) в производстве, «умный» холодильник в буфете, сетевое хранилище, купленное отделом маркетинга за свой счёт. Если устройство имеет стек TCP/IP, оно — потенциальный вектор атаки и должно быть учтено. Аудит в одной компании, сертифицированной по требованиям ФСТЭК, выявил утечку через старый ИБП с незащищённым веб-интерфейсом. Его не было в реестре, потому что «это не ИТ-оборудование».
Второй пласт — теневое IT. Сотрудники отдела маркетинга могут использовать Figma для хранения макетов, содержащих коммерческую тайну. Отдел закупок — вести переписку с поставщиками через личный мессенджер. Эти сервисы работают вне зоны контроля ИТ и ИБ: к ним не применяются политики DLP, нет журналирования действий, они не входят в схемы аутентификации. До тех пор, пока не составлена хотя бы примерная карта используемых облачных сервисов, строить политики доверия бессмысленно.
Особый вызов — унаследованные (legacy) системы, модернизация которых невозможна или крайне дорога. Например, промышленная АСУ ТП на Windows XP или финансовая система на старом Java-стеке без поддержки SAML. Они не впишутся в современную IAM. Решение — не игнорировать, а изолировать. Для них создаётся строго контролируемый сегмент сети с жёсткими правилами межсегментного взаимодействия, а доступ к управлению такими системами выделяется в отдельный, максимально защищённый процесс.
Доступы и люди: кто и зачем входит в систему
Главный вектор риска — учётные записи с расширенными правами. Речь не только об администраторах домена, но и о сервисных аккаунтах для автоматизации, временных учётках подрядчиков, дежурных инженеров. В одной организации после аудита обнаружилось 150 учётных записей с правами локального администратора на критичных серверах. Из них 40 были «мёртвыми» (не использовались более года), а 15 принадлежали сотрудникам, давно уволившимся. В модели Zero Trust любая повышенная привилегия должна быть временной, строго обоснованной и автоматически отзываемой.
Ключевое отличие от традиционного подхода — учёт контекста. Старая логика: «Сотрудник Иванов аутентифицирован — доступ ко всем системам отдела разрешён». Новая: «Сотрудник Иванов с корпоративного ноутбука в офисе в рабочее время пытается получить доступ к папке с персональными данными из CRM». Контекст формируется из десятков параметров: тип и состояние устройства (заблокирован ли экран, стоит ли антивирус), сеть (офисная, домашняя, публичный Wi-Fi), геолокация, время, история предыдущих действий. Политика должна оценивать этот набор данных в реальном времени.
Самый сложный этап — изменение культуры. Сотрудники привыкли, что доступ, это вечное право, полученное при найме. Zero Trust утверждает обратное: доступ, это временное разрешение, которое нужно доказывать перед каждой операцией. Возникает сопротивление: «Я не могу ждать одобрения, чтобы посмотреть отчёт», «Зачем сканировать мой телефон, если я уже ввёл код». Преодолеть это приказом нельзя. Нужны пилот на ограниченной группе, подробные инструкции на понятном языке (не на жаргоне ИБ) и демонстрация выгод: например, автоматический доступ ко всему необходимому с любого устройства без запроса пароля при соблюдении безопасных условий.
Роль бизнес-владельцев систем становится критичной. Именно они, а не ИБ-отдел, должны утверждать, кому и какой доступ к их CRM, ERP или системе документооборота действительно нужен для работы. Без их вовлечения ИБ либо выдаст всем права «на всякий случай», либо заблокирует бизнес-процессы.
Процессы, которые должны работать как часы
Если цикл управления доступом не автоматизирован, Zero Trust превращается в ручную сборку. Рассмотрим ключевые процессы.
Жизненный цикл учётной записи
- Создание: Должно автоматически инициироваться из HR-системы при приёме на работу. Настройка базовых прав — согласно роли в кадровой системе.
- Изменение: При переводе сотрудника в другой отдел из HR приходит сигнал — в IAM запускается скрипт отзыва старых прав и выдачи новых. Всё это должно происходить в течение часов, а не дней.
- Удаление: В день увольнения (лучше — в момент подписания приказа в электронном кадре) учётная запись блокируется, а через заданный срок (например, 30 дней для резервного копирования почты) — удаляется. Задержка в неделю, это неделя риска.
Временный (Just-in-Time) доступ
Это механизм для ситуаций, когда сотруднику нужны повышенные права на короткое время. Например, разработчику — доступ к продакшен-базе данных для расследования инцидента. В идеале процесс выглядит так:
- Сотрудник создаёт запрос в специальном портале, указывая систему, требуемую роль и обоснование.
- Запрос автоматически уходит на утверждение бизнес-владельцу системы и руководителю.
- После утверждения система IAM выдаёт права на строго ограниченный срок (например, 2 часа).
- По истечении времени доступ автоматически отзывается. Все действия под временными правами подробно журналируются.
Если этот процесс занимает полдня и требует пяти согласований, пользователи найдут обходной путь, например, попросят у коллеги пароль.
Непрерывный мониторинг и реагирование
Сбор логов — только начало. Необходим анализ аномалий в реальном времени и чёткие регламенты реагирования. Пример playbook для инцидента:
- Если пользователь в 3:00 по МСК с домашнего IP скачивает 5000 записей из базы с персональными данными, система UEBA помечает это как высокорисковое событие.
- Автоматически отправляется уведомление в SOC и владельцу данных.
- Сессия пользователя принудительно разрывается, доступ к системе блокируется до выяснения.
- В тикет-системе создаётся инцидент, который назначается конкретному аналитику.
Без таких отточенных процессов внедрение технологий даст лишь иллюзию контроля.
Чек-лист готовности: 15 пунктов для внутренней проверки
Прежде чем обсуждать с вендорами, оцените текущее состояние по ключевым векторам. Каждый отрицательный ответ — не приговор, а пункт плана подготовки.
| Категория | № | Вопрос для самооценки | Критерий прохода |
|---|---|---|---|
| Данные и активы | 1 | Существует ли актуальный автоматизированный реестр ВСЕХ сетевых устройств (включая IoT, оргтехнику, промышленное оборудование)? | Обнаружение новых устройств происходит автоматически, их инвентаризация — в течение 24 часов. |
| 2 | Проведена ли классификация информационных активов (данных, систем) по уровням критичности и секретности в соответствии с внутренними регламентами и 152-ФЗ? | Существует утверждённый классификатор, владельцы информационных активов назначены. | |
| 3 | Определены и задокументированы ключевые потоки данных между системами (например, передача ПДн из CRM в BI-систему)? | Есть схема потоков данных для критичных бизнес-процессов. | |
| 4 | Есть ли процедура выявления и учёта сервисов «теневого IT»? | Проводятся регулярные опросы отделов и анализ сетевого трафика на использование неразрешённых облачных сервисов. | |
| Идентификация и доступ | 5 | Внедрена ли многофакторная аутентификация (МФА) для всех систем, обрабатывающих персональные данные или коммерческую тайну? | МФА используется для 100% таких систем, исключения отсутствуют или строго обоснованы. |
| 6 | Работает ли централизованная система управления учётными записями и доступом (IAM/SIAM), охватывающая сотрудников, подрядчиков и партнёров? | Более 90% систем интегрированы с IAM для единого входа и управления жизненным циклом. | |
| 7 | Проводится ли ежеквартальный аудит привилегированных учётных записей (администраторы, сервисные аккаунты) с выявлением «мёртвых» и избыточных прав? | Процесс аудита формализован, результаты утверждаются руководством и исполняются. | |
| 8 | Существует ли механизм временного (JIT) предоставления прав с автоматическим отзывом? | Механизм внедрён хотя бы для одной пилотной системы, используется регулярно. | |
| Политики и управление | 9 | Существуют ли утверждённые политики доступа, реализующие принцип минимальных необходимых привилегий для каждой роли? | Политики документированы, размещены во внутреннем репозитории, доведены до сотрудников. |
| 10 | Назначены ли бизнес-владельцы для ключевых информационных систем, ответственные за санкционирование доступа? | Список владельцев и их зон ответственности утверждён приказом. | |
| 11 | Проводится ли ежегодная (или чаще) аттестация доступа — пересмотр и подтверждение прав сотрудников? | Процесс автоматизирован, отчётность по его результатам формируется для руководства. | |
| 12 | Есть ли регламент работы с внешними подрядчиками (выдача, контроль и отзыв временного доступа)? | Регламент существует и соблюдается, доступ подрядчиков логируется отдельно. | |
| Технологии | 13 | Поддерживает ли сетевая инфраструктура сегментацию на уровне, достаточном для изоляции legacy-систем и критичных активов? | Сегментация (VLAN, группы брандмауэра) реализована как минимум на уровне выделенных подсетей для разных типов систем. |
| 14 | Развёрнуты ли средства анализа поведения пользователей и устройств (UEBA) или есть техническая возможность для их внедрения? | Средства мониторинга собирают достаточно контекстных данных (логины, действия) для последующего анализа. | |
| 15 | Настроен ли централизованный сбор и хранение журналов событий безопасности (SIEM) со всех ключевых систем? | Журналы с критичных систем (AD, VPN, шлюзы, БД) стекаются в SIEM, время их хранения соответствует требованиям регуляторов. |
Если положительных ответов меньше 10, фокус должен быть на подготовке инфраструктуры и процессов, а не на закупке новых решений.
Первые шаги после чека: с чего начать изменения
Не пытайтесь внедрять Zero Trust повсеместно. Это путь к выгоранию команды и саботажу со стороны бизнеса. Выберите один контролируемый, но значимый пилотный проект. Идеальный кандидат — система, которая:
- Имеет чётких бизнес-владельцев, готовых к сотрудничеству.
- Содержит информацию ограниченного доступа (ПДн, коммерческая тайна).
- Имеет ограниченный круг пользователей (20-50 человек).
- Технически совместима с современными протоколами аутентификации.
Хороший пример — система электронного документооборота (СЭД) или портал договоров. Запустите пилот на одной группе (например, юридический отдел и финансы). В рамках пилота реализуйте:
- Централизованный вход через корпоративный портал с обязательной МФА.
- Контекстный контроль доступа: разрешите вход только с корпоративных устройств, прошедших проверку на наличие антивируса и обновлений. Блокируйте попытки входа из необычных мест или в нерабочее время.
- Принцип минимальных привилегий: пересмотрите и заново назначьте права внутри СЭД, убрав все глобальные роли «администратора» там, где они не нужны.
- Журналирование и мониторинг: настройте детальное логирование всех действий (кто, когда, какой документ открыл/скачал/изменил) и простые алерты на аномалии (массовое скачивание).
В течение 2-3 месяцев собирайте метрики: число успешных/неуспешных входов, количество запросов в техподдержку из-за новых правил, скорость выполнения типовых операций, количество срабатываний алертов. Учитесь на ошибках: если все жалуются на задержки — упростите политики для офисного доступа. Если обнаружили попытку несанкционированного доступа — усильте проверку для внешних сетей.
Собранные данные — ваш главный аргумент для масштабирования. Доклад руководству должен звучать не как «Мы купили новую систему», а как «В пилотной зоне мы сократили риск утечки документов на 80%, не замедлив работу отдела». Только после успешного завершения пилота, отладки процессов и подготовки команды можно планировать постепенное расширение на другие системы.