Разработка мобильного приложения для государственных услуг

Разработка мобильного приложения для государственных услуг

Госуслуги — это не просто CRUD с авторизацией. Это интеграция с ФНС, Госключом, ЕСИА (Единой системой идентификации и аутентификации), очередями СМЭВ, УКЭП и XML-схемами, которым по 12 лет. Плюс — обязательная сертификация, 152-ФЗ, хранение ПДн на серверах РФ. Прежде чем написать первую строку кода, нужно разобраться с регуляторикой.

Авторизация через ЕСИА и Госключ

Самая болезненная точка. ЕСИА работает через OAuth 2.0 с модификациями, но не стандартными. Подпись запроса — ГОСТ Р 34.10-2012, не RSA. Это значит, что стандартная библиотека типа AppAuth для iOS и Android не подойдёт напрямую — нужно либо использовать SDK от Ростелекома, либо реализовывать подпись самостоятельно через CryptoPro или ViPNet.

На Android CryptoPro CSP встраивается как .apk-провайдер или через JCE-провайдер. Сертификат пользователя лежит в хранилище КриптоПро, доступ к нему — через KeyStore с кастомным провайдером:

val keyStore = KeyStore.getInstance("CryptoProKeyStore")
keyStore.load(null)
val privateKey = keyStore.getKey(alias, null) as PrivateKey
val signature = Signature.getInstance("GOST3411withGOST3410EL")
signature.initSign(privateKey)
signature.update(dataToSign)
val signedData = signature.sign()

На iOS история сложнее — нативного ГОСТ нет, используется SDK ViPNet CSP через Obj-C/C++ обёртку. Bridging Header, статическая линковка, ручное управление памятью в критических местах. В одном из проектов из-за этого cold start вырос с 1.2 до 2.8 секунд — пришлось вынести инициализацию провайдера в background thread с проверкой готовности перед первым криптооперацией.

Госключ интегрируется через Deep Link / Universal Link: приложение формирует запрос на подпись, передаёт в Госключ через URL-схему, получает callback с подписанным документом. Схема работает, но с нюансом — если Госключ не установлен, нужен fallback на веб-версию или QR-код. Обрабатывать это в UIApplicationDelegate / Activity.onNewIntent нужно аккуратно: состояние экрана может измениться пока пользователь был в Госключе.

Интеграция со СМЭВ и ГИС

СМЭВ 3 работает через SOAP с WS-Security. Мобильное приложение напрямую со СМЭВ не общается — только через backend. Но это не снимает проблемы: XML-схемы запросов бывают объёмными (реестры, справки), и нужна валидация на клиенте до отправки.

Для Android используем javax.xml.validation с XSD:

val schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI)
val schema = schemaFactory.newSchema(Source(xsdInputStream))
val validator = schema.newValidator()
validator.validate(StreamSource(xmlInputStream))

На iOS — libxml2 через C-биндинги, либо просто JSON-API через backend-прокси. Второй вариант проще, но теряется часть контроля над форматом.

Статусы заявок — отдельная боль. Государственные процессы асинхронные: заявка подана, обрабатывается 3-5 рабочих дней, приходит уведомление. Нужен polling или push через FCM/APNs. Push-уведомления от госсервисов часто содержат только serviceId без деталей — значит, при тапе на нотификацию нужен отдельный запрос за данными перед навигацией. Если запрос упал — показываем skeleton, не крашимся.

Требования к хранению данных и безопасности

152-ФЗ требует хранения ПДн на территории РФ. Для мобильного приложения это означает: backend на российских серверах (Яндекс.Облако, SberCloud, VK Cloud), запрет на передачу данных через зарубежные CDN и аналитику.

Локальное хранение чувствительных данных — только через EncryptedSharedPreferences на Android (AES256-GCM через Jetpack Security) или Keychain на iOS с kSecAttrAccessibleWhenUnlocked. Токены сессии ЕСИА нельзя хранить в SharedPreferences без шифрования — это прямое нарушение требований к защите ПДн.

Сертификация ФСТЭК нужна не всегда, но если приложение обрабатывает сведения ограниченного доступа (не государственную тайну, но служебную информацию) — нужна аттестация по 17-му приказу. Это влияет на выбор криптобиблиотек: только сертифицированные СКЗИ.

Сканирование на уязвимости перед релизом — обязательно. Используем MobSF (Mobile Security Framework) для статического анализа APK/IPA, OWASP Mobile Top 10 как чеклист. Особое внимание — exported Activities без проверки Intent, незащищённые ContentProviders, логирование токенов в LogCat.

Специфика UX для госприложений

Аудитория — люди 18-80 лет с разным уровнем цифровой грамотности. Размер шрифта по умолчанию — крупнее стандартного. Поддержка Dynamic Type (iOS) и sp-единиц (Android) обязательна. Экраны с формами — короткие шаги, никаких многостраничных wizard-форм без сохранения прогресса.

Доступность (a11y): contentDescription для каждого значимого элемента, правильные accessibilityRole в React Native или UIAccessibilityTraits в SwiftUI. Приложения Госуслуг периодически проверяет Роскомнадзор, в том числе на доступность для людей с ОВЗ.

Офлайн-режим критически важен: не у всех пользователей стабильный интернет. Кэшируем справочники (список регионов, типов документов) через Room / Core Data. Статусы заявок синхронизируем при восстановлении соединения через WorkManager (Android) или BGTaskScheduler (iOS).

Стек и архитектура

Для большинства госприложений оптимальна нативная разработка — iOS (Swift + UIKit/SwiftUI) + Android (Kotlin + Jetpack Compose). Flutter — допустим, если команда подготовлена и нет hard-зависимости от нативных криптобиблиотек. React Native с react-native-crypto — рискованно: ГОСТ-криптография через JS-мост нестабильна.

Архитектура: Clean Architecture + MVVM. Repository слой изолирует СМЭВ/ЕСИА от UI. UseCase содержит бизнес-логику обработки статусов. ViewModel управляет состоянием экрана. Dependency Injection — Hilt (Android) / Swinject (iOS).

Этапы работы

Аудит требований включает юридическую экспертизу: какие данные обрабатываются, нужна ли аттестация, какие API ЕСИА/СМЭВ используются. Без этого этапа техническое проектирование невозможно.

Проектирование: UX для целевой аудитории, схема авторизации, модель данных, API-контракты с backend.

Разработка идёт итерационно: сначала авторизация и core-флоу, потом формы и справочники, потом push и офлайн. Интеграционное тестирование — в тестовой среде ЕСИА (есть отдельный стенд для разработчиков).

Публикация: RuStore обязателен для госприложений с 2023 года. Google Play и App Store — параллельно. Прохождение ревью RuStore медленнее (5-10 дней vs 1-3 дня в Google Play).

Поддержка: изменения API ЕСИА и схем СМЭВ выходят без предупреждения. Мониторинг через Firebase Crashlytics + кастомные алерты на изменение структуры ответа.

Сроки MVP (авторизация + 2-3 госуслуги): 3-5 месяцев. Полнофункциональное приложение с широким каталогом услуг — 8-14 месяцев. Стоимость рассчитывается индивидуально после анализа требований и состава интеграций.