Zero Trust для серверной инфраструктуры: с чего начать

Подрядчик подключается по VPN с домашнего ноутбука и автоматически оказывается во внутренней сети рядом с боевыми серверами: его сессия видит файловые шары, базу 1С, контроллер домена и бэкап-сервер, потому что классический файрвол доверяет любому, кто прошёл проверку на входе.

На таком ландшафте - облака, удалёнка, BYOD у руководства, подрядчики с правами администратора на своих устройствах, модель «жёсткий периметр, мягкое нутро» перестаёт защищать. Подход 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 для администраторов. Без этих двух шагов закупка любых коробок даёт нулевой эффект.

Когда инвентаризация прошла и базовая сегментация описана, на сцене остаются конкретные технические компоненты. Архитектура собирается из нескольких слоёв. 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 нет или его никто не разбирает, факт нарушения политики никто не увидит.

ZTNA приходит на смену корпоративному VPN. Вместо «подключился к сети - попал везде» пользователь получает доступ к конкретным приложениям после проверки личности и состояния устройства. По классу решения разнятся: Cisco Duo закрывает компактный сценарий - проверка личности, MFA и условный доступ к набору приложений. Palo Alto Prisma Access - корпоративная SASE-платформа с собственной сетью присутствия, L7-инспекцией и интеграцией с CASB, разумна для распределённых офисов с десятками точек. ZTNA - один компонент Zero Trust, отвечающий за доступ к приложениям, а не вся архитектура целиком.

От набора компонентов переходим к календарю. 12 месяцев - реалистичный горизонт для средней инфраструктуры на 50–200 серверов при условии, что у проекта есть владелец со стороны ИТ-директора и выделенная команда. Без владельца проект распадается на разрозненные закупки.

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 определяется тремя вещами одновременно: должен быть владелец проекта со стороны ИТ-директора или CISO, выделен бюджет на горизонт 12 месяцев, а не на квартал, и команда готова не только собирать события в SIEM, но и реагировать на алерты. Если хотя бы один из этих пунктов под вопросом, имеет смысл начать с независимой оценки - аудит безопасности инфраструктуры покажет реальную карту рисков и последовательность шагов под бюджет конкретной компании.