Требования к разрабатываемому федеральному сегменту межведомственной системы
-
Общие требования к системе
Создание федерального сегмента Межведомственной системы должно основываться на применении следующих принципов:
учет Контингента обучающихся в Межведомственной системе со дня государственной регистрации рождения и начала обучения в организациях, осуществляющих образовательную деятельность;
обеспечение условий для персонифицированного учета данных о Контингенте обучающихся;
наполнение Межведомственной системы данными из информационных систем различных органов государственной власти и государственных внебюджетных фондов в объеме, необходимом для достижения целей, определенных в разделе 3.2 настоящего документа;
использование для информационного обмена между элементами Межведомственной системы и ведомственными информационными системами, инфраструктуры обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг, а также исполнения государственных функций в электронной форме, в том числе: СМЭВ, ЕСИА, ЕС НСИ;
использование страхового номера индивидуального лицевого счета, в качестве единого идентификатора Персоны для осуществления межведомственного информационного взаимодействия;
соблюдение установленных законодательством Российской Федерации требований по защите персональных данных от несанкционированного доступа.
-
Требования к структуре и функционированию системы
Федеральный сегмент Межведомственной системы должен состоять из следующих компонентов:
Подсистема администрирования;
Подсистема обеспечения информационной безопасности;
Подсистема сбора, хранения и верификации данных;
Подсистема управления данными о Персонах, педагогических работниках и организациях;
Подсистема управления нормативно-справочной информацией;
Подсистема анализа данных;
Подсистема интеграций с внешними системами;
Портал.
Более подробная структура функциональных компонентов федерального сегмента представлена на рисунке 1 (см. рисунок 1).
 Рисунок 1. Структура функциональных компонентов федерального сегмента Межведомственной системы.
-
Требования к способам и средствам связи для информационного обмена между компонентами системы
Входящие в состав Системы подсистемы в процессе функционирования должны осуществлять обмен информацией на основе открытых форматов обмена данными, используя для этого входящие в их состав модули информационного взаимодействия.
Форматы данных и способы взаимодействия должны быть определены и согласованы с Заказчиком на этапе технического проектирования.
-
Требования к характеристикам взаимосвязей создаваемой системы со смежными системами
Должны быть разработанысервисы информационного взаимодействия федерального сегмента Межведомственной системы со следующими смежными системами, являющимися участниками взаимодействия:
ИС федеральных органов исполнительной власти и государственных внебюджетных фондов, указанных в пункте 6.1.1.2.1 Технического задания;
элементы инфраструктуры электронного правительства;
региональные сегменты Межведомственной системы;
сегмент высшего образования Межведомственной системы.
-
Требования к взаимодействию с ФОИВ и государственными внебюджетными фондами
Должны быть разработаны прототипы сервисов информационного взаимодействия федерального сегмента Межведомственной системы, а также требования к доработкам информационных систем ФОИВ и государственных внебюджетных фондов (разработка технических регламентов информационного взаимодействия между федеральным сегментом и ИС ФОИВ).
К федеральным органам исполнительной власти и государственных внебюджетных фондов, информационные системы которых являются источниками сведений для федерального сегмента Межведомственной системы, относятся:
Федеральная налоговая служба Российской Федерации– с целью проверки сведений об организациях, осуществляющих образовательную деятельность;
Пенсионный фонд Российской Федерации – с целью проведения соответствующей проверки фамильно – именной группы и СНИЛС, а также предоставления СНИЛС на основе фамильно-именной группы;
Федеральная миграционная служба Российской Федерации – с целью проверки действительности регистрации гражданина Российской Федерации, иностранных граждан, лиц без гражданства по месту пребывания и месту жительства, а также с целью проверки действительности паспортов граждан Российской Федерации;
Министерство здравоохранения Российской Федерации – ограниченные сведения о группе здоровья Контингента обучающихся, в том числе потребности в адаптированной основной общеобразовательной программе;
Министерство труда и социальной защиты Российской Федерации – ограниченные сведения по инвалидности Контингента обучающихся, в том числе потребности в адаптированной основной общеобразовательной программе;
Федеральная служба по надзору в сфере образования и науки Российской Федерации – данные о результатах ЕГЭ и об организациях, осуществляющих образовательную деятельность по имеющим государственную аккредитацию образовательным программам.
При реализации взаимодействия в рамках межведомственной системы должен использоваться СМЭВ 3.0 как ключевой элемент для унификации взаимодействия с федеральными органами исполнительной власти, а также для обеспечения защищенного канала связи для передачи сведений.
Состав информации, используемой при взаимодействии федерального сегмента Межведомственной системы с ИС ФОИВ и государственных внебюджетных фондов, должен быть определен и согласован с Заказчиком на этапе технического проектирования.
Тестирование прототипа сервиса взаимодействия необходимо осуществляется с эмулятором информационных систем ФОИВ и внебюджетных фондов, разрабатываемым исполнителем.
-
Требования к взаимодействию с региональными сегментами Межведомственной системы.
Должен быть разработан сервис информационного взаимодействия федерального сегмента Межведомственной системы с региональными сегментами.
Сервис информационного взаимодействия должен обеспечивать двустороннее взаимодействие (прием и передачу данных) между федеральным сегментом и региональными сегментами по защищенному каналу связи, обеспечивающий выполнение следующих функций:
получение из регионального сегмента учетных данных о Контингенте обучающихся с соблюдением формата и структуры данных, установленных техническим регламентом информационного взаимодействия федерального сегмента с региональными сегментами (далее – Регламент взаимодействия);
получение из регионального сегмента данных об образовательных достижениях обучающихся в образовательных организациях с соблюдением формата и структуры данных, установленных Регламентом взаимодействия;
получение из регионального сегмента сведений об организациях, осуществляющих образовательную деятельность, сведения об оказываемых образовательных услугах, реализуемых образовательных программах и иных сведений, с соблюдением формата и структуры данных, установленных Регламентом взаимодействия;
получение из регионального сегмента сведений о педагогических работниках с соблюдением формата и структуры данных, установленных Регламентом взаимодействия;
обеспечение проверки сведений о Контингенте обучающихся, об организациях, осуществляющих образовательную деятельность, о педагогических работниках, полученных из регионального сегмента на соответствие сведениям, содержащихся в ИС ФОИВ;
взаимодействие с региональными сегментами при миграции Персоны, в том числе запрос и передача всех сведений между региональными сегментами;
передача в региональный сегмент необходимых сведений, получаемых федеральным сегментом Межведомственной системы из ИС ФОИВ;
передача информации в региональный сегмент о дублировании данных о Контингенте обучающихся, образовательных организациях, педагогических работниках;
загрузка из регионального сегмента аналитической и статистической информации по региону;
выгрузка в региональный сегмент нормативно-справочной информации.
Функции интеграции должны быть реализованы совокупностью программных компонент федерального сегмента, обеспечивающих выполнение следующих функциональных требований:
обеспечение возможности обмена данными между федеральным сегментом и региональными сегментами путем обмена файлами и/или данными в составе виртуальных конвертов сообщений, отправляемых по установленным защищенным каналам и в рамках интерфейсов взаимодействия;
обеспечение требуемого законодательством уровня защищенности данных, передаваемых из региональных сегментов;
обеспечение целостности данных, передаваемых из региональных сегментов;
обеспечение заданного формата данных, передаваемых из региональных сегментов;
обеспечение возможности выгрузки в федеральный сегмент Межведомственной системы, выбранных данных из регионального сегмента по сформированному запросу.
При реализации взаимодействия в рамках межведомственной системы должен использоваться СМЭВ 3.0 как ключевой элемент для унификации взаимодействия с федеральными органами исполнительной власти, а также для обеспечения защищенного канала связи для передачи сведений.
Состав информации, используемой при взаимодействии федерального и региональных сегментов Межведомственной системы, должен быть определен и согласован с Заказчиком на этапе технического проектирования.
Апробация взаимодействия осуществляется в случае адаптации выбранными пилотными субъектами региональных сегментов Межведомственной системы в срок до 5 декабря 2015 г. с целью обеспечения информационного взаимодействия. В случае отсутствия на 5 декабря 2015 г. адаптированных региональных сегментов Межведомственной системы тестирование производится на эмуляторе регионального сегмента, предоставляемом исполнителем.
-
Требования к взаимодействию с сегментом высшего образования
Должен быть разработан сервис информационного взаимодействия федерального сегмента Межведомственной системы с сегментом высшего образования.
Сервис информационного взаимодействия должен обеспечивать двустороннее взаимодействие (прием и передачу данных) между федеральным сегментом и сегментом высшего образования по защищенному каналу связи, обеспечивающий выполнение следующих функций:
обеспечение возможности обмена данными между федеральным сегментом и сегментом высшего образованияпутем обмена файлами и/или данными в составе виртуальных конвертов сообщений, отправляемых по установленным защищенным каналам и в рамках интерфейсов взаимодействия;
обеспечение требуемого законодательством уровня защищенности данных, передаваемых из сегмента высшего образования;
обеспечение целостности данных, передаваемых из сегмента высшего образования;
обеспечение заданного формата данных, передаваемых из сегмента высшего образования;
обеспечение возможности выгрузки в федеральный сегмент Межведомственной системы, выбранных данных из сегмента высшего образования по сформированному запросу.
При реализации взаимодействия в рамках Межведомственной системы должен использоваться СМЭВ 3.0 как ключевой элемент для унификации взаимодействия с федеральными органами исполнительной власти, а также для обеспечения защищенного канала связи для передачи сведений.
Состав информации, используемой при взаимодействии федерального сегмента и сегмента высшего образования Межведомственной системы, должны быть определены и согласованы с Заказчиком на этапе технического проектирования.
Апробация взаимодействия осуществляется в случае адаптации сегмента высшего образования Межведомственной системы в срок до 5 декабря 2015 г. с целью обеспечения информационного взаимодействия. В случае отсутствия на 5 декабря 2015 г. адаптированного сегмента высшего образования Межведомственной системы тестирование производится на эмуляторе сегмента высшего образования, предоставляемом исполнителем.
-
Требования к взаимодействию с элементами инфраструктуры электронного правительства
В рамках создания федерального сегмента Межведомственной системы должно быть обеспечено взаимодействие со следующими элементами инфраструктуры электронного правительства:
ЕСИА – федеральная государственная информационная система «Единая система идентификации и аутентификации в инфраструктуре обеспечивающей информационно технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме».
ЕСНСИ – федеральная государственная информационная система «Единая система нормативно-справочной информации».
ЕСИА должна использоваться для обеспечения авторизации и аутентификации операторов, администраторов и пользователей при работе с Межведомственной системой. Применение ЕСИА как средства идентификации и аутентификации при работе Межведомственной системы обусловлено выполнением Постановления Правительства от 10 июля 2013 г. № 584 «Об использовании федеральной государственной информационной системы «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме».
Компоненты федерального сегмента должны взаимодействовать с ЕСНСИ как основным источником и средством получения нормативно-справочной информации федерального уровня.
Способ взаимодействия и состав информации, используемой при взаимодействии федерального сегмента Межведомственной системы с элементами инфраструктуры электронного правительства, должны быть определены и согласованы с Заказчиком на этапе технического проектирования.
-
Требования к режимам функционирования системы
Федеральный сегмент Межведомственной системы должен иметь следующие основные режимы функционирования:
штатный режим – основной режим функционирования, когда выполняется полный набор требуемых функций с максимальной производительностью;
режим системного администрирования – используемый для сопровождения, в том числе изменения конфигурации, параметров работы, настроек, выполнения регламентного обслуживания программно-технических средств;
аварийный режим – режим, в котором один, или несколько компонентов Межведомственной системы ограничивают реализуемую функциональность в случае обнаружения ошибок, которые не обязательно приводят к полной остановке обслуживания (например, недоступность какой-либо из не критичных БД или внешних систем).
-
Требования к численности и квалификации персонала системы и режиму его работы
В Системе должно быть предусмотрено разделение пользователей по типам. Должны быть представлены следующие типы пользователей:
Оператор Системы - Министерство связи и массовых коммуникаций Российской Федерации;
Администратор Системы - Министерство связи и массовых коммуникаций Российской Федерации;
Пользователь Системы - Министерство образования и науки Российской Федерации.
Численность и квалификация персонала Системы должны определяться с учетом следующих требований:
структура и конфигурация Системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала;
структура Системы должна предоставлять возможность управления всем доступным функционалом Системы как одному администратору, так и предоставлять возможность разделения ответственности по администрированию между несколькими администраторами;
для администрирования Системы к администратору не должны предъявляться требования по знанию всех особенностей функционирования элементов, входящих в состав администрируемых компонентов Системы;
аппаратно-программный комплекс Системы не должен требовать круглосуточного обслуживания и присутствия администраторов у консоли управления.
Штатный состав персонала, эксплуатирующего Систему, должен формироваться на основании нормативных документов Российской Федерации, Трудового кодекса Российской Федерации, штатного расписания организации, эксплуатирующей Систему и внутренних регламентов организации, эксплуатирующей Систему.
Все специалисты должны работать с нормальным графиком работы не более 8 часов в сутки.
Система реализуется на персональных компьютерах, поэтому требования к организации труда и режима отдыха при работе с ней должны устанавливаться, исходя из требований к организации труда и режима отдыха при работе с этим типом средств вычислительной техники.
Деятельность персонала по эксплуатации Системы должна регулироваться должностными инструкциями. Должностные инструкции должны быть приведены в томе «Технологическая инструкция» комплекта эксплуатационной документации.
Программно-аппаратный комплекс должен иметь возможность работы в режиме «автоматического резервирования», когда основная рабочая часть системы переключается на резервную автоматически с возможной потерей состояния пользовательских и служебных сессий.
Программно-аппаратный комплекс должен поддерживать механизмы горизонтального масштабирования для обеспечения роста емкости входящих в него систем и компонентов по схеме N+1, 1+1, или по гибридной схеме, в зависимости от того какая из них обеспечит заданные параметры по доступности и отказоустойчивости при минимальных затратах на оборудование и эксплуатацию. При подключении новых узлов должно происходить автоматическое распределение нагрузки на дополнительно подключаемые вычислительные мощности без прерывания работы основных узлов.
Обновление ПО и отмена обновления ПО на резервированной масштабируемой конфигурации системы должны длиться не более 1 часа, при этом функционирование системы не должно прерываться. Обновление и отмена должны происходить последовательно на резервной, а затем на основной частях Системы.
ПО должно обеспечивать механизмы журналирования и автоматизированного предоставления журналов по всем основным функциям ИС во внешнюю систему журналирования для дальнейшей статистической обработки.
ПО должно обеспечивать механизмы мониторинга всех основных функций ПО для оперативного отслеживания ошибок и сбоев, а также автоматическое информирование систем мониторинга о критических ошибках и угрозах сбоев в работе ПО. Параметры мониторинга качества функционирования услуг и сервисов, их пороговые значения, параметры нагрузки и соответствующие формы отчетности должны быть согласованы с Заказчиком на этапе проектирования системы.
ПО должно реализовывать автоматизированные механизмы тестовых сценариев работы ИС по основным функциям для оперативной проверки и мониторинга функционирования.
Программно-аппаратная архитектура, удовлетворяющая выше сформулированным требованиям, должна быть спроектирована Исполнителем и согласована с Заказчиком на этапе подготовки технического проекта.
-
Требования к эргономике и технической эстетике
При создании Системы следует руководствоваться стандартом ГОСТ Р 9241-210-2012 «Эргономика взаимодействия человек-система. Часть 210. Человеко-ориентированное проектирование интерактивных систем», а также интерфейсными стандартами производителей или операционных систем, в рамках которых будет использоваться Система.
Если разрабатываемая Система предполагает наличие web-интерфейса, предназначенного для внешних пользователей, то он должен соответствовать требованиям стандарта ГОСТ Р 52872-2012 «Интернет-ресурсы. Требования доступности для инвалидов по зрению (уровень А)».
-
Общие требования к интерфейсу разрабатываемой системы
Каждый экран Системы должен содержать название раздела или операции, которая совершается на данном экране. Если экран представляет собой шаг из последовательности для решения задачи, должно быть указано название раздела или операции, а также номера шага, который выполняется.
На каждом уровне навигации Системы не должно быть более 8 элементов (включительно). Если их 9 (девять) или более, следует разделить список на несколько групп (создать дополнительный уровень навигации).
Элементы каждого уровня навигации Системы должны быть отсортированы, начиная от самых важных и часто используемых пунктов. Важность пунктов определяется исходя из задач пользователей (определенных в ролевой модели).
Элементы навигации должны быть четко дифференцированы (не должно быть одинаковых или похожих разделов — как по сути, так и по звучанию).
Иерархия подразделов Системы должна четко прослеживаться (должно быть понятно, в какой раздел входят данные подразделы, в случае их наличия).
Текущий пункт меню должен быть выделен визуально.
На любой странице Системы с уровнем вложенности 3 (три) и более должна использоваться последовательность ссылок на страницы более высокой иерархии, начиная от главной страницы и заканчивая страницей одним уровнем выше текущей.
Навигация, расположение названия раздела, расположение ссылки для возврата на стартовый экран (главную страницу) Системы должны быть единообразными для каждого экрана системы.
Одинаковые задачи в Системе, в рамках как минимум одного типа устройств, должны решаться одинаковыми способами (использовать одинаковые способы взаимодействия, элементы управления и т.д.).
Одинаковые сущности в интерфейсе Системы должны именоваться одинаково, если возможно дать им русскоязычные названия – следует использовать их, избегая американизмов (к примеру, вместо «логин» следует использовать термин «имя пользователя»).
Разные сущности Системы не должны называться одинаково или иметь похожее название (названия не должны быть похожи ни по смыслу, ни, по написанию и звучанию).
Одинаковые сущности Системы, даже в рамках разных типов устройств, должны называться одинаково. Допустимо отличие в количестве доступных действий. В интерфейсе Системы должна использоваться лексика из словаря основной целевой аудитории, представители которой будут работать с системой (особенно это касается названий разделов и ключевых ссылок).
Интерфейс Системы должен давать ответ на любое действие пользователя с интерактивным элементом. Интерактивные элементы после их активации должны совершать указанное действие (открывать новую страницу, совершать поиск и т.п.).
Интерактивные элементы Системы должны выделяться цветом, подчеркиванием, использовать привычные паттерны иконок, менять свой вид при наведении мыши и прочее.
Размер экранов Системы должен быть адаптирован для размеров экранов устройств, с помощью которых пользователи будут работать с Системой.
-
Требования к отдельным элементам
-
Требования к использованию ссылок
Ссылки в Системе должны отличаться от текста цветом и должны быть подчеркнуты. Все ссылки должны быть одного цвета.
Для веб-интерфейса Системы посещенные ссылки должны отмечаться другим цветом.
Ссылки для загрузки (скачивания) файла в Системе должны содержать дополнительную информацию о размере и типе файла.
-
Требования к использованию изображений
Все содержательные изображения (например интерактивные иконки, не имеющие текстового описания) в Системе должны содержать альтернативное описание (атрибут alt), кратко описывающий суть изображенного.
Интерактивные иконки Системы, не имеющие текстового описания, должны содержать всплывающую подсказку (атрибут title) с указанием выполняемого ей действия.
Любой текст в Системе, который возможно разместить как текст, недопустимо размещать как изображение.
В системе для критически важной информации (навигация, совершение действий) не должна использоваться графика. В этих случаях для оформления следует использовать фоновые изображения (присоединяемые средствами CSS), которые не влияют на отображение информации в отключенном виде. Вместе с фоновыми изображениями необходимо использовать фоновую заливку.
-
Требования к использованию элементов взаимодействия
Флажки в Системе должны использоваться, только если формат ответа – Да/Нет (Включить/Отключить). Флажки должны быть доступны для нажатия также при нажатии на его название (label).
Группа флажков должна использоваться, когда нужно выбрать один или несколько из представленных элементов. Каждый флажок должен быть доступен для нажатия также при нажатии на его название (label).
Переключатели в Системе должны использоваться для выбора одного из нескольких представленных элементов. Каждый переключатель должен быть доступен для включения также при нажатии на его название (label).
Выпадающие списки в Системе должны использоваться для выбора одного из нескольких элементов.
Поля ввода в Системе должны использоваться для коротких текстов. Необходимо указывать пример заполнения такого поля (если формат – не свободный) или указывать ограничения, если они есть.
Кнопки, завершающие действия в Сиcтеме должны иметь надпись (надпись должна быть глаголом, кроме случаев, указанных отдельно (например, «Назад»)).
В случае, если кнопок, завершающих действие, несколько, одна из них должна быть основной (то есть выделяться цветом, размером или иными параметрами).
Если кнопка завершает форму, она должна располагаться либо под формой, либо справа от последнего элемента формы (второй вариант следует использовать только для форм, где важно экономить вертикальное пространство, например, в фильтрах к спискам).
Текстовые поля в Системе должны использоваться для многострочных комментариев.
Каждое поле должно иметь название. Расположение названий относительно элементов форм (сверху или слева) в рамках одной формы расположение должно быть одинаковым.
Расположение названий должно зависеть от длины полей и их количества. В формах с большим количеством полей должно быть левостороннее расположение названий, в формах с длинными полями названия должны располагаться сверху. Для обеспечения однообразности в рамках системы должен использоваться один способ расположения как эталон.
Названия полей не должны быть оторваны от того поля, к которому относятся. В случае, если это происходит, следует переносить более длинные подписи на несколько строк, чтобы выровнять форму.
Внутри полей не должны быть указаны названия полей, так как при вводе значения поля название исчезнет.
Названия полей не должны превышать 1 строки (в крайних случаях допустимо 2 строки). Если название указано сверху, его длина не должна превышать длину самого поля более чем вдвое.
Комментарии к полям должны использоваться, когда есть ограничения на определенные символы, которые можно вводить в поле, или если существует определенный формат ввода символов. Указанные ограничения должны быть минимизированы.
Поле для загрузки файла должно использоваться, когда необходимо дать пользователю возможность загрузить файл (текстовый и прочее). В подсказке к этому полю необходимо указывать формат файлов, которые можно загружать, и их максимальный размер.
Элементы форм могут быть в активном и неактивном состояниях. Активное состояние — состояние по умолчанию, когда пользователь должен воспользоваться формой. Неактивное состояние должно использоваться, если форма имеет несколько контекстов использования, и в каком-то из них определенные поля неактуальны. При этом поля должны присутствовать на странице, чтобы пользователь знал об их существовании.
Если элемент находится в неактивном состоянии, пользователь должен понимать, почему это происходит и как это изменить (например, нужно использовать подсказки «почему это не работает», если связи не самоочевидны).
Значения по умолчанию должны использоваться во всех случаях, в которых это возможно и уместно.
Должно применяться автозаполнение полей введенной ранее/хранимой в системе информацией (если это технически реализуемо).
-
Требования к информированию пользователя об ошибках
Ошибки в формах должны предотвращаться, в частности, необходимо не использовать ограничения на формат ввода или использовать их минимально, только там, где это необходимо.
В полях, где возможны ошибки, пользователю должен быть предоставлен выбор, реализованный с помощью переключателей, флажков, выпадающих списков и так далее, вместо возможности свободного ввода текста.
При возникновении ошибки пользователю должно выводиться уведомление (именно в тот момент, когда это случилось). Информирование должно происходить в области внимания пользователя, например, рядом с тем полем, при вводе информации в которое он ошибся.
Если ошибку невозможно установить до нажатия пользователем на кнопку отправки формы, то уведомление об ошибке должно быть показано в самом начале формы или экрана и возле каждого поля с ошибкой. Внешний вид (цветовая гамма) сообщения должен максимально контрастировать с внешним видом системы, чтобы можно было легко заметить сообщение.
-
Требования к результату действия пользователя
После выполнения пользователем какого-либо действия в Системе (например, заполнения формы и ее отправки нажатием на кнопку) обязательно должна быть ответная реакции о результатах (ошибки, либо уведомление) выполненного действия.
По внешнему виду оно должно отличаться от сообщения об ошибке и быть единственным или самым визуально значимым сообщением на экране. Первая фраза в таком уведомлении должна указывать на статус только что выполненного действия (например, «Форма была отправлена»). Данное правило не должно применяться для форм массового ввода.
-
Требования к использованию списков и таблиц
Для разделения однородного списка элементов (например, результатов поиска) на несколько страниц должен использоваться пейджинатор (разделитель страниц)
Заголовок таблицы должен быть выделен.
Не должно быть насыщенных линий в качестве разделителей.
Строки в таблицах должны отделяться друг от друга фоном через строку («полосатая» таблица) для удобного просмотра информации.
-
Требования к защите информации от несанкционированного доступа
Защита информации от несанкционированного доступа должна быть обеспечена комплексом организационных и технических мер, направленных на защиту информации ограниченного доступа и персональных данных, обрабатываемых в процессе работы Системы, в соответствии с требованиями действующего законодательства. Комплекс организационных и технических мер, направленных на обеспечение защиты информации, должен разрабатываться с учётом:
-
законодательных документов федерального уровня:
Федерального закона № 63-ФЗ «Об электронной подписи» от 6 апреля 2011 года;
Федерального закона № 149-ФЗ «Об информации, информационных технологиях и защите информации» от 27 июля 2006 года;
Федерального закона № 152-ФЗ «О персональных данных» от 27 июля 2006 года;
-
руководящих и нормативно-правовых документов федерального уровня:
Постановлению Правительства РФ № 1119 от 01 ноября 2012 года «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»;
Приказу ФСТЭК России № 17 от 11 февраля 2013 года «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»;
Приказу ФСТЭК России № 21 от 18 февраля 2013 года «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»;
Приказу ФСБ России № 378 от 10 июля 2014 года «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности»;
руководящему документу ФСБ России «Методические рекомендации по обеспечению с помощью криптосредств безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств автоматизации» от 21 февраля 2008 года;
руководящему документу ФСТЭК России «Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных» от 15 февраля 2008 года;
руководящему документу ФСТЭК России «Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных» от 15 февраля 2008 года;
специальным требованиям и рекомендациям по технической защите конфиденциальной информации (СТР К) (утвержденные решением Коллегии Гостехкомиссии России № 7.2 от 02 марта 2001 года);
-
стандартам по защите информации от несанкционированного доступа (НСД) и руководящим документам:
ГОСТ Р 53114-2008 «Защита информации. Обеспечение информационной безопасности в организации. Основные термины и определения»;
ГОСТ Р 51275-2006 «Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения»;
ГОСТ Р 51583-2014 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения»;
ГОСТ Р 51624-2000 «Защита информации. Автоматизированные системы в защищенном исполнении»;
ГОСТ Р 34.10-2012. «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи»;
ГОСТ 15971-90 «Системы обработки информации. Термины и определения»;
Р 50.1.053-2005 «Информационные технологии. Основные термины и определения в области технической защиты информации»;
Р 50.1.056-2005 «Техническая защита информации. Основные термины и определения».
-
Требования к сохранности информации при авариях
Сохранность информации в Системе должна обеспечиваться:
при пожарах, затоплениях, землетрясениях и других стихийных бедствиях: организационными и защитными мерами, опирающимися на подготовленность помещений и персонала, обеспечивающими сохранность хранимых копий информации на магнитных носителях;
при разрушениях данных при механических и электронных сбоях и отказах в работе компьютеров: на основе программных процедур восстановления информации с использованием хранимых копий баз данных, программных файлов Системы, а также загружаемых файлов;
при сбое в электропитании: организационными и защитными мерами, опирающимися на подготовленность резервного питания для поддержания нормального функционирования Системы в течение времени, необходимого для устранения сбоя в электропитании или для корректного завершения работы Системы;
при сбое из-за ошибок в работе персонала: организационными и защитными мерами, опирающимися на подготовленность персонала.
Система должна автоматически восстанавливаться при перезапуске аппаратных средств. Полная перезагрузка Системы в резервированной масштабируемой конфигурации с полным восстановлением функциональности должна происходить не более чем за 10 минут.
Для обеспечения сохранности информации в Системе должны быть включены следующие функции:
резервное копирование операционных систем, баз данных, программных и загружаемых файлов;
восстановление данных в непротиворечивое состояние при программно-аппаратных сбоях (отключение электрического питания, сбоях операционной системы и других) вычислительно-операционной среды функционирования;
восстановление данных в непротиворечивое состояние при сбоях в работе сетевого программного и аппаратного обеспечения.
-
Требования к патентной чистоте
Патентная чистота разрабатываемого федерального сегмента Межведомственной системы, должна соответствовать требованиям по патентной чистоте согласно действующему законодательству Российской Федерации.
Исполнитель должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц. Это требование должно обеспечивать соблюдение авторских, смежных, патентных и иных прав разработчиков используемых сторонних компонент.
Если в Системе использованы объекты интеллектуальной собственности, исключительные права на которые принадлежат третьим лицам, Исполнитель обязуется получить необходимые права на использование данных объектов и передать указанные права Заказчику, при этом стоимость прав на использование данных объектов должна быть включена в стоимость Договора.
|
