Судьба требований ГОСТ 34-й серии в проектах по информационной безопасности

Что в 2020 году подразумевает требование «проектировать по ГОСТу», становится ли оно менее обязательным? Что делать, если государственный регулятор не предлагает замену для ГОСТов 34-й серии? И вообще, какими стандартами стоит руководствоваться при оформлении проектной документации? Отвечает Николай Зенин, специалист с 12-летним опытом формирования таких требований.

Введение

Проблематика

К 2020 году складывается впечатление, что требование «проектировать по ГОСТу» постепенно становится всё менее обязательным, а замены для ГОСТов 34-й серии государственным регулятором не предлагается. Поэтому при формировании требований к разработке технических документов, принятии решения о содержании и оформлении проектной документации возникает вопрос: «какими стандартами следует руководствоваться?».

На этот и другие вопросы отвечает специалист с 12-летним опытом формирования требований и разработки комплектов проектной документации на создание и модернизацию систем защиты информации, информационных систем в государственных органах, организациях различных направлений деятельности (ТЭК, финансовая сфера, системные интеграторы).

Терминология

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

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

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

Основным стандартом, определяющим последовательность работ по созданию автоматизированных систем, является ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания», введённый в действие с 01.01.1992 взамен предыдущего принятого Госстандартом СССР ГОСТа 1986 года и с тех пор так и не подвергавшийся обновлению. Стандартом ГОСТ 34.601-90 определено 8 стадий создания автоматизированных систем, но по сложившейся практике выполнения проектов эти стадии объединяются, и работы выполняются в 3-6 этапов:

• Предпроектный этап. На данном этапе заказчики самостоятельно определяют технические требования к системе и размещают заказы на закупку. Ему соответствует стадия 1 «Формирование требований к АС» (согласно ГОСТ 34.601-90).
• Обследование. На этом этапе привлечённый исполнитель обследует инфраструктуру заказчика и нормативную документацию, определяет угрозы безопасности информации, подготавливает отчёт об обследовании, модель угроз и комплект организационно-распорядительной документации (согласование которой может продолжаться в течение последующих стадий проекта). Этапу соответствует стадия 2 «Разработка концепции АС» (согласно ГОСТ 34.601-90).
• Техническое задание. На данном этапе выполняется разработка и утверждение технического задания на создание системы, что соответствует стадии 3 «Техническое задание» по ГОСТ 34.601-90. Часто этапы «Обследование» и «Техническое задание» объединяют.
• Технорабочее проектирование. На этом этапе исполнитель разрабатывает комплект документации технического проекта, рабочей документации (включая эксплуатационную), программу и методику испытаний. Этапу соответствуют стадия 4 «Эскизный проект», стадия 5 «Технический проект» и стадия 6 «Рабочая документация» (согласно ГОСТ 34.601-90).
• Ввод в действие. На данном этапе выполняются пусконаладочные работы, подготовка персонала, проводятся испытания системы и — при необходимости — аттестация системы по требованиям безопасности информации. Ему соответствует стадия 7 «Ввод в действие» (согласно ГОСТ 34.601-90).
• Эксплуатация и сопровождение. На этом этапе выполняются работы в соответствии с гарантийными обязательствами, а также послегарантийное обслуживание. Этап продолжается до вывода системы из эксплуатации. Ему соответствует стадия 8 «Сопровождение АС» (согласно ГОСТ 34.601-90).

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

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

Состав ГОСТов 34-й серии

Под основными стандартами разработки технической документации на автоматизированные системы понимаются:

• ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем»;
• ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;
• ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»;
• РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов»;
• ЕСКД (ГОСТ 2) «Единая система конструкторской документации»;
• ЕСПД (ГОСТ 19) «Единая система программной документации».

Первые три стандарта, руководящий документ (РД) и ранее рассмотренный ГОСТ 34.601-90 образуют «костяк» требований ГОСТов 34-й серии. Состав документов технического проекта определён стандартом ГОСТ 34.201-89 (действующий). Содержание отдельных документов (технического задания, программы и методики испытаний) определены ГОСТ 34.602-89 и ГОСТ 34.603-92 соответственно (действующие).

Содержание каждого разрабатываемого документа технорабочей документации ранее определялось руководящим документом РД 50-34.698-90, и наступил бы его 30-летний юбилей, но действие данного документа на территории Российской Федерации было отменено приказом Федерального агентства по техническому регулированию и метрологии (Росстандарта) от 12.02.2019 №216, а нового руководящего документа взамен РД (на момент его отмены) не предложено.

«Программой национальной стандартизации в 2019 году», утверждённой приказом Росстандарта от 01.11.2018 №2286, запланирована разработка в том числе документа «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов», заменяющего РД 50-34.698-90 (плановая дата утверждения — 30.03.2021). Но до наступления этого момента мы не имеем действующего на территории Российской Федерации руководящего (методического) документа, определяющего содержание каждой части комплекта технорабочей документации.

Согласно разъяснениям Росстандарта содержание каждого документа, разрабатываемого при проектировании автоматизированных систем согласно ГОСТ 34.201-89, теперь определяет сам разработчик.

Рассматриваемые вопросы

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

• В чём суть требований ГОСТ 34 и какова их польза?
• Что устарело в ГОСТ 34 и почему он всё ещё действует?
• Чем заполнить пустоту в связи с отменой РД 50-34.698-90 и какими требованиями следует руководствоваться при проектировании систем в 2020 году?
• Какие требования ГОСТ 34 обязательны?
• Как оптимизировать трудозатраты, проектируя по ГОСТ 34?

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

В чём суть требований ГОСТ 34 и какова их польза?

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

• стадии проекта создания системы;
• состав проектной документации;
• содержание проектной документации;
• оформление проектной документации;
• последовательность приёмки системы.

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

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

Что устарело в ГОСТ 34 и почему он всё ещё действует?

Конечно, стандарты 30-летней давности морально устарели, в них заложены архаичные представления об архитектуре автоматизированной системы. Наиболее богатым артефактами такого рода был недавно отменённый РД 50-34.698-90 (который определял содержание проектной документации).

В структуре требований ГОСТ 34 к проектированию предусмотрено указание сведений о расположении технических средств, о физическом подключении компонентов, о наличии программных средств, баз данных, клиент-серверных взаимодействий; однако не предусмотрены ни элементы сетевой модели OSI (в каких таблицах ведётся учёт IP-адресов и VLAN), ни технологии виртуализации, ни облачные вычисления, не говоря уже о современных тенденциях развития информационных технологий.

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

За последние несколько лет были приняты изменения ГОСТов в части оформления (новые ГОСТ Р 2.105-2019, ГОСТ Р 2.106-2019 — по оформлению ЕСКД, ГОСТ 7.32-2017 — по оформлению отчёта о научно-исследовательской работе).

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

Чем заполнить пустоту в связи с отменой РД 50-34.698-90 и какими требованиями следует руководствоваться при проектировании систем в 2020 году?

Во-первых, требования ГОСТов 34-й серии (в частности — ГОСТ 34.201-89, определяющего виды документов, и ГОСТ 34.602-89, определяющего содержание технического задания на создание системы) остаются действующими. Таким образом, после отмены РД 50-34.698-90 не произошло отказа от всей системы стандартов ГОСТ 34-й серии. Изменилась только ситуация с наличием действующего регламента по содержанию документации. Действительно, РД 50-34.698-90 нуждался в серьёзной переработке, поскольку был рассчитан на применение устаревших методов обработки информации. Оставшиеся действующими документы определяют структуру всей системы документации и содержание основных проектных документов, в том числе — технического задания.

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

• ГОСТ Р 51583-2014 «Защита информации. Порядок создания автоматизированных систем в защищённом исполнении. Общие положения»;
• приказ ФСТЭК России от 11.02.2013 №17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»;
• постановление Правительства Российской Федерации от 06.07.2015 №676 (в редакции от 07.08.2019) «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации».

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

В-третьих, стандарты на разработку технической документации носят рекомендательный характер и не являются обязательными в общем случае. Заказчик вправе выбирать набор требований к разработке документации.

Таким образом, требования к составу проектной документации остаются прежними (как и в предыдущие 30 лет), а требования к содержанию документации определяет разработчик.

Хорошо, если имеется отраслевой стандарт или внутри организации заказчика системы утверждён стандарт корпоративный, определяющий правила изложения и оформления документации технического проекта. В качестве основы для подготовки такого стандарта хорошо подходят требования РД 50-34.698-90 вместе с ГОСТ 34.201-89 (в качестве мастер-таблицы), если убрать из них ненужные документы и разделы.

Заказчику, приступающему к созданию системы по ГОСТ 34 в отсутствие корпоративного стандарта организации, следует в технических требованиях на проектирование системы вместо привычной ссылки на РД 50-34.698-90 указывать (цитатами из руководящего документа) конкретные требования к содержанию разрабатываемых документов. Например: «Пояснительная записка к техническому проекту (П2), содержащая разделы: “Общие положения”, “Описание процесса деятельности”, “Основные технические решения”, “Мероприятия по подготовке объекта автоматизации к вводу системы в действие”». Разработчик, увидев требования (в данном случае процитированные не из ГОСТ 2.120-2013 ЕСКД / ГОСТ 19.404-79 ЕСПД, а именно из ранее действующего РД 50-34.698-90), должен из соображений здравого смысла и своего опыта разработки подготовить документацию по ГОСТ 34.

Какие требования ГОСТ 34 обязательны?

В соответствии с Федеральным законом от 29.06.2015 №162-ФЗ «О стандартизации в Российской Федерации» добровольность применения документов по стандартизации является одним из её принципов (статья 4). ГОСТ становится обязательным только если это установлено Федеральным законом (не случай с ГОСТ 34) либо если изготовитель / исполнитель заявляет о применении национального стандарта (статья 26 вышеуказанного 162-ФЗ).

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

• технического задания на создание подсистемы безопасности;
• модели угроз безопасности информации;
• документации на систему (проектной документации);
• рабочей (эксплуатационной) документации.

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

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

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

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

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

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

Как оптимизировать трудозатраты, проектируя по ГОСТ 34?

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

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

Состав документации, определённый в ГОСТ 34.201-90, избыточен (содержит исчерпывающий набор на все возможные случаи и был сформирован для устаревшей архитектуры систем). Среди предложенных документов исходя из специфики задачи могут быть выбраны наиболее подходящие. Если требования заказчика не вполне определены, автор статьи рекомендует присмотреться к одному из предложенных в таблице 2 наборов (1…5) документации, описываемой ГОСТами 34-й серии, в качестве рекомендации, от которой можно далее отталкиваться.

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