Даже если ты следуешь классическим рецептам из учебников по безопасности, рано или поздно появляется ощущение, что сеть защищена лишь на бумаге. Perimeter-based security превращается в ритуал с дырками, а VPN и доступ по IP-адресам создают иллюзию защиты. Zero trust, это не про ‘отказаться от всего’, а про управление доступом на основе твоего контекста, а не сетевого положения. Всё, что нужно, это готовность разобрать существующую логику до самого фундамента и собрать заново, только на основе политик. Главное — не выключать систему на эти три дня. https://seberd.ru/5379
Почему perimeter-based security уже не работает и что такое zero trust на деле
Традиционная модель безопасности строилась на чётком разделении: внутренняя сеть (доверенная) и внешний мир (недоверенный). Внутри сети пользователи и системы получали широкие привилегии по умолчанию. Брандмауэр, VPN, сегментация VLAN — все эти меры были направлены на защиту периметра. Однако с ростом облачных сервисов, удалённой работы и BYOD (Bring Your Own Device) этот периметр размылся до неузнаваемости. Злоумышленник, проникнув внутрь через компрометированные учётные данные или уязвимость в веб-приложении, получает свободу передвижения.
Концепция zero trust отказывается от идеи доверенной сети как таковой. Её суть выражена в принципе «никогда не доверяй, всегда проверяй». Каждый запрос на доступ к ресурсу — будь то пользователь, сервис или устройство — должен проходить аутентификацию, авторизацию и непрерывную проверку, независимо от его происхождения.
Для российского ИТ-контекста, особенно с учётом требований регуляторов (152-ФЗ, приказы ФСТЭК), переход на zero trust, это не просто мода, а необходимость. Требования регуляторов всё чаще смещаются от контроля периметра к защите самих информационных активов и управлению доступом на основе минимальных привилегий (принцип least privilege). Zero trust предоставляет конкретные архитектурные подходы для реализации этих требований.
Подготовка: инвентаризация, политики и план миграции
Перенос без простоя невозможен без детальной подготовки. Главная ошибка — пытаться внедрить технологические решения до того, как будет понятна логика доступа.
Шаг 1: Полная инвентаризация активов и потоков данных
Начни с составления карты инфраструктуры. Тебе нужен не просто список серверов, а понимание того, кто и к каким ресурсам обращается, какие протоколы используются и с какими данными ведётся работа. Особое внимание удели legacy-системам и сервисам с неявными зависимостями.
- Приложения и сервисы: Веб-приложения, базы данных, API, файловые хранилища, системы управления.
- Пользователи и роли: Не только люди, но и сервисные учётные записи, CI/CD-агенты.
- Устройства: Корпоративные ноутбуки, личные устройства сотрудников (при использовании BYOD), серверы.
- Сетевые потоки: Кто к кому подключается, на каких портах и с какой целью.
Результатом должен стать граф зависимостей, а не плоский список. Этот этап часто выявляет «зомби-сервисы» и неучтённые доступы.
Шаг 2: Определение политик доступа в терминах zero trust
На основе карты инфраструктуры сформулируй политики доступа. Вместо правил брандмауэра по IP-адресам и портам тебе нужны политики вида:
- Кто: Пользователь из группы «Бухгалтерия» с устройством, имеющим актуальный антивирус и включённым шифрованием диска.
- К чему: Веб-интерфейс ERP-системы на конкретном хосте.
- При каких условиях: Только в рабочее время, с территории РФ, при уровне уверенности в аутентификации не ниже «среднего».
Это основа для будущих правил в контроллере доступа. Сразу раздели политики на критичные (финансовые системы, персональные данные) и менее строгие (внутренние Wiki, тестовые стенды).
Шаг 3: Выбор и настройка компонентов zero trust
Архитектура zero trust не привязана к одному вендору. В российских реалиях часто собирается из нескольких компонентов:
- Контроллер доступа (Identity-Aware Proxy): Шлюз, который проверяет каждую попытку доступа к приложению. Примеры реализаций можно найти в рамках российских решений для СЗИ или собрать на базе open-source компонентов (например, на основе обратного прокси с модулями аутентификации).
- Средства аутентификации и управления идентификацией (IAM): Интеграция с Active Directory, поддержка многофакторной аутентификации (MFA). Для 152-ФЗ критична надёжность аутентификации.
- Агенты на устройствах (Endpoint Security): ПО для проверки состояния устройства (софт установлен, диск зашифрован, нет признаков заражения) перед предоставлением доступа. Результаты проверок становятся атрибутами для политик контроллера доступа.
- Система логирования и мониторинга (SIEM): Все события аутентификации и доступа должны агрегироваться для анализа и расследования инцидентов, что прямо следует из требований регуляторов.
На этом этапе компоненты разворачиваются в тестовом контуре параллельно с работающей инфраструктурой.
Три дня миграции: стратегия параллельного развёртывания
Цель — плавный переход, при котором пользователи могут работать через старую и новую систему одновременно. Это исключает простои и позволяет откатиться в случае проблем.
День 1: Внедрение контроллера доступа для нефункциональных сервисов
Начни с наименее критичных систем, доступ к которым не прерывает бизнес-процессы. Идеальные кандидаты — внутренние порталы, системы мониторинга, тестовые среды.
- Размести контроллер доступа (например, reverse proxy с поддержкой OIDC) перед выбранным приложением.
- Настрой политики доступа для этих сервисов. Пока используй упрощённые правила, основанные только на аутентификации пользователя.
- Перенаправляй трафик на новый шлюз для ограниченной группы тестовых пользователей. Основной трафик продолжает идти по старому пути.
- Протестируй доступ, аутентификацию, работу приложения. Убедись, что логируются все события.
К концу дня у тебя будет работающий сегмент zero trust для некритичной нагрузки. Пользователи основной массы не заметили изменений.
День 2: Подключение критичных систем и активация проверок устройств
Теперь очередь ключевых бизнес-приложений — CRM, ERP, документооборот.
- Добавь эти приложения в зону действия контроллера доступа. Настрой для них более строгие политики из подготовленного списка (например, обязательная MFA, доступ только с корпоративных устройств).
- Активируй проверки состояния устройств через агентов. Интегрируй результаты этих проверок (атрибуты «устройство соответствует политике безопасности», «исправность ЭП») в механизм принятия решений контроллера доступа.
- Переведи на новый доступ сначала пилотные группы (отдел ИБ, администраторы), затем постепенно расширяй на отделы. Используй механизм канареечного развёртывания: часть пользователей идёт через zero trust, часть — по старой схеме. Это позволяет оперативно выявлять проблемы.
На этом этапе большинство пользователей уже работает через новую систему. Старые пути доступа (прямые подключения, VPN для этих приложений) остаются, но используются всё реже.
День 3: Финализация, отключение legacy-доступа и настройка мониторинга
Завершающий этап — полный перенос и «уборка».
- Убедись, что все целевые пользователи и системы успешно работают через zero trust-шлюз. Мониторь метрики задержек и ошибок.
- Отключи старые, ненужные теперь правила доступа:
- Публичный доступ к административным интерфейсам приложений.
- Прямые подключения к базам данных с рабочих станций.
- VPN-доступ к внутренним приложениям (VPN может остаться для других нужд, например, управления инфраструктурой).
- Настрой автоматические реакции в SIEM на подозрительные события zero trust: множественные неудачные попытки аутентификации, доступ с несоответствующих политике устройств, попытки доступа к ресурсам в нерабочее время.
- Проведи итоговый брифинг с командой поддержки, передай документацию по политикам и процедурам устранения неполадок.
К концу третьего дня инфраструктура работает в новой модели. Периметр как точка контроля исчез, его заменили распределённые точки проверки у каждого ресурса.
Чек-лист успешного перехода на zero trust
- Подготовка (до миграции):
- ✅ Составлена полная карта активов и потоков данных.
- ✅ Политики доступа сформулированы в терминах атрибутов (пользователь, устройство, контекст).
- ✅ Выбраны и протестированы в изоляции все компоненты (контроллер доступа, IAM, агенты).
- ✅ Определён порядок миграции приложений от наименее к наиболее критичным.
- Миграция (3 дня):
- ✅ День 1: Контроллер доступа работает для нефункциональных сервисов, трафик тестовых пользователей идёт через него.
- ✅ День 2: Критичные системы подключены, активированы проверки устройств, большинство пользователей переведено.
- ✅ День 3: Legacy-доступ отключён, настроен мониторинг и оповещения, проведена документация.
- После миграции:
- ✅ Регулярный пересмотр политик доступа (например, каждые 3 месяца).
- ✅ Аудит логов доступа на предмет аномалий.
- ✅ План по интеграции в zero trust-модель новых сервисов по мере их появления.
Какие сложности ждут на практике и как их обойти
Переход редко проходит абсолютно гладко. Вот частые проблемы и способы их решения.
Legacy-системы без поддержки современных протоколов аутентификации. Старые системы, понимающие только логин-пароль или работающие по устаревшим протоколам, — основная головная боль. Решение — использовать контроллер доступа в режиме «перехвата сессии» (TCP/UDP прокси) или развернуть перед такой системой тонкий веб-обвес (adapter), который будет выполнять современную аутентификацию, а затем передавать управление легаси-приложению.
Инциденты с производительностью контроллера доступа. Каждый запрос теперь проходит дополнительные проверки, что добавляет задержку. Чтобы избежать проблем, нагрузочное тестирование компонентов zero trust — обязательный этап подготовки. Используй кеширование сессий, горизонтальное масштабирование шлюзов и настройку таймаутов.
Сопротивление пользователей из-за MFA или проверок устройств. Усложнение процедуры входа может вызвать негативную реакцию. Важно объяснять не «мы всё усложняем», а «мы повышаем безопасность вашей работы и данных компании». Внедряй MFA поэтапно, начиная с наиболее защищённых ресурсов. Предоставь удобные методы аутентификации (TOTP-приложения, аппаратные токены).
Проблемы с доступом сервисных учётных записей и автоматизаций. Роботы и CI/CD-пайплайны тоже должны аутентифицироваться. Для них используй механизм сервисных аккаунтов с ограниченным временем жизни токенов или взаимную аутентификацию по сертификатам (mTLS), интегрированную в политики контроллера доступа.
Главный инструмент против непредвиденных сложностей — параллельная работа старой и новой системы. Она даёт время на отладку без давления на бизнес.
Zero trust и регуляторика: как это помогает закрыть требования ФСТЭК и 152-ФЗ
Внедрение zero trust — не технический каприз, а прямой путь к выполнению многих требований российских регуляторов в области ИБ.
- Принцип минимальных привилегий (п. 19 Требований ФСТЭК): Zero trust реализует его на архитектурном уровне. Политики доступа описывают именно то, что нужно для работы, и ничего лишнего. Доступ к персональным данным или критичным системам предоставляется только при соблюдении строгих условий.
- Аутентификация и управление доступом (п. 14, 15 Требований ФСТЭК): Многофакторная аутентификация (MFA), проверка состояния устройства и контекстные политики, это механизмы для усиления аутентификации и детализированного управления доступом, которые прямо рекомендуются регулятором.
- Регистрация событий безопасности (ст. 19 152-ФЗ): Контроллер доступа и компоненты zero trust становятся централизованными источниками логов о всех попытках и фактах доступа к информационным ресурсам. Эти логи структурированы (кто, когда, откуда, к чему, с каким устройством, результат) и легко передаются в SIEM для хранения и анализа.
- Защита от несанкционированного доступа: Отказ от доверенной сети и проверка каждого запроса сводят на нет многие классические векторы атак, связанные с перемещением внутри сети после первоначального проникновения.
внедрение zero trust позволяет перейти от формального «отчёта на бумаге» о выполнении требований к их реальной, измеримой технической реализации. Архитектура становится не просто защищённой, но и доказуемо соответствующей ожиданиям регулятора.