Реалізація DLP (Data Loss Prevention) політик у мобільному додатку

Реалізація DLP (Data Loss Prevention) політик у мобільному додатку

DLP у мобільному контексті — це не антивірус і не брандмауер. Це набір обмежень на те, що користувач може робити з корпоративними даними: копіювати у буфер обміну, робити скриншот, пересилати в особистий месенджер, завантажувати на особистий хмарний диск. Без цих обмежень MDM втрачає сенс.

Де дійсно витікають дані

Буфер обміну — найпоширеніша точка витоку. Користувач копіює корпоративний контракт, перемикається в 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:).

Скриншоти. На Android заблокувати через WindowManager.LayoutParams.FLAG_SECURE:

// У Activity або Fragment
window.setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE)

Цей прапор також приховує вміст у перемикачі Recent Apps — важливо для конфіденційних екранів. Не застосовувати глобально: користувачі скаржаться, що не можуть робити скриншоти інструкцій. Ввімкніть лише на екранах із чутливими даними.

На iOS немає рідного запобігання скриншотам. Можна перехопити подію:

NotificationCenter.default.addObserver(
    self,
    selector: #selector(screenshotTaken),
    name: UIApplication.userDidTakeScreenshotNotification,
    object: nil
)

І в результаті — замазати екран, вийти з режиму, залогувати інцидент. Але не запобігти.

Screen recording та screen mirroring — окрема історія. На iOS UIScreen.isCaptured дозволяє виявити запис через AirPlay чи ReplayKit та замінити вміст на заглушку.

Open-In та Share Sheet

Найбільш болісна точка — UIDocumentInteractionController на iOS та Intent.ACTION_SEND на Android. За замовчуванням користувач може відкрити корпоративний PDF у будь-якому сторонньому додатку.

На iOS обмеження здійснюється через UIActivityViewController із користувацьким excludedActivityTypes — але список потрібно підтримувати вручну, і нові додатки автоматично не потрапляють. Правильний корпоративний підхід — Managed Open-In через MDM-профіль: документи з керованих додатків відкриваються лише в інших керованих додатках.

На Android — через DevicePolicyManager з Work Profile. Інтенти з робочого профілю за замовчуванням не переходять у особистий. Це стандартна поведінка, не ломайте її — просто не ломайте її випадково через addCrossProfileIntentFilter.

Класифікація даних

DLP без класифікації — обмеження скрізь і завжди, що дратує користувачів. Потрібно розрізняти:

Класифікатор може бути простим — regex за паттернами (номер контракту, ІНН, IBAN) — або ML-based через CoreML / TensorFlow Lite для складніших випадків.

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

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

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

Кожна DLP-подія йде в SIEM: спроба скриншота на захищеному екрані, спроба open-in у незатверджений додаток, очищення буфера обміну. Логи зберігаються на сервері, не на пристрої.

Етапи роботи

Аудит існуючого додатку на точки витоку → проектування політик та матриці класифікації → реалізація технічних обмежень → тестування через pentest-сценарії (скриншот, ADB backup, буфер обміну) → документація для IT.

Терміни: 3–5 днів на базовий набір (скриншоти, буфер, open-in). З ML-класифікатором та watermark — від 1,5 тижня.