«Внезапное требование соответствия Zero Trust в госсекторе, это не конец, а возможность переписать правила игры. Задача кажется невозможной, пока ты не откажешься от главного мифа: что доверие, это зона. Три дня были не хаотичной сменой технологий, а переключением с географии на человека. Результат — ноль простоя не потому, что я всё спланировал, а потому, что перестал считать сеть критическим элементом».
Что скрывается за Zero Trust на практике
Термин Zero Trust превратился в модный ярлык, за которым поставщики решений предлагают всё что угодно — от VPN нового поколения до SIEM-систем. В российском контексте, особенно под давлением регуляторов ФСТЭК и требований 152-ФЗ, концепция часто сводится к формальному выполнению пунктов приказов: многофакторная аутентификация здесь, сегментация сети там. Но ядро идеи остаётся неизменным: устранение концепции доверенной сети как таковой. Не «система внутри периметра безопасна», а «каждый запрос не заслуживает доверия». Реальная сложность перехода кроется не в установке софта, а в изменении ментальной модели у всех участников процесса.
Почему «за три дня» — не преувеличение
Стандартные сценарии миграции рисуют месяцы пилотных зон, анализа потоков трафика и поэтапного отключения старых систем. Это работает, когда время не критично. Мой сценарий был другим: внезапный аудит, требование соответствия и жёсткий дедлайн. Три дня, это не «идеальный план», это время, за которое можно физически переконфигурировать ключевые системы, если отказаться от иллюзии, что нужно сначала построить идеальную схему. Секрет был в приоритизации: не внедрять всё сразу, а обеспечить непрерывность критического бизнес-процесса под новыми правилами.
Первый день: инвентаризация и выделение критического пути
Первые восемь часов ушли не на чтение документации, а на жёсткий инвентаризационный аудит. Цель — найти самую узкую точку, от которой зависит работа организации. Оказалось, это не корпоративная почта или файловое хранилище, а одна небольшая веб-служба, через которую идёт согласование платежей. Её работа обеспечивала финансовую жизнеспособность. Всё остальное на этом этапе было классифицировано как «второстепенное».
Был составлен список всех компонентов этой службы:
- Веб-сервер (Nginx).
- Сервер приложения.
- База данных.
- Сетевые правила (порты, протоколы).
- Пользователи и их роли в системе.
Отказ от сетевого периметра как точки контроля
Традиционный подход потребовал бы настройки VPN для удалённых сотрудников или создания DMZ. Вместо этого было принято решение вынести сервис в изолированный сегмент с единственной точкой входа — reverse proxy с функцией контроля доступа. Сеть перестала быть механизмом авторизации. Её роль свелась к транспорту. Все проверки переносились на уровень приложения и идентификации.
Второй день: внедрение механизмов контроля доступа
Ключевой принцип Zero Trust — «никогда не доверяй, всегда проверяй». На практике это реализовалось тремя компонентами.
1. Контекстная аутентификация вместо пароля
Была внедрена связка из обязательного сертификата пользователя на устройстве и одноразового кода через приложение-аутентификатор. Но главное — была добавлена проверка контекста. Система анализировала:
- С какого устройства идёт запрос (известно ли оно).
- В какое время (соответствует ли рабочему графику).
- С какой сетевой локации (не с публичной Wi-Fi сети в другой стране).
Попытка доступа в нерабочее время или с неподписанного устройства блокировалась, даже если логин и пароль были верными.
2. Минимальные привилегии (Least Privilege) на уровне API
Была проведена точечная настройка политик доступа. Пользователь из бухгалтерии получал доступ только к модулю согласования, но не к журналам аудита системы. Инженер техподдержки видел статус службы, но не мог войти в веб-интерфейс. Это было реализовано не через сложные роли в AD, а через политики внутри самого сервиса, которые проверялись при каждом запросе к API.
[КОД: Пример конфигурации политики доступа для reverse proxy (например, на основе Open Policy Agent)]3. Шифрование и контроль сессий
Весь трафик, включая внутренний между сервисами в выделенном сегменте, был переведён на обязательное mTLS (взаимный TLS). Сессии пользователей стали короткоживущими (15-30 минут) с обязательной повторной аутентификацией для критических действий, таких как подтверждение платежа.
Третий день: подключение остального и мониторинг
С критическим путём, работающим по новым правилам, можно было дышать спокойнее. Оставшееся время ушло на последовательное подключение второстепенных систем — почты, файловых шары, CRM. Для каждой применялся тот же принцип: выделить, проанализировать доступ, внедрить контроль. Ключевым элементом третьего дня стало развёртывание централизованного мониторинга и аудита.
Построение системы наблюдаемости
Была настроена агрегация логов со всех точек контроля:
- Попытки аутентификации (успешные и неуспешные).
- Применённые политики доступа.
- Контекст запросов (устройство, время, действие).
Эти данные визуализировались на единой панели, что позволяло в реальном времени видеть не просто «система работает», а «система работает так, как задумано в политиках».
Как удалось избежать простоя: ключевые приёмы
Нулевой простой, это не случайность, а результат нескольких осознанных решений, противоречащих классическому «отключим всё на выходных».
Параллельная работа старого и нового контуров
Для критического сервиса на 12 часов была организована параллельная работа. Старый доступ через внутреннюю сеть оставался для уже открытых сессий и фоновых задач. Все новые сессии перенаправлялись на новый контур с Zero Trust. Это позволило избежать паники и дало время на тонкую настройку.
Поэтапный перенос пользователей
Переход был организован волнами. Первыми перешли администраторы и ключевые пользователи (бухгалтерия) под пристальным наблюдением. Их опыт и обратная связь использовались для быстрого исправления ошибок конфигурации. Затем волна за волной подключались остальные отделы.
Готовность к откату через конфигурацию
Все изменения вносились через системы управления конфигурацией (например, Ansible). Это означало, что в случае критической проблемы весь новый контур контроля доступа можно было отключить одной командой, вернув старые, менее безопасные, но рабочие настройки. Сам факт наличия такого плана придавал уверенности.
С какими трудностями пришлось столкнуться
Переход не был гладким. Основные проблемы были не техническими, а организационными.
- Сопротивление пользователей. Обязательная аутентификация по сертификату и приложению вызывала шквал вопросов. Решением стала короткая инструкция-скринкаст, разосланная перед переходом конкретной волны, и дежурство техподдержки в чате.
- Унаследованные системы. Одно старое приложение не поддерживало современные методы аутентификации. Для него пришлось временно создать «шлюз» — отдельный прокси-сервис, который брал на себя аутентификацию по новым правилам, а к старой системе обращался от имени технического пользователя.
- Сложность аудита для регулятора. ФСТЭК привык видеть схемы сети и журналы доступа к портам. Пришлось дополнительно готовить отчёты, которые показывали, как контекстные политики и проверка устройств заменяют традиционный сетевой периметр, обеспечивая требования 152-ФЗ к защите персональных данных на более высоком уровне.
Итог: что изменилось после перехода
Главным результатом стал не отчёт для аудита, а сдвиг в модели безопасности. Угроза сместилась с «взлома периметра» на «компрометацию учётных данных конкретного сотрудника». Это более управляемый и точечный риск.
- Гибкость. Новым сотрудникам доступ настраивается за минуты через назначение политик, а не заявку в сетевой отдел на изменение VLAN.
- Наблюдаемость. Теперь точно известно, кто, когда и что делал. Попытка несанкционированного действия видна сразу, а не постфактум по сетевым логам.
- Соответствие. Архитектура стала по умолчанию ближе к требованиям регуляторов о разграничении доступа и контроле действий пользователей.
Переход на Zero Trust за три дня оказался возможен не благодаря революционным технологиям, а за счёт жёсткого фокуса на бизнес-процесс и готовности отказаться от сетевых догм. Это не финальное состояние, а новая точка отсчёта, с которой начинается непрерывное ужесточение политик и повышение уровня доверия — к пользователю, а не к сети.