3.6Сведения об обеспечении заданных в техническом задании (ТЗ) потребительских характеристик Системы (подсистем), определяющих ее качество
Функциональные характеристики Системы, определяющие качество автоматизации бизнес-задач, проверяются во время испытаний Системы. Регламентирующими для проверки является документ «Программа и методика испытаний компонентов Системы», разрабатываемый в соответствии с РД 50-34.698-90.
Ниже приведены сведения об обеспечении заданных в Техническом задании потребительских характеристик Системы (Подсистем), определяющих ее качество.
3.6.1.1 Характеристики приспособляемости Системы, допустимые пределы модернизации и развития системы
Архитектура Системы должна разрабатываться с учетом возможности модернизации в направлении решения задач, предусмотренных в том числе в рамках мероприятия «Обеспечение перехода на предоставление государственных и муниципальных услуг в электронном виде», а именно:
развитие сервисов для упрощения процедур взаимодействия общества и государства с использованием информационных технологий;
перевод государственных и муниципальных услуг в электронный вид;
развитие инфраструктуры доступа к сервисам электронного государства;
повышение открытости деятельности органов государственной власти.
При разработке Системы предусмотрена возможность расширения в части внесения изменений:
в объектную и реляционную модель данных Системы;
в состав и внешний вид экранов пользовательского интерфейса АРМ Федерального реестра и Реестра государственных услуг.
С этой целью в составе реестра выделен отдельный модуль. Данный модуль содержит Java-классы, описывающие объектно-реляционную модель реестра, в соответствии с которым строится протокол взаимодействия между АРМ реестра и сервером реестра, а так же правила формирования пакетов транспортной системы, в части полезной нагрузки. Расширение АРМ реестра происходит за счет написания новых модулей в соответствии с правилами платформы Eclipse RCP.
Для упрощения развития и доработки Системы предоставляется комплект исходных кодов базовых модулей, в т.ч. модуля модели данных. В составе кодов модели имеются соответствующие комментарии и программные аннотации.
Возможность обеспечения доступа к информации, хранящейся в Системе, предоставляется за счет использования архитектуры межсистемных взаимодействий, реализованной за счет использования веб-сервисов, что позволяет добавлять внешние по отношению к модулям системы обработчики SOAP-сообщений без необходимости изменения программного кода и настроек отдельных модулей Системы.
3.6.1.2 Эксплуатационные показатели назначения
Программное обеспечение Системы реализовано таким образом, что:
администраторы Системы должны обладать стандартными навыками администрирования (не требуются специальные навыки);
при сбоях и отказах Система может быть восстановлена за период, не превышающий одного рабочего дня.
3.6.1.3 Решения по поддержке организационных мер защиты
Решение основано на принципах «наименьших достаточных прав»:
пользователям даются ровно те привилегии, которые необходимы и достаточны для выполнения их обязанностей;
физического разделения подсистем в зависимости от типа запрашиваемого доступа;
ограничения возможности сетевой коммуникации только теми протоколами, которые необходимы;
ограничения возможности сетевой коммуникации между сетью «Интернет» и сервером взаимодействия с внешними сетями;
запрета прямого доступа к серверам БД Подсистем Системы как из сети Интернет, так и из локальной сети ОГВ.
3.6.1.4 Политики межсетевого взаимодействия
С учетом требований к безопасности Системы, а также требования независимости от внешних угроз работы сотрудников ОГВ, необходимо построение в ОГВ сетевой инфраструктуры с выделением отдельной сетевой зоны (Демилитаризованная Зона, DMZ), отделенной от внутренней сети ОГВ и сети Интернет межсетевыми экранами. В Демилитаризованную Зону необходимо вынести сервер, организующий поддержку подсистемы взаимодействия с внешними информационными системами (Транспортная система). Серверы хранения данных (на сервере СУБД) и логики их обработки (на сервере (или серверах) Системы) будут располагаться внутри локальной сети ОГВ. Взаимодействие с данными подсистемами возможно со стороны других подсистем только по заранее заданным защищенным протоколам.
3.6.1.5 Политики обеспечения конфиденциальности и целостности информации
3.6.1.5.1 Политика паролей
Пароли пользователей системы, включая пароли администраторов серверов Системы и межсетевых экранов, должны соответствовать набору требований:
пароли должны состоять из букв латинского алфавита и цифр;
длина пароля пользователя реализована не менее 6 символов;
пароли администраторов рекомендуется делать длиной не менее 8 символов;
пароль не должен повторять имя пользователя;
в качестве пароля не рекомендуется использовать свое имя, день рождения, номер телефона и квартиры;
пароль должен регулярно меняться, причем новый пароль должен отличаться от предыдущего минимум на 3 символа;
пароли администраторов рекомендуется хранить в запечатанном конверте в сейфе руководителя.
Политикой паролей Системы запрещено:
уполномоченным пользователям сохранять пароль Системы в браузере или использовать другие средства автоматического заполнения поля ввода пароля при авторизации в АРМ Федерального реестра или Реестра государственных услуг;
запрещается сообщать свои реквизиты доступа к Системе другому сотруднику ОГВ независимо от того, имеет этот сотрудник свои реквизиты доступа или нет;
запрещается сообщать свои реквизиты доступа к ОГВ посторонним людям любым способом;
запрещается оставлять записанный на бумаге пароль в общедоступном месте.
3.6.2 Решения по стандартизации и унификации
При разработке Системы минимизировано использование нестандартных и ненормативных классификаторов.
Автоматизированные рабочие места Системы унифицированы и опираются на единую технологию работы и использование типовых программных решений.
Для организации обмена информацией между подсистемами и внешними системами:
Разработаны и описаны в виде XML Schema спецификации файлов в формате XML.
Реализована возможность информационного обмена при помощи файлов в формате и структуре, соответствующей разработанным XML Schema.
Использована технология веб-сервисов для синхронного и асинхронного взаимодействия подсистем. Связь между узлами транспортной подсистемы реализована путем асинхронного обмена данными. Узлы других подсистем Системы взаимодействуют путем синхронного обмена.
Проводимые работы соответствуют требованиям ФЦП «Электронная Россия» по отчуждаемости и совместимости:
Применяемые при создании Системы технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции и т.п.) решения должны быть документированы в виде, достаточном для независимой (без обращения к Исполнителю) реализации третьими сторонами и доступны. Применение недокументированных или недоступных решений не допускается.
При выборе применяемых решений преимущество должно отдаваться стандартизированным решениям (т.е. прошедшим процедуру стандартизации и утвержденные в качестве стандарта либо рекомендации каким-либо признанным международным, федеральным, отраслевым, промышленным органом по стандартизации).
В случае применения исполнителем специфицированных, но не стандартизированных решений должно быть представлено обоснование на каждый такой случай.
Требования отчуждаемости и совместимости относятся к решениям по взаимодействию с любыми внешними информационными системами, а также к взаимодействию между подсистемами проекта. При взаимодействии между подсистемами проекта использование нестандартизированных решений возможно только по отдельному согласованию с государственным заказчиком при наличии обоснования.
Совместимость со смежным программным обеспечением обеспечивается путем предоставления возможностей загрузки и выгрузки информации в электронные файлы фиксированного формата и/или предоставлением специфицированного программного интерфейса (API).
|
