Этапы развития ракет и ракетной техники
На сегодняшний день Российская Федерация обладает самой мощной в мире космической отраслью. Россия является...
Ниже представлен пример (образец) проектного документа "Пояснительная записка к техническому проекту на создание автоматизированной системы ", основанный на методических указаниях РД 50-34.698-90 . Данный документ формируется IT-специалистом на стадии технического проектирования информационной системы .
В качестве примера разработки информационной системы использован проект внедрения информационно-аналитической системы «Корпоративное хранилище данных» .
На странице ниже приведено содержание пояснительной записки технического проекта в соответствии с ГОСТ, внутри каждого из разделов кратко приведены требования к содержанию и текст примера заполнения (выделяется вертикальной чертой).
Разделы пояснительной записки:
Общие положения
Основные технические решения
Решения по структуре системы, подсистем, средствам и способам связи для информационного обмена между компонентами системы
Решения по взаимосвязям АС со смежными системами, обеспечению ее совместимости
Решения по режимам функционирования, диагностированию работы системы
Решения по персоналу и режимам его работы
Сведения об обеспечении заданных в техническом задании потребительских характеристик системы, определяющих ее качество
Состав функций, комплексов задач реализуемых системой
Состав и размещение комплексов технических средств
Пример «Пояснительная записка» (П2 по), разработанного для автоматизированной измерительно-информационной системы коммерческого учета электроэнергии (АИИС КУЭ) согласно к, и документа. по и. Редакция от 20.06.2018.
Создан 25.03.2014 11:48:18
Внимание! Технические требования оптового рынка электроэнергии (ОРЭ), ссылки на пункты которых содержатся в примерах документов на автоматизированные измерительно-информационные системы коммерческого учета электроэнергии (АИИС КУЭ), меняются достаточно часто, но не нами, а администратором торговой системы (АТС). Просьба отнестись к этому с пониманием
Все документы боевые , прошедшие множество, включая экспертизы в ФГУП «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ВНИИМАШ) РОССТАНДАРТА, поэтому сомнению не подлежит.
Для получения бесплатной сокращенной версии любого в виде *.pdf достаточно щелкнуть по титульного листа. Документ откроется в браузере с возможностью на. Полные версии документов - платные, их можно получить в формате за определенную сумму, воспользовавшись. Любой документ может в течение некоторого времени быть доработан под конкретные требования заказчика. Условия обсуждаются.
Как правило, Пояснительная записка бывает самым сложным документом на ПО, подчас вызывая множество споров и дискуссий вокруг своего содержания. Почему так случается?
Мы уже говорили о том, что в разработке программного обеспечения – это один из важных этапов . В нем должно быть представлено описание вашей системы с учетом выбранных технологий, как от нас того требует ГОСТ 34. А документ Пояснительная записка к техническому проекту, или, сокращенно, ПЗ, является одним из основных документов данного этапа. И, надо сказать, чаще всего именно Пояснительная записка бывает самым сложным документом на ПО, подчас вызывая множество споров и дискуссий вокруг своего содержания.
Пояснительная записка к техническому проекту включает в себя такие разделы, как:
– Введение . В этом разделе приводится полное наименование системы и тема разработки, а также список документов, послуживших основанием для работ по проекту.
– Назначение и область применения . Здесь описываются цели и задачи, которые будут решены с помощью системы, а также сфера ее использования.
– Технические характеристики . Этот раздел обычно разбивают на подразделы, в которых описывают: постановку задачи на создание программы; используемый математический аппарат; алгоритм работы ПО; структуру входных и выходных данных; состав технических и программных средств. Также необходимо приводить расчеты и результаты анализа для обоснования выбора именно тех решений, о которых говорится в документе.
– Ожидаемые технико-экономические показатели . Раздел предполагает экономическое обоснование разработки с учетом ее технических показателей.
– Источники, использованные при разработке . Раздел представляет собой список документов, статей и публикаций, на которые были приведены ссылки в тексте.
Состав разделов определяется ГОСТом 19.404, однако, стандарт позволяет эти разделы при необходимости объединять, а также добавлять новые. В случае использования ГОСТ серии 34 следует разрабатывать документ в соответствии с РД 50-34.698. Тем не менее, документ должен оставаться в рамках требований общих стандартов, таких, например, как ГОСТ 19.105.
Как же с наименьшими затратами создать документ на программу, максимально полезный для вашего проекта, который:
– с одной стороны, внятно и доходчиво представляет все нужные (а порой и нудные) сведения, включая сложные технические подробности;
[из п. 2.2.1 РД 50-34.698-90]
В разделе «Общие положения» приводят:
[из п. 2.2.2 РД 50-34.698-90]
В разделе «Описание процесса деятельности» отражают состав процедур () с учетом обеспечения взаимосвязи и совместимости процессов и деятельности, формируют к организации работ в АС [из п. 2.2.3 РД 50-34.698-90]
В разделе «Основные технические решения» приводят:
В разделе приводят в виде иллюстраций другие документы, которые допускается включать по ГОСТ 34.201 [из п. 2.2.4 РД 50-34.698-90]
В разделе «Мероприятия по подготовке к вводу системы в действие» приводят:
27.10.2016 09:57:23
В данной статье рассматривается стадия технического проекта, относящаяся к одному из этапов жизненного цикла системы информационной безопасности (СИБ) - этапу "проектирование", который в соответствии с отечественным стандартом ГОСТ 34.601-90 следует сразу за разработкой Технического задания на систему информационной безопасности.
Жизненный цикл системы информационной безопасности (далее - СИБ) в общем виде состоит из следующих этапов:
В данной статье рассматривается стадия технического проекта, относящаяся к этапу «проектирование» и в соответствии с отечественным стандартом ГОСТ 34.601-90 следует сразу за разработкой Технического задания на систему информационной безопасности.
Ответ на этот вопрос следует рассматривать в двух плоскостях: в плоскости владельца информационных ресурсов (для защиты которых и создается СИБ) и в плоскости непосредственного разработчика СИБ.
Для владельца информационных ресурсов важно получить результат в виде функционирующей системы информационной безопасности, снижающей риски компрометации информации ограниченного доступа в организации. Технический проект в данном случае служит для разработки фундаментальных основ будущей системы, а именно включает описание того, каким образом СИБ будет строиться и функционировать, какими мерами и средствами будет обеспечиваться защита информации, каковы возможности развития и совершенствования системы. По завершении разработки технического проекта на систему информационной безопасности Заказчик получает исчерпывающий комплект документации на СИБ, описывающий все технические нюансы будущей системы.
Для непосредственного исполнителя на этапе технического проекта необходимо заложить наиболее подходящую архитектуру СИБ, а также сделать правильный выбор мер и средств защиты информации в организации. Также важно обеспечить соответствие характеристик и свойств системы техническому заданию, либо обосновать при участии и согласии Заказчика корректировку требований, указанных в ТЗ, для повышения эффективности создаваемой системы.
Таким образом, в результате разработки документации технического проекта у Заказчика появятся ответы на следующие вопросы:
Исполнитель в процессе разработки документации технического проекта получит следующие результаты:
Разработка технического проекта для системы информационной безопасности чаще всего осуществляется на основе соответствующих стандартов и руководящих документов. Причем для государственных учреждений их применение обязательно, а для коммерческих рекомендуется. На практике коммерческие организации также используют государственные стандарты при разработке документации технического проекта по следующим причинам:
Для разработки документации стадии технического проекта (ТП) на СИБ используются государственные стандарты и руководящие документы серии 34:
Важно понимать, что согласно стандартам серии 34, технический проект - это стадия создания системы, а не просто набор документов. Данная стадия на практике часто объединяется со стадией эскизного проекта, служащей для разработки нескольких предварительных решений и обоснования наиболее подходящего. Такое объединение допускается стандартом, но необходимо учитывать, что это не отменяет необходимости реализации целей стадии эскизного проекта.
Чаще всего стадию эскизного проекта разрабатывают в том случае, когда требования технического задания на систему можно реализовать несколькими принципиально различающимися способами, а также в случае, если среди этих способов нет однозначно предпочтительных.
Однако стоит отметить, что вышеуказанные стандарты являются слишком общими и в основном реализуют оформительскую и общеструктурную функцию. Для разработки сутевой части документов стадии технического проекта проектировщиками используются сведения из следующих источников:
Действующие нормативные документы (НПА), регламентирующие требования к защите той или иной информации ограниченного доступа. В данных НПА представлены требования к мерам по защите информации в информационных системах, описаны нюансы реализации этих мер и дополнительные меры усиления. Среди актуальных НПА можно выделить следующие:
Требования к защите информации ограниченного доступа и перечни защитных мер разнятся для ИС разных уровней/классов защищенности. В случае, если информация в организации не относится к защищаемой в соответствии с федеральными законами РФ (например, служебная тайна), то владелец данной информации может воспользоваться подходами, предлагаемыми в данных НПА для построения корпоративной СИБ.
Российские и зарубежные стандарты, описывающие различные подходы к способам реализации стадий жизненного цикла построения СИБ, в том числе стадии технического проекта:
Эксплуатационная документация производителя на средства защиты информации и вспомогательные средства. В данных документах содержится исчерпывающая техническая информация о применяемых при построении СИБ средствах, в том числе напрямую к реализации мер ИБ не относящихся, например, серверах, системах хранения данных, средствах виртуализации и прочих. Общий набор таких документов у разных производителей различен и зависит в том числе от исполнения того или иного средства (аппаратное/программное). Ниже представлен стандартный набор эксплуатационной документации на средства защиты информации, используемый для разработки документов стадии технического проекта:
Общая информация об имеющихся архитектурах СИБ, лучшие практики в части построения СИБ, руководства по безопасности и интеграции СЗИ друг с другом, сведения о проблемах при взаимодействии тех или иных СЗИ. Примерами таких сведений могут являться следующие документы:
Разработка документов стадии технического проекта на СИБ осуществляется чаще всего интеграторами данных услуг и реализуется преимущественно в соответствии со следующим планом:
Определение перечня разрабатываемых документов – данные сведения указываются в техническом задании на СИБ. В некоторых случаях разработчик документов по согласованию с Заказчиком может расширить или сократить данный перечень, если возможность этого предусмотрена в ТЗ;
Разработка шаблонов документов стадии ТП – используется структура в соответствии с РД 50-34.698-90 и ГОСТ 2.106 (для некоторых документов), оформление в соответствии с ГОСТ 2.105-95;
Разработка сутевой части документов. Требования к системе устанавливаются в техническом задании на СИБ. В соответствии с данными требованиями определяется перечень защитных технических и организационных мер, необходимых к реализации в системе. Меры защиты могут быть определены в соответствующих НПА (в зависимости от типа защищаемой информации), корпоративных стандартах и политиках информационной безопасности, а также исходя из наличия актуальных угроз безопасности, выявленных на этапе разработки модели угроз организации. Основываясь на перечне мер защиты, разработчик СИБ осуществляет выбор соответствующих средств защиты информации и разрабатывает функциональную структуру системы информационной безопасности (подсистемы, компоненты). Далее в документах технического проекта описывается практическая реализация мер защиты на основе выбранных СЗИ или организационных мер в инфраструктуре организации.
Согласование разработанной документации и представленных в ней решений с Заказчиком системы.
При разработке документации технического проекта чаще всего не требуется разрабатывать полный перечень документов, указанный в ГОСТ 34.201-89, так как данный стандарт морально устарел и часть документов не учитывают тенденции разработки и технологии современных информационных систем. Минимальный комплект документов, необходимый для описания системы информационной безопасности, следующий:
По требованию Заказчика или в том случае, если СИБ является сложной многокомпонентной системой, дополнительно могут разрабатываться также следующие документы:
Необходимо отметить, что ГОСТ 34.201-89 допускает расширение номенклатуры документов стадии ТП, однако на практике означенных документов хватает с избытком.
Ведомость технического проекта
Обозначение: ТП.
Данный документ предназначен для описания перечня разрабатываемых на этапе технического проекта документов. Также указывается количество страниц каждого из разработанных документов.
Пояснительная записка к техническому проекту
Обозначение: П2.
Данный документ является основным для стадии ТП и включает в себя описание архитектуры СИБ, технических и организационных мер, функций СИБ, комплексов программных и технических средств и прочего. Согласно стандарту состоит из четырех основных разделов:
Схема функциональной структуры
Обозначение: С2.
Данный документ описывает логическую структуру СИБ, а именно:
Схема структурная комплекса технических средств
Обозначение: С1.
Данный документ включает в себя описание следующих элементов СИБ:
Схема организационной структуры
Обозначение: С0.
Данный документ описывает организационную структуру организации в части управления СИБ, а именно:
Ведомость покупных изделий
Обозначение: ВП.
Данный документ включает в себя перечень всех программных и технических средств, а также лицензий, используемых при создании СИБ. Разрабатывается в соответствии с ГОСТ 2.106.
Примечание. Здесь также стоит отметить, что руководящий документ РД 50-34.698-90 допускает дополнение любого документа стадии ТП (включение разделов и сведений, отличных от предложенных), объединение разделов, а также исключение некоторых отдельных разделов. Решения об этом принимаются разработчиком документов стадии ТП и основываются на особенностях создаваемой СИБ.
Пояснительная записка к техническому проекту:
В интернете размещается огромное количество информации, в той или иной мере способной помочь при разработке документации технического проекта. Основные ресурсы представлены в таблице ниже.
Таблица. Ресурсы по техническому проектированию СИБ
Тип ресурса | Информация | Примеры ресурсов |
---|---|---|
Интернет-порталы федеральных органов исполнительной власти | Нормативные документы, методические рекомендации, реестры (в том числе сертифицированных СЗИ), базы данных (в том числе БД уязвимостей и угроз) | fstec.ru
clsz.fsb.ru minsvyaz.ru/ru/ |
Интернет-порталы производителей СЗИ, дистрибьюторов решений в области ИБ | Описание решений по ИБ, эксплуатационная документация по СЗИ, аналитические материалы и статьи | securitycode.ru
kaspersky.ru/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/ cisco.com/c/ru_ru/index.html checkpoint.com altx-soft.ru |
Специализированные ресурсы по ИБ | Сравнение решений по ИБ, обзорные статьи по решениям ИБ, тесты решений по ИБ, глубокие технические сведения о технологиях ИБ | anti-malware.ru
bis-expert.ru safe.cnews.ru securitylab.ru/ vulners.com/ csrc.nist.gov itsecurity.com owasp.org sans.org |
Для понимания требований к содержанию документации стадии ТП далее представлены примеры наполнения основных документов (разделов документов).
Пояснительная записка - достаточно объемный документ, поэтому здесь приводится пример содержания раздела «Основные технические решения» в части одной из подсистем СИБ - подсистемы анализа защищенности.
Подсистема анализа защищенности СИБ
Структура и состав подсистемы
Подсистема анализа защищенности (ПАЗ) предназначена для проведения систематического контроля состояния защищенности автоматизированных рабочих мест (АРМ) персонала и серверов организации. Основой ПАЗ являются программное средство «Test» производства компании ООО «Информационная безопасность». СЗИ Test имеет сертификат ФСТЭК России на соответствие техническим условиям (ТУ) по безопасности информации и по 4-му уровню контроля отсутствия недекларированных возможностей.
В состав ПАЗ входят следующие компоненты:
Описание компонентов подсистемы представлено в таблице ниже.
Таблица. Компоненты ПАЗ
Компонент | Описание |
---|---|
Сервер управления Test Server | Обеспечивает управление задачами сканирования, выполняет функции контроля состояния защищенности АРМ и серверов организации. Параметры сканирования задаются администратором ИБ на сервере управления Test Server. Вся собранная информация о результатах сканирования сохраняется в хранилище сервера Test Server на базе системы управления базами данных Microsoft SQL Server 2008 |
Консоль управления Test Console | Позволяет администратору ИБ подключаться к серверу Test Server, просматривать и изменять его конфигурацию, создавать и модифицировать задачи на проведение сканирований, просматривать информацию о ходе выполнения задач и результаты их выполнения. Консоль управления устанавливается на АРМ администратора ИБ |
Обеспечение функций
ПАЗ обеспечивает выполнение следующих функций:
Решение по комплексу технических и программных средств
Перечень используемого программно-технического обеспечения ПАЗ приведен в таблице ниже.
Таблица. Программно-технические средства ПАЗ
Сервер управления ПАЗ
Технические средства
Физический сервер, используемый в качестве сервера управления ПАЗ, должен удовлетворять техническим требованиям к установленным на него ПО и ОС, приведенным в таблице ниже.
Таблица. Требования к ОС и ПО сервера управления ПАЗ
Программное обеспечение | Технические требования | |
---|---|---|
CPU | RAM, МБ | |
Microsoft Windows Server 2008 R2 | 3000 МГц, 4 ядра | 8192 |
Microsoft SQL Server 2008 R2 | ||
ПО Test Server |
Программные средства
ОС сервера управления
Установка ОС Windows 2008 R2 на сервер управления производится штатным образом с загрузочного дистрибутива.
Управление ОС сервера управления осуществляется как локально с консоли, так и по протоколу RDP.
СУБД сервера управления
Установка БД Microsoft SQL Server 2008 R2 осуществляется под учетной записью с правами локального администратора посредством стандартного мастера установки из дистрибутива, поставляемого разработчиком продукта.
ПО Test Server
Установка ПО Test Server на сервер управления осуществляется с помощью стандартного мастера установки.
Первоначальная настройка и последующее управление ПО Test Server в штатном режиме осуществляются с помощью консоли управления Test Console, установленной на АРМ администратора ИБ.
АРМ администратора ИБ
Технические средства
В качестве платформы используется существующий АРМ сотрудника подразделения организации, ответственного за обеспечение ИБ, под управлением ОС семейства Microsoft Windows.
Технические средства АРМ администратора ИБ должны обладать следующими характеристиками аппаратной конфигурации (рекомендуется не менее):
Программные средства
ПО Test Console
АРМ администратора ИБ, на которое выполняется установка ПО Test Console, должно функционировать под управлением одной из следующих ОС:
Кроме того, для корректной работы ПО консоли управления Test Console на АРМ администратора ИБ должно быть установлено ПО Microsoft .NET Framework версии 3.5 SP1 или выше, а настройки безопасности используемой ОС должны разрешать доступ к серверу Test Server.
Установка ПО Test Console на АРМ администратора ПАЗ осуществляется с помощью стандартного мастера установки ПО Test Server с выбранной опцией установки консоли управления Test Console и прочими настройками по умолчанию.
Взаимодействие со смежными системами
Для ПАЗ смежными являются:
Для обеспечения сетевого взаимодействия со смежными системами и непосредственно между самими компонентами ПАЗ должно быть организовано прохождение необходимого сетевого трафика.
Для обеспечения возможности получения обновлений базы знаний и модулей ПО Test для сканера Test Server необходимо обеспечить доступ к веб-серверу обновлений компании ООО «Информационная безопасность» update.com по порту 443/tcp.
При сканировании в режиме PenTest взаимодействие сканера Test Server и АРМ и серверов организации осуществляется по протоколу IP. При сканировании в режиме Audit и Compliance используются протоколы удаленного управления WMI, RPC и т. п. Для сканирования узлов на устройствах с функциями межсетевого экрана необходимо разрешить соединения от сервера Test Server к сканируемым узлам по протоколу IP. Соответственно, для сервера Test Server необходимо обеспечить доступ к сетевым портам сканируемых узлов по соответствующим протоколам удаленного управления.
Поскольку ПАЗ при сканировании в режимах Audit и Compliance использует для анализа протоколы удаленного управления, то средства сканирования ПО Test должны проходить аутентификацию и авторизацию на сканируемом узле. В ПАЗ для сканирования узлов в режимах Audit и Compliance в каждом из типов узлов (АРМ, сервер, прикладные системы, СУБД и т. п.) используются учетные записи c административными привилегиями.
Все регистрируемые события информационной безопасности хранятся в СУБД Microsoft SQL. Данные события посредством специальных коннекторов могут отправляться в подсистему мониторинга событий ИБ.
Эксплуатация и обслуживание ПАЗ
Пользователи подсистемы
Эксплуатация и обслуживание средств ПАЗ осуществляется сотрудниками организации с функциональной ролью «администратор ИБ».
Под администратором ИБ понимается специалист, в задачи которого входит:
Режимы эксплуатации системы
Штатный режим эксплуатации
В штатном режиме эксплуатации ПАЗ функционирует 24 часа в сутки 7 дней в неделю.
В штатном режиме работы администратор ИБ выполняет:
Аварийный режим эксплуатации
При нарушении работоспособности средств ПАЗ функционирование подсистемы нарушается. Нарушение работоспособности средств ПАЗ не влияет на функционирование АРМ и серверов организации.
Функциональные схемы могут разрабатываться для всей СИБ или для ее части, например, подсистемы или компонента.
Пример общей функциональной схемы СИБ представлен на рисунке ниже.
1.6.3. Схема структурная комплекса технических средств
Структурная схема комплекса технических средств может разрабатываться как для всей СИБ, так и для ее частей - подсистем и компонентов. Целесообразность разработки схем для частей СИБ определяется масштабом системы и требуемой детализацией.
Пример структурной схемы комплекса технических средств СИБ представлен на рисунке ниже.