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

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

Якщо ваше B2B-застосунок обробляє корпоративні дані, сертифікація SOC 2 — обов'язкова умова для роботи з Enterprise-клієнтами в США та Європі. Без неї вас не допустять навіть до пілоту, а великі контракти залишаться недоступні. Ми допомагаємо впровадити контролі безпеки, доступності та конфіденційності прямо в мобільний код — від впровадження багатофакторної аутентифікації до автоматичного збору логів для аудитора. Кожен контроль документується та перевіряється: аудитор вимагає не намірів, а доказів. Наш досвід — 15+ підготовок до SOC 2 для iOS, Android та Flutter-застосунків, включаючи проекти з вимогами до безпеки фінансових даних. Гарантуємо, що ваш застосунок пройде аудит з першого разу.

Як автоматизувати збір evidence для аудитора?

Ручний збір evidence — найчастіша причина затягування аудиту. Щотижневі звіти, логи, конфіги — все це потрібно версіонувати та зберігати за період 12 місяців. Ми налаштовуємо CI/CD pipeline, який автоматично збирає SAST-звіти (MobSF, Semgrep), логи Play Integrity, результати certificate pinning та access review. Це скорочує час підготовки вдвічі порівняно з ручним збором, а витрати — на 30–50%. Аудитор отримує єдиний дашборд з історією змін.

Які критерії Trust Service Criteria застосовні?

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-аутентифікація (через Firebase або власний push) або biometric + 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. Не тільки виробничих — staging середовище з тестовими даними клієнтів теж повинно бути захищене. Окремий пін для staging, документований у runbook ротації.

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

CC7.2 — Monitoring of System Components

Аудитор вимагатиме докази виявлення модифікації клієнтського застосунку. Ми реалізуємо tampering detection за допомогою Play Integrity API на Android та DeviceCheck + AppAttest на iOS. Токен верифікується на сервері через Google API.

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

CC9.2 — Vendor and Business Partner Management

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

Свідчення (Evidence) для аудитора

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

Порівняння підходів до збору evidence

Автоматизація збору evidence скорочує час підготовки вдвічі порівняно з ручним збором, а витрати — на 30–50%. Отримайте консультацію щодо вашого проекту — ми покажемо, як це зробити.

Як підготуватися до аудиту SOC 2?

Continuous Compliance — єдиний реальний шлях. Неможливо впровадити контролі за тиждень до аудиту. Ось покроковий план:

1. Проведіть gap analysis поточного стану застосунку.
2. Реалізуйте контролі: MFA, certificate pinning, tampering detection, session timeout.
3. Налаштуйте автоматичний збір evidence: SAST у CI/CD, логування, periodic access review.
4. Документуйте кожен контроль і процедуру.
5. Оберіть акредитованого аудитора.
6. Пройдіть аудит і виправте зауваження.

Ми маємо 7+ років досвіду в мобільній розробці та провели понад 15 підготовок до SOC 2. Економія часу на аудит становить до 40% завдяки автоматизації. Зв'яжіться з нами для консультації — ми оцінимо обсяг робіт і запропонуємо план.

Стандарт SOC 2 розроблений AICPA. Детальніше на Wikipedia.