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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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