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

Ложь, наглая ложь и статистика

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

Формулирование таких метрик и понимание их изменения помогает сразу по нескольким фронтам. Во-первых, исполнитель всегда может оценить прогресс и наглядно продемонстрировать руководству что и насколько улучшено (или ухудшено), с актуальными «здесь и сейчас» цифрами. Ура, нет больше ночных бдений «срочно предоставить к утру отчет о том что сделано по этой проблеме» — отчёты доступны здесь и сейчас в любой момент.

Во-вторых, самому сотруднику для профилактики выгорания и получения обратной связи о своей работе важно иметь возможность оценить, что и как изменилось в результате его труда. Это особенно важно в деятельности по эксплуатации и настройке систем, где часто нет четкой финальной точки (типа «построил дом — завершил проект»), а есть бесконечный непрерывный процесс, и без понимания его прогресса может возникать впечатление что работа не приносит результатов, что она неисчерпаема и как будто топчется на месте.

Предположим, внедряется процесс управления учетными записями в AD — настраиваются политики, вычищаются старые или ненужные записи, настраиваются параметры безопасности. Как оценить насколько сегодня ситуация лучше чем была месяц назад? Безопасник нашел и поставил задачу исправить N записей, за это время админы сделали M новых, что в целом по ситуации? Какова её оценка и как она изменилась?

Другой практический пример — управление обновлениями Windows хостов при помощи WSUS. Насколько сегодня уровень покрытия инфраструктуры апдейтами лучше чем два месяца назад? Не стало ли хуже из-за раздолбайства смежных подразделений, или выхода апдейта с ошибками установки? Ситуация в целом исправляется или наоборот, движется в ад? А что, патчи в этом месяце раскатываются с обычной динамикой, или что-то идёт нештатно?

Третий пример — некая система управления агентами на хостах, показывающая в реальном времени статус сервера (онлайн-оффлайн), но не хранящая истории этих состояний. Как узнать (с достаточной точностью в 1-2 часа) когда хост светился в системе в последний раз?

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

Достаём подарки из-под ёлки

Основная идея этого kenk-велосипеда заключается в том, чтобы регулярно и автоматически собирать (или выгружать) из информационных систем данные, и после этого хранить и анализировать их с помощью ELK Stack.

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

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

Картинки и примеры

Приведу пару визуальных примеров. В картинках ниже конкретные цифры (показатели) и временные отметки на скриншотах удалены по причине NDA

Пример 1. Графики изменения во времени на группе хостов метрик «процент обновлённых назначенными патчами машин» и «процент машин, требующих перезагрузки для завершения обновления». Вы никогда не получите эти данные из WSUS, потому что он не хранит историю состояний хостов

Пример 2. График изменения во времени на группе хостов количества установленных экземпляров Chrome разных версий. Здесь красиво видно, как по мере выпуска патчей одна версия Chrome сменяет на группе хостов другую. Вы не получите эти данные, если ваша система учёта ПО на хостах этого не умеет (данные для графика получены из отчетов Kaspersky Security Center)

Общее описание архитектуры

Итак, как такое устроить?

• регулярно генерим по расписанию данные о системе (сгружаем из неё через апи или парсим штатные отчёты системы)
• обогащаем эти данные информацией из смежных систем и добавляем сведения и метрики, которых нет в исходных данных
• записываем всё в json файлы
• установленный на хосте-анализаторе filebeat подхватывает дамп и отсылает в Elasticsearch
• настроенные в Kibana дашборды отображают красоту и позволяют формировать отчёты играя параметрами (наборы хостов, время выборки, прочие фильтры)

kenk-дисклеймер

Этот подход рожден и работоспособен в условиях, когда у вас есть набор информационных систем, возможности которых недостаточны для решения озвученных задач. Если ваша система всё это может (и в условиях дивной новой реальности вы можете эту систему продолжать покупать), сий велосипед не для вас.

Также, в полном соответствии с kenk-доктриной, решение потребует кровавого программинга на коленке и применения прочих костыльно-пластилиновых технологий. Если вы не готовы к таким жертвам — решение не для вас