Как вести журнал операций с КЭП и расследовать спорные подписания
В компании возникает спор: документ подписан КЭП, а владелец КЭП говорит, что не подтверждал операцию. Администратор открывает логи: токен был подключён, пользователь работал в системе, ошибок не видно. Этих данных может не хватить, чтобы понять, кто отправил запрос на подписание, каким ключом подписали документ и чем завершилась операция.
Чтобы разобрать такие ситуации, нужен журнал операций с электронной подписью. В статье покажем, какие события должны попадать в журнал, как он помогает при спорном подписании, ИБ-инциденте или конфликте с контрагентом. В конце — чек-лист «10 событий для журнала операций с ЭП».
Чего может не хватать при спорном подписании ЭП
Документ подписан, а владелец КЭП говорит, что не подтверждал это действие. В таких ситуациях в компании начинают с системных логов, а затем проверяют всё, что может помочь: журнал учёта КЭП, историю подключения токена, события в ЭДО.
Журнал учёта КЭП, системные логи и журнал использования токена показывают отдельные факты: сертификат действовал, пользователь входил в систему, токен был подключён. Для полноценного расследования инцидента с ЭП этого будет мало. Необходимо разобраться, кто отправил документ на подпись, подтвердил ли владелец КЭП это действие и успешно ли прошла операция.
Без журнала операций с ЭП компании приходится разбирать спор по неполным данным:
- Вход пользователя в систему не всегда удаётся связать с конкретным подписанием.
- Приходится отдельно выяснять, кто отправил документ на подпись.
- Сложнее проверить, каким ключом подписали конкретный документ.
- Можно пропустить изменение прав доступа перед спорным подписанием ЭП.
- Сложнее обнаружить попытки доступа без прав или ошибки при подписании.
- Материалы для ИБ, руководства или юристов приходится собирать вручную из нескольких систем.
- Расследование больше зависит от переписки и объяснений участников, чем от журнала операций.
Что должен фиксировать журнал операций с ЭП
По журналу операций с ЭП должно быть понятно, что произошло при подписании: когда подключали токен, кто отправил документ, чей ключ использовали и какой результат вернула система.
Для расследования важна запись, которая связывает операцию с конкретным документом: кто отправил его на подпись, подтвердил ли владелец КЭП операцию и была ли она успешно выполнена. По таким полям проще отделить штатное действие от ошибки, злоупотребления доступом или признаков компрометации ключа.
Как организовать аудит: архитектура журналирования КЭП в Ключник ГОСТ
Для расследования спорных подписаний важен журнал, в котором запись появляется в момент действия с КЭП. В нём видно, кто отправил запрос на подписание, какой ключ использовали, подтвердил ли владелец КЭП операцию и какой результат зафиксировала система.
В Ключник ГОСТ, аппаратно-программном решении RNDSOFT для управления КЭП, это устроено так: токены с КЭП подключают к устройству, которое устанавливают в защищённом месте, серверной или сейфе. Ключ не покидает устройство, его не экспортируют и не переносят на рабочее место сотрудника.
Запросы на подписание идут из рабочих систем, ключи остаются на защищённом устройстве, а операции фиксируются в журнале
На практике подписание проходит так:
- Пользователь отправляет запрос на подписание из 1С, ЭДО, ЭТП или другой рабочей системы.
- Владелец ЭП подтверждает действие с помощью двухфакторной аутентификации, если она включена.
- Ключник ГОСТ выполняет подписание и записывает результат в журнал.
В журнале операций фиксируются действия с ЭП: кто и когда подписал документ, какой ключ использовали и какой результат зафиксировала система. При расследовании администратор или ИБ-специалист проверяет время операции, использованный ключ, инициатора запроса, IP-адрес и события до и после подписания. Так разбор опирается на журнал, а не на версии участников.
Сценарий расследования: пошаговый разбор инцидента
Расследование начинается с журнала операций с ЭП.
- Зафиксировать спорный документ и время подписания. Взять данные из системы, где был подписан документ: название, номер или другой идентификатор, если он есть. Также уточнить дату и время операции.
- Найти операцию в журнале ЭП: по подписанному документу можно понять какой ключ использовали, кто отправил запрос на подписание.
- Проверить события до и после подписания: подключение и отключение токена, изменения прав доступа и действия администратора.
- Зафиксировать выводы и сохранить выгрузки из журнала, сведения о документе, времени операции, ключе, пользователях и действиях администратора. Если спор выходит за пределы компании, эти материалы передают юристам вместе с другими документами по делу.
Что логировать при работе внешней бухгалтерии и закупщиков
Внешний бухгалтер готовит отчётность, акты, счета-фактуры и первичные документы в 1С, ЭДО или другом рабочем сервисе. Сертификат КЭП выдан руководителю компании-клиента или другому уполномоченному лицу, поэтому право подтверждать подписание остаётся у владельца КЭП. Закрытый ключ нельзя передавать бухгалтеру или переносить на его рабочее место.
В журнале операций с ЭП необходимо фиксировать:
- Факт подписания документа.
- Инициатора запроса на подписание.
- Владельца КЭП.
- Использованный ключ.
- Подтверждение запроса со стороны владельца КЭП.
- Статус операции.
Эти данные показывают, кто отправил документ на подписание, какой ключ использовали и подтвердил ли владелец КЭП операцию. Если подписание позже оспорят, компания сможет проверить запись в журнале, а не собирать ход операции по переписке, объяснениям сотрудников и логам из разных систем.
Закупщики работают с заявками, договорами и документами на электронных торговых площадках (ЭТП), где операция может проходить в сжатые сроки. Доступ к КЭП могут временно изменить на время отпуска, замены сотрудника или срочной закупочной процедуры. Если это не учтено, сложнее понять, была ли спорная операция штатным замещением, ошибкой в правах или злоупотреблением доступом.
В журнале операций с ЭП необходимо фиксировать: источник запроса, ЭТП или другая система, инициатор запроса и его роль, какая роль была у пользователя, использованный ключ, время операции, статус операции: выполнена, отклонена или завершилась ошибкой, изменения прав доступа к КЭП перед подписанием, попытки доступа без прав.
Как перейти от разрозненных логов к системному журналу операций
Переход к системному журналу не требует полной перестройки процесса. Сначала разберите, где компания использует КЭП, какие записи уже остаются в рабочих системах и где при споре не хватит данных.
- Описать роли. Укажите владельцев КЭП, инициаторов запросов, администраторов и роли с доступом к журналу. Так проще разделить подготовку документа, подтверждение операции, управление доступами и просмотр записей.
- Проверить текущие источники данных. Посмотрите, что уже есть в системных логах, журнале учёта сертификатов, событиях ЭДО и истории подключения токенов: вход пользователя, подключение носителя, статус сертификата, ошибки доступа.
- Найти разрывы. Проверьте, можно ли по текущим данным разобрать подписание. Например, токен подключён, но нет данных о документе; пользователь найден, но непонятно, какой ключ применили; сертификат действовал, но результата операции нет.
- Определить минимальный набор событий. В журнале необходимы записи о запросе на подписание, инициаторе операции, владельце КЭП, использованном ключе, результате операции, изменениях прав доступа. Если система фиксирует документ, его идентификатор, эти данные тоже помогают при расследовании инцидента с ЭП.
- Настроить права доступа к КЭП и журналу. Роли настраивают так, чтобы пользователь мог отправлять разрешённые запросы на подписание, администратор управлял доступами и видел журнал, но не получал доступа к закрытым ключам. Если владелец КЭП подтверждает подписание, это событие тоже должно попадать в журнал.
- Проверить журнал на спорном сценарии. Возьмите типовую спорную ситуацию: подписание отчёта, заявки на ЭТП или договора. В журнале должны сходиться основные данные: кто отправил запрос, каким ключом подписали документ, какой статус зафиксировала система и менялись ли права доступа перед операцией.
- Определить порядок хранения и выгрузки записей. Заранее определите, кто просматривает журнал, кто выгружает записи, где они хранятся и как передаются ИБ, руководству или юристам.
После такой проверки видно, где текущих логов достаточно, а где остаются разрывы. Системный журнал операций с ЭП связывает данные, которые нужны для разбора: запрос на подписание, использованный ключ, участника операции, статус и изменения доступа.
От ручной сверки к контролю подписаний
Журнал операций с ЭП помогает навести порядок в той части работы с подписью, которая остаётся на стороне компании: кто работает с подписью, какие права действуют, какие документы подписывают и какие события сохраняются для разбора. Чем раньше такой журнал встроен в процесс, тем меньше компания зависит от ручной сверки логов и объяснений участников после конфликта.
FAQ
Инициатор запроса, время операции, использованный ключ. Отдельно фиксируется подключение и отключение токена.
Журнал учёта КЭП показывает, кому выдана КЭП, срок действия и статус сертификата. Журнал операций показывает действия при подписании: кто отправил запрос, каким ключом подписали документ и чем завершилась операция.
Зафиксировать документ и время подписания, затем найти операцию в журнале ЭП. В записи проверить ключ, владельца КЭП, инициатора запроса, результат операции, IP-адрес и события доступа до и после подписания. Если процесс предусматривает подтверждение владельцем КЭП, проверить, подтвердил он запрос или отклонил его.
Журнал сам по себе не доказывает компрометацию, но помогает увидеть признаки: изменение прав перед спорной операцией, использование ключа вне обычного сценария, запрос с нетипичного IP-адреса. Вывод можно сделать на основе комплекта материалов: журналу операций, системным логам, сведениям о доступах и данным о документе.
Нужны журнал операций с ЭП, системные логи, журнал учёта сертификатов, история подключения токена, события ЭДО или другой системы, где прошло подписание. Ключевая запись связывает операцию с ключом, инициатором, временем, IP-адресом и результатом. Данные о документе сопоставляют с журналом, если они доступны.
Да, как часть доказательной базы. Для внутреннего расследования или суда обычно собирают выгрузку журнала, данные о документе, сведения о ключе, правах доступа, пользователях, IP-адресах и действиях администратора.