Стоимость корпоративного внедрения DLP-систем формируют не только лицензии на ПО, но и нужное для него оборудование. С учётом поступательного роста цен на «железо» вендоры прикладного софта оптимизируют свои решения, чтобы сделать их доступнее за счёт меньших требований к ресурсам. О своём опыте такого рода рассказывает «СёрчИнформ».
- Введение
- Проблемы оптимизации DLP-систем
- Оптимизация ПО на уровне архитектуры
- Оптимизация ПО на уровне хранения данных
- Другие способы снизить ресурсоёмкость внедрения
- Выводы
Введение
В 2022 году рынок ИТ упал на 8 %, в основном в сегменте оборудования. С уходом иностранных производителей закупать его стало сложнее, необходимые мощности оказались в дефиците — а за дефицитом подтянулось перманентное повышение цен. Вендорам это не на руку: стоимость любого внедрения для заказчика увеличивается в разы, сколько бы ни стоили лицензии, а заказчикам свойственно экономить. В этих условиях выигрывают те, чей софт требует меньше дополнительных затрат — на оборудование, сопутствующее ПО и прочее.
Оптимизацией своих решений в «СёрчИнформе» занялись давно, и результата добились. В этом материале — о том, какие основные «боли» есть у ПО в сегменте внутренней ИБ и как вендор с ними разбирался.
Проблемы оптимизации DLP-систем
Оптимизация ПО — многоступенчатый процесс, непростой, если с самого начала софт не был задуман экономичным. Проблемы «под капотом» у многих одни и те же. В итоге страдают заказчики — из-за неудачной или спорной архитектуры решений.
Например, вот что «болит» у большинства отечественных DLP-систем (вендор говорит с позиции разработчика DLP-системы — «СёрчИнформ КИБ»):
- Неэкономичное хранение данных. DLP — «прожорливые» продукты, при любом раскладе они обрабатывают огромные потоки трафика и хранят большие объёмы данных, в том числе тяжёлых: аудио, видео, графику. Если ничего не предпринимать и хранить всё «как есть», очень скоро выяснится, что система постоянно требует расширять СХД, а места постоянно не хватает. Это бьёт и по работоспособности софта, и по карману заказчика.
У «СёрчИнформа» в DLP заложено много вариантов управления местом для хранения: от ручных настроек и фильтров до автоматических алгоритмов, которые сами чистят хранилища. При этом тяжёлые данные сжимаются, а редко используемые — архивируются. Система может сама переносить их на медленные диски и хранить отдельно.
- Несколько серверов с разными ОС / СУБД. Очень многие решения представляют собой, по сути, своеобразных франкенштейновских чудищ: за отдельные функции отвечают разные модули системы. Например, анализ трафика — это один компонент, мониторинг пользовательской активности — другой. Зачастую изначально это решения разных производителей, которые собраны в единое целое. Но так как разрабатывались они разными людьми в разных средах, то и «дружат» между собой очень условно. В итоге имеем ситуации, когда один продукт требует, например, двух серверов (один на Linux, другой на Windows) с разными СУБД. Добавьте сюда по два агента на каждый пользовательский ПК, и получите двойную нагрузку в конечных точках, которая мешает работе.
«СёрчИнформ» с самого начала разрабатывал всё самостоятельно, поэтому все компоненты его систем работают в одной среде и даже разные продукты (например, DLP и DCAP) могут обойтись одним агентом, ужиться на одном сервере с одной ОС и СУБД.
- Вычисления только на агентах. Это отличный плюс к скорости, например, блокировок в каналах передачи данных — важной функции DLP, если вы хотите действительно предотвращать утечки. Это даёт решению автономность и экономит серверные мощности (на сервер отправляются только события по политикам безопасности). Никакого «сырого» перехвата, обработку трафика можно распараллелить на столько потоков, сколько ПК под контролем. Однако здесь есть свои «но». Во-первых, можно пропустить инциденты, не описанные в политиках. Во-вторых, при неудачной реализации такой агент нагружает пользовательские ПК и тормозит их работу, то есть «отъедает» базовый ресурс.
В «СёрчИнформ КИБ» можно гибко настроить, где запускать проверки — централизованно на сервере или на ПК. Например, почта может блокироваться по контенту как на агентах, так и на сервере: где нужнее, заказчик решает сам. И хотя тех же моментальных блокировок в решении много, они не перегружают агенты, потому что разработчик придумал, как уйти от тяжеловесного контентного анализа.
Вот пример того, как такая архитектура делает закупку дороже. Это кейс потенциального заказчика — крупного производителя удобрений, который выбирал между несколькими DLP. Рассчитывали конфигурацию «железа» для внедрения «СёрчИнформ КИБ» на 6000 рабочих станций, где нужно было контролировать все каналы передачи информации, в том числе перехватывать потоки с микрофона, веб-камеры и монитора, т. е. обрабатывать и хранить большое количество медиаданных. Вот что получилось (см. рис. 1).
Рисунок 1. Предварительный расчёт технических требований для внедрения DLP-системы
Итого: с учётом оборудования внедрение «СёрчИнформ КИБ» обошлось почти в три раза дешевле.
А вот другой пример, из совсем свежих. Компании требовалось установить контроль за 100 рабочими станциями — трафик плюс аудио и видео. По расчётам конкурента, на это потребовалось бы пять серверов с разными ОС и СУБД плюс СХД; по прикидкам «СёрчИнформа» — всего один. В обоих случаях КИБ сравнивали с самым близким конкурентом, входящим в топ-3 DLP в России.
Вот за счёт чего достигаются такие показатели.
Оптимизация ПО на уровне архитектуры
Когда «СёрчИнформ КИБ» только выводили на рынок, главной целью вендора было нарастить функциональность, охватить максимум каналов передачи данных. В результате программа работала с шестью (!) консолями, почти каждый модуль перехвата управлялся из своего интерфейса. Так делали все, но очень скоро стало понятно, что нужно «ужиматься». Путь, правда, у разработчика получился долгим. Процесс начался в 2015 году, к 2018-му удалось поднять производительность системы на 30 %. Сейчас у КИБ две «рабочих» консоли («AlertCenter» и «Консоль Аналитика») и две «настроечных», где можно управлять перехватом и конфигурацией системы. В 2024 году разработчик анонсирует их объединение в настольной редакции, а в веб-версии всё — и аналитика, и управление — уже работает в одном интерфейсе.
И, конечно, все компоненты работают на одном сервере — если он достаточно производителен, этого хватает на среднее и даже весьма крупное внедрение (до 1000 ПК), часто можно обойтись и без отдельной СХД.
У вендора с самого начала был козырь в рукаве — собственное поисковое ядро (SearchServer). Это базовое преимущество, ведь так компания, во-первых, сама отвечает за качество продукта, а во-вторых, не зависит от лицензий стороннего производителя. Это выгодно и заказчикам, которым не нужно платить дважды. И всё-таки некоторая дополнительная нагрузка на карман клиента присутствовала: для инсталляции требовались платные ОС Windows Server и СУБД Microsoft SQL Server. Изначально КИБ «строился» на них, потому что того требовали абсолютное большинство клиентов. Но со временем тенденция изменилась. Сейчас вендор переводит серверные компоненты КИБ на Linux, чтобы добавить поддержку в т. ч. свободно распространяемых серверных ОС, и уже «переехал» на СУБД PostgreSQL — она бесплатна, клиент экономит. Также в DLP поддержали российскую версию PostgreSQL Pro, но это платная тема. А ещё продукт может одновременно работать и с коммерческой Microsoft SQL Server, и с бесплатной PostgreSQL. Это позволяет задействовать уже имеющиеся инвестиции в СУБД (всё-таки Microsoft SQL Server производительнее), а на новые лицензии СУБД не тратиться.
Наконец, разработчики всё же перенесли часть вычислений на агенты. Это действительно повышает быстродействие и разгружает сервер — преимущество особенно хорошо видно у крупных заказчиков.
Допустим, нужна блокировка писем, куда вложены PDF-документы с грифом. Сперва такие письма надо перехватить агентом либо сетевой платформой, затем распарсить (извлечь текст и атрибуты), затем отправить результат на хранение в базу данных, куда придёт индексатор. Индексатор создаст удобную структуру для текстового поиска (индекс), по которому система проведёт проверку. По результатам проверки DLP примет решение, заблокировать письмо или нет. Весь этот процесс идёт на сервере, причём одновременно в обработке могут находиться тысячи писем. В итоге от момента отправки письма пользователем до его фактической отправки системой может проходить много времени (и 5, и 10, и 15 минут) — бизнес-процессы тормозят, мощности перегружаются. Вместо того чтобы централизованно собирать и парсить каждое письмо, анализировать с помощью OCR каждый вложенный PDF, можно провести анализ локально одновременно в тысяче точек — результат будет почти мгновенным. Всего на локальном уровне в КИБ работают больше 10 видов блокировок, причём не только по атрибутам, но и по контенту.
Контентные блокировки ресурсоёмки, поэтому разработчики искали компромисс между гибкостью, скоростью и ресурсами. Результатом стало появление облегчённой версии основного поискового ядра (miniSearchServer), встроенной в агент. Урезание аналитических возможностей позволило урезать и «аппетиты» к ресурсам.
При этом возможность полноценного контентного анализа перед блокировкой на агенте сохраняется. Если в компании развёрнут «СёрчИнформ FileAuditor» (напомним, что и агент, и сервер у них с КИБ общие), он классифицирует по содержимому все файлы и в соответствии с классификацией расставляет метки. КИБ в свою очередь может блокировать передачу или запуск файлов по меткам FileAuditor, не проверяя файл каждый раз, как пришлось бы «по классике». Иначе говоря, критерием блокировки становится наличие метки: она уже содержит «инструкцию» по обработке файла в зависимости от контента, дополнительные ресурсы на принятие решения не нужны.
Оптимизация ПО на уровне хранения данных
КИБ позволяет контролировать объёмы хранения данных. ИБ-специалист может настроить обработку контента как ему удобно — например, при анализе хранилищ полностью отказаться от теневого копирования файлов, ограничиваясь только аудитом, или настроить систему таким образом, чтобы запись велась только в рабочие часы. Откалибровать можно всё вплоть до мелочей. Фильтров, исключений и прочих тонких настроек так много, что место в СХД под архив записей можно сократить до восьми раз.
Действуют и автоматические механизмы, позволяющие не захламлять хранилище. Например, работает автоудаление архивных инцидентов старше заданной даты. Для всех каналов перехвата работает дедупликация, то есть каждое письмо и вложение в КИБ хранятся в единственном экземпляре, даже если их пересылают или отправляют множеству получателей. За кросс-канальную дедупликацию отвечает компонент Unified Storage; он позволяет не раздваивать в архиве один и тот же документ, переданный, например, по почте, по «Скайпу» и на флешке. Экономия места составляет 10–20 %.
Понятно, что больше всего места в архиве занимают аудио- и видеозаписи активности пользователя. Поэтому в КИБ заложили большое количество доступных битрейтов и кодеков для качественного сжатия «тяжёлых» данных. Также можно писать видео в определённой доле от качества оригинала, только в чёрно-белом формате и так далее. Благодаря этому, а также алгоритму VAD (позволяет писать аудио только при звуке речи) и прочим алгоритмам экономится до 25 % СХД без ощутимой потери качества данных.
Другие способы снизить ресурсоёмкость внедрения
Кроме компактности для DLP важны стабильность и быстродействие, особенно если речь идёт о масштабном внедрении. В КИБ реализована кластеризация для всех компонентов, чтобы одна и та же задача могла выполняться на нескольких серверах одновременно. Логика — та же, что и с вычислениями на агентах: параллельная обработка более мелких «порций» данных идёт быстрее. При этом можно сделать так, чтобы каждая задействованная единица была мультизадачной. Допустим, компания закупила мощный сервер для OCR. Но задача распарсить 500-страничный PDF возникает раз в год, а «железо» куплено и простаивает без дела. Чтобы этого не допустить, КИБ может направлять на свободный сервер другие задачи — например, передать на него часть потока писем из почтового карантина. КПД каждого компонента системы таким образом вырастает.
Но не кластером единым. Работу над оптимизацией «СёрчИнформ» ведёт постоянно, что-то улучшается почти в каждом релизе. Например, обработку тяжёлых медиаданных вынесли на отдельное ядро (AAServer), которое работает автономно и не задействует основные ресурсы системы. Также внедрили графические метрики работы всех компонентов, чтобы управлять индексами, БД, конфигурацией сервера и работой поискового ядра.
Важная доработка из недавних — возможность перемещать данные на медленные диски. Например, туда можно отправлять архивный «перехват», который не используется в ежедневной работе ИБ-специалиста. Перенос не влияет на общую производительность DLP, зато за счёт применения более медленных и дешёвых дисков и изменения схемы RAID затраты на хранение архива могут быть до 10 раз ниже, чем на оперативное хранилище.
Выводы
По оценкам заказчиков, внедрение продуктов «СёрчИнформ» обходится бизнесу дешевле решений от других производителей и на старте, и на длинной дистанции. КИБ до двух раз менее требователен к ЦП и ОЗУ, чем большинство аналогов на рынке, то есть на старте заказчику не нужно вкладываться в сверхмощное «железо». За счёт экономичного хранения данных и эффективного использования хранилищ заказчику не придётся часто расширять парк оборудования под систему, и даже плановое расширение (например, когда накопится много архивного перехвата) можно сделать заметно дешевле за счёт использования медленных дисков. При этом низкая ресурсоёмкость никак не сказывается на функциональности КИБ — это одна из сильнейших систем в своём классе на российском рынке.
Вывод напрашивается один: хорошо делай — хорошо будет. Разработчик с самого начала заявил систему с удачной архитектурой, а потом делал ставку на запросы заказчиков (которым, напомним, свойственно экономить). В нынешних условиях «приятный бонус» в виде низких по сравнению с аналогами требований к ресурсам превращается в важное преимущество.
Чтобы попробовать и убедиться, закажите бесплатную пробную версию на 30 дней.
Реклама. Рекламодатель ООО «СерчИнформ», ОГРН 1157746137955
ERID: 2VfnxyDrF76
