Безопасность Корпоративной Информации
 

Как устроена консолидация архивов в DeviceLock DLP

Не так давно мы выпустили новую минорную версию 8.3.75005 программного комплекса предотвращения утечек данных DeviceLock DLP и помимо других улучшений, включили в нее довольно полезную для крупных компаний функцию консолидации данных с серверов хранения.

Для начала немного о том, как устроен сбор и хранение перехваченных данных в DeviceLock DLP. Являясь агентским решением по предотвращению утечек информации, DeviceLock DLP осуществляет перехват, анализ и разрешение/запрещение передачи данных непосредственно на компьютерах пользователей при помощи агентов. Помимо перехвата, анализа и принятия решения о разрешении/запрете передачи, агенты также могут (если это задано политикой) накапливать данные аудита и теневого копирования (копию передаваемой пользователями информации).

Для централизованного хранения и последующего пост-анализа накопленных агентами данных (например, построения отчетов, поиска по архиву и т.п.) используется сервер хранения DeviceLock Enterprise Server (DLES). Таких серверов в организации может быть установлено неограниченное число (мы не ограничиваем их количество лицензией), что позволяет равномерно распределять нагрузку на отдельные сегменты сети и минимизировать время сбора данных с агентов. Для агентов может быть задано несколько серверов DLES и указаны правила выбора сервера при передаче накопленных данных в архив. Каждый DeviceLock Enterprise Server подключается к SQL-серверу и хранит свои данные в отдельной базе данных. Более того, к одному SQL-серверу может быть подключено несколько серверов хранения.

Сбор и хранение перехваченных данных в DeviceLock DLP

Если организация имеет несколько филиалов, чаще всего используется схема, когда в каждом филиале установлен свой сервер (или несколько серверов) хранения, а в центральный офис накопленные данные стекаются по заданному расписанию (раз в день, неделю, т.п.).

До выпуска этого обновления репликация данных могла осуществляться средствами SQL-сервера, что было не совсем хорошо с точки зрения общего удобства настройки комплекса.

Нетривиальность репликации особенно проявлялась в ситуации, когда несколько серверов хранения подключались к одному SQL-серверу.

Сейчас мы предлагаем использовать намного более простую в настройке и использовании функцию консолидации, при которой репликация данных по расписанию выполняется исключительно встроенными средствами DeviceLock Enterprise Server.

Покажу на «живом» примере базовую конфигурацию консолидации накопленных данных с четырех серверов хранения на главный сервер.

Консолидация накопленных данных на главный сервер

На схеме выше показано, что два сервера (Test28-w10x64 и PC-55OSI) подключены к одному SQL-серверу (SQL2), тогда как другие два сервера (VSamsonov-PC и mamaev-pc) подключены каждый к своему SQL-серверу (SQL1 и SQL3 соответственно). Репликация данных будет выполняться на главный сервер DLSRV, подключенный к SQL-master.

Для задания расписания и указания мастер-сервера, куда должны реплицироваться данные, на каждом из «нижестоящих» серверов Test28-w10x64, PC-55OSI, VSamsonov-PC и mamaev-pc необходимо задать параметры консолидаци.

Задание параметров консолидаци

Помимо всего прочего, можно дополнительно указать, что именно неоходимо реплицировать (какие журналы), копировать ли данные или переносить их, шейпить ли сетевой канал или отдать под консолидацию его целиком.

После успешного установления соединения между «нижестоящим» и главным сервером, в интерфейсе последнего появится статистика консолидации.

Статистика консолидации

Увидеть собранные данные можно, как обычно, в стандартном просмотрщике соответствующего журнала. Например, для журнала теневого копирования это будет <выглядеть так:

Журнал теневого копирования

Изначальный сервер, собравший данные с агентов, тут отображается в колонке «Сервер».

Отдельно хочу отметить, что «уровень вложенности» консолидации не ограничен. Если будет необходимо реплицировать данные с DLSRV куда-то еще «наверх», то просто в настройках консолидации у DLSRV надо будет прописать его «вышестоящий сервер». И так практически до бесконечности.

Автор: Ашот Оганесян