44,7% взломов связаны с украденными учетными данными, а в критической инфраструктуре такой входной билет может обернуться не утечкой, а остановкой сервиса, производства или логистики. Zero Trust в критической инфраструктуре из модного лозунга окончательно превращается в скучную, но необходимую операционную практику: проверять нужно не только человека с логином, но и устройство, с которого он пришел.
Эту мысль подробно разбирает Specops Software в спонсорском материале, о котором сообщает BleepingComputer. Повод для разговора не новый, но по-прежнему болезненный: атака на Colonial Pipeline в мае 2021 года началась, как сообщалось, с неактивной VPN-учетки без многофакторной аутентификации. Дальше пострадали бизнес-системы, включая биллинг, а итогом стала остановка работы и сбои в поставках топлива на восточном побережье США. Пять лет спустя кейс по-прежнему используют как учебник по тому, как один слабый элемент в контуре доступа превращается в национальную проблему.
Логика атак на критическую инфраструктуру с тех пор не изменилась, зато выросли ставки. Такие организации интересны злоумышленникам не только из-за данных, но и из-за эффекта от сбоя: отключение, простой или нарушение поставок давят на компанию сильнее любого пресс-релиза про утечку. В материале отдельно подчеркивается риск со стороны групп, которых связывают с государствами: для них ценность представляет не только разовый взлом, но и длительное скрытое присутствие в сети. Иными словами, задача не обязательно в том, чтобы сразу что-то шифровать или ломать. Иногда важнее закрепиться так, чтобы доступ можно было использовать в нужный момент, например на фоне политического кризиса.
В этом контексте показателен кейс Volt Typhoon. Американские ведомства предупреждали, что связанные с КНР акторы компрометировали сети критической инфраструктуры и в отдельных случаях сохраняли там доступ годами. Microsoft ранее описывала активность Volt Typhoon в Гуаме и других локациях США против организаций из связи, промышленности, коммунального сектора, строительства и транспорта. Набор приемов при этом не выглядит как киберпанк будущего: уязвимые маршрутизаторы, межсетевые экраны и VPN-устройства на периметре, украденные администраторские учетные записи, легитимные аккаунты и техника living off the land, когда злоумышленник использует встроенные системные инструменты вместо вредоноса. Для SOC это худший жанр: активность похожа на обычную работу, а не на яркий фейерверк из IOC.
Отсюда и главный тезис: одной проверки личности уже недостаточно. Да, MFA остается обязательным минимумом, и спорить с этим поздно. Но сам по себе второй фактор не спасает, если атакующий уже перехватил сессию, провел пользователя через фишинг, зарегистрировал подставное устройство, вошел через доверенный канал удаленного доступа или просто использует реальный корпоративный аккаунт с неконтролируемого ноутбука. Поэтому Zero Trust в критической инфраструктуре упирается не в абстрактное «не доверяй никому», а в очень прикладной вопрос: кто именно подключается, с какого устройства, в каком состоянии это устройство находится и к какому ресурсу запрашивается доступ.
Отдельную актуальность этому подходу добавляет сближение IT- и OT-контуров. CISA недавно выпустило документ Adapting Zero Trust Principles to Operational Technology, где прямо говорится об опасности неявного доверия. Для OT-среды это особенно чувствительно: там есть требования к безопасности технологических процессов, к доступности, к совместимости со старым оборудованием и системами, которые никто не может просто выключить на выходные ради модернизации. Но проблема не ограничивается цехом и контроллерами. Colonial Pipeline показала неприятную вещь: даже если злоумышленник ломает не саму операционную технологию, а бизнес-критичные IT-системы, ущерб все равно может оказаться вполне физическим. Биллинг, удаленный доступ, облачные сервисы, SaaS и внутренняя админка давно стали частью того, что держит на плаву «железную» инфраструктуру.
Поэтому начальной точкой для внедрения здравого Zero Trust авторы называют доступ сотрудников к критичным системам. Это действительно прагматичный путь. Переделать весь OT-ландшафт быстро невозможно: слишком много наследия, подрядчиков, специализированного ПО и сценариев, где ошибка защиты стоит дороже самой атаки. Зато можно пересобрать правила доступа персонала к приложениям, данным и административным контурам. В такой модели служба безопасности перестает задавать только вопрос «это правильный пользователь?» и добавляет еще три: это правильный пользователь, на правильном устройстве, в правильном состоянии и для правильного ресурса? Для инженера на управляемом ноутбуке с актуальными патчами, шифрованием и защитой конечной точки ответ может быть одним. Для финансиста, заходящего с личного домашнего устройства, совсем другим. И это не дискриминация, а нормальная работа риск-модели.
Specops, разумеется, подводит к собственному решению и предлагает связывать идентичность с конкретным устройством. Идея понятна даже без привязки к вендору: украсть пароль, токен или cookie сессии заметно проще, чем одновременно завладеть еще и проверенным физическим устройством, которое соответствует политике компании. В описании продукта упоминаются несколько функций, которые хорошо ложатся на общий тренд рынка: проверка доверия к устройству при каждом запросе доступа, контроль его состояния во время сессии, видимость как управляемых, так и «теневых» устройств, а также ограничение числа разрешенных устройств на пользователя. Добавим сюда возможность дать сотруднику время на обновление или самостоятельное исправление части проблем без звонка в сервис-деск, и получится важная деталь любой рабочей Zero Trust-модели: безопасность не должна ломать бизнес быстрее, чем его могут сломать атакующие.
Для русскоязычной IT-аудитории вывод довольно приземленный. Если в компании до сих пор считают MFA финальной точкой зрелости доступа, это опасная самооценка. В 2026 году граница доверия проходит уже не по офисной сети и не по факту успешного входа в SSO, а по совокупности сигналов от личности, устройства, сессии и конкретного ресурса. Вопрос теперь не в том, придет ли Zero Trust в критическую инфраструктуру, а в том, кто успеет внедрить его до первого неприятного инцидента, а кто снова будет объяснять совету директоров, как одна «неактивная» учетка внезапно стала проблемой уровня отрасли.