Zero Trust: принципы, архитектура и внедрение модели нулевого доверия

Zero Trust (от английского «нулевое доверие») — это концепция кибербезопасности, согласно которой по умолчанию нельзя доверять ни одному пользователю, приложению или устройству. Даже если они находятся внутри корпоративной сети и раньше успешно проходили проверки безопасности. Модель опирается на:

• непрерывную проверку каждого запроса вне зависимости от сети;

• принцип минимальных привилегий;

• предположение о возможной компрометации инфраструктуры (assume breach). 

Эти подходы есть в новых ИБ-стандартах и публикации NIST SP 800-207, посвященной Zero Trust Architecture.

Концепция Zero Trust строится по принципу Never trust, always verify — «никогда не доверяй, всегда проверяй». Подход меняет не только периметр информационной безопасности, но и саму логику предоставления доступа. В этом главное отличие от традиционной периметровой защиты, где объекты корпоративной сети считаются доверенными. 

Ключевые практические принципы концепции нулевого доверия 

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

Обязательные меры:

• Проверка состояния устройств. Оценивается безопасность серверов, корпоративных ноутбуков и компьютеров, с которых пользователи будут заходить в корпоративные системы и приложения.

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

• Принцип наименьших привилегий (Least Privilege). Выдача пользователям и программам только тех прав, которые необходимы для работы. Полномочия нужно постоянно пересматривать и отзывать неактуальные.  

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

Zero Trust — архитектура и дорожная карта, а не готовый продукт

Некоторые ошибочно думают, что для безопасности достаточно купить конкретный продукт одной лицензией. Нет, Zero Trust — модель ИБ, которую внедряют поэтапно. Она объединяет контроль доступа, проверки устройств и пользователей, мониторинг действий внутри инфраструктуры и защиту критичных данных. Для реализации необходимы разные технические решения, а главное — готовность команды к изменениям и новым корпоративным политикам. 

Краткое сравнение с традиционной периметровой моделью:

Чтобы концепция работала, нужны разные уровни защиты, каждый из которых будет закрывать свою часть рисков. 

Идентичность

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

Чтобы снизить риски атак при компрометации аккаунтов, разумно внедрить многофакторную аутентификацию (MFA). Помимо пароля или ключа пользователь должен будет предъявить системе что-то еще, например, одноразовый код, токен, биометрию. 

Устройство и контекст: условия доступа

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

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

Доступ к приложениям: ZTNA вместо подключения ко всей сети

VPN обычно предоставляет доступ к корпоративной сети, а ZTNA (Zero Trust Network Access) — только к конкретным приложениям после проверки пользователя и устройства. Например, подрядчик сможет работать в одной системе, но не получит доступ к другим приложениям и базам данных. Так даже при компрометации его учетной записи злоумышленник не сможет свободно перемещаться по сети.

Сеть и нагрузки

Политика нулевого доверия подразумевает микросегментацию — разделение сети на несколько изолируемых сегментов, которые не могут обмениваться трафиком. Если один будет взломан, атака не пойдет дальше. 

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

Данные и наблюдаемость

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

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

Мы уже вкратце рассказывали о ZTNA. Объясним подробнее, как работает доступ. VPN, как правило, предоставляет доступ на сетевом уровне (к сегментам сети), тогда как ZTNA — к конкретным приложениям после проверки. VPN может быть ограничен политиками, но даже в этом случае после установления туннеля пользователь часто получает более широкий сетевой доступ, чем при ZTNA. 

ZTNA ограничивает доступ конкретными приложениями. Например, подрядчик может работать только с CRM, а другие системы для него закрыты. Если аккаунт будет скомпрометирован, злоумышленники не смогут свободно продвигаться по инфраструктуре. 

Когда VPN остается

ZTNA подходит для управления доступом к отдельным приложениям, но не всегда заменяет VPN. VPN нужен, когда сотруднику требуется подключение к целому сегменту сети или приложение не поддерживает интеграцию с ZTNA.

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

Переход к модели нулевого доверия можно условно разделить на пять этапов. 

Этап 1. Инвентаризация: пользователи, устройства, сервисы, интеграции и подрядчики

Составьте перечень учетных записей, корпоративных устройств, приложений, серверов и связей между системами. Проверьте технические учетки, API-ключи и доступ подрядчиков. Что нужно выяснить:

• кто какими системами пользуется;

• сколько есть привилегированных учеток и за кем они закреплены;

• какие сервисы и приложения могут обмениваться данными.

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

Этап 2. Классификация ресурсов и выбор пилотной системы

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

Этап 3. Идентичность и MFA, минимальные привилегии

Подключите централизованное управление учетными записями и многофакторную аутентификацию (MFA), особенно для удаленного доступа и привилегированных пользователей. Пересмотрите текущие права, отзовите избыточные и «забытые». Введите метрики времени выдачи и отзыва доступа.

Этап 4. Замена сетевого доступа на доступ к приложениям, микросегментация

Постепенно замените сетевой доступ (там, где это возможно) на доступ к конкретным сервисам. Если для каких-то систем не подходит ZTNA, ужесточите правила для подключения через VPN. 

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

Этап 5. Наблюдаемость и автоматический отзыв прав

Настройте журналы для отслеживания входов и запросов, изменений привилегий, действий администраторов. Чтобы было удобнее анализировать события из разных систем, предусмотрите корреляцию. Для этого подойдет SIEM-система (Security Information and Event Management). Она поможет выполнять поведенческую аналитику и складывать цепочки событий, которые по отдельности выглядят нормально, а по факту являются атакой. 

Zero Trust архитектура не гарантирует защиту, если не учитывать в правилах реальные рабочие процессы. Как компании ошибаются на старте:

• Покупают инструменты безопасности до аудита инфраструктуры. Без инвентаризации пользователей, устройств, приложений и прав доступа сложно определиться с мерами защиты. Представьте, компания внедряет систему контроля доступа, даже не зная, какие права накопились у сотрудников. Работать система будет, но по-настоящему защищать — нет. 

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

• Упускают из вида сервисные учетки. Именно под ними часто работают приложения, сервисы и интеграции. Если их не контролировать, могут накопиться бессрочные ключи доступа или избыточные права. При компрометации таких учеток они попадут к злоумышленникам и станут причиной инцидентов ИБ. 

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

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

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

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

Идентичность и права доступа

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

Сегментация и периметр

Для ограничения сетевого доступа и контроля границ сети Cloud.ru предлагает несколько инструментов:

• UserGate (виртуальный NGFW) — межсетевой экран нового поколения для фильтрации трафика, разграничения доступа между сегментами сети и контроля сетевых взаимодействий.

• Curator Anti-DDoS — фильтрация трафика и защита от DDoS-атак. Для защиты веб-приложений от взлома (эксплуатации уязвимостей, инъекций и т.п.) предназначен WAF, который в Cloud.ru доступен в составе решения Curator Anti-DDoS+WAF. 

• Curator Anti-DDoS+WAF — комбинированное решение: фильтрация DDoS-трафика и защита веб-приложений от взлома (WAF). 

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

• Direct Connect — выделенное высокоскоростное физическое подключение между ЦОД или офисом и облаком.

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

Нагрузки и наблюдаемость

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

• Evolution Container Security — проверяет контейнерные образы, конфигурации и хосты на уязвимости, позволяет задавать политики безопасности и контролировать действия в Kubernetes-среде.

• Cloud Logging — собирает и анализирует логи облачных сервисов и приложений, помогает искать нужные события и настраивать уведомления. Данные можно через API отправлять в сторонние системы.

• Cloud Monitoring — собирает метрики инфраструктуры и приложений, отображает их на дашбордах и отправляет оповещения об аномалиях.

• Cloud Advisor — анализирует уязвимости, конфигурации и права доступа к облачным ресурсам. Также выявляет риски, связанные с публичной доступностью и настройками IAM. Сервис поддерживает интеграцию с SIEM.

Комплаенс

Платформа Cloud.ru Evolution аттестована по требованиям безопасности информационных систем персональных данных уровня УЗ-1 согласно 152-ФЗ. Сервисы прошли оценку по ГОСТ Р 57580. Для систем критической информационной инфраструктуры провайдер предлагает аттестованное «Облако для КИИ», для размещения инфраструктуры в собственном контуре — платформу Cloud.ru Evolution Stack, сертифицированную ФСТЭК России. 

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

1. Проверяется ли личность пользователя при каждом доступе к корпоративным ресурсам?

2. Включена ли MFA для доступа к критичным системам?

3. Учитывается ли состояние устройств при принятии решения о доступе?

4. Соблюдается ли принцип минимальных привилегий?

5. Ограничен ли доступ подрядчиков конкретными приложениями и данными?

6. Блокируются ли вовремя неактуальные учетные записи, пересматриваются ли права доступа?

7. Контролируются ли сервисные аккаунты?

8. Ведется ли инвентаризация активов и сервисов, включая API-интеграции и автоматизированные процессы?

9. Изолируются ли критичные системы друг от друга?

10. Пересматриваются ли политики доступа с учетом ландшафта актуальных угроз и изменений инфраструктуры?

Заключение

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

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

FAQ

• Что такое Zero Trust простыми словами?

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

• Чем модель нулевого доверия отличается от периметровой защиты?

  Периметровая защита направлена на границы корпоративной сети и подразумевает доверие к внутренним ресурсам. В Zero Trust организованы постоянный контроль и проверки. 

• Чем ZTNA отличается от VPN?

  VPN создает защищенное соединение с сетью и позволяет открывать доступ к внутренним ресурсам. ZTNA предоставляет доступ только к заранее разрешенным приложениям после проверки пользователей и устройств.

• Что такое микросегментация и зачем она нужна?

  Микросегментация делит сеть на изолированные сегменты со своими правилами доступа. Это помогает сдержать атаку, если злоумышленник уже получил доступ к каким-то ресурсам.

• С чего начать внедрение Zero Trust в компании?

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

• Сколько времени занимает переход на модель нулевого доверия?

  Срок зависит от масштаба инфраструктуры и готовности компании. Для небольших организаций полноценный переход может занять несколько месяцев; для крупных предприятий с гетерогенной инфраструктурой — 12–18 месяцев и более. Первые меры (например, включение MFA или инвентаризация) можно внедрить за 2–3 недели.

• Подходит ли Zero Trust для работы с легаси-системами?

  Да, но нужно учитывать ограничения. Если система не поддерживает современные механизмы аутентификации, можно организовать контроль доступа через шлюзы, прокси-серверы и сетевую сегментацию.