Техническое задание на проектирование аппаратно-программного комплекса «безопасный город»


Скачать 2.2 Mb.
Название Техническое задание на проектирование аппаратно-программного комплекса «безопасный город»
страница 9/23
Тип Техническое задание
rykovodstvo.ru > Руководство эксплуатация > Техническое задание
1   ...   5   6   7   8   9   10   11   12   ...   23

4.1.1.2Перечень проектируемых подсистем КСА ЕЦОР, их назначение и основные характеристики


Создаваемые КСА ЕЦОР предназначены для автоматизации деятельности ЕДДС пилотных муниципальных образований г. Хабаровск и г. Комсомольск-на-Амуре.

КСА ЕЦОР должен включать в себя следующие функциональные подсистемы:

  1. Подсистема поддержки принятия решений.

  2. Подсистема приема и обработки сообщений.

  3. Подсистема комплексного мониторинга.

  4. Интеграционная географическая информационная подсистема.

  5. Подсистема электронного взаимодействия с муниципальными службами и населением (далее - Интернет – портал).

  6. Подсистема обеспечения координации и взаимодействия.

  7. Подсистема комплексного информирования и оповещения.

  8. Подсистема интеграции данных (интеграционная платформа).

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

  1. Подсистема вычислительных комплексов.

  2. Транспортная подсистема.

  3. Подсистема хранения данных.

  4. Подсистема виртуализации.

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

  6. Подсистема администрирования.

  7. Подсистема информационной безопасности.
4.1.1.2.1Подсистема поддержки принятия решений

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

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

  1. Хранилище данных.

  2. Модули загрузки и трансформации данных (ETL).

  3. Модули формирования и визуализации отчетов.

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

  • визуализация результатов прогнозирования последствий происшествий;

  • расчет необходимых сил и средств для ликвидации происшествия и восстановительных работ;

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

Перечень функций подсистемы поддержки принятия решений должен включать:

  1. расчет последствий аварий и КСиП следующих типов:

  • пожаров;

  • паводковых наводнений;

  • лесных пожаров;

  • разливов нефти;

  • аварии на объектах ЖКХ;

  1. ввод информации о КСиП, формирование сводки КСиП на заданную дату, формирование статистики по КСиП за период;

  2. навигация по картографической основе подсистемы комплексного мониторинга;

  3. просмотр, поиск и редактирование информации, являющейся исходными данными для слоев субмодели обстановки в ГИС;

  4. автоматизированный сбор, обработку и представление информации о возникших КСиП на объектах мониторинга;

  5. оценку обстановки при КСиП, в том числе, определение силы опасного воздействия и границы зон поражения;

  6. расчет возможного ущерба при КСиП, в том числе:

  • расчет количества населения, оказавшегося в зоне действия поражающих факторов;

  • расчет медико-санитарных потерь разной степени тяжести;

  1. определение списка объектов (жилых и нежилых строений, объектов экономики, и т.д.), попавших в зону КСиП;

  2. расчет количества сил и средств, необходимого для выполнения неотложных спасательных и восстановительных работ, в том числе:

  • определение потребного количества коек, в т.ч. специализированных, с указанием конкретных ЛПУ для госпитализации пострадавших;

  • определение потребности в инженерной технике, необходимой для ликвидации последствий ЧС, с указанием наименований организаций, из числа не попавших в зону ЧС;

  • определение потребности в технике для эвакуации;

  • определение потребного количества комплектов продовольственного и вещевого снабжения;

  1. формирование документов и рекомендаций к плану действий, в том числе:

  • отчетов в стандартных формах 1-3/ЧС.

  • проект решения председателя комиссии по чрезвычайным ситуациям региона;

  • формирование списков ЛПУ, ближайших к зоне ЧС, БСМП, в т. ч. специализированных;

  • формирование списка организаций поставщиков автомобильной техники для эвакуации, других видов сил и средств из числа не попавших в зону ЧС;

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

  • добавление объектов с возможностью указания географической и адресной привязки объекта;

  • занесения необходимых характеристик;

  • добавление источников опасности различного типа, расположенных на территории ПОО;

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

  • учитывать различное количество находящихся людей/персонала в различное время суток;

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

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

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

В состав подсистемы должны входить следующие функциональные компоненты:

  1. Компонент маршрутизации и распределения вызовов.

  2. Компонент «Нормативно-справочная информация и база знаний».

  3. Компонент консультативного обслуживания.

  4. Компонент контроля качества обслуживания.

  5. Компонент обучения.

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

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

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

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

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

В состав функционального компонента обучения должны входить:

  1. библиотека материалов;

  2. учебный макет системы;

  3. эксплуатационная документация.
4.1.1.2.3Подсистема комплексного мониторинга

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

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

Подсистема комплексного мониторинга должна включать в свой состав следующие функциональные компоненты:

  • Компонент систем мониторинга и обеспечения безопасности;

  • Компонент видеомониторинга и видеоанализа;

  • Компонент мониторинга состояния окружающей среды;

  • Компонент мониторинга систем ЖКХ.

Компонент систем мониторинга и обеспечения безопасности должен обеспечивать:

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

  • формирование и передачу в другие компоненты системы информации о внештатной ситуации на контролируемых стационарных и подвижных объектах;

  • получение и регистрация текущего местоположения и состояния контролируемых транспортных средств;

  • ведение статистики внештатных ситуаций по контролируемым стационарным и подвижным объектам;

  • предоставление списка объектов мониторинга;

  • предоставление списка обращений, поступивших по объекту мониторинга;

  • предоставление списка происшествий, зарегистрированных на объектах мониторинга.

Компонент видеомониторинга должен обеспечивать:

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

  • отображение направления и зон обзора камер на электронной карте;

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

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

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

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

  • измерение основных параметров окружающей среды;

  • прием и обработку информации и сигналов, поступающих с постов мониторинга радиационной и химической обстановки на РОО и ХОО;

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

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

Компонент мониторинга систем ЖКХ должен обеспечивать:

  • прием и обработку оконечными устройствами результатов измерений параметров систем ЖКХ;

  • информирование ЕДДС в случае наступления неблагоприятного или опасного явления при выходе одного из наблюдаемых параметров за предельные нормы;

  • отображение мест расположения объектов ЖКХ, с которых поступает сигнал тревоги, на цифровой карте муниципального образования.
4.1.1.2.4Интеграционная географическая информационная подсистема

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

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

  2. место возникновения происшествия или ЧС;

  3. отображение зон ответственности ДДС;

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

  5. расположения ЕДДС, взаимодействующих ДДС и подразделений экстренных служб;

  6. расположение потенциально опасных и критически важных объектов;

  7. информации о местонахождении и перемещении сил и средств реагирования, при наличии технических возможностей используемых технологий ГЛОНАСС;

  8. характеристик территории.
4.1.1.2.5Интернет – портал (Подсистема взаимодействия муниципальных служб и населения)

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

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

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

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

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

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

Подсистема комплексного информирования и оповещения должна иметь доступ к средствам экстренного оповещения общероссийской комплексной системы информирования и оповещения населения в местах массового пребывания людей (ОКСИОН).

Подсистема комплексного оповещения и информирования должна обеспечивать:

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

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

  • мониторинг и контроль системы информирования.
4.1.1.2.8Подсистема интеграции данных (интеграционная платформа)

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

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

Основными задачами подсистемы интеграции данных должны являться:

  • интеграция разнородных информационных систем;

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

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

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

  1. Модуль ведения реестра информационных систем в составе:

  • Компонент ведения справочника метаданных информационного обеспечения Системы;

  • Компонент трансформации, контроля, очистки и нормализации (приведение к общим форматам, классификаторам и т.п.) данных из внешних информационных систем;

  • Компонент актуализации и синхронизации общесистемных справочников и классификаторов.

  1. Модуль реализации общей шины данных;

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

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

- обеспечение целостности данных, передаваемых между интегрируемыми ИС, путём контроля изменений в ИС-источниках и синхронизации этих изменений по всем ИС-потребителям, входящим в состав КСА;

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

- ведение журнала операций информационного обмена.

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

Обмен данными между ИС и подсистемой интеграции данных должен осуществляться посредством единого унифицированного протокола обмена данными, основанного на протоколах HTTP/SOAP с пересылкой XML-сообщений. Модулем должен поддерживаться синхронный и асинхронный режим обмена данными. В случаях, когда обмен данными по единому унифицированному протоколу с какой-либо ИС не возможен, для соответствующей ИС должен быть разработан адаптер, представляющий собой отдельное приложение, берущее на себя взаимодействие с модулем ведения реестра и другими ИС в формате единого протокола и взаимодействующий с собственной ИС посредством имеющихся у неё сервисов, интерфейсов, либо посредством прямого подключения к базе данных ИС.

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

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

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

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

Разработка прикладного ПО модуля должна вестись на языках высокого уровня. Используемое при разработке программное обеспечение и библиотеки программных кодов должны иметь широкое распространение, быть общедоступными и использоваться в промышленных масштабах.

Выбранная исполнителем платформа разработки должна поддерживать большинство наиболее распространенных СУБД (Oracle, Microsoft SQL Server, MySQL или PostgreSQL).

При разработке необходимо использовать следующие технологии (или эквивалент):

- Spring, для организации связывания функциональных блоков между собой;

- Hibernate, для работы с СУБД;

- Tapestry, для реализации пользовательского интерфейса.

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

Модуль управления данными подсистемы интеграции данных должен обеспечивать:

- организацию маршрутизации, ведение очередей и гарантированную доставку информации, передаваемой между региональными и муниципальными КСА АПК «Безопасный город» и КСА ЕЦОР;

- преобразования различных форматов и протоколов обмена к виду единого унифицированного протокола;

- агрегацию информации, полученной от муниципальных КСА ЕЦОР и при необходимости её передачу в региональные ИС, другие КСА ЕЦОР;

- формирование базы мета-данных по интегрированным в единую информационную среду КСА сегментов АПК «Безопасный город».

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

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

Модуль управления данными должен обеспечивать возможность регистрации новых региональных и муниципальных ИС, КСА и их адаптеров в составе интегрированной среды АПК «Безопасный город».

Конкретный состав и распределение компонентов подсистемы интеграции данных определяется и уточняется на этапе технического проектирования.
4.1.1.2.9Подсистема вычислительных комплексов

Подсистема вычислительных комплексов должна включать в свой состав следующие компоненты:

  • выделенные вычислительные узлы;

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

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

Виртуализируемые вычислительные узлы должны формировать общий пул ресурсов для подсистемы виртуализации.
4.1.1.2.10Транспортная подсистема

Транспортная подсистема должна включать в свой состав следующие компоненты:

  1. Сегмент передачи данных:

    • активное сетевое оборудование уровня ядра;

    • активное сетевое оборудование уровня доступа.

  2. Сегмент управления.

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

Сегмент передачи данных должен включать в себя активное сетевое оборудование уровня ядра и доступа. При необходимости, уровень ядра и уровень доступа могут быть объединены.

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

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

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

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

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

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

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

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

  • устройства хранения (дисковые массивы, системы хранения данных);

  • сеть хранения данных.

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

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

Требования к подсистеме хранения данных:

  • управление системами хранения данных (далее – СХД) должно осуществляться через web-интерфейс и/или командную строку;

  • СХД должна иметь функции мониторинга и несколько вариантов оповещения администратора о неполадках

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

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

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

  • подсистема хранения данных должна обеспечивать достаточную производительность для работы Системы;

  • подсистема должна обеспечивать масштабируемость;

  • подсистема не должна иметь единой точки отказа;

  • СХД должна обеспечивать файловый доступ к данным по протоколам NFS и CIFS(SMB);

  • СХД должна поддерживать пулы хранения данных.
4.1.1.2.12Подсистема виртуализации

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

  • гипервизоры;

  • виртуальные машины (серверы);

  • управляющий модуль.

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

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

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

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

  • периодическое архивирование различных массивов данных;

  • извлечение данных из архива и запись их в соответствующий массив;

  • хранение и учет копий данных.

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

  • управляющий модуль;

  • клиентские модули;

  • узел хранения резервных копий;

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

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

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

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

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

Подсистема администрирования предназначена для установки, изменения и контроля основных параметров системы в процессе его эксплуатации.

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

  • администрирование операционных систем, сетевого и инструментального программного обеспечения, входящего в систему;

  • контроль исправности основных элементов системы;

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

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

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

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

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

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

В Системе предполагается циркуляция информации ограниченного доступа, не содержащей сведения, составляющие государственную тайну, относящейся к следующим видам:

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

  • служебные сведения – информация, доступ к которой ограничен органами государственной власти в соответствии с Гражданским кодексом Российской Федерации и федеральными законами (служебная тайна);

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

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

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

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

  • неправомерных уничтожения или модифицирования информации (обеспечение целостности информации);

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

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

  • идентификацию и аутентификацию субъектов доступа и объектов доступа;

  • управление доступом субъектов доступа к объектам доступа;

  • ограничение программной среды;

  • защиту машинных носителей информации;

  • регистрацию событий безопасности;

  • антивирусную защиту;

  • обнаружение (предотвращение) вторжений;

  • контроль (анализ) защищенности информации;

  • целостность Системы и информации;

  • доступность информации;

  • защиту среды виртуализации;

  • защиту технических средств;

  • защиту Системы, ее средств, систем связи и передачи данных.

Детальный состав технических и организационных мер защиты, используемых при разработке ПОИБ Системы, согласно требованиям Приказа №17, должен быть определен на основании:

  • требуемого класса защищенности Системы;

  • актуальных угроз информационной безопасности;

  • требований к мерам и средствам защиты информации, применяемых в Системе;

  • требований к защите информации при информационном взаимодействии ИС с иными Системами.

В соответствии с п. 14.2 Приказа №17 ФСТЭК от 11.02.2013 устанавливается класс защищённости Системы не ниже К3.

Для обеспечения защиты информации должны применяться средства защиты информации, прошедшие оценку соответствия в форме обязательной сертификации на соответствие требованиям по безопасности информации в соответствии с ФЗ №184 «О техническом регулировании» от 27 декабря 2002 г.

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

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

1   ...   5   6   7   8   9   10   11   12   ...   23

Похожие:

Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание на выполнение работ по монтажу муниципального...
«Безопасный город» Самарской области в рамках Распоряжения Правительства Российской Федерации от 03. 12. 2015 №2446-р об утверждении...
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание на проектирование и построение опытных участкаов...
Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты 9
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание на проектирование и построение опытного участка...
Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты 9
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание на проектирование, создание и техническое обслуживание...
Целью работ является создание комплексной системы обеспечения безопасности населения путем решения следующих основных задач
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание На 103 листах
Выполнение работ по разработке составной части технического проекта и рабочей документации в целях выполнения опытно-конструкторской...
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание на разработку проектно-сметной документации развития...
Назначение, цель и задачи развития сегментов апк «Безопасный город» на территории Республики Коми 7
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание на выполнение проектных работ по модернизации...
На выполнение проектных работ по модернизации систем оповещения в рамках выполнения опытно-конструкторской работы по созданию опытного...
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание на выполнение работ по разработке технического...
«Безопасный город» на территориях пилотных зон в составе муниципальных образований Ханты-Мансийского автономного округа – Югры
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Бюллетень
Утвердить прилагаемый состав Межведомственной комиссии по вопросам, связанным с внедрением и развитием систем аппаратно-программного...
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание на выполнение опытно-конструкторской работы и...
Направляю вам Техническое задание на выполнение опытно-конструкторской работы и создание опытного образца программно-аппаратного...
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon К Техническому заданию на выполнение опытно-конструкторской работы...
Техническому заданию на выполнение опытно-конструкторской работы и создание опытного образца систем аппаратно-программного комплекса...
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание на заключение Договора финансовой аренды (лизинга)...
Фгуп «Почта России» (Заказчик) извещает о внесении изменений в документацию №31401253481 о проведении редукциона на право заключения...
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание на проектирование апк «безопасный город»
Совет главных конструкторов автоматизированной информационно-управляющей системы рсчс
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание на проектирование и построение опытных участков апк «Безопасный город»
Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты 11
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание на проектирование и построение опытных участков апк «безопасный город»
Комплексная система экстренного оповещения населения об угрозе возникновения или о возникновении чрезвычайных ситуаций
Техническое задание на проектирование аппаратно-программного комплекса «безопасный город» icon Техническое задание на выполнение работ по «Модернизации аппаратно-программного...
«Модернизации аппаратно-программного комплекса (апк) по проверке аппаратуры па-м жипс. 421427. 062 для выполнения проверки аппаратуры...

Руководство, инструкция по применению




При копировании материала укажите ссылку © 2024
контакты
rykovodstvo.ru
Поиск