1.1.               

1.1.1.          

Редактировать свои данные (телефон, рабочее место и прочие данные, не приходящие из кадровой системы). При 

этом отредактированные пользователем данные проходят авторизацию сотрудника с ролью администратора. 0.5

1.1.2.          Запрашивать доступ к новым ресурсам/новым ролям. 1.0

1.1.3.          Контролировать заявки поданные самим пользователем и поданные другим пользователем на него . 1.0

1.1.4.          

Возможность сформировать заявку на другого пользователя (выступить в роли заявителя).

При этом возможность сформировать заявку на другого пользователя - право, не доступное всем по умолчанию, но 

которое можно запросить наряду с другими правами в Системе. 1.0

1.1.5.          Контролировать свои текущие роли\доступы к ИР. 1.0

1.2.               

Возможность отозвать заявку, поданную самими пользователем (где данный пользователь является инициатором) или 

поданную для пользователя (где пользователь - субъект получения прав доступа) с любого этапа согласования. 1.0

1.3.               Интерфейс пользователя должен поддерживать русский и английский языки. 1.0

1.4.               

1.4.1.               IE 8 и выше, Firefox, Google Chrome в Windows 1.0

1.4.2.               Firefox, Google Chrome в Linux 0.5

1.4.3.               Safari в MacOS X 1.0

1.4.4.               Safari в iOS 1.0

1.5.               Версия интерфейса для мобильных устройств. 1.0

1.6.               

Интерфейсы системы должны позволять кастомизацию для возможности соблюдения корпоративного стиля 

Компании 0.75

1.7.               Интерфейс должен быть полностью кастомизируемым. 1.0

1.8.               Интерфейс пользователя должен быть интуитивно понятен и эргономичен. 1.0

1.9.               Возможность подключения «визардов» для задания параметров запуска бизнес-процесса (формирование заявки). 0.5

1.10.           Для продвинутых пользователей – возможность работы без «визардов». 0.5

1.11.           

Интерфейс должен быть «наборным» в зависимости от полномочий пользователя. Не должно быть лишних 

элементов. 1.0

1.12.           Интерфейс администратора Системы должен иметь возможность быть перенесенным на другой URL, другой порт. 1.0

1.13.           

Желательна интеграция с Exchange/Outlook для реализации согласования заявки непосредственно из почтового 

клиента. 0.75

1.14.           

Продолжительность неактивности сессии пользователя и администратора – конфигурируемый параметр, по 

истечении этого таймаута должна автоматически выполняться операция корректного завершения сеанса. 1.0

2.1.               

Система базируется на стандартных решениях (СУБД, сервер приложения, операционные системы и т.п.), если 

используется собственная разработка вместо имеющегося на рынке стандартного решения, - на это должно быть 

объективное основание. 1.0

2.2.               Работа в среде виртуализации. 1.0

2.3.               

Система должна обеспечивать транзакционную целостность - атомарность операций. При успешном согласовании 

изменений и недоступности реализации изменений в управляемой системе (например, проблемы с каналом связи), 

изменения должны быть сохранены и применены после восстановления связи автоматически. Аналогично для систем-

источников данных - система не должна позволять выполнение неполной синхронизации: начатая и аварийно 

законченная синхронизация должна быть откачена и принята только после успешного завершения. 1.0

2.4.               

Система позволяет размещение своих компонентов на разных аппаратных платформах в целях построения 

высоконадежной системы и повышения безопасности решения. В частности, необходима возможность разделения 

системы на Front-End и Back-End, с возможностью вынесения Front-End в ДМЗ. 1.0

2.5.               

2.5.1.               подключения источников данных, 1.0

2.5.2.               подключения управляемых систем, 1.0

2.5.3.               готовности бизнес-процессов. 1.0

2.6.               

Возможность построения распределенной архитектуры: множество сайтов, соединенных слабыми каналами. На 

каждом сайте - своя организационная структура и свой каталог ресурсов (технически это может быть один каталог, но 

поддерживающий срезы). Какие ресурсы одного сайта делать "видимыми" на других\всех сайтах - настраиваемый 

параметр. 0.5

Сервис самообслуживания пользователей (кабинет), позволяющий:

Интерфейс представляет собой тонкий клиент, работающий в стандартных Web-браузерах/операционных системах современных версий:

Возможность поэтапного запуска в эксплуатацию по мере (система должна иметь модульную архитектуру, позволяющую подобный 

поэтапный запуск в продуктивную эксплуатацию):

ТребованиеВес требования 

(0.00 – 1.00)

1.                   Требования к интерфейсу пользователя

2.                   Требования к архитектуре Системы

2.7.               

Везде, где можно, должны использоваться механизмы синхронизации, направленные на экономию сетевого трафика: 

технологии сжатия, инкрементальные обновления и т.п. 0.5

2.8.               

Возможность построения отказоустойчивой конфигурации (кластеризация, балансировка нагрузки и т.п.). Для оценки 

необходимо руководствоваться следующими данными: количество одновременно работающих пользователей – 20 

000, общее количество пользователей – 100 000, количество управляемых ролей и полномочий – 100 000, количество 

обрабатываемых транзакций в день – 1 00 000, суммарное время простоя системы не должно превышать 4 часа в 

месяц, только на время проведения плановых работ, система должна восстанавливаться после сбоя в течение 1 

рабочего дня, при этом недопустимы потери данных, аварийно прерванные операции должны быть корректно 

завершены или отменены, в случае отката каких-либо операций об этом должно быть однозначным образом сообщено 

ответственным любым реализованном в системе способом (запись в журнале регистрации (log), оповещение по почте 

и т.п. 1.0

2.9.               Возможность линейного масштабирования по ресурсам за счет добавления новых серверов, модулей СХД. 0.5

2.10.               

Система должна позволять использование квалифицированной электронной подписи (см. Федеральный закон от 

06.04.2011 N 63-ФЗ «Об электронной подписи») в процессе согласования заявки на доступ. 1.0

2.11.               Возможность экспорта подписываемого образа заявки на любом этапе согласования с целью последующего импорта. 0.5

2.12.               В момент импорта имеется возможность отредактировать получившуюся заявку. 0.5

2.13.               

Доступ к пользовательским интерфейсам и трафик между компонентами системы защищен от перехвата и 

модификации (SSL и т.п.). 1.0

2.14.               Компоненты системы аутентифицируют друг друга для исключения неавторизованного доступа. 0.2

2.15.               

Рассылаемые Системой письма-оповещения подписываются электронной подписью с возможностью ее проверки в 

MS Outlook (допустимо использование неквалифицированной подписи). 1.0

2.16.               Рассылаемые письма-оповещения подписаны квалифицированной подписью (опционально). 0.3

2.17.               

Система должна хранить исторические данные для построения отчётов за всю историю согласования. Глубина архива 

системы должна быть не менее 10 лет. 1.0

2.18.               Система должна иметь API, позволяющее программно расширять функционал Системы. 1.0

2.19.               Система должна позволять создавать коннекторы с любой системой-источником данных и управляемой системой. 1.0

2.20.               

Продолжительность обучения специалиста средней технической квалификации разработке коннекторов не должна 

превышать 5 дней. 0.5

2.21.               Обучение должно быть доступно на территории РФ. 0.5

2.22.               

Наличие сертификата на ПО по требованиям безопасности для защиты персональных данных до 3 уровня 

защищенности включительно. 1.0

2.23.               Наличие сертификата как ПО общего назначения для использования при создании АС до класса 1Г включительно. 1.0

2.24.               

Сертификация как СЗИ для использования при создании АС до класса 1Г включительно по реализации функций:

·                     Контроля доступа, идентификации и аутентификации

·                     Регистрации событий безопасности

·                     Обеспечению целостности 1.0

2.25.               

Документация производителя на систему должна содержать руководство по безопасной настройке или обеспечению 

безопасности. 1.0

2.26.               

Все объекты, учитываемые в Системе должны иметь расширяемый набор параметров, что позволяет учитывать 

дополнительные характеристики объектов. 0,75

3.1.

3.1.1.

3.1.1.1. MS Excel 1.0

3.1.1.2. XML 1.0

3.1.2. Текстовый с разделителями (формат CSV) 1.0

3.1.3. Каталог LDAP 0.5

3.1.4. Возможность добавления ресурсов вручную администратором 1.0

3.2. Наличие в системе ролевой модели, привязываемой к организационной структуре. 1.0

3.3.

Функционал Системы должен предусматривать возможность делегирования, замещения и эскалации полномочий на 

любом шаге любого бизнес-процесса. Согласующий через интерфейс самообслуживания должен иметь возможность 

делегировать свои полномочия на ограниченный период и на разные ресурсы разным лицам. Эскалация должна 

происходить автоматически по истечению заданного временного интервала.

Права на изменение делегирования и эскалации должны настраиваться наряду с любыми другими параметрами 

Системы ответственным сотрудником (например, администратором) или автоматически в результате бизнес-

процесса. 1.0

Возможность подгружать справочник ресурсов из:

Файла установленного формата:

3.                   Справочник ресурсов/ролей

3.4.

"Видимость" ресурсов в Справочнике ресурсов\ролей - настраивается. "Видимость" ресурса\роли управляется на 

уровне организационной структуры: по подразделению, по Компании и т.п. 1.0

3.5.

Технология выбора запрашиваемого ресурса построена в виде удобного "Визарда", позволяющего удобно 

запрашивать ресурс из справочника в несколько тысяч ресурсов\ролей. 1.0

3.6.

Возможность интеграции Системы с системой анализа SOD-конфликтов, либо сама Система поддерживает этот 

функционал. 1.0

4.1. Создание пользователя на основании данных из кадровой системы. 1.0

4.2. Изменение данных пользователя на основании данных из кадровой системы. 1.0

4.3. Возможность регистрации пользователя и изменения его данных через графический интерфейс (Ручной ввод). 1.0

4.4. Поддержка множества параллельных организационных структур (Предприятие, рабочая группа, проект, ….). 1.0

4.5. На пользователя можно запрашивать доступ в контексте нескольких, разных организационных структур.  1.0

4.6. Организационные структуры могут, как приходить из систем-источников данных, так и задаваться вручную. 1.0

4.7. Возможность управления жизненным циклом организационных структур через бизнес-процессы (заявки). 1.0

5.1.

5.1.1. Ролей\Ресурсов 1.0

5.1.2. Организационных структур 1.0

5.1.3. Пользователей 1.0

5.1.4. Подключаемых систем 1.0

5.2. Бизнес-процессы можно инициировать по событиям 1.0

5.3. Возможность организации последовательного согласования 1.0

5.4. Возможность организации параллельного согласования 1.0

5.5.

Автоматическое вычисление согласующих по различным критериям, заданным при формировании маршрута бизнес-

процесса 1.0

5.6.

Возможность создания бизнес-процесса временного предоставления повышенных полномочий (на период устранения 

инцидентов и т.п.) 1.0

5.7. Возможность создания бизнес-процесса временного лишения полномочий (на период отпуска и т.п.) 1.0

5.8. Возможность запуска тестовых заявок для продуктивных пользователей/ресурсов для целей отладки 1.0

5.9. Возможность отключения ресурса/роли на период устранения проблем с последующим восстановлением доступа 1.0

5.10. Возможность формирования заявки на предоставление доступа одновременно на нескольких пользователей. 1.0

6.1. Microsoft Active Directory 1.0

6.2. Поддержка множества доменов MS AD, независимо от доверительных отношений 1.0

6.3. Система 1 1.0

6.4. Система 2 1.0

6.5. Система 3 1.0

6.6. Система 4

6.7. Система 5 1.0

6.8. Система 6 1.0

6.9. Система 7 1.0

6.10. Система 8 1.0

6.11. Система 9 1.0

6.12. Система 10 1.0

6.13.

Сама система. Система должна поддерживать свою же ролевую модель и гибко предоставлять доступ к своим 

функциям, используя настроенные бизнес-процессы. 1.0

6.14.

6.14.1. Получение списка пользователей 1.0

6.14.2. Получение списка ролей пользователя 1.0

6.14.3. Создание пользователя 1.0

6.14.4. Присваивание роли пользователю 1.0

6.14.5. Отъем роли у пользователя 1.0

6.14.6. Блокирование пользователя 1.0

6.14.7. Удаление пользователя 1.0

Возможность сконфигурировать бизнес процессы управления жизненными циклами следующих сущностей:

Возможности коннекторов:

4.                   Справочник пользователей

5.                   Маршруты согласования и бизнес-процессы

6.                   Требования по интеграции с управляемыми системами

6.15.

Автоматический аудит расхождений информации о пользователях и присвоенных им ролях в целевой системе. 

Создание скриптов реагирования на расхождения. 1.0

7.1. Интеграция с SAP HR 1.0

7.2. Система 2 1.0

7.3. Интеграция с 1С 1.0

7.4. Интеграция с Microsoft Active Directory 1.0

7.5. Возможность получать организационную структуру из структурированного файла 1.0

7.6. Возможность получать организационную структуру из реляционной базы данных 1.0

7.7. Дополнительные возможности интеграции с источниками данных 1.0

7.8. Возможность ручного ввода организационной структуры 1.0

7.9. BMC Remedy. Обращения в Remedy оператор Helpdesk может переводить в заявки в Системе. 0.5

7.10. Возможность получать организационную структуру из LDAP каталога 1.0

8.1. Возможность настройки авторизации через членство в группах Active Directory 1.0

8.2. Аутентификация учетной записью в Windows-домене 1.0

8.3.

Прозрачная аутентификация учетной записью в Windows-домене (сквозная прозрачная аутентификация). 

Аутентификация в одном домене, через остальные – при наличии доверительных отношений. 1.0

8.4. Возможность использования множества доменов Windows независимо от доверительных отношений 1.0

8.5. Аутентификация на основе SSL-сертификатов 0.5

8.6.

При использовании парольной аутентификации, пароль должен храниться/передаваться по сети исключительно в 

зашифрованном или хешированном виде. 1.0

9.1.

9.1.1. Изменение статуса согласования 1.0

9.1.2. Системного события. Перечень событий должен задаваться. 1.0

9.1.3. Любое событие, фиксируемое в системе. 0.5

9.2. Информация, указываемая в теле отправляемых сообщений, полностью конфигурируема. 1.0

9.3. Перечень получателей полностью конфигурируем. 1.0

9.4. Система должна иметь возможность регистрировать все активные события изменения данных. 1.0

9.5.

При этом для каждой операции изменения должны фиксироваться: дата изменения, старое значение, новое значение, 

кто изменил. 1.0

9.6. Система должна регистрировать все операции изменения настроек безопасности. 1.0

9.7.

9.7.1.

9.7.1.1. SIEM только одного производителя. 0.5

9.7.1.2. Конкретный список производителей SIEM. 0.5

9.7.1.3. Возможна интеграция с любым (или список содержит всех лидеров рынка на момент выбора). 0.5

9.7.2. Поддержка syslog. 0.5

9.7.3. Поддержка других открытых стандартов пересылки событий. 0.5

10.1.               

Система должна позволять формировать любые отчеты по данным, хранимым в Системе, включая исторические 

данные. Отчеты, приведенные далее, являются необходимыми минимумом. 1.0

10.2.               

Отображаемые во всех отчетах поля должны конфигурироваться (представление отчетов должно быть настаиваемо), 

должны конфигурироваться поля упорядочивания. 1.0

10.3.               Отчеты можно запускать по расписанию, а результаты высылать на заданный почтовый адрес. 1.0

10.4.               Отчеты можно экспортировать в электронные таблицы: Excel, XML. 1.0

10.5.               Отчетность позволяет выполнять поиск заявок по различным критериям. 1.0

10.6.               

10.6.1.               Созданные им заявки  1.0

10.6.2.               Другие отчеты 0.5

10.7.               

10.7.1.               Список ресурсов, где он владелец 1.0

10.7.2.               Список пользователей по каждому ресурсу 1.0

10.7.3.               Другие отчеты Владельца ресурса 0.5

10.8.               

Возможность автоматического сохранения событий в удаленных хранилищах (по заданному расписанию или в реальном времени):

7.                   Требования по интеграции с источниками данных

8.                   Требования аутентификации и авторизации пользователей

9.                   Требования к аудиту

10.               Требования к отчетности

Возможность отправки оповещений по электронной почте для случаев:

Интеграция с решениями SIEM

Отчеты для инициатора заявки

Отчеты для Владельца ресурса

Отчеты для любого согласующего (Руководитель – обязательный согласующий)

10.8.1.               История согласования с его участием 1.0

10.8.2.               Поиск заявок по различным критериям 1.0

10.8.3.               Другие отчеты для согласующего 0.5

10.9.               

10.9.1.               «Карточка ресурса\роли» на заданную дату – показать, кто имеет данную роль в заданный момент времени. 1.0

10.9.2.               

«Карточка пользователя» на заданную дату – показать полномочия и кадровую информацию пользователя в заданный 

момент времени. 1.0

10.9.3.               

Матрица доступа для заданного списка пользователей и ресурсов (строки - пользователи, столбцы - роли, на 

пересечении - доступ\наличие роли). 1.0

10.9.4.               История изменения полномочий пользователя с упорядочиванием по дате. 1.0

10.9.5.               История изменения роли с упорядочиванием по дате. 1.0

10.9.5.1.               Наличие возможности настраивать, какие события и изменения должны попадать в отчеты. 1.0

10.9.6.               Результаты аудита прав доступа в управляемой системе и IDM/IAG. 1.0

10.9.7.               

Обнаружение учетных записей и изменений полномочий в управляемых системах, произведенных вне установленных 

процессов согласования. 1.0

10.9.8.               Перечень заявок, которые уже прошли согласование, но еще не реализованы в целевых системах. 1.0

10.9.9.               Перечень учетных записей пользователей в управляемых системах, не связанных с пользователями в IDM. 1.0

10.9.10.               

Избыточные полномочия: группы, роли, присвоенные в управляемых системах пользователям, но не известные 

Системе. 1.0

10.9.11.               Отчеты об аудите событий безопасности системы. 1.0

10.9.12.               Другие отчеты для офицера безопасности. 0.5

10.10.               

10.10.1.               Заявок за период с группировкой по дням, по неделям, по месяцам 1.0

10.10.2.               Заявок за период с группировкой по дням, по неделям, по месяцам по указанным подразделениям пользователей 1.0

10.10.3.               Заявок за период с группировкой по дням, по неделям, по месяцам по указанным ролям 1.0

10.10.4.               Другие статистические отчеты 0.5

10.11.               

Данные для отчетности должны храниться в нормализованном виде в реляционной СУБД, включая дополнительные 

поля, созданные в рамках кастомизации системы. Данное требование предполагает возможность построения отчетов с 

помощью коммерческих средств построения отчетности, используя прямой доступ в СУБД. 0,75

11.1. Вендор обязуется предоставить экспертов с опытом внедрения предлагаемой системы в проектную команду 1.0

11.2. Подтвердить сертификатами, квалификацию предоставленных экспертов 1.0

11.3.

Вендор должен гарантировать проведение экспертизы проекта на соответствие своим рекомендациям использования 

продукта и отсутствие противоречий с будущими изменениями в продукте (дорожной карте развития продукта) 1.0

11.4.

В рамках проекта необходимо проведение обучения специалистов Общества с целью сопровождения и последующего 

развития Системы силами команды Общества (продолжительность обучения ~ 5 дней, проведение – на территории 

РФ, рассчитано на среднего инженера) 1.0

12.1.

12.1.1. Интеграция с новыми источниками данных. 1.0

12.1.2. Интеграция с новыми управляемыми системами. 1.0

12.1.3. Разработка новых бизнес-процессов, модификация существующих. 1.0

12.1.4. Переход на новые версии IDM, установка обновлений. 1.0

12.1.5. Поддержка инфраструктуры системы IDM. 1.0

12.1.6. Разработка отчетов по заданным критериям. 1.0

13.1.               Схема лицензирования (описать текстом). 1.0

Отчеты для офицера безопасности

Статистические отчеты

Обязательно выполнение следующих работ силами Общества:

13.               Требования к лицензированию.

11.               Требования к проектной команде

12.               Требования к поддержке