Территориально распределенная безопасность: как сделать, чтобы реально работало

Кратко о MultiDozor

Мультидозор позволяет использовать DLP-систему Solar Dozor в территориально распределенных компаниях, которые заинтересованы в контроле конфиденциальных данных во всех своих коммуникациях. Раньше компаниям для решения подобного рода задач приходилось устанавливать отдельные экземпляры DLP-системы в своих территориальных подразделениях и потом пытаться различными инженерными способами агрегировать данные коммуникаций, если такое вообще было возможно.

Архитектура MultiDozor была создана таким образом, чтобы территориально распределенную конструкцию системы можно было настроить под запросы больших компаний с самыми различными вариантами организации ИТ-инфраструктуры. Какие это могут быть варианты?

Вариант развертывания в подкластерах¹

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

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

Технически в данном случае организационные единицы² соотносятся с подкластерами. Гибкая настройка прав в модуле позволяет организовать доступ сотрудников безопасности в зависимости от их категории (квалификации, уровня доступа к информации и т.п.): к данным только своего подразделения, к данным нескольких подразделений или к данным всей компании в целом.

Вариант развертывания в компании с централизованной ИТ-инфраструктурой

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

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

Такую модель в MultiDozor можно реализовать посредством соотнесения организационных единиц с ветками организационно-штатной структуры, по принадлежности к которым система будет маркировать данные.

Комбинированный вариант развертывания с частичной централизацией и использованием подкластеров

Этот вариант предназначен для крупных компаний, данные коммуникаций которых частично находятся в одном месте и частично накапливаются в территориальных подразделениях.

Примерами являются те случаи, когда компании используют единую корпоративную почту, а трафик, поступающий в DLP-систему с endpoint-агентов, развернутых на рабочих станциях сотрудников, обрабатывается и хранится на ресурсах территориальных подразделений.

При таком варианте организационные единицы соотносятся и с подкластерами, и с ветками организационно-штатной структуры компании.

Востребованность архитектурных решений

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

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

Вариант развертывания системы в компании с централизованной ИТ-инфраструктурой заинтересовал организации финансовой сферы. Централизация данных в таких компаниях связана с тем, что они стремятся собрать свою чувствительную информацию в одном месте, а не «распылять» ее, то есть обеспечить максимально возможный контроль. Это объяснимо, так как именно банки представляют особый интерес для злоумышленников с точки зрения близости к деньгам.

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

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

Варианты развертывания в подкластерах либо одновременно в подкластерах и в центре могут быть интересны для государственных организаций, поскольку территориально они распределены по всей стране (в России 85 регионов), а каналы передачи данных у некоторых подразделений могут иметь невысокую пропускную способность.

Использование MultiDozor: практика и нюансы

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

MultiDozor позволяет выбрать конкретный филиал и исследовать ситуацию исключительно в нём: активность филиальных сотрудников безопасности, коммуникации и данные изучаемого филиала, правила политики безопасности и инциденты филиала. По выбранному филиалу можно построить отчетность. Также можно исследовать коммуникации на предмет межфилиального взаимодействия, тут могут обнаружиться инциденты, плохо заметные в разрозненных DLP-системах, связанные с межфилиальными конфликтами или, и того хуже, – с межфилиальным сговором.

По результатам анализа ситуации в филиалах офицер безопасности из центра с помощью MultiDozor может корректировать политики безопасности в отношении филиалов, а также устанавливать и настраивать endpoint-агенты применительно к каждому филиалу в зависимости от уровня риска.

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

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

Расширение возможностей

За 2 года жизни MultiDozor получил большое развитие в результате множества пилотов и внедрений в самых разных организациях. Чем же прирос модуль за это время?

Локальный веб-сервер

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

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

Так у нас появилась задача локализовать интерфейс системы в филиалах, то есть сделать локальные точки входа в MultiDozor. При этом потребность в доступе к данным всей компании или части филиалов через единую точку входа никуда не делась.

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

Рис. 1. Схема реализации MultiDozor с общим и локальным интерфейсом

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

MultiCrawler

В рамках усовершенствования MultiDozor в территориально-распределенный режим работы был также переведен discovery-модуль DLP-системы Solar Dozor – Dozor File Crawler.

Модуль Dozor File Crawler позволяет сканировать файловые и облачные хранилища, а также исторически накопленные почтовые сообщения. Кроме того, модуль позволяет строить карту сети и делает это в инкрементальном режиме, то есть пользователь может видеть изменения, произошедшие с данными с момента их прошлого сканирования.

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

Чего не хватало Dozor File Crawler по мнению заказчиков? Во-первых, – настройки задач под различные филиалы, так как угрозы безопасности и, соответственно, потребности в инвентаризации данных для разных подразделений различны. Во-вторых, – представления карты сети в разрезе филиалов, так как в крупных территориально-распределенных компаниях возникают сложности при анализе всего массива данных, поступающего от Dozor File Crawler.

В итоге в Dozor File Crawler появилась возможность настраивать задачи по сканированию файловых ресурсов, сети, архива корпоративной почты, облачных хранилищ в разрезах выбираемых организационных единиц, то есть физических ресурсов. Кроме того, теперь модуль умеет работать с построенной картой корпоративной сети компании в разрезах организационных единиц.

Технически это было реализовано так, что управляющий модуль Master Dozor File Crawler размещается на общих ресурсах, а задачи по сканированию передает как на общие ресурсы (если это необходимо), так и на служебные модули в подкластерах организационных единиц (Рис. 2).

Рис. 2. Схема реализации Multi File Crawler

MultiUBA

Dozor User Behavior Analytics (UBA) – модуль в составе DLP Solar Dozor, который по сути является самообучаемой системой анализа поведения сотрудников. Dozor UBA используется многими клиентами для мониторинга и выявления поведенческих отклонений, детектирования аномалий, предотвращения и расследования нарушений, обнаружения рисков, в том числе ранее неизвестных.

Один из заказчиков в банковской сфере тестировал модуль Dozor UBA в территориально-распределенном режиме. В процессе пилотирования выяснилось, что у заказчика есть отдельное территориальное подразделение, которое занимается только техническими вопросами, и есть операционное подразделение, которое активно взаимодействует с внешним миром. У обоих – принципиально разный характер коммуникаций, и сравнивать поведение их сотрудников некорректно. Также по итогам пилота стало очевидным, что необходимо соотносить результаты анализа поведения сотрудников по времени суток (утро, день, вечер, ночь) в филиалах в Москве и, скажем, в Петропавловске-Камчатском, где, как известно, всегда полночь (ЛОЛ, на самом деле только когда в столице полдень).

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

Технически это было реализовано так, что информация о сообщениях обрабатывается в каждом подкластере организационной единицы, после чего передается модулю Dozor UBA на общих ресурсах, где производятся расчеты поведенческих показателей с учетом принадлежности сотрудников к тому или иному филиалу (Рис. 3).

Рис. 3. Схема реализации MultiUBA

Выводы

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

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

1 - Подкластер – совокупность локальных информационных ресурсов, узлов системы в подразделении компании. Узлы подкластера могут обращаться как к хранящимся локально данным Solar Dozor, так и к общим ресурсам.
2 - Организационные единицы (ОЕ) – термин в MultiDozor, описывающий подразделения в составе территориально-распределенных компаний. ОЕ могут быть описаны через соответствующие им подкластеры, через ветки организационно-штатной структуры либо в комбинации – через подкластеры и ветки оргструктуры.