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

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

Хотелось бы рассказать о консолидации чуть подробнее…

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

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

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

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

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

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

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

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

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

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

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

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

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