Как организована техническая сторона защиты данных от утечек

Руслан Рахметов, Security Vision

Публикация персональных данных в сети или передача конкурентам конфиденциальной информации – это результат случайных ошибок или злого умысла. Вне зависимости от причин подобных утечек последствия подвергают опасности людей и компании, которым впоследствии перестают доверять. Поэтому защита данных от утечек – задача, которая будет актуальной, пока существуют люди и компании. Решается она различными организационными мерами и применением специальных технических средств.

Организационные методы основаны на рекомендациях и требованиях соответствующих законов. Так, например, персональные данные защищаются согласно требованиям 152-ФЗ (на территории Российской Федерации) и GDPR (если речь идёт о данных субъектов, которые находятся на территории стран Евросоюза, даже если эти данные обрабатываются в других государствах), а другие типы конфиденциальных данных определяются внутренними нормативными актами и установлением режима конфиденциальности (ноу-хау, коммерческая тайна), который работает по аналогии с патентным и авторским правами.

Технические средства тоже бывают разные: одни из них обеспечивают мониторинг трафика (CMS – Content Monitoring System), другие – проведение расследований по уже произошедшим утечкам (ILD – Information Leakage Detection) и последние, но не последние по важности, предназначены для защиты траффика «на лету» (DLP).

В этой статье пойдёт речь о том, как организованы DLP-системы, какие задачи они выполняют и том, какие каналы передачи данных можно защитить с их помощью.

DLP – это общее название для различного программного обеспечения, которое обеспечивает мониторинг и защиту. Сам термин расшифровывается как «предотвращение утечек данных» (Data Leakage Prevention) или «защита от потери данных» (Data Loss Protection).

Если вмешиваться в передачу данных не входит в ваши планы, то DLP-система устанавливается параллельно исходящему трафику и работает в режиме «зеркалирования». А если вы решаете задачу защиты данных на лету, нужно обеспечить подачу трафика через DLP-систему, таким образом DLP будет работать в режимах «карантин» и/или «вразрыв».

В зависимости от того, как происходила эволюция DLP-системы определённого вендора, можно заметить особое внимание к конкретным каналам. Так, например, InfoWatch Traffic Monitor эволюционировал из средства контроля сетевых узлов, защита данных на агенте появилась уже в процессе обновления; SearchInform КИБ в своих первых версиях контролировал трафик именно на уровне хоста; Google DLP обеспечивает защиту данных только внутри своих веб-сервисов в рамках специальной корпоративной подписки.

Современная DLP-система чаще всего является клиент-серверным приложением:

· Часть ПО работает централизованно (СЕРВЕР), что позволяет контролировать сетевой и почтовый трафик через соответствующие шлюзы (прокси- и почтовые сервера).

· Вторая часть устанавливается на хосты пользователей (АГЕНТ), чтобы обеспечить контроль подключения физических устройств, буфера обмена, текста, вводимого с клавиатуры, запуск приложений и другие каналы, которые можно контролировать только на этом уровне.

Благодаря подобной архитектуре можно контролировать разные пути передачи данных, от удалённого подключения через VPN и терминальные сессии, до организации DMZ и копирования данных через устройства, подключённые физически. Мы проанализировали решения различных вендоров и составили общий список каналов передачи данных, которые им удаётся эффективно защищать.

Данные при передаче (Data in motion):

·  Сетевой траффик HTTP, FTP, SMB;
·  Почтовый трафик POP3, IMAP4, SMTP;
·  Печать документов через локальные или сетевые принтеры;
·  Передача на внешние устройства USB, MTP и другие.

·  Документы и файлы на рабочих станциях;
·  Данные на серверах и в БД.

· Запуск приложений;
· Передача данных через приложения;
· Ввод текста с клавиатуры и вставка из буфера обмена.

Чаще всего DLP работает на защиту определенной зоны, например периметра вашей компании, но благодаря интеграциям защиту можно вывести на новый уровень – за пределы периметра. Текущий обзор мы завершим способами выхода за пределы возможностей DLP «из коробки».

1) Можно анализировать открытые публикации в социальных сетях («Крибрум», https://www.kribrum.ru/technology/) на предмет наличия в них конфиденциальных данных, которые не должны быть опубликованы;

2) Можно организовать анализ печатаемых на твёрдые носители документы без установки DLP-агента на рабочую станцию – централизованно с сервера управления печатью (Konica Minolta Business Solitons Russia, https://www.infowatch.ru/company/presscenter/news/17119);

3) Можно также интегрировать MDM-решения, чтобы обеспечить контроль корпоративных данных на личных мобильных устройствах (технология BYOD, https://habr.com/ru/post/281463/);

4) Даже при использовании облачных сервисов (например, Яндекс 360 или Office 365) данные внутри них можно анализировать в on-premise DLP при помощи интеграций или нативно (Google, https://cloud.google.com/dlp).

Технически, почти любой канал передачи данных можно направить на анализ в DLP, для этого используются:

·  встроенные возможности систем (из списка выше);
·  средства разработки коннекторов SDK API;
·  low-code инструменты для интеграции.

Существующие DLP-системы могут организовать мониторинг и блокировку передачи данных за пределы организации, для этого ПО устанавливается на сетевые узлы и рабочие станции сотрудников. А возможности «из коробки» расширяются за счёт интеграций и могут быть выведены за пределы привычного защищаемого периметра.