Всем привет! За последние несколько лет число кибератак кратно выросло — это создало необходимость в новых подходах к кибербезопасности. Одним из них стала эшелонированная защита — ряд СЗИ, работающих на разных сетевых уровнях, но выполняющих одну задачу по защите ресурсов. Сегодня мы расскажем об агрегации логов различных СЗИ — задаче, которая возникла как следствие внедрения эшелонирования.
В этой статье мы поделимся, как построили универсальную систему для хранения логов с различных СЗИ с возможностью как ретроспективного, так и моментального анализа событий «в одном окне» с помощью open source-решения (и объясним, почему это безопасно).
Проблема хранения и визуализации логов разных СЗИ
Защита ресурсов несколькими эшелонами подразумевает больший уровень защищенности, но и большее количество эксплуатируемых СЗИ. Они в свою очередь генерируют огромное количество логов и метрик, которые содержат ценные данные о событиях безопасности, атаках и других инцидентах. Хранение и визуализация этих логов и метрик — важная задача для анализа безопасности и выявления угроз. В нашем случае логи — текстовые записи событий, генерируемые СЗИ, которые содержат временную метку и сообщение с определенным контекстом (ID-сработки, IP-адрес, структурированный JSON и т. п.). В то же время метрики — числовые показатели, изменяемые с течением времени. Примерами могут быть: загрузка CPU, использование памяти, дисковый I/O, количество запросов в секунду (RPS), время ответа приложения.
При работе с логами СЗИ может возникнуть множество проблем, например:
Большой объем данных. Логи быстро накапливаются, что создает нагрузку на хранилища и затрудняет их анализ.
Разнообразие форматов. СЗИ генерируют логи в разных форматах, что усложняет их унифицированное хранение и анализ. К тому же формат логов в новой версии того же СЗИ может существенно отличаться от старого.
Визуализация данных. Для анализа логов важно представлять данные в наглядном виде, для этого требуются специальные инструменты визуализации.
Масштабируемость. По мере роста объема поступаемых логов и количества используемых СЗИ система хранения должна масштабироваться, что может быть проблематично без гибкой архитектуры.
Скорость. Эшелонирование приводит к большому многообразию СЗИ с собственными хранилищами данных. Их сбор, сопоставление и аналитика занимают очень много времени, что является критичным для анализа атак в режиме реального времени.
Использование собственных инструментов защиты. Становится актуальным построение визуализации для СЗИ.
Для решения этих проблем мы решили построить универсальную систему для хранения логов с различных СЗИ с возможностью как ретроспективного, так и моментального анализа событий «в одном окне».
Попытка использования ELK
По нашему опыту, первый инструмент, с которым сталкиваются инженеры в ходе разработки системы, — это ELK.
ELK (Elasticsearch, Logstash, Kibana) — популярный стек для сбора, хранения и визуализации данных. Он широко используется для работы с разными логами благодаря многим возможностям.
Преимущества ELK:
Гибкая система поиска и анализа данных (встроенный движок Apache Lucene).
Гибкие инструменты визуализации — Kibana.
Поддержка различных источников данных.
Возможность интеграции с другими системами.
Однако при использовании бесплатной версии ELK есть ряд ограничений:
Расширенные функции безопасности — управление доступом на основе ролей (Role Based Access Control), шифрование, аудит — доступны только в платных версиях.
Ограниченное количество плагинов и модулей из-за особенностей лицензии.
Тесная интеграция с Elastic Cloud. Могут быть ограничения при использовании других облачных платформ.
Проект в целом сфокусирован на коммерческой функциональности, модификации некоторых параметров недоступны в открытой версии.
ELK является хорошим решением для анализа, хранения и визуализации данных, однако текущие ограничения в области коммерческого лицензирования для РФ делают его использование затруднительным, что побудило нас рассмотреть альтернативы.
Поиск open-source-альтернатив ELK
При поиске альтернатив ELK мы рассмотрели множество решений, таких как: Grafana Loki, Prometheus, Graylog, OpenSearch.
Grafana Loki. Продукт специализируется на логах с акцентом на эффективном хранении и поиске по тегам и меткам (labels), а не на содержимом. Также он не индексирует текст логов, только метаданные, что снижает затраты на хранение и ускоряет запись. Обычно он требует меньше ресурсов, что прекрасно подходит для облачных и контейнерных сред (Kubernetes), где логи генерируются в огромных объемах. Он не совсем подходит для глубокого анализа логов. При использовании Loki, мы не сможем искать по содержимому, только по меткам. Более того, эти данные не индексированы, поэтому поиск будет занимать больше времени по сравнению с полнотекстовым индексом в OpenSearch.
Prometheus специализируется на временных рядах (метриках) с оптимизацией под высокую частоту записи. Использует простую модель данных: (метка: значение) + временная метка. Отличный алертинг в режиме реального времени обеспечивается через Alertmanager. Также хорошо подходит для мониторинга инфраструктуры в режиме реального времени: есть интеграция с экосистемой CNCF (Kubernetes, Istio, Thanos). Не подходит для хранения логов или событий в течение длительного времени (обычно 15–30 дней), что делает невозможным ретроспективную аналитику. В нашем случае имеется множество текстовых данных, необходимых для поиска и анализа, поэтому с Prometheus будут сложности.
Graylog специализируется только на логах, для метрик потребуются дополнительные инструменты (те же Prometheus и Grafana). Поиск ограничен метками и частичным текстовым анализом (Grok-паттерны). Продукт добавляет накладные расходы из-за MongoDB и своей очереди обработки (может стать узким местом при высокой нагрузке). При этом у Graylog есть версия, которая может удовлетворять всем нашим требованиям, но она также имеет ограничения в области коммерческого лицензирования для РФ.
OpenSearch обладает рядом преимуществ над системами, рассмотренными выше:
Единая платформа. Нет необходимости настраивать целый ряд систем. Все логи, метрики и трейсы хранятся в одном месте.
Поддержка полнотекстового поиска и сложных агрегаций. К примеру, можно найти все запросы по определенному пути с кодом 5xx за последний час и сгруппировать по СЗИ.
Поддержка долгосрочного хранения без дополнительных инструментов с выгрузкой данных на S3-хранилище, что выгодно для архивирования.
Полностью бесплатный, с открытым исходным кодом. Затраты только на ресурсы для VM/серверов, есть возможность свободного использования и модификации под свои нужды.
Знакомый синтаксис запросов API. Синтаксис запросов и API OpenSearch совместимы с Elasticsearch, что упрощает переход и интеграцию с существующими системами.
Богатый функционал без ограничений. OpenSearch предлагает аналогичные Elasticsearch-инструменты без разделений версий по функциональности на основе подписки.
Широкий спектр возможностей формирования визуализаций.
Активное сообщество и поддержка. Проект поддерживается активным сообществом разработчиков, в т. ч. Amazon, что гарантирует своевременность обновлений с решением проблем, а также появление новых возможностей. Новые версии выходят достаточно часто.
Гибкость и масштабируемость. OpenSearch можно масштабировать, что позволяет работать с большими объемами данных и адаптировать кластер под растущие потребности.
Безопасность. OpenSearch разработан с учетом современных требований к защите данных: предусмотрены гибкие инструменты аутентификации, механизм разграничения прав на основе ролей (Role-Based Access Control), поддержка шифрования каналов, средства ведения журнала событий, возможность настройки TLS/SSL, а также встроенные способы проверки подлинности пользователей и контроля их полномочий. Все это позволяет легко построить систему с учетом возможных рисков и внутренних политик безопасности. Дополнительно система может быть размещена в изолированном сегменте сети, не имеющем прямого доступа из внешних периметров.
Таким образом, Opensearch — единый инструмент, обладающий широкой универсальностью для работы не только с логами, но и метриками с трейсами, а также позволяющий использовать обширный спектр визуализаций и дашбордов для аналитики получаемых логов. Это наиболее привлекательная альтернатива ELK для организаций, которые ищут эффективное и экономически выгодное решение для хранения и визуализации логов СЗИ.
Тестирование standalone-node, изучение функциональности
После изучения вопросов выбора системы мы приступили к установке OpenSearch на один узел со следующими характеристиками:
8 vCPU
16 GB RAM
~500 GB ROM
OpenSearch, Logstash и OpenSearch Dashboards был установлен из .deb пакетов, версия 2.17.1. Logstash версии 8.8.2.
На этой инсталляции удалось утвердить формат логов разных СЗИ, а также отработать эффективные паттерны Logstash для обработки данных логов. В новой версии OpenSearch нашли интересные и необходимые инструменты, такие как:
Alerting. Возможность настроить корреляции событий.
Security Analytics. Интересный инструмент, превращающий OpenSearch в SIEM. Модуль предназначен для изучения, обнаружения, анализа угроз безопасности и реагирования на них.
Anomaly detection. Аномалия в OpenSearch — любое необычное изменение входящих данных по времени. Аномалии могут дать ценную информацию о новых данных. Например, для данных с WAF аномалия по RPS может помочь выявить признаки атаки.
После небольшого периода тестирования мы убедились, что OpenSearch полностью удовлетворяет всем нашим требованиям к системе хранения и аналитики логов. Следующим шагом было необходимо построить систему для логов СЗИ с реальным трафиком. Поэтому было решено выделить больше ресурсов и перейти на кластерную конфигурацию.
Решение о переходе на кластер
После проверки предыдущей схемы (СЗИ -> Logstash -> OpenSearch) стало понятно, что в ней не хватает надежной доставки данных от СЗИ к OpenSearch. Более того, предыдущая схема не учитывает сохранение событий в случае проблем с OpenSearch, когда он не может принять события (к примеру, кластер в состоянии Red). Поэтому было решено перейти на кластер OpenSearch и добавить в схему Apache Kafka. Kafka — платформа для обработки массивных потоков данных в режиме реального времени. Она сочетает функции системы обмена сообщениями, хранилища данных и инструмента для потоковой обработки. Данные в Kafka хранятся на диске, а не только в оперативной памяти, что обеспечивает надежность и возможность повторного чтения. Сообщения хранятся заданное время или до достижения лимитов по объемам, что позволяет OpenSearch обрабатывать их с задержкой. Таким образом, повысится надежность доставки данных до OpenSearch. Конечная схема выглядит приблизительно так:
Агент отправки событий на СЗИ (обычно Filebeat, реже чистый Syslog) -> Kafka -> Logstash -> OpenSearch Cluster.
Схема отмечена ниже:
Сам кластер OpenSearch был построен из следующих элементов:
Coordinating nodes. Принимают трафик, координируют входящие запросы.
Cluster manager nodes (минимум 3 для необходимого кворума). Опрашивают другие узлы, проверяя доступность и получая текущее состояние. Создают и удаляют индексы. Один из узлов — Master.
Hot data nodes. Горячие узлы индексируют и хранят свежие данные согласно Hot->Cold-политике.
Cold data nodes. Холодные узлы принимают менее свежие данные с горячих узлов.
В будущем планируем добавить в схему теплые узлы для разгрузки горячих узлов и переноса более тяжелых процедур на теплые и холодные узлы. Возможно, стоит рассмотреть добавление в схему узлов поиска (Search) для снижения нагрузки на узлы с данными во время индексации.
Тестирование новой схемы
После расчетов по сайзингу для нового кластера мы приступили к развертыванию необходимой инфраструктуры. Процесс создания кластера неплохо описан в документации OpenSearch. Отметим несколько необычных пунктов:
Некоторые параметры задаются единожды только при первом запуске кластера (потом их можно удалить). Пример: cluster.initial_master_nodes. Для узлов с данными дополнительно указываем атрибуты зоны и принадлежности группе узлов (горячей или холодной): node.attr.data и node.attr.zone.
Для исключения ситуаций split brain разработчики рекомендуют использовать минимум 3 узла Cluster Manager. Нужно учитывать данный факт при составлении схемы.
Использование отдельно горячих и холодных узлов необходимо для работы политик хранения данных, чтобы распределить нагрузку и уменьшить ее для каждого отдельного узла с данными во время операций записи и индексации данных. От теплых узлов пришлось отказаться из-за ограничений по выделенным ресурсам.
Итоговая схема с несколькими ЦОД получилась приблизительно такой:
Таким образом, данная схема позволяет обеспечить высокую степень отказоустойчивости и оптимальной производительности.
Создание дашбордов для конкретных СЗИ с просмотром событий
OpenSearch Dashboards — это веб-интерфейс (панель управления) для работы с OpenSearch. Мощный инструмент для анализа и визуализации данных, входящих в экосистему Opensearch. Он позволяет преобразовывать сырые данные из индексов в наглядные графики, карты и интерактивные дашборды, упрощая процесс принятия решений. Рассмотрим ключевые возможности визуализации в данной платформе.
OpenSearch Dashboards поддерживает разнообразные форматы отображения данных:
Графики и диаграммы: линейные, столбчатые, круговые, гистограммы для анализа распределений и трендов.
Геопространственные карты: визуализация данных на картах (Tile Map, Region Map) для анализа локаций, например распределения событий по регионам.
Тепловые карты: выявление аномалий и зон высокой активности.
Таблицы и метрики: отображение агрегированных значений (среднее, максимум, минимум).
Пользователи могут объединять несколько визуализаций на одном дашборде, добавляя глобальные фильтры (например, по временному диапазону или тегам). Это позволяет динамично исследовать данные: изменение фильтра автоматически обновляет все связанные элементы. Поддерживается настройка панелей управления (controls) для удобного взаимодействия без редактирования запросов.
Гибкость анализа
Агрегация и трансформация: создание сложных запросов с использованием метрик (count, sum, avg) и группировок (terms, date, histogram).
Обработка временных рядов: визуализация динамики событий с возможностью сглаживания данных и сравнения периодов.
Кастомизация: настройка цветов, меток, осей и легенд для адаптации визуализаций под конкретные задачи.
Интеграция с экосистемой OpenSearch
Dashboards тесно взаимодействуют с другими компонентами OpenSearch:
Alerting: настройка оповещений на основе условий в визуализациях (например, при превышении порога ошибок).
Notebooks: совмещение визуализаций с текстовыми описаниями и SQL-запросами в интерактивных отчетах.
Безопасность: интеграция с Opensearch Security для контроля доступа к дашбордам на уровне ролей.
Как часть open-source-решения, OpenSearch Dashboards активно развивается сообществом. Пользователи могут расширять функционал через плагины, а также модифицировать исходный код под свои нужды. Это делает платформу гибкой альтернативой коммерческим инструментам.
Ниже представлен пример дашборда по одному заказчику с несколькими СЗИ. В нем присутствуют данные, получаемые с WAF- и Anti-DDoS-решений отдельного заказчика, такие как: RPS (как суммарный, так и по разным цепочкам), топ IP-адресов, топ путей, график кодов ответа и графики со статистикой по входящему трафику. Представление данных сразу с нескольких СЗИ в одном окне дает возможность получать моментальное представление об эффективности работы обоих эшелонов защиты. Данные на графиках являются интерактивными: возможна фильтрация по предоставленным значениям в режиме реального времени. Таким образом, время на анализ работы СЗИ, в том числе во время атак, сокращается в разы.
ISM — создание политик и операций с индексами
Основа работы с OpenSearch — это управление жизненным циклом индексов: изменение количества реплик или шардов, перемещение индексов на конкретные узлы, закрытие, удаление и другие операции. Управлять сотнями индексов вручную — плохая практика, но есть решение по автоматизации всего процесса. Index State Management (ISM) — это механизм автоматизации управления жизненным циклом индексов в OpenSearch, который позволяет оптимизировать работу кластера, снизить затраты на хранилище, а также снизить нагрузку на отдельные узлы. Дальше рассмотрим пример политики обработки индексов.
Данные, которые накапливаются в OpenSearch, рекомендуется распределять в зависимости от их значимости. Примером может служить политика хранения данных, основанная на принципе «горячих», «теплых» и «холодных» узлов.
В нашем случае свежие данные сначала поступают на «горячие» узлы, обладающие наибольшим количеством ресурсов, а затем уже распределяются по другим узлам кластера. В общем и целом узлы можно настроить на прием только «горячих», «теплых» или «холодных» данных (Hot-Warm-Cold).
В OpenSearch для управления индексами применяется механизм Index State Management (ISM). Пример политики отображен ниже.
В отличие от Elasticsearch, где состояния Hot, Warm и Cold предоставляются по умолчанию, в OpenSearch пользователь может создавать состояния и переходы между ними вручную. Для начала необходимо определить шаблон индекса (Index Pattern).
Каждое состояние может включать одно или несколько действий (Actions), которые выполняются последовательно. Некоторые действия выполняются в фоновом режиме, передавая индекс следующему действию, что необходимо учитывать.
Важно настроить параметры тайм-аута и повторных попыток выполнения действий, что позволит повторно выполнить действие в случае возникновения ошибки.
Политика управляет состояниями (states), в которых указаны операции, применяемые к индексам.
Для перехода между состояниями можно задать условие, при выполнении которого будет осуществлен переход. Это условие можно выбрать из списка.
Из-за ограничений в ресурсах для тестирования мы были вынуждены использовать политику Hot-Cold: сначала данные поступают на «горячие» узлы, затем, согласно заданным параметрам (обычно по времени или минимальному размеру шарда конкретного индекса), выполняет��я Rollover (создание нового индекса со счетчиком вида XXXXXX в названии), и готовый индекс обрабатывается политикой.
Изначально мы хотели организовать сжатие на «холодных» узлах, но при тестировании через ISM не удалось организовать надежную схему со сжатием. Кроме того, ISM проверяет соответствие условиям с некоторым запаздыванием (пример), что критично для высоконагруженных индексов. Поэтому мы приняли решение реализовать выполнение политики с помощью собственных скриптов. Они учитывают текущее состояние кластера, выполняют Rollover, а также перемещают индексы с горячих узлов на холодные со сжатием. При большом количестве индексов может осуществляться сразу несколько операций с исключением пересечений в активных заданиях.
Для тестирования и проверки работы скриптов в разных условиях пришлось также создать асинхронный генератор большого количества сообщений, приближенных к реальным данным с высоконагруженных СЗИ. Позже эти политики показали высокую эффективность на реальных данных: удалось добиться сжатия до 36% (совпадает с заявленными значениями), а также убрать лишнюю нагрузку с горячих узлов.
Выводы
В процессе внедрения и эксплуатации решения мы получили ряд практических выводов, которые могут быть полезны тем, кто планирует реализовать аналогичный проект.
Критически важно на раннем этапе уделить внимание проектированию архитектуры и расчету ресурсов. Недооценка объема логов, скорости их поступления и требований к хранению может привести к проблемам производительности и масштабирования. На собственном опыте можем посоветовать к любой рассчитанной цифре объема ресурсов будущего кластера прибавлять еще 30%.
Во-вторых, стоит заранее продумать схему индексов, политики хранения данных и жизненный цикл логов. Отсутствие четких правил ротации и архивирования быстро приводит к неконтролируемому росту хранилища и усложняет администрирование кластера.
В-третьих, механизм ISM удобен в использовании, однако уступает прямому управлению через API с точки зрения гибкости и контроля. Для реализации сложных сценариев и оптимизации процессов следует быть готовым к использованию пользовательских скриптов с применением API OpenSearch.
Отдельное внимание следует уделять надежности доставки данных. Использование механизмов гарантированной доставки и буферизации на стороне источников логов значительно снижает риски потери событий.
Подводя итоги, можем сказать, что мы успешно завели логи шести разных СЗИ c гарантией доставки на OpenSearch и построили по ним информативные дашборды с агрегированными данными. Дашборды позволяют анализировать в моменте или ретроспективе работу эшелонированной защиты заказчика, быстрее принимать решения на основе визуального анализа или даже сформировать отчет в формате png или pdf.
Пока что OpenSearch используется для нужд отдельных подразделений компании. В наших ближайших планах расширение кластера для подключения большего количества СЗИ и добавление дополнительных инструментов аналитики.
Авторы:
Артём Борзунов, старший инженер 1-й линии администрирования ГК «Солар»;
Владислав Дубровский, инженер автоматизации ГК «Солар»;
Наталья Кулакова, администратор информационной безопасности ГК «Солар».
