Корпоративная сеть больше не ограничивается офисом и собственным центром обработки данных. Сотрудники подключаются из дома и командировок, приложения размещаются в облаках, подрядчики получают доступ к внутренним системам, а данные распределяются между рабочими устройствами, SaaS-сервисами и внешними площадками.
Почему защиты периметра стало недостаточно
Классическая модель информационной безопасности строилась вокруг периметра. Внутри него находились сотрудники, серверы и доверенные устройства, снаружи — потенциальные нарушители. Такой подход был логичен, пока большая часть инфраструктуры располагалась в одном офисе или центре обработки данных.
Теперь граница между внутренней и внешней средой стала условной. Пользователь может находиться в офисе, но работать с заражённого ноутбука. Подрядчик может подключиться через разрешённый VPN, используя общую учётную запись. Злоумышленник может войти в систему с правильным паролем и похищенным токеном активной сессии.
Приложения и данные находятся в локальной сети, облаках, SaaS-сервисах, филиалах и на площадках партнёров.
Сотрудники подключаются из разных сетей и используют корпоративные, мобильные, а иногда и личные устройства.
Доступ получают внешние специалисты, партнёрские системы, API, роботы и сервисные учётные записи.
Для начала атаки нарушителю может быть достаточно похищенной учётной записи или действующей пользовательской сессии.
Если пользователь после входа автоматически считается доверенным, одна скомпрометированная учётная запись может открыть путь к нескольким сегментам инфраструктуры.
Что означает Zero Trust
Zero Trust часто переводят как «нулевое доверие», но речь не идёт о недоверии к сотрудникам или о постоянных запретах. Основной принцип проще: ни один запрос не должен считаться безопасным только потому, что он поступил из корпоративной сети или с известного устройства.
В NIST SP 800-207 Zero Trust описывается как переход от защиты статичного сетевого периметра к защите пользователей, устройств, приложений и данных. Сетевое расположение само по себе не становится основанием для доверия.
Решение учитывает личность, устройство, роль, ресурс, местоположение, время и риск текущей сессии.
Пользователь получает только доступ, необходимый для конкретной задачи, системы и периода работы.
Архитектура должна ограничивать последствия, даже если одна учётная запись или устройство уже захвачены.
Чем Zero Trust отличается от периметровой модели
| Периметровый подход | Zero Trust |
|---|---|
| Внутренняя сеть считается относительно доверенной. | Сетевое расположение не определяет уровень доверия. |
| После подключения пользователь получает широкий доступ. | Доступ предоставляется к конкретному ресурсу и операции. |
| Права часто действуют постоянно. | Права ограничиваются задачей, временем и контекстом. |
| VPN открывает путь в корпоративную сеть. | Каждый ресурс применяет собственную политику доступа. |
| Доступ пересматривается периодически. | Условия могут проверяться в течение всей сессии. |
| Основное внимание уделяется внешним атакам. | Учитываются внешние атаки, инсайдеры и заражённые устройства. |
Как принимается решение о доступе
В простой системе проверяется пара «логин — пароль». В архитектуре Zero Trust решение формируется из нескольких сигналов. Один и тот же пользователь может получить полный доступ, ограниченный режим, запрос дополнительного подтверждения или отказ — в зависимости от текущего контекста.
Кто обращается к ресурсу, подтверждена ли личность и нужны ли запрашиваемые права для должностной задачи.
Зарегистрировано ли устройство, установлены ли обновления, работает ли защита и нет ли признаков компрометации.
Соответствуют ли время, география, способ подключения и действия пользователя его обычному рабочему сценарию.
Чем чувствительнее данные или критичнее операция, тем строже проверка и уже набор разрешённых действий.
Открытие внутреннего справочника и изменение платёжных реквизитов не должны требовать одинакового уровня проверки.
Проверка не обязательно означает, что сотруднику придётся вводить код при каждом действии. Политики могут работать незаметно, пока устройство и поведение соответствуют установленным условиям. При росте риска система может запросить дополнительный фактор, сократить срок сессии, ограничить операции или полностью отозвать доступ.
Пример: доступ к ERP-системе
Рассмотрим компанию, в которой ERP используют склад, бухгалтерия, финансовая служба, руководители и внешние специалисты сопровождения. Со временем роли разрастаются: сотрудникам добавляют новые разрешения, но редко удаляют старые, а подрядчики пользуются общей учётной записью, созданной несколько лет назад.
Формальный контроль
- вход по паролю считается достаточной проверкой;
- VPN предоставляет широкий сетевой доступ;
- общий логин не позволяет определить исполнителя;
- накопленные права сохраняются бессрочно;
- нетипичная активность выявляется постфактум.
Доступ по Zero Trust
- каждый пользователь имеет собственную учётную запись;
- права разделены по задачам и подразделениям;
- подрядчик работает только в согласованное время;
- привилегии выдаются отдельно и на ограниченный срок;
- значимые действия регистрируются и анализируются.
В результате бухгалтер работает с финансовыми документами, сотрудник склада — с остатками и движением товаров, подрядчик — только с функциями сопровождения. Компрометация одной учётной записи не должна автоматически открывать все разделы ERP и связанные серверы.
Из каких компонентов складывается Zero Trust
Zero Trust нельзя купить в виде одного программного продукта. Это архитектурная модель, объединяющая несколько технических и организационных направлений.
Единый источник сведений о пользователях, ролях и статусе сотрудников; централизованные правила входа и завершения сессий.
Дополнительное подтверждение личности, разделение обычных и административных записей, временная выдача привилегий.
Учёт подключаемых устройств и проверка обновлений, шифрования, средств защиты и признаков компрометации.
Разделение пользовательских, серверных, облачных и технологических сред; контроль связей между системами.
Сопоставление журналов идентификации, устройств, приложений, сетевых средств и систем защиты.
Классификация ресурсов и применение разных условий доступа в зависимости от их критичности.
Модель зрелости CISA рассматривает пять взаимосвязанных направлений: идентификацию, устройства, сети, приложения и рабочие нагрузки, данные. Сквозными элементами выступают наблюдаемость, автоматизация и управление.
Аудит информационной безопасности помогает оценить управление доступом, сегментацию, технические меры, документы и процессы, а затем сформировать приоритетный план изменений.
Как внедрять Zero Trust поэтапно
Попытка одновременно изменить доступ ко всем системам создаёт высокий риск сбоев. Начинать следует не с выбора продукта, а с определения защищаемых бизнес-процессов.
Установить, нарушение каких процессов приведёт к значимому ущербу, и связать их с приложениями, данными и инфраструктурой.
Собрать пользовательские, административные и сервисные учётные записи, роли, привилегии и определить владельцев ресурсов.
Подключить централизованную аутентификацию, единые правила входа, MFA и управляемое завершение пользовательских сессий.
Удалить неактуальные права и выдавать новый доступ по заявке, после согласования, в минимальном объёме и на необходимый срок.
Определить минимальные требования к рабочим станциям и связать состояние устройства с условиями доступа к ресурсам.
Разделить сеть и приложения на контролируемые сегменты, заменить широкие разрешения явно описанными маршрутами.
Определить регистрируемые события, условия дополнительной проверки, правила отзыва прав и порядок анализа предупреждений.
Проверить подход на важном, но управляемом процессе, устранить влияние на работу пользователей и только затем расширять охват.
Что делать с устаревшими системами
Переход осложняется, если приложение не поддерживает современные протоколы аутентификации, детальные роли или полноценное журналирование. Отказаться от такой системы сразу обычно невозможно, поэтому применяются компенсирующие меры.
- разместить систему в отдельном сетевом сегменте;
- организовать доступ через контролируемый шлюз;
- выделить административные рабочие места;
- разделить обычные и привилегированные учётные записи;
- ограничить разрешённые маршруты и время подключения;
- вести запись административных сессий;
- ввести дополнительный контроль критичных операций;
- запретить прямое подключение из пользовательских сетей.
Эти меры не превращают устаревшее приложение в полноценный компонент Zero Trust, но уменьшают область возможного ущерба и позволяют включить его в общую модель контроля.
Если у компании нет актуальной карты систем, интеграций и сетевых связей, отправной точкой может стать аудит ИТ-инфраструктуры.
Почему проекты Zero Trust терпят неудачу
Одновременное изменение всех политик создаёт сбои, исключения и сопротивление пользователей.
Дополнительный фактор не исправляет избыточные права и не ограничивает перемещение после входа.
ZTNA, IAM и PAM решают отдельные задачи, но не определяют владельцев ресурсов и правила доступа.
Приложения, роботы и API также имеют идентификаторы, права, секреты и доступ к критичным данным.
Непрозрачные правила быстро накапливают исключения и становятся неподдерживаемыми.
Если изменения представлены только как усиление контроля, пользователи будут искать способы их обойти.
Сотрудникам важно объяснить практическую цель: защитить рабочие процессы, клиентские данные и доступность сервисов, не усложняя обычные действия без необходимости.
Как оценивать результат
Успех Zero Trust нельзя измерить количеством приобретённых продуктов. Полезнее отслеживать изменения в доступе, наблюдаемости и управляемости инфраструктуры.
- доля значимых систем с многофакторной аутентификацией;
- количество общих и бесхозных учётных записей;
- доля привилегий, выдаваемых на ограниченный срок;
- количество неактуальных прав;
- охват устройств централизованным контролем;
- число критичных систем без журналирования;
- количество лишних маршрутов между сегментами;
- время отзыва скомпрометированного доступа;
- доля действий, связанных с конкретным пользователем;
- время расследования инцидента;
- количество ложных блокировок;
- нагрузка изменений на службу поддержки.
Показатели безопасности необходимо сопоставлять с влиянием на бизнес. Если меры регулярно мешают выполнению рабочих операций, политики нужно корректировать, а не компенсировать постоянными исключениями.
Что получает бизнес
Компрометация одного пользователя не должна открывать нарушителю всю внутреннюю инфраструктуру.
Внешние специалисты получают персональный, ограниченный и отзываемый доступ к согласованным ресурсам.
Действия связываются с конкретными пользователями, устройствами, сессиями и системами.
Компания безопаснее подключает удалённых сотрудников, облачные приложения и внешние площадки.
Проверить, насколько существующая сегментация и разграничение доступа сдерживают нарушителя после первоначального проникновения, можно в рамках внутреннего тестирования на проникновение.
Краткий чек-лист перед внедрением
- Какие процессы и данные являются критичными?
- Какие системы участвуют в этих процессах?
- Кто владеет каждым ресурсом и согласует доступ?
- Какие пользователи, устройства и сервисы подключаются к ресурсу?
- Есть ли общие, неактуальные или бесхозные учётные записи?
- Как выдаются и отзываются привилегии?
- Можно ли проверить состояние подключаемого устройства?
- Какие маршруты доступны пользователю после входа?
- Регистрируются ли действия в критичных системах?
- Можно ли быстро завершить подозрительную сессию?
- Какие устаревшие приложения потребуют компенсирующих мер?
- По каким показателям будет оцениваться результат?
Если на часть вопросов нет ответа, начинать следует с обследования инфраструктуры и управления доступом, а не с закупки программного обеспечения.
Вывод
Zero Trust появился не как модный отказ от доверия, а как ответ на изменение корпоративной инфраструктуры. Пользователи, приложения и данные больше не находятся внутри одного контролируемого периметра, а легитимная учётная запись может принадлежать как сотруднику, так и злоумышленнику.
Эффективное внедрение начинается с критичных бизнес-процессов, инвентаризации ресурсов и наведения порядка в правах. Затем подключаются централизованная идентификация, контроль устройств, сегментация, ограничение привилегий и анализ событий.
Переход должен быть поэтапным: сначала защищаются наиболее значимые процессы, затем проверенные политики распространяются на остальную инфраструктуру.
Для субъектов критической информационной инфраструктуры Zero Trust может дополнять, но не заменяет выполнение обязательных требований. В этом случае отдельно проводится аудит и категорирование объектов КИИ по 187-ФЗ.
