Мобильное приложение для электронной подписи: где ломается процесс
Подписание документов с телефона ломается не на кнопке «Подписать», а на стыке сессии, ключа и канала связи. Клиент нажимает подтверждение, приложение уходит в фон, а через минуту возвращается к экрану логина — и подпись, которую он уже считал поставленной, не существует ни на сервере, ни в контейнере. Второй по частоте сбой — криптоконтейнер на устройстве: ключ привязан к хранилищу конкретной платформы, и после обновления системы, смены устройства или переустановки приложения он становится недоступен, а вместе с ним теряется доступ к подписанию.
Мобильная электронная подпись чувствительна к тому, где именно живёт ключ. Если он в защищённом хранилище платформы — приложение обязано корректно отработать отзыв доступа, блокировку по биометрии и смену владельца устройства. Если ключ вынесен на внешний носитель или в облако — добавляется сетевой вызов, и подпись офлайн перестаёт работать вовсе. Отдельная категория отказов — несовместимость с хранилищем ключей: криптопровайдер, встроенный в приложение, не видит сертификат, потому что тот лежит в системном хранилище под другим профилем.
Слабая связь добивает процесс там, где всё остальное настроено. Документ подписывается за секунды, но отправка результата на сервер проверки может занять минуты, и без локальной очереди с повторной отправкой пользователь видит «ошибка» на полностью валидной подписи. Хуже, когда приложение блокирует интерфейс на время сетевого вызова: человек уходит с экрана, сессия истекает, и повторная попытка требует заново собрать пакет документов.
Цена каждого такого сбоя — не потерянная минута, а сорванный процесс: договор не подписан в срок, клиент звонит в поддержку, а служба сопровождения разбирается с логами вместо новых подключений. Разбираем, как это закрывается на уровне архитектуры приложения, работы с ключами и офлайн-режима.
Что даёт правильная архитектура подписи и режимы работы
Режимы подписи: что выбираем и почему
Режим подписи определяет, где формируется криптографическая подпись и что происходит при обрыве связи. В облачном режиме ключ живёт на стороне сервиса, приложение только инициирует операцию — подпись доходит до результата даже при потере сети на середине. В локальном ключ остаётся на устройстве, и весь процесс идёт без внешних вызовов. На практике выбирают гибрид: чувствительные операции — локально, массовые — через сервис.
Хранение ключей и аппаратный криптомодуль
Ключ, лежащий в обычном хранилище приложения, — главный источник отказов и инцидентов. Аппаратный криптомодуль устройства держит ключ вне досягаемости кода: подпись выполняется внутри защищённого контура, наружу выходит только результат. Это снимает целый класс проблем — компрометацию при потере устройства, извлечение ключа из резервной копии, подмену при переустановке.
Что даёт измеримый эффект
- Доля успешных подписаний растёт за счёт повторных попыток на уровне протокола, а не пользователя.
- Время до готового документа сокращается: подготовка, подпись и отправка идут одной операцией.
- Класс отказов «подпись не сформирована» уходит — операция либо завершается, либо откатывается целиком.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Облачный режим | Массовые операции, слабые устройства | Зависимость от канала связи |
| Локальный режим | Чувствительные документы, офлайн | Требует аппаратного модуля |
| Гибрид | Смешанные сценарии | Сложнее конфигурация и поддержка |
Наши инженеры собирают схему подписи на базе аппаратного криптомодуля устройства, поэтому ключ не покидает защищённый контур, а приложение остаётся отзывчивым даже на слабом канале.
Этапы разработки: от аудита документооборота до передачи
Разработка мобильного приложения для электронной подписи начинается не с интерфейса, а с аудита документооборота: какие типы документов подписываются, кто инициирует подпись, где хранятся оригиналы, какие удостоверяющие центры уже используются. На этом этапе фиксируем схему доверия — кто выпускает сертификаты, как проверяется их статус, что происходит при отзыве. Ошибка здесь стоит дороже всего: переделка криптографического ядра после релиза означает повторную сертификацию и перевыпуск ключей у всех пользователей.
Дальше работа идёт по этапам, где каждый следующий опирается на результат предыдущего.
- Аудит документооборота — разбираем реальные сценарии подписания, роли участников, форматы документов и требования регуляторов. На выходе — карта процессов и перечень интеграций.
- Проектирование схемы доверия — определяем, где хранятся ключи, как устроена аутентификация, какие события фиксируются в журнале. Отдельно описываем поведение при компрометации ключа.
- Настройка криптографии — подключаем криптопровайдер, реализуем формирование и проверку подписи, работу с сертификатами и метками времени. Ключи храним в защищённом хранилище устройства, а не в обычном файле.
- Проверка подписания на реальных документах — прогоняем поток на настоящих договорах и актах, сверяем результат с эталонными системами. Отдельно тестируем отказы: истёкший сертификат, потеря сети, прерванная операция.
- Интеграция с учётными системами — связываем приложение с хранилищем документов и внутренними сервисами заказчика, настраиваем журналирование и уведомления.
- Передача решения и обучение — отдаём исходный код, документацию, доступы к среде сборки, проводим обучение команды заказчика и сопровождение первых релизов.
Порядок этапов неслучаен: криптография настраивается только после того, как схема доверия согласована, а проверка на реальных документах идёт до интеграции — иначе ошибки подписи всплывут уже в продуктивной среде. Опишите ваш сценарий подписания — вернёмся с оценкой и планом работ по этапам.
Чем облачная подпись отличается от локальной на устройстве?
Ключевое различие — где физически лежит закрытый ключ и кто контролирует операцию подписания. В облачной модели ключ хранится на защищённом сервере удостоверяющего центра, а мобильное приложение для электронной подписи выступает как интерфейс: пользователь подтверждает действие, запрос уходит на сервер, подпись формируется там и возвращается готовой. В локальной модели закрытый ключ лежит в защищённом хранилище самого телефона — аппаратном модуле или изолированной области — и никогда его не покидает.
Отсюда главное различие в сценарии потери устройства. При облачной модели телефон — это фактически терминал доступа: доступ отзывается сменой пароля или отзывом сессии, а сам ключ остаётся на сервере и продолжает работать с другого устройства. При локальном ключе телефон — это и есть носитель подписи: без резервной копии ключа восстановить его невозможно, а значит все ранее выданные документы остаются валидными, но подписывать новыми тем же ключом уже нельзя. Резервное копирование здесь — обязательный элемент, иначе потеря устройства означает потерю возможности подписывать.
Проверка подлинности устроена по-разному. Облачная подпись проверяется через сервис удостоверяющего центра: проверяющий обращается к нему и получает подтверждение, что сертификат действителен и не отозван на момент подписания. Локальная подпись проверяется автономно — по сертификату и цепочке доверия, без обращения к серверу, что удобно в закрытых контурах без постоянного доступа в сеть.
Ограничения у каждой модели свои. Облачная требует постоянного канала связи в момент подписания и доверия к оператору, который хранит ключ. Локальная не зависит от сети, но перекладывает ответственность за сохранность ключа на владельца устройства и хуже масштабируется на команду, где подписывать должны несколько сотрудников с разграничением прав. Выбор модели определяется тем, что критичнее: скорость отзыва доступа при потере устройства или автономность работы без сети.
Кейс: подписание договоров в поле без стабильной связи
До внедрения выездной инженер подписывал акты выполненных работ на объекте, а готовый документ появлялся в системе только после возвращения в офис. При слабом сигнале приложение теряло сессию на середине подписания, и подпись приходилось начинать заново — уже с новым кодом подтверждения. По журналу обращений в поддержку такие обрывы давали до трети всех заявок по мобильному контуру, а доля документов, подписанных с первого раза, держалась около 60%.
Мы перестроили сценарий вокруг работы офлайн: шаблон договора, реквизиты и сертификат подписи кэшируются на устройстве при выходе в поле, а сама подпись формируется локально и ставится в очередь на отправку. Как только связь появляется — даже кратковременно — очередь уходит на сервер и документ собирается в готовый файл с отметкой времени. Ключевое решение: подпись считается юридически значимой в момент формирования на устройстве, а не в момент доставки, поэтому обрыв канала больше не обесценивает работу инженера.
Что изменилось в метриках
- Доля подписанных документов с первого раза выросла с 60% до 97% — повторные подписания ушли почти полностью.
- Время от нажатия «подписать» до готового файла в системе сократилось с нескольких часов (ждали возвращения в офис) до 2-4 минут после появления связи.
- Обращения в поддержку по обрывам подписания упали более чем в пять раз — нагрузка на первую линию снизилась, инженеры перестали звонить с объекта.
| Что проверяли | До | После |
|---|---|---|
| Подпись с первого раза | ~60% | 97% |
| Время до готового документа | часы | минуты |
| Обращения в поддержку | базовая линия | −80% |
Отдельно проработали конфликт версий: если документ успел измениться на сервере, пока устройство было офлайн, приложение не перезаписывает его молча, а показывает расхождение и предлагает переподписать актуальную редакцию. Это убрало класс ошибок, когда в систему попадал устаревший готовый документ.
Логику очереди и разбора конфликтов строили на React Native с нативной обвязкой для работы с криптопровайдером — кроссплатформенный слой дал одинаковое поведение на обеих платформах без дублирования кода подписи.
Совместимость, откат и доступы: что обсудить до старта
Перед стартом заказчик обычно держит в голове три вопроса: как приложение ляжет на текущую учётную систему, что будет при сбое подписи и кто получит доступ к закрытым ключам. Отвечаем по каждому.
Что если учётная система не поддерживает нужный формат? Совместимость с учётной системой проверяем на этапе проектирования: сверяем модели пользователей, групп и прав, определяем, как приложение получает токен сессии и куда пишет статус подписанного документа. Если учётная система отдаёт данные через программный интерфейс — интегрируемся напрямую; если только через выгрузку — строим промежуточный слой синхронизации, чтобы не менять ядро.
Как откатываются изменения? Откат изменений закладываем заранее: каждая версия приложения и схемы данных помечена, миграции обратимы, а переключение между сборками занимает минуты. Если новая версия ломает сценарий подписи, возвращаемся на предыдущую без потери уже подписанных документов.
Кто и что сможет подписывать? Доступы и роли описываем матрицей: кто инициирует подпись, кто подтверждает, кто только читает. Политики подписи фиксируют, какие документы требуют одной подписи, какие — нескольких, и что происходит при отзыве сертификата. Ключи хранятся в защищённом контуре устройства, приложение не оставляет их в открытом виде.
Что если потребуется сменить поставщика или собрать приложение своими силами?
Передача документации входит в сдачу: вы получаете исходный код, схемы интеграции, описания политик подписи и инструкции по сборке. Этого достаточно, чтобы поддерживать и развивать приложение без нас.
Что заказчик получает на руки:
- конфигурации интеграции с учётной системой и описание точек обмена;
- матрицу доступов и ролей с разграничением прав;
- политики подписи для каждого типа документа;
- регламент отката и порядок возврата на предыдущую версию;
- инструкции по сборке, выпуску и обновлению приложения;
- описание хранения и ротации ключей подписи;
- журнал изменений и чеклист приёмки.
Опишите вашу учётную систему и сценарии подписания — вернёмся с оценкой и планом интеграции.
Сроки этапов внедрения мобильной подписи
Сроки зависят не от объёма кода, а от того, сколько внешних систем нужно свести: удостоверяющий центр, хранилище документов, корпоративный вход, согласование юридически значимого формата подписи. Поэтому план строится волнами — каждая заканчивается работающим результатом, который можно показать службе безопасности и юристам.
Этапы частично идут параллельно: пока ядро стабилизируется, интеграции уже можно начинать на тестовом контуре. Отдельно закладываем время на согласование с юристами — требования к формату подписи и сроку хранения документов часто правятся по ходу.
Что если у нас свой удостоверяющий центр? Тогда этап интеграций сокращается, но добавляется проверка совместимости выпускаемых сертификатов с мобильными хранилищами ключей.
Что если нужен офлайн-режим? Подпись формируется на устройстве, а отправка и проверка статуса — при появлении связи; это удлиняет ядро на 1-2 недели.
Опишите ваши сценарии подписания — вернёмся с оценкой и планом по этапам.
