⚖️ Судебная практика. А была ли кибератака?

Восьмой арбитражный апелляционный суд (дело А70-12019/2026) оставил в силе решение о включении ИП в реестр недобросовестных поставщиков на 2 года. ИП не подписал контракт по итогам электронного аукциона, сославшись на… хакерскую атаку.

Заказчик разместил проект контракта 21.04.2026, срок подписания - до 28.04.2026. Предприниматель контракт не подписал и обеспечение не предоставил. Ссылался на то, что 22.04.2026 его компьютер подвергся кибератаке, и возможность подписать контракт появилась только 29.04.2026.

Две судебные инстанции решили:
🔹21.04.2026 у предпринимателя была реальная возможность подписать контракт, но он этого не сделал.
🔹21 и 22 апреля он заходил в личный кабинет на электронной площадке, но никаких действий не совершил.
🔹Токен - съёмный носитель, его можно использовать на любом другом компьютере.
🔹Доказательств, что подписать контракт было невозможно с иного устройства, не представлено.

Ключевой тезис суда:

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

Недобросовестность определяется не виной, а степенью осмотрительности. Участвуешь в закупках - будь добр отвечать за работоспособность своей техники.

Кто сказал про мобильную подпись?

✍️"Об ЭП и УЦ"

✍️Уведомление от eMudhra номер 6

28 октября 2026 г. опубликовано шестое обновление, содержащее уточнённую информацию о переходе клиентов:
🔹около 30 800 сертификатов, созданных в рамках скомпрометированных подчиненных сертификатов G3, относятся к клиентской экосистеме в США, которой был предоставлен альтернативный путь получения новых сертификатов через другой корневой сертификат - G1 RSA.
🔹одна проблема - этот корень не включен в программы доверия CA/B Forum, поэтому eMudhra запросила у разработчиков браузеров и ОС не блокировать прежний корень, чтобы обеспечить клиентам плавный переход (поздновато, Mozilla, Apple, Microsoft его уже заблокировали).
🔹ведутся переговоры с другими мировыми УЦ для обеспечения поддержки перехода. Работа с клиентами, УЦ и разработчиками ОС, браузеров будет продолжаться до завершения перехода.
🔹корень G1 будет использоваться только для поддержки указанного перехода. В рамках добровольного сворачивания международного УЦ eMudhra прекратит выдачу TLS-сертификатов под G1 после завершения перехода. Большинство клиентов уже переведены на другие сертификаты, завершение перехода планируется в ближайшие дни.

А пока участники обсуждения задаются вопросом:

Вопрос к программам root-доступа Mozilla и Chrome (а также и к другим, но меня больше интересует информация о двух активных программах root-доступа):

Уэйн сказал, что слабые ключи были обнаружены при запуске инструмента с открытым исходным кодом paranoid_crypto, «из коробки», на корпусе CCADB, и Chrome с тех пор подтвердил, что проверка его границы доверия не выявила других подобных случаев. Эти промежуточные ключи были обнаружены в CCADB примерно за 18 месяцев до того, как один из участников сообщества провел сканирование.

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

✍️"Об ЭП и УЦ"

✍️Об утверждении требований к порядку реализации функций национального УЦ

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

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

Проект приказа представляет кальку с 584 приказа Минцифры о требованиях к порядку АУЦ.

✍️"Об ЭП и УЦ"

✍️Согласно ч. 1 ст. 13¹ Правительство определяет федеральный орган власти, который будет уполномочен на осуществление функций в сфере использования сертификатов безопасности.

Если это Минцифры, то получится, что ведомство регулирует деятельность самого себя - сначала пишет требования, а потом их выполняет.

✍️Об ЭП и УЦ

Подписание автоматизированной подписью первичных документов

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

Однако, засовывание ключей физических лиц в реестры и подписание в режиме 24/7 влечет понятные проблемы. С одной стороны, это совсем небезопасно для владельца сертификата. Кто знает, что может сделать админ с использованием вашего закрытого ключа. С другой стороны, вопросы могут возникнуть и у представителей гос органов, контролирующих условия труда. Как сотрудник работает сутками и без выходных.

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

Логика простая: автоматизированная квалифицированная подпись - подпись компании. За нее кто-то ответственен: либо это генеральный директор, либо тот, кого он своим приказом назначил. Достаточно выстроить внутри компании нормальный процесс согласования и пускай финальную (формальную) подпись ставит машина. Секретарю не придется брать у ген директора носитель с ключом себе, нарушая требования безопасности, директору не надо будет отвлекаться на формальный процесс, а ключи сотрудников не будут в опасности.

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

Один из таких нормативных актов - закон о бухгалтерском учете.

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

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

О чем можно утверждать с уверенностью, так это о том, что пока Минфин проблемой не проникся.

А есть ли она? Пишите в комментариях👇

🚀 ЭДО для бизнеса

#эп #минфин #автоподписание

✍️Онлайнинспекция о самой непростой подписи

Онлайнинспекцию спросили - Является ли простая электронная подпись (ПЭП), сформированная в системе электронного документооборота Учебного центра (без участия Госуслуг), действительной для Государственной инспекции труда при подписании работником протокола проверки знаний по охране труда?

Онлайнинспекция ответила - Является, если данный порядок закреплен в локальном нормативном акте.

Вывод - Онлайнинспекция никогда не открывала 63-ФЗ и продолжает распространять мифы.
Онлайнинспекция - новый номинант премии "Профанация года"

Такая сущность, как "локальный нормативный акт" (а это не НПА в рамках ФЗ) не встречается среди установленных случаев признания электронного документа, подписанного ПЭП, собственноручной подписи.

Ранее против использования электронной подписи для инструктажей по охране труда неоднократно высказывались профсоюзы, против использования Маха они уже высказались?

✍️Об ЭП и УЦ

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

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

Статью 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-сертификатов.

✍️Об ЭП и УЦ