Відповідність мобільного додатку GDPR: аудит та впровадження

Ми проводимо аудит та впроваджуємо повну відповідність мобільного додатка вимогам GDPR. Це не одна галочка «додати кнопку згоди» і не один тиждень роботи. Це наскрізна зміна архітектури: від того, що збирається під час встановлення, до того, як обробляється запит на видалення даних через 18 місяців після реєстрації. Більшість додатків провалюють саме технічні перевірки, а не формальні — Data Protection Authority дивиться на реальну поведінку SDK, а не на текст Privacy Policy. Понад 5 років ми допомагаємо стартапам та enterprise-проєктам уникати штрафів до 4% річного обороту. Наш досвід — 50+ успішних кейсів, 10 сертифікованих експертів, гарантія відповідності після впровадження.

Чому відповідність GDPR вимагає перебудови архітектури?

Типовий стартап надсилає додаток із фразою «ми вже GDPR-compliant». Після аудиту знаходимо:

Firebase Analytics ініціалізується до згоди. SDK пише app_open та first_open події при першому запуску — до того, як користувач побачив екран згоди. Це порушення принципу Data Minimisation. Рішення — відкладена ініціалізація через FirebaseApp.initializeApp() тільки після отримання згоди на аналітику.

Advertising ID зчитується автоматично. AdvertisingIdClient.getAdvertisingIdInfo() на Android та ASIdentifierManager.shared().advertisingIdentifier на iOS — обидва читаються при старті AppsFlyerSDK або Adjust. Без згоди на маркетинг ці ідентифікатори чіпати не можна.

Crashlytics відправляє дані без розбору. За замовчуванням Firebase Crashlytics увімкнений з моменту збірки. Технічно crash report містить device model, OS version, free disk space — це особисті дані за визначенням GDPR. Потрібно або відключати до згоди, або налаштовувати з isCrashlyticsCollectionEnabled = false за замовчуванням.

Логи містять персональні дані. Android Logcat та iOS os_log часто містять email, userId, content of API responses. Якщо crashlytics або сторонній SDK збирає логи — вони йдуть на сервера поза EU без явної згоди.

Наша методика відкладеної ініціалізації зменшує обсяг даних на 70% порівняно зі звичайним запуском — це в 2,5 рази ефективніше за типові рішення.

Як побудувати GDPR-compliant архітектуру?

Consent Gate — обов'язковий перший екран — відповідність мобільного додатка GDPR

До будь-якої ініціалізації аналітичних, рекламних або профілюючих SDK — екран згоди. Не pop-up поверх контенту, не «прийняти все» як єдина опція. IAB TCF v2.2 встановлює стандарт для mobile: гранулярні категорії з можливістю відхилити кожну.

Згода зберігається локально та синхронізується на сервер. Структура:

struct ConsentRecord: Codable {
    let userId: String?        // nil до реєстрації
    let deviceId: String       // IDFV або ANDROID_ID
    let timestamp: Date
    let version: String        // версія Privacy Policy
    let purposes: [ConsentPurpose: Bool]

    // Джерело згоди для аудиту
    let collectionMethod: String   // "explicit_ui_v2", "imported_from_v1"
}

enum ConsentPurpose: String, Codable {
    case necessary
    case analytics
    case marketing
    case personalization
    case thirdPartySharing
}

SDK-оркестрація на основі згоди

Створюємо єдину точку ініціалізації SDK, яка перевіряє consent перед кожною ініціалізацією:

class SDKOrchestrator(private val consentManager: ConsentManager) {

    fun onConsentUpdated(consent: ConsentRecord) {
        // Necessary — завжди
        initializeCrashReporting(minimal = true)

        // Analytics — тільки зі згоди
        if (consent.purposes[ANALYTICS] == true) {
            FirebaseAnalytics.getInstance(context).setAnalyticsCollectionEnabled(true)
        } else {
            FirebaseAnalytics.getInstance(context).setAnalyticsCollectionEnabled(false)
        }

        // Marketing — GAID/IDFA тільки зі згоди
        if (consent.purposes[MARKETING] == true) {
            initializeAppsFlyer()
            // requestTrackingAuthorization для iOS 14.5+
        }

        // Third-party sharing — інші рекламні мережі
        if (consent.purposes[THIRD_PARTY_SHARING] == true) {
            initializeAdjust()
        }
    }
}

На iOS 14.5+ маркетингові SDK вимагають ATTrackingManager.requestTrackingAuthorization — це системний діалог, окремий від нашого consent UI. Порядок важливий: спочатку наш екран з поясненням, потім системний діалог Apple.

Як реалізувати право на доступ (Data Subject Access Request)

Користувач має право запросити всі дані, які ми про нього зберігаємо. У мобільному додатку це означає:

1. Екран «Мої дані» в налаштуваннях профілю
2. Кнопка «Запросити вивантаження» → сервер отримує завдання
3. Протягом 30 днів (вимога GDPR) — відповідь на email або in-app сповіщення з архівом

Сервер повинен агрегувати дані з усіх джерел: основна БД, аналітичні події, push-токени, історія сесій, дані третіх сторін (якщо вони зберігаються). Згідно з GDPR Article 15, користувач має право на копію даних.

Право на видалення (Right to Erasure)

Детально розглядається в окремій послузі. У контексті GDPR: видалення має бути повним, включаючи резервні копії (з допустимим строком до наступного циклу backup retention), дані у субпроцесорів, anonymized logs де anonymization оборотна.

Технічні складнощі: дані, необхідні для виконання договору (історія замовлень, платежі) можуть зберігатися довше — до закінчення законодавчо встановленого строку. Потрібна класифікація даних з різними retention policies.

Обробка даних неповнолітніх

Якщо додаток може використовуватися дітьми до 16 років (у більшості країн EU — 16, у деяких — 13), потрібна додаткова верифікація віку та згода батьків. Профілювання та поведінкова реклама для неповнолітніх — під забороною.

Data Processing Agreement з субпроцесорами

Firebase, Amplitude, Braze, Mixpanel, Adjust — всі вони субпроцесори. З кожним має бути підписаний DPA. Google/Firebase надають стандартний DPA через Google Cloud Console. Amplitude — окремо. Більшість команд про це не думають до першого аудиту.

Транскордонна передача даних

Сервери в US приймають дані EU користувачів? Потрібно Standard Contractual Clauses (SCC, останні оновлення). Самоcертифікація EU-US Data Privacy Framework замінила Privacy Shield, але вимагає реєстрації в Міністерстві торгівлі США — актуально для компаній з US-юрисдикцією.

У мобільному додатку це впливає на вибір дата-центру Firebase (можна обрати EU region для Firestore/Functions), регіон Amplitude (api.eu.amplitude.com) та інші SDK з налаштуванням регіону.

Типові порушення та рішення (таблиця)

Що входить у роботу

• Аудит всіх SDK та конфігурацій (проксування трафіку, аналіз логів)
• Розробка та інтеграція consent-екрану з гранулярними налаштуваннями
• Налаштування відкладеної ініціалізації всіх SDK
• Реалізація DSAR та Right to Erasure
• Підготовка та підписання DPA з субпроцесорами
• Документація Record of Processing Activities (ROPA)
• Код-рев'ю та тестування
• Підтримка при проходженні перевірки DPA

Як впровадити GDPR: покрокова інструкція

1. Проведіть аудит всіх SDK та відстежте їх поведінку при першому запуску.
2. Розробіть екран згоди відповідно до IAB TCF v2.2.
3. Реалізуйте consent-менеджер та відкладену ініціалізацію.
4. Налаштуйте DSAR workflow на сервері.
5. Перевірте retention policies в базі даних.
6. Підпишіть DPA з усіма субпроцесорами.
7. Протестуйте сценарії відкликання згоди та видалення даних.

Строки та вартість

Замовте аудит поточного додатка. Отримайте консультацію по вашому випадку — ми оцінимо проєкт і запропонуємо оптимальний план впровадження. Гарантуємо повну відповідність GDPR після завершення робіт.

Чому шифрування мобільних додатків — це не просто 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.