Как перенести инфраструктуру на Zero Trust за три дня без простоя

Как я перенёс инфраструктуру под zero trust за 3 дня без простоя

Что такое zero trust, если говорить о деле, а не о шуме

Концепцию zero trust любят упаковывать в абстракции — «доверие равно нулю», «принцип наименьших привилегий». На практике в России речь идёт о технической реализации изоляции доступа ко внутренним ресурсам. Нужно построить систему, где каждый запрос, даже из внутренней сети, проходит проверку контекста: кто, откуда, на что и в какое время хочет попасть. Главная задача — закрыть периметр, который уже не работает из-за удалённых сотрудников и облачных сервисов, без радикального усложнения жизни пользователям и администраторам.

Шаг 1: картография — какой доступ и куда существует сейчас

Первым делом нужно выяснить, что у вас в инфраструктуре вообще открыто. Взгляните на ситуацию глазами нарушителя.

Какие порты торчат наружу? Стандартные SSH (22), RDP (3389), веб-админки (443/80) на внешних IP. Многие сервисы «повесили для удобства» и забыли.
Какие VPN-подключения у сотрудников? OpenVPN, L2TP/IPsec, может быть свой корпоративный VPN. Кто имеет доступ? Все сотрудники или только часть? Есть ли доступ у подрядчиков?
Какие облачные ресурсы используются? VM в Yandex Cloud, VK Cloud, Selectel. Часто настройки безопасности по умолчанию оставляют лишние порты открытыми в группах безопасности.
Что внутри сети? После входа в VPN пользователь часто получает доступ ко всей внутренней подсети. Это классическая модель «замка на воротах и свобода во дворе».

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

Шаг 2: выбор инструмента — не только про функционал

Идеального «коробочного» zero trust решения под все задачи нет. Выбор зависит от инфраструктуры и компетенций команды.

Подход	Примеры	Плюсы	Минусы для быстрой миграции
Cloud-based шлюз	Zscaler Private Access, Cloudflare Access	Быстрое развёртывание, не нужна своя инфраструктура	Трафик уходит в интернет, может быть чувствительно к регуляторным требованиям 152-ФЗ о локализации данных.
Self-hosted шлюз	OpenZiti, Pomerium, Tailscale с собственным координатором	Полный контроль над трафиком и данными, соответствует 152-ФЗ	Требует выделенных ресурсов и настройки.
Гибридный подход	Headscale (координатор для Tailscale) + собственные реле	Гибкость, хороший баланс контроля и простоты	Нужно собирать из нескольких компонентов.

Для переноса за три дня ключевой критерий — минимальное изменение клиентской части у пользователей. Если у всех уже стоит VPN-клиент, логично использовать решение, где клиент либо остаётся тем же (с изменёнными настройками), либо ставится легко и незаметно.

Шаг 3: подготовка новой инфраструктуры — параллельно со старой

Миграция без простоя строится на параллельной работе двух систем. Пока старая VPN работает, вы разворачиваете zero trust шлюз.

Выделите сервера для шлюзов. Хватит двух виртуальных машин небольшого размера. Разместите их в той же облачной среде или на своём железе. Важно обеспечить отказоустойчивость.
Настройте DNS. Для доступа к внутренним ресурсам через zero trust понадобятся новые имена. Например, если был доступ по rdp://10.0.1.5, теперь будет https://server-admin.corp.internal. Пропишите A-записи для ваших шлюзов.
Подготовьте интеграцию с источниками аутентификации. Чаще всего это Active Directory или LDAP. Настройте в zero trust решении подключение к вашему каталогу пользователей. Это позволит использовать существующие учётные записи.

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

Шаг 4: создание первого безопасного туннеля для администраторов

Нельзя переключать всех сразу. Первыми под новую систему переводят IT-администраторов.

Установите zero trust клиент на рабочие станции админов.
Настройте доступ только к критичным для управления системам: гипервизорам, контроллерам домена, системам мониторинга.
Настройте политики доступа. Например, доступ к панели управления виртуальными машинами только с корпоративного устройства и в рабочее время.

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

Шаг 5: перенос первого бизнес-сервиса — тест на практике

Выберите один несложный, но важный сервис. Например, внутренний Confluence или систему тикетов.

На zero trust шлюзе создайте приложение (application), указывающее на внутренний адрес этого сервиса.
Настройте политику доступа. Например, «все сотрудники отдела разработки имеют доступ к Confluence с любых устройств». Или более строгую: «доступ к тикет-системе только с корпоративных ноутбуков, на которых установлен агент безопасности».
Проинформируйте целевую группу пользователей. Дайте им инструкцию по установке клиента (если нужно) и новому URL для доступа.
Переключите DNS-имя сервиса с внутреннего адреса на адрес zero trust шлюза. Или просто сообщите новый URL.

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

Шаг 6: автоматизация подключения пользователей

Ручная установка клиентов на сотни компьютеров, это недели, а не дни. Нужна автоматизация.

Если используете MDM (Mobile Device Management) или системы управления конфигурациями (например, Ansible, Puppet), создайте пакет для автоматической установки zero trust агента.
Для корпоративных устройств можно предустановить агент через образы ОС.
Подготовьте сценарий для бесшовного переключения: агент устанавливается фоном, старый VPN-профиль отключается, новый профиль zero trust подключается автоматически при входе в систему.

Это критичный этап для масштабирования миграции на всех сотрудников.

Шаг 7: массовый перенос пользователей — волнами

Переход происходит группами, например, по отделам.

Подготовьте инструкции. Чёткий PDF или внутреннюю wiki-страницу с шагами для пользователя.
Настройте политики для отдела. Определите, к каким ресурсам нужен доступ отделу маркетинга, бухгалтерии, разработки. Создайте соответствующие правила на шлюзе.
Запланируйте «окно». Хотя простоя нет, лучше делать переход в относительно спокойное время, например, в четверг после обеда.
Выполните переход. Активируйте политики для отдела, запустите скрипт автоматической установки/переключения на их устройствах, отзвонитесь ключевым пользователям для проверки.
Оставьте старый VPN доступ на 24 часа. На случай непредвиденных проблем сотрудники смогут временно вернуться к старому способу.

После успешного перевода первого отдела процесс повторяется для следующего.

Шаг 8: ужесточение политик и отключение старого периметра

Когда все пользователи и сервисы работают через zero trust шлюз, наступает время убрать старую инфраструктуру.

Отключите правила на старом firewall, разрешающие доступ извне. Оставьте только служебные правила для управления.
Остановите или удалите VPN-серверы.
В облачных средах пересмотрите группы безопасности (Security Groups). Уберите правила, открывающие RDP/SSH на весь интернет или из широких диапазонов. Оставьте доступ только с IP-адресов zero trust шлюзов.

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

Шаг 9: мониторинг и анализ логов

Zero trust даёт детализированную картину всех попыток доступа.

Настройте сбор логов аутентификации и сессий с zero trust шлюза в вашу SIEM-систему (например, в ELK-стек или российский аналог).
Создайте алерты на подозрительные события: многочисленные неудачные попытки входа, доступ в нерабочее время, попытки доступа к ресурсам, не входящим в политики пользователя.
Регулярно просматривайте отчёты о использовании. Это помогает выявить неиспользуемые сервисы, которые можно отключить, и скорректировать политики.

Шаг 10: интеграция с системами ИБ и регуляторными требованиями

Zero trust модель хорошо ложится на требования регуляторов, таких как ФСТЭК и 152-ФЗ.

Аутентификация и учёт. Все события входа фиксируются. Этого достаточно для многих требований по журналированию.
Шифрование трафика. Современные решения используют mTLS или аналоги, что покрывает требования к защите данных при передаче.
Контроль доступа. Принцип наименьших привилегий, реализованный через политики, напрямую соответствует рекомендациям ФСТЭК по разграничению доступа.

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

Шаг 11: что получилось в итоге и где подводные камни

Через три дня старая VPN-инфраструктура отключена, весь доступ идёт через zero trust шлюз. Пользователи замечают лишь смену иконки соединения и, возможно, новый URL для некоторых сервисов.

Выгоды:

Исчезли открытые наружу порты RDP/SSH, что сразу закрывает целый класс уязвимостей.
Доступ стал контекстно-зависимым. Можно гибко ограничивать доступ по времени, устройству, местоположению.
Упростился процесс предоставления доступа подрядчикам: выдали временную политику — доступ есть, политику отозвали — доступ исчез.

Сложности, с которыми стоит быть готовым:

Legacy-приложения. Сервисы, работающие по устаревшим протоколам без поддержки HTTPS или со сложной схемой аутентификации, могут потребовать дополнительных прокси или модификаций.
Привычки пользователей. Кто-то привык работать напрямую по локальным IP-адресам. Придётся переучить или настроить локальный DNS.
Производительность. Весь трафик теперь проходит через шлюз(ы). Необходимо мониторить нагрузку и масштабировать шлюзы при необходимости.

Переход на zero trust, это не разовая акция, а изменение модели безопасности. Три дня, это срок, чтобы запустить процесс и получить работающую систему. Её дальнейшая тонкая настройка, расширение на новые типы ресурсов и ужесточение политик будут идти постоянно, делая инфраструктуру устойчивее с каждым днём.