Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 9,873   Сказал «Спасибо»: 361 раз
Поблагодарили: 1420 раз в 1094 постах
|
Автор: nomhoi  С другой стороны можно и отпечаток подставить другой.
Можно ли с помощью браузерного плагина добавить сертфикат в подпись в момент создания подписи? Используйте криптографию правильно. Изучите API и что доступно при проверке\подписании... После успешной проверки - проверяете информацию о подписанте (сертификат передаёте либо в cms, либо отдельно "ищите у себя" в известным данным из cms, для raw - будет "сложнее" - прослойку писать, чтобы найти нужный открытый ключ). |
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 9,873 Сказал «Спасибо»: 361 раз
Поблагодарили: 1420 раз в 1094 постах
|
Автор: two_oceans
Искать отпечатку в БД достаточно и можно, все верно. Вопрос в продлении сертификата через год - если привязаться к отпечатку, то через год к аккаунту надо будет как-то привязывать новый сертификат, специальную страницу, например, процедуру подтверждения администратором. А если к аккаунту прописать снилс, то можно будет автоматом опознать что пользователь продлил сертификат по соответствующим полям нового сертификата. Выбор за Вами, но однозначно удобнее не привязываться к конкретному отпечатку. Не забываем, что у сервера должно быть еще доверие к УЦ. При регистрации по отпечатку - проверяющий проверил\активировал доступ... а вот с информацией (ИНН\СНИЛС) встречал такие ИС... которые "автоматически" пускали к себе и давали полный доступ (бесплатно и без смс!)... опираясь лишь на данные из сертификата, а то, что сертификат был сделан в тестовом УЦ и вообще другими лицами - ... как-то не смогли продумать. |
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,153 Откуда: Иркутская область Сказал(а) «Спасибо»: 76 раз
Поблагодарили: 264 раз в 248 постах
|
Автор: Андрей * Не забываем, что у сервера должно быть еще доверие к УЦ. Справедливо. Подразумевается, что доверие отдельный вопрос, который проработан. Автор: Андрей * а то, что сертификат был сделан в тестовом УЦ и вообще другими лицами - ... как-то не смогли продумать. Не факт... у них мог быть добавлен тестовый УЦ в доверенные, и все проверки проходили на ура. Вообще удивляюсь зачем люди добавляют тестовый УЦ в системное хранилище на "боевых" серверах, хотя можно сделать пару лишних движений для безопасности: добавить тестовый УЦ в отдельное файловое PEM/P7B хранилище, открывать такое хранилище только на тестовых билдах, вручную проверять цепочку. Например, у меня программа проверяет свой путь - если папка, где идет разработка есть в пути, используется тестовый режим; на боевом сервере путь другой и тестовые "примочки" отключаются.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 9,873 Сказал «Спасибо»: 361 раз
Поблагодарили: 1420 раз в 1094 постах
|
Автор: two_oceans Автор: Андрей * Не забываем, что у сервера должно быть еще доверие к УЦ. Справедливо. Подразумевается, что доверие отдельный вопрос, который проработан. Автор: Андрей * а то, что сертификат был сделан в тестовом УЦ и вообще другими лицами - ... как-то не смогли продумать. Не факт... у них мог быть добавлен тестовый УЦ в доверенные, и все проверки проходили на ура. Вообще удивляюсь зачем люди добавляют тестовый УЦ в системное хранилище на "боевых" серверах, хотя можно сделать пару лишних движений для безопасности: добавить тестовый УЦ в отдельное файловое PEM/P7B хранилище, открывать такое хранилище только на тестовых билдах, вручную проверять цепочку. Например, у меня программа проверяет свой путь - если папка, где идет разработка есть в пути, используется тестовый режим; на боевом сервере путь другой и тестовые "примочки" отключаются. ... программисты продумывали, писали функции\криптопрография (хеш на хеш с солью да добавить сертификатов по вкусу) и прочее ... но всё "сломалось" через .. администратора, который для теста добавил и забыл убрать корневой (или для тестов на бою?))  Хотя и первое утверждение не факт... |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 31.01.2017(UTC) Сообщений: 215 Откуда: Санкт-Петербург Сказал(а) «Спасибо»: 11 раз
Поблагодарили: 40 раз в 39 постах
|
И да, не забываем все это прописать в документах. причем лучше всего со схемами, графиками и ССЫЛКАМИ и ЦИТАТАМИ с инструкций и ГОСТов.
Неумному проверяющему понравится количество букв и ссылки на ГОСТ, умный разберется и вопросы отпадут. Да и сам поймешь что откуда берется и куда девается. |
Цена свободы - вечная бдительность! |
 2 пользователей поблагодарили nikolkas_spb за этот пост.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 39 Сказал(а) «Спасибо»: 8 раз
|
Автор: two_oceans Зачем что-то присоединять, тем более постоянную часть? Другим сертификатом просто не проверится подпись, так как открытые ключи разные в сертификатах. Поэтому подмена сертификата ничего не дает. Вы в курсе как во вторую мировую вскрывали шифр машинки Энигма? Немцы тупо писали в начале каждого шифрованного сообщения что-то типа "Дорогой господин" - фиксированную фразу, что давало возможность подбирать ключ пока не получится эта фраза.
Поэтому добавлять постоянную фразу вредно, весь смысл чтобы стейт был целиком неизвестным заранее (случайно сгенерированным, например). Как вариант, может быть хэшем от соединения нескольких меняющихся частей, ведь хэш сложно спрогнозировать, если хотя бы одна часть неизвестна. Однако хэш от одной строки (даже будь она соединением нескольких) одинаков и прогнозируем. Я чуть выше писал, что state - уникальная строка, которая генерируется в момент открытия формы логина. Если информацию по сертификату можно извлечь из подписи, то и хэш присоединять не надо. Цитата:Искать отпечатку в БД достаточно и можно, все верно. Вопрос в продлении сертификата через год - если привязаться к отпечатку, то через год к аккаунту надо будет как-то привязывать новый сертификат, специальную страницу, например, процедуру подтверждения администратором. А если к аккаунту прописать снилс, то можно будет автоматом опознать что пользователь продлил сертификат по соответствующим полям нового сертификата. Выбор за Вами, но однозначно удобнее не привязываться к конкретному отпечатку. Понятно. Цитата:Цитата:Можно ли с помощью браузерного плагина добавить сертфикат в подпись в момент создания подписи? Да, использовать cades. Скорее тогда не получится сделать без сертификата. Однако объем подписи будет несколько килобайт что неудобно. Обычно используют при аутентификации на странице Raw подпись до пары сотен байт, в ней нет сертификата. В приложении https://github.com/vgoma/crypto-pro, которое мы используем, используется CADES-BES. Получается, что сертификат включается в подпись. Цитата:Цитата:хэш на хэш - нехорошо Возможно это прочитали про зарубежные алгоритмы? потому что при формировании ключа которым шифруется контейнер из пароля в гост вычисляется 2000 раз хеш на хэш+соль. Главное не забывайте соль добавлять и хэш на хэш не проблема. Да, это понятно.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 39 Сказал(а) «Спасибо»: 8 раз
|
Автор: two_oceans По идее (плагином) после проверки Verify или CadesVerify должен стать доступен массив Signers подписи из которого можно получить сертификат.
Ах, другое API... после CadesVerifyMessage (или другой подходящей, смотрите по смыслу) получается CADES_VERIFICATION_INFO, в которой есть pSignerCert
MS API: CryptVerifyMessageSignature ppSignerCert Спасибо, посмотрю.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 39 Сказал(а) «Спасибо»: 8 раз
|
Автор: Андрей * Автор: nomhoi С другой стороны можно и отпечаток подставить другой.
Можно ли с помощью браузерного плагина добавить сертфикат в подпись в момент создания подписи? Используйте криптографию правильно. Изучите API и что доступно при проверке\подписании... Как написал выше при создании подписи используется формат CADES-BES. Вот нашел в документации функцию CadesVerifyDetachedMessage: https://docs.cryptopro.r...desverifydetachedmessage__out_opt PCADES_VERIFICATION_INFO *ppVerificationInfo - здесь получается будет получена информацию по сертификатку. Пока непонятно, что и в каком там виде будет эта информация. Цитата:После успешной проверки - проверяете информацию о подписанте (сертификат передаёте либо в cms, либо отдельно "ищите у себя" в известным данным из cms, для raw - будет "сложнее" - прослойку писать, чтобы найти нужный открытый ключ).
Получается в ppVerificationInfo будет нужная информация по сертификату, или сам сертификат. И по этой информации мы будем искать ее в нашей базе пользователей для идентификации. Спасибо.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 39 Сказал(а) «Спасибо»: 8 раз
|
Автор: Андрей * Автор: two_oceans
Искать отпечатку в БД достаточно и можно, все верно. Вопрос в продлении сертификата через год - если привязаться к отпечатку, то через год к аккаунту надо будет как-то привязывать новый сертификат, специальную страницу, например, процедуру подтверждения администратором. А если к аккаунту прописать снилс, то можно будет автоматом опознать что пользователь продлил сертификат по соответствующим полям нового сертификата. Выбор за Вами, но однозначно удобнее не привязываться к конкретному отпечатку. Не забываем, что у сервера должно быть еще доверие к УЦ. При регистрации по отпечатку - проверяющий проверил\активировал доступ... а вот с информацией (ИНН\СНИЛС) встречал такие ИС... которые "автоматически" пускали к себе и давали полный доступ (бесплатно и без смс!)... опираясь лишь на данные из сертификата, а то, что сертификат был сделан в тестовом УЦ и вообще другими лицами - ... как-то не смогли продумать. Вот инструкция: https://zakupki.gov.ru/e...adDocument.html?id=32884Нам нужно повторить функционал описанный в разделе 4.1 этой инструкции "Регистрация организации в ЕИС, сведения о которой включены в Сводный реестр (в соответствии с разделом III Порядка регистрации No27н)". Пока не понятно нужно ли будет повторять весь этот процесс, все пункты этого раздела. Пока делаю простой эпизод: сертификат пользователя или какая-то информация из сертификата в базе уже присутствует, нужно выполнить вход по ЭЦП. Т.е. нашем случае сразу уже определено, что если пользователя нет в базе, то и аутентификация не пройдет. Регистрация/активация нового пользователя будет выполняться как-то в ручном режиме, как выглядит этот процесс я не в курсе. Отредактировано пользователем 30 ноября 2020 г. 11:52:57(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 39 Сказал(а) «Спасибо»: 8 раз
|
Автор: nikolkas_spb И да, не забываем все это прописать в документах. причем лучше всего со схемами, графиками и ССЫЛКАМИ и ЦИТАТАМИ с инструкций и ГОСТов.
Неумному проверяющему понравится количество букв и ссылки на ГОСТ, умный разберется и вопросы отпадут. Да и сам поймешь что откуда берется и куда девается. Ок. Спасибо.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 39 Сказал(а) «Спасибо»: 8 раз
|
Автор: two_oceans Автор: Андрей * Не забываем, что у сервера должно быть еще доверие к УЦ. Справедливо. Подразумевается, что доверие отдельный вопрос, который проработан. Интересно, как этот вопрос прорабатывается правильно?
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,153 Откуда: Иркутская область Сказал(а) «Спасибо»: 76 раз
Поблагодарили: 264 раз в 248 постах
|
Автор: 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) Сообщений: 39 Сказал(а) «Спасибо»: 8 раз
|
Спасибо, понятно. До этого вопроса еще надо будет дойти.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 31.01.2017(UTC) Сообщений: 215 Откуда: Санкт-Петербург Сказал(а) «Спасибо»: 11 раз
Поблагодарили: 40 раз в 39 постах
|
Автор: two_oceans Автор: nomhoi Интересно, как этот вопрос прорабатывается правильно? Ну, на правильность 100% наверно претендовать не стану, но опишу свое видение, там уже коллеги добавят. Выше уже описано как я тестовые функции и тестовые УЦ разрешаю только если исполняемый файл находится в определенном месте. Пока что у меня тоже разрешительная система по отпечатку - потому и говорю какая это головная боль вручную вбивать разрешения. В планах есть идея (не реализовано пока потому что мне нужны всего пара УЦ из трехсот) в отдельном процессе ежедневно/еженедельно скачивать список аккредитованных УЦ с сайта Минцифры e-trust.gosuslugi.ru (там предусмотрена специальная выгрузка всего списка, но адрес навскидку не помню), разбирать этот список (сертификаты УЦ уже вроде как в самом списке), скачивать списки отзыва (списки отзыва можно и почаще проверять, но зависит от УЦ - некоторые публикуют список отзыва только раз в квартал). Потом по вкусу все это запихивать либо в файловое хранилище либо в системное. Лично я за файловое, так как постоянно держать 300 УЦ в системном проблематично. Однако для регионального портала может понадобится держать на готове все. Или хотя бы те УЦ от которых были выданы сертификаты в разрешенном списке.
Сам список с сертификатами можно легко скачать и установить через КриптоАРМ, но списки отзыва не подгружаются, их все равно пилить отдельно. Есть отдельная утилита от ИИТ - ставится сервисом, отлично работает с одним УЦ (расчитана на то что все лежит в одной папке, а не на куче серверов), по расписанию скачивает и ставит списки отзыва. Однако чем больше УЦ тем больше тупит, поэтому хорошо подходит для одного УЦ или для копирования списков отзыва по локалке, но собирать в одну папку надо чем-то другим.
Кроме того, не забываем, что у Майкрософт есть программа распространения зарубежных корневых УЦ. Ставить сами сертификаты или нет конечно надо хорошо подумать, но вот список блокировки оттуда взять - полезно для безопасности. я бы не спешил. что творится с законодательством по ЭП - мрак (см. доверенные стороны), м.б. все сменится мгновенно. |
Цена свободы - вечная бдительность! |
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,153 Откуда: Иркутская область Сказал(а) «Спасибо»: 76 раз
Поблагодарили: 264 раз в 248 постах
|
Автор: nikolkas_spb я бы не спешил. что творится с законодательством по ЭП - мрак (см. доверенные стороны), м.б. все сменится мгновенно. Это несомненно так, согласен. Однако, сомневаюсь, что кто-то будет кардинально менять систему PKI.
Все изменения до сих пор практически не меняли техническую суть, подстраиваясь если не по сути, то по форме под RFC. Так, гост не использует шифрование при подписании, сам алгоритм шифрования симметричный, но различные параметры сгруппировали так, чтобы формально получились открытый и закрытый ключи. Формально все параметры функций те же, но суть отличается. Госты по алгоритмам утверждены и пока не видел признаков вывода гост-2012 из обращения. На примере гост-2001 уже убедились, что доработок при смене алгоритма требуется много, но ничего такого сверхъестественного. Минцифра тоже вряд ли откажется ст полномочий координатора системы УЦ. Федеральное казначейство и ФНС явно продолжат работу как УЦ. Общая тенденция идет на дистанционные способы взаимодействия, так что от ЭП в целом тоже не откажутся. Картина в целом устоявшаяся.
В итоге, может измениться порядок оформления документов, получения сертификата, какие-то правовые нормы или добавится оид к сертификату, могут остановить коммерческие УЦ. (Печально, я, мягко говоря, "не всегда доволен" работой государственных УЦ, но и когда все привыкли, что каждая система документооборота просит сертификат "своего" УЦ тоже немного странно.) Согласен, с этими изменениями тоже будет немало мелких заморочек, но на техническом уровне общая картина не меняется - все те же квалифицированные сертификаты ключа проверки электронной подписи.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 39 Сказал(а) «Спасибо»: 8 раз
|
Автор: two_oceans 5. Сертификат сопоставляется сервером по БД с пользователем конкретной информационной системы (сайта). Это идентификация пользователя. При регистрации/редактировании пользователя должны быть заранее указаны какие-то характерные поля сертификата (отпечаток сертификата - для запрета входа другими сертификатами того же человека - ЕИС не руководитель; ФИО, снилс - госуслуги, ЕИС руководитель; инн, огрн, огрнип - сайты ФНС; дополнительно специальное назначение сертификата - Росреестр; дополнительно должность/логин пользователя - СУФД; дополнительно код организации - старые сертификаты ЕИС). Идентификатор ключа из сертификата использовать не рекомендуется, так как теоретически его можно подделать. Для ЕИС руководителя используется основная привязка по фио и снилс, однако отпечаток последнего сертификата по которому вошли записывается в БД. По инструкции от ЕИС (ИНСТРУКЦИЯ по регистрации организаций и пользователей в Единой информационной системе в соответствии с Приказом Казначейства России от 30.12.2015 г. No 27н) аутентификация руководителя производится по ФИО и ИНН. Данные руководителя в ЕИС передаются из реестра. В нашем случае, в региональной ЕИС, пользователь сначала подает заявку на доступ. В этой заявке выбирает свою организацию из списка организация, который мы получаем из ЕИС. И вот в этой заявке мы можем затребовать от руководителя загрузку его сертификата. И тогда мы сможем реализовать аутентификацию одинаково как для руководителя, так и для других сотрудников - по отпечатку сертификата. Пойдет такое решение?
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 39 Сказал(а) «Спасибо»: 8 раз
|
Автор: two_oceans Искать отпечатку в БД достаточно и можно, все верно. Вопрос в продлении сертификата через год - если привязаться к отпечатку, то через год к аккаунту надо будет как-то привязывать новый сертификат, специальную страницу, например, процедуру подтверждения администратором. А если к аккаунту прописать снилс, то можно будет автоматом опознать что пользователь продлил сертификат по соответствующим полям нового сертификата. Выбор за Вами, но однозначно удобнее не привязываться к конкретному отпечатку. А если сотрудник продлил сертификат, т.е. сертификат заменился на новый, то руководитель/администратор просто заменяет его сертификат на новый, и сотрудник снова сможет заходить. Мне кажется, что лучше пусть руководитель/администратор поменяет в базе сертификат сотрудника, чем выполнять автоматический вход по новому сертификату. А если руководитель сменил сертификат, то проверку можно будет выполнить по ФИО и ИНН. По старому сертификату аутентификация у него не пройдет. Отредактировано пользователем 29 декабря 2020 г. 12:26:18(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 39 Сказал(а) «Спасибо»: 8 раз
|
Вход по ЭЦП реализовал с помощью подписи хэша. На запросе формы аутентификации генерируем уникальную строку, создаем хэш этой строки, записываем ее в сессию и передаем в браузер: Код: 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,153 Откуда: Иркутская область Сказал(а) «Спасибо»: 76 раз
Поблагодарили: 264 раз в 248 постах
|
Автор: nomhoi А если руководитель сменил сертификат, то проверку можно будет выполнить по ФИО и ИНН. По старому сертификату аутентификация у него не пройдет. ОК, как мне кажется пойдет. Но технически тут вопрос какой ИНН получаете из ЕИС - ИНН организации или ИНН физлица. В идеале можно бы запросить оба - инн физлица можно сверять еще и с сертификатом. Автоматически одобрите заявку по совпадению данных в сертификате руководителя и данных об организации из ЕИС? Или кто-то будет видеть отчет сверки (на глаз сверять циферки не очень безопасно, предупреждение об отличии лучше оставить) и нажимать финальную кнопку принять/отказать? Принципиально источником данных является выписка из ЕГРЮЛ в которой указаны ФИО и инн руководителя. Потом это неким образом (не буду заострять внимание) попадает в ЕИС. Далее Вы получаете из ЕИС. По питону мне сложно так сходу ответить, посмотрю внимательней когда время найдется.
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
