«Когда в системе сбой, все смотрят на тебя. Угол обзора сужается до одного рабочего места — кто из нас нажал не туда, перекинул лишний файл, открыл подозрительное письмо? Вопрос не в том, виноват ли сотрудник. Вопрос в том, почему компания не может доказать, что он не виноват. Zero Trust, это не технология контроля, это инфраструктура доказательств. Я рассматриваю её как способ перевести безопасность из туманной зоны подозрений в чёткую плоскость логов, контекста и протоколов. Здесь никто не должен оправдываться за то, что не делал. Потому что система уже знает — что, когда и при каких условиях произошло.»
Почему «виноват сотрудник», это провал безопасности
Инцидент в ИТ — как преступление в закрытой комнате. Охрана снаружи — в целости, следов взлома нет. А внутри — цифровой беспорядок. Данные ушли. Репутация под ударом. Руководство требует ответов. Первой сходит на ум фраза: «Виноват сотрудник». Но кто именно? Дать имя — значит убрать давление. Однако за этим утверждением чаще всего стоит отсутствие инструментов — не желание найти истину, а неспособность её увидеть.
Классическая защита строится вокруг периметра: межсетевой экран, VPN, фильтрация трафика. Она работает, пока кто-то не попал внутрь. А стоит одному соединению пройти авторизацию — сеть считает его легитимным. Что происходит дальше, остаётся в тени. Нет аудита на уровне отдельных действий, нет контекстных проверок. Система фиксирует «вход», но не анализирует «что делается дальше». Следовательно, при инциденте нет возможности точно определить источник события. Остаются только догадки. А догадки требуют жертвы.
Говорить «виноват сотрудник» — значит признать, что у компании нет механизма точной атрибуции. Нет возможности установить, был ли это легитимный доступ, скомпрометированный аккаунт или злоумышленник, использующий доверие системы. Это не ошибка человека. Это сбой на уровне архитектуры — и он интерпретируется как моральный промах. Это управленческий рефлекс: переложить ответственность на слабое звено, потому что сильные звенья не готовы к детальному анализу.
Последствие такого подхода — токсичная культура опасения. Люди начинают скрывать мелкие инциденты: кликнули на письмо, уронили токен, подключились с личного устройства. Они знают: реакция не будет направленной на исправление процесса, а ударит по личной репутации. Чем больше ошибок скрывается, тем больше рисков накапливается. А когда взрыв прогремит — искать будут не уязвимость в логике доступа, а имя на табличке.
Как устроена ловушка человеческого фактора в старых системах
Старый подход к доступу работает по принципу «один раз вошёл — значит, можно». Подключение к корпоративной сети через виртуальную сеть считается достаточной проверкой. После этого пользователь получает условное право на большинство ресурсов. Это как дать ключ от главного замка и разрешить ходить по всему дому. Если кто-то воспользуется этим правом не по назначению — система не отличит добропорядочного сотрудника от злоумышленника, действующего под его именем. Оба прошли аутентификацию. А дальше — всё на совести пользователя.
Отсутствие сегментации — ключевая ошибка. В большинстве устаревших сетей нет чётких границ между отделами. Бухгалтер может технически добраться до сервера с разработкой, даже если это ему не нужно. Программист — к HR-системе. Это не значит, что они это делают. Но система не блокирует — значит, может быть и не запрещено. Такая архитектура создаёт пространство для незамеченного движения. И если утечка происходит, следователь не может отследить, был ли это легальный доступ с разрешения или проникновение под легальным обликом. Результат: логичнее всего обвинить владельца учётки.
Системы не умеют задавать вопросы. Они не спрашивают: «Почему пользователь, который никогда не работал с базой резюме, в 2:47 ночи запрашивает 500 записей?» Они не реагируют на контраст между привычным поведением и текущим запросом. Нет анализа геолокации, времени, типа устройства. Нет проверки, включен ли экран блокировкой, установлен ли последний патч ОС. Всё это остаётся за кадром. А значит, при любом отклонении система будет видеть только идентификатор — имя, имя, имя. И искать ответ там, где его быть не может.
Zero Trust: протокол вместо подозрений
Zero Trust я воспринимаю как архитектурный сдвиг от «доверяй, но проверяй» к «не доверяй никогда, проверяй всегда». Это не фраза для презентаций. Это изменение базовой логики: никакое соединение, никакой доступ, никакой запрос к ресурсу не считаются безопасными по умолчанию. Каждый запрос, это транзакция, требующая полной проверки. Не важен предыдущий опыт пользователя. Не имеет значения, как давно он в офисе. Каждое соединение проходит три этапа: аутентификация, авторизация, шифрование. И каждый раз с нуля.
Основное преимущество — полная атрибуция. Я знаю не просто «кто залогинился», а «что именно было сделано, откуда, зачем и при каких условиях». Каждый доступ к файлу, базе данных или интерфейсу управления логируется с детализацией: IP-адрес, устройство, время, продолжительность сессии, тип запроса, уровень риска. Это не агрегированные метрики. Это точечные записи, привязанные к конкретному событию. Если система зафиксировала скачивание клиентской базы — я могу за три минуты понять, был ли это штатный процесс, техническая задача или незапланированная активность.
Такой подход исключает обвинительную повестку. Расследование инцидента больше не начинается со встречи, где все избегают зрительного контакта. Оно стартует с запроса к логам. Система выдаст цепочку событий: пользователь А запрашивал ресурс B через браузер C с устройства D, которое не прошло проверку на целостность ОС. Ни одного пробела для домыслов. Только факты. Я не должен гадать, кто нарушил процедуру. Я вижу, что процедура была нарушена, и знаю где — без привязки к личности.
Микросервисы доступа и политики как код
В Zero Trust доступ разбивается на микросессии. Вместо постоянного подключения ко всей сети — временный, целевой, контролируемый доступ к конкретному приложению. Например, бухгалтер получает разрешение на вход в систему учёта на 90 минут. По истечении срока сессия закрывается. Чтобы повторить — нужна новая проверка. Это исключает возможность долгосрочного использования скомпрометированной сессии. Даже если злоумышленник перехватил токен, срок его жизни ограничен — максимум несколько часов.
Политики доступа больше не хранятся в мозгах администратора или в разрозненных ACL-списках. Они формулируются как код. Это позволяет описать правила в унифицированном виде, версионировать их, проверять на противоречия и автоматически применять. Такой подход повышает точность и ускоряет реакцию на изменения. Например, политика «доступ к платёжному шлюзу разрешён только с устройств, подключённых к домену и прошедших сканирование на вредносное ПО» может быть задана в YAML-файле и интегрирована в CI/CD-пайплайн.
Возможны адаптивные сценарии. В день выплаты зарплаты система автоматически повышает уровень контроля: добавляет требования к двухфакторной аутентификации, ограничивает количество сессий, включает дополнительную проверку стран происхождения запроса. После завершения процесса политика возвращается к базовому профилю. Такие механизмы делают безопасность гибкой — она не замораживает процессы, а работает в ритме бизнеса.
Что происходит при инциденте в системе Zero Trust
Представьте ситуацию: зафиксирована попытка экспорта конфиденциальных данных. В старой системе это запускает цепочку: кто последний работал с файлом? Кто имел на него доступ? Отправляем письмо с вопросом, возвращаемся с обвинениями. В Zero Trust всё иначе. У меня есть лог: «Пользователь X, сессия Y, IP-адрес Z, геолокация — Малайзия, время — 4:17, тип запроса — массовое скачивание, статус устройства — не зарегистрировано в MDM». Кроме того, токен был выдан в 3:59, что не соответствует типовому поведению. Два фактора: нестандартное время и неавторизованное устройство.
Система уже пометила запрос как высокий риск и заблокировала его на уровне шлюза. Но даже если бы действие было завершено — у меня есть полная цепочка: как был выдан токен, какие проверки прошёл пользователь, какие условия были нарушены. Я вижу, что аутентификация прошла по паролю и временному коду, но поведенческая аналитика отметила отклонение в скорости набора текста — ниже нормы на 30%. Это не доказательство нехорошего человека. Это доказательство аномальной сессии.
Результат расследования — не «бухгалтер Петров выкрал данные», а «учётная запись Петрова использовалась для попытки скачивания в подозрительных условиях. Устройство не зарегистрировано. Вероятность компрометации — высокая. Причина — возможная утечка одноразового кода через фишинг». Такой отчёт не требует внутреннего дознания. Он даёт ясность. Работа над инцидентом переходит в плоскость устранения уязвимости: улучшение фильтрации писем, внедрение push-уведомлений вместо SMS, усиление проверки устройств.
Реальные улики: логи, контекст и аномалии
Zero Trust формирует не просто логи — он генерирует улики. Каждое событие сопровождается набором атрибутов, которые можно использовать как доказательную базу.
- Время жизни аутентификационного токена — 15 минут. Использование вне времени действия сигнализирует о подделке.
- Геолокация устройства — Берлин, хотя пользователь работает в Новосибирске. Сессия сразу блокируется.
- Состояние устройства — не установлен последний патч безопасности. Даже при наличии корректного пароля доступ отклоняется.
- Поведенческая аналитика — пользователь, который обычно делает 40 кликов в минуту, внезапно выполняет 220. Это может быть указанием на автоматизированное действие.
Система может выдать чёткое сообщение: «Доступ к CRM-системе предоставлен сотруднику из отдела поддержки для просмотра тикета №11845. Сессия прошла по сертификату, но с устройства, не включённого в систему управления мобильностью. Действие зафиксировано, но не прервано — уровень риска средний. Рекомендовано провести обучение». Это не обвинение. Это уведомление с контекстом.
Контекст — решающий фактор. Один и тот же пользователь запрашивает доступ к тестовому серверу. В рабочее время, с корпоративного ноутбука, через Wi-Fi офиса — разрешён. В 5 утра, с личного телефона, через сеть кафе в Баку — блокирован, инициируется оповещение SOC. Контекст позволяет отличать норму от угрозы без оценки характера сотрудника.
Как внедрять Zero Trust, чтобы не превратить офис в цифровую тюрьму
Начинать с тотального охвата — ошибка. Я видел проекты, где Zero Trust внедряли по принципу «сжать всё и посмотреть, кто остался». Результат — массовый отказ от использования сервисов, рост числа запросов в службу поддержки, протесты. Люди не против безопасности. Они против абсурдных блокировок, мешающих работать.
Мой подход — стратегия критической защиты. В первую очередь применяю Zero Trust к тем системам, где последствия утечки максимальны: платёжные шлюзы, базы персональных данных, R&D-серверы, системы управления персоналом. Для остальных ресурсов — постепенное внедрение. Я выбираю не по уровню доступа, а по уровню ценности данных и восприимчивости к компрометации. Например, доступ к внутреннему порталу с новостями компании не требует агрессивных политик. А вот доступ к API-ключам продукта — требует.
Важный этап — коммуникация. Я объясняю командам: Zero Trust — не про контроль, а про защиту. Он нужен не чтобы следить, а чтобы вы не стали подозреваемым в случае инцидента. Когда доступ к приложению требует второй фактор, это не потому, что вам не доверяют. Это потому, что злоумышленник не должен получить доступ, даже если перехватит ваш пароль. Я подчёркиваю: система защищает вас от ложных обвинений, а не проверяет вашу лояльность.
Политики делаю адаптивными. Пользователь в офисе, под корпоративной сетью, на управляемом устройстве — проходит минимум проверок. Тот же человек, подключающийся из отеля в другой стране — получает дополнительные уровни, включая биометрию и одноразовые сессии. Удобство и безопасность — не противоположности. Они уравновешиваются уровнем риска ситуации.
Технологии-помощники: от SASE до биометрии поведения
SASE, это практическая платформа для реализации Zero Trust. Вместо того чтобы прокидывать трафик пользователя через корпоративный шлюз, я направляю его в облачный Secure Access Service Edge. Там в режиме реального времени проверяются политики, анализируется устройство, проверяется репутация IP-адреса, блокируются вредносные загрузки. Пользователь получает доступ напрямую к приложению, не проходя через ЦОД. Это снижает задержки, упрощает масштабирование и усиливает контроль. Я вижу каждый запрос — кто, к какому сервису, откуда, с каким риском.
Биометрия поведения — один из самых недооценённых элементов. Система обучается на образце: как вы двигаете мышью, с какой скоростью печатаете, как переключаетесь между окнами. При входе она сравнивает поведение с эталоном. Если резко меняется стиль — например, текст вводится ровным темпом, без привычных пауз, — система помечает сессию как подозрительную. Это не зависит от паролей. Это анализ живого действия. Я видел случаи, когда такой механизм обнаруживал доступ через удалённый рабочий стол — пользователь «работал», но явно не сам.
PAM-системы (Privileged Access Management) — обязательный компонент. Администраторы имеют повышенные права. Поэтому каждая их сессия должна быть строго защищена. Я настраиваю режим «одноразового пароля» для входа, фиксирую полную запись экрана и все введённые команды. Если что-то пойдёт не так — у меня есть видео сессии. Я вижу, что и в каком порядке делал оператор. Это не для увольнения. Это для анализа. Чтобы понять, была ли ошибка в команде, или это часть атаки.
Итог: безопасность как культура объективности
Zero Trust, это не просто набор технологий. Это смена парадигмы. От культуры подозрений — к культуре доказательств. Я перестаю искать виноватого, потому что система уже знает, где и что произошло. Сотрудник больше не рассматривается как источник риска. Он становится участником защищённого процесса — с фиксированной логикой, контекстной проверкой и прозрачным следом.
Когда в системе сбой — не нужно оглядываться по сторонам. Я знаю, что произошло, потому что каждый шаг был проверен и залогирован. Никто не должен доказывать свою невиновность. Она подтверждена самой архитектурой. Это не только защита данных. Это защита репутации каждого сотрудника. И в долгосрочной перспективе — защита доверия внутри компании.
Когда есть полный протокол, обвинения перестают быть необходимыми.