Всем привет! Я Максим Максимович, директор департамента инжиниринга Positive Technologies. В этой статье я затрону тему обработки и оптимизации хранения событий в высоконагруженных SIEM-инсталляциях, расскажу о сложностях, с которыми многие наверняка уже сталкивались при выполнении подобных задач, и на примере одного реального проекта покажу, как их можно преодолеть.
Метрики производительности, которых требовал проект, сыграли нам на руку, так как изначально были отмечены в дорожной карте MaxPatrol SIEM. Причем добавить мы их планировали уже в следующую версию продукта. В итоге по завершении проекта мы получили не только приятный профит в виде (почти!) готового раньше намеченного срока релиза MaxPatrol SIEM, но и возможность сразу же подтвердить новые характеристики решения в боевых условиях. Речь идет о версии 6.2, которая позволяет обрабатывать до 60 тыс. событий в секунду. Добиться такой скорости мы смогли за счет гибридной схемы хранения данных, которая помогла увеличить производительность хранилища событий и при этом сократить расходы на аппаратное обеспечение.
Надеюсь, описанный в посте опыт будет полезен специалистам и энтузиастам, внедряющим и эксплуатирующим решения классов Log Management и SIEM.
Осторожно, высокое напряжение
Для тех, кто мало знаком с SIEM-системами, немного расскажу про базовые принципы работы решений этого класса. С множества различных устройств журналы, содержащие события информационной безопасности, централизованно отправляются в SIEM-систему, где они обрабатываются в режиме реального времени. На основе правил детектирования угроз система выявляет инциденты безопасности, а также другие отклонения и аномалии. Обработанные события передаются в хранилище, в котором в соответствии с внутренним регламентом компании (или требованиями регулятора, например приказом ФСТЭК № 17, приказом ФСБ № 196, РС БР ИББС-2.5-2014) они находятся в оперативном доступе.
На современные системы обработки и хранения событий распространяются базовые требования к работе с большими потоками журналов, которые необходимо долго хранить длительные периоды времени, а также требования по предоставлению доступа к данным в оперативном режиме для многочисленных пользователей. При входящих потоках cвыше 10 000–15 000 событий в секунду система хранения событий создает интенсивную нагрузку на дисковую подсистему в момент индексации (т. е. записи данных на диск). Одновременно с записью могут возникать многочисленные обращения ко всему объему хранимых данных, что накладывает дополнительную нагрузку на дисковую подсистему и зачастую превышает заложенные характеристики по количеству поддерживаемых операций записи и чтения за определенный интервал времени.
Существуют различные типовые сценарии, которые могут привести к ситуации, когда системы начинают буквально «бороться» за возможность одновременно писать и читать данные. Обычно это приводит к буферизации данных на компонентах, которые находятся на этапах обработки, предшествующих записи в базу. В большинстве случаев буферизация позволяет нивелировать переход систем в постоянный аварийный режим. Помимо этого, проблемы могут носить системный характер: к примеру, нагрузка может превышать как заложенные в систему эксплуатационные характеристики конфигурации ПО, так и аппаратные требования, особенно в части дисковой системы.
Отдельно стоит отметить работу операторов SIEM-системы, находящейся под большими нагрузками. В этом случае прогнозировать и контролировать операции с поиском данных сложно, и иногда для этого приходится наложить на систему многочисленные ограничения. В этом процессе участвуют пользователи разного уровня квалификации.
Переходим к нашей главной задаче. Она состояла в том, чтобы обеспечить бесперебойную запись и параллельное чтение данных из единого хранилища. Есть несколько способов разрешить эту сложность: например, строить хранилища только с использованием дорогостоящих SSD, строить большие и распределенные кластерные системы либо разграничивать типы хранилищ по частоте обращений к ним. На практике у каждого вендора свой подход. Далее расскажем, что выбрали мы в Positive Technologies и почему.
Проект-челлендж, который совпал со стратегией развития MaxPatrol SIEM
Нашей отправной точкой стал 2019 год. В тот момент MaxPatrol SIEM переживал стадию бурного взросления: мы активно развивали его функциональность, работали над повышением стабильности продукта и увеличением характеристик, в частности по нагрузке и обработке данных. Целевая конфигурация SIEM-системы тогда позволяла обрабатывать до 30 тыс. событий в секунду (без использования иерархической архитектуры).
Стратегия развития MaxPatrol SIEM включала в себя увеличение производительности решения, и реализовать это мы планировали уже в релизе 5.9. Что интересно, практически в это же время представился случай реализовать проект, для которого было необходимо построить систему обработки и корреляции событий, способную обрабатывать более 65 тыс. событий в секунду. Поскольку MaxPatrol SIEM уже имел архитектуру, позволяющую добиться требуемого показателя EPS (нам всего лишь было нужно построить иерархию), мы с энтузиазмом за него взялись. Кроме того, это была отличная возможность проверить работу обновленной системы в боевых условиях.
Этот проект заинтересовал нас еще и тем, что задача, для которой компания планировала использовать SIEM-систему, была нестандартной для этого класса решений. Все-таки SIEM-системы чаще всего используются для выявления инцидентов ИБ и защиты компании от киберугроз, а здесь был другой случай. И вот почему.
Пользователем выступила высокотехнологичная компания, разрабатывающая программное обеспечение, а также предоставляющая его как сервис (SaaS). Для работы со своими решениями она активно использует контейнерные технологии. В техническом задании требовалось, чтобы инсталлированная система мониторила параметры контейнеров. Однако все оказалось не настолько просто, как может показаться на первый взгляд. Параметров контейнеров оказалось так много, что, по сути, необходимо было параллельно мониторить выполнение множества задач. Так, необходимо было отслеживать:
параметры работы приложений — как они запускаются, отрабатывают статусы завершения, проходит ли это успешно или неуспешно;
параметры безопасности доступа к приложениям (например, какие пользователи заходили);
технологические параметры компонентов;
события безопасности, в частности события доступа к технологическим компонентам.
Все это создавало такой большой поток событий, с каким мы еще не сталкивались на предыдущих проектах. Можно сказать, что с технологической точки зрения для нас это был проект-челлендж.
О сложностях, которые нас не испугали
Помимо того, что требуемая скорость обработки данных до 65 тыс. событий секунду была хоть и довольно высокой, но более чем оправданной, целевая архитектура SIEM-системы, к которой мы пришли вместе с клиентом, оказалась нестандартной в рамках существующих конфигураций MaxPatrol SIEM. До этого компания имела обширный опыт работы с другими SIEM-системами, поэтому она, с одной стороны, была очень требовательна к функциям и производительности, а с другой — понимала сложность поставленной задачи. В итоге договорились о том, что критерием успешной сдачи проекта станут тестовые испытания системы под требуемой нагрузкой длительностью более одной недели с объемом хранения данных, доступных при выполнении поисковых запросов, до одного месяца. И здесь, казалось, фортуна от нас отвернулась: активная стадия реализации этого проекта выпала на период между релизными циклами MaxPatrol SIEM.
Мы всегда стремимся обновлять до новых версий компоненты наших решений — это позволяет добавлять новые функции в продукты — однако в то время мы только делали первые подходы к планированию перехода на новую, седьмую версию компонента хранения событий Elasticsearch. Необходимость внести доработки в MaxPatrol SIEM при переходе на эту версию вне запланированного релизного цикла стала очевидна на этапе нагрузочного тестирования собранной конфигурации. От того, сможем ли мы обновить продукт вовремя, без преувеличения, зависел успех проекта. Нам повезло: согласитесь, все-таки здорово, когда группа внедрения имеет за спиной команду разработки, которая готова откликнуться на новые технические вызовы и умеет добиваться нужного результата. Объединившись, мы стали раньше, чем планировалось, экспериментировать с новой версией Elasticsearch и смогли использовать тестовые сборки при реализации нашего проекта.
Убить двух зайцев один выстрелом, или Как мы создали гибридную схему хранения данных
С архитектурой разобрались, настал черед данных. Давайте посмотрим, с чем нам пришлось иметь дело. Представьте постоянный входящий поток логов объемом 65 тыс. событий в секунду. Размер событий разный — от 200 байт до нескольких килобайтов. Этот поток необходимо записывать в базу. При этом сразу после записи от операторов SIEM-системы при выполнении поисковых запросов к этим данным идут обращения на чтение.
Ежедневно записывается около 3–4 терабайт данных. По приблизительным подсчетам уже через месяц накопится 100 терабайт данных, по которым будут осуществляться поисковые запросы. Чтобы обеспечить одновременно и бесперебойную запись, и чтение данных, на дисковые системы накладываются высокие требования по IOPS. Их выполнение при таких характеристиках и объемах могут обеспечить только твердотельные диски SSD. Вследствие этого возникает новая сложность: реализовать систему хранения объемом в 100 терабайт на SSD становится дорогим удовольствием, а значит, далеко не каждая компания сможет себе позволить такой вариант исполнения хранилища.
Нам предстояло придумать, как понизить стоимость решения и при этом отвечать всем требованиям компании к работе с данными. От варианта построить хранилище полностью на HDD пришлось отказаться сразу, так как в этом случае невозможно было получить необходимые (комфортные) условия как для чтения, так и для записи данных при заявленной нагрузке.
В какой-то момент мы задались вопросом: а можно ли соединить преимущества накопителей обоих типов, чтобы реализовать требования нашего проекта? Погрузившись в тему и изучив все нюансы долгосрочного хранения данных, мы поняли, что убить двух зайцев одним выстрелом нам поможет разделение данных на условно «горячие» и «теплые». Эта функция в Elasticsearch на тот момент была реализована в рамках index lifecycle management (ILM). «Горячие» (hot) данные располагаются на высокоскоростных дисках — SSD. Их объем позволяет хранить файлы от нескольких дней до недели. Затем данные автоматически перезаписываются в раздел «теплые» (warm), который может располагаться на более приемлемых по стоимости жестких магнитных дисках — HDD. Это должно было позволить увеличить скорость обработки событий при одновременном выполнении поисковых запросов. Что касается доступа к результатам поисковых запросов, стоит отметить, что «горячие» и «теплые» индексы для оператора SIEM-системы представляют единое целое.
Таким образом, чтобы увеличить производительность хранилища событий и сократить расходы на аппаратное обеспечение, мы решили использовать гибридную схему хранения данных. Нелишним будет упомянуть, что компания-заказчик сначала скептически отнеслась к данному подходу. У нее были опасения (которые нам еще только предстояло развеять), что таким способом построить SIEM-систему, которая будет обрабатывать 65 тыс. событий в секунду, просто невозможно.
Ближе к дате завершения проекта не обошлось без потери нервных клеток. Как известно, внерелизные доработки, помимо быстрого получения результата, всегда несут дополнительные прогнозируемые ошибки и риски, которые могут влиять на стабильность либо работоспособность продукта. Поэтому нам пришлось еще немного потрудиться: мажорные изменения в схеме хранения данных потребовали сделать немало доработок внутренних механизмов записи и чтения обрабатываемых событий. Однако марш-бросок стоил того: приемочные тесты проекта показали, что MaxPatrol SIEM справился абсолютно со всеми заявленными метриками производительности, все требования компании были успешно выполнены, а сомнения принимающей стороны по поводу того, что мы не сможем качественно реализовать этот подход, были разбиты. Этот проект на следующие полтора года послужил трамплином для использования подхода с применением ILM в других высоконагруженных проектах, где оптимизировались связанные параметры.
Через тернии к звездам
Летом 2021 года мы выпустили новый релиз системы выявления инцидентов MaxPatrol SIEM — 6.2. В обновленной системе поддерживается сверхнагруженная конфигурация, в основе которой лежат технологии ILM с «горячими» и «теплыми» данными. За счет этой архитектуры появляется возможность сбалансировать стоимость системы хранения и обеспечить комфортную работу при высоких нагрузках.
Эти нововведения стали фундаментом для увеличения производительности подсистемы хранения MaxPatrol SIEM почти в два раза, что позволяет компаниям максимально охватывать всю иерархическую инфраструктуру. Этот параметр особенно важен для организаций с крупной территориально распределенной инфраструктурой, которые являются одними из основных пользователей SIEM-систем. К моменту добавления функции в официальный релиз результаты были подтверждены успешными промышленными эксплуатациями — помимо кейса, которому была посвящена эта статья, в течение года мы реализовали еще три аналогичных проекта в компаниях, где специалисты по ИБ или центры обеспечения безопасности занимаются мониторингом инфраструктуры в режиме 24/7.
P. S. В статье я намеренно не приводил абсолютные метрики и расчеты. С ними вы можете ознакомиться, написав нам по адресу partners@ptsecurity.ru.
