«Zero Trust заставляет систему сомневаться в каждом запросе, даже правильном. Это превращает украденные логины в бесполезный набор символов, потому что теперь доступ зависит от контекста. Мы не ищем злоумышленника внутри сети — мы строим систему, в которой у него просто нет точек для атаки» .
Почему пароля и VPN уже недостаточно для защиты данных
Устаревшая модель безопасности строилась на идее крепости с толстыми стенами и доверенной внутренней территорией. VPN и внутренняя сеть были этими стенами. Однако современные атаки редко взламывают стены — они просто подделывают пропуск или используют легальные входы. Компрометация рядовой учётной записи сотрудника стала стандартным вектором атаки. Через фишинговые письма, поддельные формы обновления профиля или звонки от имени службы поддержки злоумышленники получают логин и пароль, а иногда и одноразовые коды.
После этого злоумышленник оказывается внутри периметра. Традиционный VPN, выданный на основе этой же аутентификации, предоставляет ему широкий доступ для горизонтального перемещения по сети. Он может сканировать серверы, подключаться к файловым хранилищам, искать уязвимые системы. Система безопасности видит лишь легитимный трафик от «своего» пользователя внутри доверенной зоны. Не существует аномального сетевого шума или атаки на брандмауэр — есть только последовательность действий, ведущих к критичным данным.
Инциденты, связанные с социальной инженерией, показывают, что проблема не в технологиях, а в логике. Система, доверяющая факту входа, слепа к обстоятельствам этого входа. Звонок из кол-центра, в ходе которого сотрудник под давлением диктует временный код из приложения,, это легитимная сессия с точки зрения стандартных средств защиты.
Как Zero Trust превращает каждый запрос в отдельное расследование
Zero Trust смещает фокус с периметра сети на каждое отдельное действие с ресурсом. Доступ к финансовой отчетности, запрос к базе данных клиентов или авторизация в платёжном шлюзе — каждое из этих взаимодействий проходит независимую проверку. Решение о предоставлении доступа не принимается один раз при входе в сеть — оно пересчитывается непрерывно для каждой операции.
Для этого система формирует цифровой отпечаток каждой сессии. Она собирает и анализирует контекстные сигналы:
- Тип и модель устройства.
- Состояние операционной системы (версия, наличие обновлений).
- Версия и состояние браузера.
- IP-адрес и принадлежность к автономной системе (ASN) провайдера.
- Геолокация и время суток.
- История предыдущих действий пользователя.
На основе этих данных строится динамический профиль риска. Запрос оценивается не изолированно, а в сравнении с привычным паттерном поведения пользователя и политиками безопасности.
Рассмотрим реальный сценарий. Сотрудник обычно работает с корпоративного ноутбука из офиса в рабочие часы. В один момент система регистрирует попытку входа в систему электронного документооборота (СЭД) с неуправляемого смартфона через мобильную сеть в 4 часа утра. Даже если учётные данные (логин, пароль, одноразовый код) введены верно, контекст запроса вызывает подозрение. Система Zero Trust не просто разрешит доступ — она либо полностью его заблокирует, либо потребует прохождения дополнительного, более строгого фактора аутентификации (например, подтверждения через доверенное физическое устройство, которого у злоумышленника нет).
Конкретный пример: как Zero Trust ломает схему работы кол-центра
Атака начинается стандартно: мошенник под видом IT-специалиста звонит сотруднику бухгалтерии. Используя отработанные методы социальной инженерии, он убеждает сотрудника продиктовать код из приложения двухфакторной аутентификации, якобы для «срочного обновления профиля». Сотрудник, не подозревая обмана, выполняет инструкцию.
Мошенник теперь обладает временным токеном и идентификатором сессии. Он пытается установить сессию с нового, неподконтрольного организации устройства. Вот что происходит в системе, построенной по принципам Zero Trust:
- Анализ контекста. Система проверяет цифровой отпечаток: IP принадлежит мобильному оператору из другого региона; устройство не зарегистрировано в системе управления (MDM, например, Intune); операционная система устарела; используется неподдерживаемая версия браузера.
- Оценка риска. Совокупность этих факторов резко повышает оценку риска сессии. Это не соответствует нормальному профилю работы сотрудника.
- Динамическое ужесточение политики. Вместо предоставления доступа система требует прохождения дополнительного фактора аутентификации, например, подтверждения через другое доверенное устройство (корпоративный телефон с приложением-аутентификатором). У мошенника такого устройства нет.
- Блокировка и реакция. Доступ блокируется. Одновременно система автоматически помечает учётную запись как потенциально скомпрометированную и переводит её в режим карантина: доступ ко всем критичным системам (платежи, СЭД, базы данных) временно приостанавливается до проверки администратором.
Даже в гипотетическом случае успешного обхода этого этапа, политики Zero Trust, основанные на принципах Just-In-Time (JIT) и Just-Enough-Access (JEA), сведут ущерб к минимуму. Доступ к банковским системам у бухгалтера предоставляется только на время выполнения конкретной операции и требует предварительного одобрения руководителя. Любое отклонение от типового сценария работы (например, попытка сформировать нехарактерный платёж или запросить выписку по неиспользуемому счету) немедленно блокируется и регистрируется в SIEM-системе как критическое событие.
Что нужно проверить в своей инфраструктуре перед внедрением Zero Trust
Прежде чем обсуждать технологии, необходимо заложить концептуальный фундамент. Попытка начать с покупки решений — самый верный путь к неудаче.
- Определите, что именно защищать. Составьте не просто список серверов, а карту бизнес-транзакций. Где рождаются финансовые отчёты? Через какие системы проходят платежи? Где обрабатываются персональные данные сотрудников и клиентов? Каждое такое пересечение данных и процессов, это граница для сегментации и применения политик Zero Trust.
- Проведите аудит прав доступа и IAM. Управление идентификацией и доступом (IAM) — ядро Zero Trust. Проанализируйте, кто и к каким системам имеет доступ сегодня. Часто обнаруживается, что права выданы по принципу «стандартного пакета» и не соответствуют реальным обязанностям сотрудников. Проверьте, поддерживают ли ваши ключевые приложения современные протоколы аутентификации (SAML, OAuth, OpenID Connect) для интеграции с единым центром идентификации.
- Оцените возможности существующих платформ. Вероятно, вы уже используете инструменты, которые можно сделать элементами Zero Trust. Conditional Access в Microsoft Entra, Access Context Manager в Google Workspace, политики на основе условий в AWS IAM, это готовые механизмы для оценки контекста. Задача не в замене всего, а в стратегической интеграции этих механизмов с помощью ZTNA-шлюзов (Zero Trust Network Access) и брокеров доступа.
- Спланируйте работу с legacy-системами. Устаревшие системы, которые невозможно напрямую интегрировать с современными провайдерами идентификации, становятся слабым звеном. Их следует вынести в изолированный сегмент сети. Доступ к ним должен быть строго проксирован и контролироваться через шлюз с контекстной проверкой, минимизируя риски при компрометации.
Типичные ошибки при внедрении и как их избежать
Ошибки на этапе внедрения могут дискредитировать саму идею Zero Trust в глазах сотрудников и руководства.
- Жёсткие политики, игнорирующие реальные бизнес-процессы. Блокировка всех входов из публичных сетей (отелей, вокзалов, коворкингов) парализует работу мобильных сотрудников. Политики должны быть гибкими и учитывать сценарии реальной работы, постепенно повышая требования к аутентификации для более рискованных контекстов.
- Попытка охватить всю инфраструктуру сразу. Zero Trust, это не проект с чётким сроком сдачи, а непрерывный процесс. Начните с пилотного внедрения для одного наиболее критичного бизнес-блока (например, финансового департамента). Отточите политики, получите обратную связь, адаптируйте подходы. Затем методично расширяйте зону покрытия.
- Чрезмерно громоздкие сценарии аутентификации. Требование использования физического токена для доступа к корпоративному мессенджеру приведёт к тому, что сотрудники начнут оставлять токены постоянно подключенными к компьютерам, сводя на нет всю безопасность. Необходимо искать баланс: для повседневных задач достаточно биометрии на управляемом устройстве, для критических операций — дополнительные строгие факторы.
- Игнорирование человеческого фактора и подготовки. Внедрение новых процедур доступа без разъяснения их цели вызывает сопротивление. Сотрудники должны понимать, что эти меры защищают не только компанию, но и их самих от последствий ошибок, навязанных мошенниками. Обучение и коммуникация — ключевая часть перехода.
Как измерить эффективность Zero Trust: не количество блокировок, а снижение воздействия
Эффективность подхода Zero Trust измеряется не в количестве заблокированных попыток входа, а в качественном изменении ландшафта безопасности.
- Сокращение «радиуса взрыва» при компрометации. Даже если злоумышленник получает доступ к учётной записи, его возможности по перемещению внутри инфраструктуры и доступу к данным строго ограничены. Это означает, что из сотен потенциальных целей он видит лишь единицы.
- Минимизация операционных последствий инцидента. Автоматический перевод подозрительной учётной записи в карантин, отзыв сессий и оповещение SOC позволяют реагировать на угрозы быстрее, снижая время на восстановление после инцидента.
- Оптимизация процессов управления доступом. Автоматизация выдачи прав на основе ролей и запросов сокращает время онбординга новых сотрудников и гарантирует мгновенный отзыв всех доступов при увольнении, устраняя риски, связанные с «забытыми» учётными записями.
- Сокращение поверхности атаки. Перевод большинства систем с простой парольной аутентификации на контекстную с многофакторной проверкой делает массовые атаки с использованием утекших баз паролей технически неэффективными.
Zero Trust, это не про установку нового программного обеспечения. Это про изменение архитектурного подхода к безопасности: от защиты периметра к непрерывной верификации каждого действия внутри системы. Это превращает попытку мошенничества из критической угрозы в управляемый инцидент с минимальными последствиями.