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

Как обеспечить безопасность очереди массовой электронной подписи?

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

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

По каким идентификаторам ставить задание на подписание в очередь?

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

На актуальной странице BTK о турецком законе № 5070 указано, что защищённая электронная подпись позволяет обнаружить последующие изменения подписанных данных. Технические ответы BTK также поясняют, что подписант должен видеть данные до подписания, а данные создания подписи не должны выводиться из средства подписи. Для очереди вывод однозначен: если после одобрения версии PDF был сформирован заново, прежнее задание нельзя продолжать — нужно новое согласование нового хеша. [1] [2]

Какие состояния очереди нужно разделять?

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

1. Принято: Исходный документ, версия, хеш и ключ идемпотентности сохраняются атомарно.
2. Предварительная проверка: Проверяются доступ к документу, формат, принадлежность, роль подписанта, выбор сертификата и соответствие политике.
3. Ожидает подтверждения: Подписант видит правильную версию документа и даёт согласие на конкретную операцию.
4. Подписание: Обработчик получает задание с кратковременной блокировкой; даже после её истечения запись идемпотентности предотвращает повторный побочный эффект.
5. Проверка подписи: Созданная подпись проходит техническую проверку в контексте подписанного документа и сертификата.
6. Архивировано: Подписанный файл, результат проверки, подтверждение временной метки и след операций хранятся в одной связанной записи.
7. Требуется разбор: Неопределённый результат проверки, постоянная ошибка или противоречие передаются уполномоченному лицу, а не преобразуются автоматически в успех.

Руководство OWASP по авторизации операций рекомендует защищать значимые данные на сервере, выполнять этапы последовательно и создавать уникальную связь авторизации для каждой операции. Поэтому потребитель очереди не должен доверять браузерному полю «подтверждено»: хеш документа, полномочия и переход состояния необходимо повторно проверять по серверной записи. [5]

Как повторять попытки без создания двойной подписи?

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

Руководство OWASP Business Logic Security рекомендует сохранять ключ идемпотентности вместе с результатом в транзакции для внешних вызовов и операций, изменяющих состояние. Если сеть оборвалась после отправки запроса сервису подписи, опасно считать, что отсутствие ответа означает отсутствие операции. Сначала следует запросить сохранённый результат или идентификатор операции провайдера по тому же ключу; повторно отправлять запрос можно только после подтверждения, что операция не состоялась. [4]

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

Когда задание действительно считается успешным?

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

ETSI EN 319 102-1 V1.4.1 определяет входные данные и результаты создания и проверки AdES и различает успешный, неуспешный и неопределённый результаты. В процессе VizyonTech обработчик не должен закрывать задание только потому, что файл записан. Он сохраняет применённые правила и результат проверки, направляя отрицательные и неопределённые результаты на разбор. [3]

RFC 3161 определяет протокол запросов и ответов временных меток, подтверждающих существование данных до определённого момента. Поэтому, если метка необходима, недостаточно записи «запрошено»: с тем же заданием нужно связать message imprint, статус ответа, возвращённый токен и результат его проверки. Несовпадение nonce или хеша документа, запоздалый ответ и отклонённый запрос не считаются успехом. [6]

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

Как при высокой нагрузке защитить систему и подписанта?

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

• Справедливое распределение мощности: Большой пакет одного клиента не должен бессрочно задерживать других; ограничения по организациям и приоритетам должны быть явными.
• Обратное давление: При достижении установленного порога очереди приём новых пакетов замедляют или переносят на плановое время.
• Видимость времени обработки: Среднего значения недостаточно. Отдельно отслеживайте самое старое ожидающее задание, время в каждом состоянии, число повторов и очередь разбора.
• Краткая блокировка, постоянная запись: Блокировка обработчика временна, но идентификатор задания, история попыток и результат должны храниться постоянно.
• Безопасное наблюдение: Журналы не должны содержать текст документов, данные доступа, PIN, закрытые ключи или ненужные персональные данные.
• Контролируемая отмена: Неподписанное задание можно отменить. Если подпись уже создана, файл сохраняют, а решение о состоянии и распространении передают уполномоченному лицу.

Какие сценарии проверить до запуска?

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

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

Как VizyonTech реализует этот процесс?

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

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

Порядок последующего исправления подписанного отчёта описан в руководстве по ревизии электронно подписанного отчёта; проверка актуального результата конечным пользователем — в руководстве по странице проверки отчёта . Чтобы спланировать безопасный пилот с учётом объёма документов и возможных сбоев вашей организации, свяжитесь с VizyonTech.