ТЗ. Приложение № 1 к ЗД-Техническое задание (1). Техническое задание выполнение работ по модернизации опытного образца комплекса программных средств о
Скачать 0.84 Mb.
|
4.2.2 Требования к устойчивости функционирования КПС должен разрабатываться с учетом Требований по обеспечению целостности, устойчивости функционирования и безопасности информационных систем общего пользования, утвержденных Приказом Министерства связи и массовых коммуникаций Российской Федерации № 104 от 25.08.2009. Устойчивость функционирования должна обеспечиваться: разработкой мер при проектировании, направленных на выполнение требований к показателям надежности; соблюдением условий эксплуатации, установленных в технической и эксплуатационной документации соответствующих технических и программных средств; выполнением требований в части технического обслуживания ее технических и программных средств; выполнением требований к управлению в части контроля функционирования и анализа технических неисправностей. 26 В соответствии с приказом Министерства связи и массовых коммуникаций Российской Федерации от 25.08.2009 N 104 комплекс программных средств «Умный дом» относится к информационным системам общего пользования класса II, поэтому к нему предъявляются следующие требования: должна обеспечиваться защита от воздействий на технические и программные средства, в результате которых нарушается их функционирование, и защита от несанкционированного доступа к помещениям, в которых размещены данные средства; должна осуществляться регистрация действий обслуживающего персонала. 4.2.3 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Устанавливаются следующие общие требования к условиям эксплуатации и техническому обслуживанию: эксплуатация и техническое обслуживание средств должно осуществляться эксплуатационным персоналом, требования к численности, квалификации и режиму работы которого определены в разделе 4.2.11; размещение технических средств и организация автоматизированных рабочих мест пользователей должно быть выполнено в соответствии с требованиями санитарных норм и правил в соответствии с ГОСТ 21958-76; условия эксплуатации, а также виды и периодичность обслуживания технических средств должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в документации их производителя. Обязательной составляющей регламентных работ технического обслуживания должно быть периодическое резервное копирование информационных ресурсов, в том числе базы данных, исполняемых и исходных кодов программного обеспечения, областей дискового пространства, содержащих информацию, необходимую для нормального функционирования. Для обеспечения сохранности программного обеспечения должна быть создана и передана на хранение Заказчику эталонная копия дистрибутива прикладного программного обеспечения. Обновление эталонной копии может производиться Исполнителем по согласованному с Заказчиком регламенту. 4.2.4 Требования к информационной безопасности 4.2.4.1 Общие требования к информационной безопасности В ходе создания системы должны быть проведены работы по разработке механизмов защиты персональных данных, а также работы по оценке необходимости и возможности применения в системе средств криптографической защиты информации по ГОСТ. Все компоненты и прикладное ПО КПС на этапе передачи в промышленную эксплуатацию, должны быть стабильных последних версий, либо должны быть установлены обновления до тех версий, которые обеспечивают максимальную защищѐнность системы (отсутствие известных уязвимостей). 4.2.4.2 Требования к аутентификации и авторизации 27 КПС должен иметь возможность для каждого пользователя создавать уникальную учетную запись. КПС должен включать в себя механизм аутентификации. Аутентификация должна проводиться с использованием одного из следующих средств: Логин/Пароль; В КПС должен присутствовать механизм авторизации пользователей. При этом должно поддерживаться разделение прав доступа к информации/данным и функциям внутри КПС. КПС должна поддерживать предоставление пользователям прав доступа на основании групповой или ролевой модели. КПС должен предоставлять доступ к своим ресурсам только после успешного прохождения процесса аутентификации пользователя, в соответствии с его правами доступа. Данное требование не распростряняется на ресурсы, которые должны находиться в публичном доступе. Учетная запись пользователя в КПС должна создаваться в процессе подключения услуги. После аутентификации в ЕЛК пользователь может выполнить первый вход в систему с новой учетной записью. На этапе пилотного проекта к процессу аутентификации предъявляются следующие требования. КПС должен: Предоставлять пользователям возможность самостоятельно устанавливать свой пароль и менять его в любое время; Проверять качество вводимого пароля. Пароль пользователя должен содержать не менее 8 символов, из которых как минимум 1 символ является заглавной буквой и как минимум один символ является цифрой; Предоставлять возможность обязательной смены заданного администратором пароля при первом входе в систему; Иметь возможность автоматической блокировки учѐтной записи, в случае если ее пароль до установленной даты не был изменѐн; Иметь возможность блокировки учѐтной записи на заранее определенный срок после заданного количества неудачных попыток аутентификации; Иметь возможность установки срока длительности простоя пользовательской сессии, после которого сессия должна принудительно завершаться; Иметь возможность ограничить множественный вход в систему под одной учетной записью пользователя. Для ввода КПС в промышленную эксплуатацию дополнительно предъявляются следующие требования. КПС должен: Проверять качество вводимого пароля в соответствии с требованиями парольной политики; Иметь возможность задавать параметры парольной политики для группы пользователей, а также возможность назначать их отдельно для каждой отдельной учетной записи; Позволять администраторам отключать возможность смены пароля у отдельных пользователей; Обеспечивать принудительную смену пароля через установленный промежуток времени; Иметь возможность заблаговременно оповещать пользователей о необходимости смены пароля (посредством сообщений/подсказок или почтовых рассылок на электронные адреса пользователей); Обеспечивать хранение истории паролей пользователей, как минимум, за последние 12 месяцев для предотвращения повторного их использования. Пароли должны храниться и передаваться только в зашифрованном виде. При хранении и передаче должны использоваться современные криптографические алгоритмы или алгоритмы хеширования 28 На этапе пилотного проекта пользовательские интерфейсы КПС не должны выдавать информации о типе и версии системы или ее компонент до успешного завершения процедур аутентификации и авторизации. Для ввода КПС в промышленную эксплуатацию данное требование должно выполняться для всех интерфейсов КПС. В процессе аутентификации проверка введенной информации (логин, пароль) должна осуществляется только после полного ее ввода. В случае обнаружения ошибки, система не должна уточнять, какие именно данные введены неправильно. Пароль не должен отображаться при вводе. КПС и его компоненты не должны содержать жестко запрограммированных учетных записей. Компоненты КПС в случае сетевого взаимодействия через публичные сети (интернет), должны проходить процедуру взаимной аутентификации . КПС Проверка учетных данных пользователя должна проводиться на стороне серверных компонент ИС. Все неиспользуемые для штатной работы КПС учетные записи (установленные по умолчанию, тестовые, сервисные) должны быть удалены или заблокированы до начала передачи ИС в эксплуатацию. Пароли от предустановленных учетных записей и сервисов должны быть изменены сразу после установки КПС в продуктивную среду. Все действия в КПС должны производиться с использованием учетных записей, наделенных минимально необходимыми привилегиями. 4.2.4.3 Требования к аудиту Компоненты КПС должны синхронизировать системное время с NTP-сервером, являющимся частью инфраструктуры сети ОАО Ростелеком (допустимая погрешность не более 5 секунд). Серверы NTP и доступ к ним обеспечивает Заказчик. КПС должен поддерживать следующие механизмы протоколирования событий: Должны поддерживаться регистрация, хранение и просмотр событий стандартными средствами операционной системы; Должны быть реализованы регистрация и отправка событий во внешние системы по протоколу syslog. Формат сообщений должен быть описан в документации. В КПС должно осуществляться протоколирование следующих событий: Успешные и неуспешные попытки аутентификации пользователя в системе; Действия привилегированных пользователей по настройке и изменению конфигурации ИС (в том числе изменение настроек аудита); Любой доступ пользователей к данным конфиденциального характера; Успешные и неуспешные попытки доступа пользователя к данным системы и другим ресурсам; Доступ к записям журнала протоколирования событий (требование не является обязательным на этапе пилотного проекта); Запуск и остановка ИС; Создание и удаление объектов системного уровня (учетные записи, профили поддерживаемого оборудования, шаблоны сценариев и т.п.). Журналы событий должны содержать, как минимум, следующую информацию: 29 Идентификатор пользователя, выполнившего операцию; Источник события (IP-адрес, идентификатор рабочей станции, ID источника и т.д.); Название или тип выполненного события; Дату и время события; Результат события; Объект, над которым была выполнена операция; Журналы аудита КПС не должны содержать данных конфиденциального характера (паролей или другой закрытой информации в открытом или преобразованном виде и.т.д.). Для ввода КПС в промышленную эксплуатацию должна быть обеспечена защита журналов аудита от несанкционированных изменений. 4.2.4.4 Требования к сетевому взаимодействию Любой процесс обмена конфиденциальной информацией Заказчика через публичные сети должен осуществляться по зашифрованному каналу передачи данных. При этом допустимо использование следующих стандартов и протоколов: TLS/SSL (не ниже версии 3); SFTP; FTPS; SSH-2 WSS; S/M IME с использованием сертификатов x.509 v3; VPN (IPSEC, L2TP, PPTP и т.д.). При невозможности использовать указанные выше способы передачи передаваемые данные должны быть зашифрованы с применением современных стойких криптографических алгоритмов. Если КПС необходим доступ к системам или базам данных, расположенным во внутренней сети Заказчика (КСПД), то обмен данными между ними должен осуществляться с использованием защищенных протоколов. Сетевое взаимодействие между компонентами КПС, а также взаимодействие с внешними системами, должно проходить с использованием защищенных протоколов, если это технически возможно. 4.2.4.5 Требования к конфиденциальности, целостности и доступности данных Любые изменения конфиденциальных или прикладных данных в КПС должны носить характер транзакционно-ориентированных, т.е. выполняющихся в целом от начала до конца либо, в случае сбоя транзакции, не выполняющихся совсем. КПС должен обладать возможностью балансирования нагрузки между отдельными компонентами и модулями ИС. При этом выход из строя отдельных узлов ИС не должен сказываться на общей функциональности системы. Данные конфиденциального характера, хранящиеся в КПС, должны быть защищены с использованием стойких алгоритмов шифрования. 30 В пользовательских интерфейсах КПС должна поддерживаться валидация (проверка) входных данных. Должна обеспечиваться возможность ввода только тех значений, которые являются допустимыми для данных форм/применений. Должно осуществляться кодирование входных данных до их передачи ИС и ее внешним компонентам (LDAP-сервер, база данных, web-браузер и т.д.). КПС должны поддерживать режим обработки ошибок, при котором пользователю не сообщается детальная информация об ошибке (версии подсистем, таблицы БД, сетевые адреса компонент ИС и т.д.) в случае сбоя приложения. В КПС должны быть предусмотрены механизмы резервного копирования и восстановления данных с использованием системы резервного копирования Заказчика. Для реализации резервного копирования должен быть составлен перечень объектов, требующих резервирования. Настройка системы резервного копирования Заказчика лежит вне рамок данного технического задания. Для обеспечения работы внешней системы резервного копирования КПС не должен постоянно работать с данными в монопольном режиме. Должны быть предусмотрены временные интервалы, в которые КПС будет снимать блокировки с данных. 4.2.4.6 Дополнительные требования к web-компонентам КПС должен поддерживать интеграцию своих подсистем аутентификации с централизованными системами управления учетными данными и правами пользователей. Указанное требование не распространяется на процесс аутентификации клиентов B2C. Указанное требование не является обязательным в рамках пилотного проекта. КПС должен обеспечивать возможность завершения сессии пользователя из любой страницы системы. Для ввода КПС в промышленную эксплуатацию дополнительно должно быть обеспечено закрытие сессии пользователя при неаварийном закрытии браузера. На web-серверах КПС должен быть заблокирован доступ ко всем типам файлов MIME, которые не предназначены к обработке в ИС. 4.2.5 Требования по сохранности информации при авариях При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, КПС должен автоматически восстанавливать свою работоспособность после устранения сбоев и корректного перезапуска аппаратного обеспечения (за исключением случаев повреждения рабочих носителей информации с исполняемым программным кодом). К КПС предъявляются следующие общие требования по сохранности информации и восстановлению работоспособности после устранения последствий сбоев: должно осуществляться резервное копирование информации, периодичность проведения которого должна определяться Заказчиком и устанавливаться административными настройками резервного копирования; 31 средствами резервного копирования и восстановления данных должно обеспечиваться восстановление информации в состояние, соответствующее используемой резервной копии. При этом допускается приостановка функционирования некоторых средств на время проведения операций по восстановлению информации либо перевод отдельных ее компонентов в режим автономной работы. КПС должен обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях КПС должен выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. Для предотвращения наступления аварийных ситуаций в случаях, когда это допустимо, должны использоваться следующие элементы интерфейса: drag-and-drop; выпадающие списки; другие элементы, предполагающие выбор из существующего списка значений. 4.2.6 Требования к защите от влияния внешних воздействий В помещениях с размещенными техническими средствами, на которых будет функционировать КПС, должны быть обеспечены климатические условия, определяемые требованиями производителей используемых технических средств. 4.2.7 Требования к патентной чистоте По всем техническим и программным средствам, применяемым при разработке КПС, должны соблюдаться условия лицензионных соглашений и обеспечиваться патентная чистота. 4.2.8 Требования по стандартизации и унификации Разработка прикладного программного обеспечения КПС должна быть основана на применении принципов объектно-ориентированного программирования и модульной архитектуры с использованием типовых программных компонент, реализующих одни и те же функции (фрагменты функций). Должны применяться тиражные инструментальные средства разработки программного обеспечения, общепринятые (стандарты де-факто) языки программирования, стандартные технические и программные средства общего назначения и процедуры информационного взаимообмена. При создании КПС должно использоваться тиражное стандартное общесистемное программное обеспечение, лицензированное установленным порядком. Исходный программный код должен быть самодокументируемым, то есть имена переменных, процедур, функций, объектов и т. д. должны объяснять свое наименование и назначение. Данный код позволит сформировать в автоматизированном режиме полное описание всех переменных, процедур, функций, объектов и т. д. в единую документацию. Исходные коды должны быть написаны с использованием понятных имен классов, их свойств, методов и переменных. Все классы в исходном коде должны иметь комментарий, в котором указывается назначение данного класса. Все методы классов должны включать в себя: 32 комментарий, содержащий назначение данного метода (описание входных параметров метода; возможные значения возвращаемого результата; перечисление исключительных ситуаций, которые могут возникнуть при использовании этого метода); примеры использования метода (применимо в отдельных случаях, которые могут быть уточнены на этапе проектирования). Пользовательский интерфейс должен обеспечивать необходимое качество взаимодействия человека с машиной и комфортность работы пользователей. Должно применяться серийно выпускаемое оборудование и аппаратные средства ведущих мировых производителей, сертифицированное для применения в Российской Федерации. 4.2.9 Требования к режимам функционирования КПС должен поддерживать следующие режимы функционирования: Режим функционирования Характеристика Штатный режим Основной режим функционирования. В штатном режиме функционирования: — обеспечивается возможность функционирования в режиме 24/7; — исправно работает оборудование, составляющее комплекс технических средств; — исправно функционирует системное, базовое и прикладное программное обеспечение. Для обеспечения штатного режима функционирования необходимо выполнять требования и выдерживать условия эксплуатации программного обеспечения и комплекса технических средств Аварийный режим Аварийный режим функционирования характеризуется отказом одного или нескольких компонентов программного и (или) технического обеспечения Регламентный режим Используется для проведения регламентных работ |