Забезпечення відповідності мобільного додатку вимогам SOC 2

Забезпечення SOC 2-комплайансу мобільного додатку

SOC 2 — це не закон і не регулятор. Це аудиторський стандарт (AICPA), який крупні корпоративні клієнти вимагають від SaaS-вендорів та мобільних додатків, що обробляють їх дані. Якщо B2B-додаток хоче працювати з Enterprise-клієнтами в США та Західній Європі — SOC 2 Type II звіт відкриває двері, які інакше закриті.

Що SOC 2 означає для мобільного додатку

SOC 2 будується на Trust Service Criteria (TSC). Для більшості мобільних додатків релевантні три:

• Security — завжди обов'язковий
• Availability — якщо додаток критичний для бізнесу клієнта
• Confidentiality — якщо обробляються конфіденційні дані клієнта

Кожен критерій — набір контролів (CC). Аудитор перевіряє не наміри а докази: логи, конфіги, процедури, результати тестування. SOC 2 Type II — аудит за період (зазвичай 12 місяців), не снімок.

Технічні контролі на боці мобільного клієнта

Більшість SOC 2 контролів реалізується на серверній стороні. Мобільний клієнт відповідає за кілька спеціфічних областей:

CC6.1 — Logical and Physical Access Controls

Багатофакторна аутентифікація. Для корпоративних користувачів SOC 2 фактично вимагає MFA. У мобільному додатку — TOTP (Google Authenticator / Authy сумісний), push-based аутентифікація (Firebase або власна) або біометрія + PIN.

// Перевіра наявності біометрії як другого фактора
val biometricManager = BiometricManager.from(context)
when (biometricManager.canAuthenticate(BIOMETRIC_STRONG)) {
    BIOMETRIC_SUCCESS -> enableBiometricMFA()
    BIOMETRIC_ERROR_NO_HARDWARE -> requireTOTP()
    BIOMETRIC_ERROR_NONE_ENROLLED -> promptUserToEnrollBiometric()
}

Автоматичний вихід та блокування сеансу. Session timeout після періоду неактивності — типовий контроль CC6.1. Для B2B додатків: 15–30 хвилин неактивності → блокування, вимагаючи повторної аутентифікації (не повного logout).

CC6.7 — Transmission of Data

Certificate pinning для всіх API endpoints. Не тільки production — staging середовище з тестовими даними клієнтів теж повинно бути захищено. Окремий пін для staging, задокументований в runbook ротації.

Логування всіх API запитів з помилками 4xx/5xx — не на пристрої, на сервері. Аудитор попросить приклади логів за період.

CC7.2 — Monitoring of System Components

Tampering detection. SOC 2 аудитор запитує: як ви виявляєте, що клієнтський додаток модифіковано? Відповідь повинна включати технічне рішення:

// SafetyNet Attestation API (застарілий, заміна — Play Integrity API)
val integrityManager = IntegrityManagerFactory.create(context)
val integrityTokenResponse = integrityManager.requestIntegrityToken(
    IntegrityTokenRequest.builder()
        .setNonce(serverGeneratedNonce)
        .build()
)
// Маркер верифікується на сервері через Google API

На iOS — DeviceCheck + AppAttest для верифікації підлинності додатку на серверній стороні.

CC9.2 — Vendor and Business Partner Management

Кожен SDK у додатку — вендор. SOC 2 аудитор запитує: є ли vendor assessment для Firebase, Amplitude, Braze? Які дані вони отримують? Їх SOC 2 статус?

Відповідь: інвентар всіх SDK із указанием даних, що вони отримують, посилання на їх SOC 2 звіти (у Firebase, AWS, Amplitude вони є публічно або за NDA). Це vendor inventory — документ, який потрібно підтримувати актуальним.

Свідоцтва (Artifacts) для аудитора

SOC 2 аудит — це збір доказів. Для мобільного додатку типові артефакти:

Continuous Compliance

SOC 2 Type II — це 12 місяців доказів. Не можна впровадити контролі за тиждень до аудиту. Потрібен pipeline:

• SAST в CI/CD (Semgrep, Snyk) з блокуванням при критичних знахідках
• Автоматичне оновлення dependency з Dependabot / Renovate
• Periodic access review — хто має доступ до production даних
• Задокументована процедура реагування на інциденти з прикладами

Терміни

Підготовка до SOC 2 Type I (снімок): 4–8 тижнів технічних робіт + документація. SOC 2 Type II вимагає 6–12 місяців роботи контролів перед аудитом. Стоимость рассчитывается після gap analysis.