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

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

Security audit trail — это не аналитика и не UX-исследование. Это юридически значимые логи, которые при инциденте покажут: кто, когда, с какого устройства открыл документ, изменил запись, выгрузил файл. Без этого расследовать утечку невозможно.

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

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

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

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

Архитектура audit trail

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

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

// Модель события аудита
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).

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

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

Сроки: 2–3 дня на базовую реализацию с локальной очередью и серверным endpoint. С HMAC-подписями и интеграцией в SIEM — 4–6 дней.