Доверенная третья сторона: как с ее появлением меняется электронная подпись / Хабр

А что не так с меткой времени и когда она должна заработать?

Подчеркну, что, в первую очередь, меня интересует правовое закрепление использования метки времени и унификация формата ЭП с меткой времени, а не сами расширенные форматы ЭП (основанные на разных международных стандартах), в которых метка времени давно уже используется.

К сожалению, законодатель (до декабря 2022) и регуляторы (до сентября 2020) не раскрывали функционал «метки времени». Отсюда пошли различные несовместимые между собой форматы ЭП. Они вроде бы и являлись усиленными квалифицированными и были выполнены на сертифицированных средствах, но обмен документами с такими ЭП с автоматическим доверием между разными информационными системами в обход системы межведомственного электронного взаимодействия (СМЭВ) был невозможен.

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

«Метка доверенного времени» (именно так указано в законе об ЭП, но я везде пишу просто «метка времени») добавлена изменениями к закону об ЭП от 27.12.2022 г. Правда этот термин упоминается однократно в ст. 2 «Основные понятия, используемые в настоящем Федеральном законе», и больше нигде не используется. Норма о метке времени вступает в силу одновременно с нормой о ДТС (с 01.01.2021 года), поскольку они связаны между собой.

Закон определяет «метку времени» так:

«Достоверная информация в электронной форме о дате и времени подписания электронного документа электронной подписью, создаваемая и проверяемая доверенной третьей стороной, удостоверяющим центром или оператором информационной системы […]».

Таким образом, метка времени может создаваться и проверяться ДТС, УЦ и оператором ИС, если она получена:

«[…]в момент подписания электронного документа электронной подписью в установленном уполномоченным федеральным органом порядке с использованием программных и (или) аппаратных средств, прошедших процедуру подтверждения соответствия требованиям, установленным в соответствии с настоящим Федеральным законом».

Почти год спустя (14 сентября 2020 г.) после появления метки времени в законе об ЭП вышел

«Об утверждении Формата электронной подписи, обязательного для реализации всеми средствами электронной подписи»

. Он, наконец-то:


Далее. В дополнение к приказу Минцифры России № 472 (где, как я написал выше, нет ни определения метки времени, ни ссылки на нее, но есть требование к размещению в составе ЭП

«времени создания ЭП»

) появилось 2 проекта правовых актов:

Очевидно, что ДТС для фиксирования

«определенного момента времени»

также нужна метка времени или сертификат ЭП, срок действия которого еще не истек. Метка времени должна быть одновременно и

«доверенной»

, и

«правильной»

(ДТС должна ее понимать). И, скорее всего, идеальный алгоритм проверки электронных документов с ЭП, в которых реализована метка времени, в ДТС будет следующем:

  1. Создание электронного документа с ЭП, где ЭП реализована средствами и в формате с поддержкой метки времени (приказ Минцифры России №472).
  2. Получение метки времени в ДТС или где-то еще (в УЦ или у оператора ИС).
  3. Встраивание метки времени (выданной «аккредитованным» сервисом – ДТС/УЦ/оператор ИС) в документ с ЭП.


И только если все эти этапы будут пройдены, ДТС сможет

«подтвердить действительность электронной подписи»

со всеми «плюшками и расширенными отчетами». Что из этого следует? Все, кто пожелает использовать ДТС для проверки документов с ЭП после истечения срока действия сертификата ЭП, должны иметь:

Нормативно-правовые акты регуляторов еще не приняты, тем не менее пазл с меткой времен начинает сходиться:

приказ министерства цифрового развития, связи и массовых коммуникаций рф от 06.11.2020 n 580 "об утверждении порядка создания и проверки метки доверенного времени" | гарант

УТВЕРЖДЕН
приказом Министерства цифрового
развития, связи и массовых
коммуникаций
Российской Федерации
от 06.11.2020 г. N 580

1. Настоящий Порядок определяет правила создания и проверки метки доверенного времени.

2. Метка доверенного времени создается доверенной третьей стороной, удостоверяющим центром или оператором информационной системы (далее — служба меток доверенного времени) с использованием программных и (или) аппаратных средств, прошедших процедуру подтверждения соответствия требованиям, установленным в соответствии с пунктом 19 статьи 2 Федерального закона от 6 апреля 2022 г. N 63-ФЗ «Об электронной подписи» (далее — Федеральный закон «Об электронной подписи»).

3. Создание метки доверенного времени осуществляется службой меток доверенного времени по запросу участников электронного взаимодействия путем подписания электронной подписью службы меток доверенного времени текущего достоверного значения времени в соответствии с требованиями к структуре метки доверенного времени.

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

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

6. Службы меток доверенного времени, создаваемые доверенной третьей стороной или удостоверяющим центром, при создании метки доверенного времени должны получать информацию о точном значении времени с учетом часового пояса и календарной дате от технических средств передачи эталонных сигналов времени и частоты, а также информацию о точном значении времени и календарной дате (далее — технические средства передачи эталонных сигналов времени), функционирующих в соответствии с Положением о Государственной службе времени, частоты и определения параметров вращения Земли, утвержденным постановлением Правительства Российской Федерации от 23 марта 2001 г. N 225 (Собрание законодательства Российской Федерации, 2001, N 14, ст. 1361; 2022, N 49, ст. 7600). В метку времени заносятся значения о точном значении времени в соответствии со всемирным координированным временем (далее — UTC).

7. Службы меток доверенного времени, создаваемые операторами информационных систем, получают информацию о дате и времени от технических средств передачи эталонных сигналов времени или от службы меток доверенного времени, указанных в пункте 6 настоящего Порядка, посредством информационно-телекоммуникационных сетей при условии обеспечения целостности передаваемой информации с использованием средств криптографической защиты информации, имеющих подтверждение соответствия требованиям, установленным согласно части 5 статьи 8 Федерального закона «Об электронной подписи».

9. Создание метки доверенного времени осуществляется в соответствии со следующими требованиями:

1) Электронный документ должен содержать доказательства, что объекты данных существовали до определенного момента времени (далее — протокол штампов времени). В целях обеспечения указанных доказательств осуществляется взаимодействие службы штампов времени (TSA) и запрашивающей стороны посредством формирования запроса к TSA и проверки ее ответа.

2) Служба штампов времени при создании метки времени должна:

использовать значение UTC;

включать достоверное значение времени в каждый штамп;

включать уникальное целое число в каждый новый штамп;

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

включать в каждый штамп времени идентификатор политики безопасности (регламента), согласно которой он был создан;

ставить штамп времени только для хэш-значения, вычисленного с использованием устойчивой однонаправленной хэш-функции;

проверять соответствие длины хэш-значения длине, определенной в алгоритме хэширования, идентификатор которого указан в запросе к TSA;

не подвергать хэш-значение, которому присвоен штамп, какой-либо проверке (кроме проверки его длины, как это указано в предыдущем пункте);

не включать в штампы времени какую-либо информацию, идентифицирующую запрашивающую сторону;

подписывать каждый штамп времени ключом, сгенерированным специально для этой цели;

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

3) В первом сообщении обмена в рамках данного протокола запрашивающая сторона посылает в службу штампов времени запрос на штамп времени (далее — TimeStampReq). Во втором сообщении служба штампов времени отвечает запрашивающей стороне сообщением (далее — TimeStampResp).

При получении TimeStampResp, содержащего штамп времени (далее — TimeStampToken), запрашивающая сторона должна проверить ответ на ошибки о состоянии и, если их нет, проверить различные поля в TimeStampToken, а также действительность электронной подписи, которой подписан TimeStampToken, и убедиться, что данные с проставленным штампом времени соответствуют отправленным данным. Запрашивающая сторона должна проверить, что TimeStampToken содержит правильный идентификатор сертификата службы штампов времени (ESSCertIDv2), правильное хэш-значение (hashedMessage) и правильный идентификатор алгоритма хэширования (hashAlgorithm) в поле messagelmprint.

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

4) Запрос к службе штампов времени должен представлять собой структуру типа TimeStampReq:

TimeStampReq ::= SEQUENCE {
version             INTEGER { v1(1)},
messageImprint            MessageImprint,

— OID алгоритма хэширования и хэш-значение от данных, для которых

— требуется штамп времени

reqPolicy       TSAPolicyId        OPTIONAL,
nonce          INTEGER             OPTIONAL,
certReq        BOOLEAN             DEFAULT FALSE,
extensions [0] IMPLICIT Extensions OPTIONAL }

Поля структуры TimeStampReq должны быть заполнены следующим образом:

version

поле version описывает версию запроса штампа времени. Поле version должно иметь значение 1;

messagelmprint

поле messagelmprint должно представлять собой структуру типа Messagelmprint. Структура Messagelmprint должна выглядеть следующим образом:

Messagelmprint ::= SEQUENCE {

hashAlgorithm

Algorithmldentifier,

hashedMessage

OCTET STRING}

Служба штампов времени отказывает в выдаче штампа времени, возвращая сообщение со значением badAlg в поле PKIFailurelnfo, если хэш-алгоритм не распознан.

Поле hashedMessage структуры Messagelmprint должно содержать хэш-значение от данных, для которых требуется штамп времени. Служба штампов времени проверяет совпадение длины хэш-значения с длиной, установленной примененным хэш-алгоритмом, идентификатор которого указан в поле Algorithmldentifier.

По результатам такой проверки, в случае несовпадения указанных длин, служба штампов времени отказывает в выдаче штампа времени, возвращая сообщение со значением badAlg в поле badDataFormat;

reqPolicy

поле reqPolicy (при наличии) имеет тип TSAPolicyld и обозначает регламент службы штампов времени, согласно которому следует выдать TimeStampToken. TSAPolicyld определяется следующим образом:

TSAPolicyld ::= OBJECT IDENTIFIER;

nonce

поле nonce (при наличии) имеет тип INTEGER и позволяет клиенту проверить актуальность ответа, когда локальное время недоступно. Значение поля nonce должно представлять собой уникальное 64-битное целое число, сгенерированное клиентом случайным образом. При отсутствии значения nonce в ответе, ответ клиентом должен отклонен;

certReq

поле certReq (при наличии) имеет тип BOOLEAN. Если поле certReq присутствует и имеет значение «true», сертификат ключа проверки подписи службы штампов времени должен быть помещен в поле certificates в структуре SignedData.

Если поле certReq отсутствует и имеет значение «false», поле certificates в структуре SignedData в ответе службы штампов времени не указывается;

extensions

поле extensions (расширения) имеет тип Extensions и позволяет добавить дополнительную информацию в запрос.

Служба штампов времени отказывает в выдаче штампа времени, возвращая сообщение об ошибке (unacceptedExtension), если поле Extensions не распознано.

7) Тип PKIStatus структуры PKIStatusInfo должен представлять собой числовое значение, определяющее статус службы штампов времени. Если значение равно 0 или 1, штамп времени TimeStampToken должен присутствовать. Если присутствует иное значение (кроме 0 или 1), штамп времени TimeStampToken не должен присутствовать.

Служба штампов времени должна поддерживать только следующие возможные статусы:

PKIStatus ::= INTEGER {

granted

— когда PKIStatus содержит значение 0, TimeStampToken

— присутствует, как и запрашивалось.

grantedWithMods

— когда PKIStatus содержит значение 1, TimeStampToken

— присутствует с изменениями.

rejection

— штамп времени не получен, причина указана в информационном сообщении

waiting

— запрос штампа времени еще не обработан, дополнительная информация ожидается позже,

revocation Warning

— это сообщение предупреждает о том, что аннулирование неизбежно revocationNotification

— уведомление о том, что аннулирование имело место.

8) Тип PKIFreeText структуры PKIStatusInfo должен представлять собой объяснение причины отклонения запроса штампа времени в виде текста.

11) Поле encapContentlnfo структуры SignedData должно представлять собой структуру типа EncapsulatedContentlnfo. В него необходимо включать следующие значения:

— в поле eContentType — следующий объектный идентификатор штампа времени:

id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)

us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4};

— в поле eContent — штамп времени в виде строки октетов (OCTET STRING). Значение поля eContent должно быть результатом DER-кодирования структуры TSTInfo.

Структура TSTInfo содержит штамп времени и должна быть представлена следующим образом:

TSTInfo ::= SEQUENCE {
version                 INTEGER { v1(1)},
policy                  TSAPolicyId,
messageImprint               MessageImprint,
-- должно содержать то же значение, что и поле TimeStampReq
serialNumber            INTEGER,
-- сторона, запрашивающая штамп времени, должна принимать целые числа
длиной до 160 бит.
genTime                GeneralizedTime,
accuracy               Accuracy                   OPTIONAL,
ordering               BOOLEAN                    DEFAULT FALSE,
nonce                  INTEGER                    OPTIONAL,
-- должно присутствовать, если аналогичное поле имеется в
-- TimeStampReq. В этом случае поле должно иметь то же значение,
tsa                [0] GeneralName                OPTIONAL,
extensions            [1] IMPLICIT Extensions OPTIONAL}

12) Поля структуры TSTInfo должны быть заполнены в соответствии со следующими требованиями:

version

поле version имеет тип INTEGER и описывает версию запроса штампа времени. Поле version должно иметь значение 1.

Запрашивающая сторона должна распознавать штампы времени версии 1;

Policy

поле policy имеет тип TSAPolicyId и должно обозначать политику безопасности (регламент службы штампов времени, в рамках которой был дан ответ). Если в TimeStampReq присутствует поле reqPolicy, оно должно иметь то же значение, иначе должна быть возвращена ошибка unacceptedPolicy.

Поле policy содержит:

— условия использования штампа времени;

— информацию о доступности журнала штампов времени для проверки подлинности штампа времени;

messagelmprint

поле messagelmprint имеет тип MessageImprint и должно иметь то же значение, что и поле messagelmprint в TimeStampReq;

serialNumber

поле serialNumber имеет тип INTEGER и является уникальным целым числом, присвоенным данной службой штампов времени каждому штампу времени TimeStampToken. Служба штампов времени обеспечивает уникальность этого числа в том числе в случаях сбоя в работе штампов времени;

genTime

поле genTime имеет тип GeneralizedTime и обозначает время создания штампа времени соответствующей службой, должно быть выражено в UTC.

Значения GeneralizedTime должны включать секунды. Следует использовать GeneralizedTime с точностью до секунд. В отличие от ограничений, поле GeneralizedTime может содержать и доли секунд.

Используется следующий синтаксис:

ГГГГММДДччммсс[.s…]Z.

Предусмотрены следующие ограничения к DER-кодированию: 1) результат кодирования должен оканчиваться на Z. При этом десятичный знак, если он присутствует, представляется в виде точки.

2) полночь представляется в следующей форме: ГГГГММДД000000Z, где ГГГГММДД обозначает наступивший день;

accuracy

поле accuracy должно представлять собой структуру типа Accuracy и обозначает отклонение времени от времени, значение которого содержится в поле GeneralizedTime. Структура Accuracy выглядит следующим образом:

Accuracy ::= SEQUENCE {

seconds

millis [0]

INTEGER

INTEGER (1..999)

OPTIONAL,

OPTIONAL,

micros [1] INTEGER (1..999) OPTIONAL

}

Если поля seconds, millis или micros отсутствуют, то их значение должно быть равным 0.

Добавлением значения точности поле accuracy к GeneralizedTime вычисляется верхний предел значения времени в штампе времени, созданном службой штампов времени. Вычитанием точности из GeneralizedTime вычисляется нижний предел значения времени в штампе времени, созданном службой штампов времени. Точность представляется в секундах, миллисекундах и микросекундах в виде целого числа;

ordering

поле ordering (упорядочивание) имеет тип BOOLEAN и используется для обозначения работы службы штампов времени в режиме, когда время создания двух штампов времени не может совпадать.

Значение «true» поля ordering означает необходимость упорядочивания штампов времени, последовательно выдаваемых службой штампов времени, по полю genTime вне зависимости от значения поля accuracy.

Отсутствие поля ordering или его значение «false» означают отсутствие необходимости упорядочивания штампов времени, последовательно выданных службой штампов времени по полю genTime. В этом случае упорядочивание штампов времени осуществляется только тогда, когда разница между genTime первого штампа и genTime второго штампа больше суммы значений точности genTime для каждого штампа;

nonce

поле nonce (при наличии) имеет тип INTEGER и позволяет клиенту проверить актуальность значения штампа времени, когда локальное время недоступно. Значение поля nonce должно представлять собой уникальное 64-битное целое число, сгенерированное клиентом случайным образом. При отсутствии значения nonce в ответе, ответ клиентом должен отклонен;

tsa

поле tsa имеет тип GeneralName и содержит название службы штампов времени. Значение поля tsa должно соответствовать одному из имен субъектов, включенных в сертификат, используемый для проверки подписи штампа времени;

extensions

поле extensions (расширения) имеет тип Extensions и предназначено для дополнительной информации, помещаемой в запрос.

Вместо p.s. будущее рынка уц и дтс


И напоследок хотелось бы написать про возможное схлопывание рынка УЦ.

Этим же законом изменен срок аккредитации УЦ с 5 до 3 лет. Аналогичный срок – 3 года – определен для аккредитации ДТС. При этом значительно возросли требования к УЦ. Теперь необходимо:

По оценкам экспертов, увеличение требований к минимальному капиталу приведет к сокращению количества УЦ более чем в 10 раз уже в 2021 (примерно с 450 до 20-40). По аналогии не ожидается и появления значительного количества ДТС, которые, скорее всего, будут созданы при ключевых УЦ (Центробанке, налоговой службе, казначействе), чтобы обслуживать их внутренние потребности. Возможно, они появятся и при нескольких крупных «выживших» коммерческих аккредитованных УЦ.

Пользователям или разработчикам небольших прикладных систем (тех, кто хотел бы внедрить документооборот с облачной ЭП), конечно же, интереснее работать с независимыми от удостоверяющих центров ДТС, а также взаимодействовать со всеми или большинством крупных УЦ.

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

Как изменит ситуацию появление доверенной третьей стороны?

Мы добрались до самого главного. В дополнениях к 63-ФЗ «Об электронной подписи» от 27.12.2022 вместе с целым рядом изменений, в том числе юридическим признанием облачной ЭП, появляется институт доверенной третьей стороны (статья 18.1). Это новый вид организации, которая призвана обеспечить доверие при обмене электронными документами с ЭП.

Законом определяется перечень услуг, которые ДТС будут оказывать участникам электронного взаимодействия:

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

Иными словами, появляется аккредитованная организация (а не просто набор сервисов при аккредитованном УЦ), предоставляющая такой необходимый набор услуг:

По сути это все те задачи и соответствующие «аккредитованные» решения по проверке ЭП во времени, которые призваны обеспечить внешний доверенный электронный документооборот с ЭП и минимум среднесрочное хранение документов.

Какие неочевидные проблемы «краткосрочности» обычной электронной подписи существуют сегодня?

Я работаю в подразделении, которое занимается прикладной интеграцией. Так сложилось, что нам не приходилось внедрять «штатную» ЭП для документооборота «из коробки» или внедрять готовые клиентские приложения для работы с ЭП. Почти всегда задачи внедрения сводились к встраиванию ЭП (включая разного рода автоматизации по обслуживанию жизненного цикла сертификатов, ключей и их носителей) в существующие и совсем не коробочные документообороты или в информационные системы, в том числе с длительным хранением документов.

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

А вот потребность в дальнейшем среднесрочном и долговременном хранение документов с ЭП, проверка ЭП в документообороте (в том числе автоматизированная) всегда в конечном итоге влияли на архитектуру решения. Усложнялись форматы ЭП, начиная от CAdES-T и XAdES-T (с метками времени) и заканчивая их расширенными и специальными «A»-версиями (Archival).

Так как осуществить проверку ЭП документа, хотя бы лет так через 10-15? (Опустим такую подробность, что, скорее всего, спустя столько лет не будет сертифицированных средств криптографической защиты информации (СКЗИ), поддерживающих нужные криптографические алгоритмы и нужные форматы, а необходимые средства просмотра электронных документов не будут запускаться на текущих ОС.)

Обратимся к закону об ЭП (от 06.04.2022 № 63-ФЗ). Какие условия признания (проверки) квалифицированной ЭП содержатся в статье 11 «Признание квалифицированной электронной подписи» (приведу только пункт 2 статьи, потому что именно он влияет на проверку документов с ЭП во времени):

Квалифицированная электронная подпись признается действительной […] при одновременном соблюдении следующих условий:

2) квалифицированный сертификат действителен на момент подписания электронного документа (при наличии достоверной информации о моменте подписания электронного документа) или на день проверки действительности указанного сертификата, если момент подписания электронного документа не определен.

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

«достоверно»

, – и это обязательное условие.

Законодатель не предложил и даже не намекнул на способы подтверждения достоверности информации о моменте подписания электронного документа. Впрочем, это нормально. Требования к процедуре должны раскрывать ответственные регуляторы. И спустя 9 лет, после того, как в конце 2022 года вышли изменения к закону об ЭП, Минцифры России и ФСБ России (в части работы с меткой времени, но об этом дальше), наконец-то, разработали проекты приказов.

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

Какие решения для обхода «краткосрочности» базовой эп обычно используют?

Единый стандарт для формата ЭП с меткой времени в процессе разработки. Самым очевидным, с точки зрения среднесрочного (5-10 лет) и долгосрочного хранения документов с ЭП, является реализация квалифицированной ЭП в одном из расширенных форматов (на усмотрение владельца ИС) как минимум:

К менее очевидным и менее распространенным решениям, обеспечивающим проверку ЭП документа через N-лет, относится создание доверенных сред хранения. В такую среду документ с ЭП помещается чаще всего еще во время действия выданного пользователю квалифицированного сертификата ЭП (например, сразу после подписания) с максимальным набором метаданных.

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

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

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

Сложный функционал проверки полномочий в дтс

Вернемся к ДТС и функционалу проверок правильности применения сертификатов ЭП и полномочий. В соответствии с изменениями в законе об ЭП от 27.12.2022 ДТС выступает в том числе в роли «авторизационного» центра, выполняющего:


При этом первый пункт также должен включать проверку правильности применения сертификата квалифицированной электронной подписи (КЭП):

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

«подписан КЭП уполномоченного в установленном порядке на принятие соответствующих решений должностного лица соответствующего государственного органа или органа местного самоуправления»

. Сами же полномочия должны быть

«определены на основании классификатора полномочий, который уполномоченный федеральный орган формирует, актуализирует»

. В соответствии со статьями 17.2 и 17.3 закона об ЭП необходимо также проверить наличие и содержимое электронной доверенности, поскольку именно она уполномочивает сторону на те или иные правоотношения. Таким образом, при проверке полномочий ДТС должна также проверять:

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

«Авторизационные» операции при использовании сертификатов ЭП, с одной стороны, унифицировались. Специфицированные OID-ы в сертификатах ЭП теперь должны игнорироваться, а схемы авторизаций по принципу свой/чужой OID с 01.06.2020 вне закона. С другой стороны, разграничение полномочий и правила применения сертификатов ЭП трансформировались в более сложные процессы, которые еще должны быть отрегулированы к 01.01.2022.

«Белые пятна» в проверке полномочий

В

проекте приказа ФСБ России«Об утверждении Требований к средствам доверенной третьей стороны, включая требования к используемым доверенной третьей стороной средствам электронной подписи»

разъяснений по «авторизационным» функциям ДТС так и не последовало. Например, пункт 2.3 проекта требований гласит:

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

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

Сам же проект приказа определяет требования к набору компонентов средств ДТС и к функционированию компонентов средств ДТС. Большинство требований технические и организационно-технические и касаются информационной безопасности, что также несомненно очень важно, потому что позволит начать создавать «аккредитованные» ДТС.

Выводы: уже куда-то бежать или ждать?

«Легализация» хранения и дистанционного использования средствами УЦ облачной ЭП с 01.01.2021 должна запустить новый виток ее развития. Это касается увеличения количества внедряемых услуг на базе ЭП (особенно в наше ковидное время) и удобных сервисов работы с ЭП для мобильных клиентов и клиентов на рабочих местах, которые, в свою очередь, будут нуждаться во внешних обслуживающих сервисах проверки ЭП (на базе ДТС).

Скорее всего, либо под новый год, либо сразу же после праздников упомянутые мною приказы примут. Потом разработчикам СКЗИ потребуется еще месяца 3-4 для корректировки клиентского ПО и библиотек под новый формат ЭП с меткой времени и сервисы служб меток доверенного времени. К слову, последние у ключевых разработчиков СКЗИ уже реализованы и эксплуатируются как TSP-службы штампов времени.

Далее потребуется еще некоторое время на разработку функционала ДТС, явно не завязанного на какие-либо форматы, но необходимого по закону об ЭП:

С учетом всех необходимых доработок ПО, а также организационных процедур на аккредитацию, ждать появления первых ДТС раньше лета 2021 года, думаю, не стоит. Может быть, ФНС и ключевой разработчик СКЗИ выпустят что-то раньше в качестве тестовой версии ДТС.

Услуги ДТС, очевидно, не будут бесплатными для всех, и все затраты прямо или косвенно лягут на участников электронного взаимодействия.

Появление на рынке ДТС должно в итоге способствовать появлению полезных сервисов (в первую очередь, в виде API для встраивания), которые смогут обеспечивать:

Эти сервисы можно будет встраивать в информационные системы, например:

Сервисы найдут применение и в мобильных клиентах разных информационных систем, в том числе для работы с облачной ЭП. Второй вариант соответствует недавно озвученному предложению Максута Шадаева, министра цифрового развития, связи и массовых коммуникаций России:

«Нам кажется, основной сценарий — использование электронной подписи на смартфоне. Такое техническое решение мы с коллегами согласовали, такая возможность есть».

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

Итого: заявленные изменения в законе об ЭП и предложенный функционал ДТС действительно интересны, долгожданны и обязательно будут востребованы. Метка времени (которая вводится одновременно с ДТС с 01.01.2021) «автоматически» решит проблемы среднесрочного хранения документов.

ДТС и унифицированный формат ЭП с меткой времени позволят осуществлять доверенный оборот документов с ЭП старше 1 года и проверять их после отчуждения из системы. Конечно, многое зависит от реализации, и в том числе от регламентов и приказов Минцифры России и приказов ФСБ России, которые в идеале должны привести к единому знаменателю технические решения по всем ДТС.

Оцените статью
ЭЦП64
Добавить комментарий