Приказ ФСТЭК № 31: защита информации в АСУ ТП

Полное название документа — «Об утверждении Требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды». Утверждён приказом ФСТЭК России от 14 марта 2014 г. № 31, подписан директором ФСТЭК В.

Селиным, зарегистрирован в Минюсте России 30 июня 2014 г. под № 32919.

Требования распространяются на автоматизированные системы управления, которые обеспечивают контроль и управление технологическим и (или) производственным оборудованием и реализованными на нём процессами — в том числе системы диспетчерского управления, системы сбора и передачи данных, системы на основе программируемых логических контроллеров, распределённые системы управления, системы управления станками с числовым программным управлением (п.

3 Требований). Управляемые объекты — те, чья безопасность регулируется отдельным отраслевым законодательством: о безопасности объектов ТЭК, о транспортной безопасности, об использовании атомной энергии, о промышленной безопасности опасных производственных объектов, о безопасности гидротехнических сооружений и иными актами (п. 2). Товарная категория решений для такой защиты на SecRadar собрана в классе «АСУ ТП / SCADA».

Требования адресованы трём категориям субъектов (п. 4):

Отдельная оговорка — про гостайну: при обработке в АСУ информации, составляющей государственную тайну, её защита обеспечивается по законодательству РФ о гостайне (п. 5), приказ № 31 такую информацию напрямую не регулирует.

Да. Приказ № 31 действует в редакции от 15.03.2021 — список изменяющих документов на титульном листе включает приказы ФСТЭК России от 23.03.2017 № 49, от 09.08.2018 № 138 и от 15.03.2021 № 46. Полного аналога перехода «приказ № 17 → приказ № 117» — то есть отмены и замены под новым номером — для приказа № 31 не произошло: документ не отменён, не переиздан, продолжает применяться в действующей редакции.

Практический вывод: сам приказ № 31 действует без пересмотра статуса с 15.03.2021 — это закрытый вопрос. А появление отдельной методической детализации именно для АСУ ТП, по аналогии с тем, что произошло для ГИС, ПДн и значимых объектов КИИ в апреле 2026 года, — вопрос открытый, не стоит преподносить его как решённый факт.

Этот вопрос встаёт для любой АСУ ТП, которая относится к критически важным объектам и одновременно может оказаться объектом критической информационной инфраструктуры. Ответ закреплён прямой нормой в самом тексте приказа № 31 — она добавлена приказом ФСТЭК № 138 от 09.08.2018, уже после появления законодательства о безопасности КИИ:

Из этой нормы следует практическое правило «что применять к конкретной системе»:

↔ таблицу можно прокрутить вбок

Хронологически приказ № 31 (2014 год) появился до 187-ФЗ (в силе с 01.01.2018) и до приказов № 239 и № 235 (оба от декабря 2017 года) — изначально он адресовал более широкую и старую категорию объектов по отраслевому законодательству, без привязки к понятиям КИИ. Норма о разграничении с приказами № 239/№ 235 добавлена позже, чтобы развести сферы действия двух режимов, а не оставлять их конкурировать.

По вторичным источникам, состав мер и их базовые наборы в приказе № 31 в целом приведены в соответствие с составом мер по приказу № 239 — с той разницей, что в № 31 привязка идёт к классам защищённости АСУ (К1/К2/К3), а в № 239 — к категориям значимости объекта КИИ (1/2/3).

Построчное сопоставление обоих приложений не проводилось, поэтому это «единая методологическая логика», а не заявление о полной идентичности оценка. Сам 187-ФЗ и порядок категорирования здесь подробно не раскрываются — они разобраны на отдельных страницах хаба.

«Устанавливаются три класса защищённости автоматизированной системы управления, определяющие уровни защищённости автоматизированной системы управления. Самый низкий класс — третий, самый высокий — первый» (п. 13.2 Требований). Класс определяется в соответствии с приложением № 1 к Требованиям и может устанавливаться отдельно для каждого уровня АСУ или иных сегментов при их наличии; результаты классификации оформляются актом классификации.

Класс защищённости определяется от уровня значимости (критичности) обрабатываемой в АСУ информации (УЗ). УЗ, в свою очередь, задаётся степенью возможного ущерба от нарушения целостности, доступности или конфиденциальности информации, в результате которого возможно нарушение штатного режима функционирования АСУ или незаконное вмешательство в процессы её работы. Степень ущерба — высокая, средняя или низкая — определяется заказчиком или оператором экспертным либо иным методом:

• высокая — возможна ЧС федерального/межрегионального характера (по ПП РФ от 21.05.2007 № 304) или иные существенные негативные последствия;
• средняя — ЧС регионального/межмуниципального характера или умеренные последствия;
• низкая — ЧС муниципального (локального) характера или незначительные последствия.

↔ таблицу можно прокрутить вбок

Если для конкретной информации не требуется обеспечение конфиденциальности, УЗ определяется только по целостности и доступности. При обработке нескольких видов информации (измерительная, о состоянии процесса и т.д.) уровень значимости определяется для каждого вида отдельно, а итоговый УЗ — по наивысшим из полученных значений.

Приложение № 2 к Требованиям задаёт состав мер защиты в виде таблицы «код меры — наименование — К3/К2/К1» с отметками для базового набора каждого класса. Всего групп — 17 (п. 18 Требований):

↔ таблицу можно прокрутить вбок

Наиболее объёмная группа приложения № 2 — ЗИС («Защита информационной (автоматизированной) системы и её компонентов»): 39 позиций, ЗИС.0–ЗИС.39, часть из них не входит в базовый набор ни одного класса и остаётся доступной для адаптации. Построчный подсчёт числа мер по остальным 16 группам для этого материала не выполнялся и здесь не приводится не подтверждено для точных сумм.

Набор мер для конкретной системы собирается не «списком целиком», а по четырёхшаговой логике (п. 19): базовый набор — по классу защищённости АСУ, согласно приложению № 2; адаптация — под уровень АСУ и особенности функционирования, включая исключение мер по неиспользуемым технологиям; уточнение — добавление невыбранных ранее мер, чтобы закрыть все угрозы из модели угроз; дополнение — мерами из других НПА, локальных актов и стандартов.

Если меру реализовать нельзя — в том числе из-за риска для штатного режима функционирования АСУ, — разрабатываются компенсирующие меры, блокирующие ту же угрозу другим способом. В первую очередь в этом качестве рассматриваются меры промышленной и (или) физической безопасности АСУ (пп. 21–22); их достаточность оценивается на приёмочных испытаниях.

Специфика защиты АСУ ТП прямо закреплена в тексте приказа и повторяется трижды: принимаемые меры «не должны оказывать отрицательного влияния на штатный режим функционирования автоматизированной системы управления» (п. 8), система защиты «не должна препятствовать штатному режиму функционирования» АСУ (п. 14), а установленные и настроенные СЗИ «не должны оказывать отрицательного влияния на штатный режим функционирования» (п.

15.4). Тому же подчинён приоритет свойств безопасности: доступность и целостность технологического процесса — в первую очередь, конфиденциальность — при необходимости (п. 8). Это ключевое отличие от защиты офисных ИС и ГИС, где такого явного приоритета непрерывности процесса нет.

Отсюда и порядок выбора средств защиты: «в качестве средств защиты информации в первую очередь подлежат рассмотрению механизмы защиты (параметры настройки) штатного программного обеспечения автоматизированной системы управления при их наличии» (п. 24) — сначала штатные настройки безопасности SCADA-ПО или иного промышленного ПО, и только при их недостаточности — отдельные наложенные средства защиты.

Если в АСУ используются сертифицированные по требованиям безопасности средства защиты информации, для них действуют требования к классу защиты и уровню доверия — в действующей редакции приказа № 46 от 15.03.2021:

↔ таблицу можно прокрутить вбок

Уровни доверия определяются по Требованиям, утверждённым приказом ФСТЭК России от 02.06.2020 № 76 (Минюст 11.09.2020, № 59772). Формулировка «в случае использования сертифицированных СЗИ» означает, что сертификация не абсолютное требование ко всем средствам защиты АСУ ТП вне контекста — в отличие от более строгих требований к значимым объектам КИИ по приказу № 239.

В любом случае применяемые средства защиты должны обеспечивать выполнение самих Требований — то есть нужные функции безопасности независимо от формального статуса сертификации.

Работы по защите информации в АСУ проводит заказчик, оператор и (или) разработчик самостоятельно и (или) с привлечением организаций с лицензией на деятельность по технической защите конфиденциальной информации по 99-ФЗ (п. 9) — лицензия ТЗКИ нужна не владельцу АСУ автоматически, а привлекаемой сторонней организации.

«По решению заказчика подтверждение соответствия системы защиты автоматизированной системы управления техническому заданию... а также настоящим Требованиям может проводиться в форме аттестации автоматизированной системы управления на соответствие требованиям по защите информации. В этом случае для проведения аттестации применяются национальные стандарты, а также методические документы ФСТЭК России» (п. 15.8). Ключевое слово здесь — «может»: аттестация не обязательна, а опциональна.

Без формальной аттестации ввод АСУ в действие возможен и по положительному заключению в акте приёмки — по результатам приёмочных испытаний. Это прямо контрастирует с порядком для значимых объектов КИИ: там по приказу № 235 создание системы безопасности и подтверждение её соответствия — процесс с более жёстко формализованными требованиями. Общий разбор процедур подтверждения соответствия — на странице «Аттестация объектов информатизации».

Приказ прямо перечисляет пять стадий работ по защите АСУ (п. 12):

↔ таблицу можно прокрутить вбок

Практический чек-лист для проекта по приказу № 31:

• Проверить статус объекта по 187-ФЗ. Если АСУ ТП — субъект критической информационной инфраструктуры, пройти категорирование и выяснить, применяется ли приказ № 31 или вместо него — приказы № 239 и № 235.
• Определить класс защищённости. Оценить степень возможного ущерба по целостности, доступности и конфиденциальности, определить УЗ и присвоить класс К1/К2/К3, оформить акт классификации.
• Разработать модель угроз с учётом банка данных угроз ФСТЭК и требуемого классом потенциала нарушителя — подробнее на странице «Модель угроз».
• Собрать состав мер защиты по четырёхшаговой логике — базовый набор, адаптация, уточнение, дополнение (раздел выше).
• В первую очередь оценить штатные механизмы защиты промышленного ПО и только затем — наложенные средства защиты, не создающие рисков для технологического процесса.
• Провести испытания и решить вопрос аттестации. Обязательный минимум — приёмочные испытания и акт приёмки; аттестация — по отдельному решению заказчика.

Ориентировочное продуктовое покрытие части мер по приказу № 31 в каталоге SecRadar: ИАФ и УПД — классы «СЗИ от НСД» и «IdM/IAM»; СОВ и часть ЗИС — классы «IDS/IPS» и «NGFW» (для промышленных сетей часто нужны версии под протоколы АСУ ТП — Modbus, OPC); АВЗ — класс «Антивирус» без задержек в реальном времени; ИНЦ и АУД — класс «SIEM».

Это ориентир для подбора, а не готовая рекомендация — набор мер определяется индивидуально оценка.