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

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

Это не один продукт и не проект «поставить новый VPN». Zero Trust меняет модель принятия решения: вместо широкого допуска в сегмент после входа система проверяет каждое значимое взаимодействие.

Почему сетевого периметра недостаточно

Корпоративные ресурсы распределены между офисом, облаком, IaaS, SaaS и площадками партнёров. Сотрудники работают удалённо, сервисы вызывают друг друга через API, а устройства отличаются по владельцу и уровню контроля.

Классическая модель часто предполагает:

1. пользователь подключился к внутренней сети или VPN;
2. получил маршрут до большого набора адресов;
3. отдельные приложения повторно проверяют доступ не всегда;
4. скомпрометированная учётная запись может двигаться между системами.

NIST SP 800-207 определяет Zero Trust как переход от статического сетевого периметра к защите пользователей, устройств, сервисов и ресурсов. Идентификация и авторизация выполняются до установления сессии, а доверие не следует из физического расположения или принадлежности устройства.

Семь рабочих принципов

1. Защищайте ресурс, а не подсеть

Ресурсом может быть приложение, API, очередь, база данных, административная операция или набор документов. Политика формулируется в бизнес-терминах: «сотрудник финансового отдела на управляемом устройстве может читать договоры своего юридического лица», а не «сеть 10.20.0.0/16 разрешена».

2. Идентифицируйте людей и сервисы

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

3. Выдавайте минимум полномочий

Доступ ограничивается ресурсом, операцией, средой и временем. Администраторская роль не должна использоваться для повседневной работы, а временное повышение полномочий требует причины и журнала.

4. Учитывайте состояние устройства

Корректный пароль не делает заражённый ноутбук безопасным. Политика может учитывать управление устройством, шифрование диска, актуальность обновлений, наличие защиты и признаки компрометации.

5. Проверяйте контекст каждой сессии

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

6. Считайте сеть недоверенной

Шифруйте взаимодействия и проверяйте identity даже внутри дата-центра. Сегментация остаётся полезной, но становится дополнительной границей, а не единственным источником доверия.

7. Измеряйте и пересматривайте

Политика доступа без телеметрии быстро устаревает. Нужны журналы решений, отказов, повышения полномочий, состояния устройств и аномалий.

Логические компоненты

Практическую систему удобно разделить на три роли.

Компонент	Ответственность
Policy Engine	Принимает решение по правилам и сигналам риска
Policy Administrator	Создаёт, изменяет или завершает сессию
Policy Enforcement Point	Пропускает или блокирует запрос у ресурса

Источниками сигналов становятся каталог идентичностей, MFA, управление устройствами, CMDB, данные SOC, классификация ресурсов, сведения об уязвимостях и история поведения.

Точка применения политики должна находиться близко к ресурсу: reverse proxy перед приложением, API gateway, service mesh, шлюз административного доступа или механизм самой платформы.

Начните с инвентаризации

Нельзя построить точную политику для неизвестных ресурсов. Составьте реестр:

• критичные приложения и владельцы;
• данные и их классификация;
• пользовательские и машинные identity;
• устройства и уровень управления;
• внешние зависимости;
• действующие способы доступа;
• привилегированные операции;
• необходимые журналы.

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

Модель доступа

Политика должна отвечать минимум на восемь вопросов:

1. Кто обращается?
2. С какого устройства или workload?
3. К какому ресурсу?
4. Какую операцию выполняет?
5. В каком контексте?
6. Каково текущее состояние субъекта и устройства?
7. Какой уровень подтверждения нужен?
8. Как долго действует решение?

Пример:

Сотрудник поддержки может читать карточку клиента из управляемого устройства после MFA. Экспорт списка запрещён. Доступ из нового региона требует повторного подтверждения. Привилегия пересматривается каждые 90 дней.

Для сервисного API правило может связывать identity приложения, среду, допустимые операции, mTLS-сертификат, rate limit и срок действия полномочия. Общие принципы контрактов приведены в статье об интеграционной API-архитектуре.

Состояние устройства без блокировки бизнеса

Двоичная модель «соответствует / заблокировать» иногда останавливает работу из-за сбоя телеметрии. Полезно предусмотреть уровни:

• доверенный режим — полный разрешённый набор операций;
• ограниченный режим — чтение без экспорта или изменения;
• восстановление — только сервисы обновления и поддержки;
• блокировка — подтверждённый высокий риск.

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

Микросегментация и сервисные identity

Сетевые сегменты сокращают область распространения инцидента, но правила по IP трудно поддерживать в динамической инфраструктуре. Для облачных и контейнерных сред важны identity workload и политика на уровне сервиса.

Разделяйте:

• production и тест;
• пользовательский и административный трафик;
• приложения и базы данных;
• управление платформой и бизнес-нагрузку;
• резервное копирование и основной домен администрирования.

Резервная копия, доступная тем же учётным записям из той же сети, не является независимой защитой. Связь изоляции с восстановлением описана в руководстве по резервному копированию и отказоустойчивости.

Телеметрия и наблюдаемость

Для каждого решения сохраняйте:

• subject и resource ID;
• запрошенную операцию;
• результат политики;
• сработавшие правила;
• состояние устройства;
• уровень аутентификации;
• идентификатор сессии;
• время и срок действия;
• причину отказа без раскрытия лишних деталей.

Метрики должны показывать долю отказов, повторных MFA, временных повышений, просроченных прав, неизвестных устройств и критичных ресурсов без enforcement point.

Не отправляйте токены, пароли и содержимое чувствительных документов в обычные журналы. Подход к метрикам, логам и traces разобран в статье о наблюдаемости инфраструктуры.

План внедрения по этапам

Этап 1. Выбрать процесс

Определите владельца, пользователей, ресурсы, допустимые операции и критерии успеха. Зафиксируйте текущий путь доступа и инциденты.

Этап 2. Усилить идентичности

Уберите общие аккаунты, подключите MFA для риска и привилегий, создайте отдельные identity сервисов, настройте ротацию секретов.

Этап 3. Поставить точку применения политики

Разместите proxy, gateway или другой enforcement перед ресурсом. Сначала включите режим наблюдения, чтобы увидеть будущие блокировки.

Этап 4. Подключить состояние устройств

Передавайте минимально необходимые сигналы. Проверьте качество данных и сценарий недоступности источника.

Этап 5. Сузить доступ

Переведите правила с широких сетей на приложения и операции. Вводите ограничения небольшими волнами с откатом.

Этап 6. Включить постоянный контроль

Пересматривайте права, исключения и сигналы риска. Проверяйте, что удаление сотрудника или компрометация identity быстро прекращают активные сессии.

Типичные ошибки

• Покупка «Zero Trust-продукта» без модели ресурсов и владельцев.
• MFA только на входе в VPN при широком доступе после него.
• Один сервисный аккаунт для многих интеграций.
• Слишком строгая политика без режима восстановления.
• Постоянные исключения без срока и владельца.
• Доверие к устройству только по наличию агента.
• Журналирование решения без возможности связать его с бизнес-операцией.
• Попытка мигрировать всю компанию одним переключением.

Чек-лист пилота

• Выбран один критичный процесс и назначен владелец.
• Известны пользователи, сервисы, устройства и ресурсы.
• Общие identity исключены.
• Политики описывают операции, а не только сети.
• MFA и состояние устройства применяются по риску.
• Есть ограниченный режим и путь восстановления.
• Решения журналируются и доступны для расследования.
• Отзыв доступа завершает действующие сессии.
• Пилот измеряет влияние на время выполнения задачи.
• Исключения имеют владельца и дату окончания.

Вывод

Zero Trust полезен не как лозунг «никому не доверять», а как дисциплина точного доступа. Начните с одного процесса, перенесите решение от сетевого расположения к identity и ресурсу, добавьте состояние устройства и телеметрию, а затем расширяйте модель по доказанным результатам.

Основной международный ориентир: NIST SP 800-207 Zero Trust Architecture. Для облачных приложений полезно дополнение NIST SP 800-207A. Применимость стандартов и требований к конкретной российской информационной системе оценивается отдельно.

Следующий шаг: «Лоджик Телеком» может помочь описать критичные потоки доступа, выделить точки применения политики и спланировать пилот без остановки текущих процессов.