Как мы реализовали MultiDozor, чтобы не получать «среднюю температуру по больнице» в территориально распределенных компаниях

Среди заказчиков нашей DLP-системы немало компаний, у которых есть филиалы в разных концах страны. И чтобы защитить бизнес от утечек информации, от корпоративного мошенничества и других подобных проблем, таким организациям недостаточно внедрить DLP-систему только в головном офисе. Инциденты в филиалах тоже нужно мониторить. Но при отдельных инсталляциях в каждом филиале было проблематично получить полную картину об общем уровне безопасности по компании в целом. К отсутствию сквозного мониторинга добавляем нехватку в регионах квалифицированных ИТ- и ИБ-кадров, узкие и дорогие каналы связи. В прошлом году мы дополнили свою систему модулем для территориально распределенных организаций MultiDozor. Сегодня хотим рассказать о технических и архитектурных аспектах его реализации — как это помогло нашим пользователям в решении их задач.

Было — стало

До того, как мы интегрировали в свою DLP-систему модуль MultiDozor, у компаний с филиальной сетью было два варианта использования системы защиты от утечек. Самый банальный — установить систему в каждом филиале отдельно. Ясно, что в такой ситуации возможности централизованного мониторинга резко ограничены. Например, поиск по всем филиалам невозможен, единые политики быстро не настроить. По сути, это как мониторить несколько разных компаний. Безопасникам приходилось сводить отчеты воедино вручную. И отчитаться перед руководством о ситуации во всем холдинге в реальном времени они тоже не могли.

Второй вариант — одна инсталляция Solar Dozor и группа инженеров с бубном, которые «наколдуют» так, чтобы одна система стояла на нескольких разных площадках. Реализовать возможно, но рабочим такой вариант можно назвать с натяжкой. Когда сервисы начинают обмениваться огромными объемами данных, гоняя трафик через всю страну, никакого канала не хватит. Особенно если речь об отдаленных уголках нашей необъятной Родины. А нестабильность одного филиала может повлиять на всю систему.

Поэтому первая большая техническая задача, которую мы решали, — сделать так, чтобы система работала в филиале более или менее замкнуто, но при этом была частью единой сети мониторинга. То есть в филиалах пользуемся локальными ресурсами и не ходим в центр без особой необходимости. Если мы храним архив в филиале, то данные там так и лежат, пока кто-нибудь из центра их не запросит при просмотре или поиске. Это самая простая схема с физическим разделением данных.

Однако есть среди наших заказчиков и такие компании, у которых либо все данные лежат в центральном хранилище, либо часть данных находится в филиалах, а часть — в центре. Первый вариант требовал создать механизм логической «нарезки» данных по филиалам. Второй — механизм еще более сложной фильтрации. Чуть ниже поговорим подробнее о каждой из трех архитектурных схем.

Все три варианта реализации системы подразумевают единую точку входа в интерфейс. Администраторы DLP как в головном офисе, так и в филиалах могут через эту точку пользоваться функциями и ресурсами в зависимости от тех прав доступа, которые у них есть. Например, система позволяет настроить, чтобы админ филиала мог работать только с теми данными, которые относятся к его предприятию. При этом теперь заказчик, у которого были отдельные установки Solar Dozor, может мониторить действия сотрудников во всей компании, проводить сквозные расследования и централизованно управлять едиными для всей организации политиками, настраивая правила под конкретные филиалы.

Как настраивали фильтрацию при разных схемах

Давайте остановимся на схемах внедрения и на том, как мы настраивали фильтрацию в разных ситуациях. У нас три варианта:

• хранение и обработка в филиале;

• хранение и обработка данных в центре;

• часть данных хранится и обрабатывается в филиале, часть — централизованно.

С первой схемой особых сложностей нет. Здесь задача на уровне конфигурации. Нужно сделать так, чтобы система в филиале использовала локальные ресурсы и без необходимости не ходила в другие филиалы. Для этого она формирует конфигурационные файлы, прописывая соединения между сервисами с учетом подкластеров, в которых те размещаются. Это значит, что один сервис, которому необходимо обращаться к другому сервису, получит параметры подключения к экземплярам нужного сервиса внутри своего подкластера, если такие есть. Если в своем подкластере нужного сервиса нет, то будут прописаны параметры подключения к экземплярам на узлах вне подкластеров. И ни в каких случаях он не узнает об экземплярах этого сервиса в других подкластерах, потому что такие соединения в MultiDozor запрещены.

Со второй схемой — когда данные филиалов находятся в общем хранилище — на уровне конфигурации уже не разобраться. Нам нужен механизм, который позволит распределить эти данные между филиалами, чтобы каждый видел только свое. Прежде всего, принадлежность перехватов определяется по подкластеру, в котором они были получены системой. А перехваты, которые получены сервисами Solar Dozor на общих ресурсах, то есть вне подкластеров, распределяются согласно организационно-штатной структуре предприятия. Плюс пришлось прописать дополнительные правила, потому что не всегда понятно, кому принадлежит перехват. Например, когда речь не о переписке между сотрудниками, а о письмах от каких-то сторонних сервисов. В случае коммуникации между филиалами перехват, осуществленный на общих ресурсах, будет принадлежать каждому из них.

Третья схема — это комплексный вариант, когда к логической «нарезке» данных из второй схемы добавляем фильтрацию по территориальному признаку из первой схемы. Мы разделили хранилища на два вида — хранилище филиала и общие ресурсы. Запросы и ограничения прав доступа к этим хранилищам работают по-разному. В первом случае мы считаем, что все, что хранится в филиале, принадлежит филиалу. Общие ресурсы устроены так, что все, профильтрованное в филиале, относится к нему. А все, что профильтровано на общих ресурсах, делится между филиалами с учетом организационно-штатной структуры.

В общем, благодаря опыту реализации модуля MultiDozor мы теперь способны осилить любые инфраструктуры заказчика.

Как реализован быстрый поиск в MultiDozor

Быстрый поиск в Solar Dozor работает на базе движка Elasticsearch. До появления MultiDozor у нас был один кластер Elasticsearch — один узел или несколько узлов, но они все находились на одном уровне. То есть мы могли к любому из них сделать запрос. Сервер сам связывался с этими узлами и собирал от них ответы. Но при этом все они должны были находиться близко друг к другу. Если же они были разбросаны по стране, конструкция получалась не очень рабочая. Ведь Elasticsearch сам балансирует запросы. Мы не можем управлять тем, где лежат данные и какой узел будет обрабатывать наш запрос. И если взять один узел и отнести куда-то далеко, получится совершенно непредсказуемо: поиск будет быстро работать то на ближайшем узле, то где-то далеко. То есть Elasticsearch подходит для ситуации, когда много узлов, но они нужны, чтобы масштабироваться и повышать скорость, а не для того, чтобы разнести эти узлы географически и делать запросы. На такое этот движок не рассчитан.

Поэтому в случае с MultiDozor в каждом филиале мы делаем свой кластер Elasticsearch – это может быть одна или несколько машин, в зависимости от того, сколько есть ресурсов. А затем используем такую фичу, как мультикластерный поиск: на центральный сервер Elasticsearch мы отправляем запрос о сборе данных с определенных филиалов. Он делает подзапрос на каждый филиал, выбирает оттуда часть данных, собирает их на центральном узле, там объединяет и отдает в интерфейс. Это в случае, если данные филиала хранятся локально (см схему ниже).

По второй схеме, когда хранилище общее, все перехваты сбрасываются на центральный сервер Elasticsearch — в один кластер. В поисковых запросах учитываем, какие данные поступили из какого филиала, и считаем, что если что-то прилетело из конкретного филиала, то это его данные. При построении запросов, при расчете прав доступа мы учитываем принадлежность данных и показываем результаты в соответствии с правами доступа конкретного администратора. Он увидит данные только своего филиала. На сегодняшний день это уникальная для DLP-систем реализация.

Хотя, конечно, проще, когда данные филиала хранятся в нем самом. Одна из основных причин — экономия каналов. Если у нас очень много перехватов в филиале, удобнее и быстрее сложить их там, чем гнать в центр.

Как реализован расширенный поиск в MultiDozor

В отличие от быстрого поиска здесь мы не используем сторонних решений. Если говорить об обычной инсталляции Solar Dozor, то расширенный поиск реализован у нас следующим образом. Есть веб-сервер, который принимает поисковый запрос от пользователя. Есть сервер архива, который преобразует этот запрос в SQL и ищет сообщения в базах данных. Они могут быть разными, поэтому сервер архива готовит свой SQL-запрос под каждую БД. Там запросы исполняются, базы данных отдают серверу архива результаты, а он объединяет их в итоговый отчет, возвращает веб-серверу, и тот показывает его пользователю.

В случае с MultiDozor архитектура получается сложнее. В каждом филиале у нас появляется подкластер системы. Если сообщения хранятся централизованно, то отличие только в том, что в каждом подкластере есть инструмент, который фильтрует и архивирует данные, чтобы потом сложить в хранилище. Сам же поиск работает так, как будто это обычная инсталляция Solar Dozor.

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

Если у заказчика смешанная схема хранения сообщений, то отличие в том, что к серверу на центральном узле тоже подключены базы данных. И при поисковом запросе он обращается как к своим БД, так и к серверам архива в подкластерах.

Технических сложностей с реализацией расширенного поиска в MultiDozor у нас не возникло. Нам пришлось только развить структуру отчетов. Изначально они не предполагали еще одного этапа объединения. Мы улучшили API, который использовался для немультидозорных отчетов, так, чтобы клиентом этого API мог стать сервер верхнего уровня. Благодаря этому отчеты, которые получаются, можно объединить еще один раз в итоговый мультидозорный отчет.

Сложности с Endpoint-агентом

Еще одним очевидным преимуществом реализации модуля MultiDozor стало решение проблемы с Endpoint-агентами в территориально распределенных компаниях в двух направлениях — получение перехватов и управление самими агентами.

Что касается первого, в Solar Dozor используется набор серверов, который может принимать перехваты. Раньше, до MultiDozor, агенту просто отправлялся список всех серверов, и он сам случайным образом выбирал, на какой из них ему сдавать перехват. И если DLP-система устанавливалась на множество узлов, а Endpoint-агенты находились в разных частях страны, они могли гонять перехваты не туда. У нас, конечно, были инженерные решения — разными способами мы запрещали это делать и пытались загнать данные с агентов только на «свои» серверы. В частности, приходилось вручную переконфигурировать систему, чтобы ограничить агенту список серверов. Но это скорее временная подпорка, а не постоянное решение. В случае с MultiDozor конфигурация генерируется и обновляется автоматически в зависимости от заданной конфигурации в подкластере.

А что же с управлением агентами? В этом случае нужно было решить проблему с установкой и обновлением агентов в территориально распределенной организации. И здесь мы столкнулись со сложностями. В частности, с отсутствием прав доступа: в подавляющем большинстве случаев Windows на корпоративном компьютере в филиале просто не позволит нам установить или обновить Endpoint-агент извне. Нужно, чтобы это происходило во внутренней сети. Установить агент можно двумя способами — вручную и средствами самой DLP-системы. Но второй способ требовал доступа из центра к рабочей станции с правами администратора. Без него админам на местах нужно было самостоятельно устанавливать Endpoint-агенты.

В случае с MultiDozor в каждом филиале есть свой сервер Solar Dozor, на который из центра один раз загружается агентский модуль или его обновление, и сервер самостоятельно устанавливает и обновляет агенты на рабочих станциях внутри сети. Заодно такая схема помогает решить и проблему пропускной способности каналов. Ведь если разворачивать агент одновременно на большое количество рабочих мест, скачивания дистрибутива могут довольно сильно загружать канал.

Выводы

Для территориально распределенных заказчиков MultiDozor стал давно желанным решением. Одно из первых внедрений, итоги которого уже можно подвести, произошло в нефтесервисной компании с 12 подкластерами в двух странах. Удерживать внимание на всех 12 филиалах одновременно, к тому же в режиме реального времени, крайне сложно, поэтому для компании важна возможность сфокусироваться на отдельных филиалах. На рабочем столе сотрудник безопасности ежедневно мониторит ленту событий, затем выбирает нужный подкластер (чаще всего тот, в котором возникает больше всего инцидентов безопасности) и получает оперативные данные об обстановке в нем более точечно.

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

Автор: Михаил Остапчук, ведущий аналитик «Ростелеком-Солар»