⚡️АРБ просит Минтруд и Минэк доработать законопроект о кадровом ЭДО

Ассоциация российских банков направила письма Министру труда и соцзащиты, Замминистру экономического развития с замечаниями к законопроекту об изменениях в Трудовой кодекс.

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

- из пояснительной записки.

Ассоциация концептуально идею развития кадрового ЭДО, в том числе через мессенджер Скам, поддерживают, но задаёт следующие вопросы

1️⃣ Законопроект предлагает вариативность - "письменная форма" или "форма электронного документа", но электронный документ тоже является письменной формой. АРБ предлагает закрепить общее правило - переход на КЭДО только при получении работодателем письменного согласия работника.

2️⃣ Законопроект сужает использование простой ЭП - только ПЭП ЕСИА. АРБ предлагает сохранить действующую редакцию абзаца пятого ч. 5 ст. 22.3 ТК, изменения могут привести к дополнительным расходам работодателей. Новые положения предлагается добавить отдельным абзацем.

3️⃣ АРБ считает необходимым предусмотреть возможность подписания согласия работника КЭП, сертификаты которых выданы коммерческими АУЦ, а не только монополия НЭП/КЭП Госключа в связке со Скамом. Отмечается, что ведение ограничения не отвечает характеру и степени рисков ненадлежащего оформления кадровых документов.

4️⃣ Работу над изменениями в ТК предлагается вести одновременно с внесением изменений в соответствующие нормативные акты, чтобы экспертиза регулирования была более полной.

АРБ просит учесть позицию при доработке законопроекта. Учтёт ли Минтруд эти предложения?

Реализация мер, предлагаемых проектом закона потребует выделения бюджетных ассигнований (неожиданно, правда?) на развитие единой цифровой платформы в сфере занятости и трудовых отношений «Работа в России» в объеме 142, 6 млн. рублей.

В ФГИС КИ заведен ИТР «Развитие ЕЦП «Работа в России». Подписание электронных документов в рамках трудового права посредством национального мессенджера (MAX)» № 150.26.000058

В очередной раз мы видим, что вместо устранения старой ошибки в статье 22.2:

Работодатель несет расходы на получение работником электронной подписи (в случае ее отсутствия) и ее использование.

Работник или лицо, поступающее на работу, вправе использовать ранее полученную самостоятельно усиленную квалифицированную электронную подпись

- допускается новая. ПЭП это профанация электронной подписи, она не для кадровых документов. Удобнее облачной НЭП всё равно ничего не придумать.

✍️Об ЭП и УЦ

✍️Инцидент с ключами УЦ eMudhra - большой разбор от телеграм-канала "Об ЭП и УЦ"

По официальным заявлениям eMudhra все ключи генерировались с использованием HSM, сертифицированных по FIPS 140-2 Level 3. Однако конкретная модель HSM и процедура проверки стойкости закрытых ключей не раскрываются.

Тем не менее удалось выяснить:
🔹В обсуждениях инцидента на Bugzilla упоминается, что eMudhra использовала устройства Ultimaco для генерации пар ключей ECC и RSA для промежуточных ЦС. Официального подтверждения модели от самой компании в доступных материалах нет.
🔹eMudhra настаивает, что HSM соответствовали стандарту FIPS 140-2 Level 3, этот стандарт предполагает высокий уровень физической защиты и обнаружения несанкционированного доступа (что-то в районе КС3 по нашему).
🔹Согласно описанию архитектуры eMudhra, ключи корневых ЦС хранятся на изолированных HSM, а ключи промежуточных - на онлайн-кластерах HSM. Ключи генерируются внутри HSM и никогда не покидают его в открытом виде.

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

❌Но в данном случае проверка не выявила проблему по нескольким причинам:
🔹Сбой произошел на уровне скрипта, а не HSM - по версии eMudhra HSM сгенерировал два набора ключей из-за ошибки в скрипте на этапе wrap/unwrap. Слабые ключи не были результатом отказа HSM, а стали результатом сбоя работы скрипта в ходе церемонии генерации. Логика скрипта была такой:
- HSM корректно сгенерировал сильную пару ключей.
- на этапе подготовки к "обёртыванию" или в процессе него скрипт по ошибке создал слабую пару.
- слабые ключи были использованы.
Открытый вопрос - почему внешний скрипт, управлявший процедурой, обошёл или проигнорировал корректно сгенерированные HSM ключи, подставив вместо них слабые значения?
🔹Далее человеческий фактор, куда же без него. Из-за схожих меток операторы по ошибке выбрали для создания файла запроса на сертификат именно слабую пару ключей, а не изначально сгенерированную сильную.
🔹Отсутствие проверки на выходе - тоже человеческий фактор. Судя по всему, на этапе подписания CSR корневым ЦС не проводилась проверка энтропии или валидация приватного ключа на соответствие требуемым по стойкости параметрам. Слабые ключи прошли через процедуру подписания, сертификаты были созданы и опубликованы.
🔹Почему ничего не выявил аудит? Проблема оставалась незамеченной около 18 месяцев и прошла через два независимых аудиторских цикла. Ответ на самом деле простой - стандартные аудиторские проверки не включали тестирование стойкости сгенерированных ключей.

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

Ultimaco находится в контакте с eMudhra для понимания их процессов и использованного скрипта. Основной вывод производителя: проблема вызвана ошибкой в скрипте, который создал альтернативные ключи и использовал их вместо оригинальных, сгенерированных на HSM.

Ultimaco подтверждено, что все ключи внутри их HSM генерируются с использованием сертифицированных генераторов случайных чисел в соответствии с методами FIPS 186. В заявлении подчеркивается, что HSM Ultimaco не поставляются с тестовыми ключами, которые можно было бы ошибочно использовать.

Ultimaco дистанцируется от инцидента, указывая, что их оборудование работало штатно, а слабые ключи появились в результате ошибки в скрипте eMudhra, который обошёл или проигнорировал корректно сгенерированные HSM ключи.

Результат ошибки - падение акций компании на Национальной фондовой бирже Индии на 41,2% в октябре, уход с рынка международного УЦ и пресс-релизы только по вопросам TLS-сертификатов.

✍️Об ЭП и УЦ

✍️CA/B Forum удаляет из Базовых требований и Руководства по расширенной проверке требование о высоком риске

Закончился период голосования по бюллетеню "SC105: Remove High Risk language from TLS BR and EVG", бюллетень принят:
🔹удаляется определение "High Risk Certificate Request"
🔹удаляется требование из раздела 4.2.1 TLS BR - разрабатывать и применять документированные процедуры выявления запросов высокого риска и доп. проверки по ним
🔹удаляется раздел 3.2.2.12.1 EVG (High Risk Status), распространявший эти требования на EV-сертификаты
🔹обновляются смежные ссылки

Требование о "высоком риске" подвергалось критике, как расплывчатое и неисполнимое:
🔹не определено, что считать запросом высокого риска.
🔹УЦ и аудиторы не имели объективной базы для оценки его соблюдения.
🔹фактически было заменено конкретными механизмами контроля, добавленными в BR за последние годы: обработка CAA, DNSSEC, Multi-Perspective Issuance Corroboration, отказ от слабых методов валидации и др.

УЦ не лишаются права применять риск-ориентированные меры контроля, но уже в рамках собственных CP/CPS. Одобренная корректировка исключает лишь неопределённое обязательство из требований Форума. Следующий этап - период проверки интеллектуальных прав.

Вот бы наш регулятор также отредактировал пункт 1 части 1 статьи 10 63-ФЗ:

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

и удалил эту противоречивую фразу насчёт согласия.

✍️Об ЭП и УЦ

📣Онлайн-конференция Электронная подпись 2026

11 ноября в 11.00 состоится онлайн-конференция на тему: "Электронная подпись 2026: стала массовой, но стала ли удобнее?"

Темы для обсуждения определены, спикеры - в процессе, онлайн-конфереция проходит при поддержке телеграм-канала "Об ЭП и УЦ".

Участие бесплатное, регистрация по ссылке, присоединяйтесь к эфиру, голосуйте и задавайте свои вопросы!

✍️Об ЭП и УЦ

📣Подборка самых важных новостей о сфере электронной подписи от нашего канала по итогам октября 2026 года

1️⃣ Продлена аккредитация удостоверяющих центров Электронной Москвы и Альфа-Банка, количество АУЦ не изменилось - 43 шт.

2️⃣ Количество доверенных лиц УЦ ФНС России увеличилось до 8 организаций

3️⃣ Вступил в силу 355 приказ ФСБ России, внесший изменения в 6 приказов регулятора в части исключения сроков их действия, а также актуализации норм

4️⃣ УЦ ФК перешел 5 октября на создание сертификатов заявителям с использованием нового подчиненного сертификата от 22.09.2026

5️⃣ Госдума приняла в первом чтении законопроект о взимании УЦ ФК платы за выдачу квалифицированных сертификатов в 2027-2029 годах

6️⃣ Минцифры обработаны поступившие предложения на проект приказа о требованиях к сертификатам безопасности,  для общественного обсуждения размещен проект приказа об утверждении требований к порядку реализации функций НУЦ

7️⃣ Система адвокатов КИС АР,  портал Госуслуг и сайт Минцифры (RSA на LiteSSL) перешли на использование ГОСТового сертификата от НУЦ

8️⃣ Опубликовано видео секций PKI-Форума 2026

9️⃣ Информационное письмо для пользователей Рутокен S

🔟 Письма Ассоциации российских банков в адрес Минцифры и Судебного департамента о судебных документах без электронной подписи, также АРБ просит Минтруд и Минэк доработать законопроект о кадровом ЭДО

1️⃣1️⃣ Приказом Минюста внесены изменения в требования к формату нотариально оформляемого документа в электронной форме

1️⃣2️⃣ Проблемы с использование PKCS#7, в том числе и некорректным

1️⃣3️⃣ План оценки применения обязательных требований в сфере электронной подписи на 2027 год

1️⃣4️⃣ Подбор и компрометация слабых ключей промежуточных УЦ eMudhra (1, 2, 3, 4, 5, 6, 7, 8)

1️⃣5️⃣ Cloudflare сообщил о намерении создать удостоверяющий центр для всего Интернета

1️⃣6️⃣ Новости CA/Browser Forum: обновлены базовые требования - AIA, как опция; возражение против бюллетеня SC-081v3 по необоснованному сокращению сроков действия TLS-сертификатов; SC-105 - удаление требования о высоком риске

1️⃣7️⃣ Китай ужесточает контроль в сфере электронной подписи

1️⃣8️⃣ Фейковые TLS-сертификаты для Google и других сервисов

1️⃣9️⃣ Критика законопроекта Минтруда и Минэка об изменении кадрового ЭДО

2️⃣0️⃣ Анонсирована онлайн-конференция AM Live "Электронная подпись 2026"

✍️Об ЭП и УЦ

✍️Минцифры станет и регулятором, и оператором НУЦ. Это норма?

На очереди разбор проекта постановления, который наделяет Минцифры функциями национального удостоверяющего центра по новой ст. 13¹ 63-ФЗ, вступающей в силу 1 марта 2027 года.

Я полагал, что это будет аналог 976-ПП "О федеральном органе исполнительной власти, уполномоченном
в сфере использования электронной подписи" - о федеральном органе исполнительной власти, уполномоченном на осуществление функций в сфере использования сертификатов безопасности НУЦ с внесением изменений в Положение о Минцифры.

Но изменения вносятся только в Положение о Минцифры:
🔹 Ведомство утверждает требования к сертификатам безопасности НУЦ, порядку их выдачи, аутентификации и ведению реестра (пп. 5.2.73–5.2.78)
🔹Оно же всё это исполняет: создаёт и выдаёт сертификаты, ведёт реестр, выдаёт ключи идентификации и аутентификации (пп. 5.4.28–5.4.34).

То есть Минцифры (по согласованию с ФСБ) устанавливает правила и само же их выполняет. Видится, что это конфликт "регулятор - оператор", по деятельности АУЦ такого нет, Минцифры устанавливает требования, как Головной УЦ, а аккредитованные УЦ из соблюдают. А с сертификатами безопасности проверять соблюдение требований будет тот, кто их написал и сам же исполняет. Техническая часть будет у отдельного оператора, которого определит Правительство по согласованию с ФСБ. Это частично снижает риски, но нормотворчество и операционка всё равно остаются в одних руках.

В пояснительной записке сказано, что допрасходов не потребуется.

А как вы считаете - допустимо ли совмещать регулятора и оператора в одном ведомстве?

✍️Об ЭП и УЦ