Аудит баз данных в сети

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

Это также затронуло некоторые хранилища данных, которым требовалось много времени безотказной работы, и было желательно онлайн-развертывание (без простоев для записи). Имея под рукой внешний крайний срок и зная масштаб проекта, мы приступили к составлению плана.

На этапе планирования мы определили несколько открытых вопросов, на которые нам нужно было найти ответы:

1. Какие у нас есть варианты программного обеспечения, которое может это сделать?
2. Какое влияние на производительность ожидается и насколько мы можем его протестировать заранее?
3. Можем ли мы сделать это без простоя для доступности записи?

Выбор, выбор

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

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

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

Этот проект был необычен тем, что я одновременно писал его и исследовал, каким должно быть решение бизнес-задачи. Так что я знал, что многие детали будут заполнены, когда мы проведем небольшое исследование.

Нашими вариантами были:

• Плагин аудита Percona
• Аудит Mcafee MySQL

Хотя это не единственные варианты на рынке, мы посчитали, что они наиболее близки к нашему масштабу и практикам devops, чтобы гарантировать их включение в фактическую подготовку. Другие коммерческие варианты на рынке не прошли эту планку для включения в бенчмарк.

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

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

Выпечка

С помощью нашей партнерской команды в Pythian мы начали сравнение результатов. Сначала мы сравнили, как установить и настроить каждый вариант. Команда быстро определила, что у нас есть компромисс. Хотя подключаемый модуль Mcafee изначально поддерживал фильтры таблиц, он не поддерживал использование rsyslog в качестве метода потоковой передачи своих событий. Это означало, что если бы мы использовали его, нам пришлось бы локально записывать файлы на диск и управлять их отправкой в ​​стек мониторинга.

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

С другой стороны компромиссом стал плагин Percona. Он изначально поддерживает отправку событий в системный журнал, но не предлагает никаких фильтров таблиц. Мы знали, что это означает, что более загруженные кластеры в области действия будут отправлять большое количество событий, большинство из которых на самом деле не из таблиц, которые мы хотим проверить. Это представляло риск для уровня syslog-receive/logstash стека мониторинга InfoSec. Поскольку у DB ops нет доступа к этому, это означало, что успех этого проекта был результатом совместного владения.

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

Планирование развертывания

Объем установки

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

Без простоев

Мы хотели сделать это беспрепятственным развертыванием без простоев в затронутых кластерах. Это значительно сократит объем планирования и координации, которые нам придется выполнять с группами доставки, использующими эти кластеры, и значительно уменьшит влияние на клиентов. Но мы также хотели, чтобы подключаемый модуль отправлял свои события в rsyslog на определенном объекте с настраиваемой конфигурацией, которая отправляла бы события на сервер агрегации системных журналов команды InfoSec. Некоторые из этих конфигураций задокументированы Percona как нединамические, и это давало возможность того, что каждый экземпляр в рамках этого проекта подвергнется некоторому простою, поскольку мы перезапускаем экземпляр mysql с требуемой конфигурацией плагина аудита.

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

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

Используйте управление конфигурацией

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

Для управления базами данных MySQL мы используем модель кулинарной книги-оболочки для управления конфигурацией. Основная «базовая» поваренная книга определяет большую часть того, как должен выглядеть экземпляр базы данных, а поваренная книга для каждого кластера оборачивает это, чтобы изменить атрибуты или добавить конфигурацию, относящуюся к конкретному кластеру. Этот дизайн упростил добавление основной части кода, создающего необходимые файлы конфигурации, а затем загружающего плагин в один новый рецепт, который мы затем можем включать и выключать на основе атрибута шеф-повара. Мы также решили, учитывая объем вносимых нами изменений, что это гарантирует выпуск этого кода в качестве новой второстепенной версии поваренной книги.

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

Мониторинг

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

• Мы должны все согласовать явный объем владения в этой системе, тем более что она охватывает обязанности двух команд с отдельными ротациями по вызову.
• Любые новые проверки, добавленные для этого, должны поставляться с модулем Runbook, на который мы ссылаемся в проверке, с объяснением того, что эта проверка дает сбой и как это исправить.

Учитывая эти два правила, я добавил очень конкретные проверки. В этот момент я подумал также о добавлении сквозной «синтетической» проверки, но с тех пор я воздерживался от этого, поскольку сквозная проверка здесь не смогла бы сказать нам, какая именно часть системы вышла из строя, а это означает, что у нас будет жесткая проверка. время даже пейджинг правой команды с ним. И я не сторонник пейджинговых сообщений по ночам "на всякий случай"

Мы решили следить за следующим:

• Проверьте живую конфигурацию mysql плагина аудита, чтобы убедиться, что
  • Плагин был в активном состоянии
  • Для параметра audit_log_policy задано значение QUERIES .

Эта проверка подтверждает, что конфигурация БД в области видимости не изменялась на лету, поскольку эти настройки являются динамическими и могут изменяться за пределами файла my.cnf на диске .

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

Препятствия на пути

Конфигурация плагина аудита

Одна из первоначальных итераций этого проекта предназначалась для использования функции audit_log_exclude_commands , чтобы ограничить события, которые мы выдаем, только манипулированием данными или схемой. Мы быстро поняли, что список, на котором основана эта конфигурация, намного длиннее, чем можно было бы ожидать.

конфигурация rsyslog

Вот то, чего я не знал до этого проекта. Конфигурация Rsyslog — это почти отдельный язык. Например:

• Используйте второй символ @ перед удаленным пунктом назначения, чтобы отправлять журналы по протоколу TCP вместо UDP. Мы хотели использовать это средство, чтобы дать немного больше гарантий доставки журналов.
• В rsyslog есть специальная страница о том, как настроить его для надежной переадресации, что оказалось действительно полезным для новичка в этом инструменте, такого как я.
• rsyslog по умолчанию также отправляет свои данные в /var/log/messages , что было нежелательно в моем случае, потому что это МНОГО событий. Если вам нужно, чтобы средство, которое вы используете, НЕ делало этого, вы должны добавить local5.* ~ в конец вашей конфигурации .

Пожарная дрель

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

• Подтвердите, что события аудита передаются через назначенный TCP-порт.
• Используйте правило iptables, чтобы отбросить весь трафик на этом порту /sbin/iptables -A OUTPUT -p tcp –dport {PORT-NUMBER-HERE} -j DROP
• Наблюдайте за активностью записи на диск и файлами в настроенном WorkDirectory в конфигурации rsyslog. Имена файлов будут основаны на ActionQueueFileName объекта, получающего эти события.

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

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

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