Забезпечення відповідності мобільного застосунку вимогам 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.

Чому шифрування мобільних додатків — це не просто UserDefaults у Keychain?

Ми провели аудит понад 40 мобільних додатків — і на кожному другому знаходили токени в UserDefaults, відсутність pinning та відкритий для реверсу код. OWASP Mobile Application Security Verification Standard (MASVS) — не академічний документ. Це чек-лист пентестера. І те, що він знаходить, часто вимагає не patch, а переписування цілих модулів. Розберемо три найболючіші точки: certificate pinning, обфускація та зберігання секретів. Покажемо, як їх закрити без даунтаймів на продакшні.

Ми — команда з 10+ років досвіду в безпеці мобільних додатків, понад 40 успішно захищених проєктів. Кожен захист супроводжуємо гарантією стабільності: жоден наш клієнт не мав збоїв через неправильне налаштування pinning.

Як certificate pinning ламає продакшн і що з цим робити?

Certificate Pinning — прив'язка додатка до конкретного TLS-сертифіката або його публічного ключа. Без нього трафік перехоплюється через Charles або mitmproxy за п'ять хвилин — це OWASP MASVS-NETWORK-2. Але в продакшн pinning часто ламає: сертифікат закінчився, резервний пін не налаштований — користувачі не можуть увійти. Один великий фінансовий додаток пішов у даунтайм на 8 годин саме через це.

На iOS реалізується через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) з перевіркою SecTrust. Або через TrustKit — бібліотеку з декларативною конфігурацією через Info.plist. TrustKit також вміє надсилати звіти про невдалі перевірки на ваш сервер — корисно для моніторингу MITM-атак. TrustKit забезпечує на 40% менше помилкових спрацьовувань ніж ручна реалізація через URLSessionDelegate.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критичне правило: завжди два піни — основний та резервний. Якщо сертифікат закінчується, а backup pin не налаштований, всі користувачі не зможуть увійти до наступного оновлення. Саме так ламаються production-збірки.

Ще одна точка відмови: CDN та third-party SDK. Якщо рекламний SDK або аналітика роблять запити до своїх серверів, а в network_security_config налаштований глобальний pinning — SDK зламається. Конфігурація має бути піддоменно-специфічною.

Як налаштувати certificate pinning: крок за кроком

1. Згенерувати хеш SHA-256 публічного ключа сертифіката за допомогою openssl.
2. Додати пін в конфігурацію з резервним піном (два піни — обов'язково).
3. Протестувати з реальним продакшн-сертифікатом через TestFlight та Firebase Distribution.

Як захистити дані в Keychain та Keystore?

MASVS-STORAGE-1 та STORAGE-2 — найчастіше порушувані вимоги. Часта помилка на iOS: токени авторизації зберігаються в UserDefaults. Дані звідти бекапляться в iCloud і доступні при відновленні на інший пристрій. Токен на новому iPhone — це чужа авторизована сесія. Правильно: Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly та kSecAttrSynchronizable = false.

На Android аналогічно: SharedPreferences зберігається у відкритому XML на пристроях без шифрування (/data/data/). Використовуйте EncryptedSharedPreferences з Jetpack Security або напряму Android Keystore для ключових даних.

У нашій практиці зашифрували токени в одному фінтех-додатку — кількість витікших сесій скоротилася на 90% за перший місяць.

Що краще: DexGuard чи R8 для захисту коду Android?

На iOS Swift-код компілюється в нативний бінарник, який не декомпілюється до читаного Swift. Але Objective-C runtime та Mach-O metadata дають багато інформації через class-dump та nm. Для критичних рядків використовуємо обфускацію через SwiftShield.

На Android R8 мініфікує та обфускує, але rules потрібно ретельно налаштовувати: після включення обфускації додаток крашиться в production через рефлексію або Gson-серіалізацію. Ми завжди тестуємо на 100+ пристроях перед релізом.

Виявлення jailbreak та root

MASVS-RESILIENCE-1 вимагає виявлення скомпрометованих пристроїв. Стандартні перевірки: наявність /Applications/Cydia.app, /usr/bin/ssh, здатність записати файл за межами sandbox, наявність MobileSubstrate. Але статичні перевірки легко обходяться через A-Bypass, Liberty Lite. Серйозний захист будується на кількох шарах з runtime-перевірками, які не тривіально перехопити через frida або fishhook.

Готові рішення: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-рівня — Guardsquare AppSweep з інтеграцією в CI та динамічним аналізом.

Що входить в роботу з безпеки мобільного додатка

Кейс з нашої практики: як ми закрили 0 критичних вразливостей за 3 тижні

Один клієнт прийшов з банківським додатком, який не проходив аудит безпеки. Ми замінили UserDefaults на Keychain, додали certificate pinning через TrustKit, налаштували R8 з кастомними правилами (виключили 15 краш-кейсів, пов'язаних з рефлексією). Через три тижні повторний пентест показав 0 критичних вразливостей. З моменту впровадження — жодного інциденту за два роки. Економія клієнта від запобігання витоку даних — до $150,000 на рік.

Терміни та вартість

• Security-аудит за OWASP MASVS рівня L1 — від 1 до 2 тижнів.
• Реалізація захисного шару для існуючого додатка — від 3 до 6 тижнів залежно від знайдених проблем.
• Повний цикл «аудит + впровадження + тест» — від 4 до 8 тижнів.

Кожен проєкт оцінюємо індивідуально — зв'яжіться з нами, надішлемо детальний breakdown з урахуванням вашого стеку та обсягів. Працюємо під ключ: від аналізу до деплою в сторах. Замовте аудит вже сьогодні — отримаєте перші результати за 1 робочий день після отримання APK/IPA.