пример технического задания. Техническое задание (3). 1. 1Полное наименование работ 3 2Сокращенное наименование работ 4

• Название: 1. 1Полное наименование работ 3 2Сокращенное наименование работ 4
• Анкор: пример технического задания
• Дата: 03.09.2021
• Размер: 1.97 Mb.
• Имя файла: Техническое задание (3).docx
• Тип: Документы; #229137
• страница: 11 из 25

Требования, предъявляемые к составу и содержанию работ по развитию системы

1. Требования к системе в целом при выполнении работ по развитию системы

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

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

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

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

Штатные средства Системы должны позволять проводить базовые работы по администрированию Системы.

Доступ пользователей Системы к Системе должен осуществляться в режиме тонкого клиента (работа пользователя Системы осуществляется через веб-браузер), функционирующего в различных операционных средах: Microsoft Windows, Unix (Linux), MacOS.

1. Требования к структуре и функционированию системы

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

ЕИС МЖИ находится в режиме эксплуатации в составе следующих подсистем и модулей:

• 
  подсистема «Правовая экспертиза»;
  
• 
  подсистема работы с НСИ;
  
• 
  подсистема «Инспекционная деятельность»;
  
• 
  подсистема «Судебное представительство»;
  
• 
  подсистема «Реестр ТСН г.Москвы»;
  
• 
  подсистема «Мониторинг зданий с большепролетными конструкциями».
  
• 
  подсистема «Переустройство и перепланировка»;
  
• 
  Отчетная подсистема;
  
• 
  подсистема Администрирования;
  
• 
  подсистема «Реестр сведений о лицензиатах»;
  
• 
  подсистема «Контроль ведения специальных счетов капитального ремонта многоквартирных домов».
  

В рамках работ по развитию Системы должна быть создана подсистема «Информационное взаимодействие».

1. Подсистема «Инспекционная деятельность»

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

Класс подсистемы – обеспечение деятельности ОИВ. Предусмотрено размещение компонентов подсистемы на мобильных устройствах (МАРМ инспектора). Доработка МАРМ в рамках данного ТЗ не предусматривается.

2. Подсистема «Судебное представительство»

Подсистема автоматизирует деятельность МЖИ по участию в судебных делах, не связанных с рассмотрением, дел об административных правонарушениях, а именно, работа правового управления и структурных подразделений МЖИ.

Класс подсистемы – обеспечение деятельности ОИВ. Размещение компонентов подсистемы на мобильных устройствах не предусмотрено.

3. Подсистема «Правовая экспертиза»

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

Класс подсистемы – обеспечение деятельности ОИВ. Размещение компонентов подсистемы на мобильных устройствах не предусмотрено.

4. Подсистема «Реестр ТСН г.Москвы»

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

Класс подсистемы – обеспечение деятельности ОИВ. Размещение компонентов подсистемы на мобильных устройствах не предусмотрено.

5. Подсистема «Мониторинг зданий с большепролетными конструкциями»

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

Класс подсистемы – обеспечение деятельности ОИВ. Размещение компонентов подсистемы на мобильных устройствах не предусмотрено.

6. Подсистема «Переустройство и перепланировка»

Подсистема автоматизирует деятельность МЖИ по предоставлению государственной услуги «Согласование переустройства и (или) перепланировки помещений в многоквартирном доме и оформление приемочной комиссией акта о завершенном переустройстве и (или) перепланировке помещений в многоквартирном доме».

Класс подсистемы – обеспечение деятельности ОИВ. Размещение компонентов подсистемы на мобильных устройствах не предусмотрено.

7. Отчетная подсистема

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

Класс подсистемы – обеспечение деятельности ОИВ. Размещение компонентов подсистемы на мобильных устройствах не предусмотрено.

8. Подсистема работы с НСИ

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

Класс подсистемы – обеспечение деятельности ОИВ. Размещение компонентов подсистемы на мобильных устройствах не предусмотрено.

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

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

Класс подсистемы – обеспечение деятельности ОИВ. Размещение компонентов подсистемы на мобильных устройствах не предусмотрено.

10. Подсистема «Реестр сведений о лицензиатах»

Подсистема автоматизирует деятельность МЖИ по регистрации заявлений на предоставление Государственной жилищной инспекцией города Москвы услуги по лицензированию предпринимательской деятельности по управлению многоквартирными домами в городе Москве и учета лицензий на осуществление предпринимательской деятельности по управлению многоквартирными домами.

Класс подсистемы – обеспечение деятельности ОИВ. Размещение компонентов подсистемы на мобильных устройствах не предусмотрено.

11. Подсистема «Контроль ведения специальных счетов капитального ремонта многоквартирных домов»

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

Класс подсистемы – обеспечение деятельности ОИВ. Размещение компонентов подсистемы на мобильных устройствах не предусмотрено.

12. Модуль взаимодействия с клиентом ТМ АРМ инспектора

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

Класс модуля – обеспечение деятельности ОИВ. Размещается на мобильных устройствах.

13. Подсистема «Информационное взаимодействие»

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

Класс подсистемы – обеспечение деятельности ОИВ. Размещение компонентов подсистемы на мобильных устройствах не предусмотрено.

2. Требования к характеристикам взаимосвязей развиваемой системы со смежными системами, обеспечению ее совместимости

Интеграция со смежными системами должна осуществляться по стандартизированным протоколам таким, как SOAP, REST, XML-RPC в форматах *.json и/или *.xml.

Обмен информацией с внешними системами должен осуществляться в соответствии с требованиями, предъявляемыми к организации информационного взаимодействия Системы, с учетом постановления Правительства Москвы от 21 декабря 2011 г. № 604-ПП «Об утверждении положения об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие органов исполнительной власти города Москвы и организаций при предоставлении государственных услуг и исполнении государственных функций в городе Москве».

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

• 
  АС ГУФ;
  
• 
  ИС РНиП;
  
• 
  ЕЦХД;
  
• 
  ГИС РД;
  
• 
  ИАИС ЕГИП;
  
• 
  ГИС ЕХД;
  
• 
  АИС ДКР;
  
• 
  АС УР;
  
• 
  ГИС ЕМП;
  
• 
  СУДИР;
  
• 
  СУФД;
  
• 
  АИС «Контроль «одно окно»;
  
• 
  ИС ПДПС (СОЭСГ);
  
• 
  ИС РСКР;
  
• 
  ФГИС ЕРП;
  
• 
  ГИС «ЦХЭД ЭЦП»;
  
• 
  РСМЭВ;
  
• 
  ФИАС;
  
• 
  АСУ ЕИРЦ.
  

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

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

3. Требования к режимам функционирования

Система должна функционировать круглосуточно без перерывов 24 (двадцать четыре) часа в сутки, 7 (семь) дней в неделю.

Возможные режимы функционирования Системы:

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

Основным режимом функционирования является штатный режим. В сервисный режим Система переходит в следующих случаях:

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

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

4. Требования по диагностированию системы

Для диагностирования Системы должны использоваться штатные средства программно-аппаратного комплекса.

Диагностика программных средств должна осуществляться с помощью стандартных режимов сетевой ОС, ОС АРМ и СУБД, а также путем прогона контрольного примера.

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

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

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

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

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

• 
  отказы системного ПО;
  
• 
  отказы ППО;
  
• 
  отказов в результате ошибок обслуживающего персонала и пользователей Системы.
  

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

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

2. Требования к персоналу

   1. Требования к численности персонала системы

Персонал Системы должен состоять из категорий:

• 
  обслуживающий персонал;
  
• 
  пользователи Системы.
  

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

2. Требования к порядку подготовки и контроля знаний и навыков пользователей

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

3. Требования к квалификации персонала

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

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

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

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

Обслуживающий персонал должен обладать:

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

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

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

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

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

4. Требуемый режим работы персонала системы

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

3. Требования к эргономике и технической эстетике

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

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

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

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

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

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

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

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

Для обеспечения соответствия современным нормам дизайна и эргономики программного обеспечения, а также повышения степени доверия пользователей к Системе необходимо выполнить работы по созданию макетов пользовательского интерфейса, UI kit пользовательских интерфейсов Системы (графическая библиотека элементов интерфейса пользовательского интерфейса). 

Формы для создания макетов должны быть выбраны таким образом и в таком количестве, чтобы можно было ознакомиться с ключевыми особенностями и общим стилем предлагаемого решения.

UI kit Системы должен представлять собой графическую библиотеку элементов интерфейса для дальнейшего использования при разработке приложений и быть выполнен на основе UI kit предоставленным Заказчиком.

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

UI kit и макеты пользовательского интерфейса должны быть разработаны и/ или актуализированы в рамках формирования ЧТЗ.

4. Требования к защите информации от несанкционированного доступа

В соответствии с требованиями Приказа ФСТЭК России от 11 февраля 2013 г. № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» протоколом заседания комиссии по определению типа актуальных угроз безопасности персональных данных, уровня защищенности персональных данных при их обработке в информационных системах и по классификации информационных систем по требованиям защиты информации, созданной в соответствии с распоряжением Департамента информационных технологий города Москвы от 13 июля 2017 г. № 64-16-309/17 определен третий класс (К3) защищенности информационной системы, установлена необходимость обеспечения 4-го уровня защищенности персональных данных при их обработке в информационной системе, в случае необходимости пересмотра класса защищенности Системы, необходимо подготовить проект акта классификации.

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

Для определения угроз безопасности информации и разработки (актуализации) документа «Модель угроз и нарушителя безопасности информации» должны применяться методические документы, разработанные ФСТЭК России, в том числе проект методического документа ФСТЭК России «Методика определения угроз безопасности информации в информационных системах», также при рассмотрении совокупности предположений о возможностях, которые могут использоваться при создании способов, подготовке и проведении атак, необходимо применять «Методические рекомендации по разработке нормативных правовых актов, определяющих угрозы безопасности персональных данных, актуальные при обработке персональных данных в информационных системах персональных данных, эксплуатируемых при осуществлении соответствующих видов деятельности» (утв. ФСБ России 31 марта 2015 г. № 149/7/2/6-432) и Приказом ФСБ России от 10 июля 2014 г. № 378. В качестве исходных данных для определения перечня угроз безопасности информации используются Банк данных угроз безопасности информации ФСТЭК России (bdu.fstec.ru) и иные источники, содержащие сведения об уязвимостях и угрозах безопасности информации. На основании пункта 14.3 Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденных приказом ФСТЭК России от 11 февраля 2013 г. № 17, угрозы безопасности информации, определяются, в том числе, по результатам анализа возможных уязвимостей информационной системы. При анализе уязвимостей информационной системы проверяется отсутствие известных уязвимостей технических средств и программного обеспечения.

Во исполнение Приказа Федеральной службы по техническому и экспортному контролю от 11 февраля 2013 г. № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» необходимо провести работы по реализации требований описанных в пунктах 4.2.1.4.1-4.2.1.4.4 ТЗ, используя встроенные функции безопасности ППО, либо провести работы по интеграции ЕИС МЖИ с программно-аппаратным комплексом защиты информации комплекса городского хозяйства с целью защиты информации, содержащейся в Системе.

В рамках ТЗ не предусмотрено создание системы защиты информации и последующая аттестация ЕИС МЖИ по требованиям безопасности информации.

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

1. Идентификация и аутентификация субъектов доступа и объектов доступа

Идентификация и аутентификация субъектов доступа и объектов доступа должны включать:

• 
  Идентификация и аутентификация пользователей Системы (мера ИАФ.1), Аутентификация пользователя Системы должна осуществляться с использованием паролей;
  
• 
  Управление идентификаторами, в том числе создание, присвоение, уничтожение идентификаторов (мера ИАФ.3).
  

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

• 
  Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации (мера ИАФ.4).
  

Должны быть установлены и реализованы следующие функции управления средствами аутентификации (аутентификационной информацией) пользователей Системы в ЕИС МЖИ:

• 
  Установление характеристик пароля:
  

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

Назначение необходимых характеристик средств аутентификации (в том числе механизма пароля).

Обновление аутентификационной информации (замена средств аутентификации) с установленной периодичностью.

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

• 
  длина пароля не менее шести символов, алфавит пароля не менее 60 (шестидесяти) символов;
  
• 
  максимальное количество неуспешных попыток аутентификации (ввода неправильного пароля) до блокировки – 10 (десять) попыток;
  
• 
  блокировка программно-технического средства или учетной записи пользователя Системы в случае достижения установленного максимального количества неуспешных попыток аутентификации на время - 5 (пять) минут;
  
• 
  смена паролей не более чем через 120 (сто двадцать) календарных дней;
  

• 
  защита обратной связи при вводе аутентификационной информации (мера ИАФ.5).
  

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

• 
  Идентификация и аутентификация пользователей Системы, не являющихся работниками оператора (внешних пользователей Системы) (мера ИАФ.6).
  

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

2. Управление доступом субъектов доступа к объектам доступа

Управление доступом субъектов доступа к объектам доступа должно включать:

• 
  Управление (заведение, активация, блокирование и уничтожение) учетными записями пользователей Системы, в том числе внешних пользователей Системы (мера УПД.1).
  

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

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

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

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

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

• 
  дискреционный;
  
• 
  ролевой;
  
• 
  мандатный.
  

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

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

• 
  Разделение полномочий (ролей) пользователей Системы, администраторов и лиц, обеспечивающих функционирование Системы (мера УПД.4)
  

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

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

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

• 
  Ограничение неуспешных попыток входа в Систему (доступа к Системе) (мера УПД.6).
  

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

Ограничение количества неуспешных попыток входа в Систему (доступа к Системе) должно обеспечиваться в соответствии с ИАФ.4.

• 
  Блокирование сеанса доступа в Системе после установленного времени бездействия (неактивности) пользователя Системы или по его запросу (мера УПД.10).
  

Блокирование идентификатора пользователя Системы через период времени должно обеспечиваться в соответствии с ИАФ.3.

3. Регистрация событий безопасности

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

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

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

• 
  Защита информации о событиях безопасности (мера РСБ.7).
  

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

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

4. Контроль (анализ) защищенности информации

Контроль (анализ) защищенности информации - контроль правил генерации и смены паролей пользователей Системы, заведения и удаления учетных записей пользователей Системы, реализации правил разграничения доступа, полномочий пользователей в Системе (мера АНЗ.5).

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

• 
  контроль правил генерации и смены паролей пользователей Системы в соответствии с ИАФ.1 и ИАФ.4;
  
• 
  контроль заведения и удаления учетных записей пользователей Системы в соответствии с УПД.1;
  
• 
  контроль реализации правил разграничения доступом в соответствии с УПД.2;
  
• 
  контроль реализации полномочий пользователей Системы в соответствии с УПД.4 и УПД.5.
  

5. Требования по сохранности информации при авариях

Сохранность информации в Системе должна обеспечиваться:

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

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

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

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

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

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

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

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

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

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

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

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

7. Требования к регламентам и объемам резервного копирования и архивирования данных

Резервное копирование информации может осуществляться в двух режимах:

• 
  создание полной копии базы данных;
  
• 
  сохранение изменений, внесенных со времени создания последней архивной копии (архивные копии лог-файлов).
  

Периодичность и очередность этих операций определяются политикой резервного копирования информации площадки размещения.

8. Требования к патентной чистоте

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

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

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

2. Требования к использованию лицензионного программного обеспечения

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

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

9. Требования по стандартизации и унификации

Экранные формы должны быть реализованы с учетом требований по унификации:

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

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

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

10. Требования к электронным учебным курсам

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

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

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

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

1. Требования по соответствию электронных курсов международным стандартам

Электронные учебные курсы должны соответствовать требованиям стандарта SCORM 2004. (Разработчик стандарта Advanced Distributed Learning (ADL) http://www.adlnet.org/).

Согласно требованиям SCORM 2004, электронные учебные курсы должны содержать три основных компонента:

• 
  язык взаимодействия программ (run-time communications) — стандартный язык, на котором обучающая программа «общается» с системой дистанционного обучения (СДО);
  
• 
  метаданные о курсе. Каждый фрагмент курса должен соотноситься с определенным файлом метаданных, в котором содержатся указания на то, что этот фрагмент собой представляет и где находится;
  
• 
  файл-манифест / пакет содержания (Content package). Этот файл должен содержать полное описание курса обучения и составляющих его файлов. Документ (The manifest) о Едином пакете содержания (Content Packages) SCORM описывается через Extensible Markup Language (XML) (файл “imsmanifest.xml”).
  

2. Требования к формату используемых в курсе файлов

К формату используемых в курсе файлов предъявляются следующие требования:

• 
  возможность вставки в курсы любого Rich-media содержимого: Macromedia® Flash®, Shockwave®, Java®, видео в форматах (AVI, WMV, MPEG, MOV, RM, FLV);
  
• 
  простые механизмы вставки и синхронизации звукового сопровождения в форматах: AIFF, WMA, MP3, WAV, SWF;
  
• 
  присоединяемые внешние документы могут быть: Текстовый файл (TXT), HTML файл, Rich Text Format (RTF), Microsoft Word (DOC), Microsoft Excel (XLS), Adobe PDF, Архив ZIP, Архив RAR и т.д.