что такое oid в эцп

Отмена OID на электронных торговых площадках и государственных порталах

1 июля 2020 год вступила в силу часть 2.1 статьи №17 Федерального закона № 63 от 06 апреля 2011 г. в редакции от 08.06.20г. Которая вводит запрет для ряда информационных систем, а так же некоторым электронным торговым площадкам требовать внесения в состав сертификата электронной подписи специального объектного идентификатора OID.

Данный введенный запрет, в основном коснулся федеральных информационных систем. И информационных систем массового пользования организациями и физическими лицами. Деятельность этих систем регулируется различными правовыми нормами и актами. В случае отказа торговой площадки от внесения объектного идентификатора OID, в сертификат электронной подписи. То для работы на такой площадке будет достаточно приобрести обычную Квалифицированную Электронную подпись КЭП.

Торговые площадки по своему трактовали это законодательное нововведение. В связи с этим далеко не все площадки решили отказаться от использования OID в сертификатах КЭП.

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

Но далеко не все торговые площадки отказались от использования в сертификатах ЭП дополнительных OID. Такие площадки как НЭП-Фабрикант и B2B-Center от использования дополнительного расширения не отказались. Но дали возможность регистрации сертификата ЭЦП без требуемого OID. Теперь можно провести регистрацию со стандартной КЭП. Для того чтобы вы смогли использовать свою ЭЦП, вам потребуется заплатить за регистрацию вашей ЭП. На данный момент стоимость регистрации Электронной подписи на ЭТП B2B Center составляет 1600 руб. Стоимость регистрации на ЭТП НЭП-Фабрикант составит 2500 руб. Столько же примерно стоит доплата за данное расширение если купить электронную подпись в УЦ.

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

Источник

Квалифицированная электронная подпись — проблемы OID’ов информационных систем.

Вадим Малых
02.10.2013

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

Если начинать с базовых понятий, электронное подписание основывается на асимметричных алгоритмах шифрования. Основная особенность этих алгоритмов в том, что для шифрования и расшифровки сообщения используются два разных ключа. Широкой общественности более знакомы симметричные алгоритмы, когда одним ключом (или паролем) мы и шифруем и расшифровываем сообщение, например архивируем файл с паролем или защищаем документ MS Word.

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

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

Как все это работает, в двух словах. Берем асимметричный алгоритм шифрования, генерируем пару ключей (для шифрования и расшифровки). Ключ шифрования даем человеку, который будет подписывать документы. Он его должен всегда держать при себе и никому не давать. Поэтому его называют «закрытый» ключ. Другой ключ (расшифровки) даем всем желающим, поэтому он «открытый». Подписывая документ, человек должен зашифровать его своим закрытым ключом. На самом деле шифруется не сам документ, так как он может быть достаточно большим, а нам вообще-то и не нужно его шифровать. Поэтому по документу получают хэш — это некая числовая последовательность с большой долей вероятности разная для разных документов, как бы «отпечаток» документа. Его и шифруют закрытым ключом подписанта. Этот зашифрованный хэш и есть электронная подпись документа. Теперь имея документ, подпись и открытый ключ, любой может легко проверить, что именно этот документ был подписан именно этим закрытым ключом. Для этого снова получаем хэш документа, расшифровываем открытым ключом подпись и сравниваем. Должны получить две идентичные числовые последовательности.

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

Итак, подписание производится закрытым ключом, а проверка подписи открытым. Поэтому фраза «документ подписывается набором OID» (прозвучавшая в упомянутом споре) лишена всякого смысла. В процедуре подписания и проверки участвуют только два ключа, в 63-ФЗ они и названы соответственно — ключ подписи и ключ проверки подписи.

А что такое эти пресловутые OID? Формат цифрового сертификата X.509 позволяет сохранять в нем расширения (extensions). Это некие необязательные атрибуты, при помощи которых можно хранить дополнительную информацию. Каждый такой атрибут является объектом, который задается идентификатором из иерархического справочника. Отсюда OID — Object Identifier. Углубляться в природу самих OID здесь смысла нет. По сути это некоторая дополнительная информация, которая может присутствовать в сертификате.

Данные дополнительные атрибуты могут использоваться для разных целей. Они могут либо предоставлять дополнительную информацию о владельце, ключах, УЦ, либо нести какую-то дополнительную информацию для приложений и сервисов, которые этот сертификат используют. Самое распространенное применение — это управление доступами на основе ролей. Например, в сертификате можно прописать, что владелец ключа является руководителем организации, и это даст ему возможность сразу во всех ИС получить доступ к нужным функциям и сведениям, без необходимости связываться с администраторами каждой ИС и менять настройки доступа. Все это конечно при условии, что все эти ИС используют сертификат пользователя для его авторизации и анализируют один и тот-же атрибут одинаковым образом (для того-то атрибуты и выбираются из справочника, а не задаются произвольно).

Как видим, никакие законодательные нормы не диктуют обязательного наличия в квалифицированном сертификате атрибутов, связанных с авторизацией в каких-либо информационных системах. Откуда тогда эти требования берутся? А исходят они от разработчиков (или «владельцев») конкретных систем. Возьмём например «Методические рекомендации по использованию электронной подписи при межведомственном электронном взаимодействии (версия 4.3)», размещенные на технологическом портале СМЭВ. Действительно, в пункте 6 данного документа читаем: «При подготовке сведений для формирования сертификата ЭП-СП необходимо определить необходимость запроса сведений из Росреестра (выписки из ЕГРП). При необходимости такого запроса в поле “Улучшенный ключ” (OID=2.5.29.37) в сертификате ЭП-СП должен быть указан OID по требованиям Росреестра.». То есть информационная система Росреестра использует этот атрибут для определения сведений, которые можно выдавать владельцу сертификата. Однако этот же документ содержит важное примечание, а именно — данное требование действует до полного запуска ЕСИА (единый сервис авторизации в гос. системах) и подключения к ней системы Росреестра. Это важное замечание, запомним его.

Не буду разбираться с другими ИС, применяемыми в гос. органах. Подозреваю, что там ситуация похожая. Портал госзакупок, электронные торговые площадки, различные бухгалтерские и финансовые приложения также могут требовать наличия тех или иных дополнительных OID в сертификате пользователя. При этом утверждение, что прописывая OID информационной системы в сертификате, я каким-либо образом делегирую ответственность удостоверяющему центру, мягко говоря, неверно. УЦ вносит эти данные в сертификат согласно моей заявки. Если у меня изменилась должность, а я забыл подать заявку на отзыв старого и выпуск нового сертификата, УЦ никак не может отвечать за мою забывчивость. К тому-же закон 63-ФЗ прямо закрепляет ответственность за неправильное использование сертификата за его владельцем. В пункте 6 статьи 17 читаем:
Владелец квалифицированного сертификата обязан:
1) не использовать ключ электронной подписи и немедленно обратиться в аккредитованный удостоверяющий центр, выдавший квалифицированный сертификат, для прекращения действия этого сертификата при наличии оснований полагать, что конфиденциальность ключа электронной подписи нарушена;
2) использовать квалифицированную электронную подпись в соответствии с ограничениями, содержащимися в квалифицированном сертификате (если такие ограничения установлены).

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

Налицо стопроцентное попадание в концепцию, именуемую в мире Attribute Certificate (или Authorization Certificate), о которой говорилось выше и при которой рекомендуется выпускать эти сертификаты другим удостоверяющим центром (Attribute Autority, в отличие от Certificate Authority — обычного УЦ, выпускающего квалифицированные сертификаты ЭП) и по упрощенной схеме. Этот сертификат сам по себе не должен содержать ключа электронной подписи и информации о владельце. Вместо этого он содержит ссылку на сертификат открытого ключа владельца, из которого можно получить остальную необходимую информацию о персоне.

Необходимо заметить, что и эта схема имеет весьма ограниченное применение и не решает всех проблем. Что если очередная информационная система решит использовать то-же поле сертификата “Улучшенный ключ” (OID=2.5.29.37), которое уже занято значением Росреестра, для своих нужд? Вписать два разных значения в одно поле не получится. Следовательно придется выпускать ещё один AC! Другая проблема связана с коротким временем жизни PKC (один год). Если имеем несколько AC (в которых содержится ссылка на персональный сертификат), их все придется перевыпустить по истечении срока PKC. Для эффективного применения AC необходим некий единый центр авторизации пользователей во всех информационных системах, а все приложения должны согласованно и единообразно использовать атрибуты сертификатов.

Такой единый центр авторизации для гос. органов уже есть — это ЕСИА. Вспомним про примечание, касающееся OID’ов Росреестра. В будущем они будут заменены информацией из ЕСИА. Так же должны поступать и прочие информационные системы, в которых работают гос. служащие. Вместо использования AC для авторизации, необходимо интегрироваться с ЕСИА и получать необходимую информацию оттуда. ЕСИА должна иметь возможность привязки квалифицированного сертификата ЭП к учетной записи, таким образом информационные системы смогут проводить аутентификацию пользователя по персональному ключу, а его авторизацию (предоставление доступа к приложению) через ЕСИА. Такая система представляется универсальней и надежней, чем применение полей сертификатов, а в перспективе позволит автоматизировать управление доступами. Если будет создана единая система кадрового учета гос. служащих, ЕСИА сможет брать информацию о полномочиях того или иного лица непосредственно оттуда. Перевелся человек на другую должность — автоматически потерял доступ к одним системам и получил к другим. При этом он продолжает пользоваться своим ключом ЭП для подписания документов, ничего перевыпускать не нужно.

Вывод — OID’ы информационных систем в сертификате, не являясь абсолютным злом сами по себе, требуют взвешенного применения. У данного подхода есть альтернативы, которые стоит рассмотреть, например единые сервисы авторизации.

Источник

Электронная подпись для торгов. Что это такое, зачем она нужна и как получить?

что такое oid в эцп. Смотреть фото что такое oid в эцп. Смотреть картинку что такое oid в эцп. Картинка про что такое oid в эцп. Фото что такое oid в эцп

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

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

Более того, ЭЦП сейчас должна быть у каждого участника закупок, ведь именно с её помощью регистрируются в ЕИС, отправляют заявки на участие, участвуют и подписывают контракты.

Конечно, при желании можно найти и процедуры на бумажных носителях, так называемые конверты, и закупки коммерческого сектора без требований наличия цифровой подписи. Да что уж там, есть даже ЭТП, где вообще не нужна цифровая подпись! Но стоит ли создавать себе такие ограничения, учитывая, что получить ЭЦП не так сложно?

Какими бывают ЭЦП

что такое oid в эцп. Смотреть фото что такое oid в эцп. Смотреть картинку что такое oid в эцп. Картинка про что такое oid в эцп. Фото что такое oid в эцп

Видов электронной подписи не так много, запутаться не получится :). Различаются они по уровню юридической значимости.

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

Усиленная неквалифицированная электронная подпись — уже более серьёзный вариант! Такая ЭЦП создаётся при помощи криптографии – специального механизма шифрования данных. Чаще всего неквалифицированная подпись используется во внутреннем документообороте и позволяет отследить, изменился ли документ после подписания.

Усиленная квалифицированная электронная подпись (КЭП) – представляет собой, фактически, аналог рукописной подписи или печати компании. Документы, подписанные такой ЭЦП, обретают правовую силу и используются, как раз таки, в госзакупках. Регистрация в ЕИС, отправка заявки, отправка ценового предложения и заключение контракта – далеко не полный список вариантов применения КЭП. Эта подпись генерируется с помощью сертифицированных криптографических механизмов, что гарантирует максимальную защищенность и возможность отследить изменения в подписанной документации.

Помимо этих, основных видов, существует ещё один интересный вариант – облачная квалифицированная электронная подпись или ОКЭП. Такая ЭЦП обладает тем же функционалом, что и КЭП, только находится на сервере удостоверяющего центра, в котором её получили.

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

Что такое сертификат электронной подписи?

что такое oid в эцп. Смотреть фото что такое oid в эцп. Смотреть картинку что такое oid в эцп. Картинка про что такое oid в эцп. Фото что такое oid в эцп

Для того, чтобы воспользоваться токеном, необходимо иметь сертификат электронной подписи. Именно он гарантирует юридическую силу ЭЦП и её принадлежность конкретному человеку. Существует сертификат как в бумажном, так и в электронном виде.

В зависимости от удостоверяющего центра, срок действия сертификата может отличаться. Самым популярным вариантом является годовой, но существуют как на 3 месяца и 6 месяцев, так и на 15 месяцев.

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

Кстати об областях применения! Для работы на конкретных ЭТП, необходимо наличие специальных расширений в сертификате – идентификаторов OID. Удостоверяющий центр вносит их при выпуске новой КЭП, а также по запросу в уже имеющуюся. Одна цифровая подпись может содержать несколько расширений, поэтому нет необходимости выпускать много для разных площадок.

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

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

Как получить ЭЦП

что такое oid в эцп. Смотреть фото что такое oid в эцп. Смотреть картинку что такое oid в эцп. Картинка про что такое oid в эцп. Фото что такое oid в эцп

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

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

Чтобы воспользоваться подписью, после получения сертификата, необходимо приобрести носитель (токен), а также программу для проверки и защиты ЭЦП.

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

Как пользоваться ЭЦП

что такое oid в эцп. Смотреть фото что такое oid в эцп. Смотреть картинку что такое oid в эцп. Картинка про что такое oid в эцп. Фото что такое oid в эцп

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

Если опустить все эти особенности, то процедура выглядит так:

Источник

Что такое oid в эцп

Не задан ID пользователя.

Если начинать с базовых понятий, электронное подписание основывается на асимметричных алгоритмах шифрования. Основная особенность этих алгоритмов в том, что для шифрования и расшифровки сообщения используются два разных ключа. Широкой общественности более знакомы симметричные алгоритмы, когда одним ключом (или паролем) мы и шифруем и расшифровываем сообщение, например архивируем файл с паролем или защищаем документ MS Word.

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

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

Как все это работает, в двух словах. Берем асимметричный алгоритм шифрования, генерируем пару ключей (для шифрования и расшифровки). Ключ шифрования даем человеку, который будет подписывать документы. Он его должен всегда держать при себе и никому не давать. Поэтому его называют «закрытый» ключ. Другой ключ (расшифровки) даем всем желающим, поэтому он «открытый». Подписывая документ, человек должен зашифровать его своим закрытым ключом. На самом деле шифруется не сам документ, так как он может быть достаточно большим, а нам вообще-то и не нужно его шифровать. Поэтому по документу получают хэш — это некая числовая последовательность с большой долей вероятности разная для разных документов, как бы «отпечаток» документа. Его и шифруют закрытым ключом подписанта. Этот зашифрованный хэш и есть электронная подпись документа. Теперь имея документ, подпись и открытый ключ, любой может легко проверить, что именно этот документ был подписан именно этим закрытым ключом. Для этого снова получаем хэш документа, расшифровываем открытым ключом подпись и сравниваем. Должны получить две идентичные числовые последовательности.

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

Итак, подписание производится закрытым ключом, а проверка подписи открытым. Поэтому фраза «документ подписывается набором OID» (прозвучавшая в упомянутом споре) лишена всякого смысла. В процедуре подписания и проверки участвуют только два ключа, в 63-ФЗ они и названы соответственно — ключ подписи и ключ проверки подписи.

А что такое эти пресловутые OID? Формат цифрового сертификата X.509 позволяет сохранять в нем расширения (extensions). Это некие необязательные атрибуты, при помощи которых можно хранить дополнительную информацию. Каждый такой атрибут является объектом, который задается идентификатором из иерархического справочника. Отсюда OID — Object Identifier. Углубляться в природу самих OID здесь смысла нет. По сути это некоторая дополнительная информация, которая может присутствовать в сертификате.

Данные дополнительные атрибуты могут использоваться для разных целей. Они могут либо предоставлять дополнительную информацию о владельце, ключах, УЦ, либо нести какую-то дополнительную информацию для приложений и сервисов, которые этот сертификат используют. Самое распространенное применение — это управление доступами на основе ролей. Например, в сертификате можно прописать, что владелец ключа является руководителем организации, и это даст ему возможность сразу во всех ИС получить доступ к нужным функциям и сведениям, без необходимости связываться с администраторами каждой ИС и менять настройки доступа. Все это конечно при условии, что все эти ИС используют сертификат пользователя для его авторизации и анализируют один и тот-же атрибут одинаковым образом (для того-то атрибуты и выбираются из справочника, а не задаются произвольно).

Как видим, никакие законодательные нормы не диктуют обязательного наличия в квалифицированном сертификате атрибутов, связанных с авторизацией в каких-либо информационных системах. Откуда тогда эти требования берутся? А исходят они от разработчиков (или «владельцев») конкретных систем. Возьмём например «Методические рекомендации по использованию электронной подписи при межведомственном электронном взаимодействии (версия 4.3)», размещенные на технологическом портале СМЭВ. Действительно, в пункте 6 данного документа читаем: «При подготовке сведений для формирования сертификата ЭП-СП необходимо определить необходимость запроса сведений из Росреестра (выписки из ЕГРП). При необходимости такого запроса в поле “Улучшенный ключ” (OID=2.5.29.37) в сертификате ЭП-СП должен быть указан OID по требованиям Росреестра.». То есть информационная система Росреестра использует этот атрибут для определения сведений, которые можно выдавать владельцу сертификата. Однако этот же документ содержит важное примечание, а именно — данное требование действует до полного запуска ЕСИА (единый сервис авторизации в гос. системах) и подключения к ней системы Росреестра. Это важное замечание, запомним его.

Не буду разбираться с другими ИС, применяемыми в гос. органах. Подозреваю, что там ситуация похожая. Портал госзакупок, электронные торговые площадки, различные бухгалтерские и финансовые приложения также могут требовать наличия тех или иных дополнительных OID в сертификате пользователя. При этом утверждение, что прописывая OID информационной системы в сертификате, я каким-либо образом делегирую ответственность удостоверяющему центру, мягко говоря, неверно. УЦ вносит эти данные в сертификат согласно моей заявки. Если у меня изменилась должность, а я забыл подать заявку на отзыв старого и выпуск нового сертификата, УЦ никак не может отвечать за мою забывчивость. К тому-же закон 63-ФЗ прямо закрепляет ответственность за неправильное использование сертификата за его владельцем. В пункте 6 статьи 17 читаем:
Владелец квалифицированного сертификата обязан:
1) не использовать ключ электронной подписи и немедленно обратиться в аккредитованный удостоверяющий центр, выдавший квалифицированный сертификат, для прекращения действия этого сертификата при наличии оснований полагать, что конфиденциальность ключа электронной подписи нарушена;
2) использовать квалифицированную электронную подпись в соответствии с ограничениями, содержащимися в квалифицированном сертификате (если такие ограничения установлены).

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

Налицо стопроцентное попадание в концепцию, именуемую в мире Attribute Certificate (или Authorization Certificate), о которой говорилось выше и при которой рекомендуется выпускать эти сертификаты другим удостоверяющим центром (Attribute Autority, в отличие от Certificate Authority — обычного УЦ, выпускающего квалифицированные сертификаты ЭП) и по упрощенной схеме. Этот сертификат сам по себе не должен содержать ключа электронной подписи и информации о владельце. Вместо этого он содержит ссылку на сертификат открытого ключа владельца, из которого можно получить остальную необходимую информацию о персоне.

Необходимо заметить, что и эта схема имеет весьма ограниченное применение и не решает всех проблем. Что если очередная информационная система решит использовать то-же поле сертификата “Улучшенный ключ” (OID=2.5.29.37), которое уже занято значением Росреестра, для своих нужд? Вписать два разных значения в одно поле не получится. Следовательно придется выпускать ещё один AC! Другая проблема связана с коротким временем жизни PKC (один год). Если имеем несколько AC (в которых содержится ссылка на персональный сертификат), их все придется перевыпустить по истечении срока PKC. Для эффективного применения AC необходим некий единый центр авторизации пользователей во всех информационных системах, а все приложения должны согласованно и единообразно использовать атрибуты сертификатов.

Такой единый центр авторизации для гос. органов уже есть — это ЕСИА. Вспомним про примечание, касающееся OID’ов Росреестра. В будущем они будут заменены информацией из ЕСИА. Так же должны поступать и прочие информационные системы, в которых работают гос. служащие. Вместо использования AC для авторизации, необходимо интегрироваться с ЕСИА и получать необходимую информацию оттуда. ЕСИА должна иметь возможность привязки квалифицированного сертификата ЭП к учетной записи, таким образом информационные системы смогут проводить аутентификацию пользователя по персональному ключу, а его авторизацию (предоставление доступа к приложению) через ЕСИА. Такая система представляется универсальней и надежней, чем применение полей сертификатов, а в перспективе позволит автоматизировать управление доступами. Если будет создана единая система кадрового учета гос. служащих, ЕСИА сможет брать информацию о полномочиях того или иного лица непосредственно оттуда. Перевелся человек на другую должность — автоматически потерял доступ к одним системам и получил к другим. При этом он продолжает пользоваться своим ключом ЭП для подписания документов, ничего перевыпускать не нужно.

Вывод — OID’ы информационных систем в сертификате, не являясь абсолютным злом сами по себе, требуют взвешенного применения. У данного подхода есть альтернативы, которые стоит рассмотреть, например единые сервисы авторизации.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *