В 2020 году компания SolarWinds была скомпрометирована через цепочку поставщиков ПО. Около 18 000 клиентов, включая несколько федеральных агентств США, установили обновление с бэкдором. Несмотря на то что инфраструктура SolarWinds была защищена традиционными периметральными средствами защиты — файрволами, VPN, антивирусами — атака оставалась незамеченной девять месяцев. Именно этот инцидент ускорил принятие Zero Trust как обязательного стандарта для государственного и корпоративного секторов.
В России переход к Zero Trust стимулируется другими событиями: серия атак на КИИ в 2022-2024 годах, требования ФСТЭК по защите государственных информационных систем, директива о переходе на отечественное ПО в критической инфраструктуре. В 2024 году ФСТЭК выпустил методические рекомендации по применению архитектуры нулевого доверия в государственных ИС, что де-факто означает движение рынка в эту сторону.
Что такое Zero Trust: принципы без маркетинга
Термин Zero Trust ввёл аналитик Forrester Джон Киндерваг в 2010 году. Концепция строится на трёх принципах: не доверяй никому по умолчанию (ни внутренним пользователям, ни сервисам, ни устройствам), проверяй каждый запрос доступа явно, применяй принцип минимальных привилегий.
Классическая модель сетевой безопасности строилась на идее периметра: всё внутри корпоративной сети считалось доверенным, всё снаружи — нет. Эта модель работала, пока сотрудники сидели в офисе, а приложения хостились в локальных ЦОД. Облако и удалённая работа разрушили периметр. Если сотрудник подключается из кафе через личный ноутбук к корпоративному приложению в Yandex Cloud — где граница «доверенного»?
Zero Trust отвечает на этот вопрос перемещением политики доступа с уровня сети на уровень идентификации и контекста. Каждый запрос проверяется по набору атрибутов: идентификатор пользователя, уровень аутентификации, состояние устройства, IP и геолокация, время суток, чувствительность запрашиваемого ресурса. Только при соответствии политике — доступ предоставляется.
Пять технических компонентов Zero Trust архитектуры
Управление идентификациями и доступом (IAM) — фундамент Zero Trust. Каждый пользователь и каждый сервис имеет уникальную идентификацию. Многофакторная аутентификация обязательна — желательно FIDO2/Passkey или TOTP-приложение, но не SMS. В облачном контексте: сервисные аккаунты с минимально необходимыми ролями, ротация ключей доступа по расписанию, запрет длительных сессий без повторной аутентификации. Yandex Cloud IAM, VK Cloud IAM и Cloud.ru Identity Service предоставляют эти возможности нативно; важно не оставлять Root-аккаунт без MFA и не использовать его в повседневной работе.
Микросегментация заменяет плоскую сеть на изолированные сегменты, где сервисы общаются только через явно разрешённые пути. В Kubernetes это реализуется через Network Policies: под сервиса А имеет право отправлять трафик только к сервису Б на порту 5432, и никуда больше. Если злоумышленник компрометирует сервис А, микросегментация ограничивает его возможности «двигаться вбок» по инфраструктуре (lateral movement). Service mesh (Istio, Linkerd) добавляет взаимную TLS-аутентификацию между сервисами — каждый микросервис проверяет сертификат собеседника.
Проверка состояния устройств (Device Trust) — обязательный элемент для компаний с удалёнными сотрудниками. Прежде чем предоставить доступ к корпоративному ресурсу, система проверяет: актуальна ли операционная система, обновлён ли антивирус, зашифрован ли диск, не скомпрометировано ли устройство. Корпоративные MDM/EDR-решения (Microsoft Intune, Jamf, CrowdStrike Falcon) предоставляют этот сигнал. Без него Zero Trust превращается в неполную реализацию.
Шифрование всего трафика (Encryption Everywhere) означает, что даже внутри частной сети весь трафик шифруется. HTTPS везде, mTLS между микросервисами, VPN или Wireguard для управляющего трафика. В облаке: данные в покое шифруются провайдером по умолчанию (AES-256), но для чувствительных данных рекомендуется Client-Side Encryption (CSE) — шифрование на стороне клиента до передачи в облако, чтобы провайдер не имел доступа к открытому тексту.
Непрерывный мониторинг и аналитика (Continuous Monitoring) закрывает петлю: Zero Trust не работает без видимости. Логи всех аутентификаций, запросов доступа, сетевых соединений собираются в SIEM. Отклонения от нормального поведения — аномальные время/география доступа, нестандартные объёмы данных — триггерят алерты. В российском контексте: платформы типа MaxPatrol SIEM (Positive Technologies) или Kaspersky SIEM.
Как внедрить Zero Trust в облаке: практический путь
Полноценное внедрение Zero Trust — это не проект, а трансформация, занимающая месяцы или годы. Но начать можно с нескольких высокоприоритетных шагов, дающих немедленный эффект.
Аудит привилегированного доступа: найдите все учётные записи с административными правами в облаке, на серверах и в базах данных. Отзовите избыточные права. Для каждого сервисного аккаунта — минимально необходимые разрешения. Это «низко висящий плод» Zero Trust: по данным Verizon Data Breach Investigations Report 2024, 74% инцидентов включают злоупотребление привилегиями. Один выходной достаточно для этого шага.
MFA для всего, что доступно из интернета. SSH к серверам через SSO-шлюз с MFA, а не через статичные ключи. VPN с MFA перед доступом к внутренним ресурсам. Облачные консоли управления с принудительным MFA (в Yandex Cloud и VK Cloud это настраивается в IAM). Даже при компрометации пароля злоумышленник без второго фактора не получит доступ.
Сегрегация сред: production, staging, development должны быть разделены на уровне аккаунтов или проектов в облаке, не просто на уровне имён ресурсов. Разработчик, имеющий доступ к dev, не должен иметь доступ к production по умолчанию. Это снижает риск случайного удаления данных и целенаправленного внутреннего нарушителя.
Требования ФСТЭК и КИИ
В России операторы критической информационной инфраструктуры обязаны соблюдать требования Федерального закона № 187-ФЗ «О безопасности КИИ». Категорированные объекты КИИ — АСУ ТП промышленных предприятий, энергетической отрасли, транспорта, банковского сектора, здравоохранения — подпадают под требования защиты, расписанные в приказах ФСТЭК № 235 и № 239.
Приказ ФСТЭК № 239 устанавливает меры по защите значимых объектов КИИ. Среди них — управление доступом с принципом минимальных привилегий, аутентификация с использованием двух и более факторов, защита периметра и сегментация сети, мониторинг и обнаружение инцидентов, шифрование данных при хранении и передаче. Это фактически является обязательным subset Zero Trust для критической инфраструктуры.
Cloud.ru и ряд других провайдеров имеют аттестованные сегменты ЦОД для обработки данных объектов КИИ. Важный нюанс: аттестация провайдера не снимает ответственности с оператора за конфигурацию и управление своими системами — только за физическую и базовую сетевую инфраструктуру.
Часто задаваемые вопросы
Zero Trust — это конкретный продукт или концепция?
Концепция. Конкретные продукты реализуют её отдельные аспекты: Zscaler, Cloudflare Access, Cisco Duo — для ZTNA (Zero Trust Network Access), CrowdStrike, Microsoft Defender — для Device Trust, HashiCorp Vault — для управления секретами. Полная реализация требует комбинации нескольких инструментов и, главное, изменения процессов.
Как реализовать Zero Trust без замены всей инфраструктуры?
Итеративно. Начните с идентификации и MFA — это не требует замены инфраструктуры. Затем добавьте Network Policies в Kubernetes. Затем перейдите к шифрованию трафика между сервисами. Каждый шаг независимо улучшает безопасность, не требуя полной трансформации.
Насколько дороже стоит Zero Trust-инфраструктура?
Операционные расходы выше на 15-30% — дополнительные продукты (SIEM, PAM, MDM), инженерные ресурсы на настройку и мониторинг. Но это нужно сравнивать со стоимостью инцидента: средний ущерб от утечки данных в России по данным InfoWatch за 2024 год составил 4,2 млн рублей для СМБ, и существенно больше для крупного бизнеса.
Security Check — проверьте параметры безопасности вашего соединения: Security Check.