«Модель Zero Trust изначально была привязана к экосистеме западных вендоров, но её суть — не в конкретных продуктах, а в архитектурных принципах. Эти принципы универсальны и могут быть реализованы на отечественном технологическом стеке, хотя путь будет сложнее и потребует больше инженерной работы, а не просто нажатия кнопок в корпоративной консоли.»
Что такое Zero Trust на самом деле, если отбросить маркетинг
Название «Zero Trust» вызывает ощущение недоверия ко всему, но на деле это формализация здоровой паранойи, которую хорошие системные администраторы практиковали всегда. Идея проста: периметр сети, будь то корпоративный VPN или фаервол, больше не считается надёжной границей. Угроза может исходить изнутри, а аутентифицированное устройство — быть скомпрометированным. Поэтому каждое обращение к ресурсу — к серверу, базе данных, приложению — должно проверяться заново, как будто оно пришло из открытого интернета.
Это не единый продукт, который можно купить и включить. Это совокупность принципов, которую Национальный институт стандартов и технологий США (NIST) оформил в документе SP 800-207. Ключевые из них:
- Явная проверка: Никто и ничто не получает доверие по умолчанию. Аутентификация и авторизация обязательны для каждого запроса.
- Минимальные привилегии: Пользователи и службы получают доступ ровно к тем ресурсам, которые нужны для выполнения задачи, и не более.
- Предположение о компрометации: Система проектируется так, будто взлом внутренней сети — лишь вопрос времени. Акцент смещается на обнаружение аномалий, сегментацию и контроль сессий.
Именно эти принципы, а не бренд на коробке, и являются ядром. Они не привязаны к конкретной операционной системе или железу.
Западный стек: готовый конструктор с ограничениями
Такие компании как Palo Alto Networks, Zscaler, CrowdStrike или Microsoft (с их решением Azure Active Directory и Microsoft Defender) предлагают комплексные платформы. Они интегрируют множество компонентов Zero Trust в единую панель управления:
- Шлюз безопасного доступа (Secure Access Service Edge, SASE/SSE).
- Агенты для проверки состояния устройств (Endpoint Detection and Response, EDR).
- Системы управления идентификацией и доступом (Identity and Access Management, IAM).
- Аналитику поведения пользователей и сущностей (User and Entity Behavior Analytics, UEBA).
Преимущество очевидно: скорость внедрения, единая техподдержка, часто высокая степень автоматизации. Однако за этим следуют риски, которые стали особенно актуальны в последние годы: зависимость от зарубежной инфраструктуры и обновлений, потенциальные ограничения на поставки, скрытая передача телеметрии, а также жёсткая привязка к экосистеме вендора.
В российском регуляторном поле, где 152-ФЗ требует локализации персональных данных, а ФСТЭК предъявляет требования к средствам защиты информации, слепое использование западной платформы может создать больше проблем, чем решить.
Сборка Zero Trust из отечественных и open-source компонентов
Построение Zero Trust без западных вендоров, это переход от модели «покупка платформы» к модели «сборка архитектуры». Это сложнее, но даёт полный контроль и возможность глубокой адаптации под требования ФСТЭК и 152-ФЗ.
1. Идентификация и аутентификация (IAM)
Это фундамент. Вместо Azure AD или Okta можно рассмотреть:
- Open-source решения: Keycloak или FreeIPA. Keycloak — мощный сервер идентификации с поддержкой OAuth 2.0, OpenID Connect, SAML. Он может выступать центральным провайдером идентичности, интегрироваться с Active Directory или отечественными СКЗИ (средствами криптографической защиты информации) для двухфакторной аутентификации.
- Отечественные разработки: Ряд российских вендоров предлагают системы управления доступом, совместимые с ГОСТ-шифрованием и электронными подписями. Их важно проверить на способность работать по протоколам современного Zero Trust (например, выдавать короткоживущие токены).
2. Шлюз безопасного доступа и контроль сессий
Это замена традиционному VPN. Вместо Zscaler или Cloudflare Access можно использовать:
- Open-source обратные прокси с политиками доступа: Traefik или NGINX в связке с модулями аутентификации (например, lua-скриптами). Они могут проверять JWT-токен, выданный Keycloak, перед тем как пропустить запрос к внутреннему приложению.
- Сервисные сетки (Service Mesh): Istio или Linkerd для микросервисных архитектур. Они реализуют принцип Zero Trust на уровне сервис-сервисного взаимодействия: автоматически шифруют трафик (mTLS) и проверяют политики доступа между каждыми двумя микросервисами, даже внутри одного кластера.
[КОД: Пример фрагмента политики доступа Istio для разрешения вызова только от конкретного сервиса]3. Верификация устройств и непрерывная оценка безопасности
Перед предоставлением доступа система должна убедиться, что устройство соответствует политикам безопасности (обновлена ОС, стоит антивирус, включён шифрование диска). На западе этим занимаются агенты EDR.
Альтернативы:
- Самописные агенты и системы мониторинга: На базе Osquery (инструмент от Facebook с открытым кодом) можно собрать информацию о состоянии тысяч рабочих станций и отправлять её в SIEM-систему. Российские SIEM (например, «Максим» или «Гарда») могут анализировать эти данные и передавать решение о «здоровье» устройства шлюзу доступа.
- Интеграция с отечественными средствами защиты информации (СЗИ): Многие российские СЗИ, сертифицированные ФСТЭК, имеют API. Через него можно запрашивать статус защиты на конечной точке и использовать это как один из факторов для принятия решения о доступе.
4. Сегментация и микросетевое разграничение
Это предотвращает lateral movement — перемещение злоумышленника внутри сети после взлома одной системы.
- Сетевые политики Kubernetes (Network Policies): Для контейнерных сред это основной инструмент. Они определяют, каким подам (группам контейнеров) разрешено общаться между собой и с внешним миром.
- Гостевые ОС и гипервизоры: Использование российских гипервизоров (например, на базе KVM) с жёсткой изоляцией виртуальных машин и настройкой правил фильтрации на уровне виртуальных коммутаторов (Open vSwitch).
Где подстерегают сложности
Сборная архитектура — не панацея. Её главные вызовы:
- Интеграция: Все компоненты (Keycloak, Traefik, Osquery, SIEM) должны не просто работать, а обмениваться данными в реальном времени. Нужно разрабатывать и поддерживать коннекторы, скрипты, API-интеграции. Это требует высокой квалификации команды.
- Единое управление политиками: В коммерческой платформе политики (кто, с какого устройства, к чему имеет доступ) задаются в одном месте. В сборном решении политики могут быть разбросаны по конфигам Traefik, правилам Istio, настройкам Keycloak и сценариям в SIEM. Необходима строгая дисциплина документирования и, возможно, свой портал для централизованного управления.
- Масштабирование и отказоустойчивость: Каждый самодельный компонент становится критичным звеном. Шлюз доступа на базе NGINX нужно развернуть в отказоустойчивом кластере, настроить его мониторинг и аварийное восстановление.
- Соответствие требованиям ФСТЭК: Не каждое open-source решение имеет сертификат ФСТЭК. Его наличие или возможность получения — ключевой критерий выбора для систем, обрабатывающих государственную тайну или персональные данные в госсекторе. Отечественные аналоги часто уже сертифицированы, но их функционал может уступать.
Практический путь: гибридный подход
Наиболее реалистичная стратегия для многих российских компаний — не чистая «сборка», и не чистая «покупка», а гибрид.
- Базовый уровень (публичные сервисы, сотрудники): Для защиты веб-приложений и удалённого доступа сотрудников можно использовать российские облачные SASE-решения, которые уже появляются на рынке и строятся на отечественной инфраструктуре.
- Критичный периметр (ядро данных, производственные системы): Для самых ценных активов — систем, попадающих под строгие требования регуляторов, — строить кастомную Zero Trust-архитектуру внутри своего ЦОДа или приватного облака. Использовать сертифицированные ФСТЭК СЗИ, отечественные гипервизоры и шифрование по ГОСТ, а в качестве логики доступа — адаптированные open-source инструменты.
Такой подход позволяет начать быстро с готовых сервисов там, где это безопасно, и параллельно, без спешки, создавать полностью контролируемую среду для самых важных данных.
Итог: возможно, но иначе
Построить Zero Trust без западных вендоров возможно. Однако это будет не простая замена одного продукта на другой, а создание собственной security-платформы. Это путь от потребителя технологий к их архитектору.
Успех зависит от трёх факторов: наличия команды, способной глубоко разбираться в сетевых протоколах, аутентификации и безопасности; готовности инвестировать время в интеграцию, а не только в лицензии; и чёткого понимания, какие компоненты можно взять из open-source мира, а какие — только из перечня сертифицированных ФСТЭК решений. В результате получается не просто «аналог», а система, заточенная под конкретные требования российского законодательства и бизнеса, лишённая скрытых зависимостей.