«Мониторинг скорости открытия Top-100 сайтов России» Настоящий информационный запрос не является извещением о закупке. По итогам проведенного запроса информации пао мтс не несет обязательств по заключению договора ни с одной из Компаний, направивших ответ. Цель проекта

1. 
   Система должна быть централизованной – система установлена в одном регионе и из нее возможно выполнение тестирования с помощью удалённых по регионам пробников.
   
2. 
   Система должна корректно поддерживать работу с часовыми поясами.
   
3. 
   Измерение скорости открытия списка веб-страниц (ТОП-100 сайтов) в сети LTE по событию «page load» в браузере (все элементы страницы прогружены полностью). Периодичность измерений – каждые 60 минут (параметр доступный для редактирования вручную). Нормативное время загрузки страницы – 8 сек (параметр доступный для редактирования вручную).
   
4. 
   Замеры производятся:
   

• 
  на сети LTE операторов МТС, Мегафон, Билайн и Теле2.
  
• 
  на транспортной сети МТС (для сравнения)
  

5. 
   Система должна поддерживать эмуляцию устройств и ОС. Типы эмулируемых устройств: телефоны, планшеты, ПК на ОС iOS, Android, Windows (всего 5 шт.: 2 iOS, 2 Android, 1 Windows) (например, по технологии Selenium).
   
6. 
   Список ТОП-100 сайтов обновляется динамически (например, с сайта Alexa.com). При этом обновление списка возможно и вручную.
   
7. 
   Необходима интеграция с системой биллинга Foris для подготовки номера (смена тп, добавление/удаление услуг) непосредственно перед началом измерения скорости.
   
8. 
   Все замеры должны собираться в отчет, доступный для просмотра в интерфейсе системы, а также необходима возможность автоматической отправки на e-mail.
   
9. 
   Каждые 15 минут система должна проверять результаты замеров из отчета, при обнаружении факта загрузки более установленного порога, система формирует ALARM в адрес ответственных лиц (список ответственных лиц для отправки ALARM доступен для изменения).
   
10. 
    Система должна иметь возможность разграничения доступа к отчётам.
    
11. 
    Система через графический интерфейс пользователя должна позволять создавать кубы и витрины данных по любым доступным полям.
    
12. 
    Публикуемые отчёты должны быть доступны через графический интерфейс системы и высылаться по электронной почте.
    
13. 
    Система должна быть готова для интеграции с другими информационными системам (такими, как Remedy, Billing Foris OSS и т.п.) для возможности создания автоматизированных заявок об ошибках на основании сформированных ALARM'ов и др.
    
14. 
    Система должна использовать русский язык для пользовательских интерфейсов.
    
15. 
    Система не должна иметь программно-архитектурных ограничений по производительности: максимальная нагрузка может быть увеличена путем горизонтальной масштабируемости (увеличения ресурсов КТС).
    
16. 
    Требуется хранить в оперативной доступности историю по произведенным операциям за 6 месяцев.
    

1. 
   Система должна представлять собой центральный экземпляр, к которому обеспечен доступ пользователей от всех подразделений Заказчика. В каждом из 15 регионов должен присутствовать пробник, осуществляющий тестирование (Москва, Санкт-Петербург, Екатеринбург, Новосибирск, Самара, Хабаровск, Красноярск, Владивосток, Нижний Новгород, Уфа, Казань, Ростов-на-Дону, Краснодар, Иркутск, Норильск).
   
2. 
   Система должна позволять осуществлять тестирование для всех регионов одновременно.
   

1. 
   Необходимо обеспечить возможность эксплуатационного мониторинга в режиме 8/5 бизнес-метрик
   
2. 
   Для контроля за выделенными в разделе метриками, в процессе проектирования технического решения необходимо предусмотреть инструменты мониторинга метрик.
   
3. 
   Программное обеспечение должно обеспечивать обнаружение и диагностику ошибок с выдачей соответствующих сообщений администратору через лог запись.
   
4. 
   При сбое в работе функционала в логи систем, участвующих в процессе, должна попасть информация о всем пути выполнения операции, приведшей к сбою.
   

1. 
   Решение должно отвечать требованиям по патентной чистоте согласно действующему законодательству и распорядительным документам, регламентирующим создание информационных систем
   
2. 
   При создании Системы должны использоваться лицензионные программные продукты
   
3. 
   Порядок и условия лицензирования определяются условиями лицензионных соглашений с производителями программных продуктов
   
4. 
   Установка Системы в целом, как и установка отдельных частей Системы не должна предъявлять дополнительных требований к покупке лицензий на программное обеспечение сторонних производителей при его развёртывании на аппаратном обеспечении Заказчика
   
5. 
   В случае использования собственных разработок необходимо указывать наличие документальных свидетельств на владение интеллектуальной собственностью и авторскими правами.
   
6. 
   Поставщик должен подтвердить, что Решение не содержит или не выполняет функции специальных технических средств.
   
7. 
   Поставщик должен подтвердить, что Решение и его компоненты не попадают под ограничения на экспорт в Российскую Федерацию.
   

1. 
   Поставщик должен обеспечить, чтобы Решение соответствовало стандарту ПАО МТС СТ-027.
   
2. 
   Внедряемая система должна выполнять требования законодательства РФ и подзаконных актов в части защиты персональных данных, тайны связи и других видов тайн. В частности:
   

• 
  При реализации требований необходимо исключить доступ третьих лиц - не работников оператора связи к сведениям составляющим тайну связи абонентов."
  
• 
  Доступ третьих лиц к ПДн и сведениям об абонентах может быть только при наличии согласия абонентов или иного правового основания.
  
• 
  Внедряемая система должна защищать сведения ограниченного доступа согласно ПТ-002.
  

3. 
   Внедряемая система должна поддерживать интеграцию с имеющимися в МТС системами ИБ, и не вводить новые системы ИБ дублирующие функционал имеющихся.
   
4. 
   Внедряемая система должна:
   

• 
  находиться на территории РФ,
  
• 
  принадлежать ПАО “МТС”,
  
• 
  находиться в сети ПАО “МТС”,
  
• 
  эксплуатироваться сотрудниками ПАО “МТС”.\
  

5. 
   При разработке Решения должен использоваться статический анализ кода (Static Code Analysis) для автоматической проверки качества и безопасности кода.
   
6. 
   Поставщик должен указать какие средства используются для проведения анализа исходного кода Решения
   
7. 
   Поставщик должен подписывать программное обеспечение и его компоненты с использованием сертификатов открытых ключей
   
8. 
   При инсталляции программного обеспечения должна проверяться целостность и аутентичность инсталлятора
   
9. 
   При запуске программного обеспечения должна проверяться его целостность и аутентичность
   
10. 
    Программное обеспечение Решения не должно содержать средств разработки и отладки
    
11. 
    Поставщик должен перечислить все стороннее программное обеспечение и его версии, которое используется в Решении
    
12. 
    Решение не должно содержать недекларируемых возможностей. Например, функционала, подпадающего под категорию "специальные технические средства", функционала нелегального сбора данных об абонентах и предоставления их третьим лицам и т.д.
    
13. 
    При обнаружении уязвимостей в ПО Решения Поставщик обязан:
    

• 
  Незамедлительно информировать об этом Заказчика, если уязвимость является критической
  
• 
  В течении не более 1 месяца выпустить security patch для уязвимости
  
• 
  В течении не более 1 месяца установить security patch на всех экземплярах Решения у Заказчика
  

14. 
    Поставщик должен разработать для Решения следующие документы:
    

• 
  Высокоуровневый дизайн (HLD) по интеграции в IP сеть
  
• 
  Низкоуровневый дизайн (LLD) по интеграции в IP сеть
  
• 
  IP план для решения
  
• 
  Таблицу информационных потоков для Решения
  

15. 
    При интеграции Решения в IP сеть должны выполняться следующие требования:
    

16. 
    Поставщик должен предоставить Заказчику документ, описывающий настройки для межсетевого экранирования для Решения
    
17. 
    Поставщик должен предоставить расчеты трафика для Решения в табличной форме для всех информационных потоков (в packet per second или Gbps со средним размером пакета)
    
18. 
    Запрещается установка и запуск на Решение сервисов, обеспечивающих сервисные функции сети передачи данных (DHCP, DNS, все виды Proxy, NTP, SNMP relay, Routing и тп)
    
19. 
    Компоненты Решения не должны получать обновления напрямую из недоверенных сетей, типа Internet
    
20. 
    Система управления Решением должна располагаться во внутренней сети Заказчика
    
21. 
    Решение должно интегрироваться с системой сбора и обработки журналов событий (ArcSight ESM, ArcSight Logger) в части действий пользователей в решении
    
22. 
    Решение должно быть интегрирована с IDM в части управления учетными записями и правами пользователей в системе или основываться принадлежности к группе в AD
    
23. 
    Решение должно интегрироваться c WebSSO при использовании web доступа
    
24. 
    Участник должен составить таблицу информационных потоков для настройки правил экранирования на МСЭ (firewalls)
    
25. 
    При размещении системы в виртуальной инфраструктуре должна поддерживаться микросегментация сети
    
26. 
    Решение должно допускать периодическое сканирование, для выявления уязвимостей (MaxPatrol), без снижения производительности или отказов
    
27. 
    Поставщик должен обеспечить возможность сканирования Решения (penetration test) Заказчиком для выявления уязвимостей на этапе приемосдаточных испытаний. Тестирование включает, как минимум: port scanning, vulnerability testing (including robustness and DoS testing), traffic flooding/Distributed Denial of Service (DDoS) tests
    
28. 
    При необходимости использования сертификатов открытых ключей Решение должно быть интегрировано с PKI Заказчика
    
29. 
    При необходимости выработки долговременных ключей для Решения должна поддерживаться выработка и загрузка ключевого материала Заказчиком
    
30. 
    При использовании Решением технологии NFV управление решением должно поддерживать использование HyTrust как прокси при доступе к vCenter и другим компонентам инфраструктуры VMWare
    
31. 
    При использовании Web Services работающих с недоверенными сетями, в системе должен использоваться WAF (web application firewall)
    
32. 
    При использовании TLS на WebGUI должен использоваться TLS-Offload. Допускается совмещение функционала TLS Offload с WAF или замещение yf WebGate Oracle Access Manager
    
33. 
    Поставщик должен предоставить концепцию или high-level design обеспечения ИБ Решения, которое должно предоставлять информацию о том, как обеспечивается ИБ:
    

34. 
    Поставщик должен представить инструменты для автоматизированного контроля настроек, относящихся к ИБ и документацию по их использованию
    
35. 
    Инструменты для автоматизированного контроля настроек, относящихся к ИБ, должны входить в ценовое предложение
    
36. 
    Поставщик должен представить в составе эксплуатационной документации руководство по приведению Решения в защищенное состояние. Требование касается не только сетевых элементов, но и систем управления Решением
    
37. 
    В Решении должно использоваться только up-to-date версии программного обеспечения
    
38. 
    В Решении должны быть удалены все сервисы, которые не требуются
    
39. 
    Все доступные сервисы должны быть документированы.
    
40. 
    В Решении должны быть удалены все учетные записи, которые не требуются. Полный перечень всех учетных записей (локальных и удаленных) должен быть документирован.
    
41. 
    В Решении должны быть удалены все программные пакеты (software packages), которые не требуются, особенно если они могут быть использованы для атак из недоверенных сетей.
    
42. 
    Поставщик должен включить в состав ценового предложения работы по приведению Решения в защищённое состояние. Требование касается не только сетевых элементов, но и систем управления Решением.
    
43. 
    Поставщик должен предоставить перечень опционального функционала, относящегося к безопасности и противодействию фроду (включая коды для заказа)
    
44. 
    Поставщик должен предоставить связанные описания по активации и операционному использованию опциональной функциональности, относящейся к безопасности и противодействию фроду.
    
45. 
    Поставщик должен включить весь необходимый опциональный функционал, относящийся к безопасности и противодействию фроду, в коммерческое предложение. Для всего невключенного в коммерческое предложение функционала должно быть предоставлено обоснование отказа.
    
46. 
    Журналы событий должны экспортироваться в систему управления журналами событий ArcgSight, например, по протоколу syslog, в объеме достаточном для контроля всех функциональных операций, перечисленных в указанном RFP
    
47. 
    Удаленный доступ ТП должен быть организован с использованием Balabit, терминальных машин и VPN
    
48. 
    Внутренний портал должен быть расположен в сегменте inside и доступ к нему должен быть организован с использованием TLS 1.1 и выще
    
49. 
    При виртуализации Решение должно быть совместимо с HyTrust и Trend Micro™ Deep Security™.
    
50. 
    
    

1. 
   Реализация проекта в части системной инфраструктуры должна соответствовать корпоративным стандартам ПАО «МТС» и удовлетворять необходимым требованиям к доступности системы:
   

2. 
   Используемое в системе стороннее программное обеспечение должно быть актуальных версий, находящихся на основном цикле сопровождения у соответствующих поставщиков.
   
3. 
   Предложение не должно учитывать стоимость оборудования, системных программных лицензий на ОС, БД и техническую поддержку на системную инфраструктуру за исключением случаев, когда за промышленную эксплуатацию системы (включая ИТ-инфраструктуру) отвечает участник.
   
4. 
   Аппаратная платформа и программные продукты «3th party product», используемые в Системе, должны находиться в рамках программ поддержки своих производителей не менее 3-х лет с момента сдачи системы в эксплуатацию.
   
5. 
   Предложение в рамках RFP должно включать состав КТС для создания тестовой зоны.
   

1. 
   Производственный цикл системы должен поддерживать технологии непрерывной поставки - небольшими изменениями от кода в продуктивную среду
   
2. 
   Необходимо иметь возможность установки как всей системы, так и обновлений без участия администратора из репозитория
   
3. 
   Необходимо иметь возможность предоставления нового функционала в системе только определённой группе пользователей - выборка, сегмент, бизнес процесс
   
4. 
   Решение должно поддерживать возможность организации нескольких тестовых контуров с разделением доступов по пользователям и группам
   

1. 
   Система должна иметь возможность быть проинтегрированой с системами ИТ- и ИБ-ландшафта ПАО МТС
   
2. 
   Всё взаимодействие с окружающими системами ПАО МТС осуществляется с помощью обращения программным интерфейсам (API) этих систем.
   
3. 
   Допускается использовать только стандартизованные API: REST, SOAP и JSON AP
   
4. 
   Разработчик должен указать какие библиотеки и их версии использовались для создания API
   
5. 
   В библиотеках API должны использоваться все последние патчи, касающиеся безопасности
   
6. 
   Должны быть перечислены и предоставлены в ДИБ ББ КЦ формализованные описания всех используемых методов API
   
7. 
   Все внешние интерфейсы приложений (API) должны поддерживать аутентификацию взаимодействующих приложений с использованием криптографически стойких протоколов аутентификации. например, для REST и SOAP API можно использовать OAuth 1.x и 2.X, SAML, WS-Security, OpenID Connect, и тд.
   
8. 
   Аутентификация приложений должна выполняться с использованием сертификатов открытых ключей или аналогичных по стойкости методов. Использование других методов аутентификации приложений допускается только с согласования ДИБ ББ КЦ
   
9. 
   Каждое сообщение должно контролироваться в части его аутентичности и целостности. То есть, API должно аутентифицировать не только субъекта в начале сессии, но и все сообщения от данного субъекта.
   
10. 
    Информационный обмен API должен быть защищен с использованием стандартизованных криптографически стойких протоколов с приведенной стойкостью 128 бит и более:
    

11. 
    UUID (RFC4122,ISO/IEC 11578:1996, ITU-T Rec. X.667) должен быть уникален для каждого субъекта и вырабатываться с использованием ДСЧ или ПДСЧ
    
12. 
    Все авторизационные токены должны быть защищены криптографическими методами
    
13. 
    API должен контролировать целостность всех сообщений с использованием криптографических методов
    
14. 
    API должен контролировать синтактически и семантически входящие сообщения, в частности:
    

15. 
    API должны иметь защиту от DOS атак. Например, API должны иметь защиту сжатия данных при обмене - zip файл размером в 42 kB может быть распакован в файл размерностью 4,5 петабайта
    
16. 
    API должен быть стойким к атакам перенаправлением сообщений
    
17. 
    Исполнитель берёт на себя функции интегратора Системы и отвечает за выполнение требований по интеграции с внешними системами со стороны внешних систем.
    
18. 
    В своей оценке поставщику также необходимо учесть оказание сотрудникам и разработчикам-подрядчикам смежных систем МТС консультаций экспертов со стороны производителя Системы: архитекторов, разработчиков, аналитиков и т.д.
    
19. 
    Решение должно иметь встроенные средства работы с почтовыми серверами
    
20. 
    Решение не должно использовать БД, web сервера, application сервера собственной разработки.
    
21. 
    Требуется поддержка линейной масштабируемости всех компонентов системы. Поставщик в предложении должен показать правила расширения системы при 10и кратном увеличении нагрузки путём предоставления коэффициентов масштабирования по каждой из задач/компонентов.
    
22. 
    Рабочие места системы должны быть реализованы как web-based приложения, обеспечивающее доступ к содержимому посредством браузеров, являющимися на момент создания системы корпоративным стандартом (Internet Explorer 11 или Google Chrome 39)
    
23. 
    Cистема/платформа должна поддерживать горизонтальное и вертикальное разграничение доступа. Возможности просмотра, создания, изменения и удаления данных должны быть разделены на отдельные полномочия.
    
24. 
    Предлагаемая система (портал) должна поддерживать три уровня внесения изменений: конфигурирование, кастомизация и доработки «ядра» системы. Конфигурирование должно быть доступно из административных интерфейсов и при помощи инструкций в руководстве администратора системы. Уровень кастомизации должен обеспечивать возможность разработки и встраивания дополнительных программных модулей (виджетов, портлетов и т.п.) без внесения изменений в исходный код базовых компонентов системы. Подключение внешних кастомизированных модулей, созданных сторонними разработчиками, не должно быть запрещено условиями гарантийной и технической поддержки системы. Уровень «ядра» системы соответствует исходному программному продукту.
    
25. 
    Поставщик должен в предложении показать объекты и операции, которые возможно конфигурировать и кастомизировать.
    
26. 
    Поставщик должен в предложении показать объекты и операции, изменение которых требует изменение ядра системы.
    
27. 
    Требуется возможность настраивать визуальное оформление графических пользовательских интерфейсов, выбирать темы, шрифты, используемые размеры и цвета элементов интерфейса под нужды заказчика без привлечения поставщика.
    
28. 
    Соответствие принципам построения SOA/MSA микросервисной архитектуры (модульное деление на сервисы, независимость реализации модулей).
    
29. 
    Модуль/система должна продолжать работать даже в том случае, если в ряде транзакций возникла исключительная ситуация, т.е. если "весь дом в огне". Т.е. для сценариев должен быть проработан не только sunny, но и rainy day
    
30. 
    Система должна поддерживать режим горячего резерва, т.е. режим, в котором она находится в развёрнутом и готовом к работе состоянии, но реально не используется и может быть приведена в состояние действующей путём нажатия "волшебной кнопки" сотрудником эксплуатации
    
31. 
    Архитектура программных решений должна быть построена на независимых модулях, обеспечивающих набор элементарных сервисов. Модуль - минимальный компонент системы, который может быть развёрнут независимо от других компонентов системы
    
32. 
    Функции в приложении/модуле должны разделяться по модели MVC/MVVM
    
33. 
    Система должна предоставлять инструментарий для расширения функциональности системы вне ядра сторонними командами разработки
    
34. 
    Решение должно поддерживать возможность создавать автоматические скрипты тестирования
    
35. 
    Решение должно обеспечивать поддержку контроля версий для автоматических скриптов тестирования
    
36. 
    Должна быть возможность создания как общих автоматических тестов, так и пользовательских (для каждого пользователя или группы пользователей)
    
37. 
    Администратор должен иметь возможность запрещать применение на продуктовой среде каких-либо изменений до прохождения назначенных автоматических тестов без ошибок
    

1. 
   Техническое сопровождение системы должно обеспечиваться в режиме 8x5 квалифицированным персоналом на русском языке по отдельно согласовываемому регламенту, но обязательно включающему регистрацию проблемы с присвоением ей идентификационного номера, приоритета и контактов ответственного за Системы лица. Зарегистрированные заявки должны быть доступы через web-интерфейс авторизованному персоналу Заказчика.
   
2. 
   Оказание консультационных услуг Заказчику, структурным подразделениям Компании по телефону (HelpDesk), электронной почте и через автоматизированную систему управления инцидентами по вопросам:
   

3. 
   Поддержка пользователей в режиме 8x5. Оказание информационно-технической поддержки Заказчику по вопросам развертывания и сопровождения программных средств на стенде Заказчика, в структурных подразделениях Компании, в том числе, с целью проведения тестирования исправлений компонентов Системы
   
4. 
   Проведение плановых мероприятий по обслуживанию Системы.
   
5. 
   Аудит состояния системы (в части доступности, надежности и производительности) в том числе:
   

• 
  Еженедельные отчёты по промышленному и тестовому окружениям:
  
• 
  По доступности, надёжности и производительности системы;
  
• 
  По статистике проведённых тестов;
  
• 
  По инцидентам и их статистике.
  
• 
  Проведение аудита раз в квартал по конфигурации (configuration review) и по производительности (performance review) с предоставлением отчета по состоянию.
  

6. 
   Анализ и исправление возникающих технических проблем
   
7. 
   Планирование дальнейшего развития системы:
   

8. 
   Согласие на условиях отчуждения на передачу Заказчику исключительного права в полном объеме на результат выполненных Работ и созданную в рамках работ Документацию
   
9. 
   Согласие на применение Заказчиком штрафных санкций в случае невыполнения договорных обязательств со стороны Поставщика
   
10. 
    Согласие с порядком гарантийного сопровождения ПО и результатов работ:
    

• 
  Блок маркетинга – настройка пороговых значений, редактирование списка сайтов ТОП-100 и списка ответственных для отправки ALARM, отчеты.
  
• 
  Все пользователи, имеющие доступ к системе – отчеты.
  

Показатель качества сервиса	Описание показателя	Формула расчёта	Период контроля
1. Стабильность по скорости предоставления сервиса	Процентное соотношение количества успешных открытий web-страниц в нормативный период времени к общему количеству попыток открытия web-страницы. Нормативное время загрузки страницы – 8 сек. Периодичность измерений – каждые 60 минут.	где, К i_sh – показатель «Стабильность по скорости» сервиса; NG i_s - количество web – страниц, время открытия которых не превышает установленного нормативного времени; Ni_s – общее количество попыток открытия web-страниц.	Час, сутки, неделя, месяц, квартал, полугодие, год

Требования к предложению участника

1. 
   Информация об участнике (общая информация, количество сотрудников, реализованные проекты, аккредитация, местоположение офиса);
   
2. 
   Примеры успешно реализованных на базе предлагаемого решения проектов с описанием масштабов проектов, сроков реализации, полученных результатов;
   
3. 
   Краткое техническое описание и архитектура предлагаемой Системы;
   
4. 
   Бюджетная оценка стоимости внедрения с указанием первоначальных и постоянных затрат;
   
5. 
   Описание схемы поддержки и лицензирования ПО.
   

• 
  Стоимость лицензий на программное обеспечение;
  
• 
  Стоимость первичного внедрения с указанием возможности выполнения работ силами внутренней ИТ-команды МТС и затрат на подготовку (обучение, coaching и т.д.) такой команды.
  
• 
  Сайзинг КТС и возможности виртуализации КТС;
  
• 
  Стоимость технической поддержки лицензий ПО;
  
• 
  Методика расчёта лицензий ПО;
  

Таблица оценки для последующего RFP