Comments 7
… а просто не надо привязывать к сертификату область использования, а надо держать ее в ЕСИА, вот и будет счастье (есть ограничения на офлайн, конечно).
Отвечу пока на выделенный автором вопрос «Почему нельзя выдавать каждому сотруднику 1 (ОДНУ) ЭЦП и просто при каких либо изменениях добавлять или удалять в этом сертификате области использования?».
Во-первых просто так «добавлять или удалять» в сертификате ничего нельзя. В случае изменения контента сертификата он должен быть заново выпущен УЦ.
Во-вторых разные области использования обычно возникают как бы по мере необходимости. Например сначала сотруднику надо участвовать в электронных торгах, потом работать ещё в какой-то смежной системе и т.п. В каждой из систем зачастую необходимы свои политики применения сертификата. А так как сертификат нельзя вот просто так изменить то для новых областей использования выпускается новый сертификат.
Идеальный выход — это для всего набора политик использования сделать ещё один новый сертификат. Но тогда возникает другая проблема — зачастую ранее выпущенные сертификаты уже зарегистрированы в сторонних системах документооборота и привязаны к текущему пользователю. То есть после выпуска нового сертификата необходимо отозвать старые и заново «перепривязать» пользователя и новый сертификат в сторонних системах документооборота.
Во-первых просто так «добавлять или удалять» в сертификате ничего нельзя. В случае изменения контента сертификата он должен быть заново выпущен УЦ.
Во-вторых разные области использования обычно возникают как бы по мере необходимости. Например сначала сотруднику надо участвовать в электронных торгах, потом работать ещё в какой-то смежной системе и т.п. В каждой из систем зачастую необходимы свои политики применения сертификата. А так как сертификат нельзя вот просто так изменить то для новых областей использования выпускается новый сертификат.
Идеальный выход — это для всего набора политик использования сделать ещё один новый сертификат. Но тогда возникает другая проблема — зачастую ранее выпущенные сертификаты уже зарегистрированы в сторонних системах документооборота и привязаны к текущему пользователю. То есть после выпуска нового сертификата необходимо отозвать старые и заново «перепривязать» пользователя и новый сертификат в сторонних системах документооборота.
Кстати ещё одной причиной существования множества сертификатов от разных УЦ является то, что существует понятия «доверия» между УЦ. То есть для участия в определенной системе надо иметь сертификат в «доверенном» УЦ. А вот такие «доверительные отношения» сейчас далеки от «все со всеми». Так что для участия в разных системах зачастую надо иметь сертификаты от разных УЦ,
Во-первых и во-вторых: Абсолютно согласен, но например в моем конкретном случае несколько эцп у одного владельца уже несколько лет обновляются из года в год без изменений.
По поводу доверия между УЦ — почему бы это не продвинуть на государственном уровне, тем более есть 63-ФЗ и 795 приказ ФСБ.
Правда УЦ начнут терять деньги (зачем я буду получать платную КЭВ в УЦ №1 если мне точно такую же выпустит например Федеральное казначейство забесплатно).
Ну а вообще это пост — жалоба.
По поводу доверия между УЦ — почему бы это не продвинуть на государственном уровне, тем более есть 63-ФЗ и 795 приказ ФСБ.
Правда УЦ начнут терять деньги (зачем я буду получать платную КЭВ в УЦ №1 если мне точно такую же выпустит например Федеральное казначейство забесплатно).
Ну а вообще это пост — жалоба.
ЭЦП должна удостоверять человека, а что ему можно делать и что нет, должны решать те кто принимают данные подписанные конкретным ЭЦП.
Сам по себе ЭЦП никак не должна влиять на то можно что-то делать или нет определенному человеку в системе. Раз ме точ есть какие-то ограничения безопасности, короткий ключ например.
Приходит на ум. авторизация по ключу в SSH, у пользователя есть свой закрытый ключ и публичный, публичный ключ на необходимом сервере используется для предоставления определенных полномочий.
Так что дело совсем не в УЦ. А в том как ЭЦП обрабатывает ПО для которого оно требуется. Задача УЦ выдать электронное удостоверение с помощю которого можно получить определенный доступ. Прямо как паспорт, для достпа в режимный объект вас записываю и выдают пропуск(доступ). А паспорт(Сертификат выданный УЦ) обновляется в 25, 40 лет :)
Сам по себе ЭЦП никак не должна влиять на то можно что-то делать или нет определенному человеку в системе. Раз ме точ есть какие-то ограничения безопасности, короткий ключ например.
Приходит на ум. авторизация по ключу в SSH, у пользователя есть свой закрытый ключ и публичный, публичный ключ на необходимом сервере используется для предоставления определенных полномочий.
Так что дело совсем не в УЦ. А в том как ЭЦП обрабатывает ПО для которого оно требуется. Задача УЦ выдать электронное удостоверение с помощю которого можно получить определенный доступ. Прямо как паспорт, для достпа в режимный объект вас записываю и выдают пропуск(доступ). А паспорт(Сертификат выданный УЦ) обновляется в 25, 40 лет :)
Проблема выпуска универсального ключа в противоречиях требований к составу. Тендеры требуют одни данные, ФСРАР другие, а ЭДО третьи. Иногда есть возможность объединения кучи политик в один ключ, но далеко не всегда клиентам нужен такой супер ключ.
Сейчас, с появлением квалифицированной подписи, ситуация может станет несколько лучше, тем более с 01.01.14 других особо то и не останется в применении.
Сейчас, с появлением квалифицированной подписи, ситуация может станет несколько лучше, тем более с 01.01.14 других особо то и не останется в применении.
Sign up to leave a comment.
Проблема большого количества ЭЦП