Аудит дій користувача в корпоративному мобільному додатку

Аудит дій користувача в корпоративному мобільному додатку

Ми розробляємо та впроваджуємо 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) забезпечується за рахунок правильного оформлення логування та конфіденційності.