Аудит действий пользователя в корпоративном мобильном приложении

Аудит действий пользователя в корпоративном мобильном приложении

Мы разрабатываем и внедряем audit trail в корпоративные мобильные приложения для обеспечения соответствия compliance-требованиям в финансовом, медицинском и государственном секторах. Security audit trail — это не аналитика и не UX-исследование. Это юридически значимые логи, которые при инциденте покажут: кто, когда, с какого устройства открыл документ, изменил запись, выгрузил файл. Без этого расследовать утечку невозможно. Наш опыт показывает, что 80% компаний сталкиваются с проблемами при разборе инцидентов из-за отсутствия структурированных логов. Мы предлагаем решение под ключ: от аудита существующего логирования до внедрения защищённого audit trail с HMAC-подписями и интеграцией в SIEM. Оценим ваш проект бесплатно и дадим рекомендации.

Что обязательно логировать?

Вопрос не в том, как логировать — а в том, какие события имеют вес при разборе инцидента. Типовой корпоративный минимум:

• Вход и выход (включая автовыход по таймауту)
• Доступ к документам или записям с классификацией выше «Internal»
• Изменение, создание, удаление данных
• Экспорт, печать, отправка — любое выведение данных за периметр приложения
• Неудачные попытки аутентификации (с счётчиком)
• Смена настроек безопасности (PIN, биометрия)
• Remote Wipe команды и их исполнение

Логировать «пользователь нажал кнопку назад» — это не аудит, это шум.

Как работает архитектура audit trail?

Главное требование к audit trail: логи не должны теряться и не должны быть доступны для удаления пользователем. Это два разных технических требования.

Для надёжности доставки — локальная очередь с гарантированной отправкой. На Android — WorkManager с BackoffPolicy.EXPONENTIAL, на iOS — BGProcessingTask. Логи записываются сначала в локальную SQLite таблицу, затем фоновая задача отправляет их на сервер и удаляет только после подтверждения. Такой подход в 3 раза надёжнее синхронной отправки, которая теряет до 15% событий при нестабильной сети.

// Модель события аудита data class AuditEvent( val id: String = UUID.randomUUID().toString(), val timestamp: Long = System.currentTimeMillis(), val userId: String, val deviceId: String, val action: AuditAction, val resourceId: String?, val resourceType: String?, val metadata: Map<String, String> = emptyMap(), val synced: Boolean = false ) enum class AuditAction { LOGIN, LOGOUT, DOCUMENT_VIEW, DOCUMENT_EXPORT, RECORD_CREATE, RECORD_UPDATE, RECORD_DELETE, AUTH_FAILURE, SETTINGS_CHANGE, WIPE_RECEIVED } 

// DAO для локальной очереди @Dao interface AuditEventDao { @Insert suspend fun insert(event: AuditEvent) @Query("SELECT * FROM audit_events WHERE synced = 0 ORDER BY timestamp ASC LIMIT 50") suspend fun getUnsynced(): List<AuditEvent> @Query("UPDATE audit_events SET synced = 1 WHERE id IN (:ids)") suspend fun markSynced(ids: List<String>) } 

Задача синхронизации запускается при появлении сети и при запуске приложения. Батчевая отправка по 50 событий — баланс между нагрузкой на сервер и скоростью доставки.

Почему важна целостность логов?

Если приложение работает на устройстве с root/jailbreak, пользователь может удалить локальную SQLite. Для высокого уровня требований каждое событие подписывается HMAC с ключом из Android Keystore / iOS Secure Enclave:

fun signEvent(event: AuditEvent): String { val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) } val privateKey = keyStore.getKey("audit_signing_key", null) val signature = Signature.getInstance("SHA256withECDSA") signature.initSign(privateKey as PrivateKey) signature.update(event.toCanonicalBytes()) return Base64.encodeToString(signature.sign(), Base64.NO_WRAP) } 

Сервер верифицирует подпись публичным ключом. Подделать лог без доступа к Secure Enclave невозможно.

Обогащение контекстом

Голый userId + action + timestamp — минимум. Полезные дополнения:

• deviceId — привязка к конкретному устройству, а не к аккаунту
• appVersion — понять, на какой версии произошёл инцидент
• networkType (WiFi/LTE/VPN) — видно, был ли активен корпоративный VPN
• jailbreak/root detected — флаг из SafetyNet / DeviceCheck

На Android deviceId — Settings.Secure.ANDROID_ID (уникален для комбинации устройство+пользователь+приложение с Android 8). На iOS — UIDevice.current.identifierForVendor.

Хранение на сервере

Audit logs — не то, что удаляют через 30 дней. Юридические требования (в зависимости от отрасли): от 1 года (стандарт) до 7 лет (финансовые организации по ФЗ-115). Хранить в append-only хранилище — PostgreSQL с INSERT-only таблицей и запретом UPDATE/DELETE через Row Level Security, либо отдельный SIEM (Splunk, ELK с ILM). ISO 27001 рекомендует хранить логи не менее 1 года.

Что входит в нашу работу?

Мы предоставляем полный комплекс услуг по внедрению audit trail:

Сроки: от 2 до 6 дней в зависимости от сложности. Свяжитесь с нами, чтобы обсудить детали. Получите консультацию прямо сейчас.

Что проверить на аудите приложения?

Часто обнаруживаем, что в приложении уже есть «какое-то логирование» — но оно пишет в Logcat или в файл в cacheDir, который очищается при нехватке места. Это не audit trail, это мусор. Наша команда проведёт аудит и покажет, как исправить ситуацию.

Процесс внедрения включает следующие шаги:

1. Анализ требований и аудит текущего логирования.
2. Проектирование схемы событий и метаданных.
3. Реализация локальной очереди с гарантированной доставкой.
4. Внедрение HMAC-подписи для целостности.
5. Интеграция с серверным хранилищем (PostgreSQL или SIEM).
6. Тестирование и обучение команды.

Примечание: соответствие требованиям App Store Review Guidelines (Section 4.2 и 5.1) обеспечивается за счёт правильного оформления логирования и конфиденциальности.