Не доверяй никому — даже себе: как живёт Zero Trust

Zero Trust Network Access давно превратился из модного лозунга в обязательный пункт стратегий информационной безопасности. Но за яркой витриной часто скрывается довольно приземленная реальность: многофакторная аутентификация есть, VPN есть, а до настоящего подхода нулевого доверия все равно далеко. Чтобы понять, где заканчивается просто «безопасный доступ» и начинается ZTNA, нужно разложить его на несколько базовых компонентов.

В основе ZTNA лежит простая идея: не доверять ни пользователю, ни устройству только потому, что они уже «внутри сети» или однажды успешно прошли проверку. Каждый запрос должен подтверждаться, каждая сессия должна находиться под контролем, а уровень доступа должен меняться в зависимости от реального состояния безопасности. Рассмотрим три ключевых составляющих, без которых Zero Trust остается только красивой надписью в презентации.

Zero Trust Network Access как архитектура, а не продукт

Важно сразу зафиксировать отправную точку: ZTNA не является одной коробкой, одним облачным сервисом или галочкой в интерфейсе маршрутизатора. Это архитектурный подход к тому, как вы строите доступ к ресурсам, совмещая средства аутентификации, авторизации, мониторинга и реагирования.

Классическая модель «внутри все свои, снаружи чужие» опирается на периметр: попал в офис, вот тебе порт в коммутаторе, подключился к VPN, вот тебе полсети организации. Zero Trust ломает этот подход. Неважно, где находится пользователь и устройство: в офисе, дома, в гостинице. Доступ к каждому ресурсу определяется набором правил, которые учитывают личность пользователя, состояние рабочей станции, контекст сессии и текущие риски.

Поэтому любые разговоры в стиле «мы включили многофакторную аутентификацию, значит у нас Zero Trust» немного лукавы. Многофакторная аутентификация, сегментация сети, проверки безопасности устройства, сценарии реагирования центра мониторинга все это лишь части большого конструктора. Настоящий ZTNA начинается там, где эти элементы связаны в единую систему.

Компонент 1. Сильная аутентификация пользователя и устройства

Первая, самая очевидная составляющая Zero Trust Network Access это надежное установление того, «кто» и «что» подключается. Нужно удостовериться и в личности пользователя, и в том, что его устройство соответствует требованиям безопасности. Причем делать это как для физического подключения по проводной сети, так и для удаленного доступа.

В простейшем варианте это выглядит как комбинация факторов: что пользователь знает (пароль или пин-код), что у него есть (аппаратный токен, телефон с приложением для подтверждения входа), и, при необходимости, что он собой представляет (биометрия). К этому добавляется идентификация самого устройства его сетевые параметры, сертификаты, учетная запись в домене, результат проверок безопасности.

Аутентификация при физическом подключении

В локальной сети первичным рубежом часто выступает стандарт 802.1X на порту коммутатора. Устройство получает доступ не автоматически, а после проверки по одному или нескольким признакам: адресу оборудования, сертификату, учетной записи компьютера или пользователя в домене. До успешной аутентификации порт может находиться в гостьевом или карантинном состоянии.

Такая схема уже серьезно повышает уровень безопасности по сравнению с «голым» портом, куда можно воткнуть что угодно. Но для ZTNA важно не только то, что произошло в момент подключения, но и то, что будет дальше. Поэтому к первичной проверке обязательно добавляют оценку состояния устройства: актуальность операционной системы, наличие обновлений, включенный антивирус, рабочий межсетевой экран, установленный корпоративный клиент защиты.

На практике это реализуется через специальное клиентское приложение или встроенные средства операционной системы, которые передают на сервер доступа к сети набор параметров. Если устройство не соответствует политике, его можно отправить в ограниченную подсеть для обновления или вовсе заблокировать подключение.

Аутентификация при удаленном доступе

Для удаленных пользователей центральную роль играют службы удаленного доступа и виртуальные рабочие столы. Здесь стандартная комбинация выглядит так: логин и пароль плюс одноразовый код из SMS или приложения, либо подтверждение входа по push-уведомлению, либо аппаратный токен. На этом этапе проверяется личность пользователя, но не состояние его компьютера.

Чтобы приблизиться к Zero Trust, этого недостаточно. Клиентское приложение удаленного доступа должно выполнять проверку безопасности устройства перед установлением сессии: проверить версию операционной системы, наличие критических обновлений, работу антивируса, актуальность его баз, наличие обязательного корпоративного программного обеспечения, отсутствие признаков вредоносной активности. Только при успехе всех проверок пользователю выдается доступ хотя бы к какому-то набору ресурсов.

На этом этапе многие компании останавливаются. У них есть многофакторная аутентификация, есть проверка устройства при входе, и кажется, что все требования выполнены. Но для настоящего Zero Trust этого все еще мало, потому что состояние пользователя и устройства может поменяться уже после успешного подключения.

Компонент 2. Доступ по принципу наименьших привилегий

Вторая фундаментальная часть ZTNA доступ не «в сеть вообще», а только к тем ресурсам, которые нужны пользователю для работы. В идеале каждый сотрудник, подрядчик или сервисная учетная запись получают строго определенный набор разрешений, а не полный доступ ко всему, что находится за VPN или в офисном сегменте.

На сетевом уровне это означает продуманную сегментацию: разделение инфраструктуры на зоны, подсети и виртуальные сегменты с различными наборами правил. Пользователь не должен «видеть» базу данных, если ему нужна только веб-служба, и не должен иметь возможность подключиться по административным протоколам, если его задачи ограничиваются чтением отчетов.

Сегментация и подсети с нужными сетевыми доступами

Простейший вариант реализации принципа наименьших привилегий это помещение устройства в определенную подсеть в зависимости от его роли и результатов проверок. Например, рабочие станции сотрудников бухгалтерии оказываются в отдельном сегменте, который имеет доступ только к бухгалтерским системам, порталам отчетности и ограниченному набору общих сервисов.

Технически это может выглядеть как назначение VLAN на порту в зависимости от результатов аутентификации, выдача адреса из нужного пула, применение набора правил межсетевого экранирования. Для удаленного доступа роль такой «подсети» часто играет виртуальный сегмент в шлюзе ZTNA или в системе удаленных рабочих столов.

Более продвинутый вариант использует не только сетевую адресацию, но и идентификаторы пользователей и устройств. В этом случае решения контроля доступа умеют применять правила на основе групп в домене, меток устройств, информации из системы управления конфигурациями и других источников.

Индивидуальные списки доступа и политики

В рамках ZTNA индивидуальный список контроля доступа это не экзотика, а нормальный инструмент. Для каждого пользователя или группы задается явный набор ресурсов: какие приложения доступны, по каким протоколам, из каких локаций и в какое время. Избыточный доступ не поощряется, а считается риском.

Например, сотрудник службы поддержки может иметь доступ к административному интерфейсу клиентских сетевых устройств только через специализированный портал, с обязательной многофакторной аутентификацией и записью всех действий. Прямые подключения по SSH или RDP из произвольного места запрещены, даже если формально пользователь обладает высокими правами.

Такой подход не только сокращает поверхность атаки, но и упрощает расследование инцидентов. Когда каждый доступ проходит через контролируемую точку и получается в соответствии с явной политикой, легче ответить на вопрос, кто, когда и к чему подключался, и было ли это в рамках допустимого поведения.

Компонент 3. Непрерывное отслеживание состояния безопасности и динамический доступ

Третий элемент Zero Trust Network Access чаще всего остается за кадром. При этом именно он превращает архитектуру в действительно «нулевое доверие», а не в разовый контроль на входе. Речь идет о постоянной оценке состояния безопасности подключенных устройств и учетных записей, с возможностью автоматически повышать или понижать уровень доступа.

Суть проста: факт успешной аутентификации не дает пожизненный «абонемент на доверие». Устройство может устареть по обновлениям, на нем может появиться вредоносная активность, учетная запись может быть скомпрометирована, поведение пользователя может стать подозрительным. Система ZTNA должна уметь заметить это и отреагировать не через неделю, а в ходе текущей сессии.

Зачем нужна непрерывная проверка

Представим сотрудника, который утром подключился к сети с полностью исправной рабочей станции. В обед он открыл вредоносный вложенный файл, антивирус обнаружил подозрительную активность, а система обнаружения вторжений зафиксировала попытки сканирования внутреннего сегмента. Если инфраструктура доступа никак не реагирует, то у злоумышленника остается много времени для развития атаки.

В модели нулевого доверия такие события должны сразу изменить статус устройства и учетной записи. Например, рабочая станция переводится в карантинный сегмент, где доступ ограничен обновлением и диагностикой, часть критичных приложений становится недоступной, а для дальнейших действий от пользователя требуется повторная аутентификация с более строгими факторами. Все это должно происходить автоматически, без ручной работы администратора в каждый отдельный момент.

Непрерывная проверка нужна и по более «мирным» причинам. Допустим, устройство длительное время не получает обновления, антивирус давно не обновлял базы, шифрование диска выключено. По отдельности эти факты не означают атаку, но в сумме создают высокий риск. ZTNA должен уметь снижать доверие к таким устройствам, постепенно ограничивая их возможности до приведения в соответствие требованиям.

Как система узнает, что пора менять уровень доступа

Технически непрерывный контроль строится вокруг двух механизмов. Первый это клиентское приложение на устройстве, которое регулярно передает серверу доступа обновленную информацию о состоянии системы. Второй это интеграция с системами мониторинга и реагирования c центром мониторинга, системой управления событиями безопасности, средствами защиты рабочих станций, системами предотвращения утечек.

Источником сигнала может быть все, что связано с безопасностью: сработавшая защита, изменение уровня риска учетной записи, детект необычного поведения, блокировка вредоносного файла, обнаружение подозрительного процесса. Как только один из этих компонентов понимает, что ситуация изменилась, он отправляет команду инфраструктуре доступа пересмотреть уровень доверия.

Для проводной сети это может выглядеть как запрос на повторную проверку по протоколам управления доступом, перевод порта в другую политику или подсеть, назначение новых правил фильтрации. Для удаленного доступа шлюз ZTNA может принудительно разорвать сессию, потребовать повторной аутентификации с дополнительным фактором или полностью заблокировать доступ до выяснения обстоятельств.

Связка центра мониторинга, сценариев реагирования и сетевого оборудования

Чтобы это работало, нужен мост между миром мониторинга и миром сетевой инфраструктуры. Событие в системе защиты должно приводить не только к записи в журнал, но и к конкретным действиям на коммутаторах, маршрутизаторах, межсетевых экранах, шлюзах ZTNA. Эту роль выполняют сценарии автоматизированного реагирования.

Типовой пример: система обнаружения вторжений фиксирует подозрительный трафик с конкретной рабочей станции. Сценарий реагирования автоматически обращается к серверу контроля доступа и меняет политику для этой станции на карантинную. Порт коммутатора помещается в отдельный сегмент, сессии удаленного доступа обрываются, пользователю предлагается запустить проверку безопасности. Все это занимает секунды, а не десятки минут или часов.

В другом сценарии рост риска учетной записи например, множественные неудачные попытки входа из разных стран приводит к тому, что при следующем обращении к критичным ресурсам система требует дополнительный фактор или вовсе блокирует доступ. Так Zero Trust Network Access выходит за рамки простой проверки при входе и становится динамическим механизмом, постоянно подстраивающим уровень доверия.

Что само по себе еще не ZTNA

Из перечисленных компонентов видно, почему многие распространенные практики безопасности не дотягивают до настоящего Zero Trust, хотя выглядят впечатляюще в описании. Они важны и полезны, но являются только шагами на пути к ZTNA.

Несколько характерных примеров:

• Аутентификация по 802.1X с проверкой адреса оборудования, сертификата, учетной записи компьютера или пользователя. Это серьезный уровень базовой защиты проводной сети, но если после первоначального подключения устройство не пересматривается с точки зрения безопасности, это еще не Zero Trust.

• Удаленный доступ по VPN или к виртуальному рабочему столу с логином, паролем и одноразовым кодом по SMS, push-уведомлению или токену. Многофакторная аутентификация резко снижает риск компрометации пароля, но не говорит ничего о состоянии самого устройства и не меняет доступ динамически.

• Удаленный доступ с многофакторной аутентификацией и проверкой безопасности устройства только в момент подключения. Это уже очень продвинутый уровень, но если после установления сессии никакой повторной оценки не происходит, то полезные свойства Zero Trust реализованы лишь наполовину.

Все эти решения необходимы, но только в сочетании с принципом наименьших привилегий и непрерывным пересмотром уровня доступа они складываются в полноценный Zero Trust Network Access.

Типовая архитектура ZTNA в организации

Чтобы лучше представить, как выглядят все три компонента вместе, полезно мысленно собрать типовую архитектуру ZTNA. В ней обычно присутствуют несколько классов систем, каждая из которых закрывает свою часть задачи, а связи между ними обеспечивают непрерывность доверия.

В центре находится служба управления учетными записями и доступом: каталоги пользователей, системы единого входа, хранилище групп и ролей. Она отвечает за то, чтобы понятие «кто это» было единым для всех компонентов. К ней подключаются серверы контроля доступа к сети, шлюзы удаленного доступа и прикладные системы.

На границе сети работают средства контроля подключения: для офисной среды это решения управления доступом к сети, для удаленного доступа шлюзы ZTNA или системы виртуальных рабочих столов. Они принимают решения, пустить ли пользователя и его устройство, в какую подсеть или логический сегмент, какие правила фильтрации применить, какие приложения открыть.

За оценку состояния устройств отвечают системы управления конфигурациями, платформы защиты рабочих станций, средства управления мобильными устройствами. Они передают в инфраструктуру доступа сведения о версиях операционной системы, состоянии средств защиты, наличии критичных уязвимостей и других параметрах.

За непрерывный контроль и реагирование отвечает совокупность центра мониторинга, системы управления событиями безопасности и платформ автоматизированного реагирования. Именно они получают события от всех компонентов, определяют уровень риска и запускают сценарии, которые меняют уровень доступа на сетевом и прикладном уровне.

Для углубленного изучения концепции Zero Trust и типовых архитектур можно обратиться, например, к материалам Национального института стандартов и технологий США на сайте официального ресурса NIST, а также к аналитическим отчетам производителей средств контроля доступа и сегментации сети.

Практические шаги по внедрению Zero Trust Network Access

Внедрение ZTNA не делается одним большим проектом «с понедельника живем по-новому». Обычно это последовательная работа, которая начинается с базовых вещей и постепенно движется к более сложным сценариям. Главное не пытаться охватить все сразу, а выстраивать структуру шаг за шагом.

Один из возможных маршрутов внедрения может выглядеть так:

1. Провести инвентаризацию пользователей, устройств и критичных ресурсов. Без понимания того, кто и к чему должен получать доступ, любые политики будут либо чрезмерно жесткими, либо слишком размытыми.

2. Ввести или усилить многофакторную аутентификацию для удаленного доступа и критичных приложений. Это быстрый и сравнительно недорогой шаг, который резко снижает риск эксплуатации украденных паролей.

3. Настроить базовый контроль доступа к сети в офисе: аутентификация при подключении к проводной и беспроводной сети, разделение на сегменты по ролям и типам устройств, ограничение доступа «по умолчанию».

4. Внедрить проверки безопасности устройств при подключении: соответствие версии операционной системы, наличие обновлений и средств защиты, обязательные корпоративные приложения. На этом этапе уже можно реализовать карантинные сегменты и процедуры приведения устройств в соответствие.

5. Определить и внедрить политики наименьших привилегий для ключевых групп пользователей. Начать имеет смысл с наиболее чувствительных областей: финансовые системы, административные доступы, системы обработки персональных данных.

6. Настроить обмен событиями между средствами защиты, центром мониторинга и инфраструктурой доступа. Определить перечень событий, которые должны автоматически приводить к изменению уровня доступа, и реализовать соответствующие сценарии реагирования.

7. Постепенно расширять охват: подключать новые сегменты, группы пользователей, приложения, доводить политики до более детализированного уровня, уточнять критерии оценки риска и поведения.

На каждом шаге полезно использовать инструменты для визуализации сетевых связей и зависимостей приложений, чтобы понимать, какие потоки трафика на самом деле нужны для работы и какие можно безопасно отрезать. В качестве примера можно рассмотреть решения для анализа сетевого трафика и построения карт приложений, а также открытые утилиты для инвентаризации устройств и сервисов из репозиториев свободного программного обеспечения.

Итоги: из каких элементов складывается Zero Trust Network Access

Если собрать все части вместе, картина ZTNA выглядит уже не как абстрактный лозунг, а как конкретный набор требований к инфраструктуре доступа. Чтобы честно сказать, что у вас реализован подход нулевого доверия, в системе должны одновременно присутствовать три ключевых компонента.

Во-первых, это сильная аутентификация пользователя и устройства с учетом их реального состояния. Во-вторых, это доступ, выданный строго в соответствии с необходимым минимумом полномочий, с продуманной сегментацией и индивидуальными политиками. В-третьих, это непрерывное отслеживание состояния безопасности и динамическая корректировка уровня доступа в зависимости от того, что происходит с пользователем, устройством и окружающей средой.

Отдельно каждая из этих частей полезна и без упоминания Zero Trust, но только в связке они дают то, что обычно рисуют на схемах: постоянное подтверждение доверия, минимизацию ущерба от взлома, сокращение возможностей для горизонтального перемещения злоумышленника. В этом смысле ZTNA не столько про конкретные технологии, сколько про дисциплину: не верить «однажды проверенному» и всегда задавать вопрос «а не стало ли сегодня опаснее, чем было вчера».