1. Zero Trust и OT: вызовы
Zero Trust — это не очередной маркетинговый ярлык, а устойчивая философия сетевой недоверчивости. Если коротко, она утверждает: никому и ничему нельзя верить по умолчанию, даже собственным серверам после обеда. Архитектура Zero Trust (ZTA — Zero Trust Architecture) строится на том, что каждый доступ проверяется в контексте: кто, откуда, зачем и в каком состоянии устройство. Суть проста — пока субъект не докажет, что достоин доверия, он его не получает.
Актуальность ZTA сегодня диктуется ростом взаимосвязанности систем и абсурдной скоростью, с которой IT и OT‑миры переплетаются. Производственные сети, которые раньше были «в офлайне и под замком», теперь подключены к облачным аналитическим сервисам и внешним подрядчикам. И вот тут паранойя перестаёт быть теорией за кофе, а становится архитектурным требованием — особенно для КИИ, где ошибка может стоить не данных, а реальной физической аварии.
1.1. IT vs OT: различия в приоритетах
Zero Trust придумали радикальные параноики, которым не хватает сна и доверия. Это философия, где любая сессия, устройство и пользователь априори считаются потенциально скомпрометированными, пока не доказано обратное. В IT‑среде она прижилась легко: если ноутбук офисного сотрудника не смог пройти многофакторку, никто особо не плачет. IT‑специалисты живут в мире, где подобное недоразумение — катастрофа уровня «не пришёл отчёт к утру»Но стоит применить ту же схему к промышленной инфраструктуре (OT — Operational Technology), и внезапно оказывается, что тут живут по другой логике. OT‑инженеры живут в мире, где отказ контроллера оставит без вентиляции целый химический цех.
В IT думают по модели CIA (Confidentiality‑Integrity‑Availability), а в OT всё наоборот — AIC (Availability-Integrity-Confidentiality) : сначала доступность, потом целостность, и уж потом конфиденциальность. Когда на кону SCADA‑система (Supervisory Control And Data Acquisition — диспетчерское управление и сбор данных), управляющая турбиной или технологической линией, отказ в связи из-за «строгой Zero Trust‑политики» выглядит не безопасностью, а саботажем.
В OT‑пространстве всё упирается в жизненный цикл. За годы производственных апдейтов и модернизаций протоколы, патчи и контроль доступа рассинхронизировались так, что корпоративная SOC‑команда просто не успевает «доверять, но проверять». Патчить PLC посреди рабочей смены — значит пойти на священное нарушение «zero downtime» (нулевой простой). Поэтому чисто IT‑подход в лоб тут не работает: безопасность должна встроиться в процессы так, чтобы технологи даже не заметили.
1.2. Legacy devices и протоколы без защиты
В OT (Operational Technology — операционные технологии) до сих пор в ходу устройства, которые помнят времена, когда слово "кибербезопасность" вызывало недоумение. Классический PLC (Programmable Logic Controller — программируемый логический контроллер) часто не имеет ни криптографической поддержки, ни внятного механизма аутентификации. Протокол Modbus проектировался в расчёте на физическую изоляцию и доверенную среду. Передавать по нему команды можно с таким же успехом, как отправлять SMS — никакой аутентификации, никакого шифрования, просто "прочитай регистр" или "запиши значение".Проблема не в том, что производители плохие, а в том, что эти устройства работают, и работают десятилетиями. Заменить их на современные аналоги — значит остановить производство, перепрошить сотни контроллеров и пересмотреть всю логику управления процессом.
Zero Trust в этой ситуации сталкивается с жестокой реальностью: невозможно установить агент безопасности на контроллер, который едва справляется со своей основной задачей. Невозможно потребовать от него MFA (Multi-Factor Authentication), если у него нет интерфейса для ввода пароля. Приходится искать обходные пути: защищать не само устройство, а доступ к нему, ставить контрольные точки на путях трафика и учиться распознавать аномалии без активного вмешательства в работу железа. Это архитектура компенсирующих мер, где безопасность строится вокруг легаси, а не путём его замены.
1.3. Детерминированность, real-time и абсолютная доступность
OT-сети не прощают задержек. Если команда на открытие задвижки не дошла за 50 миллисекунд, процесс может уйти в аварию. Это не гигиеническое требование, а физический закон, завязанный на механику, гидравлику и термодинамику. Внедряя любое решение безопасности, приходится каждый раз отвечать на один и тот же вопрос: "А сколько это добавит к latency?" Если ответ больше допустимого — решение отправляется в корзину, даже если оно закрывает десяток критических уязвимостей.Классический подход Zero Trust, предполагающий inline-проверку каждого пакета с динамическим принятием решений, для многих промышленных контуров неприменим в чистом виде. Здесь важна детерминированность связей: инженерная станция А должна иметь возможность всегда, без вариантов, достучаться до контроллера Б. Любая система, которая может ошибочно заблокировать этот трафик, становится источником риска, который часто перевешивает угрозу внешнего взлома. Поэтому архитектура Zero Trust для КИИ требует принципиально иного подхода: безопасность должна быть встроена так, чтобы даже в случае её полного отказа производственный процесс продолжал работать. Fail-open, а не fail-closed. И это, пожалуй, самое неудобное требование для специалиста по безопасности, привыкшего, что в случае сомнений лучше заблокировать доступ. В промышленной среде лучшее — враг хорошего, а доступность — король.
1.3. Availability и детерминированность процессов
Если спросить любого оператора SCADA, что страшнее — компрометация или остановка производственной линии, ответ будет очевиден. В критической инфраструктуре (КИИ) нулевая терпимость к простоям превращает любую концепцию ZTA (Zero Trust Architecture) в инженерный квест. Задача — внедрить политику «всё проверяем» без того, чтобы кто‑то заметил, что теперь всё проверяется.Решения находятся между технологиями и интуицией: passive monitoring (пассивный мониторинг), staged rollout (поэтапное развёртывание), фильтрация в inline-режиме (прямолинейная фильтрация трафика) с fail-open (отказоустойчивый режим «разрешить при сбое») на отказоустойчивом канале. Иногда внедрение ZTA (Zero Trust Architecture — архитектура нулевого доверия) в OT похоже на хирургическую операцию на работающем организме — всё движется, всё критично, и один неверный шаг может дорого стоить. Поэтому Zero Trust для КИИ — не про контроль любой сессии, а про доверие в балансе с физикой процессов. А паранойя тут становится не диагнозом, а эксплуатационным требованием, но она не должна мешать производственному процессу
2.1. Семь принципов Zero Trust в промышленной среде
Ссылка скрыта от гостей
— — руководство по архитектуре Zero Trust, даёт чёткие семь принципов, которых надо придерживаться во время применения Zero Trust в промышленности.- Все источники данных и вычислительные сервисы считаются ресурсами.
- Любая коммуникация защищается вне зависимости от того, где она проходит.
- Доступ к каждому корпоративному ресурсу предоставляется на индивидуальной сессионной основе.
- Доступ к ресурсам определяется динамической политикой, которая учитывает наблюдаемое состояние клиента (идентификатор, приложение или сервис, запрашивающий актив), а также другие поведенческие и средовые атрибуты.
- Организация контролирует и измеряет целостность и уровень безопасности всех принадлежащих ей и связанных с ней активов.
- Аутентификация и авторизация при обращении к любым ресурсам осуществляются динамически и строго проверяются до предоставления доступа.
- Организация собирает максимум информации о текущем состоянии активов, сетевой инфраструктуры и коммуникаций и использует её для повышения уровня безопасности.
Принципы адаптируются хитро: «verify explicitly» превращается в проверку сертификатов на границе зон, а «assume breach» — в постоянный аудит трафика без остановки линии. В итоге из семи абстрактных тезисов рождается рабочая схема, где Zero Trust КИИ не мешает детерминированной связи, а просто убирает из неё лишних гостей. Ирония в том, что самые строгие правила NIST тут смягчаются реальностью — иначе производство встанет раньше, чем хакеры доберутся до сети.
2.2. Policy Engine и Policy Enforcement в OT-трафике
Policy Engine (движок политик) — это мозг системы, который в реальном времени решает, пускать ли пакет от PLC к SCADA или вежливо завернуть обратно. В OT он не висит в облаке, как в корпоративных историях, а работает локально или в гибридном режиме, чтобы задержка не превышала микросекунд. Policy Enforcement Point (PEP, точка принудительного выполнения политик) — это уже «руки» системы: шлюзы на границах зон, встроенные контроллеры или даже смарт-коммутаторы, которые физически разрезают или пропускают трафик по директивам от Engine.
В промышленной сети это выглядит как оверлей над плоской топологией: Engine коррелирует данные из пассивных сенсоров, логов и контекста, а PEP просто исполняет — без вопросов и объяснений. Если сессия не прошла trust check, она тихо дропается, но с fail-open, чтобы критический heartbeat-трафик PLC не прервался. Такой тандем делает Zero Trust для КИИ не бюрократией, а скоростным конвейером решений, где паранойя упакована в миллисекундные циклы.
2.3. Trust algorithm: контекстные параметры доступа
Trust algorithm (алгоритм доверия) — сердце NIST-адаптации, где решение «да/нет» рождается из коктейля: здоровье устройства (device health), личность пользователя (user identity), контекст (зона, смена, роль) и текущий уровень риска. В OT это не просто if-then скрипт, а нейросеть на стероидах, которая понимает разницу между плановой остановкой насоса и аномальным трафиком из ниоткуда. Например, инженер получает доступ к SCADA только с аттестованного ноутбука в зоне А, а PLC общается только с известными соседями по Purdue-модели.Алгоритм динамичен: если устройство начинает сыпать ошибками или контекст меняется (ночная смена без графика), доверие падает, и сессия идёт на усиленную проверку. Continuous monitoring КИИ здесь встроен по умолчанию — не как опция для параноиков, а как базовый режим выживания. Ирония в том, что в мире, где uptime священен, именно эта параноидальная математика позволяет спать спокойно, зная, что сеть сама себя фильтрует лучше любого оператора.
3. Технологии ZTA для КИИ: микросегментация и управление идентификацией
Разговоры о Zero Trust для промышленности часто упираются в одну и ту же стену: «Это всё красиво на слайдах, но как это воткнуть в мою сеть, где PLC работают с прошлого века, а downtime для экспериментов никто не даст?» Ответ — не пытаться воткнуть Zero Trust туда, где он сломает процесс, а строить вокруг него обходные архитектурные пути. Речь идёт не о замене оборудования, а о внедрении слоёв контроля, которые работают поверх существующей реальности. Три ключевые технологии, которые делают ZTA для КИИ не просто возможной, а относительно безболезненной: микросегментация через overlay-сети, замена классических VPN на SDP и управление machine identity для устройств, которые даже не подозревают о существовании криптографии.3.1. Микросегментация: overlay network поверх flat OT network (без реконфигурации)
Классическая OT-сеть — это, как правило, плоский (flat) пруд, где рыбы плавают где хотят. Инженерная станция видит все контроллеры, контроллеры видят всё, что попросят, и если злоумышленник добирается до одного сегмента, он часто получает компас на всю акваторию. Переделывать физическую топологию, перетаскивать кабели и перенастраивать коммутаторы, которые отвечают за real-time трафик, — занятие для самоубийц. Поэтому вместо того, чтобы ломать существующую сеть, ей накидывают поверх ещё одну, виртуальную — overlay network. Это как проложить над старыми железнодорожными путями новые маршруты, не выкапывая рельсы.Технически это выглядит так: между абонентами (инженерная станция, HMI, сервер) и контроллерами выстраиваются защищённые туннели по принципу «каждый с каждым только если разрешено политикой». Сами PLC и SCADA-серверы продолжают работать по своим родным протоколам, даже не подозревая, что вокруг них построили забор с электронным замком. Микросегментация (microsegmentation) в такой модели реализуется без единого изменения в конфигурации промышленного оборудования. Для legacy устройств, которые понятия не имеют о криптографии, это, пожалуй, единственный способ объяснить, что такое «доверие с проверкой».
3.2. SDP для remote access: замена VPN на Zero Trust Network Access (ZTNA)
VPN в мире КИИ — это как оставить дверь открытой, но повесить табличку «посторонним вход воспрещён». Подключившись к VPN, пользователь или атакующий получает полноценный доступ к сети, а дальше уже вопрос времени, когда он найдёт незащищённый контроллер. Вдобавок классические VPN-концентраторы сами становятся жирной целью: скомпрометировал VPN — получил ключи от всего королевства. Для промышленных сетей, где каждая учётная запись инженера тянет за собой доступ к десяткам критических устройств, это недопустимый риск.Альтернатива — SDP (Software Defined Perimeter) или его более маркетинговое воплощение ZTNA (Zero Trust Network Access). Идея простая до гениальности: ресурс не висит в сети в ожидании подключений. Его вообще не видно, пока не пришёл запрос с подтверждённой идентичностью. Пользователь сначала аутентифицируется, проходит проверку устройства, и только после этого ему открывается одноразовый, строго ограниченный по времени и целям канал к конкретному PLC или SCADA-серверу. Не ко всей сети, а к одной-единственной задаче. Для OT-инженера, которому нужно перепрошить конкретный контроллер в конкретном цехе, это выглядит как VPN, только безопасность на порядок выше, а поверхность атаки стремится к нулю.
3.3. Machine identity: X.509 certificates для PLC, SCADA servers
Пользователей можно заставить вводить пароль и подтверждать вход пуш-уведомлением. А что делать с PLC, который должен получать команды от конкретной инженерной станции, но сам не способен ни пароль ввести, ни даже понять, что его спрашивают? Тут в игру вступает концепция machine identity — идентификация машины. Устройствам выдаются цифровые паспорта, чаще всего в виде X.509 сертификатов, которые позволяют системе безопасности проверять: «А точно ли этот SCADA-сервер — тот самый, кому разрешено писать в контроллер № 4567?»Для современных контроллеров, поддерживающих сертификаты, это работает прозрачно. Для legacy PLC, которые думают, что сертификат — это справка из поликлиники, приходится применять финты ушами. Система безопасности берёт на себя роль посредника: она видит трафик от устройства, распознаёт его по fingerprint (цифровому отпечатку — MAC-адресу, протоколу, сигнатуре поведения), и уже от его имени предъявляет сертификат при взаимодействии с другими сегментами. Внешне для соседей по сети это выглядит как полноценная аутентификация, а старый PLC продолжает жить своей счастливой жизнью, даже не подозревая, что его научили работать с доверием.
4. Поэтапное внедрение
Zero Trust в промышленности нельзя «купить и развернуть», это не тот случай, когда можно прийти с коробкой, воткнуть железку и уйти домой довольным. OT-инфраструктура не прощает резких движений, поэтому внедрение здесь напоминает скорее хирургию, чем переустановку Windows. Стратегия простая: сначала разобраться, что у тебя есть, потом аккуратно попробовать на чём-то нестрашном, и только потом, убедившись, что всё не развалилось, раскатывать на всю сеть. Ключевое условие на каждом этапе — никакого downtime, потому что в мире КИИ остановка производства приравнивается к стихийному бедствию.4.1. Фаза 1: Пассивная инвентаризация и картирование сети
Первый и самый недооценённый этап — понять, чем ты вообще владеешь. Звучит обидно для промышленного предприятия, но практика показывает: никто точно не знает, сколько у него PLC (Programmable Logic Controller — программируемый логический контроллер), какие протоколы они используют и кто с кем разговаривает в час ночи. Активная инвентаризация со сканированием портов в OT — это как стучаться в двери спящего цеха: можно и не дождаться ответа, а можно и разбудить то, что лучше не будить. Поэтому используется пассивный сбор (passive discovery): сетевые TAP-ы (Test Access Point) или SPAN-порты на коммутаторах позволяют слушать трафик, не вмешиваясь в процесс.За пару недель такой прослушки вырисовывается картина, которую раньше видели только самые опытные инженеры АСУ ТП, да и то не целиком. Выявляются все активы, их IP-адреса, используемые протоколы (Modbus, Profinet, OPC UA и прочие), а главное — зависимости (dependencies): какой HMI стучится в какой PLC, без какой инженерной станции остановится конкретный участок. Это карта местности, без которой любая политика микросегментации будет гаданием на кофейной гуще. И да, всё это происходит без единой секунды простоя.
4.2. Фаза 2: Пилотный проект — микросегментация не критичного сегмента
После того как карта готова, возникает закономерный вопрос: «А давай попробуем, но на чём-нибудь, что не убьёт бизнес, если мы ошибёмся». Это называется стратегия low-hanging fruit — низко висящие фрукты, которые проще всего сорвать без риска сломать лестницу. Пилотный сегмент выбирается по принципу минимальной критичности. Идеальные кандидаты: система сбора данных (например, исторические данные с датчиков, которые пишутся в базу), периферийные устройства, не влияющие напрямую на технологический процесс, или участок с относительно современным оборудованием, где есть хоть какая-то поддержка криптографии.На этом сегменте разворачивается микросегментация в ограниченном объёме. Задача — не защитить всё и сразу, а доказать концепцию (PoC — Proof of Concept): что политики работают, что real-time коммуникации не нарушаются, что система не глючит при перезагрузке и что инженеры всё ещё могут выполнять свою работу, не проклиная службу безопасности. Если на пилоте что-то пошло не так, последствия локализованы и некритичны. Если всё прошло гладко — появляется аргумент для руководства: «Видите, работает, и цех не взорвался. Давайте дальше».
4.3. Фаза 3: Расширение на все зоны и непрерывный мониторинг
Третий этап — это когда заканчиваются игрушки и начинается настоящая работа. Политики безопасности, отработанные на пилоте, масштабируются на всю Purdue-модель: от нулевой зоны (самые чувствительные контроллеры) до третьей (операторский уровень и DMZ). На этом этапе критически важно, чтобы процессы были автоматизированы, потому что вручную настраивать доступ для сотен PLC и десятков инженерных станций — занятие для очень терпеливых людей, которых в природе почти не осталось.Здесь же в полный рост встаёт continuous monitoring (непрерывный мониторинг). Это уже не просто «посмотрим логи, если что-то случилось», а активный процесс: система следит за каждой сессией, анализирует поведение устройств и пользователей, ищет аномалии. Обнаружила попытку записи в контроллер в три часа ночи, хотя инженер Иванов всегда работает с девяти до шести? Доверие автоматически понижается, сессия завершается, устройство отправляется в карантин, а событие улетает в SIEM (Security Information and Event Management) и, если настроено, триггерит SOAR-плейбук (Security Orchestration, Automation and Response). В идеальном мире этот цикл — обнаружение, оценка, изоляция — происходит без участия человека, потому что человек будет думать, а в промышленной сети думать нужно быстро или не думать вообще, если речь идёт о блокировке угрозы.
5. Compliance
Zero Trust для КИИ — это не только про безопасность в вакууме. В реальности за внедрение спрашивают не только инженеры, но и регуляторы, аудиторы, а главное — финансовый директор, который хочет понимать, сколько это сэкономило или хотя бы не сожрало бюджет без причины. Хорошая новость: правильно построенная ZTA (Zero Trust Architecture) закрывает сразу несколько нормативных требований одновременно и позволяет перестать плодить десятки разрозненных средств защиты, каждое со своей лицензией и своим интерфейсом. Плохая новость — доказать это кому-то, кроме технических специалистов, всё равно придётся.5.1. IEC 62443: мэппинг ZTA-контролей
Стандарт IEC 62443 — это такой чек-лист для промышленной безопасности, который любят аудиторы и не любят инженеры: зоны, каналы, уровни защищённости, управляемость, логирование, всё как положено. Когда мы накрываем КИИ Zero Trust Architecture (ZTA — архитектура нулевого доверия), внезапно оказывается, что половина требований IEC 62443‑3‑3 закрывается «из коробки»: микросегментация даёт сегрегацию зон, identity-based access (доступ, основанный на идентичности пользователя или устройства) реализует контроль привилегий, а continuous monitoring (непрерывный мониторинг) оформляет красивые отчёты про события безопасности.Фокус в том, чтобы не рисовать две параллельные модели — «жизнь по ZTA» и «жизнь по IEC 62443», — а честно проложить mapping (соответствие) между контролями. Один и тот же SDP for OT (Software Defined Perimeter для операционных технологий) одновременно удовлетворяет требованиям к сегментации и защищённым каналам, а machine identity (цифровая идентичность машин) с X.509‑сертификатами спокойно ложится в требования по аутентификации устройств. В итоге CISO получает не религиозный спор «про стандарты», а таблицу вида: «вот ZTA‑компонент, вот пункт IEC, вот галочка».
5.2. ФЗ-187: как ZTA помогает соответствовать требованиям к КИИ
Российский ФЗ‑187 о безопасности критической информационной инфраструктуры требует от владельцев КИИ много неприятных вещей: знать свои значимые объекты, защищать периметр, управлять доступом, мониторить события и докладывать, если что‑то пошло не так. ZTA, как ни странно, здесь не модный западный атрибут, а вполне рабочий способ эти требования закрыть и не утонуть в зоопарке разрозненных средств защиты. Zero Trust КИИ позволяет описать архитектуру так, что у регулятора меньше поводов задавать убийственные вопросы.Микросегментация и ZTNA (Zero Trust Network Access — доступ к ресурсам по принципу Zero Trust) обеспечивают управляемый удалённый доступ к значимым объектам, continuous monitoring КИИ даёт базу для журналирования и инцидент‑репортинга, а identity-based access OT делает так, что инженер «Петя» больше не логинится под общим «admin». Важно, что ZTA оформляется в виде единой архитектурной модели, которую можно положить на стол при проверке: вот структура, вот потоки, вот контроли, вот как они закрывают требования ФЗ‑187. Всё ещё страшно, но хотя бы логично.
5.3. ROI: снижение risk exposure и compliance costs через единый ZTA framework
У любого нормального промышленника первый вопрос не «насколько безопасно?», а «сколько стоит и зачем?». Тут в игру входит ROI (Return On Investment — возврат на инвестиции): если ZTA framework (архитектурный каркас Zero Trust) уменьшает risk exposure (подверженность рискам) и compliance costs (затраты на соответствие требованиям), он внезапно перестаёт быть игрушкой для CISO и становится бизнес‑аргументом. Один раз сделать нормальную микросегментацию и централизованное управление доступом дешевле, чем каждый год латать новые дыры точечными решениями под конкретный пункт чек-листа.Единый ZTA‑подход экономит ещё и на людях: меньше ручных правил на межсетевых экранах, меньше «уникальных исключений», которые никто не может объяснить, меньше часов на подготовку к очередной проверке по ФЗ‑187 и IEC 62443. Вместо того чтобы каждый раз заказывать отдельный аудит по каждой системе, компания показывает одну архитектуру: industrial Zero Trust как базовую модель для всей КИИ. Паранойя становится не расходом, а активом: она снижает вероятность инцидента и одновременно удешевляет прохождение всех тех процедур, которыми регулятор так любит нагружать бизнес.
