Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 58 Сказал(а) «Спасибо»: 10 раз
|
Автор: two_oceans Автор: Андрей * Не забываем, что у сервера должно быть еще доверие к УЦ. Справедливо. Подразумевается, что доверие отдельный вопрос, который проработан. Интересно, как этот вопрос прорабатывается правильно?
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 394 раз в 366 постах
|
Автор: nomhoi Интересно, как этот вопрос прорабатывается правильно? Ну, на правильность 100% наверно претендовать не стану, но опишу свое видение, там уже коллеги добавят. Выше уже описано как я тестовые функции и тестовые УЦ разрешаю только если исполняемый файл находится в определенном месте. Пока что у меня тоже разрешительная система по отпечатку - потому и говорю какая это головная боль вручную вбивать разрешения. В планах есть идея (не реализовано пока потому что мне нужны всего пара УЦ из трехсот) в отдельном процессе ежедневно/еженедельно скачивать список аккредитованных УЦ с сайта Минцифры e-trust.gosuslugi.ru (там предусмотрена специальная выгрузка всего списка, но адрес навскидку не помню), разбирать этот список (сертификаты УЦ уже вроде как в самом списке), скачивать списки отзыва (списки отзыва можно и почаще проверять, но зависит от УЦ - некоторые публикуют список отзыва только раз в квартал). Потом по вкусу все это запихивать либо в файловое хранилище либо в системное. Лично я за файловое, так как постоянно держать 300 УЦ в системном проблематично. Однако для регионального портала может понадобится держать на готове все. Или хотя бы те УЦ от которых были выданы сертификаты в разрешенном списке.
Сам список с сертификатами можно легко скачать и установить через КриптоАРМ, но списки отзыва не подгружаются, их все равно пилить отдельно. Есть отдельная утилита от ИИТ - ставится сервисом, отлично работает с одним УЦ (расчитана на то что все лежит в одной папке, а не на куче серверов), по расписанию скачивает и ставит списки отзыва. Однако чем больше УЦ тем больше тупит, поэтому хорошо подходит для одного УЦ или для копирования списков отзыва по локалке, но собирать в одну папку надо чем-то другим.
Кроме того, не забываем, что у Майкрософт есть программа распространения зарубежных корневых УЦ. Ставить сами сертификаты или нет конечно надо хорошо подумать, но вот список блокировки оттуда взять - полезно для безопасности. Отредактировано пользователем 30 ноября 2020 г. 13:30:06(UTC)
| Причина: Не указана
|
1 пользователь поблагодарил two_oceans за этот пост.
|
nomhoi оставлено 30.11.2020(UTC)
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 58 Сказал(а) «Спасибо»: 10 раз
|
Спасибо, понятно. До этого вопроса еще надо будет дойти.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 31.01.2017(UTC) Сообщений: 219 Откуда: Санкт-Петербург Сказал(а) «Спасибо»: 11 раз Поблагодарили: 41 раз в 40 постах
|
Автор: two_oceans Автор: nomhoi Интересно, как этот вопрос прорабатывается правильно? Ну, на правильность 100% наверно претендовать не стану, но опишу свое видение, там уже коллеги добавят. Выше уже описано как я тестовые функции и тестовые УЦ разрешаю только если исполняемый файл находится в определенном месте. Пока что у меня тоже разрешительная система по отпечатку - потому и говорю какая это головная боль вручную вбивать разрешения. В планах есть идея (не реализовано пока потому что мне нужны всего пара УЦ из трехсот) в отдельном процессе ежедневно/еженедельно скачивать список аккредитованных УЦ с сайта Минцифры e-trust.gosuslugi.ru (там предусмотрена специальная выгрузка всего списка, но адрес навскидку не помню), разбирать этот список (сертификаты УЦ уже вроде как в самом списке), скачивать списки отзыва (списки отзыва можно и почаще проверять, но зависит от УЦ - некоторые публикуют список отзыва только раз в квартал). Потом по вкусу все это запихивать либо в файловое хранилище либо в системное. Лично я за файловое, так как постоянно держать 300 УЦ в системном проблематично. Однако для регионального портала может понадобится держать на готове все. Или хотя бы те УЦ от которых были выданы сертификаты в разрешенном списке.
Сам список с сертификатами можно легко скачать и установить через КриптоАРМ, но списки отзыва не подгружаются, их все равно пилить отдельно. Есть отдельная утилита от ИИТ - ставится сервисом, отлично работает с одним УЦ (расчитана на то что все лежит в одной папке, а не на куче серверов), по расписанию скачивает и ставит списки отзыва. Однако чем больше УЦ тем больше тупит, поэтому хорошо подходит для одного УЦ или для копирования списков отзыва по локалке, но собирать в одну папку надо чем-то другим.
Кроме того, не забываем, что у Майкрософт есть программа распространения зарубежных корневых УЦ. Ставить сами сертификаты или нет конечно надо хорошо подумать, но вот список блокировки оттуда взять - полезно для безопасности. я бы не спешил. что творится с законодательством по ЭП - мрак (см. доверенные стороны), м.б. все сменится мгновенно. |
Цена свободы - вечная бдительность! |
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 394 раз в 366 постах
|
Автор: nikolkas_spb я бы не спешил. что творится с законодательством по ЭП - мрак (см. доверенные стороны), м.б. все сменится мгновенно. Это несомненно так, согласен. Однако, сомневаюсь, что кто-то будет кардинально менять систему PKI.
Все изменения до сих пор практически не меняли техническую суть, подстраиваясь если не по сути, то по форме под RFC. Так, гост не использует шифрование при подписании, сам алгоритм шифрования симметричный, но различные параметры сгруппировали так, чтобы формально получились открытый и закрытый ключи. Формально все параметры функций те же, но суть отличается. Госты по алгоритмам утверждены и пока не видел признаков вывода гост-2012 из обращения. На примере гост-2001 уже убедились, что доработок при смене алгоритма требуется много, но ничего такого сверхъестественного. Минцифра тоже вряд ли откажется ст полномочий координатора системы УЦ. Федеральное казначейство и ФНС явно продолжат работу как УЦ. Общая тенденция идет на дистанционные способы взаимодействия, так что от ЭП в целом тоже не откажутся. Картина в целом устоявшаяся.
В итоге, может измениться порядок оформления документов, получения сертификата, какие-то правовые нормы или добавится оид к сертификату, могут остановить коммерческие УЦ. (Печально, я, мягко говоря, "не всегда доволен" работой государственных УЦ, но и когда все привыкли, что каждая система документооборота просит сертификат "своего" УЦ тоже немного странно.) Согласен, с этими изменениями тоже будет немало мелких заморочек, но на техническом уровне общая картина не меняется - все те же квалифицированные сертификаты ключа проверки электронной подписи.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 58 Сказал(а) «Спасибо»: 10 раз
|
Автор: two_oceans 5. Сертификат сопоставляется сервером по БД с пользователем конкретной информационной системы (сайта). Это идентификация пользователя. При регистрации/редактировании пользователя должны быть заранее указаны какие-то характерные поля сертификата (отпечаток сертификата - для запрета входа другими сертификатами того же человека - ЕИС не руководитель; ФИО, снилс - госуслуги, ЕИС руководитель; инн, огрн, огрнип - сайты ФНС; дополнительно специальное назначение сертификата - Росреестр; дополнительно должность/логин пользователя - СУФД; дополнительно код организации - старые сертификаты ЕИС). Идентификатор ключа из сертификата использовать не рекомендуется, так как теоретически его можно подделать. Для ЕИС руководителя используется основная привязка по фио и снилс, однако отпечаток последнего сертификата по которому вошли записывается в БД. По инструкции от ЕИС (ИНСТРУКЦИЯ по регистрации организаций и пользователей в Единой информационной системе в соответствии с Приказом Казначейства России от 30.12.2015 г. No 27н) аутентификация руководителя производится по ФИО и ИНН. Данные руководителя в ЕИС передаются из реестра. В нашем случае, в региональной ЕИС, пользователь сначала подает заявку на доступ. В этой заявке выбирает свою организацию из списка организация, который мы получаем из ЕИС. И вот в этой заявке мы можем затребовать от руководителя загрузку его сертификата. И тогда мы сможем реализовать аутентификацию одинаково как для руководителя, так и для других сотрудников - по отпечатку сертификата. Пойдет такое решение?
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 58 Сказал(а) «Спасибо»: 10 раз
|
Автор: two_oceans Искать отпечатку в БД достаточно и можно, все верно. Вопрос в продлении сертификата через год - если привязаться к отпечатку, то через год к аккаунту надо будет как-то привязывать новый сертификат, специальную страницу, например, процедуру подтверждения администратором. А если к аккаунту прописать снилс, то можно будет автоматом опознать что пользователь продлил сертификат по соответствующим полям нового сертификата. Выбор за Вами, но однозначно удобнее не привязываться к конкретному отпечатку. А если сотрудник продлил сертификат, т.е. сертификат заменился на новый, то руководитель/администратор просто заменяет его сертификат на новый, и сотрудник снова сможет заходить. Мне кажется, что лучше пусть руководитель/администратор поменяет в базе сертификат сотрудника, чем выполнять автоматический вход по новому сертификату. А если руководитель сменил сертификат, то проверку можно будет выполнить по ФИО и ИНН. По старому сертификату аутентификация у него не пройдет. Отредактировано пользователем 29 декабря 2020 г. 12:26:18(UTC)
| Причина: Не указана
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 58 Сказал(а) «Спасибо»: 10 раз
|
Вход по ЭЦП реализовал с помощью подписи хэша. На запросе формы аутентификации генерируем уникальную строку, создаем хэш этой строки, записываем ее в сессию и передаем в браузер: Код: hashedData = pycades.HashedData()
hashedData.Algorithm = pycades.CADESCOM_HASH_ALGORITHM_CP_GOST_3411_2012_256
hashedData.Hash(uuid.uuid4().hex)
self.state = hashedData.Value
request.session['state'] = self.state
В браузере, с помощью функции createDetachedSignature библиотеки https://github.com/vgoma/crypto-pro создаем отделенную подпись хэша и передаем ее на сервер. В бэкенде аутентификации проверяем подпись: Код: state = request.session['state']
signature = credentials['signature']
hashedData = pycades.HashedData()
hashedData.Algorithm = pycades.CADESCOM_HASH_ALGORITHM_CP_GOST_3411_2012_256
hashedData.SetHashValue(state)
_signedData = pycades.SignedData()
_signedData.VerifyHash(hashedData, signature, pycades.CADESCOM_CADES_BES)
print("Verified successfully")
Далее из подписи получаем данные сертификата и выполняем сверку с данными из таблицы пользователей. Примерно так получается. Отредактировано пользователем 30 декабря 2020 г. 9:27:25(UTC)
| Причина: Не указана
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 394 раз в 366 постах
|
Автор: nomhoi А если руководитель сменил сертификат, то проверку можно будет выполнить по ФИО и ИНН. По старому сертификату аутентификация у него не пройдет. ОК, как мне кажется пойдет. Но технически тут вопрос какой ИНН получаете из ЕИС - ИНН организации или ИНН физлица. В идеале можно бы запросить оба - инн физлица можно сверять еще и с сертификатом. Автоматически одобрите заявку по совпадению данных в сертификате руководителя и данных об организации из ЕИС? Или кто-то будет видеть отчет сверки (на глаз сверять циферки не очень безопасно, предупреждение об отличии лучше оставить) и нажимать финальную кнопку принять/отказать? Принципиально источником данных является выписка из ЕГРЮЛ в которой указаны ФИО и инн руководителя. Потом это неким образом (не буду заострять внимание) попадает в ЕИС. Далее Вы получаете из ЕИС. По питону мне сложно так сходу ответить, посмотрю внимательней когда время найдется.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 58 Сказал(а) «Спасибо»: 10 раз
|
Автор: two_oceans Автор: nomhoi А если руководитель сменил сертификат, то проверку можно будет выполнить по ФИО и ИНН. По старому сертификату аутентификация у него не пройдет. ОК, как мне кажется пойдет. Но технически тут вопрос какой ИНН получаете из ЕИС - ИНН организации или ИНН физлица. В идеале можно бы запросить оба - инн физлица можно сверять еще и с сертификатом. В сертификате содержится только ИНН руководителя. У нас пока решили всех по отпечатку сертификата выполнять аутентификацию. Цитата: Автоматически одобрите заявку по совпадению данных в сертификате руководителя и данных об организации из ЕИС? Или кто-то будет видеть отчет сверки (на глаз сверять циферки не очень безопасно, предупреждение об отличии лучше оставить) и нажимать финальную кнопку принять/отказать? Как будет выглядеть процесс проверки заявки на доступ пока не в курсе. Цитата:Принципиально источником данных является выписка из ЕГРЮЛ в которой указаны ФИО и инн руководителя. Потом это неким образом (не буду заострять внимание) попадает в ЕИС. Далее Вы получаете из ЕИС. Предложу добавить автоматическую проверку данных, спасибо.
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close