Конфиденциальный контракт, скопированный в буфер обмена, оказывается в личном 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-политик с гарантией результата. Наши инженеры имеют сертификации по безопасности и опыт работы с банковским сектором.