ТЕХНИЧЕСКОЕ ЗАДАНИЕ к договору на оказание услуг по внедрению сервиса «Мобильный менеджмент» Москва 2014 2 СОДЕРЖАНИЕ 1 Список сокращений и терминов ............................................................................. 4 2 Общие сведения .......................................................................................................... 8 2.1 Заказчик работ ...................................................................................................... 8 2.2 Исполнитель работ .............................................................................................. 8 2.3 Сведения об источниках и порядке финансирования работ ............................ 8 2.4 Цели работ ............................................................................................................. 8 2.5 Общие сведения об облачной платформе Заказчика ........................................ 9 2.6 Задачи, требующие решения в рамках оказания услуг ..................................... 9 3 Состав работ, планируемые сроки оказания услуг ......................................... 11 3.1 Сроки оказания услуг ........................................................................................... 11 3.2 Требования к оказанию услуг .............................................................................. 11 3.3 Плановые сроки оказания услуг ......................................................................... 12 4 Место оказания услуг ............................................................................................. 16 5 Функциональные требования к системе ............................................................ 17 5.1 Общие требования к задачам, выполняемым сервисом.................................. 17 5.2 Требования к модели лицензирования услуги и набору услуг ......................... 18 5.3 Требования к функционалу управления устройствами, функциям аудита устройств 20 5.4 Требования к управлению приложениями .......................................................... 22 5.5 Требования к взаимодействию с инфраструктурой клиентов ..................... 23 5.6 Требования к взаимодействию с почтовыми сервисами ................................ 25 5.7 Требование к системе клиентского самообслуживания решения ................. 27 5.8 Требования к клиентскому ПО на устройствах .............................................. 28 5.9 Требования к интерфейсу администраторов и пользователей ................... 30 5.10 Требования к управлению данными и потоками данных ............................. 31 5.11 Требования к подсистеме отчета ................................................................ 32 5.12 Дополнительные требования ........................................................................ 32 6 Требования к внедряемому решению в целом ................................................... 33 6.1 Требования к структуре и функционированию решения ................................ 33 6.2 Требования к производительности ................................................................... 34 6.3 Требования к характеристикам взаимосвязей со смежными системами .... 34 6.4 Требования по доработке системы управления НОП и портала o7.com ..... 36 2 3 6.5 Требования к численности и квалификации персонала системы и режиму его работы .............................................................................................................................. 37 6.6 Требования по эргономике и технической эстетике ...................................... 37 6.7 Требования по унификации и стандартизации ................................................ 38 6.8 Требования к программным средствам ............................................................ 39 6.9 Требования к техническому обеспечению ........................................................ 39 6.10 Резервное копирование данных ...................................................................... 40 6.11 Мониторинг и управление .............................................................................. 40 6.12 Требования к режимам функционирования ................................................... 42 6.13 Перспективы развития, модернизации системы ........................................ 42 6.14 Требования к информационной безопасности ............................................. 43 6.15 Требования по криптографической поддержке ............................................ 44 6.16 Требования к соблюдению конфиденциальности информации .................. 45 6.17 Специальные требования............................................................................... 45 7 Требования к качеству, техническим характеристикам и результатам оказания услуг по сопровождению Сервиса MDM .......................................................... 46 7.1 Общие требования .............................................................................................. 46 7.2 Требования к технической поддержке и консультированию пользователей по вопросам использования и работы Системы ................................................................. 47 7.3 Требования к составу услуг технической поддержки Сервиса. ..................... 50 7.4 Требования к организационному обеспечению эксплуатации ........................ 50 8 Порядок контроля и приемки работ .................................................................... 51 9 Требования к результатам работ ....................................................................... 52 9.1 Требования к документированию ...................................................................... 52 9.2 Требования к оформлению .................................................................................. 53 10 Информация, требуемая для оценки технико-коммерческих предложений. 54 3 4 1 Список сокращений и терминов Определение, термин или сокращение Определение API Application Programming Interface – интерфейс программирования приложений (иногда, интерфейс прикладного программирования) — набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах. Используется для интеграции с существующими системами и платформами AppStore Магазин приложений для устройства. Может быть публичным и обслуживаемым производителем операционной системы (Apple AppStore, Google Play, и тд) или частным репозиторием компании, доступным ее сотрудникам CRM Customer Relationship Management – система управления взаимоотношениями с клиентами B2B Business to Business, буквально бизнес для бизнеса - вид информационного и экономического взаимодействия, классифицированного по типу взаимодействующих субъектов, в данном случае — это юридические лица, которые работают не на конечного рядового потребителя, а на такие же компании, то есть на другой бизнес. HTTPS Hypertext Transfer Protocol Secure(расширение протокола передачи гипертекстов HTTP, поддерживающее шифрование) IP (Internet Protocol) Протокол работы сети интернет KPI Key Performance Indicators - ключевые показатели эффективности LDAP Lightweight Directory Access Protocol – облегченный протокол доступа к каталогам MDM Mobile Device Management Powershell Расширяемое средство автоматизации от Microsoft, состоящее из оболочки с интерфейсом командной строки и сопутствующего языка сценариев SAN Storage Area Network – сеть хранения данных 4 5 Определение, термин или сокращение Определение SaaS Software as a Service, программное обеспечение как услуга - бизнес-модель продажи и использования программного обеспечения, при которой поставщик разрабатывает услугу-сервис и самостоятельно управляет ею, предоставляя заказчику доступ к программному обеспечению через Интернет SMS Short Messaging Service - технология, позволяющая осуществлять приём и передачу коротких текстовых сообщений с помощью сотового телефона SNMP Простой протокол сетевого управления SIEM Security Information and Event Management – системы сбора и анализа информации, предоставляющие возможности создания отчетов, корреляции событий, активных реакций на них. TCP/IP (Transmission Control Protocol / Internet Protocol) Протокол управления передачей /протокол Интернет VPN (Virtual Private Network) Виртуальная частная сеть Jailbreak процесс взлома мобильного устройства, при котором обеспечивается административный (Root)-доступ к его операционной системе. Root-доступ позволяет осуществлять действия, недоступные на устройстве с пользовательским доступом. АИС Автоматизированная информационная система АСР Автоматизированная система расчетов, включающая в себя подсистемы: каталог продуктов, база тарифов, абонентская база, тарификатор, биллинг и др АРМ Автоматизированное рабочее место Блейд Сервер-лезвие, монтируемый в шасси ВМ Виртуальная машина ГОСТ Государственный (отраслевой) стандарт 5 6 Определение, термин или сокращение Определение ИБ Информационная безопасность ИТ Информационные технологии ЛВС Локальная вычислительная сеть НСД Несанкционированный доступ НОП Национальная облачная платформа О7 ОС Операционная система ПК Персональный компьютер ПМИ Программа и методика испытаний ПО Программное обеспечение РД Рабочая документация РМ Рабочее место СУБД Система управления базами данных СУР Система управления ресурсами СХД Система хранения данных ТП Технический проект ТУ Технические условия ФСБ Федеральная Служба Безопасности ФСТЭК Федеральная служба по технологическому и экспортному надзору ЦОД Центр обработки данных ЧТЗ Частное техническое задание 6 7 7 8 2 Общие сведения 2.1 Заказчик услуг Заказчик: ОАО «Ростелеком». 2.2 Исполнитель услуг Исполнитель определяется по результатам проведенного конкурса и процедуры закупок. 2.3 Сведения об источниках и порядке финансирования услуг Источник финансирования определяется Заказчиком. 2.4 Цели оказания услуг Внедрение решения по управлению мобильными устройствами в перспективе позволяет обеспечить: - развитие направления мобильных сервисов для потенциальных и текущих пользователей, у которых существуют следующие потребности: • реализация корпоративных политик безопасности на мобильных устройствах; • контроль расходов сотрудников на мобильную связь; • контроль используемых сотрудникам приложений; • определение местоположения мобильных устройств; • удаленная блокировка мобильных устройств; • удаленная настройка доступа к корпоративной почте и другим внутренним ресурсам клиента. - занятие доли рынка услуг по управлению мобильными устройствами; - развитие направления мобильных сервисов для B2B пользователей; - продвижение профильных услуг в составе комплексного сервиса и обеспечение роста клиентской базы. Целью оказания услуг является развертывание в облачной инфраструктуре Заказчика и дальнейшее функционирование системы, обеспечивающей оказание коммерческих услуг по управлению мобильными устройствами корпоративным клиентам Заказчика в соответствии с описанными выше потребностями. 8 9 2.5 Общие сведения об облачной платформе Заказчика Национальная Облачная платформа Заказчика (далее – Национальная Облачная платформа или НОП) представляет собой интегрированную программно-аппаратную среду, имеющую компонентную структуру. Клиентами НОП являются: инфраструктура электронного правительства; федеральные и региональные органы исполнительной власти; коммерческие компании; частные лица. Под структурными компонентами применительно к НОП понимаются составные части – подсистемы, обеспечивающие её функционирование. В состав НОП входят следующие подсистемы: - подсистема инфраструктурного обеспечения; - подсистема управления; - подсистема идентификации и аутентификации O7 СИА; - подсистема обеспечения информационной безопасности. В состав подсистемы инфраструктурного обеспечения входят следующие компоненты: - подсистема телекоммуникационной инфраструктуры; - подсистема вычислительной инфраструктуры, обеспечивающая предоставление вычислительных ресурсов, необходимых для пользователей облачной платформы; - подсистема хранения данных; - подсистема резервного копирования, предназначенная для создания резервных копий системных данных и данных обрабатываемых в Национальной облачной платформе, необходимых для оперативного восстановления работоспособности системы в случае аварии или по запросу пользователей; - подсистема инфраструктурных сервисов Национальной облачной платформы; - подсистема виртуализации. 2.6 Задачи, требующие решения в рамках оказания услуг Все требования данного пункта являются обязательными условиями. Для оказания услуг по внедрению данного решения необходимо: 9 10 - произвести предпроектное исследование и разработать частное техническое задание на оказание услуг по теме «Внедрение сервиса «Мобильный менеджмент»»; - установить и сконфигурировать на базе НОП компоненты промышленной и тестовой схемы сервиса управления мобильными устройствами; - осуществить интеграцию сервиса с Порталом самообслуживания облачной платформы Заказчика; - осуществить интеграцию сервиса с автоматизированной системой расчётов облачной платформы Заказчика; - осуществить интеграцию сервиса с компонентом учета потребленных и свободных ресурсов (лицензии, дисковое пространство и т.д.) облачной платформы Заказчика; - должны быть выполнены работы по проработке организации технической поддержки сервиса; - разработать комплект проектной документации; - разработать комплект рабочей документации; - разработать комплект эксплуатационной документации; - разработать комплект организационно-распорядительных документов. 10 11 3 Состав услуг, планируемые сроки оказания услуг 3.1 Сроки оказания услуг Сроки начала и окончания оказания услуг должны быть соблюдены в соответствии с согла- сованным планом-графиком и Договором на оказание услуг. - начало оказания услуг – не позднее 3 календарных дней с даты заключения Договора; - окончание оказания услуг – в соответствии с план-графиком, приведенным в таблице 1 п.3.3 и исходя из фактической даты начала оказания услуг. 3.2 Требования к оказанию услуг Все требования данного пункта являются обязательными условиями. Оказание следующих услуг производится в 3 этапа: - внедрение решенияи передача проекта в службу эксплуатации и технической поддержки; - лицензирование и поддержка и сопровождение в рамках гарантийного обслуживания; - постгарантийное обслуживание и техническая поддержка. Порядок следования данных видов услуг, а также возможность оказания некоторых услуг параллельно, последовательно или комбинированно, определяется участником тендера при условии сохранения приведенной выше этапности: - проведение предпроектного исследования; - разработка документации: разработка календарного плана-графика оказания услуг; разработка организационных документов проекта (Устав проекта, планы управления проектом, протоколы рабочих совещаний проекта, проекты организационно распорядительных документов проекта); разработка проектной документации содержащей документы: частные технические задания, технический проект, рабочий проект; разработка программы тестовой эксплуатации; разработка эксплуатационной документации; разработка программ и методик испытаний системы. Включая функциональные, интеграционные испытания и иных в случае выявления таковой необходимости; разработка акта о проведении приемо-сдаточных испытаний; 11 12 - реализация решения в соответствии с настоящим техническим заданием и разработанным техническим проектом, включая: установку и настройку программного обеспечения системы для реализации всех функциональных требований промышленной и тестовой схемы решения; интеграционные работы с Порталом Самообслуживания и компонентом учета потребленных ресурсов облачной платформы Заказчика; интеграционные работы с Автоматизированной системой расчётов; тестовая эксплуатация системы; иные работы по реализации решения в соответствии с настоящим техническим заданием и разработанным техническим проектом при необходимости; проведение приемо-сдаточных испытаний системы: функционального, нагрузочного, интеграционного и иных в случае выявления таковой необходимости. - передача комплекта исполнительной, проектной документации и материалов для обучения администраторов, супервизоров и пользователей; - проведение работ по управлению проектом. - поддержка и сопровождение пользователей Сервиса в рамках гарантийного обслуживания 3.3 Плановые сроки оказания услуг Таблица 1. Плановые сроки оказания услуг по проекту внедрения системы управления мобильными устройствами Этап № 1.1 Наименование и состав работ Поставка/Внедрени решения Результаты работ Сроки Предпроектное исследование Отчёт об исследовании Разработка и согласование планаграфика оказания услуг Подробный планграфик оказания услуг Частное ТЗ Не более 15 календарных дней с даты заключения Договора Не более 30 календарных дней от завершения предпроектного исследования и параллельно с ним Разработка частного технического задания Разработка технического проекта Подготовка документации для ин- Технический проект Документация для 12 13 теграционного тестирования 1.2 Передача в опытнокоммерческую эксплуатацию и пере- интеграционного тестирования Разработка программы тестовой Программы тестоэксплуатации вой эксплуатации Разработка программы и методики Программа и метоиспытаний, включая функциодика испытаний нальное, интеграционное и нагру- (ПМИ) зочное тестирование Развертывание продуктивной и Спроектированная, тестовой среды сервиса MDM в развернутая и повиртуальной инфраструктуре ставленная на моНОП ниторинг инфраструктура сервиса MDM Доработка СУ НОП для вывода • Доработанный новой услуги на портал. Доработ- Портал O7.com и ка тестовой и продуктивной среды карточка Сервиса сервиса. для подключения новой услуги; • Доработанный модуль оркестрации для подключения новой услуги и интеграции с ИС Сервиса MDM развернутого в НОП; • Доработанный модуль предбиллинга для подсчета оказанных услуг и подключения услуги к биллингу Заказчика. • Доработанный функционал тестовой и продуктивной среды Сервиса MDM. • Документация на систему в части СУ НОП Проведение работ по интеграции Передача продукта системы с инфраструктурой НОП в опытнокоммерческую эксплуатацию Разработка описания продукта Описание про(программного обеспечения и ин- граммного обеспеформационного обеспечения) чения, Описание информационного обеспечения Не более 40 календарных дней от завершения этапа проектирования Не позднее 40 календарных дней от завершения проектирования и 13 14 дача решения на техническую поддержку Разработка пользовательской документации Разработка эксплуатационной документации Приемо-сдаточные испытания (сквозное тестирование по ПМИ) Инструкция для пользователей и администраторов системы Инструкция по организации резервного копирования и восстановления и прочие дежурные инструкции - протокол ПМИ; параллельно с ними. 15 календарных дней с момента завершения п.1.1 Организация опытнокоммерческой эксплуатации Сервиса в НОП - Отчет по итогам 90 календарных дней оказания услуг по опытнокоммерческой эксплуатации и сопровождению сервиса «Мобильный менеджмент» (в соответствии с формой, указанной в Приложении №1) Передача в коммерческую эксплуатации Сервиса в НОП Актуализиро- 15 календарванная эксплуа- ных дней с момента затационная доку- вершения опытноментация коммерческой Акт приемки в эксплуатации коммерческую Сервиса эксплуатации Сервиса. Акт сдачи- приемки услуг 3го этапа. 2.1 Лицензирование Поставка лицензий в рамках подписанных заказов - Поставка лицензий По запросу 14 15 2.2 Коммерческая эксплуатация/Гарантий ное обслуживание. Гарантийное обслуживание в соответствии с требованиями, изложенными в разделе 7 - - 3 Постгарантийное обслуживание и е техническая поддержка Гарантийное обслуживание в соответствии с требованиями, изложенными в разделе 7 - - Ежеквартальный отчет по итогам оказания услуг по эксплуатации и сопровождению сервиса «Мобильный менеджмент» (в соответствии с формой, указанной в Приложении №1) Акт сдачиприемки результатов оказания Услуг 365 календарных дней. Начало отсчета одновременно с запуском в опытнокоммерческую эксплуатацию. Ежеквартальный отчет по итогам оказания услуг по эксплуатации и сопровождению сервиса «Мобильный менеджмент» (в соответствии с формой, указанной в Приложении №1) Акт сдачиприемки результатов оказания Услуг В соответствии с условиями рамочного договора 15 16 4 Место оказания услуг Услуги могут оказываться по адресам размещения оборудования и программного обеспече- ния облачной платформы Заказчика Исполнителю предоставляется доступ к управлению виртуализированной средой в рамках облачной платформы Заказчика, предоставленной Исполнителю согласно установленным на этапе технического проектирования требованиям. 16 17 5 Функциональные требования к системе 5.1 Общие требования к задачам, выполняемым сервисом Требования данного пункта являются обязательными к реализации. Система должна в полной мере поддерживать принцип мультиарендности (Multitenancy), когда единое решение обслуживает множество организаций-клиентов. При этом программные приложения должны одновременно работать с несколькими конфигурациями и наборами данных нескольких организаций, а каждая организация-клиент работает со своим экземпляром виртуального приложения, видя только свою конфигурацию и свой набор данных, то есть система должна разделять доступ для разных организаций-клиентов (один клиент не должен иметь возможности просматривать информацию о других клиентах). Администраторы системы управляют системой в целом и создают необходимую конфигурацию для организаций-клиентов. Администраторы организаций-клиентов управляют только своей конфигурацией и при необходимости создают нижележащие организационные единицы. Архитектура системы должна иметь возможность наращивать количество сущностей (tenant) без использования дополнительного аппаратного или программного обеспечения. - Решение должно поддерживать набор следующих задач и сценариев управле- ния:система должна позволять создавать профили доступа пользователей, в системе должны быть, как минимум, предусмотрены два профиля: полный или частичный доступ (без доступа к определенным возможностям системы), также должна существовать возможность редактирования этих профилей, их создания и удаления; - создавать, сохранять и применять политики безопасности и настройки к мобильному устройству (группе устройств) в зависимости от производителя и версии программного обеспечения и прочих параметров; - возможность создания с помощью интерактивной веб-карты специальных географических зон и применение профилей устройств в зависимости от их географического положения; - возможность самообслуживания конечных пользователей с возможностью настройки гранулированного доступа к функциям или полного запрета самообслуживания; - разграничение доступа к корпоративным ресурсам через гранулированные политики; - возможность запрета копирования данных через буфер обмена; - возможность запрета запуска программного обеспечения, автоматическая очистка корпоративного программного обеспечения и/или корпоративных данных в случае выявления попыток обхода действующих политик доступа к этим данным; 17 18 - в случае блокировки аккаунта пользователя в организационной структуре компании (AD) должна быть предусмотрена возможность оперативного блокирования связанных с ним аккаунтов/устройств в системе как силами оператора, так и автоматически. 5.2 Требования к модели лицензирования услуги и набору услуг Требования данного пункта являются обязательными к реализации. В базовом варианте лицензий система должна выполнять все общие требования, необходимые для реализации функционала управления мобильными устройствами. Различия должны достигаться за счет возможности использования дополнительных возможностей, таких, как: - мобильный браузер от поставщика решения; - мобильный почтовый клиент от поставщика решения (и, соответственно, интеграция с почтовыми сервисами клиента по прокси-модели); - защищенный контейнер и корпоративное хранение и обмен данными; - функция «обертывания» (добавления дополнительного функционала) приложений; - и т.п. На этапе внедрения системы должны быть реализованы следующие различные по тарификации пакеты услуг. Все пакеты услуг должны быть реализованы в рамках одного решения. Лицензии являются неисключительными, бессрочными, на одно устройство; закупаются по соответствующим заказам, Ростелеком не имеет обязательств по покупке всех лицензий в соответствии с представленным прогнозом. Решение должно обрабатывать все бизнес-транзакции вне зависимости от ограничений лицензирования. Ограничение возможно только производительностью оборудования. Весь требуемый функционал должен обеспечиваться в рамках поставляемого решения, без необходимости дозакупки конечным клиентом или ОАО «Ростелеком» дополнительных услуг, работ и приложений от третьих лиц. Тип Пакета №1 Функционал Базовый функционал MDM Описание функционала Базовое управление политиками на мобильном устройстве, включающее следующий основной функционал: - централизованное управление приложениями; - управление обновлениями; - защищённый доступ к корпоративным сервисам; - удалённая блокировка и частичная или полная очистка устройства; - разрешение/запрещение доступа к корпоративным ресурсам; - настройка параметров конфигурации устройства при помощи про18 19 Безопасная почта филей; - карантин устройств и управление ими в индивидуальном порядке; - создание профилей с учетом формы владения устройством. Почтовый клиент для различных платформ, обеспечивающий разделение корпоративных и персональных данных. Также обеспечивает такие функциональные возможности, как запрет копирования, ограничение пересылки почты на определённый администратором список доменов и др. Тип пакета №2 Функционал Базовый функционал MDM Безопасная почта Защищенный контейнер и корпоративное хранение и обмен данными Описание функционала См.выше См.выше Хранилище для данных, обеспечивающее пользователям безопасный доступ к конфиденциальной информации с мобильных устройств. Должно поддерживать возможность просмотра/изменения/хранения данных из разнообразных источников: - хранилище системы; - корпоративные хранилища, такие как Sharepoint, сетевые папки и др. - облачные хранилища SkyDrive, GoogleDrive, Office365 и др. - CMIS - WebDAV Тип пакета №3 Функционал Базовый функционал MDM Безопасная почта Защищенный контейнер Изолированная рабочая среда Каталог приложений ПО для создания оболочек приложений Описание функционала См.выше См.выше См.выше Функционал, позволяющий централизованно управлять корпоративными приложениями и данными в контейнере без необходимости брать управление над устройством целиком. Функционал для управления внутренними, общедоступными и приобретёнными организацией приложениями. Позволяет создавать корпоративные каталоги приложений, централизованно управлять установкой приложений и обновлений на мобильных устройствах, реализовывать политики безопасности в контексте мобильных устройств. Для платформы Apple iOS должен поддерживаться функционал централизованного распространения и обновления корпоративных приложений без получения полного доступа к устройству в MDM. Функционал для создания оболочки приложений. Позволяет осуществлять дополнительный контроль за счет внедрения специальных политики, применимых к приложению или группе приложений, например: - необходимость аутентификации для запуска приложения; - ограничение возможности сохранять на мобильном устройстве данные, связанные с этим приложением; 19 20 Безопасный браузер - ограничение возможности использования команд по копированию/вставке. Браузер с предопределенными корпоративными политиками для работы в сети Интернет, например: - политиками использования cookie; - политиками копирования, печати; - "белыми" и "черными" списками доменов и веб-сайтов. 5.3 Требования к функционалу управления устройствами, функциям аудита устройств Требования данного пункта являются обязательными к реализации, кроме ряда указанных параметров. Внедряемое решение должно обеспечивать выполнение следующих задач: - контроль среды - местоположение (на основе данных GPS/ГЛОНАСС или мобильных вышек), контроль беспроводного трафика, аудит парка моделей и выведение из эксплуатации мобильных устройств; - контроль коммуникаций - почтовые настройки, настройки VPN соединения, настройки Wi-Fi, корпоративный AppStore; - контроль безопасности - установка сертификатов/политик для пользователей, контроль Jailbreak/Root прав, применение PIN-кодов и паролей на устройствах, удаленное отключение функций телефона, очистка устройства (Remote Wipe) и пользовательских приложений. Должна существовать возможность создать, сохранить и применить политики безопасности и профили настроек к мобильному устройству (группе устройств) в зависимости от производителям, модели, версии программного обеспечения на платформе, выполнения дополнительных требований (таких как geofencing, т.е. применение политик и профилей устройства в зависимости от географического положения устройства). Должна поддерживаться возможность выполнения следующих дистанционных действий с мобильным устройством: - возможность рассылки оповещений пользователям системы (в том числе и групповых) через SMS-, email-, push-сообщения на основании принадлежности к какойлибо административной группе; - возможность установить расписание работы (запрет на использование) приложений/функций (запрет камеры, запрет копирования в буфер и т.п.), установленных в мобильном устройстве; - запрос доступности мобильного устройства; 20 21 - блокирование паролем; - запрет копирования данных через буфер обмена; - наличие механизма карантина с настраиваемыми действиями при попадании устройства в карантин; - раздельный wipe (wipe корпоративных данных/wipe всех данных); - запрос координат GPS/ГЛОНАСС; - автоматические действия (блокировка ПО, очистка корпоративных данных или очистка памяти устройства, блокировка устройства) в случае попыток обхода действующих политик доступа к этим данным. Должны задаваться типы владения для подключаемых устройств, обеспечивающие различный уровень конфиденциальности для конечных пользователей системы: общекорпоративный, частно-корпоративный, личный и незаданный; для каждого типа должен быть задан изменяемый набор типов данных, доступных для сбора системой (данные о местоположении, о роуминге, о провайдере связи и т.п.). Решение должно обеспечивать получение следующей минимальной информации о мобильном устройстве. Объем собираемой информации может быть ограничен типом владения устройством: - MSISDN; - ICC ID; - IMEI; - текущий оператор связи; - уровень заряда батареи; - версия ОС на мобильном устройстве; - версия прошивки мобильных устройств; - версия клиентского ПО; - определение JailBreak; - список установленных сертификатов и профилей на мобильном устройстве; - GPS/ГЛОНАСС координаты (с возможностью блокирования этой функции); - информация об общей и свободной памяти устройства; - список установленных на мобильном устройстве приложений с версиями этих приложений; 21 22 На основе получаемых данных система должна формировать настраиваемые интерактивные сводные таблицы и графики, отображающие общее состояние парка устройств (с индикацией устройств, не прошедших политику, распределение по моделям, статусам функционирования, устройства с приложениями из черного списка, устройства без обязательных приложений и т.п.) Должно быть предусмотрена возможность запрета роуминга для устройства\группы устройств. Опционально должен быть реализован сбор данных об использовании устройством интернет-трафика, звонков, SMS; возможность создания планов использования телеком-возможностей мобильных устройств (голосовые данные, трафик, SMS) и возможность динамического назначения созданных планов на устройства\группы устройств. 5.4 Требования к управлению приложениями Требования данного пункта являются обязательными к реализации. Внедряемое решение должно обеспечивать следующие возможности управления приложениями: - возможность настройки приложений посредством создания соответствующих профилей в интерфейсе администратора с гибкой моделью применения, как минимум, по производителю, модели устройства, версии ПО; - установка приложений и обновление приложений из-под корпоративного аккаунта; - платформа должна позволять настраивать конечные мобильные приложения (изменять их настройки); - управление (удаление/запрет удаления) корпоративным ПО и корпоративными данными на устройстве; - чёрные и белые списки ПО, контроль по имени ПО; - автоматическая установка ПО (предоставление такой возможности) на основе определения платформы устройства и/или включения пользователя в группу доступа. Решение должно поддерживать создание каталога приложений для автоматизации распространения, слежения, обновления и защиты корпоративных мобильных приложений. Приложения могут быть публичными, устанавливаемыми из-под единого корпоративного аккаунта, так и внутрикорпоративными. Приложения из каталога должны устанавливаться как автоматически, так и пользователем самостоятельно. В интерфейсе редактирования профилей устройств должны существовать отдельные настройки для создания на рабочем столе устройств веб-ссылок на каталог приложений для самостоятельных действий пользователей. 22 23 Решение должно предоставлять функционал анализа репутации приложений (подозрительная сетевая активность, доступ к чувствительной информации, повышенный набор прав и т.п), на основе которого должны создаваться отчеты для администраторов, принимающих решение о включении приложения в черный список. Для осуществления возможности гибко настраивать политику управления и назначения приложений должен поддерживаться функционал создания специальных групп управления, совмещающей различные виды принадлежности устройства на основе следующего минимального набора параметров: - организационная группа; - группа пользователей; - тип собственности; - специальные теги; - платформа; - модель; - операционная система; - исключения (безусловный выбор конкретных устройств). Решение должно предоставлять возможность через интерфейс администратора создавать специальные профили настроек приложений для Apple- и Android-устройств, которые добавляют дополнительный функционал к корпоративным приложениям, такой как: - добавление аутентификации, а также функции single sign-on; - логирование; - ограничения по функциям, таким как: печать, копирование и вставка данных, доступ к камере, возможность передачи данных с помощью Bluetooth; - ограничения по сетевому доступу, например, запрет на использование Wi-Fi; - добавление настроек VPN-соединения; - добавление настроек прокси-сервера. 5.5 Требования к взаимодействию с инфраструктурой клиентов Требования данного пункта являются обязательными к реализации, кроме ряда указанных параметров. Сервис должен предоставляться клиентам без необходимости инсталляции программных или аппаратных средств в инфраструктуре клиента (программный клиент ставится только на мобильном устройстве), за исключением случаев необходимости интеграции системы с внутренними сервисами клиента. 23 24 В случае интеграции с инфраструктурой клиента должна быть обеспечена поддержка следующих систем и протоколов: Обязательные к реализации: - SCEP; - AD/LDAP и Domino; - аутентификация SAML/двухфакторная аутентификация; - Exchange Powershell; - Syslog. Опциональные к реализации: - BlackBerry Enterprise Server (BES); - OpenTrust CMS Mobile; - Entrust PKI; - Symantec MPKI; При интеграции должна быть обеспечена безопасность передаваемых данных и защита от компрометации данных по зашифрованному с помощью общедоступных методов (SSL) протоколу(HTTPS).. Программный клиент-прокси для интеграции должен предоставляться поставщиком решения, входить в стандартный функционал решения и иметь возможность упрощенной инсталляции и настройки. Под упрощенной инсталляцией подразумевается установка программного пакета на сервере клиента под управлением ОС семейства Windows с использованием стандартного установщика, а также возможность настройки клиента-прокси с помощью конфигурационного файла, созданного в веб-интерфейсе администратора решения. Веб-форма настройки интеграции должна иметь возможность задания URL-адреса, указывающего на опубликованный шлюз (клиент-прокси), возможность модификации (разрешение или запрещение) списка сервисов для взаимодействия, а также механизм проверки успешности соединения с клиентом-прокси. Клиент-прокси должен иметь режим работы для установки его в DMZ инфраструктуры клиента. Клиент-прокси должен иметь возможность логирования событий и сетевых соединений с настройкой минимального уровня важности (severity) событий. Дальнейшая настройка и использование интегрируемых сервисов должна происходить в соответствующих разделах настроек системы прозрачно для администратора системы (непривязанно к способу реализации интеграции), то есть с указанием непосредственных настроек серви24 25 сов, таких как локальные IP-адреса, доменные имена, сетевые порты и прочее, как если бы система функционировала на инфраструктуре клиента. Система не должна требовать установки аппаратной части у конечного пользователя для оказания услуг. Установка программной части допускается. Взаимодействие мобильного устройства пользователя с корпоративной сетью пользователя при необходимости может осуществляться по двум различным каналам, каналу управления мобильным устройством и каналу передачи корпоративных данных на устройство (e-mail, документооборот, Intranet-сайты). Выбор необходимого оборудования/программного обеспечения для шифрования канала возможен в соответствии с требованиями клиентов (если такая возможность технически осуществима для выбранного типа устройств) 5.6 Требования к взаимодействию с почтовыми сервисами Требования данного пункта являются обязательными к реализации, кроме ряда указанных параметров. Система должна поддерживать следующие модели взаимодействия с клиентскими почтовыми системами: - прокси-модель; - прямая интеграция. Для прокси-модели должны выполняться следующие требования: - поддержка почтовых систем: o o Обязательные к реализации: Microsoft Exchange 2003/2007/2010/2013; Lotus Domino (Lotus Notes); Novell GroupWise (with EAS); Опциональные к реализации: - Google Apps for Business. обеспечение безопасности передаваемых данных и защита от компрометации данных с помощью общедоступных методов (SSL, HTTPS), в случае необходимости должна применяться принудительная SSL-перегрузка. Программный клиент-прокси должен предоставляться поставщиком решения и иметь возможность упрощенной инсталляции и настройки. Под упрощенной инсталляцией подразумевается установка программного пакета на сервере клиента под управлением ОС семейства Windows с использованием стандартного установщика, а также возможность настройки клиента-прокси с помощью 25 26 конфигурационного файла, созданного в веб-интерфейсе администратора решения. Вебформа настройки компонента должна иметь возможность модификации различных параметров взаимодействия, а также механизм проверки успешности соединения с клиентом-прокси. - клиент-прокси для интеграции с почтовыми сервисами клиента должен обеспечивать шифрование как самих писем, так и приложенных к письмам файлов; должен реализовывать политики безопасности, настраиваемые администратором системы MDM через отдельную интерактивную форму, такие как: разрешение, запрещение синхронизации почты; запрещение доступа для незарегистрированных устройств; управление списком почтовых клиентов, разрешенных или запрещенных для синхронизации; управления доступом к почте на основе соблюдения политик соответствия (например, включен ли пароль на мобильном устройстве), на основе модели, версии ОС, активности мобильного устройства. - приложенные файлы, зашифрованные почтовым клиентом-прокси, должны открываться только в доверенном внешнем приложении от поставщика Решения. При прямой интеграции должны поддерживаться режимы работы с: - Powershell: поддержка Microsoft Exchange 2010/2013 и Microsoft Office 365 (обязательно); - Google Apps for Business: работа с почтовыми сервисами Google (опционально). Должна существовать возможность создания специальных профилей приложений для автоматической настройки почтовых клиентов. Должна обеспечиваться возможность создания данных профилей для почтовых клиентов, специфичных для поддерживаемых операционных систем и мобильных устройств, например Nitro TouchDown, а также для безопасного почтового клиента, предоставляемого поставщиком решения. Действия конечных пользователей по настройке почтового клиента должны быть сведены к минимуму (например, только ввод пароля). Безопасный почтовый клиент от поставщика решения должен быть доступен в магазинах приложений, таких как Apple App Store и Google Play Store. Настройка безопасного почтового клиента от поставщика решения должна осуществляться только через профиль настроек мобильных устройств администратором системы. На всех поддерживаемых на данный момент времени мобильных платформах должны в полной мере поддерживаться функции, такие как: 26 27 - полная поддержка протоколов Exchange ActiveSync; - поддержка протоколов SMTP/POP3/IMAP и пр.; - отображение дерева почтовых папок; - создание, ответ, пересылка, удаление почтовых сообщений; - использование календаря событий; - просмотр, модификация, использование контактов; - шифрование хранимой базы информации; - настраиваемый запрет на копирование информации через буфер обмена. Требования по шифрованию почты должны обеспечиваться как при интеграции с почтовыми системами раздела «Обязательные к реализации», так и при интеграции с почтовыми системами раздела «Опциональные к реализации» (в случае, если они реализованы). В случае отказа любого из модулей системы «Мобильный менеджмент», система не должна блокировать использование пользователями корпоративной почты на уже работающих с почтой мобильных устройствах. 5.7 Требование к системе клиентского самообслуживания решения Требования данного пункта являются обязательными к реализации. Решение должно предоставлять возможность самостоятельных действий пользователей через специальный портал самообслуживания. Администраторы клиента должны иметь возможность гранулировано настраивать доступ к функциям, предоставляемым данным порталом, либо же запрещать конкретным пользователям или группам пользователей доступ к порталу самообслуживания системы. Должна существовать возможность автоматически создавать веб-ссылки на устройствах для обеспечения быстрого доступа клиентов системы к порталу самообслуживания. Интерфейс портала должен поддерживать в том числе мобильные браузеры. Должны поддерживаться действия: - выбор зарегистрированного устройства, если у пользователя их несколько; - смена пароля; - передача сообщения на устройство; - блокировка устройства; - установка опциональных профилей настройки; - частичный (удаление корпоративных данных) и полный wipe устройства; - механизм обнаружения устройства; 27 28 - управление личным хранилищем данных; - запрос технической поддержки; - просмотр следующей информации об устройстве: соответствие политикам безопасности; состояние сети и функций шифрования; список установленных профилей и приложений; список корпоративных и личных документов, хранимых на устройстве в специальном хранилище; список установленных сертификатов; местоположение устройства; список событий. 5.8 Требования к клиентскому ПО на устройствах Требования данного пункта являются обязательными к реализации, кроме ряда указанных параметров. Управление со стороны мобильного устройства должно обеспечиваться при помощи программного клиента, получаемого с общедоступных магазинов приложений соответствующего производителя. Программный клиент должен обеспечивать минимальное участие конечного пользователя в настройке устройства и приложений (как правило, только ввод аутентификационной информации). Программный клиент должен иметь возможность воспроизводить следующие способы регистрации на устройстве: обязательные к реализации: o самостоятельный ввод информации по присланным (SMS, email) подробным инструкциям по подключению (сервер для подключения и прочие идентификационные данные); o ввод корпоративного email пользователя с автоматическим распознаванием домена пользователя и сопоставления ему соответствующей информации о подключении. опциональные к реализации: o анализ автоматически сгенерированного QR-кода с заключенной в нем информацией для подключения; 28 29 Программный клиент должен предоставлять информацию о статусе регистрации, режиме соответствия устройства политикам, техническом состоянии устройства(статусе подключения, состоянию батареи, местоположении, статусе сети), а также должен обеспечивать возможность сброса всех настроек решения, которое приводит устройство в первоначальное состояние с целью дальнейшей инициализации и настройки. Программный клиент должен иметь встроенную защиту от установки на jailbreak/rooted устройства или иметь механизмы выявления данных действий для отображения их в информации об устройстве в интерфейсе администратора. Решение должно поддерживать следующие платформы и устройства: обязательные к реализации: o Android версий 2.2 и старше; o Apple iOS версии 4.0 и старше; o Windows Phone 7 и 7.5 Mango; o Windows Phone 8; o BlackBerry 10; опциональные к реализации: o Symbian OS3 и S60. o Windows Mobile 5/6 и Windows CE 4/5/6; o BlackBerry 5, 6, 7; Для обязательных к реализации платформ и устройств должна обеспечиваться поддержка новых версий операционных систем в течение 10 дней со дня их официального релиза. Клиентское приложение для устройств под управление OS Android должно иметь единый дистрибутив как для устройств на Google Android, так и для устройств под управление ОС с измененными API (Samsung, Motorola, LG, Другие). Однако,. Для платформы Android решение должно поддерживать расширенные API, предоставляемые соответствующими производителями мобильных устройства. При настройке профилей управления устройствами и приложениями должна отображаться доступность функций в зависимости от версии расширенных API. обязательные к реализации: o Samsung KNOX, SAFE; опциональные к реализации: 29 30 o LG Gate; o HTC One; o Nokia Lumina. Решение должно обеспечить возможность работы с мобильным устройством без применения строгих профилей безопасности и получения полного контроля над устройством. При этом должна быть предоставлена изолированная рабочая среда (отдельное мобильное приложение) для централизованного доступа к корпоративному каталогу приложений, позволяющая пользователям системы самостоятельно выбрать установить приложения из списка рекомендуемых или обязательных(корпоративных) приложений. Данное приложение должно обеспечивать шифрование передаваемых и хранимых данных, с возможностью удаленного стирания всех данных администраторами системы. Данное приложение от поставщика Решения должно иметь возможность работы в двух режимах: режим отдельного запускаемого приложения и режим отдельного рабочего пространства, позволяя таким образом разделять для пользователя «корпоративный» и обычный режим работы устройства. 5.9 Требования к интерфейсу администраторов и пользователей Требования данного пункта являются обязательными к реализации. Интерфейс решения должен иметь различную функциональность в зависимости от уровня доступа: - Наивысший. Технический администратор Заказчика. Полное управление решением, добавление администраторов поддержки. Для просмотра и управления доступны все функции и все остальные аккаунты всех ролей. - Высокий. Администраторы поддержки Заказчика. Возможность добавления администраторов клиентов, пользователей клиентов. Для управления недоступны настройки системы. Доступны функции просмотра и управления аккаунтами администраторов поддержки клиентов и пользователей клиентов. - Средний. Администраторы поддержки клиентов. Возможность добавления пользователей клиентов. Для просмотра и управления доступны аккаунты администраторов поддержки клиентов и пользователей клиентов этой же компании-клиента. - Низший. Пользователи клиентов. Доступны только функции управления собственным аккаунтом в степени, определяемой администратором поддержки Заказчика или администратором поддержки этого же клиента (могут быть закрыты полностью) 30 31 Экран входа пользователей системы должен предоставлять возможность сброса или восстановления забытого пароля к системе. Должен быть предусмотрен механизм защиты от случайных действий для важных функций (например, wipe устройств). 5.10 Требования к управлению данными и потоками данных Требования данного пункта являются обязательными к реализации Решение должно предоставлять защищенный доступ с устройств к различным репозитариям данных. Репозитариями данных могут быть как внешние облачные ресурсы(OneDrive, Google Drive, Office 365 и пр.), так и внутренние ресурсы клиента (сетевые папки, sharepoint и пр.), для доступа к внутренним ресурсам должен существовать способ интеграции системы с инфраструктурой клиента. Добавление и настройка репозитариев должна происходить через соответствующей раздел веб-интерфейса администратора путем указания локальных (для внутренних ресурсов) или публичных (для внешних ресурсов) сетевых адресов или доменных имен, задания аутентификационных данных при необходимости, настроек групповых прав доступа. Должна существовать возможность задания шаблонов для добавления новых репозитариев данных. Решение должно предоставлять отдельное приложение (защищённый контейнер) от поставщика решения, которое будет обеспечивать защиту корпоративных данных и безопасный доступ пользователей к конфиденциальной информации с мобильных устройств, а также обеспечивать автоматическую синхронизацию с заданными репозитариями данных. Настройка защищенного контейнера должна происходить через отдельную форму в веб-интерфейсе администратора, конечному пользователю должно быть необходимо лишь аутентифицироваться в приложении на мобильном устройстве, либо администратор должен активировать функцию единого входа (Single Sign-On). Защищенный контейнер должен обеспечивать: - шифрование передаваемых и хранимых данных по безопасным протоколам; - возможность редактирования распространённых форматов документов(pdf, doc, xml); - возможность удаленного стирания хранимых данных на устройстве пользователя без «обнуления» самого устройства; - возможность для конечного пользователя предоставления доступа к личным документам другим пользователям для совместной работы; - запрещение копирования файлов или отдельных данных через буфер обмена. 31 32 5.11 Требования к подсистеме отчета Требования данного пункта являются обязательными к реализации, кроме ряда указанных параметров. Должна быть предусмотрена возможность создания отчётов по установленным критериям (моделям, группам устройств, действиям пользователям, событиям и т.д.). Отчетность должна быть доступна для выгрузки в форматах pdf, txt и csv. Опционально решение должно поддерживать интеграцию с SIEM системами. 5.12 Дополнительные требования Требования данного пункта являются опциональными к реализации. Система должна поддерживать следующие дополнительные функции: - поставщиком решения должен предоставляться безопасный интернет-браузер, распространяемый через общедоступные магазины приложений. Настройка данного браузера должна происходить только посредством настройки профиля приложения в веб-интерфейсе администратора системы. Должна быть предусмотрена функциональная возможность отключения или запрещения использования другого браузера (списка браузеров) на мобильном устройстве. Мобильный браузер должен отвечать следующим минимальным требованиям: доступ к веб-адресам по белым (запрещено все, что не разрешено) и черным спискам (разрешено все, что не запрещено); настраиваемый запрет на копирование информации через буфер обмена при работе с браузером; наличие режимов киоска, при котором доступ возможен только к заданному администратором веб-ресурсу, при этом исчезают панели навигации и поле ввода адреса и обычного режима, для которого работают белые и черные списки доступов. Наличие предустановленных в системе групп веб-сайтов, отнесенным к предопределенным категориям для включения в черные списки является плюсом решения и оценивается дополнительно. В случае наличия такого функционала обновление категорий и включенных в них веб-сайтов осуществляется поставщиком решения без дополнительной оплаты. 32 33 6 Требования к внедряемому решению в целом 6.1 Требования к структуре и функционированию решения Требования данного пункта являются обязательными к реализации. Для пользователей решение должно предоставляться по модели «программное обеспечение как услуга» (SaaS). Решение должно быть рассчитано на круглосуточный и ежедневный режим работы. Функционал системы должен предоставляться абонентам любого оператора сотовой связи. Решение должно строиться с использованием облачной платформы Заказчика – НОП и должно быть развернуто на территории Российской Федерации. Система самообслуживания решения должна располагаться по адресу в сети Интернет, определяемому ОАО «Ростелеком». Должны быть предусмотрены продуктивная и тестовая схемы внедряемого решения. Требования к тестовой схеме уточняются на этапе разработки технического проекта. Система должна предусматривать возможность включения режима временного использования “Try&Buy”, который предоставит администратору конечного пользователя использовать систему бесплатно на ограниченное время (3 месяца), по истечению которого управление устройствами станет неактивным до момента приобретения стандартных лицензий. Пользователи режима временного использования обслуживаются ОАО «Ростелеком» без приобретения каких-либо лицензий у Поставщика, бесплатно для ОАО «Ростелеком». Для каждого клиента, использующего режим временного использования, должно быть установлено ограничение количества конечных пользователей, равное 100. Количество клиентов, которые могут использовать режим временного использование, не должно быть ограничено. Переход из режима временного использования в режим постоянного (коммерческого использования) должен происходить без необходимости перезаведения клиента и перенастройки учетных и других данных. Решение должно иметь модульную структуру, где каждый модуль выполняет свойственную только ему функцию в рамках общей задачи. Такими модулями должны быть: - модули хранения данных; - модули управления и взаимодействия устройствами; - модули управления системой, предоставления интерфейса администратора. Система должна иметь возможность балансировки нагрузки между своими модулями. Параметры балансировки и её реализация должны быть уточнены на этапе разработки технического проекта. 33 34 Система должна иметь возможность добавления новых блоков функциональности от поставщика решения. Решение должно обеспечить поддержку следующих сценариев получения услуги: - клиент самостоятельно через систему самообслуживания или личный кабинет Компании или при помощи сотрудника Заказчика через интерфейс обслуживания клиентов подключает услугу; - при подключении услуги для клиента в multi-instance и multi-tenant среде решения создается отдельный профиль (при этом multi-tenant среда является предпочтительной для Заказчика); - клиент получает доступ к функциональным возможностям решения через кастомизированный под бренд Заказчика или под бренд клиента веб-интерфейс платформы (клиенту не требуется устанавливать дополнительное программное обеспечение на своей стороне для доступа к веб-интерфейсу). 6.2 Требования к производительности Требования данного пункта являются обязательными к реализации. На первый год эксплуатации система должна поддерживать управление 15000 устройств. Должна поддерживаться возможность модернизации и масштабирования системы (до сотен тысяч и миллионов устройств, а также тысяч компаний-клиентов). Решение должно обеспечивать KPI требуемого уровня сервиса в расчете на требуемую нагрузку. KPI предлагается поставщиком решения в рамках предложения. 6.3 Требования к характеристикам взаимосвязей со смежными системами Требования данного пункта являются обязательными к реализации. Информационная совместимость со смежными системами должна обеспечиваться с использованием согласованных протоколов информационного взаимодействия автоматизированных систем. Решение должно обеспечивать сбор информации об объеме ресурсов, предоставленных потребителям и предоставлять доступ к данной информации посредством API (REST\SOAP) с использованием средств аутентификации компоненту учета потребленных ресурсов облачной платформы Заказчика, а также системе биллинга Заказчика. 34 35 На этапе технического проектирования должны быть разработаны решения по взаимодействию с корпоративными информационными системами Заказчика, участвующими в настоящий момент в расчетах облачных услуг, в части подключения услуги через портал НОП и предоставления информации, необходимой для проведения расчетов по использованным услугам и выставления счетов. Управление услугой должно проходить через портал НОП (отработка команд по подключению, блокировке и разблокировке учетных записей корпоративных клиентов). Взаимодействие должно обеспечивать обмен следующими параметрами (как минимум): - количество подключенных пользователей на учетной записи корпоративного клиента; - тарифный план, используемый корпоративным клиентом. Используемый в системе API должен быть описан и детально документирован, а документация должна быть предоставлена до начала проекта внедрения и интеграции (язык может быть отличным от русского). Система должна предоставлять клиентам возможность интеграции с внешними решениями, выполняющими функции SMS-шлюзов. Также должна быть предусмотрена возможность предоставления клиенту системы предварительно настроенного SMS-сервиса, входящего в состав инфраструктуры Заказчика. Взаимодействие с SMS-шлюзом должно быть организованно по прото- 35 36 колу SMPP v3.4. Заказчик организует необходимые доступы и обеспечит каналы связи с предоставленным SMS-шлюзом. 6.4 Требования по доработке системы управления НОП и портала o7.com Требования данного пункта являются обязательными к реализации. В рамках оказания услуг по внедрению Системы необходимо доработать систему управления облачной платформы и портала O7.com, спроектировать, разработать и внедрить: карточку сервиса на портале o7.com с описанием и формой карточки заказа. адаптер оркестратора системы управления НОП, обеспечивающий интеграцию с компонентами сервиса «Мобильный менеджмент» и позволяющий: o создавать заказ посредством вызова соответствующего сервиса компонентов Системы; o редактировать заказ посредством вызова соответствующего сервиса компонентов Системы; o удалять заказ посредством вызова соответствующего сервиса компонентов Системы; компонент системы учета НОП, обеспечивающий периодическое получение данных по всем заказанным услугам от компонентов сервиса иформирование на основании полученных данных файлов необходимого формата для последующей передачи файлов в систему предбилинга ОАО «Ростелеком» Форма карточки заказа должна быть аналогичной уже используемым в рамках предоставления других услуг на портале О7 и содержать: Наименование услуги для корректного отображения в панели управления , для случая, если клиент заказал несколько услуг; Выбор типа пакета; Количество пользователей (по каждому типу пакета, если их более 1); Информацию о заказчике; Страницу подтверждения заказа по введеным значениям. - 36 37 6.5 Требования к численности и квалификации персонала системы и режиму его работы В процессе оказания услуг по внедрению сервиса и подготовки эксплуатационной документации требуется разработать требования к количеству, квалификации и режимам работы персонала, задействованного для обеспечения работоспособности сервиса. Численность и квалификация персонала системы должны определяться с учетом следующих требований: - структура и конфигурация системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала; - структура системы должна предоставлять возможность управления всем доступным функционалом системы как одному администратору, так и предоставлять возможность разделения ответственности по администрированию между несколькими администраторами; - для администрирования системы к администратору не должны предъявляться требования по знанию всех особенностей функционирования элементов, входящих в состав администрируемых компонентов системы; - аппаратно-программный комплекс системы не должен требовать круглосуточного обслуживания и присутствия администраторов у консоли управления. Штатный состав персонала, эксплуатирующего систему, должен формироваться на основании нормативных документов Российской Федерации и Трудового кодекса. Все специалисты должны работать с нормальным графиком работы не более 8 часов в сутки. Управление системы реализуется на персональных компьютерах, поэтому требования к организации труда и режима отдыха при работе с ней должны устанавливаться, исходя из требований к организации труда и режима отдыха при работе с этим типом средств вычислительной техники. 6.6 Требования по эргономике и технической эстетике Требования данного пункта являются обязательными к реализации. Интерактивная среда управления сервисом должна обеспечивать удобный для администратора интерфейс, позволяющий управлять всеми функциями системы в едином пространстве. Интерактивная среда управления сервисом должна обеспечивать интерфейс, отвечающий следующим требованиям в части интерактивного взаимодействия с персоналом: 37 38 - должен быть обеспечен удобный и интуитивно понятный интерфейс для персонала, который хорошо знает свою предметную область, но не обладает достаточными знаниями в области информационных технологий; - взаимодействие персонала и пользователей с сервисом должно осуществляться на русском языке (исключения могут составлять только системные сообщения, не подлежащие русификации); - должно быть обеспечено предоставление быстрого доступа к справочной информации, оснащенной механизмами интерактивного поиска; - интерфейс должен поддерживать мультиязычность (минимальный набор языков – русский и английский). Смена языка производится из самого интерфейса. - интерфейс должен быть единым и самодостаточным, все управление всеми доступными клиенту функциями должно осуществляться из единого интерфейса (вебсайта), без необходимости перехода в другие интерфейсы (веб-сайты). 6.7 Требования по унификации и стандартизации Требования данного пункта являются обязательными к реализации. Управление системой и взаимодействие пользователей и администраторов системы должно осуществляться через веб-интерфейс. Веб-интерфейс системы должен поддерживать основные браузеры: - Internet Explorer версии 6 и выше; - Chrome 11 и выше; - FireFox версии 3.0 и выше; - Safari версии 5.0 и выше. Работа с иными или устаревшими версиями интернет-браузеров приветствуется, но не должна быть гарантирована. Должны быть предусмотрены всплывающие подсказки к ключевым действиям, которые должны отображаться только на русском языке; Интерфейс системы должен для каждой организационной единицы иметь возможность изменения силами администраторов Заказчика или клиента под требования клиента непосредственно с помощью инструментов, предоставляемых интерфейсом системы. Для этого в интерфейсе системы должен быть предусмотрен специальный раздел, группирующий следующие функции: 38 39 - возможность замены стандартного логотипа и размещение логотипа клиента, должна поддерживаться возможность загрузить изображение с логотипом клиента. Логотип может быть основной и дополнительный; - задание внешнего URL для элемента управления, в котором размещается логотип клиента; - изменение изображения для страницы входа в веб-консоль администрирования, должна поддерживаться возможность загрузить данное изображение; - изменение цветовой гаммы интерфейса (изменение цветов кнопок, фона, других элементов), веб-интерфейс должен предоставлять выбор предзаданных цветовых шаблонов, а также возможность их изменения (задание цветов с помощью числобуквенных кодов RBG, либо выбора цвета на интерактивном окне-палитре); - возможность углубленного изменения интерфейса путем задания через специальную форму css-кодов для графических элементов интерфейса. 6.8 Требования к программным средствам Требования данного пункта являются обязательными к реализации. Программные средства для работы системы должны соответствовать предъявленным требованиям и иметь техническую поддержку от производителя. Все компоненты системы должны иметь возможность работать в выбранной виртуализированной среде, без жестких требований к программному обеспечению для виртуализации, как минимум, VMWare ESX\ESXi. Компоненты системы должны иметь возможность работы под операционной системой Microsoft Windows, компоненты обеспечивающие балансировку нагрузки и шлюз во внешнюю сеть должны располагается в демилитаризованной зоне и иметь реализации под Microsoft Windows и Unix платформу. Уровень хранения данных должен быть построен на основе современных реляционных или объектно-реляционных СУБД (Систем Управления Базами Данных), ориентированных на внедрение в облачных инфраструктурах. Обеспечение целостности данных должны использоваться встроенные механизмы СУБД. Требования к программному обеспечению сервиса уточняются на стадии разработки технического проекта. 6.9 Требования к техническому обеспечению Требования данного пункта являются обязательными к реализации. 39 40 Техническое обеспечение сервиса должно быть реализовано на решениях, предоставленных облачной платформой Заказчика и располагаться в ЦОДе Заказчика. Требования к техническому обеспечению решения уточняются на стадии разработки технического проекта. 6.10 Резервное копирование данных Требования данного пункта являются обязательными к реализации. Для обеспечения сохранности данных и возможности их восстановления, а также восстановления функционирования системы при авариях в процессе эксплуатации должна создаваться резервная копия системных и хранимых данных. Система резервного копирования данных должна базироваться на возможностях, предоставляемых средствами облачной платформы Заказчика, а также должны быть ориентирована на согласованные требования по отказоустойчивости сервиса. Требования к организации резервного копирования сервиса уточняются на стадии разработки технического проекта. 6.11 Мониторинг и управление Требования данного пункта являются обязательными к реализации. Решение должно поддерживать централизованное управление всеми своими компонентами. Решение должно обеспечивать мониторинг и логирование деятельности и активностей администратора системы, а также поддерживать механизм генерации аварии или инцидента при наступлении событий: преодоление определенных порогов показателей, отсутствие данных и др. Система должна поддерживать отдельное добавление параметров мониторинга, управления или контроля мобильных устройств в списке доступных для администратора клиента. Доступность/закрытие опций возможно изменять по запросу от клиента. Решение должно поддерживать механизм API для взаимодействия и управления системой и ее компонентами из внешних автоматизированных систем. Решение должно поддерживать механизм генерации аварии или инцидента при наступлении событий: преодоление определенных порогов показателей, отсутствие данных и др. Решение должно поддерживать механизм назначения приоритета аварий на основе заданных правил (по severity). 40 41 Пороги для генерации аварий должны быть конфигурируемыми пользователем, система должна поддерживать задание нескольких порогов (на пример warning, violation) и соответственно генерацию различных типов аварий (severity). Внедряемая система должна поддерживать различные механизмы определения порогов: - в зависимости от времени суток, дня недели; - в зависимости от допустимого коридора значений (trend); - фиксированный (<, >, диапазон); - динамический; - на основе исторических данных с различной детализацией (день недели, период времени суток, день месяца, заданный период); - автоматическое определение порогов на основе статистических данных. Решение должно поддерживать механизмы экспорта аварийных сообщений во внешнюю систему обработки аварий. Решение должно содержать различные способы уведомлений о наличии аварийных и других сообщений (по email, SMS, и т.д.) и поддержку списка адресатов рассылки уведомлений. Решение должно обеспечивать мониторинг и обнаружение деградации сервиса. Решение должно поддерживать визуализацию активных сервисных аварий и состояния показателей качества услуг на географической карте. Решение должно поддерживать формирование специальных аварий по группе клиентов или услуг, предоставляемых корпоративному клиенту или группе клиентов, для поддержки SLA с клиентами. В системе должны быть реализованы функции протоколирования событий безопасности. Обязательному протоколированию (регистрации) подлежат: - факты использования административных привилегий, в том числе, изменение политик аудита; - успешные и неуспешные попытки входа в систему; - факты выхода из системы; - запуск и остановка функции аудита. Функция аудита должна однозначно сопоставлять каждое подлежащее аудиту событие с идентификатором пользователя, который был инициатором этого события с фиксацией времени события и определением, по возможности, адреса (например, сетевого). Должно быть реализовано разграничение доступа к журналам регистрации, предотвращающее несанкционированное удаление и изменение записей в журнале. 41 42 Должна быть реализована возможность, в рамках ИС, централизованного сбора и хранения журналов регистрации, либо поддерживаться интерфейс с решениями по сбору и хранению журналов, используемыми в Компании. Перечень регистрируемых событий, формат данных регистрации должны быть документированы в эксплуатационной документации на систему. 6.12 Требования к режимам функционирования Требования данного пункта являются обязательными к реализации. Для сервиса должны быть определены следующие режимы функционирования: - штатный режим; - режим технического обслуживания; Штатный режим функционирования является основным при эксплуатации сервиса. В данном режиме сервис должен обеспечивать выполнение всех заявленных функций и обеспечивать работы зарегистрированных пользователей в соответствии с показателями назначения. Режим технического обслуживания должен использоваться для обновления программного обеспечения компонентов сервиса, введения в работу новых компонент в рамках задачи масштабирования и выполнения прочих работ, связанных с текущим техническим обслуживанием. В данном режиме сервис в целом или его отдельные функции становятся недоступными для пользователей с соответствующим предупреждением, либо происходит частичное ухудшение сервиса без его остановки. 6.13 Перспективы развития, модернизации системы Требования данного пункта являются обязательными к реализации. Система должна реализовывать возможность дальнейшей модернизации как программного обеспечения, так комплекса технических средств. Необходимо предусмотреть возможность увеличения производительности системы путем её масштабирования. Должны быть обеспечены методы: горизонтального масштабирования (увеличение количества серверных компонентов с балансировкой серверной нагрузки), вертикального масштабирования (увеличение производительности каждого компонента системы c целью повышения общей производительности). Решение должно подвергаться масштабированию путем модернизации или добавления компонентных модулей без внесения изменений в код программного обеспечения или общую архитектуру решения. 42 43 6.14 Требования к информационной безопасности Требования данного пункта являются обязательными к реализации. Система должен удовлетворять следующим требованиям: - доступ к системе должен осуществляться только авторизованным пользователям с учетом служебных полномочий; - система должна поддерживать разделение ролей пользователей по уровню доступа (администратор платформы, администратор группы клиентов, администратор клиентского аккаунта и т.д.) - все действия администраторов в системе должны фиксироваться и быть доступны в электронном контрольном журнале; - система должна быть защищена от атак посредством подбора паролей путем блокировки учетной записи при нескольких попытках входа в систему, учетная запись должна быть заблокирована на задаваемый интервал времени; - должны существовать встроенные механизмы ограничения действий администраторов, а также защита о случайных действий, например путем ввода пин-кода для разрешения определенных важных действий; - решение должно разделять доступ для разных компаний-клиентов (один клиент не должен иметь возможности просматривать информацию о других клиентах) - каждому пользователю должна соответствовать индивидуальная учетная запись в системе, использование групповых учетных записей запрещено; - пользовательские идентификаторы не должны явно указывать на уровень привилегий пользователя; - функция аутентификации должна активно противостоять атакам, направленных на подбор пароля, для этого, например, может использоваться временная или постоянная блокировка учетных записей, механизм увеличения временного интервала между вводом пароля, иные методы. - функция идентификации/аутентификации должна использовать стандартные и криптостойкие протоколы аутентификации, реализующие механизмы единого и прозрачного входа в систему, и использовать единые источники централизованного хранения информации о пользователях, используемые в компании (Active Directory, LDAP); - для доступа к системе (любым компонентам) должен применяться такой режим аутентификации, который не позволит скомпрометировать аутентификационную информацию и не позволит заблокировать аккаунты пользователей в централизованном хранилище; 43 44 - возможность запроса персональных сертификатов для конкретного пользователя на существующей системе, безопасное хранение и распространение сертификатов на устройства - все стандартные (создаваемые по-умолчанию) пользователи должны быть документированы в эксплуатационной документации. - должна поддерживаться возможность смены паролей, удаления, блокировки или модификации стандартных пользователей. - необходимо предусмотреть возможность временного ограничения продолжительности сессии пользователя, либо средствами информационной системы регулярно запрашивать аутентификационную информацию для подтверждения полномочий и продления сессии. - система должна поддерживать реверсивные прокси от ведущих производителей на рынке (Bluecoat, Microsoft, F5 Networks, IBM, Cisco) для размещения системы в закрытом контуре и безопасной публикации сервисов в интернет. Требования к информационной безопасности уточняются на стадии разработки технического проекта. 6.15 Требования по криптографической поддержке Требования данного пункта являются обязательными к реализации. Внедряемое решение должно отвечать следующим требованиям: - применение средств криптозащиты обязательно при хранении и передаче строго конфиденциальной информации (во всех случаях), и передаче конфиденциальной информации по публичным сетям. - для защиты данных при хранении и передаче должны использоваться криптографически стойкие алгоритмы и протоколы. Рекомендуется использовать промышленные, прошедшие тестирование, криптографические протоколы и алгоритмы: 3DES, AES, Blowfish, RSA, ГОСТ 28147-89, ГОСТ Р 34.11/34.10-2001, MD5, SHA1. - в ИС, использующих криптографические системы с открытым ключом, необходима поддержка интеграции с инфраструктурой открытых ключей Компании. - система должна быть сертифицирована или иметь плановые сроки сертификации в органах ФСТЭК в 2015 г., к моменту ввода сервиса в коммерческую эксплуатацию. - процесс управления ключами (генерация, распределение, хранение, смена, уничтожение, восстановление) должен быть документирован. 44 45 6.16 Требования к соблюдению конфиденциальности информации Требования данного пункта являются обязательными к реализации. Поставщик решения обязуется не разглашать третьим лицам конфиденциальную информацию и не использовать её любым другим образом, кроме как для выполнения задач в рамках настоящего задания. Поставщик обязуется предпринять все необходимые меры для предотвращения разглашения конфиденциальной информации его сотрудниками, в том числе и после их увольнения. Предпринятые Поставщиком меры по предотвращению разглашения конфиденциальной информации должны быть не меньшими, чем меры, предпринимаемые Заказчиком по предотвращению разглашения собственной информации, считаемой Заказчиком конфиденциальной. 6.17 Специальные требования Требования данного пункта являются обязательными к реализации. В процессе проектирования системы должен быть учтен опыт создания и эксплуатации подобных информационных систем в Российской Федерации и в мире, в том числе для операторской модели предоставления услуги MDM, а также должны быть учтены технические особенности и функциональные возможности, предоставляемые НОП, на основе которой будет происходить внедрение данного решения. В комплект поставки должна входить стоимость всех лицензий системного программного обеспечения, необходимого для работы системы. 45 46 7 Требования к качеству, техническим характеристикам и результатам оказания услуг по сопровождению Сервиса MDM Требования данного пункта, включая все подпункты, являются обязательными к реализации. 7.1 Общие требования Услуги по сопровождению Сервиса MDM должны включать в себя: - техническую поддержку инфраструктуры и прикладного ПО Сервиса MDM; - техническую поддержку и консультации пользователей по вопросам использования и работы Сервиса MDM; - обновление прикладного ПО Сервиса MDM. В рамках технической поддержки Исполнитель должен предоставлять Заказчику услугу по обеспечению работоспособности программного обеспечения Сервиса в круглосуточном режиме. Организационная модель эксплуатации Исполнителя должна быть направлена на минимизацию возможных периодов недоступности или неработоспособности Сервиса. Приём запросов в техническую поддержку должен осуществляться Исполнителем круглосуточно, 24 часа в сутки, 7 дней в неделю. Приоритет - критерий важности и срочности решения инцидента, с учётом влияния, оказываемого на пользователей ИС. В ходе эксплуатации Сервис, должны быть выделены не менее 3-х типов приоритетов для возникающих инцидентов. Приоритет инцидента Описание Аварийная внештатная ситуация, связанная с полной или частич1-го приоритета (Критичный) ной потерей более 50% функционала работоспособности Сервиса Частичная потеря работоспособности ПО, не приводящая к потере 2-го приоритета (Высокий) критичного (основного) функционала, возможны альтернативные варианты выполнения основных функций Сервиса 3-го приоритета (СтандартСнижение производительности, не приводящие к потере функционый) нала Сервиса Время реакции на инцидент (время, с момента регистрации инцидента до момента принятия инцидента в работу) должно зависеть от приоритета, но быть не ниже представленных: - критичный – 30 минут; - высокий – 1 рабочих часа; - стандартный – 2 рабочих часа. Параметры оказания услуг эксплуатации должны быть не ниже следующих: 46 47 Вид запроса Инцидент Максимальное допустимое время устранения инцидента, в зависимости от приоритета Критичный Высокий Стандартный 4 часа 8 рабочих часов 24 рабочих часа Инциденты с приоритетом «Критичный» должны обрабатываться в круглосуточном режиме, остальные приоритеты с 09.00 до 18.00 часов (московское время) ежедневно по рабочим дням, установленным Правительством Российской Федерации. Работы Исполнителя по исполнению заявок (в том числе устранение неисправностей, предоставление консультаций и обработке стандартных запросов) могут быть приостановлены Исполнителем, если часть работ (ответственности) по обработке запроса находится вне зоны ответственности Исполнителя. Примерами таких случаев являются: - устранение неисправности, находящейся в зоне ответственности Заказчика, если таковая выявлена Исполнителем в результате диагностики; - требуется действие со стороны Заказчика, вплоть до выполнения данного действия Заказчиком. Заказчик должны быть уведомлены о том, что работы приостановлены до выполнения необходимого действия; - Заказчику был отправлен запрос на получение дополнительной информации, с момента уведомления Заказчика вплоть до предоставления таковой Заказчиком. Проведение плановых регламентных работ, требующих прерывание сервиса, возможно с 21:00 до 07:00 (по московскому времени) с уведомлением Заказчика о проведении работ за 8 рабочих часов до начала работ. Уведомления о проведении неотложных работ за 2 часа до начала работ. Проведение регламентных работ, нарушающих работоспособность, допускается не чаще 3 раз в месяц. Более частые работы должны быть согласованы с Заказчиком. 7.2 Требования к технической поддержке и консультированию пользователей по вопросам использования и работы Системы В рамках эксплуатации Системы необходимо обеспечить оказание следующих Услуг: Наименование услуги Сроки исполнения: начало/окончание Консультирование Заказчика по вопросам функционала С момента тестовой эксплуатации до оконча- 47 48 решения ния договора на техническую поддержку Консультирование пользователей Заказчика по вопросам С момента тестовой эксплуатации до окончафункционала решения ния договора на техническую поддержку Время реакции на обращения по предоставления консультаций и выполнения стандартных запросов на обслуживание (время, с момента регистрации инцидента до момента принятия инцидента в работу) не больше 2 рабочих часов. Параметры времени предоставления консультаций и выполнения стандартных запросов на обслуживание: Вид запроса Максимальное допустимое время устране- Согласование Форма подачи ния инцидента, в зависимости от приори- запроса запроса тета, рабочих часов Критичный Высокий Стандартный Консультирование Не требуется Заказчика по вопро- ращение 81 сам предоставления Телефонное обЭлектронная Услуги почта Стандартные запросы2 Внесение изменений Требуется со- Технические в гласование За- требования конфигурацию программноаппаратной инфра- структуры Сервиса 403 804 к казчика и Ис- выполнению полнителя изменений MDM 1 С момента предоставления инициатором запроса на консультацию полной информации, необходимой для исполне- ния запроса. 2 Указанное время отсчитывается с момента предоставления полного и детализированного технического решения по необходимым изменениям и согласования его с Заказчиком и Исполнителем. При необходимости время внесения изменений могут быть отдельно согласованы Заказчиком и Исполнителем. 3 С момента предоставления инициатором запроса на консультацию полной информации, необходимой для исполне- ния запроса. 4 С момента предоставления инициатором запроса на консультацию полной информации, необходимой для исполне- ния запроса. 48 49 Работы Исполнителя по исполнению запросов (в том числе предоставление консультаций и обработке стандартных запросов) могут быть приостановлены Исполнителем (инцидент или запрос переведены в ожидание), если часть работ (ответственности) по обработке запроса находится в зоне ответственности Заказчика. Примерами таких случаев являются: 1. Устранение неисправности, находящейся в зоне ответственности Заказчика или аппаратного обеспечения, используемого в НОП, если таковая выявлена Исполнителем в результате диагностики (в том числе и в случае необходимости замены или ремонта вышедшего из строя оборудования НОП); 2. Требуется действия со стороны Заказчика, вплоть до выполнения данного действия Заказчиком. Заказчик должен быть уведомлен о том, что работы приостановлены до выполнения необходимого действия; 3. Заказчику или Заявителю был отправлен запрос на получение дополнительной информации, с момента уведомления Заказчика вплоть до предоставления таковой Заказчиком; 4. Исполнителю необходимо получить доступ к виртуальным серверам и программному обеспечению Сервиса, вплоть до получения необходимых доступов. В таблице ниже приведены Услуги, нарушение предоставления которых, а также их отсутствие, оказывает влияние на поддержание согласованного уровня предоставления для текущей Услуги: Наименование связанных услуг и/или информационных систем Ответственный за предоставление Предоставление Услуги регистрации запросов Заказчик Вычислительная инфраструктура Национальной Облачной Платформы (НОП) Заказчик В таблице ниже приведены Услуги и информационные системы, смежные относительно Услуги, и имеющие высокую степень интеграции с Сервисом MDM: Наименование связанных услуг и/или информационных систем Ответственный за предоставление Система управления Национальная Облачной Платформой (НОП) Заказчик Система идентификации и аутентификации О7 Заказчик Описанные выше параметры предоставления Услуг должны быть гарантированы Исполнителем в случае, если Заказчик обеспечил бесперебойное функционирование в круглосуточном режиме связанных информационных систем и Услуг, приведенных в таблицах данного раздела. 49 50 7.3 Требования к составу услуг технической поддержки Сервиса. В рамках предоставления услуг технической поддержки Исполнитель должен осуществлять выполнение следующего перечня основных операций и оказание следующих услуг: - документирование всех запросов на поддержку Сервиса и процесса выполнения запросов пользователей; - мониторинг работоспособности и производительности Сервиса; - подготовка, согласование, тестирование и проведение изменений настроек Сервиса; - устранение замечаний к функционированию Сервиса; - устранение возникающих инцидентов и проблем с Сервисом; - проведение регламентных работ; - периодическое резервное копирование данных и настроек систем; - установку релизов и обновлений: o обновление системы до минорных версий ( не более 4-х раз в год); o обновление системы до мажорных версий (не более 2-х раз в год). 7.4 Требования к организационному обеспечению эксплуатации Для обеспечения эффективной эксплуатации ИТ-процессов в качестве методологического основания должны применяться рекомендации IT Infrastructure Library версии 3 (ITIL v3). Целью организации качественного управления эксплуатацией Сервиса должно быть: - обеспечение качественного предоставления ИТ-услуг, связанных с эксплуатацией Сервиса; - оптимизация взаимодействия участников Службы эксплуатации, участвующих в организации эксплуатации Сервиса; - обеспечение единого информационного пространства при работе в рамках установленных ИТ-процессов; - предоставление оперативных аналитических данных, отчетов о текущих результатах эксплуатации, формирование отчетов, необходимых для контроля качества эксплуатации Сервиса. 50 51 8 Порядок контроля и приемки результатов оказанных услуг Сдача-приемка результатов оказанных услуг осуществляется в соответствии с требованиями к результатам услуг в соответствии с условиями Договора с предоставлением отчетной документации и завершается оформлением Акта сдачи-приемки оказанных Услуг, подписанного Исполнителем и Заказчиком. 51 52 9 Требования к результатам работ 9.1 Требования к документированию В рамках проведения работ должны быть разработаны следующие документы: - частное техническое задание на оказание услуг по теме «Внедрение сервиса «Мобильный менеджмент»; - комплект проектной документации; - комплект рабочей и эксплуатационной документации; - комплект организационно-распорядительных документов. Комплект проектной документации должен состоять из следующих документов: - ведомость технического проекта; - пояснительная записка; - техническое задание; - технический проект; - рабочий проект. Комплект рабочей документации должен состоять из следующих документов: - программа тестовой эксплуатации; - программы и методики приемочных испытаний (ПМИ). Комплект эксплуатационной документации должен состоять из следующих документов: - руководство администратора; - руководство пользователя; - проект регламента технической поддержки сервиса. Комплект организационно-распорядительных документов должен состоять из следующих документов: - протокол приемочных испытаний. Комплект отчетной документации должен состоять из следующих документов: - отчет по итогам оказания услуг по эксплуатации и сопровождению сервиса «Мобильный менеджмент» (в соответствии с формой, указанной в Приложение №1); Отчетная документация должна прилагаться в бумажном и электронном виде (на оптическом CD или DVD носителе) на русском языке. Вспомогательная документация (не указанная в качестве непосредственного результата работ) должна передаваться в электронном виде. 52 53 9.2 Требования к оформлению Вся разрабатываемая документация должна быть на русском языке. Исключения допускаются для общепринятых терминов и аббревиатур, а также технической документации, поставляемой с оборудованием и программным обеспечением импортного производства Разрабатываемая документация должна соответствовать следующим требованиям: - язык материалов – русский; - отчетные материалы должны быть предоставлены на бумажном носителе и в электронной форме; - отчетные материалы на бумажном носителе должны быть оформлены на листах формата А3 или А4; - номера листов(страниц) должны быть проставлены, начиная с первого листа, следующего за титульным листом, в верхней части листа(над текстом, посередине); - на титульном листе должно быть помещено наименование отчетного материала, учетные реквизиты, подписи Исполнителя и Соисполнителей, скрепленные печатями; - отчеты и материалы в электронном виде должны быть представлены на оптическом диске, исключающем возможность изменения информации( CD-R, DVD-R, DVD+R); - форматы предоставления информации в электронном виде - doc, rtd, vsd, ppt, xml, pdf. 53 54 10 Информация, требуемая для оценки технико-коммерческих предложений. Для оценки необходимо предоставить лист расчёта стоимости владения сервисом за 5 лет, включающий: Стоимость внедрения сервиса, включающую все работы и услуги, необходимые для инсталляции ПО, его адаптации и интеграции с информационными системами ОАО «Ростелеком» согласно Техническому заданию, а также включая все требуемое для дальнейшей эксплуатации прикладное ПО; Стоимость лицензий, исходя из следующих данных: Количество пользователей по годам накопительным итогом: 1 год – 15 000 2 год – 30 000 3 год – 45 000 4 год – 60 000 5 год – 60 000 Распределение пользователей по пакетам: Пакет №1 – 70% от общего количества; Пакет №2 – 25% от общего количества; Пакет №3 – 5% от общего количества; Стоимость технической поддержки в соответствии с требованиями, предъявляемыми в рамках технического задания. Суммарная стоимость технической поддержки (размер всех операционных затрат в рамках Договора №3) не может превышать 25% от стоимости лицензий, приобретаемых в рамках Договора №2; Требования, предъявляемые к вычислительным ресурсам, выделяемым в облачной платформе ОАО «Ростелеком», исходя из указанных в п.2 данных Прочие работы и услуги, требуемые для запуска и сопровождения продукта; Все положения Технического задания и замечания Участника конкурса в виде комментариев к соответствующим положениям Технического задания. Комментарии участника конкурса выделяются красным цветом и курсивом. Пример формы для заполнения (конечный вариант формы остается на усмотрении участника): 54 55 Пример подачи информации.xlsx 55 56 Приложение № 1 к Договору № ___________ от «___» _______ 20__ г ФОРМА начало формы ОТЧЕТ по итогам оказания услуг по эксплуатации и сопровождению сервиса «Мобильный менеджмент» № Номер инциденТема Тип Статус Дата Дата реРешение п/п та создания шения 1 2 3 4 5 6 7 8 Текущее программно-аппаратное обеспечение сервиса «Мобильный менеджмент»: исправно, функционирует в штатном режиме 1 2 … от Исполнителя: Должность ________________ / ФИО / М.П. окончание формы С формой Приложения к Договору согласны: от Заказчика: от Исполнителя: _______________ М.П. _______________ М.П. 56
