Реализация 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)

Этот флаг также скрывает контент в switcher (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 с username и timestamp при отображении документов. Это не предотвращает утечку через фото экрана, но создаёт аудиторный след. Реализуется через кастомный PDFRenderer на Android или PDFKit на iOS с наложением слоя через Core Graphics.

Логирование DLP-инцидентов

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

Этапы работы

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

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