Zero Trust и КИИ: где концепция накладывается на приказ 239

ФСТЭК в этом году активно дорабатывает методическую базу по защите критической информационной инфраструктуры. Последние рекомендации касаются сегментации сетей и контроля доступа к объектам КИИ - то есть именно тех вещей, которые в рамках Zero Trust обсуждаются уже несколько лет. Пересечение оказалось интереснее, чем мы ожидали.

Что ФСТЭК сейчас говорит

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

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

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

Где это пересекается с Zero Trust

Zero Trust как концепция строится на нескольких принципах: не доверять сети по умолчанию, проверять каждый запрос явно, минимизировать привилегии. Когда смотришь на меры защиты из приказа 239 - особенно раздел УПД (управление правами доступа) и ЗИС (защита информационной (автоматизированной) системы) - обнаруживаешь, что требования к ним формулируются в терминах, которые с Zero Trust хорошо рифмуются.

Конкретно: меры УПД.2 (управление учётными записями), УПД.3 (управление составом привилегий) и УПД.4 (разделение полномочий) вместе складываются в то, что в Zero Trust называется принципом минимальных привилегий. Мера ЗИС.17 про сегментирование информационной системы - это и есть микросегментация, только в терминах ФСТЭК.

Это не значит, что «внедрить Zero Trust = выполнить 239». Приказ требует конкретных мер с конкретными классами систем, и соответствие подтверждается не концепцией, а документами и конфигурациями. Но Zero Trust даёт архитектурную логику, в рамках которой регуляторные требования выглядят не как список галочек, а как связная система.

Как это выглядит на практике

У одного из клиентов с объектами КИИ второй категории мы разбирали именно это пересечение. Задача стояла так: приближается аттестация, есть понимание что часть мер формально выполнена, но «как это работает» - вопрос открытый.

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

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

Это не катастрофа, это типичное состояние системы, которую не трогали с точки зрения прав несколько лет. Аудит позволяет зафиксировать фактическое состояние - и именно с него начинается разговор про то, что реально нужно сделать, а что уже есть.

Что с этим делать

Пересечение Zero Trust и требований КИИ даёт практический ориентир для приоритизации работ.

Микросегментация. Закрывает ЗИС.17 и убирает риск бокового движения внутри технологического сегмента. Начинать с инвентаризации: какие потоки данных между сегментами реально нужны, а какие «исторически разрешены».

Минимальные привилегии и review доступов. Закрывает УПД.2-УПД.4. Это регулярная операция, а не разовая - учётки и права меняются вместе с персоналом и задачами. Если последний раз права пересматривались при вводе системы в эксплуатацию, это уже проблема.

Явная аутентификация для привилегированного доступа. В КИИ это особенно критично: доступ оператора к АСУ должен быть персонифицирован и логируем. Общие учётки типа «operator» без привязки к конкретному человеку - это не только регуляторный вопрос, это невозможность разобраться что произошло после инцидента.

Логирование событий доступа. Меры АУД (аудит безопасности) в 239-м требуют фиксации событий безопасности. В Zero Trust-терминологии это «непрерывная верификация» - и то и другое требуют одного: видеть кто, куда и когда обращался.

Практический результат такого подхода - не «мы внедрили Zero Trust», а «у нас есть конкретный перечень мер, которые закрывают конкретные пункты 239-го и одновременно улучшают реальную защищённость системы». Для аттестации важен первый аргумент, для ИБ-команды - второй. Хорошо, когда они совпадают.

Регуляторика по КИИ продолжает уточняться, и методические рекомендации - это попытка ФСТЭК дать больше конкретики там, где приказ оставлял вопросы. Направление правильное, хотя работы по интерпретации меньше не становится.