Разграничение доступа к ЭП: как не передавать токены из рук в руки

Квалифицированная электронная подпись (КЭП) нужна для подписания электронной отчётности, актов, договоров и других документов. Закрытый ключ для её создания хранится на токене — USB-носителе. Чтобы не задерживать документы, токен передают уполномоченным сотрудникам компании. В результате, теряется контроль над тем, кто от лица руководителя подписывает эти документы и на каком основании. Разберём, как организовать доступ к ЭП без передачи токенов: когда сотруднику нужны собственная КЭП и МЧД, а когда документ должен подписывать владелец ключа.

Передавать токен вместе с PIN-кодом другому сотруднику для самостоятельного подписания нельзя. Владелец усиленной электронной подписи обязан сохранять конфиденциальность ключа, сообщать о её нарушении и не использовать ключ, если есть основания считать его скомпрометированным. Эти обязанности закреплены в Статье 10 Федерального закона № 63-ФЗ «Об электронной подписи».

Если токен лежит в общем ящике, а PIN-код знают несколько человек, владелец уже не контролирует ключ. Запрет передачи КЭП в регламенте сам по себе проблему не решает: нужны персональные учётные записи, технические ограничения и журнал событий.

Сценарий 1. Токен хранится в бухгалтерии. Им по очереди пользуются несколько сотрудников. Если в отчётности обнаружат ошибку или спорную операцию, по одной записи о подписании нельзя понять, кто держал токен и вводил PIN-код.

Сценарий 2. Ключ передают внешнему бухгалтеру. Компания не контролирует его компьютер, резервные копии и круг людей с доступом. После завершения договора у подрядчика может остаться копия ключа, сохранённый PIN-код или удалённое подключение.

Сценарий 3. Токен передают на время отпуска. После возвращения руководителя доступ часто не пересматривают. Корпоративную учётную запись можно заблокировать, но человек по-прежнему знает PIN-код. Это мешает расследовать спорные подписания.
Хранение токена в общем доступе и передача PIN-кода повышают риск компрометации. Компания должна видеть не только итоговую подпись, но и всю цепочку: кто подготовил документ, кто проверил полномочия, кто запросил подписание, кто подтвердил операцию и каким ключом она выполнена.

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

Владелец ключа контролирует токен и PIN-код. Он подписывает документ лично или подтверждает запрос, а также видит историю операций со своим ключом.

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

ИТ-администратор настраивает оборудование, учётные записи и интеграции. Техническая роль не даёт права подписывать документы и не требует знания PIN-кодов владельцев.

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

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

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

USB-over-IP даёт удалённому компьютеру доступ к USB-порту и подключённому токену через сеть. Это решает задачу подключения, но само по себе не проверяет полномочия пользователя. В журнале видно подключение к порту, но не документ, инициатора запроса и согласующего.

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

При выборе между USB-over-IP, JaCarta Management System, Рутокен KeyBox и другими решениями важно сравнивать доступные функции: можно ли отправить запрос без прямого доступа к ключу, какие события попадают в журнал, отделено ли администрирование от подписания и сохраняется ли история после увольнения пользователя.

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

«Ключник ГОСТ» — аппаратно-программная платформа РНДСОФТ для централизованной работы с токенами электронной подписи. Токены подключают к устройству, которое размещают в защищённом месте, серверной или сейфе. Ключ не переносят на рабочее место сотрудника и не экспортируют из устройства.

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