Зенин Николай Николаевич

главный архитектор проектов
компании Angara Security

Традиционно разработчики документации на автоматизированные системы при создании и обеспечении защиты этих систем применяли ГОСТы 34-й серии. С 2022 года наконец-то произошло обновление старых стандартов в рамках новой серии национальных и межгосударственных стандартов на автоматизированные системы (далее — ГОСТ на автоматизированные системы).

В этой статье мы проясним основные особенности применения ГОСТ на автоматизированные системы, а также разберемся в изменениях, которые произошли в 2022 году.

Состав ГОСТов на автоматизированные системы

С первой половины 2022 года вступили в действие новые стандарты (пункты 1–6) согласно Таблице 1.

Таблица 1 — Перечень действующих стандартов.

Комплекс стандартов на автоматизированные системы вводит глоссарий, содержит примеры оформления, описывает технологический процесс, содержит продуманную структуру этапов разработки и хорошо узнаваемые разработчиками разделы технической документации.

Своды знаний, содержащиеся в ГОСТах, основаны на результатах исследований, на международных стандартах и на практическом опыте. Даже организациям, которым не требуется следовать во всем ГОСТу, стандарты разработки технической документации будут полезны в качестве чек-листа для проверки, «все ли продумано перед созданием системы?». Применение ГОСТов позволяет снизить риски, связанные с упущениями при проектировании, позволяет выставлять разработчикам требования на понятном языке.

Среди перечисленных стандартов наибольшее внимание в статье будет уделено двум из них, регламентирующим состав и содержание документации технического проекта:

• ГОСТ 34.201–2020 (взамен ГОСТ 34.201–89), определяющий состав документов технического проекта;

• ГОСТ Р 59795–2021 (взамен руководящего документа РД 50–34.698–90), определяющий содержание каждого разрабатываемого документа технорабочей документации.

Основные изменения стандартов

Основополагающие в проектировании автоматизированных систем стандарты, разработанные еще в 1989–1992 годах, не подвергались пересмотру 30 лет и, естественно, утратили свою актуальность. Они уже не учитывали современных тенденций развития технологий. Например, с тех времен, когда документы отчерчивали на кульмане, в составе проектной документации было принято разрабатывать «Чертеж формы документа (видеокадра)», а для хранения данных в картотеках с полу автоматизированной обработкой формировался «Каталог базы данных». Был непонятен статус старых стандартов (ведь было принято переиздавать стандарты как минимум раз в 10 лет, но этого не происходило).

И вот, наконец-то стандарты пересмотрены, переизданы и введены в действие.

• Кардинально изменилась ситуация неопределенности требований к содержанию технорабочей документации, возникшая с момента отмены в 2019 году методических рекомендаций РД 50–34.698–90. Теперь требования к содержанию документации регламентированы ГОСТ Р 59795–2021.

• Стали более четкими формулировки ГОСТ 34.201–2020, введенного взамен ГОСТ 34.201–89 (который устанавливал наименование, комплектность и обозначение документов), теперь устанавливает требования к видам, наименованию, комплектности и обозначению документов. Таким образом, новые требования к наименованию и содержанию документов ГОСТ на автоматизированные системы перешли из разряда методических рекомендаций в разряд требований.

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

• Ведомость машинных носителей информации (ВМ);

• Состав выходных данных (сообщений) (В8), при этом оставлен документ «Перечень выходных сигналов (документов)» (В2);

• Инструкция по формированию и ведению базы данных (набора данных) (И4).

Остальные 55 документов, 4 из которых — с измененными формулировками (например, вместо «Чертеж формы документа (видеокадра)» — теперь «Шаблон документа», вместо «Каталог базы данных» — «Описание базы данных»), оставлены в перечне документов по ГОСТ 34.201–2020.

Состав работ по созданию систем

Основной стандарт, определяющий последовательность работ по созданию автоматизированных систем, — это ГОСТ Р 59793–2021 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания» (принят взамен ГОСТ 34.601–90). Данным стандартом определено 8 стадий создания автоматизированных систем, но, по сложившейся практике выполнения проектов, стадии объединяются, и работы выполняются в несколько этапов, перечисленных в Таблице 2.

Таблица 2 – Стадии работ по созданию системы.

Для упрощения применяемой терминологии часть понятий в данной статье объединены (в случаях, где не требуется разделение понятий):

• под «созданием системы» подразумеваются как проекты создания, так и проекты модернизации (доработки) системы;

• под «системой» подразумеваются как автоматизированные системы (состоящие из персонала, информации, комплекса технических и программных средств автоматизации целевой деятельности), так и информационные системы (аналогично автоматизированным системам, но без персонала), системы защиты информации;

• под «системой защиты информации» подразумеваются как, собственно, система/подсистема защиты информации в соответствии с нормативными требованиями, так и системы/подсистемы информационной безопасности (в отличие от «защиты информации», термин «информационная безопасность» часто подразумевает послабление применяемых нормативных требований).

Отдельных комментариев заслуживают стадии: 1. «Формирование требований к АС», 3. «Техническое задание», 4-6, объединенные в этап работ на практике 3) «Технорабочее проектирование». Разберем их подробнее.

Техническое задание

Может возникать путаница в обозначении того, что считается Техническим заданием (Частным техническим заданием):

• На стадии 1. «Формирование требований к АС» для публикации на портале закупок или модернизации существующей системы подготавливается документ с требованиями к системе, называемый по сложившейся практике «Техническим заданием». Однако, документ, создаваемый на данной стадии, остается только лишь требованиями пользователя к системе, и Техническим заданием не является.

• На стадии 3. «Техническое задание» разрабатывается Техническое задание на систему, которое является Техническим заданием по ГОСТ на автоматизированные системы.

На стадии 3. «Техническое задание» определяются требования к системе в целом. На основании требований о защите информации государственных информационных систем, значимых объектов критической информационной инфраструктуры, персональных данных, автоматизированных систем управления, утвержденные Постановлением Правительства Российской Федерации от 06.07.2015 №676 и приказами ФСТЭК от 11.02.2013 №17, от 25.12.2017 №239, от 18.02.2013 №21, от 14.03.2014 №31, одновременно с определением требований, определяются и меры защиты информации, применение которых необходимо для нейтрализации актуальных угроз, выявленных по результатам моделирования угроз безопасности информации. Меры защиты включаются в Техническое задание на систему и затем при необходимости могут уточняться в рамках проектирования.

Технорабочее проектирование

На этапе работ «Технорабочее проектирование» разрабатываются два блока документации:

• Проектные решения (технический проект иногда называют «документацией на систему»). Данный блок описывает будущую систему в терминах принятых архитектурных и технических решений. Стадия эскизного проектирования — упрощенная версия технического проекта.

• Рабочая документация. Этот блок содержит настройки для успешного развертывания и ввода в действие системы, эксплуатационную документацию для дальнейшей эксплуатации системы и комплект организационно-распорядительной документации.

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

Практика применения требований ГОСТ на автоматизированные системы

Обязательность применения требований ГОСТ

В соответствии с Федеральным законом от 29.06.2015 №162-ФЗ «О стандартизации в Российской Федерации», добровольность применения документов по стандартизации — один из принципов стандартизации (статья 4).

ГОСТ становится обязательным,

• если это установлено Федеральным законом (в случае защиты государственной тайны или в отношении оборонной продукции (статья 6) — что не является общим случаем для применения ГОСТ на автоматизированные системы);

• если изготовитель/исполнитель принимает на себя требования (например, требования Технического задания) о применении национального/межгосударственного стандарта (статья 26 вышеуказанного 162-ФЗ).

Есть особые случаи, в которых необходимо учитывать требования ГОСТ на автоматизированные системы: создание автоматизированных систем в защищенном исполнении, создание государственных информационных систем, защита персональных данных, защита автоматизированных систем управления технологическими процессами, обеспечение безопасности критической информационной инфраструктуры, аттестация по требованиям безопасности информации. Нормативными требованиями в таких случаях предусматривается разработка:

• Технического задания на создание подсистемы безопасности;

• модели угроз безопасности информации;

• документации на систему (проектной документации);

• рабочей (эксплуатационной) документации.

В данных случаях необходимо руководствоваться требованиями ГОСТ на автоматизированные системы, даже если в современных трактовках вышеуказанных нормативных требований к разработке документации не употребляется прямая отсылка к ним, а, например, указываются цитаты из ГОСТ Р 59793–2021:

• документация на систему (проектные решения) должна быть «в объеме, необходимом для описания полной совокупности проектных решений, достаточном для дальнейшего выполнения работ по созданию системы»;

• рабочая документация должна содержать «все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) АС в соответствии с принятыми проектными решениями».

Так, например, на необходимость учета требований ГОСТ на автоматизированные системы при создании систем указывает действующая нормативная база, в частности:

• ГОСТ Р 51583–2014 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения»;

• Приказ ФСТЭК России от 11.02.2013 №17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»;

• Постановление Правительства Российской Федерации от 06.07.2015 №676 (в редакции от 23.12.2021) «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации».

Последний из указанных нормативных актов не содержит прямого указания на ГОСТ Р 59793–2021, но содержит цитату из него, дополненную требованиями по защите информации: «Этап разработки документации на систему и ее части включает разработку, согласование и утверждение документации в объеме, необходимом для описания полной совокупности проектных решений (в том числе по защите информации) и достаточном для дальнейшего выполнения работ по созданию системы».

ГОСТы на автоматизированные системы и связанные с ними стандарты регламентируют следующие 5 основных областей требований к проектированию систем:

1. стадии проекта создания системы;

2. состав проектной документации;

3. содержание проектной документации;

4. оформление проектной документации;

5. последовательность приемки системы.

В Таблице 3 обзорно приводится, какие из этих областей требований к проектированию систем по ГОСТ на автоматизированные системы обязательны.

Таблица 3 — Обязательность отдельных областей требований к документации.

Состав документации

Если Вы приступаете к разработке проектной документации по ГОСТ на автоматизированные системы (в рамках создания или модернизации системы) либо оформляете требования к системе для размещения заказа на портале закупок, необходимо определить и требования к разработке документации (состав, содержание и оформление разрабатываемой документации).

Полный состав документации, определенный в ГОСТ 34.201–2020, — избыточен. Среди предложенных документов могут быть выбраны наиболее подходящие исходя из специфики задачи. Если требования заказчика не вполне определены, я предлагаю присмотреться к одному из предложенных в Таблице 4 подходу к проектированию (1…5) — набору документации, описываемой ГОСТами на автоматизированные системы. Один из таких подходов можно выбрать и применять в качестве рекомендации, от которой можно далее отталкиваться.

Таблица 4 — Рекомендуемые наборы документации.

Коды документов в Таблице 4 приведены в соответствии с ГОСТ 34.201–2020. Акты, протоколы, приказы, эскизный проект, редко разрабатываемые документы из списка 55 документов по ГОСТ 34.201–2020 не учитывались в данной таблице.

Набору 1 соответствует практическое отсутствие документации технического проекта и обоснования мер защиты на основе модели угроз (но хотя бы Техническое задание и программа испытаний должны присутствовать в каком-то виде).

Набору 2 соответствует минимальный состав документации (технический проект представлен пояснительной запиской, а эксплуатационная документация – руководством пользователя).

Набору 3 соответствует оптимальный состав документации технорабочего проекта, разрабатываемой на практике в проектах создания систем.

Набору 4 соответствует расширенный состав документации, когда технорабочий проект должен быть всесторонне проработан.

Набор 5 редко требуется в настолько широком составе, даже для аттестации систем.

Содержание документации

Требования к содержанию документации установлены ГОСТ Р 59795–2021, на который (вместо РД 50–34.698–90) следует ссылаться при определении технических требований на проектирование системы.

Разработчику технической документации необходимо вести несколько справочников, отражающих проектные характеристики, и на которых будет основываться разрабатываемая документация:

• Справочник объектов автоматизации (объектов защиты). Должен содержать перечни физических адресов, помещений (площадок), сегментов сети, оборудования, адресов и сетевых имен.

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

• Справочник функциональных требований. Должен быть четко описан переход конкретных требований к результатам. Предпроектные технические требования после запуска проекта должны превратиться в Техническое задание (внесением уточнений по результатам обследования и определения угроз), а решения технического проекта должны стать подтверждением перехода от требований «должен» к «решено»: [Технические требования (предпроектный этап)] → [Техническое задание (описывает, как должно быть)] → [Технический проект (решения, принятые при проектировании)] → [Рабочая документация (описывает реализованные решения и настройки)].

• Номенклатурный справочник. Должен содержать принятую в рамках проекта единую терминологию, правила наименования объектов автоматизации, перечень применимых нормативных документов и требований.

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

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

На рынке стали доступны среды автоматического формирования комплектов документации по ГОСТ на автоматизированные системы, включая модель угроз по новым требованиям ФСТЭК. Такие среды опираются в своей работе на систему справочных данных по проекту. Для предприятий мелкого и среднего бизнеса подобная услуга может сэкономить время на подготовку документации, если заказчиком предъявляются только базовые требования к содержанию и оформлению документации.

Оформление документации

Стандартом оформления технической документации принято считать ЕСКД (ГОСТ 2) «Единая система конструкторской документации». Требования к тестовым документам установлены ГОСТ 2.105–2019.

Согласно ГОСТ Р 59795–2021 (строки 4-26 в Таблице 4) оформление технической документации выполняют по ГОСТ 2.105 и ГОСТ 2.106, которыми установлены требования к оформлению текстовых документов и чертежей, включая рамку по границам листа, с надписью внизу рамки по ГОСТ 2.104 и с кодом документа по ГОСТ 34.201–2020.

Ранее требованиями ГОСТ 34.602–89 указывалось, что «ТЗ на АС оформляют… без рамки, основной надписи и дополнительных граф к ней». Однако, вступившим в силу ГОСТ 34.602–2020 данная оговорка заменена на «ТЗ на АС оформляют в виде текстового документа». Таким образом, Техническое задание на систему должно оформляться аналогично технорабочему проекту, в рамке по границам листа (если в заказе на разработку документации не будет указано обратное).

Оформление документов в рамке по границам листа формата по ГОСТ 2.301 — в свое время было замечательным решением для обеспечения бумажного документооборота (всегда можно было определить принадлежность листа документа к конструкторской документации и место любого листа по уникальной комбинации кода документа и номера листа). Но с переходом к электронному документообороту требования к наличию рамок стали менее актуальными. Если заказчик разработки документации считает, что рамки по границе листа затрудняют восприятие документа, от них можно отказаться, не нарушая требований ГОСТ. Для этого в заказе на разработку документации необходимо указать: «без рамки», — например, в такой формулировке: «Документация оформляется в виде текстового документа без рамки, основной надписи и дополнительных граф к ней».

Для производства профессионально составленной документации разработчикам (техническим писателям) рекомендуется применять соответствующие ГОСТ рекомендации специализированных руководств, одним из наиболее заслуженных среди которых считается «Справочник издателя и автора» (Мильчин А.Э, Чельцова Л.К.), — шестое издание 2021 года. 

Отдельных комментариев заслуживает ситуация с санкционными ограничениями и отзывом в 2022 году компанией Monotype возможности доступа на загрузку распространенных шрифтов Times New Roman, Arial с российских IP-адресов. Данное ограничение не запрещает использовать указанные шрифты на территории Российской Федерации, однако подталкивает разработчиков документации к установке и переходу к использованию шрифтов отечественного производства, из которых наибольшую известность заслужили шрифты компании «Паратайп» (Paratype):

• PT Astra Serif – на смену Times New Roman;

• PT Astra Sans – на смену Arial.

Из системы стандартов по информации, библиотечному и издательскому делу (ГОСТ Р 7.0.97-2016) исключены рекомендации по использованию проприетарных шрифтов из состава ОС Windows (Times New Roman, Arial, Courier New, Verdana), а в ГОСТ 2.105-2019 добавлено примечание о том, что применение таких шрифтов может привести к искажениям при отображении этих документов в других операционных системах (например, при переходе на отечественное ПО), в которых эти шрифты отсутствуют в связи с санкционными и лицензионными ограничениями.

Подытожим?

Итого, по результатам рассмотрения требований ГОСТ на автоматизированные системы, мы приходим к заключению, что эти требования обязательны к применению в перечисленных в данной статье в случаях, связанных с защитой информации. Требования содержат важные структурообразующие элементы, умелое применение которых позволит сформировать слаженную систему документации для создания и эксплуатации автоматизированных систем, систем защиты информации.