Категорирование объекта КИИ по 187-ФЗ при облачной SCADA стороннего оператора

На категорировании химического предприятия в прошлом году комиссия убила две недели на один вопрос: SCADA (система диспетчерского управления и сбора данных) управляет реактором, но крутится на серверах стороннего облачного провайдера. Кто субъект КИИ — завод, который владеет процессом, или провайдер, которому принадлежит железо? Форму 236 (документ с результатами категорирования, утверждённый приказом ФСТЭК) переписывали трижды, прежде чем регулятор её принял. Это пошаговый разбор, как правильно провести категорирование объекта КИИ по 187-ФЗ, когда SCADA живёт в чужом облаке, и какие ошибки гарантированно приведут к возврату документов.

Кто является субъектом КИИ при аутсорсинге SCADA оператору

Федеральный закон 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» (ст. 2) определяет субъекта КИИ (критической информационной инфраструктуры) как организацию, которой на праве собственности, аренды или ином законном основании принадлежат объекты КИИ — информационные системы, информационно-телекоммуникационные сети и автоматизированные системы управления технологическими процессами (АСУ ТП). Обратите внимание на формулировку «на ином законном основании» — она здесь ключевая.

Когда предприятие переносит SCADA в облако, возникает юридическая развилка. Завод по-прежнему управляет технологическим процессом, а облачный оператор предоставляет инфраструктуру, на которой работает ПО SCADA. Кто субъект?

Позиция ФСТЭК однозначна: субъектом КИИ остаётся организация, чей критический процесс обслуживает система. Если завод использует облачную SCADA для управления реактором — он и есть субъект КИИ, независимо от физического расположения серверов. Договор SaaS-подписки или аренды облачной инфраструктуры — то самое «иное законное основание» из ст. 2. Облачный оператор при этом может быть субъектом КИИ отдельно — если сам работает в одной из отраслей, перечисленных в 187-ФЗ (связь, энергетика, ТЭК и т.д.).

Передача SCADA в облако не снимает с предприятия ни одной обязанности по категорированию. Постановление Правительства РФ №127 от 08.02.2018 (Правила категорирования объектов КИИ) прямо указывает: даже если часть инфраструктуры обеспечивается подрядчиком, решение о категории принимает субъект КИИ. Делегировать ответственность договором не получится — это норма закона, а не пожелание регулятора.

Границы значимого объекта КИИ в гибридной архитектуре

Самый болезненный этап при работе с облачной SCADA — определение границ объекта КИИ. Когда всё стоит на площадке завода, границы очевидны: от полевых датчиков до HMI (пульта оператора — Human-Machine Interface) в диспетчерской. Когда часть компонентов уходит в облако, граница размывается, и именно здесь комиссии чаще всего ошибаются.

Типичная архитектура облачной SCADA включает несколько уровней. Для их описания полезна модель Пёрдью (Purdue Model — стандартная модель сегментации промышленных сетей, которая делит инфраструктуру на уровни от полевого оборудования до корпоративной сети; если вы приходите из IT — представьте её как OSI-модель, но для заводов):

• Уровень 0–1 (полевой): датчики, исполнительные механизмы, ПЛК (программируемые логические контроллеры — по сути, мини-компьютеры, управляющие конкретным оборудованием), RTU (удалённые терминальные устройства) — физически на площадке завода
• Уровень 2 (управление): HMI, SCADA-сервер, сервер алармов — размещены в облаке провайдера
• Уровень 3 (операции): историан (сервер хранения технологических данных — аналог базы данных, но для показаний датчиков с привязкой ко времени), инженерные станции — могут быть частично в облаке, частично локально
• Каналы связи: VPN-туннели, выделенные каналы, MPLS между площадкой и облаком

Правило для комиссии по категорированию: объект КИИ — вся АСУ ТП целиком, включая облачную часть. Нельзя разбить одну систему управления на «свою часть» и «облачную часть», чтобы снизить категорию. ФСТЭК рассматривает объект как единое целое. Я видел попытки — ни одна не прошла.

На практике границы фиксируются в акте категорирования КИИ и включают:

1. Перечень полевого оборудования (ПЛК, RTU, датчики) с привязкой к технологическому процессу
2. Облачные компоненты SCADA (серверы, HMI, историан) с указанием провайдера и площадки ЦОД
3. Каналы связи между площадкой и облаком (тип, резервирование, шифрование)
4. Точки сопряжения — конкретные узлы (gateway, демилитаризованная зона), где зона ответственности завода переходит в зону провайдера

Чем OT-угрозы для облачной SCADA отличаются от IT-рисков

Корректная оценка критериев значимости невозможна без понимания специфики угроз. Облачная SCADA — не «ещё одна ИС в облаке». Отличия от IT-безопасности фундаментальны, и для SCADA безопасности эта разница определяет всё. Если вы переходите из IT в промышленную ИБ, вот что нужно перестроить в голове:

Приоритеты перевёрнуты. В IT на первом месте конфиденциальность (Confidentiality), затем целостность (Integrity), затем доступность (Availability) — классическая триада CIA. В АСУ ТП — наоборот: доступность и физическая безопасность (Safety) важнее конфиденциальности. NIST SP 800-82 (руководство по безопасности промышленных систем управления) фиксирует это явно: для ICS-окружений доступность и безопасность превалируют над конфиденциальностью. Если SCADA управляет химическим реактором и теряет связь с облаком — это не «утечка данных», а потенциальная авария с экологическими и социальными последствиями.

Протоколы без аутентификации. Промышленные протоколы Modbus (функциональные коды 1–6 для чтения/записи регистров: например, function code 6 — Write Single Register — записывает значение в единичный регистр ПЛК), DNP3, OPC UA в базовой конфигурации передают команды в открытом виде, без криптографической аутентификации. Когда такой трафик идёт через облачный канал, атакующий, получивший доступ к облачной инфраструктуре, может отправить управляющую команду напрямую на контроллер. В IT-мире аналог — представьте REST API без токена авторизации, только вместо записи в базу данных — открытие задвижки на трубопроводе.

Реальные инциденты подтверждают, что это не теория. По данным EN-источников (Zentera, IEEE Public Safety Technology), в 2015–2016 годах координированные атаки на энергосеть Украины привели к отключению электричества у примерно 230 000 потребителей — первые подтверждённые кибер-индуцированные блэкауты. Атакующие проникли через фишинг IT-сотрудников, латерально переместились в OT-сегмент и манипулировали выключателями. В 2021 году ransomware-атака на Colonial Pipeline (крупнейший топливопровод США) привела к шестидневной остановке поставок топлива на восточном побережье. Оба инцидента начались в IT-сети и перешли в OT — путь, который при облачной SCADA становится ещё короче, потому что облако и есть IT-сеть.

Критерии значимости объекта КИИ с облачной SCADA-системой

Постановление Правительства РФ №127 устанавливает пять групп критериев значимости. Для каждого критерия оценивается последствие компьютерного инцидента, ведущего к нарушению функционирования объекта. Оценка ведётся по наихудшему реалистичному сценарию — не по «что может случиться в теории», а по «что случится, если всё пойдёт не так одновременно».

Три категории значимости: первая (высшая), вторая, третья. Категория присваивается по наивысшему достигнутому показателю. Если по социальному критерию объект тянет на третью категорию, а по экономическому — на вторую, присваивается вторая. Если ни один критерий не достигнут — объект КИИ остаётся без категории, но сведения всё равно направляются в ФСТЭК.

Дополнительные сценарии при облачной архитектуре

При оценке критериев для облачной SCADA включайте в расчёт два сценария, которых нет при классической локальной инсталляции:

Компрометация облачного провайдера. Атакующий получает доступ к облачной инфраструктуре и может манипулировать HMI или историаном. Этот сценарий обязан быть в модели угроз. Для формирования перечня актуальных угроз используйте БДУ ФСТЭК (Банк данных угроз — открытый реестр угроз безопасности информации на bdu.fstec.ru; по сути, это российский аналог MITRE ATT&CK, но заточенный под нормативку РФ).

Полная потеря канала связи. DDoS-атака на провайдера, обрыв магистрального канала или авария в ЦОД — полевое оборудование может перейти в аварийный режим или продолжить работу без управления. Последствия зависят от наличия локального резерва (standalone-контроллер, локальная HMI) и от того, протестирован ли он реально. «Резерв есть, но мы его не проверяли» — фраза, которую я слышал на каждом втором предприятии. ФСТЭК тоже её слышит и категорию на этом основании не снижает.

Пошаговое категорирование облачной SCADA: от приказа до ФСТЭК

Ниже — конкретный алгоритм, адаптированный для гибридной архитектуры «площадка + облако». Каждый шаг — одно действие с ожидаемым результатом.

Требования к окружению

Перед началом убедитесь, что доступны:

• Действующий договор с облачным оператором SCADA (нужен для определения границ ответственности)
• Полный перечень технологических процессов предприятия (из технологической документации)
• Данные о составе АСУ ТП: полевое оборудование, ПО SCADA, каналы связи
• Контакт с ИТ/ИБ-подразделением облачного провайдера (для уточнения архитектуры на его стороне)

Шаг 1. Издать приказ и сформировать комиссию

Зачем. Без комиссии по категорированию результаты юридически недействительны — ФСТЭК вернёт документы.

Что делаем. Руководитель предприятия подписывает приказ о создании комиссии. Состав (по ПП №127):

• Руководитель или уполномоченное лицо (председатель)
• Специалист по ИТ/АСУ ТП
• Специалист по ИБ (если есть в штате)
• Технолог (знает процесс, который обслуживает SCADA)
• Специалист по ГО и ЧС (гражданская оборона и чрезвычайные ситуации)
• Юрист (при необходимости)

Нюанс для облачной SCADA: включите в комиссию сотрудника, который взаимодействует с облачным провайдером и понимает архитектуру решения. Если внутренней экспертизы нет — привлеките внешнего консультанта, но ответственность за категорирование остаётся на субъекте КИИ. Консультант поможет с документами; отвечать перед ФСТЭК будете вы.

Результат: подписанный приказ с составом и положением о комиссии.

Шаг 2. Выявить все объекты КИИ, включая облачные компоненты

Зачем. Пропущенный объект — основание для предписания ФСТЭК при проверке.

Что делаем. Комиссия анализирует деятельность предприятия и составляет перечень всех ИС (информационных систем), ИТС (информационно-телекоммуникационных сетей) и АСУ. Для каждой системы фиксируется:

• Какой критический процесс она обеспечивает
• Где физически расположены компоненты (площадка / облако / гибрид)
• На каком основании используется (собственность, аренда, SaaS)

Облачная SCADA — один объект КИИ (АСУ ТП), а не два отдельных. Полевой уровень на площадке и облачная часть у провайдера — единая система. Разделять их для занижения категории — прямой путь к возврату документов. Регулятор этот приём знает.

Результат: перечень объектов КИИ с типом, привязкой к процессу и размещением компонентов.

Шаг 3. Определить границы каждого объекта

Зачем. Некорректные границы — причина номер один возврата формы 236 при облачной архитектуре.

Что делаем. Для облачной SCADA документируем:

• Полевой уровень: перечень ПЛК, RTU, датчиков, исполнительных механизмов с серийными номерами и IP-адресами
• Облачный уровень: компоненты в облаке (сервер сбора данных, HMI, историан, сервер алармов), наименование провайдера, тип сервиса (IaaS/PaaS/SaaS), расположение ЦОД
• Каналы связи: тип, пропускная способность, наличие резерва, шифрование
• Точки сопряжения: конкретные узлы, где зона ответственности завода переходит в зону провайдера

Результат: паспорт объекта КИИ с полной топологией, включая облачный сегмент.

Шаг 4. Оценить критерии значимости

Зачем. На этом этапе определяется, какую категорию (или отсутствие категории) получит объект.

Что делаем. По каждому из пяти критериев ПП №127 оцениваем последствия компьютерного инцидента, ведущего к нарушению функционирования объекта. Для облачной SCADA наихудший реалистичный сценарий — одновременная потеря облачной части и компрометация полевого уровня.

Для каждого показателя записываем: применим ли к нашему объекту (да/нет), какое значение достигается при наихудшем сценарии, какая категория значимости соответствует.

Результат: таблица расчёта по всем критериям и итоговая категория.

Шаг 5. Оформить акт категорирования КИИ и заполнить форму 236

Зачем. Форма 236 — обязательный документ для направления в ФСТЭК.

Что делаем. Результат работы комиссии оформляется протоколом заседания и актом категорирования, после чего заполняется форма 236. При заполнении для облачной SCADA:

• В описании объекта укажите, что часть компонентов размещена в облаке стороннего оператора, с наименованием провайдера и типом сервиса
• В разделе о мерах защиты разграничьте, что реализуется на стороне завода, а что — на стороне провайдера (со ссылкой на SLA и ИБ-приложение к нему)
• В модели угроз явно укажите угрозы, связанные с облачным размещением: компрометация инфраструктуры провайдера, перехват канала связи, несанкционированный доступ через облачную среду

Результат: заполненная форма 236, протокол и акт категорирования.

Шаг 6. Направить сведения в ФСТЭК

Зачем. Законодательная обязанность субъекта КИИ (ст. 7, ч. 5 187-ФЗ). Пропустить нельзя.

Что делаем. Направляем сведения в ФСТЭК в письменном виде в десятидневный срок со дня принятия решения комиссией. ФСТЭК проверяет документы в тридцатидневный срок. Если всё корректно — значимый объект включается в реестр значимых объектов КИИ (ЗОКИИ). При нарушениях — сведения возвращаются с мотивированным обоснованием, и у вас есть десять дней на устранение замечаний. Десять дней — это мало, особенно если нужно заново согласовывать границы объекта с провайдером. Поэтому лучше сделать правильно с первого раза.

Результат: уведомление от ФСТЭК о включении в реестр или о доработке.

Что включить в SLA с облачным провайдером SCADA по требованиям приказа ФСТЭК №239

После присвоения категории значимости вступают в силу требования приказа ФСТЭК №239 (требования по обеспечению безопасности значимых объектов КИИ). Часть этих требований невозможно выполнить силами предприятия, если инфраструктура SCADA — в чужом облаке. ИБ-приложение к SLA (соглашению об уровне сервиса) — не формальность, а рабочий инструмент для прохождения проверки ФСТЭК.

Минимальный набор пунктов для ИБ-приложения:

Управление доступом. Провайдер реализует разграничение доступа к облачным компонентам SCADA: только авторизованные сотрудники предприятия и согласованные специалисты провайдера получают доступ к HMI, серверам сбора данных, историану. MFA (многофакторная аутентификация — подтверждение личности двумя и более способами, например пароль + одноразовый код из приложения) обязательна для любого удалённого подключения.

Логирование и мониторинг. Провайдер ведёт журналы всех действий в облачной части SCADA: авторизации, изменения конфигурации, управляющие команды. Журналы хранятся не менее срока, установленного для конкретной категории значимости, и предоставляются субъекту КИИ по запросу. Это требование перекликается с IEC 62443 (международный стандарт безопасности промышленной автоматизации), который требует мониторинга трафика на границах зон и каналов.

Уведомление об инцидентах. Провайдер уведомляет субъекта КИИ о любом инциденте ИБ в облачной инфраструктуре SCADA в согласованный срок (для ЗОКИИ первой категории — не более 4 часов). Субъект КИИ передаёт информацию в ГосСОПКА (государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак — по сути, национальный CERT, куда обязаны сообщать все субъекты КИИ).

Резервное копирование и восстановление. RPO (Recovery Point Objective — максимальный допустимый период потери данных) и RTO (Recovery Time Objective — максимальное допустимое время восстановления) указываются конкретными числами в часах. Формулировка «в разумные сроки» — не годится. Напишите «RPO: 1 час, RTO: 4 часа» — и ФСТЭК примет, и провайдер будет знать, за что отвечает.

Локализация данных. Серверы облачной SCADA размещаются на территории РФ — для ряда отраслей это прямое требование. Провайдер документально подтверждает расположение ЦОД.

Порядок обновлений. Установка обновлений на облачные компоненты SCADA согласовывается с субъектом КИИ. В отличие от IT-систем, обновление SCADA-сервера может потребовать остановки технологического процесса — провайдер не вправе обновлять компоненты в одностороннем порядке. Это не каприз, а специфика OT: в IT вы обновляете nginx и перезапускаете сервис, в OT вы обновляете SCADA-сервер и останавливаете конвейер.

Типичные ошибки при категорировании облачной SCADA и возврат формы 236

За время работы с категорированием на полутора десятках предприятий я видел одни и те же ошибки, которые ведут к возврату формы 236 из ФСТЭК:

Ошибка 1: «Облако — не наше, категорировать нечего». Предприятие решает, что раз серверы SCADA ему не принадлежат физически, объект КИИ отсутствует. ФСТЭК возвращает сведения: объект определён не полностью, не учтены все компоненты АСУ ТП. Напомню: «иное законное основание» из ст. 2 — это и про SaaS-договор тоже.

Ошибка 2: Искусственное разделение одной АСУ ТП на части. Завод категорирует полевой уровень как отдельный объект (без категории), а облачную часть оформляет как ИС с другими критериями значимости — или вовсе «не замечает». ФСТЭК выявляет несоответствие и возвращает форму.

Ошибка 3: Модель угроз без облачных сценариев. Модель угроз составлена как для обычной локальной SCADA, без учёта компрометации облачной инфраструктуры и потери канала связи. При проверке по ст. 14 187-ФЗ (государственный контроль ФСТЭК за выполнением требований по безопасности ЗОКИИ) это основание для предписания.

Ошибка 4: SLA без ИБ-приложения. Предприятие ссылается на SLA с провайдером, но в документе нет ни слова про информационную безопасность — только uptime 99,9% и время реакции техподдержки. Для ФСТЭК это не подтверждение выполнения мер защиты по приказу №239.

Ошибка 5: Занижение категории через непроверенный «локальный резерв». Предприятие заявляет, что при потере облачной SCADA процесс управляется автономными контроллерами и последствия минимальны. На проверке выясняется, что резерв не тестировался, не задокументирован или покрывает 30% функций. ФСТЭК возвращает форму с требованием пересчитать критерии на основании реального состояния. Если ваш «резерв» — это контроллер, который последний раз переключался в автономный режим три года назад при пусконаладке, это не резерв.

Категорирование объекта КИИ при облачной SCADA выглядит бюрократической задачей, но на деле превращается в полноценный архитектурный аудит всей системы управления. Именно здесь всплывают реальные проблемы, которые предприятие не видело до начала процедуры: незадокументированные каналы связи, непротестированные аварийные режимы, SLA без единого пункта про безопасность.

Тренд устойчивый: предприятия мигрируют SCADA в облако ради экономии на серверной инфраструктуре, но не закладывают в бюджет стоимость комплаенса. ИБ-приложение к SLA, модель угроз с облачными сценариями, тестирование локального резерва при потере связи — всё это стоит денег и времени. И всё это нужно до отправки формы 236, а не после первой проверки.

Главная ловушка — ожидание, что облачный провайдер «всё обеспечит». Провайдер обеспечивает доступность своей инфраструктуры. Ответственность субъекта КИИ за безопасность критического процесса не передаётся ни одним договором — это прямая норма 187-ФЗ. В ближайшие год-два ФСТЭК усилит контроль за гибридными и облачными объектами КИИ — регулятор видит массовый переезд в облака при категорировании по старым лекалам. Формы 236 будут возвращать чаще, проверки по ст. 14 — назначать прицельно по предприятиям с облачной инфраструктурой. Кто пройдёт категорирование грамотно сейчас, тот сэкономит полгода переписки с регулятором. Если вы переходите из IT в промышленную ИБ и нужна структура — IB Basics на codeby.school закрывает фундамент за пару месяцев, от базовых концепций до первых практических задач.