От периметра к Zero Trust: почему доверие к внутренней сети умерло

"Переход от периметра к Zero Trust, это не просто замена старой технологии на новую. Это признание того, что сама концепция защищённой внутренней сети умерла. Теперь каждый запрос — потенциальная угроза, требующая проверки. Я не защищаю границы, я управляю движением на каждом перекрёстке."

Нет внутренней сети: как Zero Trust заставляет забыть старые правила безопасности

Почему периметр как концепция исчез

Исторически корпоративная IT-инфраструктура проектировалась по модели крепости. Локальный дата-центр с серверами, это цитадель, внутренняя сеть — охраняемый двор, а межсетевой экран (МЭ) на границе — главные ворота с подъёмным мостом. Главная идея была проста: всё, что внутри крепости, заслуживает доверия, всё, что снаружи — враждебно. Подразумевалось, что физический контроль над офисом и кабельной инфраструктурой обеспечивает и логическую безопасность.

Эта модель разрушается тремя фундаментальными сдвигами:

1. Дисперсия пользователей и устройств. Работа больше не привязана к офису. Сотрудники подключаются с домашних компьютеров, личных смартфонов, кафе и аэропортов. Эти устройства не контролируются корпоративной IT-службой, их уровень защиты непредсказуем, а их сетевое окружение — публичное и небезопасное.

2. Миграция приложений и данных в облако. Корпоративный «периметр» теперь размазан по десяткам облачных провайдеров. Сервисы SaaS (например, электронная почта, CRM, системы документооборота) доступны напрямую из интернета. Трафик между пользователем и Google Workspace или Salesforce никогда не проходит через ваш централизованный МЭ, что делает его «невидимым» для классических средств защиты периметра.

3. Изменение вектора атак. Современные атаки редко начинаются с грубого взлома брандмауэра. Они начинаются с фишинга, компрометации учётных данных или уязвимости в публичном веб-приложении. Получив валидный логин и пароль, злоумышленник становится «легитимным» пользователем внутри сети. Периметр беспомощен против угроз, которые уже находятся внутри него по определению.

Таким образом, сам вопрос «где проходит граница моей сети?» теряет смысл. Периметр не просто ослаб — он перестал существовать как единая, чётко очерченная линия обороны. Попытка усилить несуществующую границу, это вложение ресурсов в иллюзию безопасности.

Из чего на самом деле состоит Zero Trust

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

• Никакого неявного доверия. Доверие никогда не предоставляется по умолчанию, основываясь только на расположении (внутри сети) или владении учётными данными. Каждый субъект (пользователь, устройство, приложение) считается потенциально скомпрометированным.
• Проверка каждого запроса. Каждая попытка доступа к ресурсу должна быть аутентифицирована, авторизована и проверена на соответствие политике безопасности в реальном времени, независимо от предыдущих проверок.

Реализация этих принципов строится вокруг непрерывной оценки контекста. В отличие от разовой аутентификации при входе в сеть (VPN), Zero Trust требует постоянного мониторинга множества сигналов для каждого отдельного запроса доступа. Эти сигналы формируют контекст, на основе которого система принимает решение.

Ключевые элементы контекста для оценки доступа:

Архитектурно Zero Trust реализуется через создание микропериметров (microperimeters) вокруг каждого защищаемого ресурса — будь то приложение, база данных или даже отдельный API-эндпоинт. Доступ к ресурсу возможен только через специальный шлюз (например, обратный прокси или API Gateway), который и проводит всю необходимую проверку контекста.

Как работает проверка доступа в реальном времени

Механизм принятия решений в Zero Trust, это динамический процесс, часто описываемый как Policy Decision Point (PDP) и Policy Enforcement Point (PEP).

1. PEP (Шлюз доступа) перехватывает запрос пользователя к ресурсу.
2. PDP (Движок политик) анализирует контекст запроса, собранный из различных источников (Identity Provider, MDM, SIEM, Threat Intelligence), и сверяет его с заданными политиками.
3. На основе этой оценки PDP возвращает решение PEP: разрешить доступ полностью, разрешить с ограничениями, потребовать шаг-up аутентификации или полностью заблокировать.

Рассмотрим несколько сценариев в динамике:

• Сценарий "Аномальное поведение". Пользователь из отдела продаж обычно работает с CRM с 9 до 18 часов из Московского региона. В субботу в 3:00 ночи система фиксирует попытку входа с IP-адреса, принадлежащего дата-центру в другой стране. PDP оценивает это как аномалию с высоким уровнем риска. Вместо блокировки (которая может быть ложным срабатыванием) система через PEP предлагает пользователю пройти дополнительную проверку по биометрии или через push-уведомление в доверенном приложении. Только после успешного прохождения доступ предоставляется.

• Сценарий "Скомпрометированное устройство". Ноутбук сотрудника, зарегистрированный в MDM, подвергается атаке, и агент безопасности на нём отключается. MDM отправляет сигнал в PDP о потере доверия к устройству. При следующем запросе этого пользователя к конфиденциальному документохранилищу, PDP, зная о скомпрометированном состоянии устройства, диктует PEP политику "доступ только для чтения" или полностью блокирует загрузку файлов, предотвращая возможную утечку данных.

• Сценарий "Временные привилегии" (Just-In-Time Access). Системному администратору требуется выполнить срочные работы на критичном сервере. Вместо того чтобы иметь постоянные права суперпользователя, он через портал запрашивает повышенные привилегии на определённый срок (например, 2 часа). Запрос утверждается ответственным лицом или автоматически на основе расписания. По истечении времени доступ автоматически отзывается, сводя к минимуму окно для возможных злоупотреблений.

Первые шаги: с чего начать переход от периметра

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

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

   • Определите критичные активы (Crown Jewels). Какие данные, приложения или системы принесут максимальный ущерб при компрометации? Финансовые отчёты, базы персональных данных, исходный код.
   • Картируйте потоки доступа. С помощью сетевых анализаторов, логов прокси-серверов и облачных платформ постройте схему: кто, откуда и к каким ресурсам обращается. Вы удивитесь, сколько трафика уже проходит в обход вашего «периметра».

2. Создайте единый центр идентификации. Zero Trust невозможен без строгой и централизованной идентификации всех субъектов.

   • Внедрите или приведите в порядок Identity Provider (IdP), например, на базе решений, поддерживающих протоколы SAML или OIDC.
   • Обязательно внедрите многофакторную аутентификацию (MFA) для всех пользователей, особенно для доступа к критичным системам.
   • Начните регистрировать корпоративные и BYOD-устройства в системе управления (MDM/UEM), чтобы получать данные об их состоянии.

3. Выберите пилотную зону. Не пытайтесь охватить всё сразу. Выделите один критичный, но относительно изолированный ресурс — например, веб-приложение для удалённых сотрудников или доступ к облачному файловому хранилищу.

   • Разверните перед ним шлюз доступа (Zero Trust Network Access, ZTNA).
   • Настройте политики, требующие MFA и проверки состояния устройства для доступа к этому конкретному приложению.
   • Этот пилот позволит отработать процессы, показать ценность команде и получить первую победу.

4. Внедряйте сегментацию. Начните дробить плоскую внутреннюю сеть на сегменты.

   • Сначала изолируйте самые критичные сегменты (например, финансовые системы или промышленные сети).
   • Используйте не только VLAN, но и политики межсетевых экранов нового поколения (NGFW) на уровне приложений (L7) и хостовые файрволы.

Изменения для команды: новая роль администратора безопасности

Переход к Zero Trust кардинально меняет роль специалиста по безопасности и принципы работы команды.

• От сетевого администратора к архитектору политик. Основная задача смещается с настройки статических ACL на IP-адреса и порты к проектированию динамических политик, основанных на атрибутах (роль пользователя + состояние устройства + тип ресурса). Это требует более глубокого понимания бизнес-процессов и логики приложений.

• Автоматизация жизненного цикла доступа. Вручную управлять тысячами временных доступов и постоянных прав невозможно. Ключевым становится интеграция IdP с HR-системами для автоматической выдачи, изменения и отзыва прав при приёме, переводе и увольнении сотрудников. Та же логика применяется к сервисным аккаунтам и внешним контрагентам.

• Сдвиг безопасности влево (Shift Left). Безопасность перестаёт быть функцией, которая «добавляется» в конце. Архитекторы безопасности должны участвовать в проектировании новых приложений и сервисов с самого начала, закладывая принципы Zero Trust (например, сервис-меши для микросервисов, API-шлюзы) в их архитектуру.

• Фокус на данные и поведение. Центр внимания смещается с защиты сетевого периметра на защиту данных и анализ поведения субъектов. Команда тратит больше времени на настройку DLP-систем, классификацию данных и расследование инцидентов на основе аномалий в поведении пользователей и устройств.

Частые препятствия и как их обойти

1. Культурное сопротивление и устаревшее мышление. Самая большая преграда — убеждение, что «внутренняя сеть — безопасное место». Преодолеть это можно только через образование и демонстрацию. Показывайте примеры реальных инцидентов, где атака развивалась изнутри. Проводите тренировки для сотрудников, разъясняя, почему теперь требуется MFA даже в офисе.

2. Унаследованные (legacy) системы. Многие старые приложения не поддерживают современные протоколы аутентификации (SAML, OAuth) и рассчитаны на доступ из «доверенной» подсети. Решение — не ломать их, а изолировать.

   • Поместите такие системы в отдельный, максимально закрытый сегмент сети (броневик).
   • Организуйте доступ к ним только через «переходной» шлюз (бастион-хост или выделенный VPN), который сам будет защищён по принципам Zero Trust (с MFA и проверкой устройства).
   • Планируйте их постепенную модернизацию или замену.

3. Ожидание мгновенного результата и «серебряной пули». Zero Trust, это не проект с датой окончания, а непрерывный процесс. Начните с малого, определите измеримые цели для пилота (например, «снизить количество попыток неавторизованного доступа к приложению X на 90%»), документируйте успехи и постепенно масштабируйте подход.

4. Вендорская зависимость. Опасайтесь решений, которые предлагают «полный Zero Trust в коробке», но являются закрытыми экосистемами. Стремитесь к построению открытой архитектуры, где компоненты (IdP, MDM, шлюзы, SIEM) общаются через стандартные API. Это даёт гибкость и позволяет адаптировать логику под уникальные требования бизнеса.

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