Что несут свежие изменения в 63-ФЗ «об электронной подписи»

в 15:54, , рубрики: информационная безопасность, криптография, электронная подпись, электронные услуги

23 декабря 2015 года Государственной думой в 3м чтении был принят проект ФЗ-445 об изменении в 63-ФЗ «об электронной подписи». Так как многие коллеги еще не знакомы с этим законом, хотелось бы донести и рассказать чего коснутся изменения и как он повлияет на развитие единого пространства доверия в Российской Федерации. Но обо всем по порядку.

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

В итоге такой схемы взаимодействия УЦ с ГУЦ мы получали изоляцию пространств доверия каждого отдельного УЦ, так как все операционные системы и прикладное ПО проводят проверку сертификата ключа по цепочке сертификации, до тех пор, пока издатель сертификата не совпадет с владельцем сертификата. Таким образом получалась картина, что для того чтобы два пользователя с сертификатами двух разных УЦ доверяли друг другу, им было необходимо добавить сертификаты УЦ друг друга в доверенные. Тут специалисты мне вежливо укажут на кросс-сертификаты между УЦ, но я уверенно отвечу – это костыли, и объясню почему: Представьте, что вы в сети интернет и вы ходите от одного узла сети к другому, каждый из которых использует сертификат своего УЦ. Тогда, для обеспечения доверия всем узлам (они и правда доверенные) вам придётся иметь у себя локально сертификаты всех УЦ в Российской Федерации. Более того, вам придётся их самостоятельно поддерживать в актуальном состоянии. Оно вам надо?

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

image

Что произойдет в итоге изменений в 63-ФЗ внесенных 30 декабря 2015:

1. «Удостоверяющему центру запрещается указывать в создаваемом им сертификате ключа проверки электронной подписи ключ проверки электронной подписи, который содержится в сертификате ключа проверки электронной подписи, выданном этому удостоверяющему центру любым другим удостоверяющим центром.»

Или «переводя с русского на русский» УЦ теперь запрещено самостоятельно генерировать себе «самоподписанные» сертификаты.

Более того, уточняется: «Аккредитованный удостоверяющий центр для подписания от своего имени квалифицированных сертификатов обязан использовать квалифицированную электронную подпись, основанную на квалифицированном сертификате, выданном ему головным удостоверяющим центром, функции которого осуществляет уполномоченный федеральный орган. Аккредитованному удостоверяющему центру запрещается использовать квалифицированную электронную подпись, основанную на квалифицированном сертификате, выданном ему головным удостоверяющим центром, функции которого осуществляет уполномоченный федеральный орган, для подписания сертификатов, не являющихся квалифицированными сертификатами».

То есть, теперь не важно, кем выдан сертификат вашего ключа ЭП, так как все сертификаты проверки ключа ЭП позволяют построить цепочки сертификатов до Головного Удостоверяющего центра. И все что остается пользователю – иметь в доверенных только сертификат ГУЦ.

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

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

Ведомствам издателям сертификатов теперь ЗАПРЕЩЕНО вносить с сертификаты дополнительные поля и требования их обязательности. Это, безусловно, убьет интересы ФНС, Росреестра и прочих ведомств требующих наличия только «своих» сертификатов. Зато, теперь, имея одну единственную квалифицированную ЭП вы можете быть авторизованы и использовать ВСЕ государственные информационные системы.

4. Исправлены досадные неточности в 63-ФЗ, например, связанные с тем, что СКЗИ должно самостоятельно визуализировать подписываемый документ, и пр..

5. Увеличена ответственность УЦ за причинение убытков третьим лицам, уточнены требования к срокам публикации списков отозванных сертификатов и их доступности в сети Интернет.

Резюмирую. Предложенные Минкомсвязью и принятые государственной думой изменения в закон о электронной подписи сильно упростят жизнь простых пользователей ЭП, и позволят им использовать одну подпись для доступа ко всем государственным ресурсам. С другой стороны эти изменения не сильно усложнят жизнь УЦ, так как теперь вместо запроса на «подписание кросса» в ИС ГУЦ, они обязаны будут делать запрос на подчиненный сертификат (это все тот же запрос PKCS#10 и ПО менять не придётся).

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

Скажу честно, я доволен работой МКС по развитию пространства доверия, которое перерастает детские болезни в области использования ЭП в России, давно пора.

Автор: slay2000

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js