Принципы нулевого доверия: никогда не доверяйте, всегда проверяйте

Zero Trust — это модель Security, основанная на принципе, согласно которому ни User, ни Device, ни сеть не должны считаться надёжными по умолчанию — даже если они находятся внутри корпоративного периметра. Традиционная Security исходила из того, что внутри межсетевого экрана всё безопасно, однако современные атаки регулярно доказывают ошибочность этого предположения. Zero Trust заменяет неявное доверие на явную непрерывную проверку каждого запроса на доступ.

Zero Trust опирается на три фундаментальных принципа. Явно проверяйте означает, что каждый Request необходимо аутентифицировать и авторизовать с использованием всех доступных сигналов. Используйте минимально необходимые привилегии — предоставляйте доступ только к тому, что требуется для выполнения текущей задачи. Исходите из того, что система скомпрометирована — проектируйте системы так, словно злоумышленники уже находятся внутри, чтобы меры защиты были направлены на ограничение ущерба и быстрое обнаружение горизонтального перемещения.

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

В Zero Trust идентичность становится основной плоскостью управления. Вместо доверия к расположению в сети (IP-адресу, VLAN) каждый Request должен предъявлять подтверждённую идентичность — User, Device, рабочей нагрузки или сервиса. Поставщики идентификации (IdP), такие как Azure AD или Okta, непрерывно оценивают сигналы: кто отправляет Request, с какого Device, из какого места и с каким уровнем риска.

Zero Trust требует проверять Device наряду с User. Соответствующий требованиям Device должен отвечать требованиям Security: иметь актуальные исправления, включённое шифрование диска, работающий агент EDR и не должен иметь обнаруженных признаков Jailbreak или получения прав root. Платформы Mobile Device Management (MDM) и Endpoint Detection and Response (EDR) передают эти данные о состоянии механизму Policy в момент предоставления доступа.

Традиционные VPN предоставляют доступ на уровне сети — после подключения User могут обращаться ко многим ресурсам. Zero Trust заменяет это на доступ на уровне ресурса: каждое приложение или сервис предоставляет доступ отдельно на основе идентичности, состояния Device и контекста. Это реализуется с помощью продуктов Software-Defined Perimeters (SDP) и Zero Trust Network Access (ZTNA), которые делают ресурсы невидимыми, пока доступ явно не предоставлен.

Исходить из того, что система скомпрометирована — значит проектировать и эксплуатировать среду так, словно злоумышленники уже проникли в неё. Этот подход определяет несколько важных практик: шифровать весь внутренний трафик, чтобы горизонтальное перемещение нельзя было наблюдать; вести журнал всего для последующего расследования; внедрять микросегментацию для ограничения масштаба ущерба; и проводить непрерывный мониторинг, а не проверки в отдельные моменты времени.

Минимально необходимые привилегии в Zero Trust выходят за рамки RBAC. Доступ Just-in-time (JIT) предоставляет расширенные разрешения только при необходимости и автоматически отзывает их по истечении заданного времени. Доступ Just-enough-access (JEA) ограничивает административные действия определёнными командами. Эти подходы значительно сокращают период уязвимости при компрометации привилегированной учётной записи, поскольку учётные данные быстро истекают, а область доступа ограничена.

Zero Trust заменяет принцип «аутентифицируй один раз — доверяй всегда» на непрерывную проверку. После первоначальной аутентификации механизм Policy отслеживает сигналы на протяжении всей сессии: необычную загрузку данных, доступ из нового географического места, активность в нерабочее время или изменения состояния Device. Если риск возрастает во время сессии, система может усилить аутентификацию (снова запросить MFA) или полностью завершить сессию.

Механизм Policy Zero Trust — это точка принятия решений, которая оценивает запросы на доступ. Он получает сигналы от поставщиков идентификации, систем управления устройствами, источников сведений об угрозах и средств поведенческой аналитики, а затем применяет Policy, чтобы разрешить, отклонить или запросить дополнительную проверку каждого запроса. Современные облачные платформы реализуют это с помощью Conditional Access (Azure AD), Access Context Manager (Google BeyondCorp) и шлюзов ZTNA.

Облачные среды естественным образом подходят для Zero Trust, поскольку в них нет физического периметра, который нужно защищать. Каждый вызов API, взаимодействие между сервисами и запрос User на доступ можно контролировать с помощью cloud IAM policies, service meshes (например, Istio с взаимным TLS) и cloud-native ZTNA solutions. Модель разделения ответственности уже исходит из того, что базовой инфраструктуре нельзя доверять, — Zero Trust распространяет этот принцип на User и рабочие нагрузки.

Проверьте, насколько хорошо Вы поняли изложенные в этом уроке концепции CompTIA Security+ (SY0-701).

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