Автор: Зенин Николай Николаевич, главный архитектор проектов компании Angara Technologies Group.
1 Введение
1.1 Проблематика
Данная статья призвана прояснить основные особенности применения отечественных стандартов на разработку документации технического проекта. К 2020 году складывается впечатление, что требование «проектировать по ГОСТу» постепенно становится все менее обязательным, а замены ГОСТ 34 серии государственным регулятором не предлагается. Поэтому при формировании требований к разработке технической документации, принятии решения о содержании и оформлении проектной документации возникает вопрос: «Какими стандартами следует руководствоваться?».
На этот и другие вопросы отвечает автор статьи с 12-летним опытом формирования требований и разработки комплектов проектной документации на создание и модернизацию систем защиты информации, информационных систем в государственных органах, организациях различных направлений деятельности (ТЭК, финансовая сфера, системные интеграторы).
1.2 Терминология
Для упрощения применяемой терминологии часть понятий в данной статье объединены (в случаях, где не требуется разделение понятий):
¾ под «созданием системы» автор подразумевает как проекты создания, так и проекты модернизации (доработки) системы;
¾ под «системой» автор подразумевает как автоматизированные системы (состоящие из персонала, информации, комплекса технических и программных средств автоматизации целевой деятельности), так и информационные системы (аналогично автоматизированным системам, но без персонала), системы защиты информации;
¾ под «системой защиты информации» автор подразумевает как, собственно, систему/подсистему защиты информации в соответствии с нормативными требованиями, так и системы/подсистемы информационной безопасности (в отличие от «защиты информации», термин «информационная безопасность» часто подразумевает послабление применяемых нормативных требований).
1.3 Состав работ по созданию систем
Основным стандартом, определяющим последовательность работ по созданию автоматизированных систем, является ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания», введенный в действие с 01.01.1992 взамен предыдущего принятого Госстандартом СССР ГОСТа 1986 года и с тех пор так и не подвергавшийся обновлению. Стандартом ГОСТ 34.601-90 определено 8 стадий создания автоматизированных систем, но, по сложившейся практике выполнения проектов, стадии объединяются, и работы выполняются в 3-6 этапов:
0) Предпроектный этап. На данном этапе Заказчик самостоятельно определяет технические требования к системе и размещает заказ на закупку. Этапу соответствует стадия 1. Формирование требованиям к АС (согласно ГОСТ 34.601-90).
1) Этап «Обследование». На данном этапе привлеченный исполнитель обследует инфраструктуру Заказчика и нормативную документацию, определяет угрозы безопасности информации, подготавливает Отчет об обследовании, Модель угроз, комплект организационно-распорядительной документации (согласование которой может продолжаться в течение последующих стадий проекта). Этапу соответствует стадия 2. Разработка концепции АС (согласно ГОСТ 34.601-90).
2) Этап «Техническое задание». На данном этапе выполняется разработка и утверждение технического задания на создание системы, что соответствует стадии 3. Техническое задание по ГОСТ 34.601-90. Часто этапы «Обследование» и «Техническое задание» объединяют в один этап.
3) Этап «Технорабочее проектирование». На данном этапе исполнитель разрабатывает комплект документации технического проекта, рабочей документации (включая эксплуатационную документацию), программу и методику испытаний. Этапу соответствуют стадии 4. Эскизный проект, 5. Технический проект, 6. Рабочая документация (согласно ГОСТ 34.601-90).
4) Этап «Ввод в действие». На данном этапе выполняются пуско-наладочные работы, подготовка персонала, проводятся испытания системы и, при необходимости, аттестация системы по требованиям безопасности информации. Этапу соответствует стадия 7. Ввод в действие (согласно ГОСТ 34.601-90).
5) Этап «Эксплуатация и сопровождение». На данном этапе выполняются работы в соответствии с гарантийными обязательствами и послегарантийное обслуживание. Этап продолжается до вывода системы из эксплуатации. Этапу соответствует стадия 8. Сопровождение АС (согласно ГОСТ 34.601-90).
Отдельных комментариев в терминах настоящей статьи заслуживает этап «Технорабочее проектирование». На этом этапе разрабатываются два важных блока документации:
¾ Проектные решения (технический проект иногда называют «документацией на систему», документацией стадии «П»). Данный блок описывает будущую систему в терминах принятых архитектурных и технических решений. Предварительную стадию эскизного проектирования автор статьи умышленно пропустил, поскольку она является упрощенной версией стадии «П».
¾ Рабочая документация. Данный блок содержит настройки для успешного развертывания и ввода в действие системы, а также эксплуатационную документацию (для дальнейшей эксплуатации системы).
1.4 Состав ГОСТов 34 серии
Под основными стандартами разработки технической документации на автоматизированные системы понимаются:
а) ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем»;
б) ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;
в) ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»;
г) РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов»;
д) ЕСКД (ГОСТ 2) «Единая система конструкторской документации»;
е) ЕСПД (ГОСТ 19) «Единая система программной документации».
Первые 3 стандарта, руководящий документ (РД) и ранее рассмотренный ГОСТ 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, теперь определяет сам разработчик.
1.5 Рассматриваемые вопросы
Руководители подразделений информационной безопасности, подразделений информационных технологий задаются вопросами, на которые автор статьи постарается ответить:
1) В чем суть требований ГОСТ 34 и какова их польза?
2) Что устарело в ГОСТ 34 и почему он все еще действует?
3) Чем заполнить пустоту в связи с отменой РД 50-34.698-90 и какими требованиями следует руководствоваться при проектировании систем в 2020 году?
4) Какие требования ГОСТ 34 обязательны?
5) Как оптимизировать трудозатраты, проектируя по ГОСТ 34?
2 Практика применения требований ГОСТ 34
2.1 В чем суть требований ГОСТ 34 и какова их польза?
ГОСТы 34 серии и связанные с ними стандарты регламентируют следующие 5 основных областей требований к проектированию систем:
1) стадии проекта создания системы;
2) состав проектной документации;
3) содержание проектной документации;
4) оформление проектной документации;
5) последовательность приемки системы.
ГОСТы на техническую документацию вводят глоссарий, содержат примеры оформления, описывают технологический процесс, содержат хорошо продуманную структуру этапов разработки и компонентов документации, обладая полнотой и, по большей части, непротиворечивостью требований, содержат хорошо узнаваемые разработчиками разделы технической документации, коррелируют с западными стандартами разработки документации, но при этом являются русскоязычными документами с большой практикой применения. Автор статьи полагает, что пройдут еще десятки лет, мы станем разрабатывать более удобные в обращении документы, но сформированная когда-то «правильная» структура документации по ГОСТ 34 серии и сложившаяся терминология будут оставаться узнаваемыми.
Своды знаний, содержащиеся в ГОСТах, основаны на результатах исследований, на международных стандартах и на практическом опыте. Даже организациям, которым не требуется следовать во всем ГОСТу, стандарты разработки технической документации будут полезны в качестве чек-листа для проверки, «все ли продумано перед созданием системы?». Применение ГОСТов позволяет снизить риски, связанные с упущениями при проектировании, позволяет выставлять разработчикам требования на понятном языке.
2.2 Что устарело в ГОСТ 34 и почему он все еще действует?
Конечно, стандарты 30-летней давности морально устарели, в них заложены архаичные представления об архитектуре автоматизированной системы. Наиболее богат артефактами такого рода был недавно отмененный РД 50-34.698-90 (который определял содержание проектной документации).
В структуре требований ГОСТ 34 к проектированию предусмотрено указание сведений о расположении технических средств, о физическом подключении компонентов, о наличии программных средств, баз данных, клиент-серверных взаимодействий; однако не предусмотрены ни элементы сетевой модели OSI (в каких таблицах ведется учет IP-адресов и VLAN), ни технологии виртуализации, ни облачных вычислений, не говоря уже о современных тенденциях развития информационных технологий.
Четыре из рассмотренных выше 5 основных областей требований к проектированию систем (стадии создания, состав документации, оформление и приемка) по-прежнему регламентируются действующими ГОСТ 34 и связанными с ними национальными стандартами.
За последние несколько лет были приняты изменения ГОСТ в части оформления (новые ГОСТ Р 2.105-2019, ГОСТ Р 2.106-2019 – по оформлению ЕСКД, ГОСТ 7.32-2017 – по оформлению отчета о научно-исследовательской работе).
Остальные ГОСТ 34 серии по-прежнему действуют и являются стандартом технического проектирования при создании систем на том основании, что принятые 30 лет назад стандарты не были ни отменены, ни заменены.
2.3 Чем заполнить пустоту в связи с отменой РД 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.
2.4 Какие требования ГОСТ 34 обязательны?
В соответствии с Федеральным законом от 29.06.2015 №162-ФЗ «О стандартизации в Российской Федерации», добровольность применения документов по стандартизации является одним из принципов стандартизации (статья 4). ГОСТ становится обязательным, только если это установлено Федеральным законом (не случай с ГОСТ 34), либо если изготовитель / исполнитель заявляет о применении национального стандарта (статья 26 вышеуказанного 162-ФЗ).
Есть особые случаи, в которых предъявляются требования по созданию автоматизированных систем в защищенном исполнении, созданию государственных информационных систем, по защите персональных данных, защите автоматизированных систем управления технологическими процессами, обеспечению безопасности критической информационной инфраструктуры, аттестации автоматизированных систем по требованиям безопасности информации. Нормативными требованиями в таких случаях предусматривается разработка:
¾ технического задания на создание подсистемы безопасности;
¾ модели угроз безопасности информации;
¾ документации на систему (проектной документации);
¾ рабочей (эксплуатационной) документации.
В данных случаях необходимо руководствоваться требованиями ГОСТ 34, даже если в современных трактовках вышеуказанных нормативных требований к разработке документации не употребляется прямая отсылка к ним, а, например, указываются цитаты из ГОСТ 34 серии:
¾ документация на систему (проектные решения) должна быть «в объеме, необходимом для описания полной совокупности проектных решений (в том числе по защите информации) и достаточном для дальнейшего выполнения работ по созданию системы»;
¾ рабочая документация должна содержать «сведения, необходимые для выполнения работ по поддержанию уровня эксплуатационных характеристик (качества) системы (в том числе по защите информации)».
Для защиты проектных решений (созданной системы) перед государственным регулятором потребуется доказывать наличие в документации соответствующих сведений (требования к содержанию).
В Таблице в 1 обзорно приводится, какие из 5 рассмотренных основных областей требований к проектированию систем по ГОСТ 34 становятся обязательными.
Таблица 1 — Обязательность отдельных областей требований к документации
В итоге, ГОСТ 34 носит рекомендательный характер только в общем случае, и организациям было бы совсем не лишним воспользоваться его рекомендациями при проектировании систем.
2.5 Как оптимизировать трудозатраты, проектируя по ГОСТ 34?
Если Вы приступаете к самостоятельной разработке проектной документации по ГОСТ 34 (в рамках создания или модернизации системы) либо оформляете технические требования для размещения на портале закупок, необходимо определить требования к разработке документации (состав, содержание и оформление разрабатываемой документации).
2.5.1 Состав документации
Состав документации, определенный в ГОСТ 34.201-90, – избыточен (содержит исчерпывающий набор документации на все случаи и был сформирован для устаревшей архитектуры систем). Среди предложенных документов могут быть выбраны наиболее подходящие исходя из специфики задачи. Если требования заказчика не вполне определены, автор статьи рекомендует присмотреться к одному из предложенных в Таблице 2 наборов (1…5) документации, описываемой ГОСТами 34 серии, в качестве рекомендации, от которой можно далее отталкиваться.
Таблица 2 — Рекомендуемые наборы документации
Коды документов в Таблице 2 приведены в соответствии с ГОСТ 34.201-90. Акты, протоколы, приказы, эскизный проект и редко разрабатываемые документы (из списка 58 документов ГОСТ 34.201-90) – не учитывались в данной таблице.
Набору 1 соответствует практическое отсутствие документации технического проекта (но техническое задание и программа испытаний должны быть в каком-то виде).
Набору 2 соответствует минимальный состав документации (технический проект представлен пояснительной запиской, а эксплуатационная документация – руководством пользователя).
Набору 3 соответствует оптимальный состав документации технорабочего проекта.
Набору 4 соответствует расширенный состав документации, когда технорабочий проект должен быть всесторонне проработан.
Набор 5 редко требуется в таком широком составе, даже для аттестации систем.
Выдвигая требования к составу документации, важно представлять, какими силами будет осуществляться разработка. Несмотря на кажущееся многообразие предложений, свободных технических писателей надлежащего уровня не так просто найти на рынке.
2.5.2 Содержание документации
Требования к содержанию документации пошатнулись с отменой РД 50-34.698-90, поэтому данный вопрос при подготовке к проектированию должен быть проработан. Теперь в технических требованиях на проектирование системы вместо привычной когда-то ссылки на РД 50-34.698-90 следует указывать (цитатами из руководящего документа) конкретные требования к содержанию разрабатываемых документов (например, документ «Пояснительная записка к техническому проекту» (П2), содержащая разделы: «Общие положения», «Описание процесса деятельности», «Основные технические решения», «Мероприятия по подготовке объекта автоматизации к вводу системы в действие»). Разработчик, увидев требования, в данном случае процитированные из ранее действующего РД 50-34.698-90, должен, из соображений здравого смысла и своего опыта разработки, подготовить документацию по ГОСТ 34.
Указывая на необходимость разработки модели угроз (определения угроз безопасности информации), можно сослаться либо на базу данных угроз ФСТЭК, либо на ГОСТ Р 56546-2015 «Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем».
Разработчику технической документации необходимо вести несколько справочников, отражающих проектные характеристики, и на которых будет основываться разрабатываемая документация:
¾ Справочник требований. Должен быть четко описан переход конкретных требований к результатам. Предпроектные технические требования после запуска проекта должны превратиться в техническое задание (внесением уточнений по результатам обследования и определения угроз), а решения технического проекта должны стать подтверждением перехода от требований «должен» к «решено»:
1) Технические требования (предпроектный этап) →
2) Модель защиты (выводы по результатам обследования и из модели угроз) →
3) Техническое задание (описывает, как должно быть) →
4) Технический проект (решения, принятые при проектировании) →
5) Рабочая документация (описывает реализованные решения и настройки).
¾ Перечни решений и изменений. Должны содержать категории защищаемой информации, списки автоматизируемых бизнес-процессов, списки ролей и полномочий (должностных обязанностей) пользователей, списки подразделений и организаций, их роли в проекте.
¾ Справочник объектов автоматизации (объектов защиты). Должен содержать перечни физических адресов, помещений (площадок), сегментов сети, оборудования, адресов и сетевых имен.
¾ Номенклатурный справочник. Должен содержать принятую в рамках проекта единую терминологию, правила наименования объектов автоматизации, перечень применимых нормативных документов и требований.
Созданная система справочных данных должна лечь в основу разрабатываемой документации. Это поможет избежать типичной ошибки при проектировании, когда структура документации пере-согласовывается и переделывается многократно по ходу проекта.
2.5.3 Оформление документации
Стандартом оформления технической документации принято считать ЕСКД (ГОСТ 2) «Единая система конструкторской документации».
Согласно РД 50-34.698-90 (на настоящий момент отмененному), документацию технического проекта (строки 5-26 в Таблице 2) выполняют по ГОСТ 2.105 и ГОСТ 2.106, которыми установлены требования к оформлению текстовых документов и чертежей на листах формата по ГОСТ 2.301, включая рамку по границам листа, с надписью внизу рамки по ГОСТ 2.104 и с кодом документа по ГОСТ 34.201-89.
Оформление документов в рамке по границам листа – в свое время было замечательным решением для обеспечения бумажного документооборота (всегда можно было определить принадлежность листа документа к конструкторской документации и место любого листа по уникальной комбинации кода документа и номера листа). Но с переходом к электронному документообороту требования к наличию рамок стали менее актуальными. Если заказчик разработки документации считает, что рамки по границе листа затрудняют восприятие документа, от них можно отказаться, не нарушая требований ГОСТ. Для этого в заказе на разработку документации необходимо указать: «без рамки», – например, в такой формулировке: «Документация оформляется в соответствии с требованиями ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа». В таком случае технорабочая документация будет выполнена так же, как подготавливается техническое задание – без рамки (что удобно для электронного документооборота).
ГОСТ 2.105, новая редакция которого вышла в 2019 году (вступление в силу отложено Приказом Росстандарта от 30.01.2020 №19-ст на 01.07.2020), содержит общие требования к текстовым документам. Для производства профессионально составленной документации разработчикам (техническим писателям) рекомендуется применять соответствующие ГОСТ рекомендации специализированных руководств, одним из наиболее заслуженных среди которых считается «Справочник издателя и автора» (Мильчин А.Э, Чельцова Л.К.), – пятое издание 2018 года.
3 Заключение
Итого, по результатам рассмотрения требований ГОСТ 34 серии, мы приходим к заключению, что требования ГОСТ имеют рекомендательный характер, их очень желательно применять как минимум в качестве чек-листа. Кажущиеся жесткими формулировки, ориентированные на архаические представления систем, не требуют обязательного исполнения. Среди требований ГОСТ содержатся важные структурообразующие элементы, умелое применение которых позволит сэкономить много сил, – как звучит в древнем высказывании: «Если притупится топор, и если лезвие его не будет отточено, то надобно будет напрягать силы; мудрость умеет это исправить».
Применяйте ГОСТ со здравым смыслом!