4 Требования к подсистемам
advertisement
СООБЩЕНИЕ о заинтересованности в проведении открытой процедуры закупки на право заключить договор на выполнение работ, поставку оборудования и программного обеспечения по единому инфраструктурному проекту Государственной корпорации «Ростех» Государственная корпорация «Ростех» сообщает о своей заинтересованности в проведении открытой процедуры закупки на право заключить договор на выполнение работ, поставке оборудования и программного обеспечения для Единого инфраструктурного проекта в порядке, установленном Федеральным законом от 18 июля 2011 года № 223-ФЗ «О закупках товаров, работ, услуг отдельными видами юридических лиц» (далее – Услуги). Указанное сообщение не является публичной офертой. Просим всех заинтересованных лиц представить свои предложения по стоимости услуг, поставки оборудования и программного обеспечения по прилагаемой форме (Приложение 1), и направить их в письменном или в электронном виде (наличие электронно-цифровой подписи необязательно) (далее – Предложения). Предложения не могут быть анонимными. Информируем, что направленные в адрес заказчика Предложения не будут рассматриваться в качестве заявки на участие в процедуре закупки или оферты на заключение договора, и не дают в дальнейшем каких-либо преимуществ для лиц, подавших указанные предложения. Рассмотрение заказчиком поступивших предложений не предполагает какого-либо информирования (в т.ч. публичного) лиц, подавших такие предложения и иных лиц о результатах рассмотрения. По результатам рассмотрения Предложений заключение договора не осуществляется. Предложения принимаются по адресу: 119991, г. Москва, Гоголевский бульвар, дом 21, строение 1 – по почте (с пометкой: для Управления информационных технологий Департамента коммуникации и информации); г. Москва, ул. Усачева, дом 24 – нарочным Референту Управления информационных технологий (495) 987-65-30. Ермакова Виктория Леонидовна V.L.Ermakova@rostec.ru – в электронном виде. Срок подачи предложений: до 22 декабря 2014 года. Контактное лицо: Парфенов Сергей Александрович, S.A.Parfenov@rostec.ru, (495) 987-25-00, доб.24-72 Приложение 1 Блок Инфраструктура виртуальных рабочих столов: Оборудование: Артик ул Описани е Комментар Колий во Цена Стоим ость Артик ул Описани е Комментар Колий во Цена Стоим ость ПО: Работы: Описани е Комментар Стоим ий ость Блок Система объединенных коммуникаций: Оборудование: Артик ул Описани е Комментар Колий во Цена Стоим ость Артик ул Описани е Комментар Колий во Цена Стоим ость ПО: Работы: Описани е Комментар Стоим ий ость Блок Система резервного копирования Оборудование: Артик ул Описани е Комментар Колий во Цена Стоим ость Артик ул Описани е Комментар Колий во Цена Стоим ость ПО: Работы: Описани е Комментар Стоим ий ость Блок Инфраструктура беспроводного доступа Оборудование: Артик Описани Комментар Кол- Цена Стоим ул е ий во Артик ул Описани е Комментар Колий во ость ПО: Цена Стоим ость Работы: Описани е Комментар Стоим ий ость Блок Система управления мобильными устройствами Оборудование: Артик ул Описани е Комментар Колий во Цена Стоим ость Артик ул Описани е Комментар Колий во Цена Стоим ость ПО: Работы: Описани е Комментар Стоим ий ость Блок Комплексная среда контроля ИТ: Оборудование: Артик ул Описани е Комментар Колий во Цена Стоим ость Артик ул Описани е Комментар Колий во Цена Стоим ость ПО: Работы: Описани е Комментар Стоим ий ость Блок Сетевое оборудование: Оборудование: Артик ул Описани е Комментар Колий во Цена Стоим ость Артик Описани Комментар Кол- Цена Стоим ПО: ул е ий во ость Блок Программное обеспечение: ПО: Артик ул Microsoft Kaspersky Описани е Комментар Колий во Цена Стоим ость Приложение 2 к Сообщению о заинтересованности Единый инфраструктурный проект ГК «Ростех». ТЕХНИЧЕСКОЕ ЗАДАНИЕ СОГЛАСОВАНО СОГЛАСОВАНО ____________________ ____________________ м.п. м.п. «_____»_____________ 2014 г. «_____»_____________ 2014 г. ____________________ «_____»_____________ 2014 г. Единый инфраструктурный проект ГК «Ростех». Техническое задание СОДЕРЖАНИЕ ТЕХНИЧЕСКОЕ ЗАДАНИЕ .............................................................................................................................. 1 1 Общие сведения .................................................................................................. 8 2 Назначение и цели работы ................................................................................ 8 3 Характеристика объекта автоматизации ........................................................ 8 4 Требования к подсистемам ............................................................................... 9 4.1 Требования к инфраструктуре виртуальных рабочих столов ............................................................... 9 4.1.1 Назначение инфраструктуры виртуальных рабочих столов (VDI) ......................................................... 9 4.1.2 Общие требования к VDI ......................................................................................................................... 10 4.1.3 Требования к структуре и функционированию VDI .............................................................................. 10 4.1.4 Требования к возможности развития и модернизации инфраструктуры VDI .................................... 11 4.1.5 Требования к сетевой инфраструктуре .................................................................................................. 12 4.1.6 Показатели вычислительной мощности применительно к создаваемым виртуальным машинам 12 4.1.7 Требования к доступности системы, а также требования к гарантийному обслуживанию серверного оборудования .............................................................................................................................................. 13 4.1.8 Требование к производительности системы под полной нагрузкой .................................................. 13 4.1.9 Требования к использованию ресурсов СХД серверами ..................................................................... 14 4.1.10 Настройка создаваемых образов виртуальных ПК ............................................................................... 14 4.1.11 Состав работ по созданию инфраструктуры VDI ................................................................................... 14 4.2 Система объединённых коммуникаций .............................................................................................. 15 4.2.1 Назначение и цели создания системы ................................................................................................... 15 4.2.2 Общие требования к Системе................................................................................................................. 15 4.2.3 Требования к структуре и функционированию Системы ..................................................................... 16 4.2.4 Требования к совместимости по взаимодействию с другими компонентами информационной инфраструктуры ............................................................................................................................................................... 16 4.2.5 Требования к надежности....................................................................................................................... 16 4.2.6 Требования к информационной безопасности ..................................................................................... 17 4.2.7 Требования к функциям (задачам), выполняемым Системой............................................................. 17 4.2.8 Требования к программному обеспечению .......................................................................................... 17 4.2.9 Требования к интеграции с имеющимися средствами ВКС ................................................................. 18 4.3 Система резервного копирования ........................................................................................................ 19 4.3.1 Назначение системы ............................................................................................................................... 19 4.3.2 Требования к аппаратным и программным средствам системы ........................................................ 19 4.3.2.1 Требования к дисковой системе хранения резервных копий ...................................................... 19 9 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.3.2.2 данных Требования к программному обеспечению резервного копирования и восстановления 20 4.3.3 Требования к работам по созданию системы ....................................................................................... 21 4.3.4 Требования к исполнителю .................................................................................................................... 21 4.3.5 Требования к документированию ......................................................................................................... 21 4.4 Инфраструктура беспроводного доступа ............................................................................................. 23 4.4.1 Назначение БЛВС ..................................................................................................................................... 23 4.4.2 Требования к БЛВС в целом .................................................................................................................... 23 4.4.3 Требования к функционалу БЛВС ........................................................................................................... 23 4.4.4 Требования к архитектуре и структуре БЛВС ........................................................................................ 24 4.4.5 Требования к точкам доступа Wi-Fi ........................................................................................................ 24 4.4.6 Требования к клиентскому оборудованию ........................................................................................... 25 4.4.7 Состав и содержание работ по внедрению БЛВС ................................................................................. 25 4.5 Система управления мобильными устройствами сотрудников (MDM) ............................................. 27 4.5.1 Назначение Системы ............................................................................................................................... 27 4.5.2 Цели создания Системы .......................................................................................................................... 27 4.5.3 Требования к системе ............................................................................................................................. 27 4.6 4.5.3.1 Общее требования к Системе ......................................................................................................... 27 4.5.3.2 Требования к структуре и функционированию Системы ............................................................. 28 4.5.3.3 Способы и средства связи для информационного обмена между компонентами системы .... 28 4.5.3.4 Требования к режимам функционирования ................................................................................. 28 4.5.3.5 Требования к информационной безопасности ............................................................................. 28 4.5.3.6 Требования к функциям, выполняемой системой ........................................................................ 30 Комплексная среда контроля ИТ .......................................................................................................... 31 4.6.1 Предпосылки для создания среды контроля ИТ................................................................................... 31 4.6.2 Перспективная архитектура среды контроля ИТ .................................................................................. 31 4.6.3 Цели и задачи создания системы мониторинга ................................................................................... 33 4.6.3.1 Цели системы мониторинга ............................................................................................................ 33 4.6.3.2 Задачи системы мониторинга ......................................................................................................... 33 4.6.4 Требования к Системе мониторинга ...................................................................................................... 35 4.6.4.1 Требования к структуре СМ ............................................................................................................. 36 4.6.4.2 Общие требования ........................................................................................................................... 37 4.6.4.3 Требования к подсистеме мониторинга глобальных и локальных сетей ................................... 38 4.6.4.3.1 Цели внедрения подсистемы ПМГЛС ..................................................................................... 38 4.6.4.3.2 Задачи подсистемы ПМГЛС ..................................................................................................... 38 4.6.4.3.3 Требования к мероприятиям по запуску в работу ................................................................ 39 4.6.4.3.4 Требования к подсистеме ПМГЛС ........................................................................................... 40 4.6.4.4 Требования к подсистеме сбора сообщений ................................................................................ 41 4.6.4.4.1 Цели внедрения подсистемы ПСС .......................................................................................... 41 10 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.6.4.4.2 Задачи подсистемы .................................................................................................................. 41 4.6.4.4.3 Требования к мероприятиям по запуску в работу ................................................................ 42 4.6.4.4.4 Требования к подсистеме ПСС ................................................................................................ 42 4.6.4.4.5 Требования к используемому ПО ........................................................................................... 43 4.6.4.5 Подсистема создания отчетов ........................................................................................................ 43 4.6.4.5.1 Цели внедрения подсистемы .................................................................................................. 43 4.6.4.5.2 Задачи подсистемы ПСО .......................................................................................................... 43 4.6.4.5.3 Требования к мероприятиям по запуску в работу ................................................................ 44 4.6.4.5.4 Требования к подсистеме ........................................................................................................ 45 4.6.4.5.5 Требования к используемому ПО ........................................................................................... 45 4.6.4.6 Подсистема функционального мониторинга................................................................................. 45 4.6.4.6.1 Цели внедрения подсистемы .................................................................................................. 45 4.6.4.6.2 Задачи подсистемы .................................................................................................................. 45 4.6.4.6.3 Требования к мероприятиям по запуску в работу ................................................................ 46 4.6.4.6.4 Требования к подсистеме ........................................................................................................ 47 4.6.4.6.5 Требования к используемому ПО ........................................................................................... 50 4.6.4.7 Подсистема агентов мониторинга .................................................................................................. 52 4.6.4.7.1 Цели внедрения подсистемы .................................................................................................. 52 4.6.4.7.2 Задачи подсистемы .................................................................................................................. 52 4.6.4.7.3 Требования к мероприятиям по запуску в работу ................................................................ 52 4.6.4.7.4 Требования к подсистеме ........................................................................................................ 53 4.6.4.7.5 Требования к используемому ПО ........................................................................................... 54 4.6.4.8 Подсистема моделирования объектов ИТ-инфраструктуры ........................................................ 55 4.6.4.8.1 Цели внедрения подсистемы .................................................................................................. 55 4.6.4.8.2 Задачи подсистемы .................................................................................................................. 55 4.6.4.8.3 Требования к мероприятиям по запуску в работу ................................................................ 56 4.6.4.8.4 Требования к подсистеме ........................................................................................................ 56 4.6.4.8.5 Требования к используемому ПО ........................................................................................... 58 4.6.4.9 Требования к документации СМ .................................................................................................... 58 4.6.4.10 Требования к оборудованию и ПО ................................................................................................. 59 4.6.4.11 Критерии оценки результатов проекта внедрения СМ ................................................................ 60 4.7 Комплексная система антивирусной защиты (КСАЗ) ........................................................................... 60 4.7.1 Предпосылки для создания КСАЗ ........................................................................................................... 60 4.7.2 Назначение КСАЗ ..................................................................................................................................... 60 4.7.3 Общие требования для КСАЗ .................................................................................................................. 60 4.7.4 Описание состава КСАЗ ........................................................................................................................... 63 4.7.5 Описание компонентов КСАЗ ................................................................................................................. 63 4.7.6 Требования к среде развертывания КСАЗ ............................................................................................. 64 4.7.6.1 Программные требования .............................................................................................................. 64 11 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.7.6.1.1.1 Гипервизор: ..................................................................................................................... 64 4.7.6.1.1.2 Требования к гостевой операционной системе гипервизора: ............................ 64 4.7.6.2 Аппаратные требования .................................................................................................................. 64 4.7.6.2.1.1 Требования к минимальному аппаратному обеспечению виртуальной к минимальному аппаратному обеспечению защищаемой машины защиты: 64 4.7.6.2.1.2 Требования виртуальной машины: ................................................................................................................................... 64 4.8 Комплексная система защиты информации ........................................................................................ 65 4.8.1 Требования к системе ............................................................................................................................. 65 4.8.1.1 Общие требования ........................................................................................................................... 65 4.8.2 Требования по идентификации и аутентификации субъектов доступа и объектов доступа ............ 66 4.8.3 Требования по управлению доступом субъектов доступа к объектам доступа ................................. 66 4.8.4 Требования по защите машинных носителей информации ................................................................ 67 4.8.5 Требования по регистрации событий безопасности ............................................................................ 67 4.8.6 Требования по антивирусной защите .................................................................................................... 67 4.8.7 Требования по обнаружению вторжений ............................................................................................. 68 4.8.8 Требования по контролю (анализу) защищенности ............................................................................. 68 4.8.9 Требования по обеспечению целостности ............................................................................................ 68 4.8.10 Требования по защите среды виртуализации ....................................................................................... 68 4.8.11 Требования по защите технических средств ......................................................................................... 69 4.8.12 Требования по защите передачи данных .............................................................................................. 69 4.8.13 Требования к численности и квалификации персонала системы и режиму его работы .................. 70 4.8.14 Показатели назначения ........................................................................................................................... 70 4.8.15 Требования к надежности....................................................................................................................... 70 4.8.16 Требования безопасности ....................................................................................................................... 71 4.8.17 Требования к эргономике и технической эстетике .............................................................................. 71 4.8.18 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы 71 4.8.19 Требования по сохранности информации при авариях ....................................................................... 72 4.8.20 Требования к защите от влияния внешних воздействий ..................................................................... 72 4.8.21 Требования к патентной чистоте ............................................................................................................ 72 4.8.22 Требования по стандартизации и унификации ..................................................................................... 73 4.8.23 Требования к видам обеспечения ......................................................................................................... 73 4.8.23.1 Требования к программному обеспечению .................................................................................. 73 4.8.23.2 Требования к техническому обеспечению .................................................................................... 73 4.8.24 Функциональные требования ................................................................................................................. 74 4.8.24.1 Требования к подсистеме защиты от НСД ..................................................................................... 74 4.8.24.2 Требования к подсистеме защиты среды виртуализации ............................................................ 75 4.8.24.3 Требования к подсистеме антивирусной защиты ......................................................................... 75 12 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.8.24.4 Требования к подсистеме криптографической защиты информации......................................... 76 4.8.24.5 Требования к подсистеме межсетевого экранирования .............................................................. 76 4.8.24.6 Требования к подсистеме обнаружения вторжений .................................................................... 77 4.8.24.7 Требования к подсистеме анализа защищенности ....................................................................... 77 4.8.25 Источники разработки............................................................................................................................. 78 5 6 Порядок контроля и приёмки работ............................................................... 79 5.1 Виды испытаний .................................................................................................................................... 79 5.2 Предварительные испытания ............................................................................................................... 79 5.3 Проведение опытной эксплуатации ..................................................................................................... 79 5.4 Приёмочные испытания........................................................................................................................ 80 Требования к составу и содержанию работ по подготовке объекта информатизации к вводу в действие развёртываемых подсистем .............. 80 7 Требования к документированию .................................................................. 81 8 Список сокращений .......................................................................................... 84 8 Спецификации оборудования и ПО ............................................................... 85 13 Единый инфраструктурный проект ГК «Ростех». Техническое задание 1 Общие сведения Полное наименование проекта: Единый инфраструктурный проект – проект 360. Предметом технического задания являются работы по проектированию, монтажу и пусконаладке решений, входящих в проект. Заказчик: ГК «Ростех». 2 Назначение и цели работы Основной целью проведения работ по проекту является развёртывание инфраструктурных сервисов в головной компании ГК «Ростех», в том числе: Инфраструктуры виртуальных рабочих столов (VDI); Системы объединённых коммуникаций; Системы резервного копирования; Инфраструктуры беспроводного доступа; Системы управления мобильными устройствами сотрудников (MDM) для обеспечения доступа к корпоративным приложениям; Комплексная среда контроля ИТ. 3 Характеристика объекта автоматизации ИТ-инфраструктура Центрального аппарата (ЦА) ГК «Ростех» предназначена для обеспечения работы прикладных программных систем и включает следующие составляющие: • сетевую инфраструктуру; • вычислительную инфраструктуру; • инфраструктуру хранения данных. Сетевая инфраструктура охватывает две территориально обособленных технологических площадки по адресам: г. Москва, Гоголевский бул., 21 и г. Москва, ул. Усачева, 24. В качестве опорного сетевого оборудования используются различные модели фирмы Alcatel. Также используются сети беспроводного доступа Wi-Fi, сервисы IP-телефонии на платформе Avaya, средства ВКС Tandberg, Polycom. Вычислительная инфраструктура ЦА Госкорпорации образована серверами (порядка 250 единиц), располагающихся как на выделенных, так и на виртуальных 14 Единый инфраструктурный проект ГК «Ростех». Техническое задание ресурсах. В качестве платформы виртуализации используются гипервизоры VMWare ESX. Оценочно серверный парк ЦА Компании составляет: • 80 физических серверов; • 60 гипервизоров VMWare ESX; • 250 серверов под управлением ОС Windows 2008 (из, которых около 230 виртуальных) Инфраструктура хранения данных включает 6 массивов хранения данных. Представленная инфраструктура обеспечивает функционирование 15 основных пользовательских приложений и автоматизированных систем (далее АС), а также инфраструктурных сервисов, реализующих общесистемные функции. В ближайшее время планируется расширенное использование технологии VDI и тонких клиентов для обеспечения функционирования рабочих мест пользователей. В качестве инфраструктурных сервисов в основном используются программные продукты компании Microsoft. Примерное число пользователей (и соответственно рабочих мест) ЦА составляет 700 человек. Штат ИТ персонала, обеспечивающего предоставления услуг ИТ составляет около 10 человек. Допускается расширение штатного состава службы ИТ для обеспечения эксплуатации средств контроля ИТ. Текущее количество автоматизированных рабочих мест составляет 700. На рабочих местах используется ОС MS Windows 7, 8 и ПО MS Office 2003/2007/2010/2013 Pro, Internet Explorer, Adobe Flash, Adobe Reader, Консультант +. 4 Требования к подсистемам 4.1 Требования к инфраструктуре виртуальных рабочих столов 4.1.1 Назначение инфраструктуры виртуальных рабочих столов (VDI) Инфраструктура виртуальных рабочих столов пользователей (VDI) предназначена для консолидации унификации вычислительных аппаратно-программной мощностей среды и в центре обеспечения обработки данных, централизованного обслуживания рабочих станций. Целями создания инфраструктуры виртуальных рабочих столов для ГК «Ростех» являются: Упрощение развертывания и администрирования пользовательских рабочих мест за счет их стандартизации. Повышение отказоустойчивости и безопасности; 15 Единый инфраструктурный проект ГК «Ростех». Техническое задание Обеспечение высокой доступности данных посредством переноса всех пользовательских данных в ЦОД. Описанные в ТЗ требования должны использоваться в качестве основы при проектировании и создании VDI для ГК «Ростех». 4.1.2 Общие требования к VDI Решение должно быть спроектировано исходя из того, что пользователи будут работать со следующими приложениями: MS Office 2013 Pro, Adobe Flash, Adobe Reader, Консультант+. Для обеспечения оптимальной производительности общая загрузка ВМ, с которыми работают пользователи, не должна превышать 70 %. Инфраструктура виртуальных ПК должна быть построена на базе решения Horizon View 6.0 от ведущего мирового лидера в области виртуализации VMware. Создаваемая система должна обеспечивать запуск и работу ВМ, запуск приложений внутри ВМ, коммуникацию с сетью Заказчика. Аппаратное обеспечение инфраструктуры VDI должно быть модульным, а также должно обеспечивать высокую эффективность работы (критерии в пункте 4.7) с ОС Windows 7/8 x32/64 и следующими приложениями: MS Office 2013 Pro, Internet Explorer, Adobe Flash, Adobe Reader, Консультант+. 4.1.3 Требования к структуре и функционированию VDI Для функционирования системы VDI необходимы следующие подсистемы: Подсистема VDI Смежные подсистемы Подсистема VDI должна включать следующие компоненты: Сервер управления виртуальной инфраструктурой VMware vCenter Server подсистема виртуализации аппаратного обеспечения, обеспечивающая функционирование инфраструктурных серверных служб в среде виртуальных серверов и управление, мониторинг параметров подсистемы виртуализации, на базе vSphere 5.5. Сервер подключения пользователей View Connection Server – обеспечивает управление и обеспечение безопасности виртуальных настольных компьютеров с помощью единой консоли администратора и удаление данных с конечных устройств. 16 Единый инфраструктурный проект ГК «Ростех». Техническое задание Сервер VMware View Composer - подсистема экономия дискового пространства и упрощение обслуживания виртуальных ПК пользователей с однотипными задачами. View Security Server - сервер обеспечивающий безопасность подключения пользователей к виртуальным рабочим столам. Сервер Persona Management – отвечающий за предоставление пользователям их профилей в плавающем пуле (floating pool). Для реализации системы VDI в инфраструктуре Заказчика должны иметься следующие смежные подсистемы: Компоненты, обеспечивающие реализацию удаленного подключения к ВМ, такие как сервера, СХД, коммутаторы. Подсистема службы каталога (доменный каталог), обеспечивающая единое хранилище аутентификационных данных пользователей, а также сведений о других объектах сети. Подсистема преобразования имен (служба DNS), обеспечивающая вспомогательные функции по разрешению имен в IP-адреса, интегрируется с доменным каталогом. Подсистема динамической конфигурации хостов и присвоения сетевых адресов (служба DHCP), предназначенная для стандартизированной автоматической конфигурации узлов сети. В сети должна быть подсистема активации ключей Windows (сервер активации ключей Microsoft Windows KMS) настроенная на использование с лицензиями MS Windows Vista/7/8. Т.к. программным ограничением ПО виртуализации является невозможность использования активации ВМ. Ответственность за предоставление перечисленных смежных подсистем и доступа к ним на этапе реализации отвечает Заказчик. 4.1.4 Требования к возможности развития и модернизации инфраструктуры VDI Инфраструктура VDI должна иметь возможность адаптации к меняющимся условиям эксплуатации, т.е. изменяющегося числа пользователей и количества серверов. Инфраструктура VDI должна допускать поэтапную модернизацию отдельных узлов. 17 Единый инфраструктурный проект ГК «Ростех». Техническое задание При построении инфраструктуры VDI должен использоваться принцип унификации оборудования, т. е. VDI должна содержать минимально возможное число наименований компонентов. Проектируемая инфраструктура VDI должна иметь возможность последующего развития, а также перехода на новые виды оборудования. 4.1.5 Требования к сетевой инфраструктуре Ниже перечислены требования к инфраструктуре ЛВС и SAN, которая должна быть обеспечена Заказчиком: Серверы должны подключаться к ЛВС на скоростях не ниже 1000 Мбит/с. Подключение серверов к системам хранения данных должно осуществляться на скорости не менее 8 Гбит/с. Подключение серверов к системе резервного копирования должно осуществляться на скорости не менее 6 Гбит/с. Подключение рабочих мест пользователей должно осуществляться на скорости не менее 10 Мбит/с. 4.1.6 Показатели вычислительной мощности применительно к создаваемым виртуальным машинам Суммарное количество виртуальных машин, расположенных на одном физическом сервере, должно быть не более 100. Выделяемые ресурсы должны быть настроены таким образом, чтобы на каждое ядро процессора приходилось не более 8 виртуальных машин, не менее 2 Гб оперативной памяти с возможностью увеличения до 4 Гб, не менее 40 Гб пространства на СХД, не менее 1 сетевого адаптера со скоростью 100/1000 Мбит/с. Расчеты по соответствовать количеству виртуальных рекомендациям машин производителя и ПО, их при параметрам этом должны должны быть соотнесены с типом и характером генерируемой пользователями системы нагрузки. Рекомендуемые (расчетные) параметры производителя: от 5 до 8 пользователей на одно физическое ядро сервера; от 2 Гб физической памяти сервера на одного пользователя; 20 IOPS на одного среднестатистического пользователя; 18 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.1.7 Требования к доступности системы, а также требования к гарантийному обслуживанию серверного оборудования Выбор модели организации пула с учётом обеспечения доступности и отказоустойчивости должен быть осуществлён Исполнителем на этапе разработки технорабочего проекта. Для построения системы должны использоваться компоненты, специально предназначенные для работы в условиях продолжительной бесперебойной работы. При проектировании системы должны быть предусмотрены механизмы отказоустойчивости и продолжения работы в случае выхода из строя одного или нескольких серверов подключения пользователей. Гарантийные обязательства на оборудование устанавливаются производителем оборудования и не должны быть менее чем 1 календарный год с даты продажи. 4.1.8 Требование к производительности системы под полной нагрузкой Объем используемых ресурсов создаваемой системы должен составлять не более 80 % при условии загрузки всех ВМ (700 шт.) на всех серверах-лезвиях, предназначенных для виртуализации рабочих столов, в каждой ВМ должен быть запущен набор приложений, перечисленных в п. 4.1. Исполнитель должен гарантировать следующие показатели работоспособности созданной системы: Открытие документа Word, Excel или Outlook из папки «Мои документы» в течение не более 8 секунд в первый раз и в течение не более чем 3 секунд в последующие разы (после кэширования данных). Документ должен содержать не более 5 страниц текста и не должен содержать вложенных объектов, макросов, итеративных вычислений, графических объектов и ссылок на другие документы. Документ должен быть создан с помощью шаблона по умолчанию, поставляемого с вышеописанными продуктами. Запуск приложений Opera, Internet Explorer с пустой домашней страницей в течение не более 5 секунд (только с надстройками, установленными по умолчанию в момент инсталляции системы). Воспроизведение потокового аудио с битрейтом не выше 96 Кбит/с без прерываний и задержек в течение не менее 1–2 минут. Время отклика ВМ, отображаемой на ТК, — менее 5 сек. 19 Единый инфраструктурный проект ГК «Ростех». Техническое задание Система обеспечивает загрузку тонкого/нулевого клиента и подключение к ВМ до момента отображения окна авторизации не более чем за 1 (одну) минуту. Указанные показатели гарантируются при соблюдении следующих условий: в момент открытия документа, запуска приложения дисковая активность ОС виртуального рабочего стола не должна превышать 5 % (по показаниям системных счетчиков ОС виртуального рабочего стола); в момент открытия документа, запуска приложения не должно быть запущено других приложений; от момента старта виртуальной машины (отображение виртуального рабочего стола) до момента открытия рабочего документа или запуска приложения должно пройти как минимум 30 секунд для обеспечения завершения фоновой активности ОС после старта. 4.1.9 Требования к использованию ресурсов СХД серверами Суммарное количество операций ввода-вывода только для инфраструктуры виртуальных ПК не должно быть менее 17 500 операций ввода-вывода в секунду или выше. Высокая доступность ВМ с которыми будут работать пользователи, должна быть обеспечена следующим образом: в случае выхода из строя сервера, пользователи, которые работали с ВМ, загруженными на этот сервер, должны пере подключиться к серверу соединений. Сервер соединений определит наиболее доступный и наиболее свободный узел, на который будет загружен образ, к которому прикреплен данный пользователь. 4.1.10 Настройка создаваемых образов виртуальных ПК В ходе создания «золотых» образов необходимо произвести тонкую настройку виртуальных ПК. Настройка должна включать оптимизацию ОС виртуальных ПК согласно рекомендациям производителя ПО, а также требованиям, которые предъявил Заказчик. Настройка ВМ должна облегчать доступ, обеспечивать более быструю загрузку за счет удаления неиспользуемых компонентов, обеспечивать интеграцию со средствами управления фермой виртуализации рабочих столов. 4.1.11 Состав работ по созданию инфраструктуры VDI Работы по созданию инфраструктуры VDI должны включать следующие этапы: Обследование и уточнение требований к инфраструктуре VDI. Разработка технорабочей документации. Согласование потребности в инфраструктурных ресурсах (серверы, ЛВС, SAN, СХД) для проектируемой системы VDI. 20 Единый инфраструктурный проект ГК «Ростех». Техническое задание Развёртывание инфраструктуры СХД. Приемосдаточные испытания. 21 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.2 Система объединённых коммуникаций 4.2.1 Назначение и цели создания системы Система объединённых коммуникаций (СОК) предназначена для предоставления следующих сервисов и инструментов коммуникаций: Обмена мгновенными сообщениями и информацией о присутствии; Голосовых вызовов с помощью клиентского ПО Аудио, видео, веб конференций Средств совместной работы с информацией Основной целью создания системы объединенных коммуникаций является обеспечение сотрудников вне зависимости от их физического местоположения возможностями обмена информацией и средствами коллективной работы. 4.2.2 Общие требования к Системе К системе предъявляются следующие общие требования: масштабируемость – способность к выполнению задачи при увеличении количества источников информации путем увеличения количества комплексов, а также наращивания возможностей существующих подсистем и модулей; безопасность и надежность – система должна обеспечивать необходимый уровень доступности и надежности, безопасность ее функционирования, надежную защиту информации и преднамеренного приложений от разрушения и ошибок, потери несанкционированного информации, контроль доступа, авторства информации и ее изменений, восстановление информации при авариях и катастрофах; адаптивность – способность выполнять свои функции при меняющихся условиях эксплуатации; унификация – использование типовых проектных и конструктивных решений, обеспечение возможности многократного использования проектных решений, обеспечивающих простоту наращивания и взаимодействия, а также взаимозаменяемость на уровнях блоков, устройств, модулей и программноалгоритмического обеспечения; система должна предусматривать возможность внедрения новых информационных систем, обеспечивать поддержку новых пользователей и данных; 22 организационных подразделений, Единый инфраструктурный проект ГК «Ростех». Техническое задание компоненты информационной системы должны предусматривать модернизацию путем обновления версий применяемого программного обеспечения в случае, если такая модернизация предусматривается его разработчиком. 4.2.3 Требования к структуре и функционированию Системы Структура Системы должна быть построена по иерархическому принципу, обеспечивая централизованное управление информационными ресурсами Заказчика с возможностью делегирования административным полномочий ответственным сотрудникам структурных подразделений. Должна быть предусмотрена возможность модификации системы, как путем изменения состава структурных подразделений, так и добавлением новых сервисов. Система не должна предусматривать принципиальных ограничений на число одновременно работающих пользователей. Количество одновременно работающих пользователей системы может быть ограничено техническими характеристиками используемых аппаратных средств и сетевого оборудования. Должны быть предусмотрены следующие режимы функционирования Системы: штатный режим производственной эксплуатации – режим предоставления сервисов в соответствии с приведенными в ТЗ требованиями; режим технического обслуживания, архивации и модернизации системы – режим произведения работ по модернизации, техническому обслуживанию, резервному копированию данных; режим аварийного обслуживания – режим произведения работ по устранению неполадок функционирования компонентов информационной инфраструктуры. 4.2.4 Требования к совместимости по взаимодействию с другими компонентами информационной инфраструктуры Компоненты информационной инфраструктуры должны функционировать в условиях существующих ограничений качества и надежности каналов связи и не предъявлять к ним дополнительных требований, реализация которых может потребовать их модернизации. В качестве основного сетевого протокола должен использоваться протокол TCP/IP. 4.2.5 Требования к надежности Технические средства и программное обеспечение Системы должны быть построены с использованием технологий обеспечения высокой доступности. 23 Единый инфраструктурный проект ГК «Ростех». Техническое задание Высокая доступность и отказоустойчивость Системы должна обеспечиваться дублированием компонентов с применением технологий виртуализации и кластерных решений СУБД для хранения данных 4.2.6 Требования к информационной безопасности Подсистема информационной безопасности в рамках функционирования Системы должна соответствовать следующим требованиям: шифрование паролей передаваемых по сети; обеспечение однократной аутентификации при доступе пользователей к компонентам Системы авторизация пользователей должна осуществляться на основе назначенных пользователю ролей в Системе. на серверы Системы должно быть установлено антивирусное ПО используемое заказчиком. 4.2.7 Требования к функциям (задачам), выполняемым Системой Разрабатываемая Система должна удовлетворять следующим требованиям: Обеспечивать возможности взаимодействия пользователей в том числе: Обмен мгновенными сообщениями с информацией о доступности пользователя в сети; Осуществление звонков внутри сети при помощи клиентского программного обеспечения Lync; Организация корпоративных конференций посредством программного обеспечения Lync; Совместное использование Рабочих областей в корпоративных конференциях. Предоставлять следующие возможности подключения пользователей: Осуществлять подключение клиентов в пределах локальной сети; Осуществлять подключение клиентов из-за пределов локальной сети; Использовать «тонких/нулевых», «толстых» и мобильных клиентов; Интегрироваться со инфраструктурными сервисами и службами в том числе Active Directory и Exchange Server. 4.2.8 Требования к программному обеспечению В качестве операционной системы для инфраструктурных серверных служб необходимо использовать операционную систему Microsoft Windows Server 2012 R2 в соответствующей редакции, языковая версия – английская. 24 Единый инфраструктурный проект ГК «Ростех». Техническое задание В качестве программного обеспечения подсистемы объединённых коммуникаций необходимо использовать Microsoft Lync Server 2013. 4.2.9 Требования к интеграции с имеющимися средствами ВКС Система объединённых коммуникаций должна интегрироваться с имеющими у Заказчика средствами ВКС Tandberg, Polycom. Исполнитель должен обеспечить необходимую настройку вновь устанавливаемой системы объединённых коммуникаций и существующего оборудования для обеспечения интероперабельности между ними. Информация по составу и техническим характеристикам имеющегося оборудования будет предоставлена Заказчиком после заключения Контракта на выполнение работ. 25 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.3 Система резервного копирования 4.3.1 Назначение системы Система резервного копирования предназначена для создания в автоматическом и ручном режиме резервных копий, данных ИТ-систем Заказчика, а также, при необходимости, для восстановления данных из сохранённых копий. Целью внедрения системы является повышение надёжности функционирования информационных систем Заказчика, а также сокращение времени их восстановления в случае отказов. 4.3.2 Требования к аппаратным и программным средствам системы Аппаратные и программные средства, на основе которых строится система, предоставляются Заказчиком. Ниже перечислены технические требования к ним. 4.3.2.1 Требования к дисковой системе хранения резервных копий Для хранения резервных копий должна использоваться дисковая система хранения данных. Дисковая система хранения резервных копий должна удовлетворять следующим требованиям: Обладать модульной конструкцией и предоставлять возможность встраивания в стандартные 19” шкафы и стойки. Поддерживать расширение дисковой емкости до максимально возможной путем добавления дисковых полок без использования промежуточных коммутаторов. Обеспечивать дедупликацию данных на уровне блоков переменной длины без буферизации недедуплицированных данных на диске. Используемая технология дедупликации должна обеспечивать глобальное исключение дублирующихся блоков и их запись в единый пул хранения, независимо от используемых протоколов, типов и количества виртуальных устройств, типа сохраняемых данных. Используемая технология дедупликации должна поддерживать расширение функциональности путем переноса части нагрузки на серверы системы резервного копирования с использованием протоколов, совместимых с Symantec OST/Avamar, при докупке дополнительных лицензий. Поддерживать механизм квотирования, ограничивающий логический объем резервных копий. Обеспечивать защиту данных на основе RAID-6/RAID-10. Поддерживать диски «горячей замены», используемые для всей системы хранения данных, а не только для определенных групп дисков. Поддерживать технологию «мгновенных снимков» состояния файловой системы. 26 Единый инфраструктурный проект ГК «Ростех». Техническое задание Обладать развитым функционалом сквозного обеспечения целостности данных, в том числе обеспечивать проверку корректности записанных в файловую систему пользовательских данных в режиме реального времени и при необходимости их немедленную перезапись из энергонезависимой памяти. Обеспечивать постоянную фоновую проверку целостности пользовательских данных, хранящихся на файловой системе, с тем, чтобы каждый блок данных был проверен не реже одного раза в месяц. Предоставлять возможность подключения к сети Ethernet по не менее чем шести портам 10 Гбит/c. Предоставлять возможность одновременного подключения по файловым (CIFS, NFS) и специализированным протоколам (совместимым с Symantec OST/Avamar) по сети Ethernet. Предоставлять возможность подключения по сети FC по специализированным протоколам (совместимым с Symantec OST/Avamar) и в режиме эмуляции VTL по не менее чем восьми портам FC 8 Гбит/c. Обеспечивать начальную полезную емкость не менее 36 ТБ и предоставлять возможность расширения полезной емкости не менее, чем до 133 ТБ. ПО управления системой должно работать на контроллере системы хранения, без необходимости выделения под эту задачу дополнительного сервера. ПО управления системой должно поддерживать как графический интерфейс через стандартный WEB-браузер, так и интерфейс командной строки с доступом по протоколу SSH. Должна обеспечиваться поддержка командных файлов («скриптов»). Иметь гарантийную поддержку производителя в течение 3 лет. 4.3.2.2 Требования к программному обеспечению резервного копирования и восстановления данных Программное обеспечение резервного копирования должно удовлетворять следующим требованиям: ПО и дисковая система хранения из п.1 должны быть от одного производителя. Поддерживать прозрачную интеграции с системой хранения резервных копий, которая описана в п.1. Иметь настраиваемый графический веб-интерфейс пользователя со встроенным средством создания отчётов. Поддержка единого входа с использованием LDAP и Active Directory. 27 Единый инфраструктурный проект ГК «Ростех». Техническое задание Иметь в комплекте лицензии на поддержку не менее 36 ТБ пространства. Поддерживать возможность резервного копирования на диски и ленты, а также иметь поддержку технологии снэпшотов. Иметь поддержку от производителя в течение 3 лет. 4.3.3 Требования к работам по созданию системы Исполнитель должен произвести комплекс работ по созданию системы резервного копирования (СРК) «под ключ». В состав работ должны входить: Обследование существующих систем, данные которых должны обслуживаться СРК; Проектирование решения СРК; Монтаж и пусконаладка аппаратных средств; Установка программного обеспечения, включая серверную часть и программные агенты (клиенты) на целевых серверах; Настройка объектов резервного копирования, пулов данных, расписания сеансов резервного копирования и прочих атрибутов системы; Разработка эксплуатационной документации, включающей регламент резервного копирования; Проведение испытаний системы. 4.3.4 Требования к исполнителю Исполнитель должен быть авторизован компаниями производителями оборудования и программного обеспечения на участие в данном конкурсе в письменном виде. Исполнитель должен иметь опыт не менее 3 лет поставки, монтажа, пуско-наладки и поддержки аналогичных систем (подтверждается актами выполненных работ или отзывами) Исполнитель должен обладать системой менеджмента качества сертифицированной в соответствии с ГОСТ Р ИСО 9001-2011 в части услуг по проектированию, разработке, внедрению аппаратного обеспечения, информационных систем и сетей передачи данных. 4.3.5 Требования к документированию На стадии разработки технического проекта и рабочей документации должен быть выпущен комплект документов на систему резервного копирования в составе: 28 Единый инфраструктурный проект ГК «Ростех». Техническое задание Раздел СРК в «Пояснительной записке к техническому проекту» (П2); Раздел СРК в «Описании комплекса технических средств» (П9); «Схема структурная комплекса технических средств» (С1); «Регламент резервного копирования». 29 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.4 Инфраструктура беспроводного доступа 4.4.1 Назначение БЛВС Назначением и целью проектируемой БЛВС офисного комплекса ГК «Ростех» является предоставление доступа в сеть Интернет по беспроводной технологии Wi-Fi для гостей компании. Использование БЛВС для доступа к внутренним сервисам Заказчика не допускается. 4.4.2 При Требования к БЛВС в целом реализации IT проекта следует использовать преимущественно существующую сетевую инфраструктуру (Центры маршрутизации, активное сетевое оборудование, СКС), с учетом ее удовлетворения техническим требованиям. В случае недостатка ресурсов текущей инфраструктуры, исполнитель обязан сформулировать необходимые требования к модернизации на этапе написания рабочего проекта. Беспроводная локальная вычислительная сеть должна проектироваться с возможностью ее расширения в будущем, путем добавления новых сегментов, при условии «бесшовного» сопряжения с уже существующими сегментами, а также путем включения дополнительного оборудование, способность, оборудования, повышающих уровень и ее или модулей производственные качество сервисов, в существующее показатели надежность (пропускную (отказоустойчивость), информационную безопасность, технологичность обслуживания и т.п.). Все проектные решения, применяемые при построении БЛВС, должны соответствовать действующим нормам и правилам техники безопасности, пожаро- и взрывобезопасности, приведенным в следующих документах: «Рекомендации по планированию мероприятий по охране труда», утвержденные постановлением от 27.02.95 № 11 Министерства труда России (приложение к указанию Минсвязи России № 57у). «Положение о порядке обучения и проверке знаний по охране труда руководителей, специалистов и рабочих предприятий, учреждений и организаций связи» (Приказ Минсвязи России от 23.01.95 № 12). «О пожарной безопасности служебных помещений» (приказ Минсвязи России от 30.01.97 № 18). 4.4.3 Требования к функционалу БЛВС Решение должно поддерживать стандарт 802.11n и быть обратно совместимо со стандартами 802.11g, 802.11b и 802.11a. Решение должно поддерживать частотные диапазоны 2.4ГГц и 5ГГц. 30 Единый инфраструктурный проект ГК «Ростех». Техническое задание Решение должно поддерживать российские регуляторные требования к подобному оборудованию для всех используемых частотных диапазонов. Решение должно обеспечивать бесшовный роуминг в зоне покрытия БЛВС Решение должно иметь удобный интерфейс для генерации выдачи временных гостевых аккаунтов к сети, с возможностью распечатки их на принтере и выдачи вместе с пропуском на входе в здание. Решение должно иметь возможность переадресации пользователя при входе в систему на сайт компании или отдельный сайт гостевого портала. 4.4.4 Требования к архитектуре и структуре БЛВС Решение должно строиться на централизованной архитектуре, в которой точки доступа управляются контроллерами WLAN. Решение должно включать в себя точки доступа, контроллеры WLAN и АААсервер. Контроллеры WLAN должны работать в отказоустойчивом режиме. 4.4.5 Требования к точкам доступа Wi-Fi Точки Доступа Wi-Fi должны быть совместимы со стандартом 802.11n и поддерживать совместную работу со стандартами 802.11g, 11b, 11a. Точки Доступа Wi-Fi должны отвечать российским нормам и стандартам в обоих частотных диапазонах 2.4GHz и 5GHz. Точки Доступа Wi-Fi должны поддерживать для 802.11n частотные каналы шириной как 20MHz, так и 40MHz. Точки Доступа Wi-Fi должны поддерживать технологию MIMO (Multiple Input Multiple Output) для 802.11n, до уровня 3х3 в зависимости от модели. Точки Доступа Wi-Fi должны иметь необходимые сертификаты РФ, как соответствующее радиоэлектронное средство. Точки Доступа Wi-Fi должны поддерживать функционал интеллектуального контроля спектра на физическом уровне радио-среды, в своих частотных диапазонах или во всей доступной спектральной полосе, в зависимости от режима использования. Точки беспроводного доступа должны иметь возможность формирования нескольких беспроводных сетей с различными уровнями безопасности и различными SSID. Точки Доступа должны поддерживать следующие виды электропитания: Питание от источника переменного тока 220В, рассчитанного на электросети РФ. 31 Единый инфраструктурный проект ГК «Ростех». Техническое задание Питание по технологии IEEE 802.3af (Power-over-Ethernet – PoE). Требования к клиентскому оборудованию 4.4.6 IT решение должно предусматривать работу любых устройств, поддерживающих работу с Wi-Fi сетями, соответствующих стандартам IEEE 802.11a/g/n (смартфоны, планшетные компьютеры и т.п.). Требования к сетевому оборудованию БЛВС: Система должна подключение быть которых построена к активному на базе точек сетевому беспроводного оборудованию АПК доступа, должно осуществляться проводным методом, с помощью медной СКС категории не ниже 5е. Точки беспроводного доступа должна поддерживать разделение на виртуальные локальные сети (VLAN). Конструктивные особенности точек доступа должны соответствовать внешним условиям среды, в которой предполагается их эксплуатировать (офисные помещения, складские помещения, улица). 4.4.7 Состав и содержание работ по внедрению БЛВС В рамках работ по реализации проекта, подрядной организацией должно быть выполнено предварительное радиообследование здания, по результатом которого подготовлен отчет о радиообследовании с наглядными зонами покрытия и уровнем сигнала в любой точке офиса, определено точное количество беспроводных точек и места их установки для выполнения требований технического задания. Должен быть выполнен рабочий проект и предоставлена вся необходимая документация. Все системы и процессы выполнения работ, должны соответствовать требованиям нормативных документов и законов РФ в объеме необходимом для получения необходимых разрешительных документов для выполнения работ. В случае нормативными возникновения документами, противоречивых надлежит требований между проконсультироваться с различными Заказчиком и производителем оборудования. Проектные, монтажные, пуско-наладочные и прочие работы должны выполняться в соответствии с требованиями, установленными для проведения данных видов работ. Все выявленные в процессе сдачи – приемке работ отклонения должны быть устранены Подрядчиком с внесением необходимых изменений в Исполнительную документацию. 32 Единый инфраструктурный проект ГК «Ростех». Техническое задание Проведено финальное радиообследование здания, по результатом которого подготовлен отчет о радиообследовании с наглядными зонами покрытия и уровнем сигнала в любой точке офиса, доказывающий что построенная сеть удовлетворяет условиям заданным в техническом задании. Ниже в таблице приведён перечень работ, которые должны быть выполнены Исполнителем. № п/п Наименование работ Разработка техпроекта 1.1 Схема структурная комплекса технических средств(С1) 1.2 Схема функциональной структуры(С2) 1.3 Ведомость покупных изделий(ВП) 1.4 Пояснительная записка к техническому проекту(П2) 1.5 Таблица соединений и подключений(С6) 1.6 Чертеж установки технических средств(СА) 1.7 Написание ПМИ 1.8 Согласование техпроекта 1.9 Согласование ПМИ Проведение радиообследования 2.1 Проведение предварительного радиообследования 12 этажей здания 2.2 Подготовка отчета по данным предварительного радиообследования 2.3 Проведение финального радиообследования 12 этажей здания 2.4 Подготовка отчета по данным финального радиообследования Работы по монтажу и подключению устройств 3.1 Монтаж и подключение беспроводных точек доступа 3.2 Монтаж и подключение контроллеров беспроводных точек доступа 3.3 Монтаж и подключение сервера AAA Работы по настройке коммутаторов 4.1 Настройка коммутаторов доступа 4.2 Настройка коммутаторов ядра сети Работы по настройке беспроводной сети 5.1 Настройка контроллеров беспроводных точек доступа 5.2 Настройка сервера AAA Запуск и отладка системы 6 Запуск и отладка системы 33 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.5 Система управления мобильными устройствами сотрудников (MDM) 4.5.1 Назначение Системы Система управления мобильными устройствами предназначена для: предоставления сотрудникам Заказчика доступа к корпоративным данным с мобильных устройств; организации управления мобильными устройствами сотрудников Заказчика, подключенными к корпоративной сети, в том числе: централизованного управления конфигурациями мобильных устройств с целью соответствия внутренним стандартам информационной безопасности; централизованной установки и обновления ПО на мобильные устройства; защиты корпоративных данных на мобильных устройствах в случае утери и кражи; контроля доступа к корпоративным ресурсам с мобильных устройств. 4.5.2 Цели создания Системы Основной целью создания системы управления мобильными устройствами является интеграция мобильных устройств сотрудников в корпоративную ИТинфраструктуру Заказчика. 4.5.3 Требования к системе 4.5.3.1 Общее требования к Системе К системе предъявляются следующие общие требования: Масштабируемость – способность к выполнению задачи при увеличении количества источников информации путем увеличения количества комплексов, а также наращивания возможностей существующих подсистем и модулей; Безопасность и надежность – система должна обеспечивать необходимый уровень доступности и надежности, безопасность ее функционирования, надежную защиту информации и преднамеренного приложений от разрушения и ошибок, потери несанкционированного информации, контроль доступа, авторства информации и ее изменений, восстановление информации при авариях и катастрофах; Адаптивность – способность выполнять свои функции при меняющихся условиях эксплуатации; Унификация – использование типовых проектных и конструктивных решений, обеспечение возможности многократного использования проектных решений, 34 Единый инфраструктурный проект ГК «Ростех». Техническое задание обеспечивающих простоту наращивания и взаимодействия, а также взаимозаменяемость на уровнях блоков, устройств, модулей и программноалгоритмического обеспечения; Компоненты информационной системы должны предусматривать модернизацию путем обновления версий применяемого программного обеспечения в случае, если такая модернизация предусматривается его разработчиком. 4.5.3.2 Требования к структуре и функционированию Системы Структура Системы должна быть разработана и построена c учетом следующих требований: Серверы, имеющие непосредственный доступ из сети Интернет, должны быть расположены в особом сегменте сети и ограничены в доступе к внутренней сети и сети интернет с помощью сетевых экранов; Должна быть предусмотрена возможность модификации системы, как путем изменения состава структурных компонентов, так и добавлением новых сервисов. 4.5.3.3 Способы и средства связи для информационного обмена между компонентами системы Компоненты системы должны быть связаны между собой вычислительной сетью. Компоненты системы должны функционировать в условиях существующих ограничений качества и надёжности каналов связи и не предъявлять к ним дополнительных требований, реализация которых может потребовать их модернизации. В качестве основного сетевого протокола должен использоваться протокол TCP/IP. 4.5.3.4 Требования к режимам функционирования Должны быть предусмотрены следующие режимы функционирования Системы: Штатный режим производственной эксплуатации – режим предоставления сервисов в соответствии с приведенными в ТЗ требованиями; Режим технического обслуживания, архивации и модернизации системы – режим произведения работ по модернизации, техническому обслуживанию, резервному копированию данных; Режим аварийного обслуживания – режим произведения работ по устранению неполадок функционирования компонентов информационной инфраструктуры. 4.5.3.5 Требования к информационной безопасности К системе предъявляются следующие требования к безопасности: 35 Единый инфраструктурный проект ГК «Ростех». Техническое задание Система должна иметь систему разграничения прав, как по действиям, так и по устройствам; Система должна позволять создавать администраторов на отдельные группы устройств, а также глобальных администраторов; Информационная безопасность должна быть обеспечена за счет использования встроенных механизмов защиты используемых операционных систем серверов, СУБД и прикладного программного обеспечения. Аутентификация и авторизация эксплуатирующего персонала в Системе должна осуществляться на основе уникального имени учетной записи в Службе Каталога (Active Directory); Для защиты информации от вредоносного кода должны использоваться только лицензионные средства защиты, рекомендованные службой информационной безопасности Заказчика; Параметры настройки средств защиты от вредоносного кода должны быть определены на этапе проектирования; Система должна взаимодействовать с сетью Интернет только по необходимым портам, которые должны быть определены на этапе проектирования. Система должна иметь возможность управления безопасностью устройств конечных пользователей включая такие функции как: Назначение политик безопасности пользователям, как группами, так и по отдельности. Создание групп пользователей, определяемых администратором или бизнес – задачами. Создание динамических групп пользователей, определяемых классификацией устройств или другими параметрами, получаемыми автоматически от устройства. Производить присваивание групповых или личных политик безопасности при добавлении устройства в группу. Сбор и передача логированных событий с устройств на сервер, либо в отдельно отведенное хранилище. Платформа должна иметь возможность принудительной установки пароля на устройства пользователей. Платформа должна иметь возможность удаленной блокировки устройства из консоли администратора. Платформа должна позволять администратору конфигурировать настройки FireWall и антивирусов, если таковы предусмотрены операционной системой устройства. 36 Единый инфраструктурный проект ГК «Ростех». Техническое задание Платформа должна иметь возможность и методы для шифрованная данных на конечных устройствах пользователя (где это возможно сторонними средствами). Платформа должна иметь возможность отслеживания установленных лицензий приложений и сертификатов. Платформа должна иметь функции, ограничивающие пользователя от доступа к определенным приложениям и данным на устройствах. 4.5.3.6 Требования к функциям, выполняемой системой К Системе предъявляются следующие требования: Система должна иметь возможность управления устройствами конечных пользователей под управлением следующих ОС: Windows Phone ( 7, 8.x ); Android (2.2, 2.3,3.x,4.x,5.x); iOS ( 5.0 и выше) Иметь единый интерфейс для управления всеми устройствами пользователей. Иметь web интерфейс для осуществления входа администраторов в систему. Иметь возможность отслеживания действий пользователей на конечных устройствах. Работать по проводным и беспроводным сетям данных, в том числе сети EDGE, GPRS, 3G, LTE, WiFi. Иметь методы, позволяющие разделять большие объемы данные на компактные пакеты для передачи по ненадежным каналам связи. Иметь метод, позволяющие контролировать целостность полученных данных. Платформа должна иметь возможность удаленной установки приложений на конечные устройства или иметь возможность предоставления пользователю списка доступных ему приложений. Платформа должна иметь возможность обновления установленных приложений по беспроводной сети (релевантно для промышленных платформ). Платформа должна иметь возможность физической инвентаризации конечных пользовательских устройств. Платформа должна иметь возможность инвентаризации приложений, установленных на устройствах пользователей. В состав решения должны входить абонентские терминалы YotaPhone 2 c установленными сертифицированными средствами криптографической защиты информации ViPNet и IP-телефонии. На абонентские терминалы должна распространяться гарантийная и сервисная техническая поддержка. 37 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.6 Комплексная среда контроля ИТ 4.6.1 Предпосылки для создания среды контроля ИТ Исходя из описания ИТ-инфраструктуры, приведённого в гл. 3, можно видеть, что высокая зависимость деятельности ЦА ГК «Ростех» от функционирования прикладных АС, тенденции, связанные с переходом на технологии виртуальных рабочих мест и тонких клиентов, незначительный штат специалистов ИТ, выполняющих функции сопровождения эксплуатации и развития АС, предъявляют повышенные требования к непрерывности функционирования ИТ и оперативному выявлению и устранению сбоев в работе ИТ. Решение задачи повышения надёжности функционирования АС, оперативного выявления сбоев и их устранения, обоснованного прогнозирования инициатив в части ИТ, что может быть достигнуто путём создания в ЦА Госкорпорации среды мониторинга и управления деятельностью ИТ. 4.6.2 Перспективная архитектура среды контроля ИТ Фундаментальной частью среды контроля ИТ является система мониторинга ИТинфраструктуры (далее – СМ), как базовый элемент выявления параметров состояния инфраструктурных компонентов ИТ-ландшафта и их влияния на функционирование АС на основе актуальной информации о существующих взаимосвязях компонентов ИТ. Анализ событийной информации системы мониторинга ИТ-инфраструктуры может использоваться в дальнейшем в рамках процессов планирования развития и совершенствования ИТ Госкорпорации. Рекомендуется, чтобы программное обеспечение автоматизации систем было одного производителя для минимизации потенциальных проблем, связанных с интеграцией систем в единую среду контроля ИТ. В случае использования для автоматизации деятельности систем ПО различных производителей требуется, чтобы технические средства могли обеспечивать обмен данными с внешними системами на основе широко используемых промышленных протоколов и технологий. Необходимо, чтобы архитектура СМ основывалась на принципах объединения в единую среду отдельных профильных подсистем, выполняющих специализированные функции. Детализированные требования к подсистемам приведены в разделах 3,4 настоящего документа. Приведенная архитектура позволяет обеспечить комплексный контроль ИТ с различных точек зрения: 38 Единый инфраструктурный проект ГК «Ростех». Техническое задание Основная функция Подсистема Предполагаемое семейство (разд. 4.6.4.1) продуктов НР Выделение сервисов и СРМ, ПМО, контроль Сервис Universal Discovery, uCMDB, Service актуальной Деск Manager структуры АС Инфраструктурный ПСС, ПМГЛС, BSM, Operations Manager, Network мониторинг ПАМ Node Manager, Sire Scope.. Мониторинг ПФМ BPM, BPI, RUM, Diagnostics работоспособности точки зрения АС с пользователя (функциональный мониторинг) Предоставление различной ПСО отчетности Service Health Reporter, Executive Scorecard При детальном проектировании СМ и среды контроля ИТ в целом рекомендуется использовать поэтапный принцип реализации функционала. На начальной стадии рекомендуется реализовать отдельные подсистемы СМ, в рамках последующих этапов рекомендуется, как расширять функционал уже имеющихся подсистем, так и реализовывать новые подсистемы и системы. В частности, подсистема функционального мониторинга может постепенно наращивать свои возможность с базовых функций диагностики работоспособности АС с точки зрения пользователя до более детального анализа потоков взаимодействия конкретного клиента приложения с сервером приложений. Комплекс подсистем инфраструктурного мониторинга может быть дополнен специализированными сторонними средствами диагностики состояния объектов ИТ (инженерная инфраструктура, аппаратное обеспечение и т.д.) для обеспечения всестороннего контроля состояния объектов ИТ-инфраструктуры с точки зрения доступности и производительности. Функциональными пользователями подобной среды контроля ИТ будут различные профильные подразделения ИТ. Для СМ пользователями будут диспетчеры, администраторы, технические специалисты. Для подсистемы отчетности пользователями будут представители руководства ИТ и руководства ЦА Госкорпорации. При проектировании и реализации среды контроля ИТ необходимо предусмотреть ролевую модель использования отдельных компонентов. 39 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.6.3 Цели и задачи создания системы мониторинга 4.6.3.1 Цели системы мониторинга Система мониторинга ИТ-инфраструктуры создаётся с целью: Повышения качества предоставления ИТ-услуг пользователям ЦА Госкорпорации, Повышения эффективности работы персонала эксплуатации; Минимизации времени недоступности АС и компонентов ИТ-инфраструктуры ЦА Госкорпорации; Оптимизации затрат на поддержание работоспособности и развитие АС. Реализация перечисленных целей приведёт к общему повышению эффективности работы ЦА Госкорпорации и позволит оптимальным образом решать перспективные задачи развития. 4.6.3.2 Задачи системы мониторинга Цели создания СМ должны быть достигнуты путём поэтапной реализации следующих задач: обеспечения средств и механизмов сбора данных о компонентах ИТ, их взаимосвязях и взаимовлияниях; обеспечения механизмов опроса состояния компонентов ИТ-инфраструктуры с целью получения актуальной информации об их состоянии; обеспечения средств и механизмов доставки событийной информации от компонентов ИТ-инфраструктуры в систему мониторинга; разработки принципов и механизмов обработки событийной информации, поступающей от различных элементов ИТ-ландшафта, с учетом роста потока событийной информации при развитии СМ и постепенного включения в состав СМ различных подсистем и объектов мониторинга; обеспечения для сообщений, поступающих в СМ, механизмов последующей обработки, включая реализацию первичной фильтрации, возможностей дедупликации, корреляционной приоритезации, обработки, ограничения объема сообщений аварийными событиями, подавления не релевантных для сменного персонала эксплуатации сообщений, массовых сообщений и сообщений, носящих информационный информации характер. должны Подобные способствовать механизмы повышению обработки событийной эффективности работы персонала эксплуатации, за счет выделения критических и аварийных сообщений для первоочередной обработки; реализации в компонентах СМ механизмов информирования персонала эксплуатации о возможных действиях (переключения, отключения, регламентные 40 Единый инфраструктурный проект ГК «Ростех». Техническое задание работы и т.д.) необходимых к выполнению, в случае обнаружения аварии, сбоя или отказа, в виде отображения заблаговременно проработанных решений (подсказки типа «проблема – порядок устранения») для минимизации времени устранения аварий и сбоев, а также эффективного распределения работ по устранению аварий между специалистами эксплуатации; предоставления персоналу эксплуатации возможностей оперативной настройки значений пороговых величин, определяющих условия возникновения событий от компонентов ИТ-инфраструктуры, для качественного управления потоком событийной информации; предоставления персоналу эксплуатации оперативной информации о состояниях объектов ИТ-инфраструктуры, в частности обеспечения идентификации следующих состояний и режимов работы: нормальное (штатное) состояние – объект доступен и параметры его производительности находятся в пределах установленных пороговых значений; предаварийное состояние – объект доступен и функционирует, однако какиелибо параметры контроля незначительно вышли за рамки установленных пороговых значений и возможна некоторая деградация связанных ИТ-услуг. (необходима предупредительная индикация); аварийное состояние – объект недоступен или какие-либо параметры его контроля значительно вышли за рамки установленных пороговых значений, связанные ИТ-услуги недоступны или предоставляются со значительной деградацией уровня качества (необходима аварийная индикация); отсутствие информации – информация о статусе объекта отсутствует по каким-либо причинам (необходима информационная индикация); вывод из эксплуатации (ремонт, модернизация, регламентные работы, временные отключения и т.п.) – объект планово снят с мониторинга, события о его состоянии не поступают в СМ, либо подавляются. (необходима информационная индикация). Поскольку СМ предполагает использование различных технических решений для организации контроля состояния объектов, следует обеспечивать единообразную трактовку, а также автоматическую синхронизацию статусов объектов (сообщений). В случае если синхронизацию компоненты статусов СМ не объектов в состоянии или обеспечить сообщений, следует автоматическую предусмотреть организационно-регламентные мероприятия по единообразной трактовке состояний объектов: 41 Единый инфраструктурный проект ГК «Ростех». Техническое задание разработки ролевой модели доступа к компонентам СМ и организации соответствующих областей представления информации для каждой определенной роли с последующим соотнесением штата специалистов эксплуатации с ролевой моделью СМ; проведения моделирования ИТ-ландшафта ЦА Госкорпорации, выделения классов объектов контроля, определения их атрибутов, характера учета состояния, стадий жизненного цикла; реализации схем эскалации статусов объектов СРМ ЦА Госкорпорации для оперативного принятия решения о последовательности и порядке выполнения работ персоналом эксплуатации; проработки архитектуры, функциональных требований и плана развертывания отдельных подсистем СМ; разработки прототипов подсистем и апробации их в рамках ИТ-инфраструктуры Госкорпорации для выбора оптимальных технических решений; обеспечения возможности функционального контроля состояния АС с точки зрения выполнения функций пользователей ИС и ожидаемыми показателями реакции ИС; разработки ключевых показателей эффективности (КПЭ) в рамках развертывания каждой подсистемы системы мониторинга. Определения и согласования трактовки пороговых значений состояния компонентов АС, инфраструктуры; реорганизации действий персонала эксплуатации ИТ в рамках внедрения системы мониторинга. Организации профильного обучения, определения единообразных принципов работы и взаимодействия структур эксплуатации в рамках СМ; разработки ресурсного подхода к обеспечению функционирования СМ, включая распределение ролей между персоналом эксплуатации, определение процессов обработки событийной и отчетной информации, разработку схем и процедур эскалации, привлечения внешних поставщиков услуг, смежных подразделений; обеспечения механизмов накопления и аналитической обработки событийной информации подсистем СМ для последующего анализа; 4.6.4 Требования к Системе мониторинга Цели и задачи построения перспективной системы мониторинга ИТ предполагают вовлечение в процессы контроля практически весь персонал, обеспечивающий функционирование ИТ ЦА Госкорпорации. Требуется обеспечить соблюдение баланса между реализацией отдельных функциональных особенностей компонентов и модулей СМ и решением общих задач 42 Единый инфраструктурный проект ГК «Ростех». Техническое задание эксплуатации, принципами унифицированного взаимодействия подразделений в процессе эксплуатации, сбором и анализом информации о функционировании ИТ для принятия стратегических решений по дальнейшему развитию. В рамках развертывания СМ следует уделить внимание определению процесса управления событиями, а также соотнесению деятельности по процессу с существующими (а при необходимости разрабатываемыми) в ЦА Госкорпорации процессами управления ИТ. В рамках реализации процесса управления событиями следует определить процедуры эскалации событий в инциденты, а также общие процедуры эскалации при обработке событий и инцидентов. Технические средства СМ должны предоставлять персоналу эксплуатации исчерпывающую информацию о состоянии объектов контроля для принятия решений и реализации схем эскалации. Система мониторинга должна предусматривать механизмы масштабирования для соответствия изменяющейся инфраструктуре ЦА Госкорпорации. Технические средства, применяемые при построении СМ должны обеспечивать возможность модификации набора типов объектов, применяемых в рамках построения СРМ, их атрибутивного состава и правил взаимосвязей с существующими типами объектов. 4.6.4.1 Требования к структуре СМ Создаваемая СМ должна иметь модульную структуру, обеспечивающую возможность постепенного наращивания функционала. В состав проектируемой СМ должны входить следующие подсистемы: подсистема мониторинга глобальных и локальных сетей (ПМГЛС), выполняющая общий контроль состояния телекоммуникационной среды); подсистема сбора сообщений (ПСС), выполняет функции консолидации событийной информации; подсистема агентов мониторинга (ПАМ), выполняет функции сбора информации о состоянии контролируемых серверных ресурсов; подсистема создания отчётов (ПСО), реализует функции представления отчетной информации; подсистема функционального мониторинга (ПФМ), обеспечивает контроль работоспособности АС с точки зрения пользователя; подсистема моделирования объектов (ПМО), обеспечивает функции представления СРМ, а также автоматизирует построение СРМ. Подсистемы должны быть интегрированы между собой для обмена данными о состоянии объектов мониторинга. Подсистема моделирования инфраструктуры должна 43 Единый инфраструктурный проект ГК «Ростех». Техническое задание быть интегрирована с подсистемой сбора сообщений для обмена данными о структуре информационных систем, находящихся в контуре мониторинга СМ. Базовое ПО для всех подсистем предлагаемой СМ должно производиться одним производителем ПО в целях снижения рисков возникновения проблем при интеграции подсистем между собой. 4.6.4.2 Общие требования Создаваемая система мониторинга должна: своевременно обеспечивать персонал эксплуатации информацией о состоянии предоставляемых ИТ-услуг и компонентов ИТ-инфраструктуры для минимизации времени выявления неисправностей и определения качества предоставляемых ИТуслуг; сигнализировать о снижении качества предоставляемых ИТ-услуг и выходе (деградации) значений параметров функционирования компонентов ИТ- инфраструктуры за установленные пороги для принятия персоналом эксплуатации необходимых упредительных и профилактических мер по проактивному предотвращению возникновения сбоев и аварий в ИТ-среде ЦА Госкорпорации; обеспечивать персонал эксплуатации средствами отображения состояния ИТ-услуг и ресурсов, доступности объектов контроля и каналов связи; обладать средствами мониторинга качества функционирования компонентов ИТинфраструктуры, входящих в охват СМ, включая контроль их доступности и производительности; обеспечивать персонал эксплуатации средствами унифицированного и централизованного доступа ко всем событиями, поступающим в СМ от объектов контроля, а также средствами определения влияния этих событий на предоставляемые пользователям ИТ-услуги для упрощения процедур контроля, снижения нагрузки на персонал эксплуатации, организации единообразных подходов к контролю состояния компонентов ИТ-инфраструктуры; предоставлять персоналу эксплуатации информацию для анализа причин сбоев и отказов компонентов ИТ-инфраструктуры для минимизации времени недоступности ИТ-услуги для пользователей или деградации качества ее предоставления; обеспечивать персонал эксплуатации средствами автоматизации исследования, моделирования и поддержания в актуальном состоянии структуры АС и компонентов инфраструктуры, определения их взаимосвязей и взаимовлияния для снижения рисков увеличения временных и ресурсных затрат по восстановлению качества предоставления ИТ-услуг при сбоях или инфраструктурных изменениях изза ошибочных данных о взаимосвязях и взаимовлияниях компонентов ИТ; 44 Единый инфраструктурный проект ГК «Ростех». Техническое задание предоставлять данные для автоматизации процессов инвентаризации, учета использования ресурсов, бюджетирования и планирования, а также повышать точность и оперативность предоставляемых данных; обеспечивать возможность учета и контроля действий профильного персонала эксплуатации, связанных с задачами эксплуатации АС; обеспечивать наличие механизмов качественного, а где возможно количественного предоставления отчетной информации об использовании существующих вычислительных мощностей, о характере работы и показателях доступности АС в оперативных и исторических перспективах; обеспечивать унификацию подходов к контролю компонентов ИТ-ландшафта Организации специалистами профильных подразделений, средств обмена информацией о состоянии АС и отдельных инфраструктурных компонентов; обеспечивать возможность анализа производительности компонентов ИТ- ландшафта ЦА Госкорпорации и сравнения этих показателей с ожиданиями пользователей АС; обеспечивать руководство агрегированных ИТ показателей ЦА Госкорпорации эффективности возможностью получения функционирования ИТ для планирования стратегического развития. 4.6.4.3 Требования к подсистеме мониторинга глобальных и локальных сетей 4.6.4.3.1 Цели внедрения подсистемы ПМГЛС Подсистема мониторинга глобальных и локальных сетей (ПМГЛС) предназначена для контроля состояния объектов сетевой инфраструктуры. Подсистема должна обеспечивать контроль доступности и параметров производительности сетевого оборудования и каналов связи. 4.6.4.3.2 Задачи подсистемы ПМГЛС Для достижения установленных целей внедрения подсистемы Исполнитель должен решить следующие задачи: разработать и согласовать с Заказчиком проектные решения по организации мониторинга сетевой инфраструктуры; разработать шаблон настроек сетевых устройств для включения их в контур мониторинга силами специалистов Заказчика; произвести установку и настройку аппаратных и программных компонентов ПМГЛС; настроить автоматическое периодическое исследование сетевой инфраструктуры для выявления новых объектов мониторинга и актуализации данных; 45 Единый инфраструктурный проект ГК «Ростех». Техническое задание выполнить создание топологической схемы сети и настройку представлений топологической схемы для использования в работе; организовать мониторинг состояния сетевых устройств в соответствии с проектными решениями, в том числе: настроить активный опрос сетевого оборудования для выявления отказов и предельного использования ресурсов оборудования; настроить прием и обработку сообщений от сетевого оборудования; настроить сбор и агрегацию данных о параметрах производительности, подготовку отчетности по собранным данным; выполнить создание учетных записей пользователей в соответствии с ролевой моделью СМ; выполнить настройку полномочий доступа различных пользователей подсистемы к объектам мониторинга; сформировать комплект проектной и эксплуатационной документации в соответствии с требованиями раздела «Требования к составу документации»; провести консультирование пользователей подсистемы по вопросам использования подсистемы в соответствии с разработанными проектными решениями. 4.6.4.3.3 Требования к мероприятиям по запуску в работу Работы по запуску подсистемы в работу должны включать в себя следующие мероприятия: согласование между Исполнителем и Заказчиком перечня объектов мониторинга для включения в контур мониторинга ПМГЛС (Перечень объектов ПМГЛС); настройка объектов мониторинга для включения в контур мониторинга ПМГЛС специалистами Заказчика в соответствии с Перечнем объектов ПМГЛС и предоставленными Исполнителем шаблонами настройки; проведение исследования сети, наполнения ПМГЛС данными об объектах мониторинга, контроль соответствия перечня объектов, представленных в подсистеме, и Перечня объектов ПМГЛС; составление схем соединений и согласование корректности схем с Заказчиком; организация рабочих мест пользователей подсистемы (развертывание клиентского ПО, предоставление сетевого доступа к серверам подсистемы с рабочих мест пользователей); проведение консультирования пользователей подсистемы; 46 по вопросам эксплуатации Единый инфраструктурный проект ГК «Ростех». Техническое задание проверка работоспособности подсистемы и перевод ее в опытную эксплуатацию в соответствии с Программой и методикой испытаний; перевод системы в промышленную эксплуатацию по результатам устранения замечаний опытной эксплуатации. 4.6.4.3.4 Требования к подсистеме ПМГЛС ПМГЛС должна обеспечивать выполнение следующих требований: возможность автоматического обнаружения и идентификации активного сетевого оборудования, поддерживающего стек протоколов TCP/IP; построение графического представления топологии взаимодействия, обнаруженного активного сетевого оборудования по канальному и сетевому уровням модели OSI; возможность обнаружения изменений в топологии активного сетевого оборудования в режиме близкому к реальному времени (без ручного вмешательства); возможность предоставления обнаруженных топологических представлений активного сетевого оборудования в базу данных конфигурационных единиц предприятия (CMDB); возможность отображения топологии активного сетевого оборудования на картах (например, географических, планах местности или зданий); возможность создания иерархии карт и просмотра топологии переходом с карты верхнего уровня на карты нижнего уровня (drill down); возможность определения пороговых значений различных метрик работы активного сетевого устройства; возможность генерации сообщений при выходе за заданные пороговые значения для метрик работы активного сетевого устройства; возможность выполнения корреляции по событиям от активного сетевого оборудования; возможность отображения статуса сетевого устройства и каналов связи на картах и в топологии взаимодействия сетевых устройств в соответствии с событиями от соответствующего устройства; возможность создания логических групп сетевых устройств по заданным параметрам (например, по территориальному принципу или по типу устройств); Возможность мониторинга агрегированных соединений и групп HSRP/VRRP. возможность снятия метрик производительности оборудования; 47 с активного сетевого Единый инфраструктурный проект ГК «Ростех». Техническое задание наличие различной отчетности по производительности активного сетевого мониторинга сетевой оборудования; наличие Web-консоли для операторов подсистемы инфраструктуры; возможность построения масштабируемого решения (построение иерархической архитектуры решения); возможность расширения функционала подсистемы за счет добавления различных функциональных модулей, предусмотренных производителем ПО подсистемы, в будущем. 4.6.4.4 Требования к подсистеме сбора сообщений 4.6.4.4.1 Цели внедрения подсистемы ПСС Подсистема сбора сообщений предназначена для сбора сообщений из различных источников и их совместной обработки. Вместе с этим ПСС должна обеспечивать отображение событий для персонала эксплуатации ИТ и оповещение персонала по зарегистрированным отказам. 4.6.4.4.2 Задачи подсистемы Для достижения установленных целей необходимо решить следующие задачи: определить источники сообщений в ИТ-инфраструктуре; определить наборы параметров для контроля состояния объектов мониторинга различных типов; разработать и согласовать с Заказчиком проектные решения по организации сбора и обработки сообщений; произвести установку и настройку аппаратных и программных компонентов ПСС; реализовать сбор сообщений из прочих подсистем СМ и внешних систем в соответствии с проектными решениями с использованием интерфейсов взаимной интеграции компонентов; настроить правила обработки событий, поступающих из различных источников; настроить правила корреляции различных сообщений; осуществить интеграцию ПСС с ПМО для передачи в ПСС данных о структуре информационных систем; реализовать наборы интерфейсов для различных ролей пользователей в соответствии с проектными решениями; выполнить создание учетных записей пользователей в соответствии с ролевой моделью СМ; 48 Единый инфраструктурный проект ГК «Ростех». Техническое задание выполнить настройку полномочий доступа различных пользователей подсистемы к объектам мониторинга; сформировать комплект проектной и эксплуатационной документации в соответствии с требованиями раздела «Требования к составу документации»; провести консультирование пользователей подсистемы по вопросам использования подсистемы в соответствии с разработанными проектными решениями. 4.6.4.4.3 Требования к мероприятиям по запуску в работу Работы по запуску подсистемы в работу должны включать в себя следующие мероприятия: согласование между Исполнителем и Заказчиком перечня источников информации для объединения сообщений в ПСС (Перечень объектов ПСС); импорт и адаптация сервисно-ресурсной модели из ПМО, контроль соответствия перечня объектов, представленных в подсистеме, и Перечня объектов ПСС; подготовка и реализация схем оповещения пользователей СМ о зафиксированных событиях; организация рабочих мест пользователей подсистемы (развертывание клиентского ПО, предоставление сетевого доступа к серверам подсистемы с рабочих мест пользователей); проведение консультирования пользователей по вопросам эксплуатации подсистемы; проверка работоспособности подсистемы и перевод ее в опытную эксплуатацию в соответствии с Программой и методикой испытаний; перевод системы в промышленную эксплуатацию по результатам устранения замечаний опытной эксплуатации. 4.6.4.4.4 Требования к подсистеме ПСС ПСС должна обеспечивать выполнение следующих требований: возможность создания единой консолидированной консоли для отображения, анализа и управления всей событийной информацией, поступающей от подсистем решения; возможность представления в единой консоли совокупных, взаимосвязанных данных в рамках сервисно-ресурсной модели информационных систем; возможность организации доступа пользователей к консоли в соответствии с определенными ролями и зонами ответственности; возможность категоризации событийной информации по типу (например, “события систем хранения” или “события от баз данных” и т.д.); 49 Единый инфраструктурный проект ГК «Ростех». Техническое задание возможность ввода новых производных индикаторов работы объекта мониторинга и его компонентов, рассчитываемых на основе базовых собираемых метрик; возможность расчета ключевых показателей эффективности работы объекта мониторинга на основе как базовых метрик, так и производных индикаторов; возможность создания правил корреляции без использования программирования (графический интерфейс), с учетом сервисно-ресурсной модели компонентов объекта мониторинга; возможность отображения зависимых друг от друга сообщений (отображение причинно-следственной связи на уровне событий); возможность просмотра графиков производительности серверных платформ по контексту; возможность отображения на одном графике данных от нескольких источников для возможности сопоставления и оценки работы объектов мониторинга; возможность гибкой настройки оповещений ответственных людей в соответствии с их зонами ответственности и типами сообщений, приходящих от подсистем системы мониторинга; наличие Web-консоли для доступа к интерфейсу системы; возможность пользовательской настройки вариантов представления данных в зависимости от роли пользователя (например, оперативное представление в соответствии с зоной ответственности, аналитическое представление в соответствии с зоной ответственности). 4.6.4.4.5 Требования к используемому ПО При лицензировании компонентов ПСС учитываются следующие исходные данные: Для размещения ПСС должен использоваться как минимум один сервер сбора сообщений, требований к отказоустойчивости не требуется. 4.6.4.5 Подсистема создания отчетов 4.6.4.5.1 Цели внедрения подсистемы Подсистема создания отчетов (ПСО) предназначена для реализации отчетности о работе информационных систем, находящихся в контуре мониторинга СМ. 4.6.4.5.2 Задачи подсистемы ПСО Для достижения установленных целей внедрения подсистемы необходимо решить следующие задачи: 50 Единый инфраструктурный проект ГК «Ростех». Техническое задание разработать и согласовать с Заказчиком проектные решения по организации отчетности о работе информационных систем, в т. ч.: определить наборы и объемы данных для отчетности; определить получателей отчетности; разработать шаблоны отчетов различных типов и периодичность создания отчетов различных типов; произвести установку и настройку аппаратных и программных компонентов ПСО; обеспечить поступление в ПСО данных, необходимых для создания отчетов в соответствии с проектными решениями; внести в подсистему разработанные шаблоны отчетов и настроить их создание по расписанию, либо по запросу; выполнить создание учетных записей пользователей в соответствии с ролевой моделью СМ; выполнить настройку полномочий доступа различных пользователей подсистемы к объектам мониторинга; сформировать комплект проектной и эксплуатационной документации в соответствии с требованиями раздела «Требования к составу документации»; провести консультирование пользователей подсистемы по вопросам использования подсистемы в соответствии с разработанными проектными решениями. 4.6.4.5.3 Требования к мероприятиям по запуску в работу Работы по запуску подсистемы в работу должны включать в себя следующие мероприятия: согласование между Исполнителем и Заказчиком перечня объектов мониторинга для формирования отчетности (Перечень объектов ПСО); согласование между Исполнителем и Заказчиком списков получателей, форм отчетов и наборов данных для формирования отчетности (Перечень отчетов ПСО); организация рабочих мест пользователей подсистемы (развертывание клиентского ПО, предоставление сетевого доступа к серверам подсистемы с рабочих мест пользователей); проведение консультирования пользователей по вопросам эксплуатации подсистемы; проверка работоспособности подсистемы и перевод ее в опытную эксплуатацию в соответствии с Программой и методикой испытаний; перевод системы в промышленную эксплуатацию по результатам устранения замечаний опытной эксплуатации. 51 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.6.4.5.4 Требования к подсистеме ПСО должна обеспечивать выполнение следующих требований: возможность построения отчетов на основе сервисно-ресурсной модели; возможность построения сквозных отчетов по всем компонентам выбранного бизнес-сервиса, услуги или приложения; возможность построения интерактивных отчетов (с возможностью детализации по контексту, динамического указания параметров отчета); наличие динамических отчетов, автоматически поддерживающих изменения в сервисно-ресурсных моделях; возможность использования данных всех возможных типов мониторинга для построения сквозных представлять отчетов данные о (например, в едином бизнес-транзакциях интерактивном пользователей, отчете технических транзакциях и технических метриках работы серверных платформ); возможность представления отчетов по годам, дням, часам с возможностью динамически изменять эти параметры; возможность создавать как отчеты уровня “Executive summary” так и уровня технической детализации. 4.6.4.5.5 Требования к используемому ПО При лицензировании компонентов ПСО должны учитываться следующие исходные данные: число серверов, задействованных в информационных системах Заказчика (включая гипервизоры виртуализации) – 310 шт. 4.6.4.6 Подсистема функционального мониторинга 4.6.4.6.1 Цели внедрения подсистемы Подсистема функционального мониторинга (ПФМ) предназначена для контроля исполнения информационными системами функций, предоставляемых пользователям этих систем. Подсистема должна обеспечивать контроль предоставления контролируемых функций и, по возможности, параметров производительности данных функций. 4.6.4.6.2 Задачи подсистемы Для достижения установленных целей внедрения подсистемы необходимо решить следующие задачи: разработать и согласовать с Заказчиком проектные решения по организации функционального мониторинга информационных систем; 52 Единый инфраструктурный проект ГК «Ростех». Техническое задание разработать правила настроек информационных систем для включения их в контур мониторинга силами специалистов Заказчика; произвести установку и настройку аппаратных и программных компонентов ПФМ; организовать мониторинг функций информационных систем в соответствии с проектными решениями, в том числе: реализовать средствами подсистемы набор тестов для контроля выбранных функций информационных систем; настроить правила обработки результатов тестов для выявления отказов и ошибок функционирования контролируемых функций информационных систем; по возможности включить в правила обработки результатов тестов контроль параметров производительности контролируемых функций информационных систем; настроить автоматическое периодическое исполнение реализованных наборов тестов; обеспечить создание сообщений о выявленных неисправностях в ПСС; выполнить создание учетных записей пользователей в соответствии с ролевой моделью СМ; выполнить настройку полномочий доступа различных пользователей подсистемы к объектам мониторинга; сформировать комплект проектной и эксплуатационной документации в соответствии с требованиями раздела «Требования к составу документации»; провести консультирование пользователей подсистемы по вопросам использования подсистемы в соответствии с разработанными проектными решениями. 4.6.4.6.3 Требования к мероприятиям по запуску в работу Работы по запуску подсистемы в работу должны включать в себя следующие мероприятия: согласование между Исполнителем и Заказчиком перечня информационных систем и контролируемых функций для включения в контур мониторинга ПФМ (Перечень объектов ПФМ); настройка информационных систем для включения в контур мониторинга ПФМ специалистами Заказчика в соответствии с Перечнем объектов ПФМ и предоставленными Исполнителем правилами настройки; внесение данных об объектах мониторинга в ПФМ, контроль соответствия перечня объектов и тестов, представленных в подсистеме, и Перечня объектов ПФМ; 53 Единый инфраструктурный проект ГК «Ростех». Техническое задание организация рабочих мест пользователей подсистемы (развертывание клиентского ПО, предоставление сетевого доступа к серверам подсистемы с рабочих мест пользователей); проведение консультирования пользователей по вопросам эксплуатации подсистемы; проверка работоспособности подсистемы и перевод ее в опытную эксплуатацию в соответствии с Программой и методикой испытаний; перевод системы в промышленную эксплуатацию по результатам устранения замечаний опытной эксплуатации. 4.6.4.6.4 Требования к подсистеме ПФМ должна обеспечивать выполнение следующих требований: возможность выполнения мониторинга приложений, услуг или сервисов с помощью эмуляции обращений к ним пользователей (методом записи выполняемых действий пользователя при обращении к этим приложениям, услугам или сервисам с последующим выполнением записанных действий с задаваемой периодичностью из разных сегментов инфраструктуры); возможность отображения данных о выполнении записанных действий пользователя (синтетических транзакций) в виде наглядных гистограмм; возможность на гистограмме отобразить данные о выполнении транзакции и времени, затраченном на соответствующем этапе ее выполнения (например, время отработки транзакции на стороне клиента, время отработки сетевых служб, время передачи данных по сети, время установки защищенного соединения, время на стороне сервера и т.д.); возможность мониторинга комбинированного приложения (использующего несколько протоколов на разных своих участках); возможность использовать для записи действий пользователей средства записи максимально возможного кол-ва различных протоколов, необходима поддержка как минимум следующих протоколов: Web (HTTP/HTML/AJAX/Scripts/Services); Action Message Format (AMF) ; Ajax TruClient; Citrix; COM/DCOM; DNS; EJB; 54 Единый инфраструктурный проект ГК «Ростех». Техническое задание FTP; Flex; IMAP; Java/JavaScript; LDAP; MMS; .Net; RDP; MAPI; MS SQL; ODBC; Oracle (NCA, Web) ; POP3; SAP (GUI/Script/Web) ; SMTP; RTE; VB script; SilverLight; Windows Sockets; наличие средств описания новых протоколов; возможность записи действий пользователя на протокольном уровне (передача и обмен данными) и на интерфейсном уровне (нажатие различных кнопок и иконок интерфейса); возможность фильтрации выводимых данных о транзакциях (по сегменту инфраструктуры откуда выполняется эмуляция, по названию, по заданному периоду времени и т.д.); возможность вывода детализации по периодам времени с информацией о том, сколько транзакций (и % транзакций) выполнились, не выполнились, выполнились в пределах заданных пороговых значений, не выполнились в рамках заданных значений; возможность отслеживания данных производительности и доступности по выбранным транзакциям; возможность вывода данных с информацией по времени отклика; возможность вывода “сырых” (без обработки) данных о результатах отработки транзакций (желательно на графике); 55 Единый инфраструктурный проект ГК «Ростех». Техническое задание возможность отображения данных о работе транзакций как в графическом виде, так и в табличном; возможность отображения данных в виде аналитических отчетов в том числе и графики типа “Over Time”; возможность отслеживания сессий, возникающих при обращении пользователя; поддержка защищенных соединений (SSL); возможность масштабирования архитектуры средств мониторинга; возможность использования внутренних хранилищ данных; возможность настройки оповещений по разным характеристикам отработки транзакций, в т. ч.: ошибка в выполнении транзакции, превышение времени отклика; время отклика в отношении к кол-ву транзакций, среднее время выполнения транзакций; возможность выполнить действия при срабатывании заданных требований отработки транзакции (создать событие, обратиться к URL, отослать SNMPсообщение, запустить исполняемый файл, записать данные в лог-файл); возможность определения как часть оповещение при срабатывании порогов нужно сгенерировать (например, каждый раз или раз в 15 минут); возможность сброса оповещения, если параметры работы транзакций пришли в норму; возможность работать с двумя методами мониторинга действий пользователя из единого интерфейса; возможность назначения времени на техническое обслуживание систем (при этом данные проверок все равно не должны теряться); возможность экспорта данных в форматах PDF, XML, Excel, CSV; возможность сопоставления данных traceroute для Web-приложений с данными эмуляции обращений пользователей к этим приложениям в целях выявления проблем, связанных с работой сети; возможность поуровневого отображения параметров отработки комплексных транзакций, основанных на использовании нескольких протоколов (например, транзакция, часть которой выполняется в виде Web-запроса, а далее в виде SQLзапроса); возможность отображения параметров транзакций с заданной критичностью, определяемой пороговыми значениями для данной транзакции, критичность должна кодироваться цветом; 56 Единый инфраструктурный проект ГК «Ростех». Техническое задание наличие графического представления данных о выполнении транзакций с возможностью получения детализации при наведении курсора мышки на элемент графика; наличие встроенных средств, позволяющих экспортировать данные о пользовательских транзакциях в графическом виде с возможностью добавления аннотаций к элементам экспортируемого графика. 4.6.4.6.5 Требования к используемому ПО В контур мониторинга подсистемы должен быть введён набор прикладных систем, представленный в таблице (Таблица 1). Для каждой из систем должен использоваться собственный тест синтетической транзакции. Таблица 1. Прикладные системы для мониторинга средствами ПФМ Наименование системы/ПО Назначение, выполняемые функции Объект, на котором Платформа Кол-во Комментарии применяется реализации польз. ППО ППО Центральный 1С: Бухгалтерия Бухгалтерский офис, предприятия 8.2 учет УИТ, ДБУ, ДФЭП, Специализированн 1С:Предприятие 30 АХД 1С: Зарплата и управление персоналом 8.2 по ая АС. В настоящее время обслуживается ДБУ Специализированн Бухгалтерский Центральный учет офис, ДБУ, УП 1С:Предприятие 20 ая АС. В настоящее время обслуживается ДБУ Специализированн 1С:Консолидаци Бухгалтерский Центральный я учет офис, ДБУ 1С:Предприятие 15 ая АС. В настоящее время обслуживается ДБУ АС Консультант+ Справочно- Центральный Правовая офис, Система Госкорпорация Вся СПС Консультант 700 Базовая АС КИС Специализированн СЭД Электронный Центральный документообор офис, от Госкорпорация вся ая Documentum 5.3 700 АС для обеспечения электронного документооборота РМР(Windows) Электронный Руководящий документообор состав от Госкорпорации Программное Java-приложение 70 обеспечение для работы документами СЭД 57 с Единый инфраструктурный проект ГК «Ростех». Техническое задание Наименование системы/ПО Назначение, выполняемые функции Объект, на котором Платформа Кол-во Комментарии применяется реализации польз. ППО по ППО Программное РМР(iOS) Электронный Руководящий документообор состав от Госкорпорации обеспечение Apple iOS для работы 70 через мобильные устройства с документами СЭД Система РТ-НИПС 30 + 40 управления не Центральный Visual профильными офис, DotNet активами Организации SQL собственности Госкорпорации 2008R2 Studio 2008 + Server Госкорпорации ожидае тся в ближай шее время Сбор информации по объектам недвижимости организаций и предприятий, входящих в состав Госкорпорации Хранение ИС АГД Хранение Центральный документов офис и оперативный поиск SharePoint 700 документов подразделений Госкорпорации Внутренний Единый портал внутрикорпорат Госкорпорации ивный портал Объединение всех Центральный офис SharePoint сайт Госкорпорации е информации Общедоступны о деятельности й ресурс Без Bitrix сайт Госкорпорации Предоставлени е информации Общедоступны о деятельности й ресурс огранич ений Госкорпорации Новый интернет Без - огранич ений Госкорпорации Электронный телефонный Центральный справочник справочник офис Bitrix 700 Госкорпорации ИСПА ая система правовых актов портале Предоставление информации о деятельности Госкорпорации Разработан в связи с внедрением нового бренда Госкорпорации Оперативный поиск Телефонный Информационн систем на едином Госкорпорации Предоставлени Интернет 700 контактных данных работников Госкорпорации Система Центральный офис Консультант+ 700 для обеспечения справочноправовыми актами 58 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.6.4.7 Подсистема агентов мониторинга 4.6.4.7.1 Цели внедрения подсистемы Подсистема агентов мониторинга (ПАМ) предназначена для выполнения задач мониторинга инфраструктуры серверов и приложений. Подсистема должна обеспечивать контроль исправности и параметров производительности компонентов инфраструктуры хранения данных, вычислительной инфраструктуры и приложений. 4.6.4.7.2 Задачи подсистемы Для достижения установленных целей необходимо решить следующие задачи: разработать и согласовать с Заказчиком проектные решения по организации мониторинга вычислительной инфраструктуры и приложений; разработать инструкции по установке агентов мониторинга в вычислительной инфраструктуре; произвести установку и настройку аппаратных и программных компонентов ПАМ; организовать мониторинг состояния устройств вычислительной инфраструктуры и приложений в соответствии с проектными решениями, в том числе: произвести установку агентов мониторинга в вычислительной инфраструктуре; провести наполнение баз данных ПАМ сведениями об объектах в контуре мониторинга ПАМ; определить правила сбора и обработки информации на агентах мониторинга; настроить сбор и обработку сообщений от агентов мониторинга на серверах ПАМ; разработать набор интерфейсов подсистемы для взаимодействия с пользователями; выполнить создание учетных записей пользователей в соответствии с ролевой моделью СМ; выполнить настройку полномочий доступа различных пользователей подсистемы к объектам мониторинга; сформировать комплект проектной и эксплуатационной документации в соответствии с требованиями раздела «Требования к оборудованию и ПО»; провести консультирование пользователей подсистемы по вопросам использования подсистемы в соответствии с разработанными проектными решениями. 4.6.4.7.3 Требования к мероприятиям по запуску в работу Работы по запуску подсистемы в работу должны включать в себя следующие мероприятия: 59 Единый инфраструктурный проект ГК «Ростех». Техническое задание согласование между Исполнителем и Заказчиком перечня объектов мониторинга для включения в контур мониторинга ПАМ (Перечень объектов ПАМ); настройка объектов мониторинга для включения в контур мониторинга ПАМ специалистами Заказчика в соответствии с Перечнем объектов ПАМ и предоставленными Исполнителем инструкциями по настройке; подключение агентов мониторинга с серверам ПАМ, наполнения ПАМ данными об объектах мониторинга, контроль соответствия перечня объектов, представленных в подсистеме, и Перечня объектов ПАМ; организация рабочих мест пользователей подсистемы (развертывание клиентского ПО, предоставление сетевого доступа к серверам подсистемы с рабочих мест пользователей); проведение консультирования пользователей по вопросам эксплуатации подсистемы; проверка работоспособности подсистемы и перевод ее в опытную эксплуатацию в соответствии с Программой и методикой испытаний; перевод системы в промышленную эксплуатацию по результатам устранения замечаний опытной эксплуатации. 4.6.4.7.4 Требования к подсистеме ПАМ должна обеспечивать выполнение следующих требований: возможность ручного добавления новых серверных компонентов в контур мониторинга; возможность совместного мониторинга оборудования вычислительной инфраструктуры как с помощью установки специальных программных агентов, так и удаленно, без установки специальных программных агентов; возможность пользовательской настройки правил мониторинга (пороговых значений и логики проверки) метрик на серверных платформах; возможность централизованного распространения правил мониторинга как на отдельные серверы, так и на группы серверов; возможность удаленного отключения выборочных правил мониторинга на выбранном сервере; наличие в составе поставки рекомендованных готовых правил мониторинга серверных платформ с возможностью их изменения; поддержка широкого набора операционных систем для мониторинга на серверных платформах; 60 Единый инфраструктурный проект ГК «Ростех». Техническое задание возможность отслеживания метрик работы различного программного обеспечения, установленного на контролируемых серверных платформах; возможность удаленного управления агентами мониторинга, установленными на серверные платформы; обеспечение работы с агентами по протоколу, обеспечивающему шифрование передаваемых данных (например, HTTPS), в целях обеспечения безопасного взаимодействия между компонентами системы мониторинга; возможность отслеживание произвольных метрик производительности на серверных платформах; возможность выполнения ручных и автоматических действий на основе пришедшего события от серверных платформ; возможность построения масштабируемого решения (построение иерархической архитектуры решения); возможность эскалации сообщений между пользователями; возможность обслуживании указания без времени потери простоя системы при событий, происходящих на профилактическом серверах во время профилактических работ; возможность интеграции с системами мониторинга аппаратной части серверных платформ; возможность выполнять запуск очередной проверки метрик по результатам отработки других проверок; возможность расчета эталонных значений отслеживаемых метрик на основе статистической информации за определенный исторический период; возможность указания зависимости исполнения заданного правила мониторинга по результату исполнения предыдущего правила мониторинга; наличие WEB-интерфейса; наличие «толстого» клиента, устанавливаемого на рабочей станции; возможность аудита действий в подсистеме; возможность копирования/синхронизации правил мониторинга между серверами мониторинга в целях снижения стоимости владения системой мониторинга. 4.6.4.7.5 Требования к используемому ПО При лицензировании компонентов ПАМ учитываются следующие исходные данные: Общее число серверов (по количеству экземпляров ОС) 250 из них виртуальных 230 61 Единый инфраструктурный проект ГК «Ростех». Техническое задание Число серверов виртуализации VMWare ESX(i) Число дисковых массивов СХД 60 6 4.6.4.8 Подсистема моделирования объектов ИТ-инфраструктуры 4.6.4.8.1 Цели внедрения подсистемы Подсистема моделирования автоматизированного создания объектов и (ПМО) хранения предназначена сервисно-ресурсной для модели информационных систем (СРМ), включенных в контур мониторинга СМ. Сервисноресурсная модель информационной системы представляет собой схему структуры информационной системы, отображающую объекты мониторинга, входящие в состав информационной системы, и связи между ними. Объекты мониторинга, представленные в СРМ, в контексте СРМ называются конфигурационными единицами (КЕ). 4.6.4.8.2 Задачи подсистемы Для достижения установленных целей внедрения подсистемы необходимо решить следующие задачи: разработать и согласовать с Заказчиком проектные решения по организации моделирования ИТ-инфраструктуры; составить перечень информационных систем Заказчика (Перечень информационных систем); собрать сведения о структуре информационных систем Заказчика и их взаимосвязях; составить перечень объектов мониторинга для включения в СРМ (Перечень объектов СРМ); произвести установку и настройку аппаратных и программных компонентов ПМО; выполнить начальную загрузку (обнаружение и идентификация) данных о структуре информационных систем Заказчика; выполнить первичное моделирование сервисно-ресурсной модели на основании данных начальной загрузки, моделирование включает: получение предварительной сервисно-ресурсной модели по данным начальной загрузки; добавление в сервисно-ресурсную модель объектов для Перечню объектов СРМ и введение соответствующих связей; 62 соответствия Единый инфраструктурный проект ГК «Ростех». Техническое задание итеративное согласование сервисно-ресурсной модели со специалистами Заказчика и соответствующая коррекция сервисно-ресурсной модели до достижения соответствия реальной структуре информационных систем; организовать автоматическое периодическое исследование ИТ-инфраструктуры для выявления данных о структуре информационных систем; осуществить интеграцию ПМО с ПСС для передачи в ПСС данных о структуре информационных систем; выполнить создание учетных записей пользователей в соответствии с ролевой моделью СМ; выполнить настройку полномочий доступа различных пользователей подсистемы к объектам мониторинга; сформировать комплект проектной и эксплуатационной документации в соответствии с требованиями раздела «Требования к составу документации»; провести консультирование пользователей подсистемы по вопросам использования подсистемы в соответствии с разработанными проектными решениями. 4.6.4.8.3 Требования к мероприятиям по запуску в работу Работы по запуску подсистемы в работу должны включать в себя следующие мероприятия: составление Исполнителем и Заказчиком совместно Перечня информационных систем и Перечня объектов СРМ; выявление Исполнителем и Заказчиком совместно структуры информационных систем Заказчика и их взаимосвязей; организация доступа к объектам мониторинга для автоматического исследования средствами ПМО; исследование ИТ-инфраструктуры и наполнения баз данных ПМО; составление и согласование с Заказчиком сервисно-ресурсной модели информационных систем; проведение консультирования пользователей по вопросам эксплуатации подсистемы; проверка работоспособности подсистемы и перевод ее в опытную эксплуатацию в соответствии с Программой и методикой испытаний; перевод системы в промышленную эксплуатацию по результатам устранения замечаний опытной эксплуатации. 4.6.4.8.4 Требования к подсистеме ПМО должна обеспечивать выполнение следующих требований: 63 Единый инфраструктурный проект ГК «Ростех». Техническое задание наличие встроенных типов конфигурационных элементов (единиц) и связей между ними; возможность в графическом режиме без использования программирования удалять, создавать и изменять типы конфигурационных единиц и собственные типы связей между конфигурационными элементами; возможность удаления, создания и изменения связей между конфигурационными единицами и атрибутов конфигурационных единиц и связей; наличие единообразного способа обращения к данным, находящимся в базе данных конфигурационных единиц для запроса необходимых данных; возможность создания, удаления и изменения описательной модели услуги, сервиса или приложения, составленной из конфигурационных единиц и связей между ними; наличие встроенных моделей, описывающих наиболее популярные и известные промышленные приложения (например, такие, как MS SQL, MS Exchange, MS Active Directory, Oracle, Siebel, IBM WebSphere, IBM MQ, SAP, Oracle Application server, JBOSS, IIS, MySQL, J2EE приложения, Apache); возможность наложения “шаблонов” на модель с целью отображения только определенного набора данных из этой модели по заданным критериям (например, отображение только сетевых соединений, портов и баз данных на операционной системе UNIX из модели, описывающей информационную систему); возможность добавления/удаления/изменения экземпляров конфигурационных единиц вручную; возможность автоматического обнаружения элементов инфраструктуры и автоматического наполнения ими базы данных конфигурационных единиц; динамическое поддержание актуальной информации об имеющихся моделях за счет периодического автоматического обнаружения; выполнение обнаружения конфигурационных единиц без использования каких-либо дополнительных агентов; возможность расширения функционала обнаружения элементов инфраструктуры; возможность представлять данные модели в виде графа (сервисно-ресурсной модели), таблицы, наборного представления элементов; возможность группировки отображаемых данных по заданным критериям (например, отображать не все серверы с Windows 2008, а сгруппировать их в группу Windows 2008 с возможностью отображения участников этой группы); возможность обогащения данных по заданным правилам (например, если конфигурационная единица соответствует заданным критериям, то автоматически 64 Единый инфраструктурный проект ГК «Ростех». Техническое задание выстраиваются дополнительные связи с другими заданными конфигурационными единицами); возможность выбора того, какие компоненты модели выводить на экран оператору, а какие скрыть по заданным критериям; возможность моделирования изменений и обнаружения взаимного влияния КЕ по запросу; возможность сохранения истории изменений конфигурационной единицы; возможность отслеживания жизненного цикла конфигурационной единицы; наличие встроенных отчетов; возможность изменения и настройки отчетов; возможность выполнения различных выборок из базы данных по заданным критериям и фильтрам (например, вывести все связанные с данной конфигурационной единицей базы данных, работающих на Windows 2008 R2); наличие Web-интерфейса консоли операторов базы данных конфигурационных единиц; управление доступом как на высоком уровне представления модели услуг, сервиса или приложения, так и на уровне типов конфигурационных единиц и их связей; возможность построения централизованной архитектуры решения (без необходимости выполнения синхронизации данных); наличие различного рода адаптеров к внешним системам; наличие открытого API; наличие функций федеративного хранения данных без дублирования; обеспечивать интеграции для получения информации о КЕ из ПМГЛС; обеспечивать интеграцию с ПСС для передачи в ПСС данных о структуре информационных систем; возможность поддержки отказоустойчивой конфигурации; поддержка работы как минимум на следующих СУБД: Microsoft SQL Server, ORACLE. 4.6.4.8.5 Требования к используемому ПО При лицензировании компонентов ПМО учитываются следующие исходные данные: Общее число серверов (по количеству экземпляров ОС) 310 4.6.4.9 Требования к документации СМ В рамках проекта создания СМ должен быть подготовлен следующий набор документов: 65 Единый инфраструктурный проект ГК «Ростех». Техническое задание «Техническое задание на построение системы мониторинга ИТ-инфраструктуры»; «Система мониторинга ИТ-инфраструктуры. Технические решения»; «Система мониторинга ИТ-инфраструктуры. Программа и методика испытаний по вводу в эксплуатацию»; комплект инструкций по эксплуатации в составе: «Система мониторинга ИТ-инфраструктуры. Подсистема мониторинга глобальных и локальных сетей. Инструкция по эксплуатации»; «Система мониторинга ИТ-инфраструктуры. Подсистема сбора сообщений. Инструкция по эксплуатации»; «Система мониторинга ИТ-инфраструктуры. Подсистема агентов мониторинга. Инструкция по эксплуатации»; «Система мониторинга ИТ-инфраструктуры. Подсистема создания отчётов. Инструкция по эксплуатации»; «Система мониторинга ИТ-инфраструктуры. Подсистема функционального мониторинга. Инструкция по эксплуатации»; «Система мониторинга ИТ-инфраструктуры. Подсистема моделирования объектов. Инструкция по эксплуатации». Набор документов может быть изменен по согласованию с Заказчиком. Исполнитель предоставляет Заказчику документацию на бумажных и электронных носителях. 4.6.4.10 Требования к оборудованию и ПО При построении СМ для создания подсистем должны быть использованы следующие программные продукты: подсистема мониторинга глобальных и локальных сетей – HP Network Node Manager I или любая другая аналогичная по функционалу; подсистема сбора сообщений - HP Operations Manager i или любая другая аналогичная по функционалу; подсистема агентов мониторинга – HP Operations Manager for Windows или любая другая аналогичная по функционалу; подсистема создания отчётов – HP Service Health Reporter или любая другая аналогичная по функционалу; подсистема функционального мониторинга – HP Business Process Monitor или любая другая аналогичная по функционалу; подсистема моделирования ИТ-инфраструктуры – HP Universal Discovery или любая другая аналогичная по функционалу. 66 Единый инфраструктурный проект ГК «Ростех». Техническое задание Оборудование для размещения компонентов СМ предоставляется Заказчиком на основании требований, которые Исполнитель должен обосновать и внести в проектную документацию. 4.6.4.11 Критерии оценки результатов проекта внедрения СМ Работы считаются выполненными при получении следующих результатов: система мониторинга настроена в соответствии с требованиями утвержденного технического задания и работает стабильно; для каждой из подсистем проведены мероприятия, указанные в разделе «Запуск в работу» соответствующей подсистемы; разработана и передана Заказчику документация, указанная в разделе «Требования к составу документации». 4.7 Комплексная система антивирусной защиты (КСАЗ) 4.7.1 Предпосылки для создания КСАЗ Описанная в гл. 3 инфраструктура, хоть и является виртуальной, по своей сути идентична обычной ИТ-инфраструктуре предприятия, соответственно повержена всем современным обеспечена киберугрозам. должным Разворачиваемая уровнем защиты, инфраструктура учитывающим все должна современные быть пути распространения и специфику вредоносных объектов 4.7.2 Назначение КСАЗ Система КСАЗ предназначена для борьбы с актуальными киберугрозами путем: выявления и нейтрализации вредоносных объектов сканированием их содержимого или анализа поступающим поведения, на выявления защищенную вредоносного инфраструктуру. содержимого Антивирусное в трафике, программное обеспечение на конечной рабочей станции должно так же обладать функционалом сетевого экрана, контроля рабочего места, защиты от сетевых атак. 4.7.3 Общие требования для КСАЗ Программные средства антивирусной защиты виртуальных сред должны: обеспечивать реализацию следующих функциональных возможностей: Резидентный антивирусный мониторинг. Защита от программ-маскировщиков, программ автодозвона на платные сайты. Эвристический анализатор, позволяющий распознавать и блокировать ранее неизвестные вредоносные программы. 67 Единый инфраструктурный проект ГК «Ростех». Техническое задание Вынесение антивирусного сканирования и других ресурсоемких задач со всех гостевых машин на отдельную машину защиты. Автоматическое обнаружение и подключение к функционирующей машине защиты, в том числе находящейся на другом хосте, в случае недоступности основной машины защиты. Обеспечение непрерывности файловой защиты в период кратковременной недоступности машины защиты посредством журналирования всех файловых операций на защищаемой ВМ в период недоступности машины защиты, и выполнение автоматического сканирования всех изменений после восстановления доступа. Облачная защита от новых угроз, позволяющая приложению при сканировании в режиме реального времени и в режиме запланированной проверки обращаться к специальным ресурсам производителя, для получения вердикта по файлу. Защита электронной корреспонденции от вредоносных программ с проверкой трафика на следующих протоколах: IMAP, SMTP, POP3 — независимо от используемого почтового клиента. Защита веб-трафика — проверка объектов, поступающих на компьютер пользователя по протоколам HTTP, FTP, в том числе с помощью эвристического анализа, c возможностью настройки доверенных сайтов. Блокировка баннеров и всплывающих окон загружаемых с Web-страниц. Распознавание и блокировка фишинг-сайтов. Проверка трафика ICQ и MSN, для обеспечения безопасности работы с интернетпейджерами. Защита от еще не известных вредоносных программ на основе анализа их поведения. Возможность определения аномального поведения приложения с помощью анализа последовательности действий этого приложения. Возможность совершить откат действий вредоносного программного обеспечения при лечении. Возможность ограничения привилегий исполняемых программ таких как запись в реестр, доступ к файлам и папкам. Автоматическое определение уровней ограничения на основании репутации программы. Наличие встроенного сетевого экрана, позволяющего задавать сетевые пакетные правила для определенных протоколов (TCP, UDP) и портов. Создание сетевых правил для конкретных программ. Защита от хакерских атак с использованием межсетевого экрана с системой обнаружения и предотвращения вторжений (IDS/IPS) и правилами сетевой 68 Единый инфраструктурный проект ГК «Ростех». Техническое задание активности для наиболее популярных приложений при работе в вычислительных сетях любого типа, включая беспроводные. Наличие компонента, дающего возможность создания специальных правил, запрещающих установку и/или запуск программ. Компонент должен контролировать приложения как по пути нахождения программы, метаданным, контрольной сумме MD5, так и по заранее заданным категориям приложений, предоставляемым вендором, а также обеспечивать возможность исключения из правил для определенных пользователей из AD. Осуществление контроля работы пользователя с внешними устройствами ввода/вывода по типу устройства и/или используемой шине, с возможностью создания списка доверенных устройств по их идентификатору и возможностью предоставления привилегий для использования внешних устройств определенным пользователям из AD. Осуществление контроля работы пользователя с сетью Интернет, в том числе явный запрет или разрешение доступа к ресурсам определенного характера, а также возможность блокировки определенного типа информации (аудио, видео и др.). Программное средство должно позволять вводить временные интервалы контроля, а также назначать его только определенным пользователям из AD. Централизованные обновления с возможностью хранения части антивирусных баз на машине защиты. Запуск специальной задачи для обнаружения уязвимостей в приложениях, установленных на компьютере, с возможностью предоставления отчета по обнаруженным уязвимостям. Интеграция с системой обновления Windows Update для установки патчей, закрывающих обнаруженные уязвимости. Возможность удаленной установки и распространения компонентов антивирусного ПО на все защищаемые виртуальные машины без использования сторонних средств. Возможность проверки всех виртуальных машин по заранее заданному расписанию. Предотвращение повторного сканирования уже проверенных файлов. Наличие информации о проверенных файлах на машине защиты, позволяющей исключить повторную проверку одних и тех же файлов, находящихся на разных виртуальных машинах. Блокирование, обезвреживание и удаление вредоносного ПО, уведомление администраторов. Единая консоль управления для всех компонентов защиты. 69 Единый инфраструктурный проект ГК «Ростех». Техническое задание Консоль централизованного управления, единая для виртуальных сред и физических рабочих станций. Предоставление подробной информации о событиях на виртуальных машинах и о выполнении задач. Возможность применять различные параметры безопасности для отдельных групп виртуальных машин. Хранение резервных копий удаленных файлов. Поддержка отката антивирусных баз. Поддержка схемы лицензирования как по числу защищаемых виртуальных машин, так и по количеству ядер CPU аппаратного обеспечения. 4.7.4 Описание состава КСАЗ Архитектура решения предусматривает наличие трех основных компонентов: Одно программное средство администрирования на всю систему, виртуальная машина защиты для каждого хоста гипервизора, комплект агент администрирования и легкий агент защиты на каждую защищаемую гостевую систему. 4.7.5 Описание компонентов КСАЗ Легкий агент защиты обеспечивает формирование и передачу запроса на предоставление вердикта для файла виртуальной машине защиты. Так же легкий агент защиты является интерфейсом средства защиты для пользователя. Легкий агент защиты ответственен за выполнение не связанных с файловым анализом защитных процедур – проверка ссылок и веб содержимого, контроль рабочего места, сетевой экран и т.д. Агент администрирования выступает связующим звеном между легким агентом защиты и средством администрирования. Ответственен за сбор статистики о защищаемой гостевой системе (информация об установленном ПО, запускаемых объектах и т.д.), передачи команд управления со средства администрирования Средство администрирования КСАЗ позволяет модифицировать и назначать политики на подконтрольные гостевые ОС, агрегирует события и позволяет строить отчеты о работе КСАЗ. Виртуальная машина защиты – отдельно развернутая виртуальная машина на базе ОС Linux, которая осуществляет проверку объектов для всех гостевых ОС одного хоста гипервизора. 70 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.7.6 Требования к среде развертывания КСАЗ 4.7.6.1 Программные требования 4.7.6.1.1.1 Гипервизор: VMware ESXi 5.1 update 2; VMware ESXi 5.3; VMware ESXi 5.5; Windows Server 2008 R2 с серверной ролью Hyper-V; Windows Server 2008 R2 SP1 с серверной ролью Hyper-V; Windows Server 2012 с серверной ролью Hyper-V; Citrix XenServer 6.0.2; Citrix XenServer 6.1.0. 4.7.6.1.1.2 Требования к гостевой операционной системе гипервизора: Windows 7 Professional / Enterprise / Ultimate SP1 32-bit/64-bit; Windows 8 Pro / Enterprise 32-bit/64-bit; 4.7.6.2 Аппаратные требования 4.7.6.2.1.1 Требования к минимальному аппаратному обеспечению виртуальной машины защиты: Виртуализированный процессор с частотой 2 ГГц; 2 Гб выделенной оперативной памяти; 30 Гб выделенного свободного места на диске; Виртуализированный сетевой интерфейс с полосой пропускания 100 Мбит/сек. 4.7.6.2.1.2 Требования к минимальному аппаратному обеспечению защищаемой виртуальной машины: Виртуализованный процессор с частотой 1 ГГц (1.5 ГГц для серверных операционных систем). 1 Гб оперативной памяти для 32-разрядных операционных систем и 2 Гб – для 64разрядных. От 1.5 до 20 Гб выделенного свободного места на диске (в зависимости от версии операционной системы). Виртуализированный сетевой интерфейс с полосой пропускания 100 Мбит/сек. 71 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.8 Комплексная система защиты информации 4.8.1 Требования к системе 4.8.1.1 Общие требования Система защиты информации инфраструктурного проекта (далее - СЗИ ИнфПр) должна обеспечивать защиту информации от неправомерного или случайного доступа к ним, уничтожения, изменения, блокирования, копирования, предоставления, распространения, а также от иных неправомерных действий в отношении защищаемой информации. В состав СЗИ ИнфПр должны входить организационные и технические меры, обеспечивающие: -- идентификацию и аутентификацию субъектов доступа и объектов доступа; -- управление доступом субъектов доступа к объектам доступа; -- защиту машинных носителей информации; -- регистрацию событий безопасности; -- антивирусную защиту; -- обнаружение вторжений; -- контроль (анализ) защищенности; -- целостность информационной системы; -- защиту среды виртуализации; -- защиту технических средств; -- защиту передачи данных; в соответствии с: -- требованиями п. 8 Приказа ФСТЭК России от 18 февраля 2013 г. №21 «Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». 72 Единый инфраструктурный проект ГК «Ростех». Техническое задание Для построения СЗИ ИнфПр необходимо использовать средства защиты информации (далее – СЗИ), прошедшие процедуру оценки соответствия (сертификации) требованиям законодательства Российской Федерации в области обеспечения безопасности информации. 4.8.2 Требования по идентификации и аутентификации субъектов доступа и объектов доступа Применяемые для построения СЗИ ИнфПр организационные и технические меры должны обеспечивать: –Идентификацию и аутентификацию пользователей; –Управление идентификаторами, в том числе создание, присвоение, уничтожение идентификаторов; –Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации; –Защиту обратной связи при вводе аутентификационной информации; –Идентификация и аутентификация пользователей, не являющихся работниками оператора (внешних пользователей). 4.8.3 Требования по управлению доступом субъектов доступа к объектам доступа Применяемые для построения СЗИ ИнфПр организационные и технические меры должны обеспечивать: –Управление (заведение, активация, блокирование и уничтожение) учетными записями пользователей; –Реализацию дискреционного и ролевого правила разграничения доступа на чтение, запись, выполнение; –Управление (фильтрация, информационными маршрутизация, потоками между контроль устройствами, соединений) сегментами информационной системы, а также между информационными системами; –Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы; –Назначение минимально необходимых прав и привилегий пользователям, администраторам и лицам, обеспечивающим функционирование информационной системы; –Ограничение неуспешных попыток входа в информационную систему (доступа к информационной системе); 73 Единый инфраструктурный проект ГК «Ростех». Техническое задание –Блокирование сеанса доступа в информационную систему после установленного времени бездействия (неактивности) пользователя; –Разрешение (запрет) действий пользователей, разрешенных до идентификации и аутентификации; –Реализация защищенного удаленного доступа субъектов доступа к объектам доступа через внешние информационно-телекоммуникационные сети; –Управление взаимодействием с информационными системами сторонних организаций (внешние информационные системы). 4.8.4 Требования по защите машинных носителей информации Применяемые для построения СЗИ ИнфПр организационные и технические меры должны обеспечивать: –Уничтожение (стирание) или обезличивание информации на машинных носителях при их передаче между пользователями, в сторонние организации для ремонта или утилизации, а также контроль уничтожения (стирания) или обезличивания. 4.8.5 Требования по регистрации событий безопасности Применяемые для построения СЗИ ИнфПр организационные и технические меры должны обеспечивать: –Определение событий безопасности, подлежащих регистрации, и сроков их хранения; –Определение состава и содержания информации о событиях безопасности, подлежащих регистрации; –Сбор, запись и хранение информации о событиях безопасности в течение установленного времени хранения; –Защита информации о событиях безопасности. 4.8.6 Требования по антивирусной защите Применяемые для построения СЗИ ИнфПр организационные и технические меры должны обеспечивать: –Реализацию антивирусной защиты; –Обновление базы данных признаков вредоносных компьютерных программ (вирусов). 74 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.8.7 Требования по обнаружению вторжений Применяемые для построения СЗИ ИнфПр организационные и технические меры должны обеспечивать: –Обнаружение вторжений; –Обновление базы решающих правил и сигнатур атак. 4.8.8 Требования по контролю (анализу) защищенности Применяемые для построения СЗИ ИнфПр организационные и технические меры должны обеспечивать: –Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей; –Контроль установки обновлений программного обеспечения, включая обновление программного обеспечения средств защиты информации; –Контроль работоспособности, параметров настройки и правильности функционирования программного обеспечения и средств защиты информации; –Контроль состава технических средств, программного обеспечения и средств защиты информации. 4.8.9 Требования по обеспечению целостности Применяемые для построения СЗИ ИнфПр организационные и технические меры должны обеспечивать: –Возможность восстановления программного обеспечения, включая программное обеспечение средств защиты информации, при возникновении нештатных ситуаций. 4.8.10 Требования по защите среды виртуализации Применяемые для построения СЗИ ИнфПр организационные и технические меры должны обеспечивать: –Идентификацию и аутентификацию субъектов доступа и объектов доступа в виртуальной инфраструктуре, в том числе администраторов управления средствами виртуализации; –Управление доступом субъектов доступа к объектам доступа в виртуальной инфраструктуре, в том числе внутри виртуальных машин; –Регистрацию событий безопасности в виртуальной инфраструктуре; –Реализацию и управление антивирусной защитой в виртуальной инфраструктуре; 75 Единый инфраструктурный проект ГК «Ростех». Техническое задание –Разбиение виртуальной виртуальной инфраструктуры инфраструктуры) для на сегменты обработки (сегментирование информации отдельным пользователем и (или) группой пользователей. 4.8.11 Требования по защите технических средств Применяемые для построения СЗИ ИнфПр организационные и технические меры должны обеспечивать: –Контроль и управление физическим доступом к техническим средствам, средствам защиты информации, средствам обеспечения функционирования, а также в помещения и сооружения, в которых они установлены, исключающие несанкционированный физический доступ к средствам обработки информации, средствам защиты информации и средствам обеспечения функционирования информационной системы, в помещения и сооружения, в которых они установлены; –Размещение устройств вывода (отображения) информации, исключающее ее несанкционированный просмотр. 4.8.12 Требования по защите передачи данных Применяемые для построения СЗИ ИнфПр организационные и технические меры должны обеспечивать: –Обеспечение защиты информации от раскрытия, модификации и навязывания (ввода ложной информации) при ее передаче (подготовке к передаче) по каналам связи, имеющим выход за пределы контролируемой зоны. 4.8.13 Требования к численности и квалификации персонала системы и режиму его работы Обслуживающий персонал должен состоять из администраторов СЗИ ИнфПр – лиц, ответственных за функционирование СЗИ ИнфПр в установленном штатном режиме. Проектные решения по созданию СЗИ ИнфПр должны содержать (при необходимости) рекомендации к изменению численности, квалификации и функциям персонала, предложения по обучению обслуживающего персонала СЗИ ИнфПр с учетом существующей организационно-штатной структуры Заказчика и разграничения ролей по реализации политики безопасности и обслуживанию технических средств СЗИ ИнфПр. Обслуживающий персонал СЗИ ИнфПр должен осуществлять обслуживание и эксплуатацию СЗИ ИнфПр по рабочим дням в рабочее время с возможностью выхода в 76 Единый инфраструктурный проект ГК «Ростех». Техническое задание нерабочее время для проведения сервисного обслуживания или восстановления работоспособности СЗИ ИнфПр. 4.8.14 Показатели назначения Техническими и организационно-распорядительными мерами должна быть обеспечена безопасность информации при их обработке в СЗИ ИнфПр, а именно обеспечены конфиденциальность, целостность и доступность защищаемой информации. СЗИ создаваемой СЗИ ИнфПр должны обеспечивать возможное расширение круга защищаемых ресурсов, добавление или удаление объектов защиты. 4.8.15 Требования к надежности Надежность СЗИ ИнфПр должна быть обеспечена за счет ведения двух копий программных СЗИ, создания резервных копий настроек СЗИ, их периодического обновления и контроля работоспособности. 4.8.16 Требования безопасности При вводе в действие оборудования СЗИ ИнфПр с учетом требований стандартов безопасности труда должна быть обеспечена безопасность при монтаже, наладке, эксплуатации, обслуживании и ремонте оборудования СЗИ ИнфПр, включая защиту от воздействий электрического тока, электромагнитных полей, акустических шумов. Размещение оборудования СЗИ ИнфПр на штатных местах должно обеспечивать его безопасное обслуживание и эксплуатацию. 4.8.17 Требования к эргономике и технической эстетике Программно-аппаратные компоненты, внедряемые при создании СЗИ ИнфПр, не должны существенно нарушать удобство работы эксплуатирующего персонала. 4.8.18 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы Климатические условия эксплуатации компонентов СЗИ ИнфПр должны соответствовать требованиям эксплуатационной документации производителей СЗИ. Эксплуатация программно-технических средств должна предусматривать следующие виды технического обслуживания: -- оперативное обслуживание; -- профилактические работы. 77 Единый инфраструктурный проект ГК «Ростех». Техническое задание Оперативное обслуживание должно предусматривать ежедневный контроль функционирования аппаратно-технических средств, целостности информационных ресурсов. Оперативное обслуживание не должно нарушать выполнения функций СЗИ ИнфПр в целом. Профилактические работы должны включать в себя периодическую проверку и обслуживание технических средств СЗИ ИнфПр, для которых такое обслуживание и процедуры предусмотрены эксплуатационной документацией. Объем и порядок выполнения технического обслуживания технических и программных средств СЗИ ИнфПр должны определяться эксплуатационной документацией производителя на СЗИ. 4.8.19 Требования по сохранности информации при авариях Сохранность информации при авариях должна быть обеспечена СЗИ ИнфПр за счет резервного копирования обрабатываемой информации. При авариях должна быть обеспечена сохранность в СЗИ ИнфПр информации: -- о собранных событиях информационной безопасности; -- о настройках компонентов СЗИ ИнфПр. Для обеспечения сохранности информации при авариях разрабатываемый технический проект на создание СЗИ ИнфПр должен предусматривать средства восстановления, а также мероприятия по ведению двух копий программных СЗИ, их периодическому обновлению и контролю работоспособности. 4.8.20 Требования к защите от влияния внешних воздействий Требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения) для компонентов СЗИ ИнфПр не предъявляются. 4.8.21 Требования к патентной чистоте Технические решения по созданию СЗИ ИнфПр должны отвечать требованиям действующего российского законодательства об авторском праве и смежных правах по патентной чистоте. 78 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.8.22 Требования по стандартизации и унификации Должна обеспечиваться совместимость технических средств и программного обеспечения СЗИ ИнфПр с комплексом технических средств СЗИ ИнфПр. При создании СЗИ ИнфПр должны использоваться унифицированные, однотипные компоненты в целях снижения расходов на обслуживание и ремонт, обеспечения удобства эксплуатации. 4.8.23 Требования к видам обеспечения 4.8.23.1 Требования к программному обеспечению Дистрибутивное программное обеспечение СЗИ ИнфПр должно храниться на внешних носителях с инструкцией и программой инсталляции. Программные средства защиты и их компоненты, устанавливаемые на рабочие станции и серверы СЗИ ИнфПр, должны функционировать в среде используемых на них операционных систем. При выборе программных средств защиты предпочтение должно отдаваться готовым покупным программным продуктам. В процессе эксплуатации СЗИ ИнфПр лицензии на дополнительные функции программного обеспечения должны поддерживаться в актуальном состоянии, т. е. необходимо регулярное их обновление. Решения по использованию программных средств защиты должны приниматься с учетом обеспечения поддержки его функционирования производителем или поставщиком данного программного обеспечения. Предлагаемое к использованию программное обеспечение должно быть лицензировано фирмой-производителем или являться авторизованной копией, изготовленной установленным порядком. 4.8.23.2 Требования к техническому обеспечению Аппаратные компоненты СЗИ ИнфПр и автоматизированные рабочие места администраторов должны базироваться на аппаратных платформах, обеспечивающих функции диагностики, резервирования и взаимозаменяемости. 79 Единый инфраструктурный проект ГК «Ростех». Техническое задание При выборе и закупке аппаратных компонентов СЗИ ИнфПр должны быть предусмотрены мероприятия по их последующему гарантийному и техническому обслуживанию. Для серверных компонентов СЗИ ИнфПр должны быть предусмотрены решения, обеспечивающие возможность наращивания производительности и объема хранимой информации. 4.8.24 Функциональные требования Организационные и технические меры, описанные в п.п. 4.8.2– 4.8.12данного ТЗ должны быть реализованы посредством реализации следующих функциональных подсистем: -- подсистема защиты от несанкционированного доступа (далее ― НСД); -- подсистема антивирусной защиты; -- подсистема криптографической защиты информации; -- подсистема межсетевого экранирования; -- подсистема обнаружения вторжений; -- подсистема анализа защищенности. Все компоненты подсистем должны интегрироваться в существующую ИТинфраструктуру. 4.8.24.1 Требования к подсистеме защиты от НСД К подсистеме защиты от НСД предъявляются следующие требования: -- обеспечение защиты от несанкционированного входа в систему на защищаемых АРМ, серверах; -- обеспечение разграничения доступа пользователей к информационным ресурсам на основе избирательного разграничения доступа и замкнутой программной среды; -- обеспечение контроля и предотвращения несанкционированного изменения целостности защищаемых ресурсов; -- регистрация событий информационной безопасности в собственном журнале; -- обеспечение возможности просмотра сведений, произошедших на защищаемых АРМ, серверах; -- обеспечение возможности контроля вывода на печать конфиденциальной информации; -- обеспечение возможности доверенного удаления файлов без возможности последующего восстановления; 80 Единый инфраструктурный проект ГК «Ростех». Техническое задание -- обеспечение возможности управления доступом пользователей к защищаемым АРМ, серверам. Требования к подсистеме защиты среды виртуализации 4.8.24.2 К подсистеме защиты среды виртуализации предъявляются следующие требования: -- обеспечение аутентификации субъектов доступа к защищаемым ресурсам виртуальной инфраструктуры; -- обеспечение дискреционного разграничения доступа к средствам управления виртуальной инфраструктурой; -- обеспечение возможности ограничения полномочий администратора по управлению виртуальной инфраструктурой; -- обеспечение контроля действий администратора виртуальной инфраструктуры; -- обеспечение блокирования доступа через веб-интерфейс в защищаемый периметр; -- обеспечение возможности редактировать парольные политики; -- обеспечение полномочного управления доступом к защищаемым ресурсам виртуальной инфраструктуры; -- обеспечение возможности блокирования любого сетевого трафика со стороны виртуальных машин к средствам управления виртуальной инфраструктурой; -- обеспечение возможности фильтрации сетевого трафика к серверу управления виртуальной инфраструктурой внутри сети администрирования; -- обеспечение возможности контроля монтирования внешних устройств к хостам виртуальной инфраструктуры. 4.8.24.3 Требования к подсистеме антивирусной защиты К подсистеме антивирусной защиты предъявляются следующие требования: -- обеспечение защиты от воздействия вредоносного кода на защищаемые ресурсы; -- обеспечение возможности удалённой централизованной установки и удаления компонент подсистемы на защищаемых ресурсах; -- обеспечение возможности централизованного управления компонентами подсистемы; -- обеспечение возможности автоматического централизованного обновления антивирусных баз на защищаемых ресурсах; -- обеспечение возможности централизованного сбора статистических отчётов о работе компонент подсистемы, событий информационной безопасности; 81 Единый инфраструктурный проект ГК «Ростех». Техническое задание -- обеспечение возможности оповещения администратора информационной безопасности о критичных событиях. 4.8.24.4 Требования к подсистеме криптографической защиты информации К подсистеме криптографической защиты информации предъявляются следующие требования: -- обеспечение возможности шифрования/расшифрования информации, передаваемой за пределы контролируемой зоны, с использованием алгоритма шифрования ГОСТ 28147-97 с применением сертифицированных ФСБ России средств криптографической защиты информации; -- реализация технологий и поддержка постоянно действующих туннелей виртуальной частной вычислительной сети (VPN); -- обеспечение возможности проверки подлинности отправителя (удаленного пользователя) и целостности, передаваемых по информационно-телекоммуникационной сети международного информационного обмена (сети связи общего пользования) данных с использованием криптоалгоритмов; -- организация контролируемого и безопасного подключения внешних пользователей для защищенного обмена информацией, в том числе аутентификацию пользователей и сетевых объектов с использованием криптоалгоритмов. 4.8.24.5 Требования к подсистеме межсетевого экранирования К подсистеме межсетевого экранирования предъявляются следующие общие требования: -- сетевое сегментирование ИнфПр в целях локализации защищаемых информационных ресурсов по степени критичности и реализация механизмов контроля доступа между сегментами на сетевом уровне; -- разделение информационных взаимодействий между сегментами ИнфПр и внешними сетями общего пользования. Для выполнения общих требований подсистема межсетевого экранирования должна обеспечивать: -- фильтрацию пакетов на сетевом уровне на основе сетевых адресов отправителя и получателя; -- фильтрацию пакетов служебных протоколов, служащих для диагностики и управления работой сетевых устройств; -- фильтрацию пакетов с учетом входного и выходного сетевого интерфейса, как средство проверки подлинности сетевых адресов; -- регистрацию и учет фильтруемых пакетов; -- регистрацию сведений об установленных сессиях; 82 Единый инфраструктурный проект ГК «Ростех». Техническое задание -- трансляцию сетевых адресов; -- разграничение сетевых потоков с использованием виртуальных контекстов в рамках одного устройства или отдельных устройств; -- маршрутизацию пакетов между сегментами ИнфПр; -- маршрутизацию пакетов или NAT в сетевые сегменты ИнфПр из сетей общего пользования. 4.8.24.6 Требования к подсистеме обнаружения вторжений К подсистеме обнаружения вторжений предъявляются следующие требования: -- обеспечение возможности контроля сетевого трафика по произвольным протоколам стека TCP/IP; -- обеспечение возможности анализа протоколов туннелирования (IPinIP, GRE, IPv6-туннели); -- обеспечение защиты от направленных и распределенных атак с возможностями создания собственных правил; -- обеспечение возможности полноценного разбора и нормализации трафика для борьбы с техниками обхода; -- обеспечение возможности URL-фильтрации по категориям сайтов, с которыми работают пользователи; -- обеспечение возможности пользователям осуществлять доступ к просмотру журналов событий, отчетам, которые для них публикуют администраторы на специализированном веб-портале. 4.8.24.7 Требования к подсистеме анализа защищенности К подсистеме анализа защищенности предъявляются следующие требования: -- обеспечение возможности сбора информации о доступности узлов ИнфПр; -- обеспечение возможности обнаружения сетевых узлов, идентификации операционных систем и серверных приложений; -- обеспечение возможности выявления уязвимостей в сетевых службах и приложениях в режиме тестирования на проникновение; -- обеспечение возможности оценки защищенности баз данных; -- обеспечение возможности проверки безопасности операционной системы и приложений на защищаемых ресурсах; -- обеспечение возможности установления различных правил политик безопасности для различных сетевых узлов; -- обеспечение контроля учетных записей и групп пользователей баз данных и приложений, объектов баз данных. 83 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4.8.25 Источники разработки При разработке проектных решений СЗИ ИнфПр необходимо использовать подход и принципы обеспечения информационной безопасности, представленные в следующих документах: -- Федеральный закон Российской Федерации от 27 июля 2006 г. № 152-ФЗ «О персональных данных» (редакция от 25 июля 2011 г.); -- Постановление Правительства Российской Федерации от 1 ноября 2012 г. № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; -- «Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных», утверждены приказом ФСТЭК России от «18» февраля 2013 г. № 21; -- Методика определения актуальных угроз безопасности персональным данным при их обработке в информационных системах персональных данных, утверждена зам. директора ФСТЭК России 14 февраля 2008 г. -- Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных, утверждена зам. директора ФСТЭК России 15 февраля 2008 г. -- Методические рекомендации по обеспечению с помощью криптосредств безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств автоматизации, утверждены приказом ФСБ России от 21 февраля 2008 г. № 149/54-144. -- Типовые шифровальных требования по организации (криптографических) и средств, обеспечению функционирования предназначенных для защиты информации, не содержащей сведений, составляющих государственную тайну, в случае их использования для обеспечения безопасности персональных данных при их обработке в информационных системах персональных данных, утверждены руководством 8 Центра ФСБ России 21 февраля 2008 г. № 149/6/6-622. -- Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации, утверждено решением председателя Государственной технической комиссии при Президенте Российской Федерации от 30 марта 1992 г.; -- «Специальные требования и рекомендации по технической защите конфиденциальной информации (СТР-К)» (Приказ Гостехкомиссии России от 20.08.2002 г. № 282); 84 Единый инфраструктурный проект ГК «Ростех». Техническое задание -- ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем». 5 Порядок контроля и приёмки работ 5.1 Виды испытаний Проверка соответствия развёртываемых подсистем предъявляемым к ним требованиям осуществляется на стадии ввода подсистем в действие. В целях контроля и приёмки работ устанавливаются следующие виды испытаний: предварительные испытания; опытная эксплуатация; приёмочные испытания. 5.2 Предварительные испытания Предварительные испытания проводятся с целью проверки работоспособности развёртываемых подсистем и соответствия их характеристик требованиям Технического задания, а также возможности их приёмки в опытную эксплуатацию. Указанные испытания проводятся по окончании пуско-наладочных работ в соответствии с Программой и методикой предварительных испытаний. По результатам предварительных испытаний оформляются протокол соответствующих испытаний и акт их завершения. Акт завершения предварительных испытаний должен содержать заключение указанной комиссии о возможности начала опытной эксплуатации развёртываемых подсистем. При наличии у комиссии мотивированных замечаний, подлежащих устранению Исполнителем, данный акт должен содержать их перечень и сроки устранения. 5.3 Проведение опытной эксплуатации Опытная эксплуатация проводится с целью: определения фактических значений количественных и качественных показателей развёртываемых подсистем и их соответствия требованиям ТЗ; определения готовности персонала к работе в условиях функционирования развёртываемых подсистем; оценки возможности проведения приёмочных испытаний развёртываемых подсистем в постоянную эксплуатацию. 85 с целью ввода Единый инфраструктурный проект ГК «Ростех». Техническое задание По окончании опытной эксплуатации проводится анализ ее результатов и, при необходимости, доработка и/или дополнительная наладка системы, доработка эксплуатационной документации. По завершении указанных работ оформляется акт завершения опытной эксплуатации, который должен содержать заключение комиссии по проведению опытной эксплуатации о возможности предъявления БЛВС на приемочные испытания. 5.4 Приёмочные испытания Приемочные характеристик испытания проводятся развёртываемых с подсистем целью определения требованиям соответствия Технического задания, проверки устранения недостатков, выявленных на предварительных испытаниях и в процессе опытной эксплуатации, а также установления возможности приёмки подсистем в постоянную эксплуатацию. Указанные испытания проводятся в соответствии с Программой и методикой приёмочных испытаний. По результатам приёмочных испытаний оформляются протокол соответствующих испытаний и акт их завершения. Акт завершения приёмочных комплексных испытаний должен содержать заключение указанной комиссии о возможности начала постоянной эксплуатации развёртываемых подсистем. При наличии у комиссии мотивированных замечаний, подлежащих устранению Исполнителем, данный акт должен содержать их перечень и сроки устранения. 6 Требования к составу и содержанию работ по подготовке объекта информатизации к вводу в действие развёртываемых подсистем К мероприятиям, которые должен провести Заказчик по подготовке объекта информатизации к вводу в действие развёртываемых подсистем, относятся мероприятия по: подготовке помещений для установки оборудования; поставке необходимого оборудования и программного обеспечения в соответствии со Спецификацией, разрабатываемых в рамках проекта; формированию новой службы эксплуатации или реорганизации существующих служб (при необходимости) с комплектованием (доукомплектованием) требуемыми категориями должностей в требуемом количестве; обучению обслуживающего персонала работе с оборудованием и программным обеспечением на авторизованных учебных курсах; 86 Единый инфраструктурный проект ГК «Ростех». Техническое задание обеспечению персонала служб эксплуатации руководящими и инструктивными материалами, а также документацией на оборудование и ПО в требуемом количестве; 7 Требования к документированию Формат и содержание документации технического и рабочего проектирования должны соответствовать номенклатуре, приведенной в следующих: ГОСТ 34.003-90 «Информационная автоматизированные системы. технология. Комплекс Автоматизированные стандартов системы. Термины на и определения»; ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; ГОСТ 34.602-89 «Информационная автоматизированные системы. технология. Техническое Комплекс стандартов задание на Комплекс стандартов на создание автоматизированной системы»; ГОСТ 34.201-89 «Информационная технология. на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем»; РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; РД 50-34.126-92. «Информационная технология. Правила проведения работ при создании автоматизированных систем». Состав документации, которая должна быть разработана Исполнителем, с учётом разбиения по разным подсистемам, 87 приведён в таблице: Единый инфраструктурный проект ГК «Ростех». Техническое задание Инфраструк- Наименование документа тура VDI Система СОК Система СРК Инфраструк- Система Среда тура БЛВС MDM контроля ИТ Отдельный Концепция (код документа П1) Техническое задание документ (код документа ТЗ) Пояснительная записка (код документа П2) Ведомость покупных изделий (код документа ВП) Схема функциональной структуры (код документа С2) Схема структурная технических Отдельный Отдельный Отдельный Отдельный Отдельный Отдельный документ документ документ документ документ документ Раздел Раздел Раздел Раздел Раздел * Раздел Раздел Раздел Раздел Раздел Раздел Отдельный Отдельный лист лист Отдельный Отдельный лист лист Раздел Раздел Раздел * Общий лист Общий лист Общий лист * Раздел * Отдельный лист комплекса средств (код Отдельный лист документа С1) Описание комплекса технических средств (код документа П9) Чертёж установки технических средств (СА) Таблица соединений подключений (код документа С6) и * Раздел 88 * * Единый инфраструктурный проект ГК «Ростех». Техническое задание Наименование документа План развёртывания Инфраструктура VDI (код документа И2) Регламент резервного документа И3) Руководство пользователя (код документа И3) Программа и методика испытаний (код документа ПМ) Система СРК Инфраструк- Система Среда тура БЛВС MDM контроля ИТ Отдельный Отдельный документ документ Раздел Раздел Отдельный Отдельный Отдельный Отдельный Отдельный документ документ документ документ документ Отдельный Отдельный Отдельный документ документ документ Раздел Раздел копирования (код документа И2) Руководство администратора (код Система СОК Раздел Раздел Раздел Раздел * * * * * * - Для комплексной среды контроля ИТ разрабатывается отдельный пакет документов, приведённый в разделах 4.6.4.9, Error! Reference source not found. 89 Единый инфраструктурный проект ГК «Ростех». Техническое задание 8 Список сокращений IOPS Количество операций ввода/вывода в секунду (Input/Output Operations Per Second) KMS Служба управления ключами (Key Management Service) MDM Система управления мобильными устройствами SAN Сеть хранения данных VDI Инфраструктура виртуальных рабочих столов (Virtual Desktop Infrastructure) БЛВС Беспроводная локальная вычислительная сеть ВМ Виртуальная машина ГК Госкорпорация ГОСТ Государственный стандарт ИБП Источник бесперебойного питания ИТ Информационные технологии ЛВС Локальная вычислительная сеть ПАМ Подсистема агентов мониторинга; ПК Персональный компьютер ПМГЛС Подсистема мониторинга глобальных и локальных сетей ПМИ Программа и методика испытаний ПМО Подсистема моделирования объектов ПСО Подсистема создания отчётов; ПСС Подсистема сбора сообщений; ПФМ Подсистема функционального мониторинга СУАУИТ Система управления ИТ-активами и ИТ-услугами СМ Система мониторинга СРК Система резервного копирования СРМ Сервисно-ресурсная модель СХД Система хранения данных ТЗ Техническое задание ТК Тонкий клиент ЦА Центральный аппарат ЦОД Центр обработки данных 90 Единый инфраструктурный проект ГК «Ростех». Техническое задание 9 Спецификации оборудования и ПО В рамках реализации проекта используется серверное оборудование Huawei, либо любое другое оборудование со схожими характеристиками. № 1 1.1 1.1.1 Артикул 1.1.3 Описание Колво OceanStor S5800T V2 V200R002 S5800T S5800T Main Equipment File Engine 02359042 1.1.2 Модель S5B-FE-2N48G File Engine(2 Nodes,AC,48GB Cache,8*8G FC Back-End Port,SPE61C0200) 1 Cluster Heads Expanding Interface Module 0302G251 LPU4I1 4*1Gbps Ethernet I/O modules(Total 4 ports) 2 0302G265 LPU2I10 2*10Gbps Ethernet I/O modules(Total 2 ports) 2 Multi-Controller Expansion Components Controller Enclosure Unit 0 Controller Enclosure 02358541 S5800T-2C192G S5800T Controller Enclosure(4U,Dual Ctrl,AC,192GB Cache,Without I/O Port,HW Storage System Software,SPE61C0200) 1 Unit Expanding Interface Module 0302G367 LPU4TOE10 4*10Gbps TOE I/O Module(4 Ports) 2 0302G248 LPU4F8 4*8Gbps Fibre Channel I/O modules(Total 4 ports) 6 2*4*6Gb SAS I/O module 4 600GB 10K RPM SAS Disk Unit (2.5") 3000GB 7.2K RPM NL SAS Disk Unit(3.5") 96 24 HSSD eMLC 600GB SAS Disk Unit(3.5"),with HW HSSD Controller System Software 24 0302G247 LPU2S6 Disk Components 0235G6M9 SAS600-10K-2 0235G6SQ NLSAS3K-7.2K-3 0235G7RQ EMLC600-S-2 Disk Enclosure 1.2 1.3 1.3.1 1.3.2 1.3.3 0235G7KP DAE12425U2-01AC Disk Enclosure(2U,2.5",AC,SAS Expanding Module,without Disk Unit,with HW SAS In-Band Management Software,DAE12425U2) 4 0235G7KR DAE12435U4-01AC Disk Enclosure(4U,3.5",AC,SAS Expanding Module,without Disk Unit,with HW SAS In-Band Management Software,DAE12435U4) 2 Installation Material 14130321 SS-OP-D-LC-M-3 Patchcord,DLC/PC-DLC/PC,Multimode,2mm Parallel,3m 36 0405G004 mini-SAS-3 High Speed Cable,External Mini SAS Cable,3.0m,External Mini SAS 26 Pin Plug,28AWG*8P BLACK(S),External Mini SAS 26 Pin Plug,Key2,4,6 1 HyperSnap Function 1 HyperCopy Function 1 System Software HyperSnap License LIC-S5800T8803G0LJ SNAP-1 HyperCopy License LIC-S5800T8803G0LK COPY-1 HyperClone License 91 Единый инфраструктурный проект ГК «Ростех». Техническое задание LIC-S5800THyperClone Function CLONE-1 HyperReplication License LIC-S5800T8803G0LM HyperReplication Function REP-1 SmartThin License LIC-S5800T8803G0LQ SmartThin THIN-1 SmartTier License LIC-S5800T8803G0LS SmartTier TIER-1 SmartMotion License LIC-S5800T8803G0LT SmartMotion MOTION-1 SmartQos License LIC-S5800T8803G0LU SmartQos QOS-1 SmartPartition License LIC-S5800T88032EYB SmartPartition PART OceanStor HW UltraPath Software License 8803G0LL 1.3.4 1.3.5 1.3.6 1.3.7 1.3.8 1.3.9 1.3.10 88032GHW 1.3.11 1.3.13 1.3.14 2 2.1 1 1 1 1 1 Device Management License for OceanStor Unified S5800T 1 2 2 2 BC1M07CPU RH2288 V3 (8HDD Passthrough Chassis) H22H-03 4 SM210 4*GE Interface Card-PCIE 1.0 X4 8056 Fan module 2U 3*8X Riser Card Module 460W AC Power Module 4 16 4 8 X86 series,2400MHz,1.8V,64bit,85000mW,Haswell EP Xeon E52620 v3,6Core,with heatsink 8 Memory Module,DDR4 RDIMM,16GB,288pin,0.9ns,2133000KHz,1.2V,ECC,2Rank(1G*4bit) 8 Hard Disk-600GB-SAS 6.0Gb/s-10000rpm,2.5"-16MB or above-Hotswap-Built-in-Front Panel 20 DDR4 Memory N00DDR401 Hard Disk(include Front Panel) 02310YCR 2.5 BC1M02HGSA 02310YKC BC1M01FGEA 02310YKN BC1M02FANA 02310YKQ BC1M3S8XV3 02130957 WEPW80013 Haswell EP CPU 06200176 2.4 1 LYNC RH2288 V3 Base Configuration 02311CDN 2.3 S58-ISM1-UNIFY File Engine CIFS License 88032KBJ FE-S5B-CIFS-LC File Engine CIFS License File Engine NFS License 88032KBL FE-S5B-NFS-LC File Engine NFS License File Engine Load Balance License 88032KBP FE-S5B-LF-LC File Engine Load Balance License 02310YJA 2.2 OceanStor HW UltraPath Software License 1 Device Management License for OceanStor Unified S5800T 88032JYR 1.3.12 LIC-UltraPath 1 N600S10W2 RAID Card and Other Accessories 02310YME BC1M03ESMQ SR430C-Board ID 0X24,RAID0,1,5,6,10,50,60,1GB Cache(LSI3108)-Support SuperCap+850mm MiniSAS HD Cable Moudle(8_10 HDD CHASSIS) 92 4 Единый инфраструктурный проект ГК «Ростех». Техническое задание 02310YMJ 2.6 3 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.2 3.3 BC1M01TFM LSI Flash Card-4GB,TFM,Supercap and 620mm Cable Moudle Cables and Optional Equipments 21240434 EGUIDER01 2U Static Rail Kit 4 4 OceanStor VTL6900 V100R005 VTL6900 Main Equipment Basic Configuration 0235G779 STFZ01HAE01 VTL6900 HA Engine(AC,2*8Gb FC+4*1Gb iSCSI Host Interface,with HW Storage Node Baseboard Management Software,SPE31M0114) 2 0235G77N STFZ01SIR04 VTL6900 SIR Engine(AC,with 70TB Dedupe Capacity,with HW Storage Node Baseboard Management Software,SPE31M0114) 3 0235G7QC STFZ02SUC VTL6900 Base Storage Unit(AC,4*4TB 7.2K NL SAS Coffer Disks,HW Storage Array Control System Software,SPE31C0212) 1 0235G7QD STFZ01EXUD VTL6900 Expansion Storage Unit(AC,without Disks,with HW SAS in Band Management Software,DAE12435U4) 2 4000GB 7.2K RPM NL SAS Disk Unit(3.5") 48 Storage Unit 02358236 VTLSAS4T Switch & Accessories 02352360 S5700-24TP-SIAC S5700-24TP-SI-AC(24 Ethernet 10/100/1000 ports,4 of which are dual-purpose 10/100/1000 or SFP,AC 110/220V) 1 02357648 SN2Z01FCSP OceanStor SNS2124 FC Switch,24 Ports(8 ports activated,with 8*8Gb Multimode SFPs),Single PS(AC) 1 06230629 SN2F01FCPU Fiber Switch,BROCADE,Port On Demand,8-Port Activate(with 8*8Gb Multimode SFPs),for SNS2124 2 License Package 0223G4GR LSTFVTL10F Engine Software With 2 FC Target Ports And 4 ISCSI PortsLicense,10TB Usable Capacity License,No Dedupe 2 0223G4H2 LSTFVTLFINL HA Function License-Inline Dedupe Option 2 0223G4H4 LSTFVTLFHA HA Function License-High Availability Option 2 0223G4HC LSTFSIR0 SIR Engine Software With 8 FC Target Ports And 4 ISCSI Ports License 3 0223G4HD LSTFSIRE5 SIR Expansion License-5TB Dedupe Usable Capacity 2 0223G4HE LSTFSIRE10 SIR Expansion License-10TB Dedupe Usable Capacity 8 Auxiliary Equipment 06310026 NLCPCIE01 NIC,10 Gigabit Ethernet Server Adapter,LC Fiber Optic,Dual Port,PCIE 2.0 X8-8086-10FB-2, Without Driver CD 2 06230618 SN2R01FCRK FC Switch,Rack Mount Kit,for SNS2124/SNS3096 1 Patchcord,DLC/PC-DLC/PC,Multimode,2mm Parallel,3m 22 Installation Material 14130321 SS-OP-D-LC-M-3 93 Единый инфраструктурный проект ГК «Ростех». Техническое задание 4 4.1 4.1.1 VSPHERE E9000 Blade Basic Configuration Blade MotherBoard 4.1.2 03056132 IT11SGCA05 Haswell EP CPU 41020487 4.1.3 4.1.5 4.1.6 5.3 5.3.1 03021FTX BC0MESMCE600 6 Memory Module,DDR4 RDIMM,16GB,288pin,0.9ns,2133000KHz,1.2V,ECC,2Rank(1G*4bit) 48 6 RU120 SAS/SATA RAID Card,RAID0,1,10,1E,0 Cache(LSI2308) 3 MZ910,2*10GE,2*8G FC Port Mezzanine Card,PCIE 3.0 X8 3 OSCA-H 12U high-powered integrative module 1 MM910,Shelf Management Module A OSCA Fan Box 3000W platinum AC power supply unit 2 14 6 Network Mezz Card IT1DMXEA0000 E9000 Chassis E9000 Chassis Basic Configuration IT1K01E9000H 03054675 IT1DSMMA0000 03030QEJ IT0E01FAN000 02310LKL IT1MPOWERM00 Switch Module 03055569 IT11XCUA02 CX912,16*10GE Optical Port,8*8G FC Port,Multi-Plane Switch Module 2 05330493 BC0LICENSE01 FCSwitch-Brocade-Full Fabric License 2 05330492 BC0LICENSE02 FCSwitch-Brocade-ISL Trunking License License 2 Optical Transceiver & SFP+ Cable Electrical interface Optical Transceiver SFP-RJ45 Optical functional module,1000BASE-T -SFP RJ45Electrical Module,Auto Negotiate,100m ,-40~85degC 8 Optical transceiver-SFP+-850nm-8.5Gbps--8dBm--1.3dBm-11.2dBm-LC-MM-0.15km 8 Multi-Mode Optical Transceiver 02311ASE 5.4 6 HardDisk-300GB-SAS-10000rpm-2.5"-16M-Hot-Swappable-Built-InFront Panel RAID Card and Other Accessories N300S10W2 02310VEN 5.3.2 N00DDR401 02310YCM 02300742 5.2 X86 series,FCLGA2011,2500MHz,1.8V,64bit,120000mW,Haswell EP Xeon E5-2680 v3,12Core,IT Product Dedicated Hard Disk(include Front Panel) 03021SHM 5 5.1 3 DDR4 Memory 06200176 4.1.4 EHSE52680 Grantley EP Compute Node,CH121 V3 SFP-8.5G-LCMM Optical transceiver,SFP+,850nm,10Gb/s,-7.3~-1dBm,-9.9dBm,LC, MM,0.3km Cables and Optional Equipments 02310VEF SFP-10G-LCMM 04050185 C0CC2P000 High Speed Cable,Passive SFP+ Cable,3.0m,SFP+20M,CC2P0.254B,SFP+20M,LSFRZH For Indoor 8 21240817 EGUIDER05 4U Static Rail Kit 1 06020088 NDVDRWU00 DVDRW-CD 24X/DVD 8X,USB2.0,External,USB 2.0 5V power, 1 HORIZON VIEW E9000 94 8 Единый инфраструктурный проект ГК «Ростех». Техническое задание 6.1 6.1.1 Blade Basic Configuration Blade MotherBoard 6.1.2 03056132 IT11SGCA05 Haswell EP CPU 41020487 6.1.3 6.1.5 6.1.6 8 X86 series,FCLGA2011,2500MHz,1.8V,64bit,120000mW,Haswell EP Xeon E5-2680 v3,12Core,IT Product Dedicated 16 Memory Module,DDR4 RDIMM,16GB,288pin,0.9ns,2133000KHz,1.2V,ECC,2Rank(1G*4bit) 80 DDR4 Memory 06200176 6.1.4 EHSE52680 Grantley EP Compute Node,CH121 V3 N00DDR401 Hard Disk(include Front Panel) HardDisk-300GB-SAS-10000rpm-2.5"-16M-Hot-Swappable-Built-InFront Panel RAID Card and Other Accessories 02310YCM N300S10W2 03021FTX BC0MESMCE600 16 RU120 SAS/SATA RAID Card,RAID0,1,10,1E,0 Cache(LSI2308) 8 MZ910,2*10GE,2*8G FC Port Mezzanine Card,PCIE 3.0 X8 8 Network Mezz Card 03021SHM IT1DMXEA0000 В качестве сетевого оборудования используется оборудование Alcatel, либо любое другое оборудование совместимое с оборудованием Заказчика. Артикул Описание Колво OS9702E-RCBA OS9702E Redundant Bundle (Dual CMMs) for AC power, w/SSL (DES,3DES,RC2,RC4). AC redundant chassis bundle includes 1 OS9702CHASSIS, 3 OS9-PS-0725A, 2 OS9702E-CMM and its AOS software w/ advanced IP routing SW (IPv4/IPv6), In-Service-SW-Upgrade & advanced security SW (802.1x). Requires E-series modules. 2 OS9-GNI-C24E 24-10/100/1000BaseT/TX RJ45 ports. Gigabit Ethernet network interface with RJ45 connectors supports 10/100/1000 Mbps transmission speed. Supports Cat5 or Cat5e UTP Cabling. (Requires minimum of 4 pairs to support 1000BaseTX). Requires E-series CMMs 6 OS9-GNI-U24E 24-unpopulated 1000BaseX ports. Gigabit Ethernet network interface with MiniGBIC (SFP MSA) connectors supports 24 MiniGBIC transceivers. MiniGBIC transceivers not included - See Transceiver section for additional ordering information. Requires E-series CMMs 6 OS6850E-48: Gigabit Ethernet L3 fixed configuration chassis in a 1U form factor with 44 RJ-45 10/100/1000 BaseT ports, 4 combo ports (10/100/1000 BaseT or 1000 BaseX), and 2 CX-4 ports. The 2 CX-4 ports can be used as stacking ports or as connectors for the OS6-XNI-U2 that supports 2 SFP+ 10GigE ports. The bundle includes a 126W AC power supply with power shelf and country specific power cord,user manuals access card, rack mounts, and RJ-45 to DB-9 adaptor. 7 OS6850E48 95 Единый инфраструктурный проект ГК «Ростех». Техническое задание OS6850EU24X OS6850E-BP OS6850-CBL-60 OS6850E-U24X: Gigabit Ethernet L3 fixed configuration chassis in a 1U form factor with 22 SFP GigE ports, 2 combo ports (10/100/1000 BaseT or 1000 BaseX), 2 SFP+ 10GigE ports, and 2 CX-4 ports. The 2 CX-4 ports can be used as stacking ports or as connectors for the OS6-XNI-U2 that supports 2 SFP+ 10GigE ports. The bundle includes a 126W AC power supply with power shelf and country specific power cord, user manuals access card, rack mounts and RJ-45 to DB-9 adaptor. 3 OS6850E-BP modular 126W AC backup power supply. Provides backup power to one non-PoE switch. Ships with chassis connection cable and country specific power cord. 10 OS6850 60 centimeters long stacking cable. 8 SFP-GIG-SX 1000Base-SX MiniGBIC Transceiver(SFP MSA) Supports MM fiber over 850nm wavelength w/ LC connector. Supports 62.5 micron MM fiber up to 300 meters. SFP-10G-SR 10GBase-SR SFP+ Optical Transceiver, 850nm 300m 8 OS9-XNI-U2E Network interface card, includes 2 unpopulated BaseX ports. 10 Gigabit network interface with XFP supports 2 XFP transceivers 4 OS6850 Advanced routing software license. 10 OS6850E-SW-AR 144 В проекте используется программное обеспечение VMWare, либо любое другое, имеющее схожий функционал Комментарий Колво VMware Horizon Enterprise Edition: 100 Pack (Named Users) Includes Horizon View Manager, Mirage, Virtual SAN, Workspace Portal, Application Remoting, ThinApp, vCenter Operations Manager for Horizon, vSphere Desktop, and vCenter Server Desktop for 100 named users. SnS Required & Sold Separately. 7 Production Support/Subscription for VMware Horizon Enterprise Edition: 100 Pack (Named Users) for 3 years Technical Support, 24 Hour Sev 1 Support -- 7 days a week. 7 Артикул License HZ-ENTN100-C SnS HZ-ENTN100-3PSSS-C Описание Беспроводная сеть должна быть выполнена на базе оборудования Aruba, либо любом другом, имеющим схожие характеристики и удовлетворяющее текущим требованиям Артикул Описание Код Колво 7030-RW Aruba 7030, 8x10/100/1000BASE-T or 8x1GBASE-X SFP dual personality ports, MC 1 SW- 1 Supports up to 64 AP and 4K clients. Integrated AC power supply. This SKU is a rest-of-world product and should not be deployed in the United States. LIC-16-AP Access Point License (16 Access Point License) AOS LIC-32-AP Access Point License (32 Access Point License) SW- 1 AOS LIC-RFP-16 RF Protect License including WIP and Spectrum (16 AP Support) SW- 1 AOS LIC-RFP-32 RF Protect License including WIP and Spectrum (32 AP Support) 96 SW- 1 Единый инфраструктурный проект ГК «Ростех». Техническое задание AOS SFP-SX 1000BASE-SX SFP; 850nm pluggable GbE optic; LC connector; up to 270 meters OT 2 AP 20 OT 20 MAS 2 MAS 2 over multi-mode fiber (Type FDDI/OM1) and up to 550 meters over multi-mode fiber (Type OM2) Точки доступа AP-103 Aruba AP-103 Wireless Access Point, 802.11n, 2x2:2, dual radio, integrated antennas AP-220-MNT- Aruba Access W1 Contains 1x Point flat Mount Kit surface (basic, wall/ceiling flat surface). mount bracket. Color: black Коммутаторы S1500-24P 1500-24P Mobility Access Switch with 24 10/100/1000BASE-T IEEE 802.3af PoE/802.3at PoE+ ports plus 4 GbE SFP (optics ordered separately). Integrated AC power supply. Power cord not included- order country-specific (PC-AC-xx) power cord below. For deployments worldwide (check regulatory status). S1500-12P S1500-12P Mobility Access Switch with 12 10/100/1000BASE-T (8 support IEEE 802.3af PoE/802.3at PoE+) ports plus 2 GbE SFP (optics ordered separately). Integrated AC power supply. Power cord not included- order country-specific (PCAC-xx) power cord below. For deployments worldwide (check regulatory status). Сервисные контракты SN1-AP-103 NBD SUPPORT FOR AP-103 (1 YEAR) SP 20 SN1-7030-RW NBD SUPPORT FOR 7030-RW (1 YEAR) SP 1 SN1-LIC-16- SUPPORT FOR LIC-16-AP (1 YEAR) SP 1 SUPPORT FOR LIC-32-AP (1 YEAR) SP 1 SUPPORT FOR LIC-RFP-32 (1 YEAR) SP 1 SUPPORT FOR LIC-RFP-16 (1 YEAR) SP 1 NBD SUPPORT FOR S1500-12P (1 YEAR) SP 2 NBD SUPPORT FOR S1500-24P (1 YEAR) SP 2 AP SN1-LIC-32AP SN1-LIC-RFP32 SN1-LIC-RFP16 SN1-S150012P SN1-S150024P В проекте используются лицензии Майкрософт Артикул Наименование Кол-во P73-06283 WinSvrStd 2012R2 RUS OLP NL 2Proc 7 5HU-00252 LyncSvr 2013 RUS OLP NL 2 6ZH-00605 LyncSvrStdCAL 2013 RUS OLP NL UsrCAL 650 7AH-00602 LyncSVrEnCAL 2013 RUS OLP NL UsrCAL 200 YEG-01185 LyncSvrPlusCAL 2013 RUS OLP NL UsrCAL 650 79P-04747 OfficeProPlus 2013 RUS OLP NL 650 FQC-08188 WinPro 8.1 RUS Upgrd OLP NL 600 97 Единый инфраструктурный проект ГК «Ростех». Техническое задание T9L-00242 SysCtrStd RUS LicSAPk OLP NL 2Proc Qlfd 7 7NQ-00271 SQLSvrStdCore RUS LicSAPk OLP 2Lic NL CoreLic Qlfd 2 В проекте используются лицензии Kaspersky Артикул Наименование Кол-во KL4151RAUFS Kaspersky Security для виртуальных сред, 500-999 VirtualWorkstation 1 year Base License 1 В проекте используются абонентские мобильные терминалы YotaPhone 2 с предустановленным сертифицированными средствами криптографической защиты информации ViPNet и IP-телефонии или любые другие, имеющие схожий функционал и отвечающие требованиям данного ТЗ: Артикул Наименование Кол-во YotaPhone 2 В проекте используется 400 система управления мобильными устройствами SafePhone или любая другая, имеющая схожий функционал. В проекте используется система защиты и контроля файловых систем Whitebox Security WhiteOps или любая другая, имеющая схожий функционал. В проекте используется система защиты от несанкционированного доступа для виртуальной среды Код Безопасности vGate или любая другая, имеющая схожий функционал. В проекте используется система сбора и управление событиями информационной безопасности АйТи (SecurityVision) или любая другая, имеющая схожий функционал. В проекте используется система управления уязвимостями и рисками MaxPatrol или любая другая, имеющая схожий функционал. 98