Реалізація DLP-політик у мобільному додатку

Конфіденційний контракт, скопійований у буфер обміну, опиняється в особистому Telegram за секунду. Це не гіпотетичний сценарій, а реальна загроза для 68% компаній, які використовують корпоративні мобільні додатки. Згідно зі звітом InfoWatch, 70% витоків даних відбуваються через мобільні пристрої. DLP-політики запобігають таким витокам на рівні коду та MDM. Ми впроваджуємо захист буфера, скріншотів і Open-In у мобільні додатки iOS та Android. За понад 5 років ми виконали більше 30 проєктів із захисту мобільних додатків від витоків, працюємо з компаніями з Banking, Fintech, Healthcare — у цих галузях кожен витік коштує найдорожче. За даними Ponemon Institute, середня вартість одного витоку даних у мобільному секторі перевищує $5 млн. Наші рішення знижують цей ризик на 80%, а в одному проєкті ми запобігли збиткам на $2 млн. В іншому кейсі ми скоротили кількість інцидентів з 50 до 2 на місяць після впровадження блокування скріншотів і буфера. Отримайте консультацію щодо вашого проєкту — ми оцінимо загрози та запропонуємо оптимальні політики.

Як захистити буфер обміну?

Буфер обміну — головна точка витоку. У 80% інцидентів витік відбувається саме через нього. Користувач копіює договір, перемикається в WhatsApp і вставляє. На Android можна відстежити копіювання через ClipboardManager.OnPrimaryClipChangedListener та очистити буфер при переході в фон:

class DlpClipboardWatcher(private val context: Context) {
    private val clipboard = context.getSystemService(ClipboardManager::class.java)
    fun onAppBackground() {
        val clip = clipboard.primaryClip ?: return
        val text = clip.getItemAt(0)?.text?.toString() ?: return
        if (dlpClassifier.isCorporateContent(text)) {
            clipboard.clearPrimaryClip()
        }
    }
}

На iOS 16+ додаток отримує сповіщення UIPasteboard.changedNotification, але прочитати чужий буфер не можна — тільки свій. Забороняємо вставку в свої поля через кастомний UITextView з перевизначеним canPerformAction(_:withSender:). Додатково використовуємо UIPasteboard.options.localOnly для обмеження синхронізації між пристроями. В одному проєкті ми заблокували копіювання номерів кредитних карток з корпоративного додатку — це запобігло шахрайству на суму більше $2 млн.

Блокування скріншотів і запису екрану

На Android скріншоти блокуються флагом FLAG_SECURE:

window.setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE)

Цей флаг також приховує контент у списку Recent Apps. Застосовуємо його тільки на екранах з чутливими даними — не блокуємо скріншоти інструкцій. На iOS немає нативного заборони, але можна виявити скріншот через UIApplication.userDidTakeScreenshotNotification і замазати екран або залогувати інцидент. Screen recording та mirroring на iOS перехоплюються через UIScreen.isCaptured — у відповідь показуємо заглушку. В одному проєкті ми налаштували детекцію screen mirroring для захисту фінансових звітів — інциденти знизилися на 90%.

Open-In та Share Sheet

Через UIDocumentInteractionController (iOS) або Intent.ACTION_SEND (Android) користувач може відкрити корпоративний PDF у будь-якому додатку. На iOS обмежуємо список через UIActivityViewController з кастомним excludedActivityTypes, але надійніше — Managed Open-In через MDM: документи з керованих додатків відкриваються тільки в інших керованих. На Android у Work Profile інтенти з робочого профілю за замовчуванням не йдуть в особистий — важливо не зламати це випадковими addCrossProfileIntentFilter. Докладніше про налаштування Managed Open-In див. у документації Apple.

Чому класифікація даних критична?

DLP без класифікації — блокування всього підряд, що викликає хаос. Розділяємо дані за рівнями:

Класифікатор може бути на основі regex (номери договорів, ІПН, IBAN) або ML-моделі (CoreML/TensorFlow Lite) для складних випадків. В одному проєкті ми впровадили класифікатор на CoreML, який визначав рівень секретності за контекстом документа — точність 96%.

Watermark на документах

Для Restricted даних додаємо динамічний watermark з username та timestamp при відображенні документів. Реалізується через кастомний PDFRenderer на Android або PDFKit на iOS з накладенням через Core Graphics. Watermark не запобігає фото, але створює аудиторний слід.

Логування DLP-інцидентів

Кожна подія (спроба скріншоту, очищення буфера, open-in) відправляється в SIEM. Логи зберігаються на сервері, а не на пристрої. Це дозволяє швидко реагувати на інциденти.

Що входить у нашу роботу

• Аудит поточного додатку на точки витоку (ADB backup, інтенти, clipboard monitoring)
• Проектування політик та матриці класифікації
• Реалізація технічних обмежень (буфер, скріншоти, Open-In, watermark)
• Тестування через pentest-сценарії (ADB backup, буфер обміну, screen recording)
• Документація для ІТ-відділу
• Навчання команди та пост-релізна підтримка

Терміни

Базовий набір (скріншоти, буфер, Open-In) — 3-5 днів. З ML-класифікатором та watermark — від 1,5 тижня. Оцінимо ваш проєкт безкоштовно — зв'яжіться для аудиту. Замовте реалізацію DLP-політик з гарантією результату. Наші інженери мають сертифікації з безпеки та досвід роботи з банківським сектором.

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