Аудит действий пользователя в корпоративном мобильном приложении
Мы разрабатываем и внедряем 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 года.
| Хранилище | Преимущества | Недостатки |
|---|---|---|
| PostgreSQL + RLS | Простота, append-only | Меньше масштабируемость при миллионах записей |
| SIEM (Splunk/ELK) | Аналитика, ротация, быстрый поиск | Сложнее настройка |
Что входит в нашу работу?
Мы предоставляем полный комплекс услуг по внедрению audit trail:
| Этап | Результат |
|---|---|
| Аудит текущего логирования | Отчёт с выявленными проблемами и рекомендации |
| Проектирование схемы событий | Документ с перечнем событий и метаданных |
| Реализация локальной очереди | Код с WorkManager/BGProcessingTask и SQLite |
| HMAC-подпись событий | Интеграция с Keystore/Enclave, серверная верификация |
| Интеграция с сервером | API endpoint с append-only таблицей |
| Документация и обучение | Инструкция для администраторов и разработчиков |
Сроки: от 2 до 6 дней в зависимости от сложности. Свяжитесь с нами, чтобы обсудить детали. Получите консультацию прямо сейчас.
Что проверить на аудите приложения?
Часто обнаруживаем, что в приложении уже есть «какое-то логирование» — но оно пишет в Logcat или в файл в cacheDir, который очищается при нехватке места. Это не audit trail, это мусор. Наша команда проведёт аудит и покажет, как исправить ситуацию.
Пример реализации локальной очереди
Код для AuditEventDao и WorkManager доступен выше. Полный проект можно запросить у нас.
Процесс внедрения включает следующие шаги:
- Анализ требований и аудит текущего логирования.
- Проектирование схемы событий и метаданных.
- Реализация локальной очереди с гарантированной доставкой.
- Внедрение HMAC-подписи для целостности.
- Интеграция с серверным хранилищем (PostgreSQL или SIEM).
- Тестирование и обучение команды.
Примечание: соответствие требованиям App Store Review Guidelines (Section 4.2 и 5.1) обеспечивается за счёт правильного оформления логирования и конфиденциальности.