Идентификатор участника электронного документооборота. Где взять идентификатор landocs

Генерация запроса на сертификат и закрытого ключа

В ППО «СЭД» производится формирование запроса на сертификат и генерация закрытого ключа как для пользователей только ППО «СЭД» (обычная), так и формирование Единого универсального сертификата (ЕУС), предназначенного для пользователей нескольких систем: СЭД, Ландокс, ООС, АСФК. Таким образом, сертификаты, сгенерированные в СЭД, универсальны для всех систем (в зависимости от параметров).

Для генерации закрытого ключа выполните следующие действия.

Откройте пункт меню «Администрирование – Криптозащита – Генерация ключей ЭЦП и запроса на сертификацию». Откроется окно «Генерация запроса на сертификат и закрытого ключа».

1. Генерация запроса на сертификат и закрытого ключа

В окне «Генерация запроса на сертификат и закрытого ключа» заполните поля:

«Наименование абонента» – введите фамилию имя и отчество владельца закрытого ключа или наименование службы/сервиса/АРМ/сервера для которого запрашивается сертификат. Поле обязательно для заполнения.
«Наименование организации» – выберите из списка АРМ абонента сертификата (по умолчанию указан текущий АРМ пользователя).
«Криптобиблиотека» – определяется тип используемой СКЗИ (по умолчанию тип уже определён как Ms Crypto API 2.0, что соответствует криптосистеме КриптоПро CSP 3.0/3.6).
«Генерировать запрос на ЕУС (единый универсальный сертификат)» – при установке данного флага будет генерироваться запрос на единый универсальный сертификат и становится доступным поле «Роли владельца сертификата». По умолчанию флаг установлен. Если флаг отключен, то производится генерация запроса на сертификат и закрытого ключа только для пользователей ППО «СЭД» (обычная)
«Роли владельца сертификата» – в поле отображается список значений из справочника «Роли владельца сертификата» в виде древовидной структуры с возможностью отметить (включить чекбокс) нужные пункты. Для раскрытия ветви дерева нажать «+», для закрытия – нажать «-» возле узла. Для назначения роли нужно отмечать конечные пункты ветви (при этом все вышестоящие узлы отмечаются автоматически). Допускается отмечать несколько пунктов. Для отмены назначенной роли/ролей достаточно снять галочку с корневого узла (при этом все нижестоящие пункты очищаются автоматически). Список ролей зависит от уровня АРМ, на котором формируется запрос на сертификат. На АРМ Сервера доступны все роли.

Внимание! Не допускается отмечать корневую роль без отметки подролей для указанной корневой роли.

Основные роли, доступные при создании сертификата:

«Подпись запросов на издание сертификатов ключей подписи» – позволяет руководителю подписывать передаваемые в ТОФК запросы на сертификат других сотрудников организации.

Примечание. Для получения сертификата руководителя организации необходимо указать роль «Подпись запросов на издание сертификатов ключей подписи».

Примечание. При генерации ЕУС для работы в АСФК обязательно также выбрать роль «Работа с ООС (Аутентификация клиента)».

«Landocs. Делопроизводство» – сертификат предназначен для использования в Landocs.
«СЭД. Электронный документооборот» – сертификат предназначен для использования в ППО «СЭД».
«СПТО. Передача статистической информации о технологических операциях – сертификат предназначен для использования в СПТО.
«Работа с ООС (Аутентификация клиента) – Подпись пакетов информационного обмена между системами» – используется для подписи транспортных пакетов при обмене между системами.
«Работа с ООС (Аутентификация клиента) – Заказчик – Должностное лицо с правом подписи контракта» – используется для получения сертификата должностного лица, имеющего право подписи контракта (копии контракта).
«ЭЦП в системе внутриведомственного документооборота» – сертификат предназначен для внутриведомственного документооборота подразделений Министерства Юстиции.

Примечание. Согласно документу «Описание структуры и порядка использования унифицированного сертификата ЭЦП» роль «Аутентификация клиента» имеет OID 1.3.6.1.5.5.7.3.2. Данный OID встроен в роль «Работа с ООС», т.е. если при генерации запроса на сертификат была указана роль «Работа с ООС», то в запросе обязательно будет и аутентификация клиента. Наличие OID в запросе можно посмотреть в СЭД по пути «Администрирование – Криптозащита – Просмотр запроса на сертификат» (см. п. 1.1.1, рисунок 10).

Для перехода на следующий шаг мастера нажмите кнопку «Далее>».

2. Заполнение параметров сертификата

В появившемся окне введите значения (см. рисунок 2):

«Идентификатор ключа (Фамилия Имя Отчество владельца ключа)» – вводится фамилия, имя, отчество владельца сертификата в виде «Фамилия Имя Отчество» или наименование службы/сервиса/АРМ/сервера, для которого запрашивается сертификат. Поле обязательно для заполнения. По умолчанию заполняется из поля «Наименование абонента» предыдущего окна.
«Фамилия» – заполняется фамилия владельца сертификата с большой буквы в одно слово без пробелов. Поле обязательно для заполнения. По умолчанию заполняется значением из поля «Идентификатор ключа».
«Имя Отчество» – имя и отчество владельца сертификата в формате «Имя Отчество» в два слова, разделенных одним пробелом. Поле обязательно для заполнения. По умолчанию заполняется значением из поля «Идентификатор ключа».
«Инициалы» – инициалы владельца сертификата без пробелов. Поле доступно и обязательно только при выборе роли «Landocs». Если заполнено поле «Имя Отчество» и разрешено для редактирования поле «Инициалы», то по нажатию кнопки «>» автоматически заполняется поле «Инициалы».
«Страна» – заполняется двухбуквенным кодом страны в соответствии с ISO 3166, в которой зарегистрирована организация. Поле обязательно для заполнения. Для России по умолчанию указывается RU.
«Регион» – наименование региона, в котором зарегистрирована организация. Заполняется значением «Наименование» из справочника «Регионы РФ». Поле обязательно для заполнения для всех систем, кроме СМЭВ. Список значений поля «Регион» приведен в Приложении 1.
«Город» – заполняется наименованием города (населённого пункта), в котором зарегистрирована организация. Поле обязательно для заполнения.
«Должность» – должность владельца сертификата. Поле обязательно для заполнения.
«Организация» – наименование организации владельца сертификата. Указывается сокращенное наименование организации (но не более первых 64 символов). При отсутствии сокращенного наименования указывается краткое наименование - наименование, которое используется при оформлении платежных и иных документов в случаях, когда информация, подлежащая к заполнению в обязательном порядке, имеет ограничения по числу символов. Поле обязательно для заполнения. По умолчанию заполняется наименованием АРМ абонента сертификата.
«Формализованная должность» – поле доступно и обязательно для заполнения только при выборе роли «АСФК». Наименование должности выбирается из выпадающего списка.
«Подразделение 1-го уровня» – организационное подразделение владельца сертификата1-го уровня. Для руководителя организации указывается значение «Руководство». Поле не обязательно для заполнения.
«Подразделение 2-го уровня» – организационное подразделение владельца сертификата 2-го уровня. Обязательно для заполнения, если выбраны роли «АСФК» или «СПТО».
«E-mail» – адрес электронной почты владельца сертификата. Обязательно для заполнения для ролей ООС, ГМУ и АСФК. Адрес должен соответствовать шаблону «*@*.*».
«ИНН» – индивидуальный номер налогоплательщика владельца СКП – юридического лица. Поле доступно и обязательно для заполнения, если выбрана роль ООС, СМЭВ (Для юридического лица для подписания ЭД при межведомственном взаимодействии). Поле должно содержать 10 или 12 символов.
«КПП» – код причины постановки на учет. Поле доступно для заполнения, если выбрана роль ООС. Поле должно содержать 9 символов.
«Экспортируемый закрытый ключ» – указывается возможность переноса ключа ЭЦП на другой носитель (если выбрано значение «нет», то контейнер с ключом нельзя будет копировать). По умолчанию указано значение «да».
«Учетный номер организации СПЗ» – учетный номер организации по СПЗ. Поле доступно и обязательно для заполнения при выборе роли ООС (длина поля – 11 символов).
«ОГРН» – основной государственный регистрационный номер владельца СКП – юридического лица (длина поля – 13 символов). Поле обязательно для заполнения, если выбрана роль ООС, СМЭВ (Для юридического лица для подписания ЭД при межведомственном взаимодействии).
«СНИЛС» – страховой номер индивидуального лицевого счета владельца сертификата – физического лица. Поле обязательно для заполнения, если выбрана роль СМЭВ (Уполномоченное лицо для подписания ЭД при межведомственном взаимодействии).
«Идентификатор безопасности» – поле доступно и обязательно для заполнения при выборе роли «Landocs», 36 символов. Если у пользователя уже есть сертификат Landocs, то необходимо заполнить поле его значением.
«Учетный номер организации ГМУ» – учетный номер Государственного (муниципального) учреждения. Поле доступно и обязательно для заполнения при выборе роли ГМУ (длина поля – 13 символов).
«Учетная запись пользователя АСФК» – поле доступно и обязательно для заполнения при выборе роли АСФК (длина поля – 255 символов).
«Адрес» – адрес места работы (улица и номер дома) владельца сертификата. Поле доступно и обязательно для заполнения при выборе роли «Landocs».

Заполнив все значения диалога своими данными, нажмите кнопку «Далее>» (см. рисунок 2).
В системе предусмотрена распечатка акта подтверждения подлинности сертификата, для этого следует установить флаг в поле «Распечатать заявку на получение сертификата ключа ЭЦП». Запрошенный документ будет выведен в форму MS Word, которую далее можно распечатать стандартными средствами MS Word.

3. Генерация запроса на сертификат

Для создания закрытого ключа и формирования запроса на сертификат нажмите кнопку «Выполнить» (см. рисунок 3).
Далее откроется окно выбора устройства считывания для носителя закрытого ключа (см. рисунок 4). По умолчанию указан «Реестр». Если носитель закрытого ключа у вас определён как дискета 3.5” (флеш-драйв, Rutoken), то перед нажатием кнопки «ОК» необходимо подключить носитель закрытого ключа и указать его в поле «Устройства» (для каждого пользователя должен быть отдельный носитель).

4. Выбор считывающего устройства

Далее появится диалог датчика случайных чисел, формирующего комбинацию закрытого ключа, и форма запроса пароля на сгенерированный ключ (см. рисунки 5, 6).

5. Датчик случайных чисел

6. Установка пароля

В случае определения пароля для закрытого ключа его ввод будет необходим перед каждой операцией обращения к функциям криптозащиты, если он не был сохранён в системе. Если пароль для доступа к ключам не используется, можно оставить поля диалога пустыми и нажать «ОК» (см. рисунок 6). Правила формирования пароля описаны в п. Error: Reference source not found.
Когда закрытый ключ сервера СЭД будет сгенерирован (при этом на ключевом носителе будет создан контейнер с закрытым ключом и в него будут помещены файлы закрытого ключа header.key, masks.key, masks2.key, name.key, primary.key, primary2.key), система автоматически сформирует запрос на сертификат – файл с расширением *.req и отобразит путь, куда он будет помещён (см. рисунок 7).

7. Директория сохранения нового ключа

После определения каталога с запросом на сертификат мастер генерации запроса на сертификат MS Crypto API 2.0 завершит свою работу и для его закрытия следует нажать кнопку «Готово».
Полученный запрос на сертификат в электронном виде вместе с бумажной копией следует доставить в СВУЦ (сеть ведомственных удостоверяющих центров) для его подтверждения, где на основе отправленного запроса на сертификат будет сформирован готовый сертификат открытого ключа электронной цифровой подписи (файл с расширением *.cer).

Примечание: Кроме сертификата с открытым ключом сервера СЭД для регистрации криптонастроек необходим открытый ключ корневого сертификата удостоверяющего центра. Без данного сертификата регистрация в системе подписи сервера СЭД невозможна.

Полученный комплект ключевой информации можно использовать в системе, настроив его параметры с помощью Мастера установки сертификата (см. п. Error: Reference source not found).

1.1.1.Просмотр сформированного запроса на сертификат

Для просмотра сформированного запроса на сертификат выберите пункт меню «Администрирование – Криптозащита – Просмотр запроса на сертификат». В открывшемся окне «Выбор файла» (см. рисунок 8) укажите путь к файлу запроса на сертификат (файл с расширением .req).

8. Выбор файла запроса на сертификат

Откроется форма просмотра запроса на сертификат, состоящая из двух вкладок: «Параметры сертификата» и «Роли владельца сертификата» (см. рисунки 9, 10).

9. Форма «Запрос на сертификат». Вкладка «Параметры сертификата»

На вкладке «Параметры сертификата» отображаются параметры в соответствии с п. .

10. Форма «Запрос на сертификат». Вкладка «Роли владельца сертификата»

На вкладке «Роли владельца сертификата» отображается список назначенных ролей. Для просмотра параметров выбранной роли нажать кнопку (редактировать/просмотреть) на панели инструментов вкладки. Откроется форма «Роль владельца сертификата (см. рисунок 11). Для выхода из формы нажать кнопку «Закрыть».

11. Роль владельца сертификата

gigabaza.ru

Генерация запроса на сертификат и закрытого ключа

ИНСТРУКЦИЯ ПО ГЕНЕРАЦИИ ЗАКРЫТОГО КЛЮЧА И ЗАПРОСА НА СЕРТИФИКАТ В ФОРМАТЕ ЕУС Откройте программу СЭД и вставьте чистую дискету Генерация запроса на ЕУС и закрытого ключа

ИНСТРУКЦИЯ ПО ГЕНЕРАЦИИ ЗАКРЫТОГО КЛЮЧА

И ЗАПРОСА НА СЕРТИФИКАТ В ФОРМАТЕ ЕУС

Откройте программу СЭД и вставьте чистую дискету.

Генерация запроса на ЕУС и закрытого ключа

Для генерации запроса на ЕУС и закрытого ключа выполните следующие действия.

Откройте пункт меню «Администрирование – Криптозащита – Генерация ключей ЭЦП и запроса на сертификацию».

1. Генерация запроса на сертификат и закрытого ключа

В окне «Генерация запроса на сертификат и закрытого ключа» заполните поля (см. рисунок 1):

«Наименование абонента» – введите фамилию имя и отчество владельца закрытого ключа, для которого запрашивается сертификат. Фамилия имя и отчество владельца заполняется полностью. Поле обязательно для заполнения.
«Наименование организации» – выберите из списка АРМ абонента сертификата (по умолчанию указан текущий АРМ пользователя).
«Криптобиблиотека» – определяется тип используемой СКЗИ (по умолчанию тип уже определён как Ms Crypto API 2.0, что соответствует криптосистеме КриптоПро CSP 2.0).
«Генерировать запрос на ЕУС (единый универсальный сертификат)» – при установке данного флага будет генерироваться запрос на единый универсальный сертификат и становится доступным поле «Роли владельца сертификата».
«Роли владельца сертификата» – в поле отображается список значений из справочника «Роли владельца сертификата» (поле «Назначение») в виде древовидной структуры с возможностью отметить (включить чекбокс) нужные пункты (строки справочника), у которых поле «Вкл.»(Enabled) имеет значение «True». Допускается отмечать несколько пунктов. Содержимое поля зависит от уровня АРМ, на котором формируется запрос на сертификат. На АРМ Сервера доступны все роли, на АРМ Клиента – только записи, у которых поле CertificatePolicies.FK имеет значение «False».

Основные роли, доступные при создании сертификата:

«Подпись пакетов информационного обмена между системами» – используется для подписи транспортных пакетов при обмене между системами.

«Подпись запросов на издание сертификатов ключей подписи» – позволяет руководителю подписывать передаваемые в ТОФК запросы на сертификат других сотрудников организации.

«СЭД. Электронный документооборот» – сертификат предназначен для использования в ППО «СЭД».

«ЭЦП в системе внутриведомственного документооборота» – сертификат предназначен для внутриведомственного документооборота подразделений Министерства Юстиции.

«Заказчик. ЭЦП Специалиста с правом подписи контракта» – используется в большинстве случаев для получения сертификата специалиста.

Для перехода на следующий шаг мастера нажмите кнопку «Далее>».

2. Генерация запроса на сертификат

В появившемся окне (см. рисунок 2) введите значения:

«Идентификатор ключа (Фамилия Имя Отчество владельца ключа)» – вводится фамилия, имя, отчество владельца сертификата в виде «Фамилия Имя Отчество», для которого запрашивается сертификат. Поле обязательно для заполнения. По умолчанию заполняется из поля «Наименование абонента» предыдущего окна.
«Фамилия» – заполняется фамилия владельца сертификата с большой буквы в одно слово без пробелов. Поле обязательно для заполнения. По умолчанию заполняется значением из поля «Идентификатор ключа».
«Имя Отчество» – имя и отчество владельца сертификата в формате «Имя Отчество» в два слова, разделенных одним пробелом. Поле обязательно для заполнения. По умолчанию заполняется значением из поля «Идентификатор ключа».
«Инициалы» – инициалы владельца сертификата без пробелов. На АРМ клиента поле не заполняется.
«Страна» – заполняется двухбуквенным кодом страны в соответствии с ISO 3166, в которой зарегистрирована организация. Поле обязательно для заполнения. Для России по умолчанию указывается RU.
«Регион» – наименование региона, в котором зарегистрирована организация. Заполняется значением «Наименование» из справочника «Регионы РФ». Поле обязательно для заполнения. Список значений поля «Регион» приведен в таблице Error: Reference source not found.
«Город» – заполняется наименованием города (населённого пункта), в котором зарегистрирована организация. Поле обязательно для заполнения.
«Должность» – должность владельца сертификата. Поле обязательно для заполнения.
«Организация» – наименование организации владельца сертификата. Поле обязательно для заполнения. По умолчанию заполняется наименованием АРМ абонента сертификата. Наименование организации должно соответствовать наименованию организации в Сводном реестре УБП, Перечне УБП или Информации из реестра.
«Формализованная должность» – наименование в свободной форме. На АРМ клиента поле не заполняется.
«Подразделение 1-го уровня» – организационное подразделение владельца сертификата1-го уровня. Поле обязательно для заполнения для всех ролей, кроме «СЭД».
«Подразделение 2-го уровня» – организационное подразделение владельца сертификата 2-го уровня. Поле необязательно для заполнения.
«E-mail» – адрес электронной почты владельца сертификата. Поле обязательно для заполнения.
«ИНН» – индивидуальный номер налогоплательщика. Поле обязательно для заполнения, если выбрана роль ООС. Поле должно содержать 10 или 12 символов.
«КПП» – код причины постановки на учет. Поле доступно для заполнения, если выбрана роль ООС. Поле должно содержать 9 символов.
«Экспортируемый закрытый ключ» – указывается возможность переноса ключа ЭЦП на другой носитель (если выбрано значение «нет», то контейнер с ключом нельзя будет копировать). По умолчанию указано значение «да».
«Адрес» – адрес организации владельца сертификата. На АРМ клиента поле не заполняется.
«Учетный номер организации (Код организации в СПЗ)» – поле доступно и обязательно для заполнения при выборе роли ООС.
«Идентификатор Landocs» – на АРМ клиента поле не заполняется.

Заполнив все значения диалога своими данными, нажмите кнопку «Далее>».

Таблица 3. Список названий регионов Российской Федерации

№	Название региона
	Ленинградская область

В форме «Генерация запроса на сертификат Ms Crypto API 2.0» (см. рисунок 4) необходимо установить флаг в поле «Распечатать заявку на получение сертификата ключа ЭЦП», так как только с данной распечатанной формой запрос на регистрацию ключей будет приниматься ТОФК. Запрошенный документ будет выведен в форму MS Word, который далее можно распечатать стандартными средствами MS Word.

4. Генерация запроса на сертификат

Для создания закрытого ключа и формирования запроса на сертификат нажмите кнопку «Выполнить».

Внимание! Если считыватель закрытого ключа у вас определён как дискета 3.5”, то перед нажатием кнопки «Выполнить» в дисковод необходимо вставить ключевую дискету, на которую будут записаны файлы закрытого ключа. В случае её отсутствия выведется соответствующее сообщение, и система будет пытаться обратиться к дисководу, пока не будет вставлена дискета.

Далее появится диалог датчика случайных чисел, формирующего комбинацию закрытого ключа, и форма запроса пароля на сгенерированный ключ (см. рисунок 5).
В случае определения пароля для закрытого ключа его ввод будет необходим перед каждой операцией обращения к функциям криптозащиты, если он не был сохранён в системе. Для того чтобы не использовать пароль для доступа к ключам, следует оставить поля диалога пустыми и нажать «ОК».

5. Запрос пароля на сгенерированный ключ

Когда закрытый ключ клиента СЭД будет сгенерирован (при этом на ключевом носителе будет создан контейнер с закрытым ключом, и в него будут помещены файлы закрытого ключа header.key, masks.key masks2.key name.key primary.key primary2.key), система автоматически сгенерирует запрос на сертификат – файл с расширением *.req и отобразит путь, куда он будет помещён (см. рисунок 6).

6. Директория сохранения запроса на сертификат

После определения каталога с запросом на сертификат мастер генерации запроса на сертификат MS Crypto API 2.0 завершит свою работу, и для его закрытия следует нажать кнопку «Готово».
Полученный запрос на сертификат (файл с расширением *.req) вместе с заявкой, заполненной, подписанной собственноручными подписями владельца и руководителя организации и заверенной оттиском печати организации, следует доставить в УФК по Ленинградской области или соответствующее отделение.
На сервере СЭД клиентский запрос на сертификат в электронном виде вместе с бумажной копией доставляется в СВУЦ (сеть ведомственных удостоверяющих центров) для его подтверждения, где на основе отправленного запроса на сертификат будет сформирован сертификат открытого ключа электронно-цифровой подписи (файл с расширением *.cer).

Примечание: Кроме сертификата с открытым ключом клиента СЭД для регистрации криптонастроек необходим открытый ключ корневого сертификата удостоверяющего центра. Без данного сертификата регистрация в системе подписи клиента СЭД невозможна.

Сертификат открытого ключа ЭЦП клиента (файл с расширением *.cer) доставляется с сервера СЭД на клиент СЭД, где его необходимо зарегистрировать.

textarchive.ru

Персональный сайт - Сервер СЭД. Руководство администратора, продолжение (часть 4)

…bsp; Версия криптобиблиотеки, с помощью которой подписан пакет.

8.2.5. Шифрование пакетов

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

Для сокращения объема зашифрованных данных в системе предусмотрена возможность их предварительного сжатия с помощью встроенного архиватора. Данные после шифрования сжать нельзя. Параметр, устанавливающий или отменяющий режим сжатия данных, указывается при выборе настроек пользователя.

Шифрование данных осуществляется по алгоритму в соответствии с ГОСТ 28147-89. Шифрование данных выполняется открытым ключом (сертификатом) получателя шифрованных данных.

Внимание! Если абонент не укажет себя в списке абонентов, для которых шифруются данные, он не сможет их расшифровать!

Для выполнения шифрации исходными параметрами являются:

Криптографический профиль пользователя системы.
Тип криптобиблиотеки, с помощью которой подписан пакет.
UID Клиента, для какого шифруются данные.

8.2.6. Расшифрование пакетов

Расшифровка транспортных пакетов производится автоматически, если в настройках профиля абонента, получившего зашифрованные данные, указано наличие прав приема/отправки почты.

Распаковка данных, если они были сжаты, при расшифровке транспортных пакетов происходит автоматически.

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

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

Для выполнения дешифрации исходными параметрами являются:

Криптографический профиль пользователя системы.
Тип криптобиблиотеки, с помощью которой зашифрован пакет.

8.3. Настройка ключей криптозащиты

Настройка ключей криптозащиты информации в системе СЭД осуществляется в следующей последовательности:

– Генерация запроса на сертификат и закрытого ключа;

– Ввод нового криптографического профиля абонента;

– Установка нового сертификата абонента;

– Настройка расширенных прав подписи;

– Настройка количества подписей под документами;

– Дополнительные настройки криптозащиты.

Если настройка ключей криптозащиты информации выполняется для зарегистрированного в системе криптографического профиля, то ввод нового профиля не выполняется, а все остальные настройки осуществляются только в рамках используемой СКЗИ данного профиля в любой последовательности. Процедура ввода нового ключа в существующий профиль описана в п. 8.3.6 Ввод нового ключа в криптографический профиль абонента.

8.3.1. Генерация закрытого ключа

8.3.1.1. Генерация запроса на сертификат и закрытого ключа (обычная)

Для генерации закрытого ключа выполните следующие действия.

Откройте пункт меню «Администрирование – Криптозащита – Генерация ключей ЭЦП и запроса на сертификацию».

Рисунок 46. Генерация запроса на сертификат закрытого ключа

В окне «Генерация запроса на сертификат и закрытого ключа» заполните поля (см. рисунок 46):

– «АРМ абонента сертификата» – выберите из списка АРМ абонента сертификата (по умолчанию указан текущий АРМ пользователя).

– «Криптобиблиотека» – определяется тип используемой СКЗИ (по умолчанию тип уже определён как Ms Crypto API 2.0, что соответствует криптосистеме КриптоПро CSP 2.0/3.0/3.6).

– «Генерировать запрос на ЕУС (единый универсальный сертификат)» – при установке данного флага будет генерироваться запрос на единый универсальный сертификат (см. п. 8.3.1.2). По умолчанию флаг установлен. Для генерации обычного запроса флаг нужно снять.

Для перехода на следующий шаг мастера нажмите кнопку «Далее>» (см. рисунок 46).

Рисунок 47. Генерация запроса на сертификат

В появившемся окне введите значения (см. рисунок 47):

– «Инициалы» – инициалы владельца сертификата без пробелов. Поле доступно и заполняется только при генерации запроса на ЕУС (см. п. 8.3.1.2).

– «Должность» – должность владельца сертификата. Поле обязательно для заполнения.

– «Формализованная должность» – поле заполняется при формировании запроса на ЕУС (см. п. 8.3.1.2).

– «Подразделение 1-го уровня» – организационное подразделение владельца сертификата1-го уровня. При генерации обычного запроса поле необязательно для заполнения.

– «Подразделение 2-го уровня» – организационное подразделение владельца сертификата 2-го уровня. Поле необязательно для заполнения.

– «E-mail» – адрес электронной почты владельца сертификата. Поле обязательно для заполнения.

– «ИНН» – индивидуальный номер налогоплательщика. Поле доступно для заполнения при генерации запроса на ЕУС (см. п. 8.3.1.2).

– «КПП» – код причины постановки на учет. Поле доступно для заполнения при генерации запроса на ЕУС (см. п. 8.3.1.2).

– «Адрес» – поле заполняется при генерации запроса на ЕУС (см. п. 8.3.1.2).

– «Учетный номер организации» – поле заполняется при генерации запроса на ЕУС (см. п. 8.3.1.2).

– «Идентификатор Landocs» – поле заполняется при генерации запроса на ЕУС (см. п. 8.3.1.2).

Заполнив все значения диалога своими данными, нажмите кнопку «Далее>» (см. рисунок 47).

Таблица 3. Список названий регионов Российской Федерации

№	Название региона
	Республика Адыгея (Адыгея)
	Республика Башкортостан
	Республика Бурятия
	Республика Алтай
	Республика Дагестан
	Республика Ингушетия
	Кабардино-Балкарская Республика
	Республика Калмыкия
	Карачаево-Черкесская Республика
	Республика Карелия
	Республика Коми
	Республика Марий Эл
	Республика Мордовия
	Республика Саха (Якутия)
	Республика Северная Осетия – Алания
	Республика Татарстан
	Республика Тыва
	Удмуртская Республика
	Республика Хакасия
	Чеченская Республика
	Чувашская Республика – Чувашия
	Алтайский край
	Краснодарский край
	Красноярский край
	Приморский край
	Ставропольский край
	Хабаровский край
	Амурская область
	Архангельская область и Ненецкий автономный округ
	Астраханская область
	Белгородская область
	Брянская область
	Владимирская область
	Волгоградская область
	Вологодская область
	Воронежская область
	Ивановская область
	Иркутская область
	Калининградская область
	Калужская область
	Камчатский край
	Кемеровская область
	Кировская область
	Костромская область
	Курганская область
	Курская область
	Ленинградская область
	Липецкая область
	Магаданская область
	Московская область
	Мурманская область
	Нижегородская область
	Новгородская область
	Новосибирская область
	Омская область
	Оренбургская область
	Орловская область
	Пензенская область
	Пермский край
	Псковская область
	Ростовская область
	Рязанская область
	Самарская область
	Саратовская область
	Сахалинская область
	Свердловская область
	Смоленская область
	Тамбовская область
	Тверская область
	Томская область
	Тульская область
	Тюменская область
	Ульяновская область
	Челябинская область
	Забайкальский край
	Ярославская область
	г. Москва
	г. Санкт-Петербург
	Еврейская автономная область
	Ханты-Мансийский автономный округ – Югра
	Чукотский автономный округ
	Ямало-Ненецкий автономный округ
	Иные территории, включая, г. Байконур

В системе предусмотрена распечатка акта подтверждения подлинности сертификата, для этого следует установить флаг в поле «Распечатать заявку на получение сертификата ключа ЭЦП». Запрошенный документ будет выведен в форму MS Word, которую далее можно распечатать стандартными средствами MS Word.

Рисунок 48. Генерация запроса на сертификат

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

Внимание! Если считыватель закрытого ключа у Вас определён как дискета 3.5”, то перед нажатием кнопки «Выполнить» в дисковод необходимо вставить ключевую дискету, на которую будут записаны файлы закрытого ключа. В случае её отсутствия выведется соответствующее сообщение, и система будет пытаться обратиться к дисководу, пока не будет вставлена дискета.

Далее появится диалог датчика случайных чисел, формирующего комбинацию закрытого ключа, и форма запроса пароля на сгенерированный ключ (см. рисунок 49).

Рисунок 49. Установка пароля

В случае определения пароля для закрытого ключа его ввод будет необходим перед каждой операцией обращения к функциям криптозащиты, если он не был сохранён в системе. Если пароль для доступа к ключам не используется, можно оставить поля диалога пустыми и нажать «ОК» (см. рисунок 49).

10. Когда закрытый ключ сервера СЭД будет сгенерирован (при этом на ключевом носителе будет создан контейнер с закрытым ключом и в него будут помещены файлы закрытого ключа header.key, masks.key, masks2.key, name.key, primary.key, primary2.key), система автоматически сформирует запрос на сертификат – файл с расширением *.req и отобразит путь, куда он будет помещён (см. рисунок 50).

Рисунок 50. Директория сохранения нового ключа

11. После определения каталога с запросом на сертификат мастер генерации запроса на сертификат MS Crypto API 2.0 завершит свою работу и для его закрытия следует нажать кнопку «Готово».

12. Полученный запрос на сертификат в электронном виде вместе с бумажной копией следует доставить в СВУЦ (сеть ведомственных удостоверяющих центров) для его подтверждения, где на основе отправленного запроса на сертификат будет сформирован готовый сертификат открытого ключа электронно-цифровой подписи (файл с расширением *.cer).

8.3.1.2. Генерация запроса на ЕУС и закрытого ключа

Для генерации запроса на ЕУС и закрытого ключа выполните следующие действия.

Откройте пункт меню «Администрирование – Криптозащита – Генерация ключей ЭЦП и запроса на сертификацию».
В окне «Генерация запроса на сертификат и закрытого ключа» заполните поля (см. рисунок 51):

Основные роли, доступные при создании сертификата:

- «АСФК» – сертификат предназначен для использования в ППО «АСФК».

- «Landocs. Делопроизводство» – сертификат предназначен для использования в Landocs.

- «СЭД. Электронный документооборот» – сертификат предназначен для использования в ППО «СЭД».

- «Заказчик. ЭЦП Специалиста с правом подписи контракта» – используется в большинстве случаев для получения сертификата специалиста.

Рисунок 51. Генерация запроса на ЕУС и закрытого ключа

Для перехода на следующий шаг мастера нажмите кнопку «Далее>».

Рисунок 52. Генерация запроса на сертификат

В появившемся окне введите значения (см. рисунок 52):

– «Должность» – должность владельца сертификата. Поле обязательно для заполнения.

– «Подразделение 1-го уровня» – организационное подразделение владельца сертификата1-го уровня. Поле обязательно для заполнения для всех ролей, кроме «СЭД».

– «E-mail» – адрес электронной почты владельца сертификата. Обязательно для заполнения. Адрес должен соответствовать шаблону «*@*.*».

– «Учетный номер организации» – поле доступно и обязательно для заполнения при выборе роли ООС.

– «Идентификатор Landocs» – поле доступно и обязательно для заполнения при выборе роли «Landocs», 36 символов. Если у пользователя уже есть сертификат Landocs, то необходимо заполнить поле его значением.

Заполнив все значения диалога своими данными, нажмите кнопку «Далее>» (см. рисунок 52). Последующие действия совпадают с шагами 6 –12 пункта 8.3.1.1.

8.3.1.3. Просмотр сформированного запроса на сертификат

Для просмотра сформированного запроса на сертификат выберите пункт меню «Администрирование – Криптозащита – Просмотр запроса на сертификат». В открывшемся окне «Выбор файла» (см. рисунок 53) укажите путь к файлу запроса на сертификат (файл с расширением .req).

Рисунок 53. Выбор файла запроса на сертификат

Откроется форма просмотра запроса на сертификат, состоящая из двух вкладок: «Параметры сертификата» и «Роли владельца сертификата» (см. рисунки 54, 55).

Рисунок 54. Форма «Запрос на сертификат». Вкладка «Параметры сертификата»

Рисунок 55. Форма «Запрос на сертификат». Вкладка «Роли владельца сертификата»

На вкладке «Роли владельца сертификата» отображается список назначенных ролей. Для просмотра параметров выбранной роли нажать кнопку (редактировать/просмотреть) на панели инструментов вкладки. Откроется форма «Роль владельца сертификата (см. рисунок 56). Для выхода из формы нажать кнопку «Закрыть».

Рисунок 56. Роль владельца сертификата

8.3.2. Создание криптографического профиля абонента

Под созданием криптопрофиля понимается автоматическое заполнение параметров СКЗИ и формирование каталогов носителя ключа.

Выберите пункт меню «Администрирование – Криптозащита – Список абонентов ЭЦП». На экране появится форма списка документов «Криптографические профили» (см. рисунок 57).

Рисунок 57. Окно «Криптографические профили»

Для ввода нового профиля нажмите клавишу «Ins» или кнопку на панели инструментов списка абонентов (в левой части формы). Откроется диалог «Криптографический профиль» (см. рисунок 58).

Рисунок 58. Окно «Криптографический профиль»

В появившемся диалоге определяется фамилия, имя, отчество владельца криптопрофиля. Эти данные заносятся в поле «Наименование криптопрофиля». Сохранение введённых параметров производится кнопкой «ОК».

После того как для регистрируемого АРМ было определено наименование криптопрофиля, нужно выполнить настройку параметров криптозащиты. Для этого в правой верхней части формы «Криптографические профили» (см. рисунок 57) нажать кнопку . Откроется форма «Настройки криптографического профиля» (см. рисунок 59).

Рисунок 59. Окно «Настройки криптографического профиля»

Наименование криптографического профиля выбранного абонента заполняется автоматически. Значение может быть изменено путем выбора из списка криптографических профилей абонентов ЭЦП.

В поле «АРМ» из справочника выбирается рабочее место АРМ БУ.

Ниже наименования АРМ задаются режимы прав подписи документов, этот параметр должен выбираться, исходя из количества требуемых подписей под документами:

– «Не может подписывать документы» – отсутствие прав подписи документов.

– «Право подписи всех документов» – наличие прав подписи документов; при установке переключателя в данное положение обязательно нужно указать в соседнем поле количество подписей (право единственной подписью; право первой подписью; право второй подписью).

– «Расширенные права подписи» – установка расширенных прав подписи, которые необходимы для задания прав подписи в зависимости от параметров документа. При выборе данного режима активируется вкладка «Расширенное право подписи» (подробнее см. п. 8.3.3).

Внимание! При настройке СКЗИ необходимо добавить запись в справочник Количество подписей, о чем подробно описано в п. 8.3.7 «Настройка количества подписей под документами». В противном случае для документов данной организации не будут требоваться никакие подписи.

– «Использовать для шифрации/дешифрации, подписи/проверки подписи данных, передаваемых транспортной подсистемой» – значение параметра определяет использование права подписи и шифрации транспортных пакетов. Постановка флага включает шифрацию данных, передаваемых на удаленный АРМ.

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

– «Возможность обмена шифрованными данными только с выбранными клиентами» – администратор сервера СЭД для некоторых клиентов может включать шифрацию данных, а для некоторых нет.

– «Привязка шифрации данных к криптопрофилю» – некоторые криптопрофили сервера СЭД могут использовать шифрацию данных, а некоторые нет.

– «Синхронность настроек шиф

pposed.narod.ru

Обзор способов и протоколов аутентификации в веб-приложениях / Блог компании DataArt / Хабр

Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

Например, при попытке попасть в закрытый клуб вас идентифицируют (спросят ваше имя и фамилию), аутентифицируют (попросят показать паспорт и сверят фотографию) и авторизуют (проверят, что фамилия находится в списке гостей), прежде чем пустят внутрь.

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

Однако в современных системах существуют и более сложные схемы аутентификации и авторизации, о которых я расскажу далее. Но начнем с простого и понятного.

Аутентификация по паролю

Этот метод основывается на том, что пользователь должен предоставить username и password для успешной идентификации и аутентификации в системе. Пара username/password задается пользователем при его регистрации в системе, при этом в качестве username может выступать адрес электронной почты пользователя.

Применительно к веб-приложениям, существует несколько стандартных протоколов для аутентификации по паролю, которые мы рассмотрим ниже.

HTTP authentication Этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и до сих пор активно применяется в корпоративной среде. Применительно к веб-сайтам работает следующим образом:

Сервер, при обращении неавторизованного клиента к защищенному ресурсу, отсылает HTTP статус “401 Unauthorized” и добавляет заголовок “WWW-Authenticate” с указанием схемы и параметров аутентификации.
Браузер, при получении такого ответа, автоматически показывает диалог ввода username и password. Пользователь вводит детали своей учетной записи.
Во всех последующих запросах к этому веб-сайту браузер автоматически добавляет HTTP заголовок “Authorization”, в котором передаются данные пользователя для аутентификации сервером.
Сервер аутентифицирует пользователя по данным из этого заголовка. Решение о предоставлении доступа (авторизация) производится отдельно на основании роли пользователя, ACL или других данных учетной записи.

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

Basic — наиболее простая схема, при которой username и password пользователя передаются в заголовке Authorization в незашифрованном виде (base64-encoded). Однако при использовании HTTPS (HTTP over SSL) протокола, является относительно безопасной.Пример HTTP аутентификации с использованием Basic схемы.
Digest — challenge-response-схема, при которой сервер посылает уникальное значение nonce, а браузер передает MD5 хэш пароля пользователя, вычисленный с использованием указанного nonce. Более безопасная альтернативв Basic схемы при незащищенных соединениях, но подвержена man-in-the-middle attacks (с заменой схемы на basic). Кроме того, использование этой схемы не позволяет применить современные хэш-функции для хранения паролей пользователей на сервере.
NTLM (известная как Windows authentication) — также основана на challenge-response подходе, при котором пароль не передается в чистом виде. Эта схема не является стандартом HTTP, но поддерживается большинством браузеров и веб-серверов. Преимущественно используется для аутентификации пользователей Windows Active Directory в веб-приложениях. Уязвима к pass-the-hash-атакам.
Negotiate — еще одна схема из семейства Windows authentication, которая позволяет клиенту выбрать между NTLM и Kerberos аутентификацией. Kerberos — более безопасный протокол, основанный на принципе Single Sign-On. Однако он может функционировать, только если и клиент, и сервер находятся в зоне intranet и являются частью домена Windows.

Стоит отметить, что при использовании HTTP-аутентификации у пользователя нет стандартной возможности выйти из веб-приложения, кроме как закрыть все окна браузера.Forms authentication Для этого протокола нет определенного стандарта, поэтому все его реализации специфичны для конкретных систем, а точнее, для модулей аутентификации фреймворков разработки.

Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.

Пример forms authentication.

Приложение может создать session token двумя способами:

Как идентификатор аутентифицированной сессии пользователя, которая хранится в памяти сервера или в базе данных. Сессия должна содержать всю необходимую информацию о пользователе для возможности авторизации его запросов.
Как зашифрованный и/или подписанный объект, содержащий данные о пользователе, а также период действия. Этот подход позволяет реализовать stateless-архитектуру сервера, однако требует механизма обновления сессионного токена по истечении срока действия. Несколько стандартных форматов таких токенов рассматриваются в секции «Аутентификация по токенам».

Необходимо понимать, что перехват session token зачастую дает аналогичный уровень доступа, что и знание username/password. Поэтому все коммуникации между клиентом и сервером в случае forms authentication должны производиться только по защищенному соединению HTTPS.Другие протоколы аутентификации по паролю Два протокола, описанных выше, успешно используются для аутентификации пользователей на веб-сайтах. Но при разработке клиент-серверных приложений с использованием веб-сервисов (например, iOS или Android), наряду с HTTP аутентификацией, часто применяются нестандартные протоколы, в которых данные для аутентификации передаются в других частях запроса.

Существует всего несколько мест, где можно передать username и password в HTTP запросах:

URL query — считается небезопасным вариантом, т. к. строки URL могут запоминаться браузерами, прокси и веб-серверами.
Request body — безопасный вариант, но он применим только для запросов, содержащих тело сообщения (такие как POST, PUT, PATCH).
HTTP header —оптимальный вариант, при этом могут использоваться и стандартный заголовок Authorization (например, с Basic-схемой), и другие произвольные заголовки.

Распространенные уязвимости и ошибки реализации Аутентификации по паролям считается не очень надежным способом, так как пароли часто можно подобрать, а пользователи склонны использовать простые и одинаковые пароли в разных системах, либо записывать их на клочках бумаги. Если злоумышленник смог выяснить пароль, то пользователь зачастую об этом не узнает. Кроме того, разработчики приложений могут допустить ряд концептуальных ошибок, упрощающих взлом учетных записей.

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

Веб-приложение позволяет пользователям создавать простые пароли.
Веб-приложение не защищено от возможности перебора паролей (brute-force attacks).
Веб-приложение само генерирует и распространяет пароли пользователям, однако не требует смены пароля после первого входа (т.е. текущий пароль где-то записан).
Веб-приложение допускает передачу паролей по незащищенному HTTP-соединению либо в строке URL.
Веб-приложение не использует безопасные хэш-функции для хранения паролей пользователей.
Веб-приложение не предоставляет пользователям возможность изменения пароля либо не нотифицирует пользователей об изменении их паролей.
Веб-приложение использует уязвимую функцию восстановления пароля, которую можно использовать для получения несанкционированного доступа к другим учетным записям.
Веб-приложение не требует повторной аутентификации пользователя для важных действий: смена пароля, изменения адреса доставки товаров и т. п.
Веб-приложение создает session tokens таким образом, что они могут быть подобраны или предсказаны для других пользователей.
Веб-приложение допускает передачу session tokens по незащищенному HTTP-соединению, либо в строке URL.
Веб-приложение уязвимо для session fixation-атак (т. е. не заменяет session token при переходе анонимной сессии пользователя в аутентифицированную).
Веб-приложение не устанавливает флаги HttpOnly и Secure для browser cookies, содержащих session tokens.
Веб-приложение не уничтожает сессии пользователя после короткого периода неактивности либо не предоставляет функцию выхода из аутентифицированной сессии.

Аутентификация по сертификатам

Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный certificate authority (CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, которых хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

Использование сертификата для аутентификации.

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

Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
Сертификат должен быть действительным на текущую дату (проверка срока действия).
Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).

Пример X.509 сертификата.

После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).

Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation). Однако трудности с распространением и поддержкой сертификатов делает такой способ аутентификации малодоступным в широких кругах.

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации two-factor authentication (2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

Другой популярный сценарий использования одноразовых паролей — дополнительная аутентификация пользователя во время выполнения важных действий: перевод денег, изменение настроек и т. п.

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

В веб-приложениях такой механизм аутентификации часто реализуется посредством расширения forms authentication: после первичной аутентификации по паролю, создается сессия пользователя, однако в контексте этой сессии пользователь не имеет доступа к приложению до тех пор, пока он не выполнит дополнительную аутентификацию по одноразовому паролю.

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (access key, API key) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password.

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

Хороший пример применения аутентификации по ключу — облако Amazon Web Services. Предположим, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.

Пример применения аутентификации по ключу.

Использование ключей позволяет избежать передачи пароля пользователя сторонним приложениям (в примере выше пользователь сохранил в веб-приложении не свой пароль, а ключ доступа). Ключи обладают значительно большей энтропией по сравнению с паролями, поэтому их практически невозможно подобрать. Кроме того, если ключ был раскрыт, это не приводит к компрометации основной учетной записи пользователя — достаточно лишь аннулировать этот ключ и создать новый.

С технической точки зрения, здесь не существует единого протокола: ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header. Как и в случае аутентификации по паролю, наиболее оптимальный вариант — использование HTTP header. В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS.

Пример аутентификации по ключу доступа, переданного в HTTP заголовке.

Кроме того, существуют более сложные схемы аутентификации по ключам для незащищенных соединений. В этом случае, ключ обычно состоит их двух частей: публичной и секретной. Публичная часть используется для идентификации клиента, а секретная часть позволяет сгенерировать подпись. Например, по аналогии с digest authentication схемой, сервер может послать клиенту уникальное значение nonce или timestamp, а клиент — возвратить хэш или HMAC этого значения, вычисленный с использованием секретной части ключа. Это позволяет избежать передачи всего ключа в оригинальном виде и защищает от replay attacks.

Аутентификация по токенам

Такой способ аутентификации чаще всего применяется при построении распределенных систем Single Sign-On (SSO), где одно приложение (service provider или relying party) делегирует функцию аутентификации пользователей другому приложению (identity provider или authentication service). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение доверяет функцию аутентификации пользователей социальным сетям.

Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя. На общем уровне, весь процесс выглядит следующим образом:

Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
Клиент аутентифицируется в SP-приложении при помощи этого токена.

Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями identity provider и service provider.

Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

Сам токен обычно представляет собой структуру данных, которая содержит информацию, кто сгенерировал токен, кто может быть получателем токена, срок действия, набор сведений о самом пользователе (claims). Кроме того, токен дополнительно подписывается для предотвращения несанкционированных изменений и гарантий подлинности.

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

Токен был выдан доверенным identity provider приложением (проверка поля issuer).
Токен предназначается текущему SP-приложению (проверка поля audience).
Срок действия токена еще не истек (проверка поля expiration date).
Токен подлинный и не был изменен (проверка подписи).

В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.

Форматы токенов Существует несколько распространенных форматов токенов для веб-приложений:

Simple Web Token (SWT) — наиболее простой формат, представляющий собой набор произвольных пар имя/значение в формате кодирования HTML form. Стандарт определяет несколько зарезервированных имен: Issuer, Audience, ExpiresOn и HMACSHA256. Токен подписывается с помощью симметричного ключа, таким образом оба IP- и SP-приложения должны иметь этот ключ для возможности создания/проверки токена.
Пример SWT токена (после декодирования).
Issuer=http://auth.myservice.com& Audience=http://myservice.com& ExpiresOn=1435937883& UserName=John Smith& UserRole=Admin& HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w
JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок, набор полей (claims) и подпись. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Подпись может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.
Пример подписанного JWT токена (после декодирования 1 и 2 блоков).
{ «alg»: «HS256», «typ»: «JWT» }. { «iss»: «auth.myservice.com», «aud»: «myservice.com», «exp»: «1435937883», «userName»: «John Smith», «userRole»: «Admin» }. S9Zs/8/uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY
Security Assertion Markup Language (SAML) — определяет токены (SAML assertions) в XML-формате, включающем информацию об эмитенте, о субъекте, необходимые условия для проверки токена, набор дополнительных утверждений (statements) о пользователе. Подпись SAML-токенов осуществляется при помощи ассиметричной криптографии. Кроме того, в отличие от предыдущих форматов, SAML-токены содержат механизм для подтверждения владения токеном, что позволяет предотвратить перехват токенов через man-in-the-middle-атаки при использовании незащищенных соединений.

Стандарт SAML

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

Assertions — собственный формат SAML токенов в XML формате.
Protocols — набор поддерживаемых сообщений между участниками, среди которых — запрос на создание нового токена, получение существующих токенов, выход из системы (logout), управление идентификаторами пользователей, и другие.
Bindings — механизмы передачи сообщений через различные транспортные протоколы. Поддерживаются такие способы, как HTTP Redirect, HTTP POST, HTTP Artifact (ссылка на сообщения), SAML SOAP, SAML URI (адрес получения сообщения) и другие.
Profiles — типичные сценарии использования стандарта, определяющие набор assertions, protocols и bindings необходимых для их реализации, что позволяет достичь лучшей совместимости. Web Browser SSO — один из примеров таких профилей.

Кроме того, стандарт определяет формат обмена метаинформацией между участниками, которая включает список поддерживаемых ролей, протоколов, атрибутов, ключи шифрования и т. п.

Рассмотрим краткий пример использования SAML для сценария Single Sign-On. Пользователь хочет получить доступ на защищенный ресурс сервис-провайдера (шаг № 1 на диаграмме аутентификации пассивных клиентов). Т. к. пользователь не был аутентифицирован, SP отправляет его на сайт identity provider’а для создания токена (шаг № 2). Ниже приведен пример ответа SP, где последний использует SAML HTTP Redirect binding для отправки сообщения с запросом токена:

В случае такого запроса, identity provider аутентифицирует пользователя (шаги №3-4), после чего генерирует токен. Ниже приведен пример ответа IP с использованием HTTP POST binding (шаг № 5):

После того как браузер автоматически отправит эту форму на сайт service provider’а (шаг № 6), последний декодирует токен и аутентифицирует пользователя. По результатам успешной авторизации запроса пользователь получает доступ к запрошенному ресурсу (шаг № 7).

Стандарты WS-Trust и WS-Federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

Формат и способы обмена метаданными о сервисах.
Функцию единого выхода из всех систем (single sign-out).
Сервис атрибутов, предоставляющий дополнительную информацию о пользователе.
Сервис псевдонимов, позволяющий создавать альтернативные имена пользователей.
Поддержку пассивных клиентов (браузеров) посредством перенаправления.

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Стандарты OAuth и OpenID Connect

В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).

Первая версия стандарта разрабатывалась в 2007 – 2010 гг., а текущая версия 2.0 опубликована в 2012 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.

Чтобы лучше понять сам стандарт, рассмотрим пример веб-приложения, которое помогает пользователям планировать путешествия. Как часть функциональности оно умеет анализировать почту пользователей на наличие писем с подтверждениями бронирований и автоматически включать их в планируемый маршрут. Возникает вопрос, как это веб-приложение может безопасно получить доступ к почте пользователей, например, к Gmail?

> Попросить пользователя указать данные своей учетной записи? — плохой вариант. > Попросить пользователя создать ключ доступа? — возможно, но весьма сложно.

Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:

Пользователь (resource owner) дает разрешение приложению (client) на доступ к определенному ресурсу в виде гранта. Что такое грант, рассмотрим чуть ниже.
Приложение обращается к серверу авторизации и получает токен доступа к ресурсу в обмен на свой грант. В нашем примере сервер авторизации — Google. При вызове приложение дополнительно аутентифицируется при помощи ключа доступа, выданным ему при предварительной регистрации.
Приложение использует этот токен для получения требуемых данных от сервера ресурсов (в нашем случае — сервис Gmail).

Взаимодействие компонентов в стандарте OAuth.

Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:

Authorization Code — этот грант пользователь может получить от сервера авторизации после успешной аутентификации и подтверждения согласия на предоставление доступа. Такой способ наиболее часто используется в веб-приложениях. Процесс получения гранта очень похож на механизм аутентификации пассивных клиентов в SAML и WS-Federation.
Implicit — применяется, когда у приложения нет возможности безопасно получить токен от сервера авторизации (например, JavaScript-приложение в браузере). В этом случае грант представляет собой токен, полученный от сервера авторизации, а шаг № 2 исключается из сценария выше.
Resource Owner Password Credentials — грант представляет собой пару username/password пользователя. Может применяться, если приложение является «интерфейсом» для сервера ресурсов (например, приложение — мобильный клиент для Gmail).
Client Credentials — в этом случае нет никакого пользователя, а приложение получает доступ к своим ресурсам при помощи своих ключей доступа (исключается шаг № 1).

Стандарт не определяет формат токена, который получает приложение: в сценариях, адресуемых стандартом, приложению нет необходимости анализировать токен, т. к. он лишь используется для получения доступа к ресурсам. Поэтому ни токен, ни грант сами по себе не могут быть использованы для аутентификации пользователя. Однако если приложению необходимо получить достоверную информацию о пользователе, существуют несколько способов это сделать:

Зачастую API сервера ресурсов включает операцию, предоставляющую информацию о самом пользователе (например, /me в Facebook API). Приложение может выполнять эту операцию каждый раз после получения токена для идентификации клиента. Такой метод иногда называют псевдо-аутентификацией.
Использовать стандарт OpenID Connect, разработанный как слой учетных данных поверх OAuth (опубликован в 2014 г.). В соответствии с этим стандартом, сервер авторизации предоставляет дополнительный identity token на шаге № 2. Этот токен в формате JWT будет содержать набор определенных полей (claims) с информацией о пользователе.

Стоит заметить, что OpenID Connect, заменивший предыдущие версии стандарта OpenID 1.0 и 2.0, также содержит набор необязательных дополнений для поиска серверов авторизации, динамической регистрации клиентов и управления сессией пользователя.

Заключение

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

Способ	Основное применение	Протоколы
По паролю	Аутентификация пользователей	HTTP, Forms
По сертификатам	Аутентификация пользователей в безопасных приложениях; аутентификация сервисов	SSL/TLS
По одноразовым паролям	Дополнительная аутентификация пользователей (для достижения two-factor authentication)	Forms
По ключам доступа	Аутентификация сервисов и приложений	-
По токенам	Делегированная аутентификация пользователей; делегированная авторизация приложений	SAML, WS-Federation, OAuth, OpenID Connect

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

Автор: Дмитрий Выростков, Solutions Architect в DataArt.

habr.com

О LanDocs

Линия программных продуктов LanDocs предназначена для построения автоматизированных систем документационного обеспечения управления на предприятиях различного масштаба и специализации. С использованием программной продукции LanDocs может быть реализован целый спектр разнообразных проектных решений:

· система автоматизации делопроизводства и документооборота, основанная на отечественных стандартах и нормах, практике организации учета документов и контроля исполнения поручений в организациях различных типов и предоставляющая разные уровни функциональности для различных категорий сотрудников;

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

· система автоматизации деятельности ведомственных архивов и архивных подразделений организаций, функционирующая в соответствии с требованиями Государственной архивной службы Российской Федерации, обеспечивающая подготовку специализированной отчетности ведомственных архивов и предоставляющая возможность реализации специальных технологий массового (пакетного) ввода документов на бумажной основе в электронный архив;

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

Информационная безопасность перечисленных проектных решений обеспечивается специализированной подсистемой безопасности, реализующей механизмы электронной цифровой подписи (в том числе – сертифицированных ФАПСИ) для подтверждения авторства и целостности документов, шифрования данных для их защиты от несанкционированного доступа, а также выполняющей функции Центра сертификации ключей (поддерживает сертификаты формата X.509) и осуществляющей протоколирование действий пользователей в специальном журнале безопасности.

service.otr.ru

Идентификатор участника электронного документооборота

Ваш регион: Москва

Мос. обл. (50)
Тула (71)
Воронеж (36)

Вход для клиентов

Воспользуйтесь поиском:

Организация получает идентификатор участника электронного документооборота при отправке заявления об участии в электронном документообороте. На один ИНН выдается один идентификатор участника. Для просмотра своего идентификатора зайдите в реквизиты организации.

Идентификатор отправителя и получателя вставляется в xml-файл:

Идентификатор участника представлен в виде XXX-YYY...YY, где:

ХХХ (3 символа)- идентификатор оператора электронного оборота счетами-фактурами (оператор ЭДО), услугами которого пользуется покупатель (продавец).

Идентификатор оператора ЭДО (при включении в сеть доверенных операторов ЭДО ФНС России) присваивается Федеральной налоговой службой согласно Приказу ФНС России от 20.04.2020 N ММВ-7-6/253@ "Об утверждении Временного положения о Сети доверенных операторов электронного документооборота и Временного положения о порядке присоединения к Сети доверенных операторов электронного документооборота".
YYY..YY (не более 43 символов) - уникальный код участника (покупателя или продавца), присваиваемый оператором ЭДО, услугами которого пользуется покупатель (продавец).

Пример идентификатора участника ЭДО: 2BM-170B038D96B34EODA1b2BB86B09585BA.

Назад к списку статей