Архив бизнес-коммуникаций нужен службе безопасности для расследования инцидентов, анализа уязвимостей, сбора доказательной базы или проверки новых политик безопасности. Обычно архивы собираются в процессе работы DLP-системы в хранилище данных, тип которого зависит от применения DLP. Поэтому вопрос о принципах хранения данных в DLP стоит учитывать при выборе решения. Давайте разберемся, насколько важен тип хранилища на практике и как от него зависят возможности DLP-системы.
1. Как работают DLP-системы разных поколений?
3. Практика применения решений DLP на основе реляционных СУБД и NoSQL
Как работают DLP-системы разных поколений?
Традиционно работа с DLP велась по такой методике: определение возможных инцидентов безопасности на предприятии, настройка инцидентных политик безопасности, аппаратно-программный комплекс перехватывает все объекты коммуникаций, которые под эти политики подходят. Для такой задачи не нужен большой архив, поэтому классические DLP-системы построены на реляционных СУБД.
С развитием культуры информационной безопасности от DLP-систем стали требовать не только защиту от утечек, но и инструменты для расследования инцидентов, которые все-таки произошли. Но если классическая DLP не среагировала на инцидент, значит, он не был описан политиками безопасности и информация о нем в архиве не сохранилась. Поэтому многие пользователи стали настраивать дополнительные политики для записи максимального количества данных. Традиционная DLP не предусматривала такого формата использования, и работа с системой усложнялась по мере накопления перехваченной информации. При этом поиск по базе замедлялся с увеличением ее объема. Необходимый инструментарий для аналитической работы с архивом отсутствовал, а ретроспективный анализ коммуникаций по инциденту по-прежнему приходилось делать вручную. Новое поколение DLP-систем основано на принципиально другой логике. Политики безопасности предназначены для оперативного реагирования на инциденты и их предотвращения. При этом автоматически собирается полный архив бизнес-коммуникаций для возможности проведения ретроспективного анализа и обогащения информации о выявленных инцидентах. Такой подход потребовал использования другой модели хранения данных — нереляционной, или NoSQL.
Технологии хранения в DLP
Основные требования к хранилищам данных: простота, отказоустойчивость, масштабируемость, производительность, совместимость и возможность получения аналитических срезов данных. Хранилища в DLP могут быть реализованы на различных СУБД, в зависимости от того, какие из параметров в приоритете.
Чаще в DLP системах используются хранилища, основанные на реляционных СУБД:
- Реляционная СУБД — система управления реляционной базой данных, в которой вся информация представлена в виде объектов, располагающихся в таблицах определенной структуры. Каждый объект состоит из свойств, связанных между собой ключами. При этом некоторые свойства могут находиться в отдельных таблицах. Это математическая модель хранения и распределения данных, которая появилась еще в 1970 годах.
Традиционные СУБД и сегодня справляются со своими функциями в приложениях любой сложности, но требуют грамотной настройки и администрирования и имеют ряд ограничений, связанных со структурой хранения данных. Ограничения реляционной модели: недостаточная производительность при работе со сложно структурированными объектами и трудоемкое горизонтальное масштабирование.
Структура хранения данных в реляционных базах данных не позволяет наращивать аппаратную мощность при сохранении ее свойств на должном уровне. Результатом увеличения количества задействованных под базы данных серверов станет возросшая трудоемкость управления БД и существенное удорожание стоимости хранения. До сих пор многие DLP-системы имеют в своей основе реляционные СУБД, что приводит к сложностям при хранении и обработке больших объемов информации и снижении производительности системы при увеличении поступаемых данных.
- NoSQL — нереляционные базы данных, в которых весь объем информации представлен без схемы, в частности, в виде пары «ключ — значение», где значение — это набор всех свойств объекта. NoSQL позволяет быстро записывать данные и обращаться к ним и легко масштабироваться горизонтально. Такая модель дает больше гибкости при работе с разными типами объектов. NoSQL базы данных не используют общий формат запроса, такой как SQL, применяя собственную систему запросов.
Технология нереляционного хранения данных за счет высокой скорости обработки больших объемов неструктурированных данных позволила значительно увеличить производительность работы DLP-систем и открыла возможности для полноценного ретроспективного анализа данных, накопленных за все время работы системы. Максимально полные архивы событий дали возможность выявлять аномалии, не нарушающие, на первый взгляд, существующие политики безопасности.
Практика применения решений DLP на основе реляционных СУБД и NoSQL
Количество хранимых данных напрямую влияет на производительность DLP-системы. Любой поисковый запрос, построение отчета, выгрузка — является запросом в базу данных или даже набором этих запросов.
Когда ресурсов для анализа данных требуется немного, несколько десятков ГБ, — нужные функции DLP будут работать быстро. Если же мы говорим о крупной корпоративной сети, использование классических баз данных может привести к серьезным замедлениям в работе — построение сложных отчетов по действительно большому количеству данных, измеряемых в сотнях ТБ и даже ПБ, может занимать от нескольких часов до суток.
С развитием сетей передачи данных, инструментов взаимодействия персонала, с ростом информатизации бизнеса появляется потребность в масштабировании хранилищ DLP.
Для автоматизации рутинных задач специалиста информационной безопасности, например построения графа взаимодействия сотрудников или карты распространения информации, нужно хранить большие объемы разнообразной информации и быстро их обрабатывать.
Технические ограничения реляционных баз данных, в принципе, преодолимы, но это требует финансовых инвестиций и постоянной работы высококвалифицированных администраторов с комплексом баз данных. Нереляционные хранилища решают вопросы масштабирования DLP, увеличивают скорость доступа и записи данных. Некоторые NoSQL-хранилища созданы разработчиками DLP самостоятельно на open-source решениях. Это положительно отражается на стоимости и удобстве владения системой, так как не нужно платить за сторонние лицензии и зависеть от производителя СУБД в вопросах обновления и технической поддержки.
Часто можно услышать, что хранение и обработка больших данных — дорогостоящий процесс. Однако в случае использования NoSQL-хранилищ в DLP это не так. На рынке существуют системы хранения, в которых могут применяться обычные SATA-диски, к тому же отказ от проприетарных СУБД позволяет существенно сэкономить на лицензировании. Решения такого класса доступны не только крупному, но и среднему бизнесу.
Выводы
При выборе DLP-системы важно учитывать, как организовано хранение, а также в каких условиях и для решения каких задач вы планируете ее использовать.
Если система нужна для контроля небольшого штата сотрудников или количество собираемой информации не превышает 1 ТБ в месяц, то использовать можно как системы на реляционных СУБД, так и системы на основе NoSQL-хранилища. По цене и функциональности подойдет любой из вариантов.
Если же планируется внедрять DLP в крупную сеть с большими объемами трафика для контроля тысячи и более рабочих мест, а критерии выбора решения — производительность и стоимость системы, то DLP-система, основанная на нереляционном или гибридном (когда используются оба подхода для хранения данных) хранилище, — обоснованный и рациональный выбор.
Лучше заранее обсудить с интегратором организацию хранения перехватываемых данных. Это поможет найти баланс между техническими и организационными мерами при внедрении, увеличить производительность системы и оптимизировать стоимость владения DLP.
