Аудит баз данных в сети, часть 2: наблюдения после развертывания

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

Подготовленные операторы и фильтрация классов команд

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

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

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

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

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

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

Представление

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

Но нет ничего без плюсов и минусов.

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

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

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

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

Прошлые решения окупаются

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

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

Но мы также не хотели планировать, основываясь только на времени «нормальной работы».

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

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

Компромиссы

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

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

Мы решили, что наши бизнес-потребности будут в достаточной степени удовлетворены за счет использования гибкого ведения журналов в rsyslog, использования спула разумного размера и использования TCP для отправки событий в наш стек мониторинга журналов. Как и все в жизни, ничто не вечно. И мы понимаем, что это решение, возможно, придется пересмотреть в будущем.

Ну наконец то

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