Zero Trust: почему мы все делаем это неправильно
За последние три года я и мои знакомые из сферы участвовали во внедрении Zero Trust в 12 компаниях разного масштаба. Пришли к неутешительному выводу: 90% организаций реализуют Zero Trust как более сложную версию VPN. Мы подменяем философию технологиями, забывая о фундаментальных принципах.
Миф об «упрощенной безопасности»
Многие верят, что Zero Trust — это просто замена VPN на ZTNA. На практике мы получаем распределенный VPN с более сложной аутентификацией. Настоящий Zero Trust требует пересмотра архитектуры приложений, а не просто установки шлюза доступа.
Я видел implementations, где:
Микросервисы общаются через сервис‑меш внутри доверенной сети
Базы данных остаются в общем сегменте
Аутентификация сводится к проверке сертификатов
Это не Zero Trust. Это периметровая безопасность с дополнительными факторами аутентификации.
Проблема наследия
Legacy‑системы — главное препятствие для настоящего Zero Trust. Когда 70% бизнес‑логики работает на AS400 и Windows Server 2008, о сегментации на уровне приложений говорить не приходится. Мы создаем костыли: прокси, врапперы, шлюзы — все, что угодно, лишь бы не переписывать системы.
Данные против политик
Самый болезненный момент — управление данными. Zero Trust предполагает, что мы знаем:
Какие данные где хранятся
Кто имеет к ним доступ
Как они перемещаются
В реальности у 80% компаний нет даже базовой классификации данных. Мы строим сложные политики доступа, не понимая, что именно защищаем.
Излюбленный человеческий фактор 2.0))))
Zero Trust не решает проблему социальной инженерии. Фишинг эволюционировал вместе с технологиями. Я наблюдал случаи, когда злоумышленники:
Обходили MFA через усталость пользователя (push‑уведомления)
Использовали легитимные OAuth‑приложения
Крали сессии с доверенных устройств
Технологические разрывы
Рынок инструментов Zero Trust фрагментирован. Мы имеем:
5+ стандартов для device attestation
3 конкурирующих протокола для ZTNA
Десятки несовместимых решений для микросегментации
Интеграция превращается в кошмар: Palo Alto Prisma, CrowdStrike Identity, Cisco Duo — каждый тянет одеяло на себя.
Культурный шок
Самое сложное в Zero Trust — изменить мышление команды. Админы привыкли к «доверенным сетям». Разработчики не хотят переписывать auth‑логику. Руководство требует быстрых результатов.
Я видел проекты, где после года внедрения:
Сотрудники использовали корпоративные устройства для личных нужд
Админы создавали бэкдоры для «удобства поддержки»
Руководители требовали исключений из политик
Что в сухом остатке?
Zero Trust — это не продукт и не проект. Это бесконечный процесс переосмысления безопасности. Успешные implementations, которые я наблюдал, имели общие черты:
Поэтапный переход (3-5 лет)
Глубокая модернизация инфраструктуры
Изменение процессов, а не только технологий
Постоянное обучение и тестирование
Мы должны признать: не каждой компании нужен «полный» Zero Trust. Иногда достаточно микросегментации критических активов и строгого контроля доступа. Гонка за модным термином не должна подменять собой здравый смысл.
Сегодня я скорее рекомендую «Zero Trust mindset», чем конкретные технологии. Начинать стоит с инвентаризации активов, классификации данных и построения карты потоков. Технологии — вторичны.
Пора перестать измерять успех количеством подключенных ZTNA‑шлюзов и начать оценивать реальное снижение рисков. Иначе мы рискуем повторить судьбу «облачной трансформации» — потратить миллионы, не получив существенного улучшени�� безопасности.