Zero trust: что это значит на практике для компании среднего размера
Zero trust превратился в модное слово. За ним стоит по-настоящему полезная модель доступа - но добраться до неё требует конкретных решений, а не декларации о намерениях.
«Мы переходим на zero trust» - фразу, которую я слышу регулярно, обычно от менеджеров, прочитавших вендорский whitepaper или разбор инцидента. Реже я слышу конкретное описание того, что именно изменится. Именно в этом разрыве буксует большинство zero trust инициатив.
Zero trust - это не продукт. Это принцип проектирования доступа: не доверяй ни одному запросу по умолчанию, вне зависимости от его источника. Проверяй идентификацию, устройство, контекст - каждый раз, для каждого ресурса. Практическая реализация этого принципа и есть сложная часть - и стоит говорить о ней конкретно.
Что заменяет zero trust
Традиционная сетевая безопасность построена на периметре: внутри сети доверяют, снаружи - нет. VPN расширяет этот периметр на удалённых пользователей. Если вы внутри - или подключены через VPN - вы можете обращаться к ресурсам, доступным вашей учётной записи, нередко с широким горизонтальным перемещением по внутренней сети.
У этой модели есть очевидная слабость: как только атакующий оказался внутри, он перемещается свободно. Инцидент с CrowdStrike и многие атаки с программами-вымогателями следуют этой же схеме - первичная компрометация, которая затем бесконтрольно распространяется по плоской внутренней сети.
Zero trust заменяет периметровое доверие непрерывной верификацией. Вопрос не «этот запрос идёт изнутри сети?», а «может ли эта конкретная идентификация, на этом конкретном устройстве, в этом конкретном контексте, обращаться к этому конкретному ресурсу прямо сейчас?»
Четыре вещи, которые реально нужны для реализации
Принцип звучит чисто. Реализация предполагает четыре конкретных требования.
Идентификация. Каждый пользователь и каждый сервис нуждается в сильной управляемой идентификации. Это означает каталог (обычно IDP - Azure AD, Okta или Google Workspace), обязательный MFA для всех людей, и сервисные аккаунты с ограниченными правами вместо общих учётных данных.
Доверие к устройству. Устройство, отправляющее запрос, должно быть в известном состоянии. Как правило, это MDM, который может проверить уровень обновлений, шифрование диска и статус защиты конечных точек перед предоставлением доступа.
Минимальные привилегии. Ресурсы должны быть сегментированы и доступны только тем идентификациям, которым это необходимо. На практике это означает проверку и ужесточение существующих разрешений - нередко самую политически сложную часть.
Непрерывная верификация. Доверие к сессии не должно предполагаться после единственного входа. Короткоживущие токены, периодическая повторная аутентификация для чувствительных операций и обнаружение аномалий - инструменты этого слоя.
С чего начать, не перестраивая всё подряд
Большинство компаний среднего размера не могут реализовать всё это сразу - и не должны пытаться. Практическая последовательность:
- Сначала наведите порядок с идентификацией. Если нет центрального IDP с обязательным MFA везде - это единственный наиболее результативный шаг, и он достижим быстро.
- Проверьте, что доступно всем на внутренней сети. Сначала сегментируйте системы с наибольшим риском - финансы, HR, репозитории с кодом, производственную инфраструктуру.
- Введите проверку состояния устройств для доступа к критичным приложениям. Большинство современных IDP это поддерживают без замены всей инфраструктуры.
- Замените широкий VPN-доступ доступом к конкретным приложениям для удалённых пользователей. ZTNA-инструменты стали доступными по цене и разворачиваются без полной замены инфраструктуры.
Ни один из этих шагов не требует полного архитектурного переосмысления. Каждый измеримо уменьшает радиус поражения при компрометации.
Часть, которая всегда сложнее технологии
По моему опыту, технологии для zero trust доступны и доступны по цене. Сложная часть - организационная: кто-то должен отвечать за периодический аудит доступа, кто-то должен настаивать на ужесточении разрешений, когда это создаёт неудобства, и руководство должно принять, что безопасность и удобство - это компромисс.
Zero trust не работает не потому, что инструменты плохие. Он не работает потому, что никто не решил, кто владеет управлением доступом на постоянной основе.