Разделы пояснительной записки к техническому проекту. Техническая документация. Разработка документации технического проекта на СИБ

ГОСТ 19.404-79

Группа Т55

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Единая система программной документации

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

Требования к содержанию и оформлению

Unified system for program documentation. Explanatory note. Requirements for contents and form of presentation

Дата введения 1981-01-01


Постановлением Государственного комитета CCCР по стандартам от 11 декабря 1979 г. N 4753 дата введения установлена 01.01.81

ПЕРЕИЗДАНИЕ. Январь 2010 г.


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

1. ОБЩИЕ ПОЛОЖЕНИЯ

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Структура и оформление документа устанавливаются в соответствии с ГОСТ 19.105-78 .

Составление информационной части (аннотации и содержания) является необязательным.

1.2. Пояснительная записка должна содержать следующие разделы:

введение;

назначение и область применения;

технические характеристики;

ожидаемые технико-экономические показатели;

источники, использованные при разработке.

В зависимости от особенностей документа отдельные разделы (подразделы) допускается объединять, а также вводить новые разделы (подразделы).

2.1. В разделе "Введение" указывают наименование программы и (или) условное обозначение темы разработки, а также документы, на основании которых ведется разработка, с указанием организации и даты утверждения.

2.2. В разделе "Назначение и область применения" указывают назначение программы, краткую характеристику области применения программы.

2.3. Раздел "Технические характеристики" должен содержать следующие подразделы:

постановка задачи на разработку программы, описание применяемых математических методов и, при необходимости, описание допущений и ограничений, связанных с выбранным математическим аппаратом;

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

описание и обоснование выбора метода организации входных и выходных данных;

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

2.4. В разделе "Ожидаемые технико-экономические показатели" указывают технико-экономические показатели, обосновывающие преимущество выбранного варианта технического решения, а также, при необходимости, ожидаемые оперативные показатели.

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

2.6. В приложение к документу могут быть включены таблицы, обоснования, методики, расчеты и другие документы, использованные при разработке.



Электронный текст документа
подготовлен ЗАО "Кодекс" и сверен по:
официальное издание
Единая система программной документации:
Сб. ГОСТов. -
М.: Стандартинформ, 2010

27.10.2016 09:57:23

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

1. Разработка документации технического проекта на СИБ

Жизненный цикл системы информационной безопасности (далее - СИБ) в общем виде состоит из следующих этапов:

  • анализ требований к СИБ;
  • проектирование;
  • реализация;
  • внедрение;
  • эксплуатация.

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

1.1. Зачем вообще разрабатывать документацию на СИБ

Ответ на этот вопрос следует рассматривать в двух плоскостях: в плоскости владельца информационных ресурсов (для защиты которых и создается СИБ) и в плоскости непосредственного разработчика СИБ.

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

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

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

  • какова общая архитектура СИБ;
  • какие меры и средства будут использоваться для реализации требований по защите информации;
  • каким образом СИБ будет функционировать;
  • какие изменения в организации, необходимые для повышения уровня защищенности информации, последуют в результате внедрения СИБ;
  • будут ли учтены требования Заказчика (бизнес-требования) и требования нормативно-правовых актов в сфере информационной безопасности при разработке и внедрении СИБ и, если да, то каким образом.

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

  • базу для перехода к следующим этапам построения СИБ, а именно стадиям рабочей документации и внедрения;
  • понимание архитектуры, используемых технологий и средств, порядка построения системы;
  • каким образом реализуются требования Заказчика (бизнес-требования) и нормативных документов в сфере информационной безопасности к системе.

1.2. Обзор подходов к разработке документации технического проекта

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

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

Для разработки документации стадии технического проекта (ТП) на СИБ используются государственные стандарты и руководящие документы серии 34:

  • ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем». В данном стандарте указаны:
    • виды и наименование документов стадии ТП;
    • комплектность документации;
    • принятые обозначения документов;
    • правила обозначения СИБ и их частей.
  • ГОСТ 34.003-90 «Термины и определения»;
  • ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания». В стандарте указаны:
    • перечень этапов работ, проводимых на стадии ТП;
    • подробное описание работ, проводимых на стадии ТП;
    • перечень организаций, участвующих в создании СИБ;
  • РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов». В данном руководящем документе указаны требования к содержанию документов стадии ТП.

Важно понимать, что согласно стандартам серии 34, технический проект - это стадия создания системы, а не просто набор документов. Данная стадия на практике часто объединяется со стадией эскизного проекта, служащей для разработки нескольких предварительных решений и обоснования наиболее подходящего. Такое объединение допускается стандартом, но необходимо учитывать, что это не отменяет необходимости реализации целей стадии эскизного проекта.

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

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

Действующие нормативные документы (НПА), регламентирующие требования к защите той или иной информации ограниченного доступа. В данных НПА представлены требования к мерам по защите информации в информационных системах, описаны нюансы реализации этих мер и дополнительные меры усиления. Среди актуальных НПА можно выделить следующие:

  • приказ ФСТЭК России от 18 февраля 2013 г. № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»;
  • приказ ФСТЭК России от 11 февраля 2013 г. № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»
  • приказ ФСТЭК России от 14 марта 2014 г. № 31 «Об утверждении требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды;
  • методический документ «Меры защиты информации в государственных информационных системах», утвержден ФСТЭК России 11 февраля 2014 г.

Требования к защите информации ограниченного доступа и перечни защитных мер разнятся для ИС разных уровней/классов защищенности. В случае, если информация в организации не относится к защищаемой в соответствии с федеральными законами РФ (например, служебная тайна), то владелец данной информации может воспользоваться подходами, предлагаемыми в данных НПА для построения корпоративной СИБ.

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

  • серия государственных стандартов ГОСТ Р ИСО/МЭК 2700X, идентичные международным стандартам ISO/IEC 2700X. Данные стандарты описывают процессный подход PDCA (Plan, Do, Check, Act) к реализации жизненного цикла системы менеджмента информационной безопасности, которая является неотъемлемой частью СИБ;
  • NIST SP 800-64 – стандарт Национального Института Стандартов и Технологий США, описывающий жизненный цикл разработки информационных систем;
  • NIST SP 800-37 – стандарт Национального Института Стандартов и Технологий США, являющийся руководством по интеграции управления рисками в жизненный цикл разработки информационных систем.

Эксплуатационная документация производителя на средства защиты информации и вспомогательные средства. В данных документах содержится исчерпывающая техническая информация о применяемых при построении СИБ средствах, в том числе напрямую к реализации мер ИБ не относящихся, например, серверах, системах хранения данных, средствах виртуализации и прочих. Общий набор таких документов у разных производителей различен и зависит в том числе от исполнения того или иного средства (аппаратное/программное). Ниже представлен стандартный набор эксплуатационной документации на средства защиты информации, используемый для разработки документов стадии технического проекта:

  • общее описание (datasheet);
  • руководство администратора (может входить руководство по локальному и централизованному управлению);
  • руководство пользователя;
  • руководство по быстрой установке и развертыванию (для аппаратного СЗИ);
  • руководство оператора;
  • руководство по развертыванию в виртуальной инфраструктуре (для программного СЗИ);

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

  • руководства по архитектурам систем информационной безопасности, например: Defense-in-Depth, Cisco SAFE, Check Point SDP и прочие;
  • лучшие практики в области информационной безопасности, например, доступные по данным ссылкам (https://www.sans.org/reading-room/whitepapers/bestprac/ , http://csrc.nist.gov/publications/nistpubs/800-14/800-14.pdf). Данные документы чаще всего представлены на английском языке, однако свои лучшие практики внедрения средств защиты есть у любого российского производителя СЗИ и по запросу их могут предоставить;
  • руководства по безопасности для СЗИ и сред функционирования. В качестве примера можно привести раздел «Безопасность» на официальном портале компании Microsoft (https://technet.microsoft.com/ru-ru/library/dd637672.aspx).

1.3. Разработка технического проекта на СИБ в соответствии с ГОСТ 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 допускает дополнение любого документа стадии ТП (включение разделов и сведений, отличных от предложенных), объединение разделов, а также исключение некоторых отдельных разделов. Решения об этом принимаются разработчиком документов стадии ТП и основываются на особенностях создаваемой СИБ.

1.4. Правила разработки документации

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

Пояснительная записка к техническому проекту:

  • разработка документа осуществляется в среде Microsoft Word, после окончания разработки рекомендуется для удобства конвертировать документ в формат PDF;
  • термины и сокращения должны быть едиными в пределах всех разделов документа;
  • рекомендуется избегать явных повторений и ненужного увеличения объема документа;
  • технические решения необходимо описывать как можно более подробно с указанием:
    • архитектуры и используемых технологий;
    • мест размещения программных и технических средств в инфраструктуре организации;
    • используемых средств защиты информации с описанием их характеристик, реализуемых функций, сведений о сертификации;
    • основных настроек средств защиты информации в части механизмов защиты, адресации, маршрутизации, взаимодействия со смежными системами и средствами и прочего;
    • средств управления, методов доступа к ним и местах их установки;
    • схемы (структурная, функциональная, организационная):
      • разрабатывать схемы в среде Microsoft Visio;
      • после разработки вставлять схемы в документ при помощи диалога «Специальная вставка» в формате EMF (метафайл Windows);
      • разрабатывать отдельные схемы на систему, подсистемы и компоненты подсистем;
      • оформление схем делать однотипным, с использованием одинаковых элементов, сокращений, иконок, стилей текста и прочего.

1.5. Ресурсы, помогающие при разработке документации

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

Таблица. Ресурсы по техническому проектированию СИБ

Тип ресурса Информация Примеры ресурсов
Интернет-порталы федеральных органов исполнительной власти Нормативные документы, методические рекомендации, реестры (в том числе сертифицированных СЗИ), базы данных (в том числе БД уязвимостей и угроз) 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


1.6. Примеры документов стадии технического проекта

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

1.6.1. Пояснительная записка к техническому проекту

Пояснительная записка - достаточно объемный документ, поэтому здесь приводится пример содержания раздела «Основные технические решения» в части одной из подсистем СИБ - подсистемы анализа защищенности.

Подсистема анализа защищенности СИБ

Структура и состав подсистемы

Подсистема анализа защищенности (ПАЗ) предназначена для проведения систематического контроля состояния защищенности автоматизированных рабочих мест (АРМ) персонала и серверов организации. Основой ПАЗ являются программное средство «Test» производства компании ООО «Информационная безопасность». СЗИ Test имеет сертификат ФСТЭК России на соответствие техническим условиям (ТУ) по безопасности информации и по 4-му уровню контроля отсутствия недекларированных возможностей.

В состав ПАЗ входят следующие компоненты:

  • сервер управления Test Server;
  • консоль управления Test Console.

Описание компонентов подсистемы представлено в таблице ниже.

Таблица. Компоненты ПАЗ

Компонент Описание
Сервер управления 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.

Технические средства АРМ администратора ИБ должны обладать следующими характеристиками аппаратной конфигурации (рекомендуется не менее):

  • CPU 2 ГГц;
  • RAM 4 ГБ;
  • HDD 80 ГБ.

Программные средства

ПО Test Console

АРМ администратора ИБ, на которое выполняется установка ПО Test Console, должно функционировать под управлением одной из следующих ОС:

  • Microsoft Windows 7, 32- и 64-битные;
  • Microsoft Windows 8/8.1, 32- и 64-битные.

Кроме того, для корректной работы ПО консоли управления Test Console на АРМ администратора ИБ должно быть установлено ПО Microsoft .NET Framework версии 3.5 SP1 или выше, а настройки безопасности используемой ОС должны разрешать доступ к серверу Test Server.

Установка ПО Test Console на АРМ администратора ПАЗ осуществляется с помощью стандартного мастера установки ПО Test Server с выбранной опцией установки консоли управления Test Console и прочими настройками по умолчанию.

Взаимодействие со смежными системами

Для ПАЗ смежными являются:

  • средства подсистемы межсетевого экранирования;
  • службы каталога Active Directory;
  • АРМ и серверы организации.

Для обеспечения сетевого взаимодействия со смежными системами и непосредственно между самими компонентами ПАЗ должно быть организовано прохождение необходимого сетевого трафика.

Для обеспечения возможности получения обновлений базы знаний и модулей ПО 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 дней в неделю.

В штатном режиме работы администратор ИБ выполняет:

  • плановое и внеплановое сканирования узлов;
  • генерацию отчетов;
  • обновление баз знаний и модулей ПО Test.

Аварийный режим эксплуатации

При нарушении работоспособности средств ПАЗ функционирование подсистемы нарушается. Нарушение работоспособности средств ПАЗ не влияет на функционирование АРМ и серверов организации.

1.6.2. Схема функциональной структуры

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

Пример общей функциональной схемы СИБ представлен на рисунке ниже.

1.6.3. Схема структурная комплекса технических средств

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

Пример структурной схемы комплекса технических средств СИБ представлен на рисунке ниже.


Основной целью документа Пояснительная записка является предоставление общих сведений о системе и обоснований для технических решений принятых в процессе ее разработки. Поэтому основанием для разработки Пояснительной записки будет в основном Техническое задание.

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

Для создания пояснительной записки к техническому проекту, описывающему автоматизированную систему (АС) рекомендуется использовать стандарт РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов» .

Многие разделы, приведенных документов, перекликаются, поэтому мы для примера рассмотрим документ Пояснительная записка, созданный на основании РД 50-34.698-90

1 Общие положения

1.1 Наименование проектируемой АС

Данный раздел документа Пояснительная записка содержит полное и краткое наименование АС.

Например: «В данном документе создаваемая система называется Корпоративный Информационный Портал. Также допускается использование сокращенного наименования КИП или Система ».

1.2 Документы, на основании которых ведется проектирование системы

В данном разделе документа Пояснительная записка следует указать ссылки на договор и Техническое задание на разработку автоматизированной системы.

1.3 Организации, участвующих в разработке системы

В данном разделе документа Пояснительная записка указываются наименования организаций заказчика и разработчика.

1.4 Цели разработки АС

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

Например: «Целью, создаваемой системы является:

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

1.5 Назначение и область использования разрабатываемой АС

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

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

  • Создание конференций для обсуждения вопросов;
  • Отправка/Получение электронных почтовых сообщений;
  • Обеспечение совместной работы над документами;
  • Согласование документов;
  • Ведение учета входящей и исходящей документации.»

1.6 Сведения об использованных при проектировании нормативно-технических документах

В данном разделе следует указать стандарты, которые использовались при создании документа Пояснительная записка.

Например: «При проектировании использовались следующие нормативно-технические документы:

  • ГОСТ 34.201-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем»;
  • ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»;
  • ГОСТ 34.003-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»;
  • ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»;
  • РД 50-682-89 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Общие положения»;
  • РД 50-680-88 «Методические указания. Автоматизированные системы. Основные положения»;
  • РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».»

1.7. Очередность создания системы

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

Например: «Реализация проекта Корпоративного информационного Портала планируется в две очереди.

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

  • Обмен мгновенными сообщениями;
  • Организация конференции;
  • Передача/прием электронной почты;
  • Согласование документов средствами Системы.»

2 Описание процесса деятельности

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

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

Для понимания отношения автоматизированных функций к неавтоматизированным в документе Пояснительная записка необходимо четко разделять действия пользователя и действия системы.

Например: «1. Пользователь формирует документ

  • Пользователь инициирует процесс передачи документа на согласование
  • Система изменяет статус документа на «на согласовании». »
  • Основные технические решения

2.1. Решения по структуре системы и подсистем.

В данном разделе документа Пояснительная записка приводятся решения по функциональной структуре системы и ее подсистем.

2.2. Средства и способы взаимодействия между компонентами системы. Взаимосвязь с внешними системами

В данном разделе документа Пояснительная записка необходимо указать перечень систем, с которыми должен взаимодействовать, создаваемый продукт. При описании взаимодействия компонентов системы в Пояснительной записке необходимо указать формат обмена данными.

Например: «В рамках взаимодействия КИП с внешними системами используются следующие технологии:
- «Бухгалтерия предприятия» - файловый обмен в установленном XML / Excel формате.»

2.3. Решения по режимам функционирования

Данный раздел документа Пояснительная записка включает перечень и описание режимов функционирования системы. Обычно выделяются следующие режимы: штатный режим, режим тестовой эксплуатации, сервисный режим. В пояснительной записке необходимо предоставить описание как самого режима так и случаев в которых он вводится.

2.4. Решения по численности, квалификации и функциям персонала АС

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

Например: «Администратор портала ответственный за:

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

2.5. Обеспечение заданных в техническом задании потребительских характеристик системы

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

Например: «Отказоустойчивость и работоспособность программных модулей КИП обеспечивается за счет применения промышленных программных платформ IBM WebSphere Portal, Enterprise Oracle 10g.»

2.6. Состав функций и комплекс задач, реализуемых системой

Данный раздел документа Пояснительная записка содержит перечень задач, которые решает система. В пояснительной записке функции и комплекс задач можно представить в виде ненумерованного списка.

2.7. Решения по комплексу технических средств, его размещению на объекте

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

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


Оборудование

Техническая характеристика

Сервер Базы данных

Исполнение для монтажа в стойку

Не более 4U

Архитектура процессоров

RISC (64-разрядная)

Частота процессора

не менее 1,5 ГГц

Кэш процессора

Не менее 1Мб

Операционные системы

Windows 2003 SP2

Возможное число устанавливаемых процессоров

Не менее 4

Число установленных процессоров

Объем возможной оперативной памяти

32 ГБ с ЕСС

Объем оперативной памяти

Минимум 8 ГБ

Наличие интерфейсов

10/100/1000 Base-T Ethernet интерфейсы 2 шт.;
Ultra320 SCSI 2 шт.;
USB 4 шт.;
последовательный интерфейс 1 шт.;
слоты расширения PCI 64-bit 6 шт.

Видео карта:

Не менее 8Мб.

Возможное число устанавливаемых же­стких дисков

Не менее 4

Число установленных дисков

Устройство для считывания

Электрическое питание

Входные параметры:
200-240 В, частота тока: 50-60 Гц;
максимальная входная мощность не более 1600 Вт;
не менее 2х блоков питания обеспечивающих отказоустойчивость.

»

При описании размещения объектов комплекса технических средств в пояснительной записке необходимо руководствоваться требованиями СНиП 11-2-80 для зданий категории "В".

2.8. Объем, состав, способы организации, последовательность обработки информации

Информационное обеспечение включает в себя внутримашинное и внемашинное информационное обеспечение. В качестве внутримашинного информационного обеспечения выступают База данных (БД), входные и выходные документы, поступающие из внешних систем.

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

При описании внутримашинной информационной базы в документе Пояснительная записка необходимо указать входные и выходные документы и сообщения для всех подсистем и внешних систем.

Например: «Входной информацией для подсистемы электронного документооборота является:

  • электронные версии документов производственного документооборота;
  • электронная цифровая подпись;

Выходной информацией для подсистемы электронного документооборота является:

  • журнал истории жизненного цикла документа;
  • журнал истории согласования документа;
  • файл электронной версии документа в формате RTF. »

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

В данном разделе документа Пояснительная записка следует привести технологии и средства разработки системы.

Например:
«

  • Сервер базы данных: Oracle 10g
  • Портал: Websphere Portal Extend v6.0.
  • Бизнес-моделирование: ARIS

»

3 Мероприятия по подготовке объекта автоматизации к вводу системы в действие

В данном разделе документа Пояснительная записка описываются следующие мероприятия:

  • мероприятия по приведению информации к виду, пригодному для обработки на ЭВМ;
  • мероприятия по обучению и проверке квалификации персонала;
  • мероприятия по созданию необходимых подразделений и рабочих мест;
  • мероприятия по изменению объекта автоматизации;
  • другие мероприятия, исходящие из специфических особенностей создаваемых АС

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

Пояснительная записка необходима для отражения информации об объекте, принятых технических решениях и их обоснования.

Состав пояснительной записки

Пояснительная записка к проекту любого ОКС вмещает подразделы:

  1. Введение. В этом разделе указывается название объекта или системы, тема разработки и перечень документов – фундамента для начала работ. Основная документация, приведенная во Введении:
    2. документ определенного (федерального, ведомственного, регионального) уровня, разрешающий разработку проекта; решение соответствующих органов; решение инвестора.

    Также в данный раздел входит:

    задание на проектирование (если проект разрабатывается на основе договора); документы, устанавливающие право собственности на объект капитального строительства (если проектная документация разрабатывается для выполнения реконструкции или ремонта объекта); отчеты по итогам инженерных исследований и испытаний; утвержденный план земельного участка, отведенного под застройку; документы на использование земельных участков, не попадающих под влияние градостроительных регламентов, полученные от уполномоченных органов федеральной, исполнительной или местной власти; технические условия и документы, разрешающие отступление от них; акты владельца объекта о необходимом сносе некоторых сооружений с территории строительства; разрешение на отклонение от граничных величин объектов капитального строительства.
  2. Функциональность, назначение объекта, дальнейшая эксплуатация. В данном разделе характеризуются цели, задачи и сфера использования разрабатываемого объекта.
  3. Технические характеристики. Это самый объемный раздел, состоящий из взаимосвязанных подразделов. В данную главу входят:
    4. данные о необходимости обеспечения объекта газом, водой, топливом и электроэнергией; сведения о проектной мощности (для промышленных объектов); информация об объемах необходимого сырья, воды, топливных и энергетических ресурсов и данные об их пользовании (для производственных объектов); сведения об изъятых участках (во временное или постоянное пользование), обоснование их размеров, если они не регламентированы нормами; в случае изъятия земель под временное или постоянное применение – данные о величине материальных средств, необходимых для возмещения убытков их обладателям; характеристика категории земель, отведенных под застройку; данные об имеющихся специальных технических условиях (в случае необходимости).
  4. Технико-экономические показатели – отражена информация о проектной мощности ОКС, значимости его для населения, количестве будущих сотрудников, числе рабочих мест и т. д.

    5. Также на этом этапе возможна характеристика компьютерных программ, примененных при разработке проекта. Приводятся сведения о вероятных затратах на снос зданий и сооружений, переселении людей, перемещении коммуникаций, конструкций и т. д. (если необходимо). Выполняется описание и обоснование возможности реализации стадийного строительства объекта, выделение этапов (при необходимости).

    Раздел ПЗ в обязательном порядке должен содержать подтверждение проектной организации того, что вся документация разработана и оформлена согласно документам:

    градостроительному плану земельного участка; задания на проектирование; градостроительному регламенту; других технических регламентов и требований.
  5. Список литературы. В этом разделе приводятся источники, документы, статьи, книги, ссылки на которые указывались в текстовой части проекта.

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

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

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

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

Структура и оформление

Пояснительная записка оформляется согласно межгосударственному стандарту ГОСТ 2.106-96 , описывающему общие требования к составлению текстовой и конструкторской документации, содержание ее разделов описано в руководящем документе РД 50-34.698-90 , регламентирующем требования к содержанию документов на АСУ.

Этот документ, согласно стандартам и руководящим документам, должен состоять из нескольких разделов:

«Общие положения»
С указанием названия разрабатываемой АСУ, документов, на основании которых система разрабатывается – технического задания, договора - организаций, которые принимают участие в проектировании, стадий и сроков выполнения работ, целей разработки системы, ее назначения и сферы применения, технической и нормативной документации, а также очередности работ по проектированию.

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

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

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