Zero Trust против VPN: архитектура нулевого доверия в enterprise

Содержание

• Периметр, которому больше нельзя доверять
• Что такое Zero Trust на самом деле
• Чем Zero Trust отличается от VPN
• Пять столпов нулевого доверия
• Микросегментация: от крупных зон к бизнес-процессам
• SSO, MFA и PAM как фундамент Zero Trust
• Как внедрять Zero Trust поэтапно
• Типичные ошибки внедрения
• Российский контекст и импортозамещение
• FAQ

Большинство корпоративных сетей до сих пор устроены по принципу замка со рвом: снаружи — враждебный интернет, внутри — доверенная зона, а граница между ними проходит по периметру. Попал внутрь — значит, ты свой, и дальше можешь обращаться почти к чему угодно. Эта модель работала, пока «внутри» означало физический офис с кабелями. Сегодня внутри — облака, контейнеры, бессерверные функции, удалённые сотрудники через VPN и подрядчики с чужих ноутбуков. Граница размылась, а доверие по факту нахождения «внутри» превратилось в главную уязвимость.

Эта статья — практический разбор архитектуры нулевого доверия (Zero Trust): что стоит за принципом «никогда не доверяй, всегда проверяй», чем Zero Trust отличается от VPN, из каких столпов он собирается и как внедрять его поэтапно, не ломая работающий бизнес. Материал рассчитан на технических руководителей и команды, которые строят корпоративные системы на Java/Kotlin, — именно с таким стеком мы в Новакоме работаем чаще всего.

Периметр, которому больше нельзя доверять

У классической периметровой модели есть врождённый дефект. Она исходит из того, что внутри защищённого контура — будь то корпоративная сеть, Kubernetes-кластер или само предприятие — все участники доверенные. Раз ты прошёл через шлюз, значит «ты парень хороший, делай что хочешь». Один микросервис вызывает другой — стало быть, вызывающему можно. Пользователь подобрал параметр в URL — и получил доступ к данным другого пользователя.

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

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

Что такое Zero Trust на самом деле

Главное недопонимание вокруг Zero Trust: его воспринимают как продукт или технологию, которую можно купить и «включить». Это не так. Zero Trust — это сдвиг мышления, а не фреймворк. Нельзя сказать «мы сделали пункты A, B и C, теперь мы Zero Trust». Это набор принципов, под которые подстраивается архитектура.

Сам термин не вполне точен. «Нулевое доверие» звучит громко, но на практике речь идёт о расширяемом доверии: по умолчанию мы не доверяем никому, но после того как пользователь или сетевой узел докажет, что с ним всё в порядке, — мы расширяем уровень доверия. И самое важное: это доверие не выдаётся навсегда. Оно постоянно пересматривается.

Принцип формулируется коротко: «никогда не доверяй, всегда проверяй» (never trust, always verify). Даже если устройство известно, а пользователь уже заходил час назад, доступ к каждому ресурсу проверяется и авторизуется заново. Доступ выдаётся гранулярно — к конкретному приложению или ресурсу, а не «ко всей сети». Соединения между пользователем и ресурсом строятся как один-к-одному и периодически пересоздаются и перепроверяются.

Из этого складываются три базовых требования к любому запросу:

1. Явная проверка. Аутентифицируйте и авторизуйте на основе максимума доступной информации — не только логина и пароля, но и устройства, геолокации, поведения, времени, контекста запроса.
2. Минимальные привилегии. Пользователь получает доступ только к той части ресурсов, которая нужна для его роли, — и не более.
3. Предположение о компрометации. Проектируйте систему так, будто атакующий уже внутри: минимизируйте радиус поражения, сегментируйте, шифруйте, ведите аудит.

Чем Zero Trust отличается от VPN

VPN и Zero Trust часто противопоставляют, и это правильно — они решают разные задачи, хотя оба касаются удалённого доступа. VPN расширяет частную сеть поверх публичного интернета: создаёт зашифрованный туннель и пускает удалённого пользователя «внутрь» корпоративной сети. И вот здесь зарыта проблема: получив доступ по VPN, пользователь обычно получает доступ ко всей сети, а не к конкретному приложению. Контроль строится на уровне сети и подсети, по IP-адресам, а видимость того, что пользователь делает после подключения, минимальна.

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

Важная оговорка: Zero Trust не отменяет VPN полностью и не «лечит» все его недостатки. VPN отлично решает свою задачу — шифрование канала и приватность, особенно в недоверенных сетях. Но как модель корпоративного контроля доступа периметровый VPN исчерпал себя: он плохо масштабируется на большое число удалённых пользователей, даёт слабую видимость и при неверной настройке сам становится точкой входа для атаки. ZTNA (Zero Trust Network Access) строится поверх публичного интернета с TLS-шифрованием и заменяет логику «пустить в сеть» логикой «дать доступ к ресурсу».

Пять столпов нулевого доверия

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

1. Идентичность. Фундамент всей модели. Нужно достоверно установить, что пользователь — тот, за кого себя выдаёт, и что он авторизован на запрашиваемый ресурс. Это аутентификация и авторизация на основе максимума контекста, а не пары «логин-пароль». Сюда же относится идентичность сервисов и рабочих нагрузок: микросервис, вызывающий другой микросервис, тоже должен предъявить, кто он.

2. Состояние устройства (device posture). Известное устройство — ещё не доверенное. Проверяется, соответствует ли оно политике безопасности: обновления, шифрование диска, антивирус, нет ли подозрительных признаков, ведёт ли оно себя так же, как раньше. Скомпрометированное устройство легитимного пользователя — типичный вектор атаки, и Zero Trust обязан его отсекать.

3. Микросегментация. Сеть разбивается на мелкие изолированные зоны вплоть до отдельного приложения, так чтобы компрометация одного сегмента не открывала доступ к остальным. О ней — отдельный раздел ниже.

4. Минимальные привилегии (least privilege). Каждый субъект получает ровно тот доступ, который нужен для задачи, и только на то время, что он нужен. Доступ на конкретное место и конкретный срок, после чего он автоматически закрывается. Это резко ограничивает, что атакующий сможет сделать, даже если проникнет внутрь.

5. Непрерывная проверка. Доверие не статично. Любое изменение идентичности, контекста или состояния устройства переоценивается, а доступ при необходимости отзывается. Это и есть третий столп архитектуры: постоянная проверка того, насколько мы всё ещё можем доверять удалённому узлу. Решения о доступе принимает центральный компонент — политический сервер (policy engine), через который проходит каждый запрос.

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

Микросегментация: от крупных зон к бизнес-процессам

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

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

На практике это выливается в несколько подходов:

• Шлюзовой доступ. Перед зоной подразумеваемого доверия стоит шлюз безопасности, внешние узлы подключаются к нему, а внутренняя инфраструктура от них скрыта — поверхность атаки минимальна.
• Контейнеризация приложений. Каждое приложение упаковано в изолированный контейнер на рабочем месте, и доступ к ресурсу идёт именно из этого контейнера, отделённого от остальных.
• Портальный (бесклиентский) вариант. На устройстве удалённого пользователя ничего не установлено — он заходит на специальный портал и работает с приложениями через него, не получая сетевого доступа как такового.

Сложность в том, что современная инфраструктура крайне разнородна: физические серверы, виртуальные машины, контейнеры, бессерверные вычисления, часть — в облаке, часть — on-premise, и поверх всего наложены требования регуляторов. Микросегментация должна работать одинаково во всех этих средах, и это главная инженерная задача внедрения.

SSO, MFA и PAM как фундамент Zero Trust

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

Единый вход (SSO) даёт центральную точку, где сосредоточены аутентификация, политика и аудит. Без него каждое приложение проверяет пользователя по-своему, и о единой политике доверия говорить нечего. Мы подробно разбирали, как строить корпоративный SSO и MFA на Apereo CAS и как делается Keycloak SSO на Spring Boot — это та самая центральная точка контроля, на которую опирается Zero Trust.

Многофакторная аутентификация (MFA) — это техническая реализация «явной проверки». Пароль сам по себе уже не доказательство идентичности. Уровень доверия к сессии определяется не фактом входа, а тем, какие факторы и при каких условиях были пройдены: для критичных систем — фишинг-устойчивый FIDO2, для остального — TOTP или push. В архитектуре Zero Trust это означает адаптивный доступ: чем чувствительнее ресурс, тем строже требование к факторам.

Привилегированный доступ (PAM) закрывает столп минимальных привилегий для самых опасных учёток — администраторов и сервисных аккаунтов. Здесь хорошо работает принцип, который мы видели у заказчиков: не выдавать учётку, а выдавать доступ. Вместо того чтобы заводить и потом сбрасывать постоянные учётные записи, доступ предоставляется на конкретное место и конкретное время — и автоматически закрывается, когда срок истёк. Это и есть least privilege в действии: нет постоянных привилегий — нечего и компрометировать.

Связка проста: SSO даёт единую идентичность, MFA — её достоверность, PAM — контроль над привилегиями, а Zero Trust связывает всё это политикой непрерывной проверки. Без этого фундамента «нулевое доверие» остаётся лозунгом.

Как внедрять Zero Trust поэтапно

Zero Trust нельзя «развернуть» за один спринт — это путь, а не релиз. На практике мы рекомендуем такую последовательность.

1. Инвентаризация и моделирование потоков. Соберите карту: какие есть приложения, данные, пользователи и как они взаимодействуют. Часто на этом этапе выясняется, что часть систем вообще не логирует доступ, а реальные потоки данных не совпадают с тем, что нарисовано в документации.
2. Наведите порядок в идентичности. Поднимите единый вход, подключите каталог пользователей, включите MFA хотя бы для критичных систем и привилегированных ролей. Это фундамент — без него остальное не имеет смысла.
3. Введите least privilege и PAM. Пересмотрите права: уберите избыточные доступы, переведите администраторов на временный доступ вместо постоянных учёток.
4. Сегментируйте по приоритету. Начните микросегментацию с самых ценных активов — финансовых данных, систем под требованиями регулятора, — а не со всей сети сразу. Скройте инфраструктуру за шлюзом, изолируйте критичные приложения.
5. Замените сетевой доступ на ресурсный. Там, где сегодня VPN пускает пользователя «в сеть», постепенно переходите на ZTNA-доступ к конкретным приложениям.
6. Включите непрерывный мониторинг. Все события доступа должны писаться и анализироваться в реальном времени — это и основа для отзыва доверия, и материал для расследования инцидентов.

Ключевая мысль: каждый шаг повышает защищённость сам по себе, даже если вы никогда не дойдёте до «полного» Zero Trust. Зрелое SSO+MFA уже снижает риск, микросегментация критичных систем — снижает ещё, и так далее. Поэтому двигаться нужно итеративно, от самых ценных активов к остальным.

Типичные ошибки внедрения

• Воспринимать Zero Trust как продукт. Покупка «решения Zero Trust» без пересмотра процессов и политики не даёт нулевого доверия. Это в первую очередь архитектурный подход, и вендорский ярлык на коробке его не заменяет.
• Начинать с сети, а не с идентичности. Микросегментация поверх слабой аутентификации бессмысленна: если идентичность подделывается, гранулярные политики бесполезны. Сначала SSO, MFA и порядок в правах.
• Глобальное включение «рубильником». Попытка разом перевести весь контур ломает доступ и провоцирует откат. Идти нужно по одному приложению и от ценных активов к менее критичным.
• Игнорировать состояние устройства. Проверять только пользователя, забывая про устройство, — значит оставить открытым один из главных векторов: скомпрометированный ноутбук легитимного сотрудника.
• Считать доверие постоянным. Если после входа доступ больше не перепроверяется, это не Zero Trust, а тот же периметр, просто с более строгой дверью. Непрерывная проверка — не опция.
• Забыть про сервис-сервис. Доверие между микросервисами по принципу «раз меня вызвали, значит можно» — внутренняя версия того же периметрового дефекта. Сервисы должны аутентифицировать друг друга так же, как пользователи.

Российский контекст и импортозамещение

Для российского enterprise Zero Trust имеет дополнительное измерение. С одной стороны, концепция нулевого доверия и поддерживающие её технологии — корпоративный VPN, защищённый удалённый доступ, шифрованные каналы, SSO, средства мониторинга — это обычная часть современной информационной безопасности, а не способ что-то обойти. Это стоит проговаривать явно, потому что в публичном поле эти инструменты иногда смешивают с обходом блокировок, хотя задачи у них принципиально разные.

С другой стороны, есть требования регуляторов и курс на технологическую независимость. Zero Trust здесь скорее союзник: модель не привязана к конкретному вендору и собирается из компонентов, которые можно заместить отечественными. Второй фактор строится на российских носителях (Рутокен MFA и аналоги), SSO разворачивается self-hosted внутри периметра, хранение событий доступа остаётся под контролем — что упрощает выполнение требований 152-ФЗ. Это та же логика, что и в общем импортозамещении ПО: нет внешней SaaS как единой точки отказа, ключи и логи не покидают контур.

Отдельно стоит держать в уме периметр устройств. Zero Trust проверяет состояние каждого устройства — а парк современной организации включает не только ноутбуки, но и IoT-технику, промышленные контроллеры, сетевое оборудование. Для них действуют свои классы угроз; мы разбирали их в материале про OWASP IoT Top 10. В архитектуре нулевого доверия такие устройства — полноправные субъекты, к которым применяются те же принципы идентичности и минимальных привилегий.

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

FAQ

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

Можно ли купить готовый Zero Trust? Нет. Вендоры продают компоненты — ZTNA-шлюзы, MFA, системы управления идентичностью, — но сам Zero Trust это архитектурный подход и политика, которые выстраиваются под конкретную инфраструктуру. Коробочного «нулевого доверия» не существует.

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

Чем микросегментация отличается от обычной сегментации сети? Масштабом и логикой. Классическая сегментация делит сеть крупными блоками (пользователи, приложения, среды). Микросегментация изолирует вплоть до отдельного приложения и идёт от бизнес-процессов, минимизируя зону подразумеваемого доверия.

Подходит ли Zero Trust небольшой компании? Да, потому что это путь, а не разовый проект. Даже первые шаги — единый вход с MFA и least privilege для администраторов — заметно снижают риск, не требуя сразу перестраивать всю сеть. Дальше можно двигаться итеративно по мере роста.

Если вы планируете переход к архитектуре нулевого доверия — от наведения порядка в идентичности и MFA до микросегментации и ZTNA — мы в Новакоме проектируем и внедряем такие решения на Java/Kotlin-стеке в корпоративном контуре. Посмотрите наши услуги по разработке на Spring и аутстаффингу Java-команд или напишите нам с описанием вашей инфраструктуры.