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