Подрядчик подключается по VPN с домашнего ноутбука и автоматически оказывается во внутренней сети рядом с боевыми серверами: его сессия видит файловые шары, базу 1С, контроллер домена и бэкап-сервер, потому что классический файрвол доверяет любому, кто прошёл проверку на входе.
На таком ландшафте - облака, удалёнка, BYOD у руководства, подрядчики с правами администратора на своих устройствах, модель «жёсткий периметр, мягкое нутро» перестаёт защищать. Подход zero trust для серверной инфраструктуры исходит из обратной установки: считаем, что злоумышленник уже внутри, и проверяем каждый запрос как пришедший из недоверенной сети.
Что такое Zero Trust и чем отличается от классической модели
Zero Trust (нулевое доверие) — модель безопасности, в которой ни пользователь, ни устройство, ни сервис не получают доступ только потому, что находятся внутри сети. Модель описана в стандарте NIST SP 800-207 и сводится к фразе «никогда не доверяй, всегда проверяй». В ее основе три принципа:
- Не доверять по умолчанию ни пользователю, ни устройству, где бы они ни находились;
- Выдавать минимальные привилегии, нужные для конкретной задачи;
- Постоянно проверять каждый запрос доступа, а не только момент входа.
Каждый запрос оценивается заново: кто его делает (пользователь, сервисный аккаунт), с какого устройства, в каком оно состоянии и к какому сервису обращается. Доверие не наследуется ни от факта подключения к VPN, ни от того, что запрос пришёл «изнутри».
Классика устроена иначе - «жёсткий периметр и мягкое нутро». Снаружи стоит файрвол и VPN-шлюз, а внутри сервисы общаются друг с другом почти свободно: один сегмент, общие учётки, плоская сеть. Украденной VPN-сессии подрядчика хватает, чтобы за одну сессию пройти от файловой шары до гипервизора: SMB-шары, базы данных, контроллер домена, бэкапы. Несколько громких инцидентов последних 2–3 лет в крупных торговых сетях и логистике развивались именно по этой схеме - вход через подрядчика и горизонтальное движение по плоской внутренней сети до критичных систем.
В Zero Trust та же сессия открывает доступ только к одному явно разрешённому сервису, а попытка пойти «вбок» к соседнему серверу блокируется на уровне политики и попадает в журналы. Zero Trust - не коробочный продукт, а набор практик: IAM, сегментация, контроль устройств, журналирование, ZTNA вместо VPN. Вендор, обещающий «Zero Trust в коробке», продаёт компонент, а не архитектуру.
С каких шагов начинать
Когда модель понятна, остаётся определить, с чего начать практически. Закупка железа и подписка на новую платформу - не первый шаг. Сначала видимость и правила, потом - продукты под них. Иначе любая лицензия вешается в воздух.
Инвентаризация активов и сервисов
Первый шаг - ответ на простой вопрос: кто, к чему и зачем имеет доступ. Без актуального реестра серверов, сервисов и матрицы доступов любая попытка построить Zero Trust остаётся декларацией. Политики не на что опереть: непонятно, какие потоки east-west считать легитимными, а какие - аномалией.
Типичная картина: десятки унаследованных сервисов без явного владельца, активные учётки уволенных сотрудников, сервисные учётки с правами «на всё», доступы подрядчиков, оформленные «временно» и живущие третий год.
Без разбора этой картины инвестиции в NGFW, SIEM или ZTNA уходят в пустую. Нулевое доверие безопасность приносит тогда, когда у политики есть точные объекты: конкретный сервис, группа пользователей, устройство.
Сегментация сети и привилегий
Второй шаг - два параллельных движения. Микросегментация сети предполагает разделение инфраструктуры на изолированные сегменты под группы сервисов: фронт, бэк, базы данных, инфраструктурные сервисы, сегмент управления, сегменты подрядчиков. Между сегментами прописываются явные правила east-west трафика: фронт ходит к бэку только по нужным портам, бэк к базе с определённых адресов, всё остальное запрещено и журналируется.
Параллельно вводится принцип минимальных привилегий: учётная запись получает только те права, которые нужны для конкретной задачи. MFA для всех административных учёток - на серверах, в гипервизоре, в системах управления конфигурацией, в облачной консоли. MFA нужен и для машинных учёток: роль второго фактора играют сертификаты, аппаратные токены и секрет-менеджеры с короткоживущими токенами вместо захардкоденных паролей в скриптах.
Первые 90 дней реалистичного проекта - это видимость (реестр активов и доступов) и базовая сегментация плюс MFA для администраторов. Без этих двух шагов закупка любых коробок даёт нулевой эффект.
Zero Trust в виртуальной среде
В виртуализации принципы Zero Trust применяют к трафику между виртуальными машинами и к самому гипервизору, потому что компрометация консоли управления дает доступ сразу ко всем машинам кластера.
- Микросегментация на уровне гипервизора. Правила фильтрации между виртуальными машинами задают средствами платформы виртуализации или распределенного межсетевого экрана, который работает на каждом хосте. Тогда трафик east-west между машинами на одном хосте тоже проходит через политику, а не идет в обход физического файрвола.
- Отдельная сеть управления. Интерфейсы управления гипервизорами, BMC серверов (iDRAC, iLO, IPMI), системы хранения и бэкап-серверы выносят в изолированный сегмент, недоступный из пользовательских и серверных сетей.
- Доступ к консоли гипервизора только через bastion. Администраторы заходят в консоль управления через bastion-хост или PAM с двухфакторной аутентификацией и записью сессий, прямой доступ с рабочих станций закрывают.
Все эти меры опираются на базовые настройки защиты сервера на самих хостах: обновления, отключенные лишние сервисы и вход по ключам.
Технические компоненты Zero Trust
Когда инвентаризация прошла и базовая сегментация описана, на сцене остаются конкретные технические компоненты. Архитектура собирается из нескольких слоёв. IAM - единый источник правды о пользователях и их правах: Microsoft Entra ID (бывший Azure AD) для облачных и гибридных сценариев или локальный аналог для контуров без выхода в облако. Поверх IAM ставится PAM - система для управления привилегированными учётками с записью сессий, выдачей доступа на время и одноразовыми паролями для критичных систем.
На серверах разворачивается EDR или XDR. EDR закрывает контур серверов и рабочих станций и подходит, когда задача - быстро покрыть весь парк хостов. XDR расширяет охват на сеть, почту и облачные сервисы и оправдан там, где SOC уже работает с корреляцией событий между источниками. На уровне сети - NGFW и микросегментация. VMware NSX и Cisco ACI берут там, где гипервизор и сетевая фабрика и так от этих вендоров: интеграция дешевле, политики ложатся на существующий контур. UserGate, Континент и ViPNet - выбор для регулируемых контуров с требованиями ФСТЭК и ФСБ или для проектов под сертифицированную криптографию.
Подбор аппаратной части под NGFW, SIEM-коллекторы и серверы EDR - отдельная инженерная задача: оборудование для информационной безопасности рассчитывается по объёму трафика, числу хостов и требованиям к хранению журналов.
Журналы - отдельный слой, без которого Zero Trust остаётся на бумаге. SIEM собирает события с серверов, сетевого оборудования, IAM и EDR, коррелирует их и поднимает алерты. Если SIEM нет или его никто не разбирает, факт нарушения политики никто не увидит.
Для контуров, где западные продукты недоступны или не допускаются требованиями регуляторов, слои архитектуры закрывают российскими решениями:
| Слой | Задача | Российские примеры |
|---|---|---|
| Каталог и IAM | Единый источник учетных записей, групп и прав | ALD Pro |
| PAM | Контроль привилегированного доступа, запись сессий, выдача доступа на время | Indeed PAM, СКДПУ НТ |
| NGFW и ZTNA | Фильтрация трафика между сегментами, доступ к отдельным приложениям вместо VPN | UserGate, Континент, ViPNet |
| SIEM | Сбор и корреляция журналов, алерты о нарушениях политик | MaxPatrol SIEM, Kaspersky KUMA, RuSIEM |
Часть западных продуктов, упомянутых выше, включая Microsoft Entra ID, Cisco Duo и Palo Alto Prisma Access, в России недоступна или работает с ограничениями, поэтому их используют только в уже развернутых инсталляциях. Как сравнить SIEM-системы по модели поставки и нагрузке на серверы, показывает разбор того, как выбрать SIEM-систему.
ZTNA приходит на смену корпоративному VPN. Вместо «подключился к сети - попал везде» пользователь получает доступ к конкретным приложениям после проверки личности и состояния устройства. По классу решения разнятся: Cisco Duo закрывает компактный сценарий - проверка личности, MFA и условный доступ к набору приложений. Palo Alto Prisma Access - корпоративная SASE-платформа с собственной сетью присутствия, L7-инспекцией и интеграцией с CASB, разумна для распределённых офисов с десятками точек. ZTNA - один компонент Zero Trust, отвечающий за доступ к приложениям, а не вся архитектура целиком.
Стоимость и этапы внедрения
От набора компонентов переходим к календарю. 12 месяцев - реалистичный горизонт для средней инфраструктуры на 50–200 серверов при условии, что у проекта есть владелец со стороны ИТ-директора и выделенная команда. Без владельца проект распадается на разрозненные закупки.
Дорожная карта на 12 месяцев
1. Первые 3 месяца - инвентаризация активов и сервисов, аудит сервисных учёток, MFA для всех административных аккаунтов, развёртывание сбора журналов и базового SIEM. На этом этапе компания закрывает самые громкие риски, не покупая дорогих лицензий.
2. Месяцы 4–6 - пилот микросегментации на одном контуре (например, бухгалтерия и 1С), запуск PAM для привилегированных учёток, внедрение ZTNA для одной группы пользователей: подрядчиков или удалённых администраторов. Пилот даёт измеримые метрики и понимание реальных трудозатрат.
3. Месяцы 7–12 - масштабирование на остальные контуры, подключение EDR на продуктивные серверы, расширение правил микросегментации, перевод оставшихся пользователей с VPN на ZTNA.
Бюджет делится на две части. CapEx - закупка железа: пара NGFW в отказоустойчивой связке, SIEM-коллекторы, узлы хранения журналов под законодательные сроки. OpEx - годовые лицензии на IAM, EDR, PAM и ZTNA (большая часть продаётся по подписке на пользователя или сервер в год) и часы интегратора с собственной командой на сопровождение. На горизонте 3 лет в контуре 50–200 серверов OpEx обычно складывается в 2–3 раза больше CapEx: железо служит 5+ лет, а подписки оплачиваются ежегодно. Это полезно закладывать в финмодель сразу, иначе со второго года бюджет ИБ становится сюрпризом для финдиректора.
Типичные ошибки внедрения
Календарь и компоненты бесполезны, если повторять чужие промахи. Ниже - пять типичных ошибок, на которых проекты Zero Trust буксуют чаще всего.
1. Воспринимать Zero Trust как «купить продукт X». Такого продукта не существует. Любой вендор закрывает один или два слоя архитектуры: IAM, ZTNA, NGFW, SIEM. Решение «под ключ» означает лишь то, что компоненты вендора лучше интегрированы между собой.
2. Пропустить инвентаризацию и сразу перейти к сегментации. Без понимания легитимных потоков east-west правила пишутся «по интуиции», ломают сервисы и потом массово ослабляются обратно.
3. MFA только для людей. Сервисные учётки с захардкоденными паролями в скриптах остаются удобным входом для атакующего. Машинные учётки тоже должны жить через секрет-менеджер, сертификаты и короткоживущие токены.
4. Нет плана по legacy. АБС, ERP двадцатилетней давности, промышленное ПО часто не поддерживают современную аутентификацию. Нужны компенсирующие меры: изоляция в отдельный сегмент, доступ через jump-хост с PAM, усиленное журналирование.
5. Считать, что ZTNA = Zero Trust. Нулевое доверие безопасность не сводится к одному компоненту: остаются серверы, базы, гипервизор, восточный трафик. ZTNA отвечает только за доступ пользователей к приложениям и не более того.
Часто задаваемые вопросы
Что такое Zero Trust простыми словами?
Это подход, при котором сеть не считается безопасной сама по себе: каждый запрос к серверу или приложению проверяют заново по тому, кто его делает, с какого устройства и к чему обращается. Доступ выдают только к нужному сервису и только с минимальными правами.
Чем Zero Trust отличается от VPN?
VPN проверяет пользователя один раз на входе и затем пускает его во внутреннюю сеть целиком. В модели Zero Trust доступ через ZTNA открывается только к конкретным разрешенным приложениям, а попытка обратиться к соседним серверам блокируется политикой и попадает в журналы.
ZTNA и Zero Trust — одно и то же?
Нет. ZTNA отвечает только за доступ пользователей к приложениям, а Zero Trust охватывает всю архитектуру: учетные записи и права, сегментацию сети, контроль устройств, журналирование, защиту серверов и гипервизоров.
Сколько стоит внедрение Zero Trust?
Бюджет складывается из CapEx на железо (NGFW, SIEM-коллекторы, хранилище журналов) и OpEx на подписки IAM, EDR, PAM и ZTNA и работу команды. Для инфраструктуры на 50–200 серверов реалистичный горизонт проекта — 12 месяцев, а на трехлетнем горизонте OpEx обычно в 2–3 раза превышает CapEx.
Нужен ли Zero Trust небольшой компании?
Полная архитектура с PAM, ZTNA и SIEM небольшой компании обычно избыточна, но базовые принципы применимы при любом масштабе. Инвентаризация доступов, отдельные учетные записи администраторов, двухфакторная аутентификация в корпоративной среде для администраторов и удаленного входа, а также отдельный сегмент управления закрывают основные риски без больших затрат.
С чего начать переход
Готовность компании к переходу на Zero Trust определяется тремя вещами одновременно: должен быть владелец проекта со стороны ИТ-директора или CISO, выделен бюджет на горизонт 12 месяцев, а не на квартал, и команда готова не только собирать события в SIEM, но и реагировать на алерты. Если хотя бы один из этих пунктов под вопросом, имеет смысл начать с независимой оценки - аудит безопасности инфраструктуры покажет реальную карту рисков и последовательность шагов под бюджет конкретной компании.