Конфіденційний контракт, скопійований у буфер обміну, опиняється в особистому 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%.
| Платформа | Блокування скріншоту | Виявлення запису екрану |
|---|---|---|
| Android | FLAG_SECURE | Відсутнє (можна детектити через MediaProjection) |
| iOS | Немає нативного | UIScreen.isCaptured + UIScreen.capturedDidChangeNotification |
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 без класифікації — блокування всього підряд, що викликає хаос. Розділяємо дані за рівнями:
| Тип даних | Рівень | Обмеження |
|---|---|---|
| Публічні матеріали | Public | Немає |
| Внутрішні документи | Internal | Буфер тільки між корп. додатками |
| Персональні дані клієнтів | Confidential | FLAG_SECURE + без Open-In |
| Фінансові дані | Restricted | Всі обмеження + watermark |
Класифікатор може бути на основі 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-політик з гарантією результату. Наші інженери мають сертифікації з безпеки та досвід роботи з банківським сектором.