Zero Trust для гибридного формата: вход утром - это не доверие на весь день

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

Гибрид ломает периметр иначе, чем удалёнка

Когда в 2020 году периметр рушился под ковидной удалёнкой, картина была простая: сотрудники ушли по домам, VPN перегрузился, домашние устройства оказались вне контроля. Про это был отдельный разбор принципов, и там вывод был про «все снаружи».

Гибрид 2026 года устроен сложнее. Один и тот же человек в понедельник сидит в офисе с корпоративным ноутбуком в доверенной сети, во вторник работает из дома через домашний Wi-Fi, в среду открывает почту с личного телефона из кафе. Это не «внутри» и не «снаружи», это плавающее состояние. Периметр умер не потому, что все ушли на удалёнку, а потому, что уровень доверия к устройству и каналу меняется от запроса к запросу у одного и того же пользователя.

Значит, и решение о доступе нельзя принимать один раз при входе.

Разовый вход - это не доверие на весь день

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

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

Что мы кладём в контекст

Контекст - это набор сигналов, по которым считается оценка риска запроса. У заказчика мы свели их к четырём группам.

Состояние устройства. Ключевой сигнал в гибриде. Корпоративный ноутбук под управлением MDM/UEM отдаёт своё состояние: включено ли шифрование диска, свежи ли обновления, работает ли агент EDR, не снята ли блокировка экрана. Личное устройство без управления такого не отдаёт - и это само по себе сигнал.

Идентичность и фактор. Кто это, каким способом подтвердился, как давно. Обращение к критичной системе может требовать более сильного фактора, чем чтение внутренней вики.

Сеть и география. Офисная сеть, домашняя, публичная - разный базовый уровень доверия. Резкая смена страны между запросами с интервалом в минуты - явная аномалия.

Поведение. Время суток, привычный набор систем, объём выгрузки. Не для того, чтобы следить за человеком, а чтобы поймать «учётка ведёт себя не как обычно».

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

Как это легло на существующие слои

Важно, что контекстный слой ничего не заменяет. Он становится «мозгом» над уже описанными «руками».

• ZTNA остаётся тем, кто физически пускает к приложению вместо VPN на весь сегмент - про пилот отечественных решений был отдельный пост.
• NAC отвечает за допуск устройства в проводную и беспроводную сеть - как он ложится на имеющуюся инфраструктуру, мы разбирали.
• Микросегментация ограничивает, куда можно дотянуться внутри - что работает на отечественных ОС, тоже писали.
• Привилегированный доступ живёт через JIT и PAM.

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

Что оказалось сложным

Честный список, как обычно.

Личные устройства без управления. Заставить сотрудника поставить UEM-агент на свой телефон - это конфликт, а не техническая задача. Мы не стали ломать людей: для неуправляемых устройств просто закрыли доступ к чувствительным данным и оставили безопасный минимум. Кому нужен полный доступ - выдаём корпоративное устройство.

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

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

Итого

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

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