Хранилище логов для облачной платформы. Опыт внедрения ELK

Источник ^[1]

Всем привет! Сегодня мы продолжим рассказывать про облачное хранилище Техносерв Cloud ^[2], но уже с точки зрения эксплуатации. Ни одна ИТ-инфраструктура не обходится без инструментов мониторинга и управления, и наше облако не исключение. Для решения повседневных задач, связанных с мониторингом, мы используем продукты с открытым исходным кодом, одним из которых является стек ELK ^[3]. В этой статье мы расскажем, как в нашем облаке устроен мониторинг журналов, и как ELK помог нам пройти аудит PCI DSS.

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

ELK – основной инструмент наших инженеров для просмотра логов платформы: в Elasticsearch собираются записи журналов со всех эксплуатируемых серверов и сетевого оборудования. Мы убеждены, что логов много не бывает, поэтому наши системы делают записи в журналы с максимальным уровнем отладки. Для получения событий используется Beats ^[4]: filebeat и winlogbeat, syslog и SNMP трапы. С сетевых устройств также собирается информация о трафике по протоколу Netflow. На сегодняшний день наш стек ELK обрабатывает около 1000 входящих записей в секунду с пиками до 10000 записей, при этом выделенных ресурсов по предварительным прогнозам должно хватить на 2-/3-кратное увеличение потока логов.

Архитектура

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

Так выглядит архитектура нашей инсталляции ELK:

Реализация

В качестве балансировщиков трафика используются HAproxy и nginx, их отказоустойчивость достигается при помощи keepalived ^[5] – приложения, реализующего протокол маршрутизации VRRP (Virtual Router Redundancy Protocol). Keepalived настроен в простой конфигурации из master и backup нод, таким образом, входящий трафик приходит на ноду, которой в настоящий момент принадлежит виртуальный IP адрес. Дальнейшая балансировка трафика в Logstash и Elasticsearch осуществляется по алгоритму round-robin ^[6] (все так же используем простые решения).

Для Logstash и Elasticseach отказоустойчивость достигается избыточностью: система продолжит корректно работать даже в случае выхода из строя нескольких серверов. Подобная схема проста в настройке и позволяет легко масштабировать каждый из установленных компонентов стека.

Сейчас мы используем четыре Logstash сервера, каждый из которых выполняет полный цикл обработки входных данных. В ближайшее время планируем разделить сервера Logstash по ролям Input и Filter, а также добавить кластер RabbitMQ для буферизации данных, отправляемых из Logstash. Использование брокера сообщений позволит исключить риски потери данных в случае разрыва соединения между Logstash и Elasticsearch.
Конфигурация Elasticsearch у нас также проста, мы используем три master ноды и шесть data нод.

Kibana – единственный компонент, который не резервируется, так как выход «кибаны» из строя не влияет на процессы сбора и обработки логов. Для ограничения доступа к консоли используется kibana-auth-plugin ^[7], а при помощи плагина Elastic HQ ^[8] мы можем наблюдать за состоянием кластера Elasticsearch в веб-интерфейсе.

^[9]

Netflow

Как было отмечено выше, помимо логов, мы собираем статистику Netflow ^[10] при помощи коробочного плагина logstash ^[11]. Настроенные представления помогают дежурным администраторам получать актуальные данные о трафике. Для диагностики сетевых проблем это важный инструмент, так как Netflow позволяет получить детальную информацию о потоках трафика внутри сети в тех случаях, когда логов сетевого оборудования недостаточно. На скриншоте ниже видно представление Kibana для Netflow: диаграммы показывают адреса, участвующие в обмене трафиком, и объем принятых/переданных данных.

^[12]

Контроль событий ИБ

В мае текущего года мы решали задачу прохождения сертификации PCI DSS ^[13] — стандарту безопасности данных индустрии платежных карт. Одним из требований соответствия данному стандарту является наличие системы контроля событий информационной безопасности. На момент прохождения сертификации стек ELK уже работал и собирал данные с большей части эксплуатируемого оборудования, поэтому было принято решение использовать его в качестве системы контроля событий ИБ. В ходе подготовки к аудиту, для всех системных компонентов Техносерв Cloud была настроена отправка в ELK событий безопасности, в том числе следующих:

• любой доступ к данным заказчиков;
• все действия, совершенные с использованием административных полномочий, на серверах и сетевом оборудовании облачной платформы;
• любой доступ к журналам регистрации событий системных компонентов Техносерв Cloud;
• любой доступ пользователей к системным компонентам платформы;
• добавление, изменение и удаление учетных записей;
• запуск и остановка системных компонентов платформы;
• создание и удаление объектов системного уровня.

Для демонстрации наличия перечисленных выше событий в системе были подготовлены представления Kibana. На скриншотах ниже видны попытки доступа пользователей на наши сервера и записи о выполнении команд из-под sudo.

^[14]
Зафиксированные неуспешные попытки доступа

Автор: TS_Cloud

Источник ^[15]