1. Приложение № 1
К Документации по проведению открытого Запроса
предложений на право заключения договора на
выполнение в 2013 году работ по развитию
федеральной
государственной
информационной
системы
«Единая
система
идентификации
и
аутентификации в инфраструктуре, обеспечивающей
информационно-технологическое
взаимодействие
информационных
систем,
используемых
для
предоставления государственных и муниципальных
услуг в электронной форме» в рамках реализации
мероприятий государственной программы Российской
Федерации «Информационное общество (2011 – 2020
годы)»
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на выполнение в 2013 году работ по развитию федеральной
государственной информационной системы «Единая система
идентификации и аутентификации в инфраструктуре, обеспечивающей
информационно-технологическое взаимодействие информационных
систем, используемых для предоставления государственных и
муниципальных услуг в электронной форме» в рамках реализации
мероприятий государственной программы Российской Федерации
«Информационное общество (2011 – 2020 годы)»

2. СОДЕРЖАНИЕ
1.
Общие сведения ......................................................................................... 3
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
НАИМЕНОВАНИЕ РАБОТ...................................................................... 3
НАИМЕНОВАНИЕ ЗАКАЗЧИКА ............................................................. 3
НАИМЕНОВАНИЕ ИСПОЛНИТЕЛЯ ........................................................ 3
ПОЛНОЕ НАИМЕНОВАНИЕ И УСЛОВНОЕ ОБОЗНАЧЕНИЕ СИСТЕМЫ..... 3
ПЛАНОВЫЕ СРОКИ ВЫПОЛНЕНИЯ РАБОТ ............................................ 3
ОСНОВАНИЯ ПРОВЕДЕНИЯ РАБОТ ....................................................... 3
ОСНОВНЫЕ НАПРАВЛЕНИЯ ВЫПОЛНЕНИЯ РАБОТ ............................... 4
СПИСОК ТЕРМИНОВ И СОКРАЩЕНИЙ .................................................. 4
2.
Цели и задачи выполнения работ .......................................................... 7
3.
Характеристика объекта автоматизации ............................................ 8
4.
Требования к системе............................................................................... 8
4.1
4.2
4.3
4.4
4.5
5.
Требования, предъявляемые к результатам работ .......................... 20
5.1
5.2
5.3
5.4
5.5
6.
ТРЕБОВАНИЯ К РАЗВИТИЮ ФУНКЦИЙ ЕСИА ..................................... 8
ТРЕБОВАНИЯ К ИНФРАСТРУКТУРНОМУ ОБЕСПЕЧЕНИЮ ................... 19
ТРЕБОВАНИЯ ПО СОХРАННОСТИ ИНФОРМАЦИИ ПРИ АВАРИЯХ ........ 19
ТРЕБОВАНИЯ К НАДЕЖНОСТИ ........................................................... 19
ТРЕБОВАНИЯ К РЕЖИМАМ ФУНКЦИОНИРОВАНИЯ ............................ 19
РАЗРАБОТКА ЧАСТНОГО ТЕХНИЧЕСКОГО ЗАДАНИЯ .......................... 20
ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ .................................................... 20
РАЗРАБОТКА ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ .......... 20
РАЗРАБОТКА ЭКСПЛУАТАЦИОННОЙ ДОКУМЕНТАЦИИ...................... 21
РАБОТЫ ПО ОБЕСПЕЧЕНИЮ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ.... 21
Требования к документированию ....................................................... 21
ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ.......................................................... 21
ПРОЕКТНАЯ И РАБОЧАЯ ДОКУМЕНТАЦИЯ......................................... 21
ИСХОДНЫЕ ТЕКСТЫ И ПРОГРАММНАЯ ДОКУМЕНТАЦИЯ .................. 22
ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ ДОКУМЕНТАЦИИ ПО ИСПЫТАНИЯМ
СИСТЕМ
22
6.5 ПЕРЕЧЕНЬ ТЕХНИЧЕСКОЙ ДОКУМЕНТАЦИИ, ПРЕДЪЯВЛЯЕМОЙ ПО
ОКОНЧАНИИ РАБОТ ............................................................................................... 23
6.6 ТРЕБОВАНИЯ К РАЗРАБОТКЕ ДЕТАЛИЗИРОВАННОЙ МОДЕЛИ УГРОЗ
6.1
6.2
6.3
6.4
БЕЗОПАСНОСТИ ИНФОРМАЦИИ СИСТЕМЫ И ДИФФЕРЕНЦИРОВАННОЙ МОДЕЛИ
ВОЗМОЖНОСТЕЙ
ВЕРОЯТНОГО
НАРУШИТЕЛЯ
ПРАВИЛ
ОБЕСПЕЧЕНИЯ
БЕЗОПАСНОСТИ ИНФОРМАЦИИ СИСТЕМЫ ............................................................ 24
6.7 ТРЕБОВАНИЯ К РАЗРАБОТКЕ КОМПЛЕКТА ДОКУМЕНТОВ ДЛЯ
АТТЕСТАЦИИ (ПЕРЕАТТЕСТАЦИИ) СИСТЕМЫ ........................................................ 25

3. 1. ОБЩИЕ СВЕДЕНИЯ
1.1 Наименование работ
Выполнение в 2013 году работ по развитию федеральной
государственной информационной системы «Единая система идентификации
и аутентификации в инфраструктуре, обеспечивающей информационнотехнологическое взаимодействие информационных систем, используемых
для предоставления государственных и муниципальных услуг в электронной
форме» в рамках реализации мероприятий государственной программы
Российской Федерации «Информационное общество (2011 – 2020 годы)»
(далее – Работы).
1.2 Наименование заказчика
Полное наименование заказчика Работ: Открытое акционерное
общество междугородной и международной электрической связи
«Ростелеком» (далее – Заказчик)
Сокращенное наименование заказчика Работ: ОАО «Ростелеком».
1.3 Наименование исполнителя
Полное наименование исполнителя Работ: Открытое акционерное
общество междугородной и международной электрической связи
«Ростелеком» (далее – Исполнитель).
Сокращенное наименование исполнителя Работ: ОАО «Ростелеком».
1.4 Полное наименование и условное обозначение системы
Полное
наименование:
Единая
система
идентификации
и
аутентификации в инфраструктуре, обеспечивающей информационнотехнологическое взаимодействие информационных систем, используемых
для предоставления государственных и муниципальных услуг в электронной
форме.
Условное обозначение: ЕСИА.
1.5 Плановые сроки выполнения работ
Начало работ:
Дата заключения Договора.
Завершение работ:
06.12.2013.
1.6 Основания проведения работ
Основанием для проведения работ являются следующие документы:
­ Федеральный закон от 27 июля 2010 г. № 210-ФЗ «Об организации
предоставления государственных и муниципальных услуг»;
­ Федеральный закон от 6 апреля 2011 г. № 63-ФЗ «Об электронной
подписи»

4. ­ Государственная программа Российской Федерации «Информационное
общество (2011 – 2020 годы)», утвержденная распоряжением
Правительства Российской Федерации от 20 октября 2010 г. № 1815-р;
­ Постановление Правительства Российской Федерации от 28 ноября
2011 г. № 977 «О федеральной государственной информационной
системе «Единая система идентификации и аутентификации в
инфраструктуре, обеспечивающей информационно-технологическое
взаимодействие информационных систем, используемых для
предоставления государственных и муниципальных услуг в
электронной форме»;
­ Распоряжение Правительства Российской Федерации от 22 февраля
2012 г. № 238-р об определении ОАО «Ростелеком» единственным
исполнителем работ в рамках реализации мер государственной
программы Российской Федерации «Информационное общество (2011
– 2020 годы)»;
­ Приказ Министерства связи и массовых коммуникаций Российской
Федерации от 13 апреля 2012 г. № 107 «Об утверждении положения о
федеральной государственной информационной системе «Единая
система идентификации и аутентификации в инфраструктуре,
обеспечивающей информационно-технологическое взаимодействие
информационных систем, используемых для предоставления
государственных и муниципальных услуг в электронной форме»
1.7 Основные направления выполнения работ
Работы выполняются в рамках реализации следующих мер
Государственной программы Российской Федерации «Информационное
общество (2011 – 2020 годы)»:
­ развитие Единого портала государственных и муниципальных услуг
(функций);
­ формирование единого пространства доверия электронной подписи;
­ развитие системы межведомственного электронного взаимодействия.
1.8 Список терминов и сокращений
Сокр
Наименование / Определение
ащен
ие
/
Терм
ин
АГС Акты гражданского состояния
АРМ Автоматизированное рабочее место
БД
База данных
ГИС Государственная информационная система о государственных и
ГМП муниципальных платежах
ЕПГ Федеральная государственная информационная система «Единый

5. Сокр
Наименование / Определение
ащен
ие
/
Терм
ин
У
портал государственных и муниципальных услуг (функций)»
ЕСИ Федеральная государственная информационная система «Единая
А
система идентификации и аутентификации в инфраструктуре,
обеспечивающей информационно-технологическое взаимодействие
информационных систем, используемых для предоставления
государственных и муниципальных услуг в электронной форме»
ЕСН Единая система справочников и классификаторов, используемых в
СИ
государственных и муниципальных информационных системах
ЕЛК Единый личный кабинет пользователя – подсистема ЕПГУ
ЖКХ Жилищно-коммунальное хозяйство
Заяви Потребитель государственных услуг, выполнивший авторизацию в
тель ЛК
ИАС Информационно-аналитическая система мониторинга качества
МКГ государственных услуг
У
ИБ
Информационная безопасность
ИНН Идентификационный номер налогоплательщика
ИС
Информационная система
ИС
Информационная система головного удостоверяющего центра
ГУЦ
ИЭП Инфраструктура электронного правительства
ЛК
Личный кабинет
МО
Муниципальное образование
МР
Методические рекомендации
МФЦ Многофункциональный центр предоставления государственных и
муниципальных услуг
НПА Нормативные правовые акты
ОГВ Орган государственной власти
ОГР Основной государственный регистрационный номер
Н
ОИВ Орган исполнительной власти
ОМС Орган местного самоуправления
У
ОС
Операционная система
ПО
Программное обеспечение
ПИБ Подсистема информационной безопасности
РОИ Региональный орган исполнительной власти
В

6. Сокр
ащен
ие
/
Терм
ин
РСМ
ЭВ
Сист
ема
опов
ещен
ий
СМУ
Наименование / Определение
Региональная
система
межведомственного
электронного
взаимодействия
Система оповещений пользователей посредством отправки
сообщений на электронную почту или через SMS
Система обеспечения взаимодействия мобильных устройств с
инфраструктурой электронного правительства
СМЭ Федеральная государственная информационная система «Единая
В
система межведомственного электронного взаимодействия»
СНИ Страховой номер индивидуального лицевого счета застрахованного
ЛС
лица в системе персонифицированного учета Пенсионного фонда
России
СПО Свободное программное обеспечение
ТЗ
Техническое задание
ФГИ Федеральная государственная информационная система
С
ФГИ Федеральная
государственная
информационная
система,
С ДО обеспечивающая процесс досудебного (внесудебного) обжалования
решений и действий (бездействия), совершенных при предоставлении
государственных и муниципальных услуг
ФИА Федеральная информационная адресная система
С
ФИО Фамилия, имя, отчество
ФОИ Федеральный орган государственной власти
В
ФРГ Федеральный реестр государственных и муниципальных услуг
У
ЧТЗ Частное техническое задание
ЭП
Электронная подпись
ЭПЭлектронная
подпись,
формируемая
от
имени
органа
ОВ
государственной власти и органа местного самоуправления,
участвующего в межведомственном взаимодействии при оказании
государственных услуг
ЭПЭлектронная подпись, формируемая от имени должностного лица
СП
органа власти, участвующего в межведомственном взаимодействии
при оказании государственных услуг
ЭПЭлектронная подпись Портала Государственных Услуг

7. Сокр
Наименование / Определение
ащен
ие
/
Терм
ин
ПГУ
ЭПЭлектронная подпись Системы межведомственного электронного
СМЭ взаимодействия
В
API
Application Programming Interface (Интерфейс программирования
приложений)
csv
Текстовый формат, предназначенный для представления табличных
данных
OAut Открытый протокол авторизации
h
REST Передача репрезентативного состояния (Representational State
Transfer)
SaaS Software as a Service (программное обеспечение как услуга)
SAM Security Assertion Markup Language
L
SMS Служба коротких сообщений (Small Messagin Service)
XML eXtensible Markup Language — расширяемый язык разметки
XSD XML Schema Definition - язык описания структуры XML-документа
WSD Web Services Definition Language - стандарт описания интерфейсов
L
веб-сервисов на основе стандарта XML
2. ЦЕЛИ И ЗАДАЧИ ВЫПОЛНЕНИЯ РАБОТ
Целями и задачами развития федеральной государственной
информационной
системы
«Единая
система
идентификации
и
аутентификации в инфраструктуре, обеспечивающей информационнотехнологическое взаимодействие информационных систем, используемых
для предоставления государственных и муниципальных услуг в электронной
форме» являются:
­ обеспечение выполнения требований законодательства Российской
Федерации в части использования электронной подписи при оказании
государственных и муниципальных услуг;
­ развитие средств ЕСИА в части ведения учётных записей
пользователей Единого портала государственных и муниципальных
услуг (функций) и других государственных и ведомственных
информационных систем;
­ развитие средств ЕСИА, обеспечивающих интеграцию ЕСИА с
другими информационными системами в рамках обеспечения
межведомственного электронного взаимодействия.

8. 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ
Объектом автоматизации являются процессы, связанные с
обеспечением санкционированного доступа пользователей информационнотелекоммуникационной сети «Интернет» и должностных лиц органов власти
к информации, содержащейся в государственных информационных системах,
муниципальных информационных системах и иных информационных
системах.
Участниками данных процессов являются:
­ пользователи
информационно-телекоммуникационной
сети
«Интернет», незарегистрированные в ЕСИА;
­ заявители – физические или юридические лица, обращающиеся за
получением государственных и (или) муниципальных услуг в органы и
организации;
­ должностные лица федеральных органов исполнительной власти,
государственных внебюджетных фондов, органов исполнительной
власти субъектов Российской Федерации, органов местного
самоуправления, государственных и муниципальных учреждений,
многофункциональных центров, а также иных организаций в случаях,
предусмотренных федеральными законами, актами Президента
Российской Федерации и актами Правительства Российской
Федерации;
­ должностные лица оператора ЕСИА – Министерства связи и массовых
коммуникаций Российской Федерации;
­ должностные лица операторов государственных, муниципальных и
иных информационных систем, для которых ЕСИА обеспечивает
санкционированный доступ к содержащейся в них информации
(далее – интегрированные с ЕСИА информационные системы);
­ должностные лица органов и организаций, имеющих право на выдачу
ключей простых электронных подписей в целях оказания
государственных и муниципальных услуг, и удостоверяющих центров,
аккредитованных в соответствии с положениями Федерального закона
от 6 апреля 2011 г. № 63-ФЗ «Об электронной подписи».
4. ТРЕБОВАНИЯ К СИСТЕМЕ
4.1 Требования к развитию функций ЕСИА
В результате выполнения работ по развитию ЕСИА система должна
обеспечивать:
­ возможность использования простой электронной подписи при
оказании государственных и муниципальных услуг;
­ возможность
использования
усиленной
квалифицированной
электронной подписи, выданной аккредитованными Минкомсвязью
России удостоверяющими центрами, с форматом сертификата,

9. соответствующим требованиям Приказа Федеральной службы
безопасности Российской Федерации от 27 декабря 2011 г. № 795.
­ возможность регистрации и ведения профилей пользователей и
организаций;
­ возможность идентификации и аутентификации пользователей
интегрированных с ЕСИА информационных систем;
­ возможность санкционированного доступа интегрированных с ЕСИА
информационных систем к данным пользователей и организаций,
зарегистрированных в ЕСИА.
4.1.1
Использование учетной записи
В результате выполнения работ по развитию ЕСИА система должна
обеспечить возможность зарегистрировать и начать использовать учетную
запись в упрощенном режиме. Начало использования учетной записи в
упрощенном режиме возможно в соответствии с порядком и требованиями
изложенными в Приложении №1 к настоящему ТЗ.
В результате выполнения работ, в ЕСИА должен быть реализован
технический регистр, обеспечивающий предоставление упрощенного
порядка доступа к ЕПГУ.
Детализация требований к доработке механизмов регистрации учетной
записи должна быть выполнена на этапе написания ЧТЗ.
4.1.2
Использование квалифицированной электронной подписи
В результате выполнения работ по развитию ЕСИА система должна
обеспечивать возможность использования квалифицированной электронной
подписи в соответствии с Федеральным законом от 6 апреля 2011 г. № 63
«Об электронной подписи», выданной аккредитованными Минкомсвязи
России удостоверяющими центрами, в том числе удостоверяющими
центрами Федеральной налоговой службы Российской Федерации и
Федеральной службы государственной регистрации, кадастра и картографии,
с форматом сертификата, соответствующим требованиям приказа
Федеральной службы безопасности Российской Федерации от 27 декабря
2011 г. № 795.
Заказчик должен не позднее, чем через 20 рабочих дней со дня
заключения Договора, предоставить Исполнителю в целях разработки и
тестирования действительные ключи и сертификаты квалифицированной
электронной подписи физических и юридических лиц, выданные
удостоверяющими центрами Федеральной налоговой службы Российской
Федерации и Федеральной службы государственной регистрации, кадастра и
картографии.
4.1.3
Регистрация и ведение профилей пользователей
Пользователями ЕСИА являются физические лица: граждане
Российской Федерации, иностранные граждане и лица без гражданства.
В результате развития ЕСИА пользователи Единого портала
государственных и муниципальных услуг (функций) должны иметь

10. возможность зарегистрировать в ЕСИА стандартную учетную запись
самостоятельно, с помощью информационно-телекоммуникационной сети
«Интернет».
В результате развития ЕСИА пользователи должны получить
возможность подтвердить свою личность, активировав учетную запись
ЕСИА, с помощью уполномоченных организаций. Должен быть создан
регистр органов и организаций, имеющих право создания (замены) и выдачи
ключа простой электронной подписи в целях оказания государственных и
муниципальных услуг, а также обеспечены средства его ведения силами
оператора. Активация учетной записи должна проходить путем нахождения
в ЕСИА учетной записи, требующей активации, по номеру предъявленного
пользователем оригинала документа удостоверяющего личность.
Для
пользователей - граждан РФ для активации должен использоваться основной
документ удостоверяющий личность, для пользователей иностранных
граждан и лиц без гражданства перечень принимаемых удостоверений
личности должен быть уточнен на этапе разработки ЧТЗ.
В рамках ведения профиля пользователя в ЕСИА:
­ должна быть обеспечена возможность использования веб-интерфейса
ЕСИА для просмотра и редактирования профиля пользователя;
­ должна быть обеспечена возможность регистрации стандартной
учётной записи в соответствии с Приложением № 1 к настоящему ТЗ;
­ должен быть реализован прикладной программный интерфейс,
позволяющий
использовать
механизмы
идентификации,
аутентификации, авторизации и ведения профилей пользователей
ЕСИА;
­ для стандартных учётных записей должна быть обеспечена
возможность замены пароля онлайн; для пользователей, не
завершивших полную регистрацию стандартной учетной записи,
возможность замены пароля онлайн также должна быть доступна.
­ восстановление пароля, в случае, если был установлен факт её
использования ненадлежащим лицом должно быть доступно при
личном визите пользователя в офис уполномоченной организации и
предъявления пользователем оригинала основного документа
удостоверяющего личность (для пользователей – граждан РФ, для
пользователей иностранных граждан и лиц без гражданства перечень
принимаемых удостоверений личности должен быть уточнен на этапе
разработки ЧТЗ).
4.1.3.1 Использование веб-интерфейса ЕСИА
редактирования профиля пользователя
для
просмотра
и
Все зарегистрированные в ЕСИА пользователи (в том числе
должностные лица органов и организаций) должны иметь возможность
просмотра и редактирования своего профиля через веб-интерфейс ЕСИА.
ЕСИА должна предоставлять пользователю возможность:

11. ­ просмотреть и отредактировать личные данные (фамилию, имя,
отчество, пол, дату рождения, адрес электронной почты, мобильный
телефон, почтовый адрес, гражданство, реквизиты удостоверяющих
личность документов);
­ подтвердить личность, используя простую или квалифицированную
электронную подпись;
­ просмотреть и изменить настройки безопасности, в том числе:
­ изменить пароль и параметры его восстановления;
­ настроить двухфакторную усиленную аутентификацию;
­ изменить список сервисов, имеющих авторизованный доступ к личным
данным пользователя;
­ управлять своей принадлежностью к группам и организациям, в том
числе:
­ зарегистрировать новую организацию;
­ инициировать процесс исключения себя из группы или организации;
­ просмотреть список систем, в которых пользователь может пройти
авторизацию, используя свою учётную запись ЕСИА;
­ подтвердить / отклонить запрос юридического лица на установку связи
с этим юридическим лицом;
­ удалить свою учётную запись;
­ вернуться на исходный веб-сайт, с которого пользователь перешёл в
ЕСИА.
4.1.3.2 Прикладной
программный
интерфейс,
позволяющий
использовать механизмы идентификации, аутентификации,
авторизации и ведения профилей пользователей ЕСИА
В рамках развития ЕСИА должен быть реализован прикладной
программный интерфейс, позволяющий использовать следующие механизмы
ведения профилей пользователей ЕСИА:
­ идентификация, аутентификация и авторизация пользователей;
­ регистрация в ЕСИА стандартной учётной записи пользователя (в
соответствии с Приложением №1);
­ проверка достоверности данных, предоставляемых гражданами
Российской Федерации, с использованием базовых государственных
информационных ресурсов (в случае их доступности);
­ финализация регистрации стандартной учетной записи – для
подтвердивших
свою
личность
и
ранее
самостоятельно
инициировавших регистрацию стандартной учётной записи граждан
Российской Федерации, а также иностранных граждан (лиц без
гражданства), имеющих СНИЛС;
­ восстановление доступа к учётной записи в случае, если пользователь
забыл пароль;
­ генерация пароля ключа простой электронной подписи для
физического или юридического лица;
­ удаление учётной записи и связанных с ней персональных данных
пользователя из ЕСИА.

12. Дополнительно должен быть реализован веб-интерфейс, позволяющий
активировать стандартные учетные записи пользователей в ЕСИА.
4.1.3.3 Восстановление паролей для стандартных учетных записей
Механизмы восстановления пароля должны быть доработаны таким
образом, чтобы пользователи не завершившие полную регистрацию
стандартной учетной записи имели возможность восстановить пароль.
Для получения кода восстановления пароля пользователь с учётной
записью должен указать зарегистрированный в ЕСИА номер телефона или
адрес электронной почты.
4.1.4
Требования к дизайну интерфейса пользователя ЕСИА
Детализированные требования к дизайну интерфейсов пользователя
должны быть приведены в ЧТЗ.
4.1.4.1 Требования к изменению существующего дизайна ЕСИА
В результате доработки ЕСИА, должны быть произведены изменения
логики
работы
пользовательского
интерфейса,
продиктованные
требованиями по изменению функциональности ЕСИА, заложенными в
настоящее ТЗ.
Общим требованием к существующему интерфейсу ЕСИА является
поддержка языков: русского, английского, немецкого и французского.
4.1.4.2 Требования к дизайну дополнительного интерфейса пользователя
ЕСИА
В результате доработки, ЕСИА должна обеспечивать возможность
работы
пользователя
с
ЕСИА
посредством
дополнительного
пользовательского интерфейса. Заказчик предоставляет дизайн указанного
интерфейса ЕСИА, включающий в себя:
­ макеты страниц, разнесенные по слоям, в формате Photoshop;
­ набор шрифтов;
­ база используемых элементов;
Исполнитель реализует дополнительный пользовательский интерфейс,
основанный на материалах, полученных от Заказчика.
В случае непредставления Заказчиком материалов в указанные сроки,
Исполнитель вправе отказаться от реализации дополнительного интерфейса.
4.1.5
Регистрация и ведение профилей организаций
В результате развития ЕСИА должны быть реализованы механизмы,
позволяющие:
­ подавать из профиля организации запрос пользователю ЕСИА (путём
указания его СНИЛС) на установку связи этого пользователя с этим
юридическим лицом;
­ автоматически проверять сведения о юридических лицах, используя
электронный сервис ФНС России «Предоставление кратких сведений

13. ­
­
­
­
4.1.6
и/или выписки из ЕГРЮЛ/ЕГРИП по запросу органов государственной
власти» (SID0003525), опубликованный в СМЭВ;
назначать администраторов профиля организации;
создавать группы пользователей с произвольными наименованиями
(например, Администраторы профиля организации, Сотрудники
организации, Сотрудники подрядчиков и т.п.);
осуществлять рассылку приглашений на присоединение к организации
или группе пользователей;
удалять группы пользователей.
Административный веб-интерфейс управления
органов и организаций, содержащихся в ЕСИА
профилями
В результате развития ЕСИА должны быть реализованы
административные
механизмы
и
интерфейсы,
позволяющие
администраторам профиля соответствующего органа или организации:
­ просмотреть и отредактировать данные органа и организации, кроме
атрибутов, которые получены из ФРГУ;
­ назначить администраторов профиля;
­ просматривать иерархию в профиле органов и организации и
должностных лиц нижестоящих органов и организаций.
4.1.7
Идентификация
и
аутентификация
пользователей
интегрированных с ЕСИА информационных систем
Подсистема аутентификации ЕСИА должна быть доработана, чтобы
обеспечить:
­ возможность использования альтернативных логинов пользователя;
­ возможность идентификации, аутентификации и авторизации
пользователей с использованием прикладного программного
интерфейса ЕСИА;
­ возможность аутентификации пользователей с использованием средств
электронной подписи, размещенных на Универсальной электронной
карте;
­ возможность аутентификации пользователя по разовым паролям;
­ возможность
поддержки
OAuth
2.0
при
взаимодействии
информационных систем с ЕСИА;
­ расширение перечня доступных утверждений SAML 2.0;
­ переход между системами, предъявляющими разные требования к
уровню достоверности идентификации;
­ регистрацию используемых пользователями методов аутентификации.
4.1.7.1 Использование альтернативных логинов пользователя
ЕСИА должна обеспечивать возможность идентификации пользователя
не только по СНИЛС, но и по номеру мобильного телефона или по адресу
электронной почты при условии их уникальности в системе.
Требования к работе доработанной системы с альтернативными
логинами пользователя должны быть уточнены в ЧТЗ.

14. 4.1.7.2 Возможность идентификации, аутентификации и авторизации
пользователей с использованием прикладного программного
интерфейса ЕСИА
ЕСИА должна обеспечивать осуществление
идентификации,
аутентификации и авторизации пользователя ЕСИА, использующего свои
учетные данные для работы с интегрированной информационной системой
путем передачи введенных пользователем данных из интегрированной
системы в ЕСИА при помощи прикладного программного интерфейса.
4.1.7.3 Аутентификация пользователей с использованием средств
электронной
подписи,
размещенных
на
универсальной
электронной карте
ЕСИА
должна
обеспечивать
возможность
аутентификации
зарегистрированного в ЕСИА пользователя с использованием сертификата
усиленной квалифицированной электронной подписи, размещенного на
Универсальной электронной карте.
4.1.7.4 Аутентификация пользователей по разовым паролям
ЕСИА должна обеспечивать возможность прохождения пользователем
аутентификации на основе разовых паролей в качестве дополнительного
фактора при усиленной аутентификации с использованием постоянного
пароля (двухфакторная усиленная аутентификация).
Пользователи должны иметь возможность включить аутентификацию
на основе разовых паролей в своем профиле.
ЕСИА должна обеспечивать возможность отправки SMS-сообщений с
разовыми паролями на номер любого российского оператора сотовой связи
посредством подсистемы рассылки уведомлений системы мобильных
устройств.
Срок действия разового пароля должен определяться настройками
ЕСИА. По умолчанию срок действия разового пароля должен составлять 300
секунд с момента генерации. Длина разового пароля должна определяться
настройками ЕСИА и по умолчанию составлять 6 цифр.
4.1.7.5 Поддержка спецификации OAuth 2.0 при взаимодействии
интегрированных с ЕСИА информационных систем
Помимо
основанного
на
стандарте
SAML 2.0
механизма
взаимодействия систем и ЕСИА должна предоставлять возможность
взаимодействия систем и ЕСИА на основе спецификации OAuth 2.0.
ЕСИА при использовании механизма взаимодействия, основанном на
спецификациях OAuth 2.0, должна:
­ обеспечивать проверку согласия пользователя на передачу данных его
профиля системе (при необходимости обеспечивается идентификация и
аутентификация пользователя);
­ обеспечивать выдачу взаимодействующей с ЕСИА системе маркера
доступа к данным профиля пользователя;

15. ­ обеспечивать возможность отзыва пользователем согласия на
дальнейшую возможность передачи данных из его профиля указанной
системе.
Возможность взаимодействия с ЕСИА на основе OAuth 2.0 должна
быть описана в актуализированной версии методических рекомендаций по
использованию ЕСИА.
4.1.7.6 Расширение перечня доступных утверждений SAML 2.0
В рамках развития ЕСИА должен быть доработан основанный на
SAML 2.0 механизм предоставления ЕСИА сведений о пользователях. ЕСИА
должна обеспечивать возможность (в зависимости от зарегистрированных в
ЕСИА настроек системы) передачи следующих утверждений о пользователе
в дополнении к поддерживаемым в настоящее время:
­ данные о вхождении пользователя в группы;
­ данные о том, что при аутентификации пользователя использовалась
двухфакторная усиленная аутентификация с использованием разовых
паролей;
­ данные о том, подтверждена ли личность пользователя.
4.1.7.7 Переход между системами, предъявляющими разные требования
к уровню достоверности идентификации
ЕСИА должна обеспечивать удобные для пользователя возможности
переключения между системами, использующими ЕСИА в качестве
поставщика идентификации и аутентификации пользователей для случая,
когда системы предъявляют разные требования к методам аутентификации и
к категориям учетных записей пользователя.
В рамках развития ЕСИА должны быть реализованы механизмы:
­ информирования пользователя о необходимости дополнительного
действия пользователя для перевода текущей сессии с недостаточным
уровнем на должный уровень аутентификации ;
­ санкционирования перехода пользователя между системами для
следующих ситуаций:
­ для доступа к системе, предъявляющей менее жесткие требования к
уровню достоверности идентификации пользователя;
­ для доступа к системе в качестве физического лица при условии, что
пользователь был аутентифицирован в качестве должностного лица;
­ информирования пользователя о необходимости дополнительного
действия для увеличения или изменения уровня аутентификации или
изменения категории пользователей – для доступа к системе в качестве
должностного лица, если пользователь был аутентифицирован в
качестве физического лица и нельзя однозначно сопоставить
физическому лицу роль должностного лица (например, пользователь
одновременно является должностным лицом нескольких организаций);
­ информирования пользователя о необходимости дополнительного
действия для получения соответствующего уровня аутентификации

16. либо прохождения процедуры подтверждения личности – для доступа к
системе, предъявляющей более жесткие требования к уровню
достоверности идентификации пользователя.
4.1.7.8 Регистрация
используемых
аутентификации
пользователями
методов
Функция регистрации и учета событий идентификации и
аутентификации должна быть доработана таким образом, чтобы обеспечить
учёт используемых пользователями методов аутентификации. В результате
доработки ЕСИА должна регистрировать для каждого события
идентификации и аутентификации пользователя, как минимум, следующие
сведения:
­ дату и время события;
­ идентификатор пользователя в ЕСИА (если идентификация выполнена
успешно);
­ результат события аутентификации;
­ идентификатор
информационной
системы,
запросивший
аутентификацию через ЕСИА;
­ код и описание ошибки (если аутентификация выполнена не успешно);
­ использованный метод аутентификации:
­ по логину и постоянному паролю;
­ по электронной подписи;
­ с использованием разовых паролей.
­ логин (если метод аутентификации - по логину и постоянному паролю);
­ сведения о сертификате электронной подписи (если метод
аутентификации по электронной подписи), в том числе название
удостоверяющего центра, выпустившего сертификат.
4.1.8
Санкционированный
доступ
интегрированных с
ЕСИА
информационных систем к данным пользователей и организаций,
зарегистрированных к ЕСИА
ЕСИА должна обеспечивать:
­ открытые программные интерфейсы для получения
данных о
пользователях и организациях, зарегистрированных в ЕСИА;
­ предоставление маркеров доступа на основе OAuth 2.0 для
возможности осуществления контроля доступа к программным
интерфейсам информационных систем;
­ обеспечение контроля доступа к программным интерфейсам ЕСИА на
основе проверки маркеров доступа.
4.1.8.1 Программные интерфейсы для
пользователях и организациях
получения
данных
о
Программные интерфейсы ЕСИА должны обеспечивать различные
уровни авторизации информационных систем для получения следующей
информации:

17. ­ персональные данные пользователей;
­ сведения о вхождении пользователя в группы и организации;
­ данные из профиля организации (из регистра юридических лиц и
регистра органов и организаций);
­ список участников группы или организации;
­ сведения о факте авторизации пользователя и обезличенный
идентификатор пользователя.
4.1.8.2 Предоставление
маркеров
доступа
для
возможности
осуществления контроля доступа к программным интерфейсам
информационных систем
ЕСИА
должна
предоставлять
информационным
системам
(потребителям сервисов) возможности по получению заверенных ЕСИА
маркеров доступа для использования их в последующем информационными
системами (поставщиками сервисов) в целях осуществления контроля
доступа к предоставляемым сервисам.
Предоставляемый ЕСИА механизм контроля доступа на основе
маркеров доступа (access token) должен быть основан на спецификации
OAuth 2.0, а особенности реализации данного механизма в ЕСИА должны
быть описаны в методических рекомендациях по использованию ЕСИА.
Маркеры доступа должны содержать информацию о подмножестве
действий, доступных информационной системе. ЕСИА должна поддерживать
следующие способы получения маркера доступа информационной системой:
­ получение маркера доступа при наличии действительного разрешения,
полученного от пользователя ЕСИА;
­ получение маркера доступа при наличии действующего правила
разграничения доступа.
Подсистема авторизации должна идентифицировать запросившую
маркер доступа систему на основе проверки электронной подписи системы.
Подсистема авторизации при идентификации информационной системы
должна поддерживать использование следующих типов электронных
подписей:
­ усиленная квалифицированная электронная подпись;
­ неквалифицированная электронная подпись.
Выпускаемый подсистемой авторизации маркер доступа должен
предусматривать возможность ограничения времени действия.
4.1.8.3 Обеспечение контроля доступа к программным интерфейсам
ЕСИА на основе проверки маркеров доступа
ЕСИА должна производить авторизацию внешних систем таким
образом, чтобы доступ внешних систем к персональным данным
пользователя был возможен только при наличии действительного
разрешения, полученного от этого пользователя.
Контроль доступа должен осуществляться на основе проверки наличия
у системы, обратившейся к программному интерфейсу ЕСИА, действующего

18. маркера доступа, подтверждающего право выполнения запрошенной
операции.
Применяемые в ЕСИА механизмы контроля доступа при
использовании программных интерфейсов ЕСИА должны быть
документированы в методических рекомендациях по использованию ЕСИА.
4.1.9
Обеспечение интеграции с ФРГУ
В результате доработки ЕСИА должен быть обеспечен механизм
дополнения реестра органов и организаций в ЕСИА данными из системы
ФРГУ об органах и организациях и их иерархии (подчиненности).
4.1.10 Эксплуатационные показатели
В результате доработки системы эксплуатационные показатели должны
соответствовать тем показателям, которые закреплены в действующем на
момент сдачи работ Договоре на сопровождение системы.
4.1.11 Требования к информационной безопасности
Система информационной безопасности инфраструктуры электронного
правительства (далее – СИБ) должна представлять собой комплекс
взаимосвязанных организационных и технических мер по обеспечению
необходимого уровня защищенности всей инфраструктуры ЭП и ее
отдельных подсистем.
Выбор и реализация необходимых организационных и технических мер
по обеспечению безопасности информации должен быть осуществлен на
основании моделей угроз и моделей нарушителя ЕСИА в соответствии с
классом защищенности.
Развитие СИБ должно осуществляться организацией, имеющей
необходимые лицензии для проведения соответствующего вида работ на
основании детализированного Частного технического задания на развитие
подсистемы информационной безопасности ЕСИА.
В момент согласования Частного технического задания на развитие
подсистемы информационной безопасности ЕСИА Исполнитель должен
представить заказчику на утверждение проект акта об определении класса
защищенности системы в соответствии с руководящими документами ФСБ и
ФСТЭК России, а также в соответствии с требованиями совместных приказов
от 13 февраля 2008 г. № 55/86/20 «Об утверждении Порядка проведения
классификации информационных систем персональных данных» и от 31
августа 2010 г. №416/№484 «Об утверждении требований о защите
информации, содержащихся в информационных системах общего
пользования» вместе с материалами обоснования.
Достаточность, полнота и качество работ по защите информации
должны быть проверены на основании отдельной, согласованной с
заказчиком, методики и программы испытаний.
Требования к эксплуатации СИБ должны быть изложены в
эксплуатационной документации.

19. По результатам работ должны быть сформированы пакеты документов
на ЕСИА для проведения аттестационных мероприятий.
4.2 Требования к инфраструктурному обеспечению
Для обеспечения функционирования Систем необходимо использовать
инфраструктурное обеспечение, созданное ранее в рамках работ по
реализации мероприятий федеральной целевой программы «Электронная
Россия (2002-2010)» и мероприятий государственной программы Российской
Федерации «Информационное общество (2011 – 2020 годы)», реализованных
в 2012 году.
4.3 Требования по сохранности информации при авариях
Сохранность информации в развиваемых/создаваемых
должна обеспечиваться:
Системах
­ при разрушениях данных, при механических и электронных сбоях и
отказах в работе компьютеров: на основе программных процедур
восстановления информации с использованием хранимых копий баз
данных, программных файлов Систем, а также загружаемых файлов;
­ при сбое из-за ошибок в работе персонала: организационными и
защитными мерами, опирающимися на подготовленность персонала.
Системы должны восстанавливаться при перезапуске аппаратных
средств.
Для обеспечения сохранности информации в Системах должны быть
включены следующие функции:
­ резервное копирование операционных систем, баз данных,
программных и загружаемых файлов;
­ восстановление данных в непротиворечивое состояние при
программно-аппаратных сбоях (отключение электрического питания,
сбоях операционной системы и других) вычислительно-операционной
среды функционирования;
­ восстановление данных в непротиворечивое состояние при сбоях в
работе сетевого программного и аппаратного обеспечения.
4.4 Требования к надежности
Спроектированные архитектурные решения Систем должны быть
устойчивы по отношению к программно-аппаратным ошибкам, отказам
технических и программных средств, с возможностью восстановления ее
работоспособности и целостности информационного содержимого при
возникновении ошибок и отказов.
4.5 Требования к режимам функционирования
Системы должны иметь возможность функционировать в следующих
режимах:
­ штатный режим;

20. ­ режим системного администрирования.
Штатный
режим
должен
являться
основным
режимом
функционирования, обеспечивающим выполнение задач Системы.
Режим
системного
администрирования
должен
являться
технологическим режимом и использоваться для сопровождения Системы, в
том числе – изменения конфигурации, параметров работы, настроек,
выполнения регламентного обслуживания программно-технических средств.
Кроме этого, в режиме системного администрирования должны выполняться
функции,
связанные
с
реконфигурацией,
конвертированием
и
архивированием баз данных Системы. После возникновения отказа в какомлибо из компонентов Системы, режим должен обеспечивать перевод
отказавших компонентов в штатный режим функционирования после
идентификации возникшего отказа и устранения его причин.
5. ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К РЕЗУЛЬТАТАМ РАБОТ
5.1 Разработка частного технического задания
При разработке частного технического задания должны быть учтены
технические и функциональные возможности и характеристики средств и
систем вычислительной и телекоммуникационной инфраструктуры
электронного правительства.
Проект частного технического задания подготавливается в
соответствии с настоящим техническим заданием и должен быть согласован
с Заказчиком.
Оформление частного технического задания должно быть выполнено
согласно требованиям пункта 11 настоящего Технического задания.
5.2 Техническое проектирование
Технический проект на развитие Системы разрабатывается в
соответствии с настоящим Техническим заданием, разработанным
соответствующим Частным техническим заданием и должен быть согласован
с Заказчиком.
Специальные
требования
к
техническому
проектированию
определяются в требованиях к работам по соответствующим пунктам
настоящего Технического задания.
Оформление технического проекта должно быть выполнено согласно
требованиям пункта 11 настоящего Технического задания.
5.3 Разработка прикладного программного обеспечения
В ходе разработки/доработки прикладного программного обеспечения
должны быть выполнены следующие работы:
­ разработка/доработка
прикладного
программного
согласно требованиям настоящего Технического
соответствующего Частного технического задания;
обеспечения
задания и

21. ­ установка и настройка прикладного программного обеспечения на
подготовленные технические средства, с установленным и
настроенным системным программным обеспечением.
­ оформление исходных текстов прикладного программного обеспечения
и программной документации согласно требованиям пункта 11
настоящего Технического задания.
5.4 Разработка эксплуатационной документации
Состав комплекта эксплуатационной документации для Системы
уточняется в соответствующем Частном техническом задании.
Оформление эксплуатационной документации должно быть выполнено
согласно требованиям пункта 11 настоящего Технического задания.
5.5 Работы по обеспечению информационной безопасности
Подсистема информационной безопасности (далее - ПИБ) должна
представлять собой комплекс взаимосвязанных организационных и
технических мер по обеспечению необходимого уровня защищенности
системы.
Выбор и реализация необходимых организационных и технических мер
по обеспечению безопасности информации должен быть осуществлен на
основании моделей угроз и моделей нарушителя Системы.
Развитие подсистемы обеспечения информационной безопасности
Системы должно осуществляться на основании Частного технического
задания на развитие подсистемы информационной безопасности Системы.
По результатам работ должен быть сформирован пакет документов для
проведения аттестационных мероприятий Системы.
6. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
6.1 Требования к оформлению
Отчетная документация должна прилагаться в бумажном и
электронном виде (на оптическом CD или DVD носителе) на русском языке.
Вспомогательная документация (не указанная в качестве непосредственного
результата работ) передается только в электронном виде.
Для каждого этапа должен быть представлен краткий отчет в форме
презентации.
6.2 Проектная и рабочая документация
Проектная и рабочая документация должна разрабатываться с учетом
требований комплекса государственных стандартов «Информационная
технология. Комплекс стандартов на автоматизированные системы»:
­ ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;

22. ­ ГОСТ 34.003-90 «Автоматизированные системы. Термины и
определения»;
­ ГОСТ
34.602-89
«Техническое
задание
на
создание
автоматизированной системы»;
­ ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при
создании автоматизированных систем»;
­ ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»;
­ РД 50-34.698-90 «Автоматизированные системы. Требования к
содержанию документов»;
­ ГОСТ 19.301-79 «Программа и методика испытаний. Требования к
содержанию и оформлению»;
­ ГОСТ 2.601-2006 «ЕСКД. Эксплуатационные документы»;
­ ГОСТ 2.106-96 «ЕСКД. Текстовые документы» (с изменениями от 22
июня 2006 года);
­ ГОСТ 2.120-73 «ЕСКД. Технический проект» (с изменениями от 22
июня 2006 года).
6.3 Исходные тексты и программная документация
Для каждой разрабатываемой/дорабатываемой системы должны быть
представлены в электронном виде Исполнителем (на оптическом CD или
DVD носителе):
­ исходные тексты прикладного программного обеспечения, включая
контрольные суммы для каждого файла по алгоритму MD5;
­ инструкция по сборке из исходных текстов рабочего прикладного
программного обеспечения;
­ исполняемые файлы (где применимо), включая контрольные суммы
для каждого файла по алгоритму MD5;
­ описание программных средств, содержащее сведения об их
логической структуре и среде функционирования, а также описание
методов, приемов и правил эксплуатации технологических средств,
используемых при их создании;
­ описание применения, содержащее сведения о назначении
программных средств, области применения, применяемых методах,
классе решаемых задач, ограничениях при применении, минимальной
конфигурации технических средств, среде функционирования и
порядке работы.
6.4 Требования к оформлению документации по испытаниям систем
Испытания развиваемых/создаваемых систем должны проводиться с
учетом требований ГОСТ 34.603-92 «Виды испытаний автоматизированных
систем».
Результатами проведения испытаний систем являются следующие
отчетные документы:

23. ­ Программа и методика предварительных комплексных испытаний
системы;
­ Протокол предварительных комплексных испытаний системы;
­ Акт приемки системы в опытную эксплуатацию;
­ Программа опытной эксплуатации системы;
­ Журнал опытной эксплуатации системы;
­ Акт о завершении опытной эксплуатации и допуске к приемочным
испытаниям системы;
­ Программа и методика приемочных испытаний системы;
­ Протокол приёмочных испытаний системы;
­ Единый протокол приемочных испытаний системы, обобщающий все
протоколы испытаний и содержащий заключение о (не-) соответствии
системы требованиям Технического Задания и (не-) возможности
оформления акта приемки системы в постоянную эксплуатацию.
Формы отчетных документов по испытаниям систем приведены в
Приложении № 2 к настоящему Техническому заданию.
6.5 Перечень технической документации, предъявляемой по окончании
работ
Для ЕСИА должна быть разработана следующая техническая
документация:
1. Частное техническое задание на развитие ЕСИА;
2. Технический проект на развитие ЕСИА;
3. Частное
техническое
задание
на
развитие
подсистемы
информационной безопасности ЕСИА;
4. Отчетные документы по предварительным комплексным испытаниям
ЕСИА в составе:
­ Программа и методика проведения предварительных комплексных
испытаний ЕСИА;
­ Протокол проведения предварительных комплексных испытаний
ЕСИА;
5. Эксплуатационная документация ЕСИА в составе:
­ Руководство пользователя ЕСИА;
­ Руководство администратора ЕСИА;
6. Отчетные документы по опытной эксплуатации ЕСИА в составе:
­
­
­
­
Акт приемки ЕСИА в опытную эксплуатацию;
Журнал опытной эксплуатации ЕСИА;
Программа опытной эксплуатации ЕСИА;
Акт о завершении опытной эксплуатации и допуске ЕСИА к
приемочным испытаниям;
7. Отчетные документы по приёмочным испытаниям ЕСИА в составе:

24. ­ Программа и методика приёмочных испытаний ЕСИА;
­ Протокол приёмочных испытаний ЕСИА;
8. Методические рекомендации по использованию ЕСИА;
9. Регламент
взаимодействия
Участников
информационного
взаимодействия с Оператором единой системы идентификации и
аутентификации и Оператором инфраструктуры электронного
правительства при организации информационно-технологического
взаимодействия информационных систем с использованием ЕСИА;
10.Проект детализированной модели угроз безопасности информации
ЕСИА;
11.Проект дифференцированной модели возможностей вероятного
нарушителя правил обеспечения безопасности информации ЕСИА;
12.Комплект документов для переаттестации ЕСИА;
13.Исполняемые коды, исходные тексты и программная документация
доработанного прикладного программного обеспечения ЕСИА,
представленные на CD или DVD носителе.
6.6 Требования к разработке детализированной модели угроз
безопасности информации системы и дифференцированной модели
возможностей вероятного нарушителя правил обеспечения
безопасности информации системы
Разработка проектов детализированных моделей угроз безопасности
информации систем должна проводиться в соответствии со следующими
требованиями:
­ требованиями нормативно-методических документов ФСТЭК России
«Методика определения актуальных угроз безопасности персональных
данных при их обработке в информационных системах персональных
данных» и «Базовая модель угроз безопасности персональных данных
при их обработке в информационных системах персональных данных»;
­ требованиями нормативно-методического документа ФСБ России
«Методические рекомендации по обеспечению с помощью
криптографических средств безопасности персональных данных при их
обработке в информационных системах персональных данных с
использованием средств автоматизации»;
­ отдельными положениями руководящих документов Гостехкомиссии
России «Концепция защиты средств вычислительной техники и
автоматизированных систем от несанкционированного доступа к
информации» и «Автоматизированные системы. Защита от
несанкционированного доступа к информации. Классификация
автоматизированных систем и требования по защите информации»;

25. ­ отдельными положениями нормативно-методического документа
Гостехкомиссии России «Специальные требования и рекомендации по
технической защите конфиденциальной информации (СТР-К)».
­ Разработка проектов дифференцированных моделей возможностей
вероятного нарушителя правил обеспечения безопасности информации
Систем должна проводиться в соответствии со следующими
требованиями:
­ требованиями нормативно-методического документа ФСБ России
«Методические рекомендации по обеспечению с помощью
криптографических средств безопасности персональных данных при их
обработке в информационных системах персональных данных с
использованием средств автоматизации»;
­ требованиями нормативно-методического документа ФСТЭК России
«Базовая модель угроз безопасности персональных данных при их
обработке в информационных системах персональных данных»;
­ отдельными положениями нормативно-технических документов ФСБ
России «Требования к средствам криптографической защиты
конфиденциальной информации» и «Требования по защите
конфиденциальной информации от несанкционированного доступа в
автоматизированных информационных системах, расположенных на
территории Российской Федерации»;
­ внутренними методиками ФСБ России.
В случае принятия решения об отнесении вероятного нарушителя к
типу Н3 базовой модели нарушителя или выше, и/или классификации
автоматизированной информационной системы по требованиям ФСБ России
согласованный с Заказчиком проект модели нарушителя направляется в
установленном порядке на согласование в ФСБ России.
6.7 Требования к разработке комплекта документов для аттестации
(переаттестации) системы
Разработка комплекта документов для аттестации (переаттестации) по
требованиям безопасности информации (с участием специальной
уполномоченной организации) должна проводиться в соответствии с:
­ требованиями нормативно-методических документов ФСТЭК России
«Основные мероприятия по организации и техническому обеспечению
безопасности
персональных
данных,
обрабатываемых
в
информационных системах персональных данных», «Рекомендации по
обеспечению безопасности персональных данных при их обработке в
информационных системах персональных данных»;
­ положениями нормативно-методического документа Гостехкомиссии
России «Специальные требования и рекомендации по технической
защите конфиденциальной информации (СТР-К)»;
­ нормами руководящего документа Гостехкомиссии России «Временное
положение по организации разработки, изготовления и эксплуатации

26. программных и технических средств защиты информации от
несанкционированного доступа в автоматизированных системах и
средствах вычислительной техники»;
­ отельными требованиями нормативно-методического документа ФСБ
России «Положение о разработке, производстве, реализации и
эксплуатации шифровальных (криптографических) средств защиты
информации (Положение ПКЗ-2005)»;
­ положениями Комплекса стандартов на автоматизированные системы
Национальной системы стандартизации Российской Федерации и
ГОСТ Р 51583-2000 «Защита информации. Порядок создания
автоматизированных систем в защищённом исполнении. Общие
положения» и ГОСТ Р 51624-2000 «Защита информации.
Автоматизированные системы в защищённом исполнении. Общие
требования».
от Заказчика:
Президент открытого
акционерного общества
междугородной и международной
электрической связи
«Ростелеком»
от Исполнителя:
_____________ С.Б. Калугин
М.П.
Приложение № 1
к Техническому заданию
Процесс регистрации в ЕСИА
Общие требования: Процесс регистрации должен быть построен
максимально линейно и одинаково для всех видов пользователей – граждан
РФ, иностранных граждан, лиц без гражданства, представителей
юридических лиц. Должен быть упразднён выбор типа учетной записи
пользователем.

27. начало
1. Создание учетной
записи
2. Заполнение
профиля и
верификация
данных
нет
Поблизости есть
уполномоченная
организация?
Переходный период
да
Отправка заказного
письма с кодом
активации
4. Подтверждение
личностиполномочий
с использованием КЭП
3. Подтверждение личности
или полномочий в
уполномоченной организации
Ввод кода активации
Финализация
стандартной учетной
записи
конец
1. Создание учетной записи:
1.1 Пользователь переходит на страницу регистрации по ссылке
со страницы авторизации ЕСИА, с Портала госуслуг или другого веб-сайта.
1.2 Пользователь указывает из возможных каналов коммуникации с
ним. По умолчанию –
номер мобильного телефона (MSISDN)1.
1
Важно отметить приоритетность использования в процессе регистрации MSISDN, так как указанный канал
является в какой то степени уже подтвержденным, кроме того уменьшает возможность фрода и создания
неограниченного количества «фальшивых» учетных записей , так как процесс получения MSISDN связан с
затратами пользователя и создать на базе оператора бесконечное количество номеров является затратным
для потенциальных мошенников.