MariaDB
 sql >> база данни >  >> RDS >> MariaDB

Съвети и трик за използване на регистриране на одит за MariaDB

Приставката за одит на MariaDB предоставя функция за одит не само за MariaDB, но и за MySQL (от версии 5.5.34 и 10.0.7) и Percona Server. MariaDB стартира включването по подразбиране на Audit Plugin от версии 10.0.10 и 5.5.37 и може да се инсталира във всяка версия от MariaDB 5.5.20.

Целта на MariaDB Audit Plugin е да регистрира активността на сървъра. За всяка клиентска сесия той записва кой се е свързал със сървъра (т.е. потребителско име и хост), какви заявки са били изпълнени и кои таблици са били достъпни и променливи на сървъра, които са били променени. Тази информация се съхранява в ротационен регистрационен файл или може да бъде изпратена до локалния syslogd.

В тази публикация в блога ще ви покажем някои най-добри практики настройки и съвети как да конфигурирате регистриране на одит за сървър на MariaDB. Писането е базирано на MariaDB 10.5.9, с най-новата версия на MariaDB Audit Plugin 1.4.4.

Настройка на инсталацията

Препоръчителният начин да активирате регистрирането на одит е чрез задаване на следните редове в конфигурационния файл на MariaDB:

[mariadb]
plugin_load_add = server_audit # load plugin
server_audit=FORCE_PLUS_PERMANENT  # do not allow users to uninstall plugin
server_audit_file_path=/var/log/mysql/mariadb-audit.log # path to the audit log
server_audit_logging=ON  # enable audit logging

Не забравяйте да зададете "server_audit=FORCE_PLUS_PERMANENT", за да наложи регистрационния файл за одит и да забраните деинсталирането му от други потребители с помощта на оператора UNINSTALL SONAME. По подразбиране дестинацията за регистриране е регистрационен файл в директорията с данни на MariaDB. Трябва да поставим регистрационния файл за одит извън тази директория, защото има вероятност datadir да бъде изтрит (SST за Galera Cluster) или да бъде заменен за физическо възстановяване, като размяна на datadir при възстановяване на архив, взет от MariaDB Backup.

Необходима е допълнителна настройка, както е показано в следващите раздели.

Филтриране на одитни събития

Плъгинът MariaDB Audit използва няколко настройки на журнала, които зависят от версията на приставката. Следните събития за одит са налични в най-новата версия на приставката 1.4.4:

Тип

Описание

СВЪРЗВАНЕ

Свързва, прекъсва и неуспешно свързване, включително кода за грешка

ЗАПИТВАНЕ

Изпълнени заявки и техните резултати в обикновен текст, включително неуспешни заявки поради грешки в синтаксиса или разрешения

ТАБЛИЦА

Таблици, засегнати от изпълнението на заявка

QUERY_DDL

Подобно на QUERY, но филтрира само заявки от DDL тип (изрази CREATE, ALTER, DROP, RENAME и TRUNCATE - с изключение на CREATE/DROP [PROCEDURE / FUNCTION / USER] и RENAME USER (те не са DDL)

QUERY_DML

Подобно на QUERY, но филтрира само заявки от тип DML (DO, CALL, LOAD DATA/XML, DELETE, INSERT, SELECT, UPDATE, HANDLER и REPLACE изрази)

QUERY_DML_NO_SELECT

Подобно на QUERY_DML, но не регистрира SELECT заявки. (от версия 1.4.4) (Изрази DO, CALL, LOAD DATA/XML, DELETE, INSERT, UPDATE, HANDLER и REPLACE)

QUERY_DCL

Подобно на QUERY, но филтрира само заявки от тип DCL (изрази CREATE USER, DROP USER, RENAME USER, GRANT, REVOKE и SET PASSWORD)

По подразбиране ще проследява всичко, тъй като променливата server_audit_events ще бъде настроена на празна по подразбиране. Имайте предвид, че по-старите версии имат по-малко поддръжка за горния тип операция, както е показано тук. Затова се уверете, че използвате най-новата версия, ако искате да направите конкретно филтриране.

Ако кешът на заявките е активиран и се връща заявка от кеша на заявките, в регистрационния файл няма да се появят TABLE записи, тъй като сървърът не е отварял или е осъществявал достъп до таблици, а вместо това разчита на кешираните резултати. Така че може да искате да деактивирате кеширането на заявки.

За да филтрирате конкретни събития, задайте следния ред в конфигурационния файл на MariaDB (изисква рестартиране):

server_audit_events = 'CONNECT,QUERY,TABLE'

Или го задайте динамично по време на изпълнение, като използвате SET GLOBAL (не изисква рестартиране, но не и постоянно):

MariaDB> SET GLOBAL server_audit_events = 'CONNECT,QUERY,TABLE';

Това е примерът за едно одитно събитие:

20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,226,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0

Записът в този регистър се състои от куп информация, разделена със запетая, съдържаща следната информация:

  • Частово клеймо

  • Хостът на MySQL (идентичен със стойността на SELECT @@hostname)

  • Потребителят на базата данни

  • Хост, където потребителят се свързва

  • Идент. № на връзката

  • Идент. № на нишката

  • Операция

  • База данни

  • SQL изявление/команда

  • Код за връщане. 0 означава, че операцията връща успешен отговор (дори празен), докато стойност, различна от нула, означава грешка при изпълнението на операцията като неуспешна заявка поради грешки в синтаксиса или разрешенията.

Когато филтрирате записите, човек ще направи прост grep и ще търси конкретен модел:

$ grep -i global /var/lib/mysql/server_audit.log
20210325 04:19:17,ip-172-31-0-44,root,localhost,14,37080,QUERY,,'set global server_audit_file_rotate_now = 1',0
20210326 00:46:48,ip-172-31-0-44,root,localhost,35,329003,QUERY,,'set global server_audit_output_type = \'syslog\'',0

По подразбиране всички стойности на паролите ще бъдат маскирани със звездички:

20210326 05:39:41,ip-172-31-0-44,root,localhost,52,398793,QUERY,mysql,'GRANT ALL PRIVILEGES ON sbtest.* TO [email protected] IDENTIFIED BY *****',0

Проверка на потребителско филтриране

Ако проследявате всичко, вероятно ще бъдете наводнени от потребителя за наблюдение за неговата отговорност за вземане на проби, както е показано в примера по-долу:

20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,226,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,227,QUERY,information_schema,'select @@global.wsrep_provider_options',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,228,QUERY,information_schema,'SHOW SLAVE STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,229,QUERY,information_schema,'SHOW MASTER STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,230,QUERY,information_schema,'SHOW SLAVE HOSTS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,231,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,232,QUERY,information_schema,'select @@global.wsrep_provider_options',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,233,QUERY,information_schema,'SHOW SLAVE STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,234,QUERY,information_schema,'SHOW MASTER STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,235,QUERY,information_schema,'SHOW SLAVE HOSTS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,5,236,QUERY,information_schema,'SET GLOBAL SLOW_QUERY_LOG=0',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,5,237,QUERY,information_schema,'FLUSH /*!50500 SLOW */ LOGS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,6,238,QUERY,information_schema,'SHOW GLOBAL STATUS',0

В рамките на една секунда можем да видим 14 събития QUERY, записани от плъгина за одит за нашия потребител за наблюдение, наречен "cmon". При нашето тестово натоварване скоростта на регистриране е около 32 KB на минута, което ще натрупа до 46 MB на ден. В зависимост от размера на съхранение и IO капацитета, това може да бъде прекомерно при някои работни натоварвания. Така че би било по-добре да филтрираме наблюдаващия потребител от регистрирането на одита, за да можем да имаме по-чист изход и е много по-лесно за одит и анализ.

В зависимост от политиките за сигурност и одит, бихме могли да филтрираме нежелания потребител като наблюдаващия потребител, като използваме следната променлива в конфигурационния файл на MariaDB (изисква рестартиране):

server_audit_excl_users='cmon'

Или го задайте динамично по време на изпълнение, като използвате SET GLOBAL (не изисква рестартиране, но не и постоянно):

MariaDB> SET GLOBAL server_audit_excl_users = 'cmon'

Можете да добавите множество потребители на база данни, разделени със запетая. След като добавихме горното, получихме по-чисти журнали за одит, както е по-долу (вече нищо от потребителя на 'cmon'):

$ tail -f /var/log/mysql/mysql-audit.log
20210325 04:16:06,ip-172-31-0-44,cmon,172.31.1.119,6,36218,QUERY,information_schema,'SHOW GLOBAL STATUS',0
20210325 04:16:06,ip-172-31-0-44,root,localhost,13,36219,QUERY,,'set global server_audit_excl_users = \'cmon\'',0
20210325 04:16:09,ip-172-31-0-44,root,localhost,13,36237,QUERY,,'show global variables like \'%server_audit%\'',0
20210325 04:16:12,ip-172-31-0-44,root,localhost,13,0,DISCONNECT,,,0

Управление на ротацията на регистрационните файлове

Тъй като дневникът за одит ще улови огромен брой събития, се препоръчва да конфигурирате правилна ротация на дневника за него. В противен случай щяхме да получим огромен размер на лог файл, което го прави много труден за анализ. Докато сървърът работи и server_audit_output_type=file, можем да принудим ротацията на логфайла, като използваме следното изявление:

MariaDB> SET GLOBAL server_audit_file_rotate_now = 1;

За автоматично завъртане на журнала трябва да зададем следните променливи в конфигурационния файл на MariaDB:

server_audit_file_rotate_size=1000000 # in bytes
server_audit_file_rotations=30

Или го задайте динамично по време на изпълнение, като използвате SET GLOBAL (не изисква рестартиране):

MariaDB> SET GLOBAL server_audit_file_rotate_size=1000000;
MariaDB> SET GLOBAL server_audit_file_rotations=30;

За да деактивирате ротацията на регистрационния файл за одит, просто задайте server_audit_file_rotations на 0. Стойността по подразбиране е 9. Редуването на регистрационния файл ще се случи автоматично, след като достигне посочения праг и ще запази последните 30 регистрационни файлове, което означава, че регистриране на одит за последните 30 дни.

Одит с помощта на Syslog или Rsyslog Facility

Използването на функцията syslog или rsyslog ще улесни управлението на регистрационни файлове, тъй като позволява регистрирането от различни типове системи в централно хранилище. Вместо да поддържаме друг компонент за регистриране, можем да инструктираме MariaDB Audit да влезе в syslog. Това е удобно, ако имате колектор/стример за регистрационни файлове за услуги за анализатор на логове като Splunk, LogStash, Loggly или Amazon CloudWatch.

За да направите това, задайте следните редове в конфигурационния файл на MariaDB (изисква рестартиране):

server_audit_logging = 'syslog'
server_audit_syslog_ident = 'mariadb-audit'

Или ако искате да промените времето за изпълнение (не изисква рестартиране, но не и постоянно):

MariaDB> SET GLOBAL server_audit_logging = 'syslog';
MariaDB> SET GLOBAL server_audit_syslog_ident = 'mariadb-audit';

Записите ще бъдат подобни на формата на Syslog:

$ grep mariadb-audit /var/log/syslog
Mar 26 00:48:49 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,36,329540,QUERY,,'SET GLOBAL server_audit_syslog_ident = \'mariadb-audit\'',0
Mar 26 00:48:54 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,36,0,DISCONNECT,,,0

Ако искате да настроите услуга за отдалечено регистриране за централизирано хранилище за регистриране, можем да използваме rsyslog. Номерът е да използваме променливата server_audit_syslog_facility, където можем да създадем филтър за улесняване на регистрирането, подобно на по-долу:

MariaDB> SET GLOBAL server_audit_logging = 'syslog';
MariaDB> SET GLOBAL server_audit_syslog_ident = 'mariadb-audit';
MariaDB> SET GLOBAL server_audit_syslog_facility = 'LOG_LOCAL6';

Въпреки това, има някои предварителни стъпки. Помислете за следната архитектура на MariaDB главен-подчинен репликация с централизиран rsyslog сървър:

В този пример всички сървъри работят на Ubuntu 20.04. На дестинационния сървър rsyslog трябва да зададем следното в /etc/rsyslog.conf:

module(load="imtcp")
input(type="imtcp" port="514")
$ModLoad imtcp
$InputTCPServerRun 514
if $fromhost-ip=='172.31.0.44' then /var/log/mariadb-centralized-audit.log
& ~
if $fromhost-ip=='172.31.0.82' then /var/log/mariadb-centralized-audit.log
& ~

Обърнете внимание, че частта "&~" е важна и не го пропускайте. По същество той казва на съоръжението за регистриране да влезе в /var/log/mariadb-centralized-audit.log и да спре по-нататъшната обработка веднага след това.

След това създайте регистрационния файл на местоназначението с правилната собственост на файла и разрешение:

$ touch /var/log/mariadb-centralized-audit.log
$ chown syslog:adm /var/log/mariadb-centralized-audit.log
$ chmod 640 /var/log/mariadb-centralized-audit.log

Рестартирайте rsyslog:

$ systemctl restart rsyslog

Уверете се, че слуша на всички достъпни IP адреси на TCP порт 514:

$ netstat -tulpn | grep rsyslog
tcp        0      0 0.0.0.0:514             0.0.0.0:*               LISTEN      3143247/rsyslogd
tcp6       0      0 :::514                  :::*                    LISTEN      3143247/rsyslogd

Завършихме конфигурирането на целевия rsyslog сървър. Сега сме готови да конфигурираме изходната част. На сървъра MariaDB създайте нов отделен конфигурационен файл rsyslog в /etc/rsyslog.d/50-mariadb-audit.conf и добавете следните редове:

$WorkDirectory /var/lib/rsyslog # where to place spool files
$ActionQueueFileName queue1     # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g     # 1GB space limit (use as much as possible)
$ActionQueueSaveOnShutdown on   # save messages to disk on shutdown
$ActionQueueType LinkedList     # run asynchronously
$ActionResumeRetryCount -1      # infinite retries if rsyslog host is down
local6.* action(type="omfwd" target="172.31.6.200" port="514" protocol="tcp")

Настройките в първия раздел се отнасят за създаване на опашка на диска, което се препоръчва, за да не се загуби никакви записи в регистрационния файл. Последният ред е важен. Променихме променливата server_audit_syslog_facility на LOG_LOCAL6 за приставката за одит. Тук посочихме „local6.*“ като филтър за препращане само на записи в Syslog, използвайки средство local6 към rsyslog, работещо на rsyslog сървъра 172.31.6.200, на порт 514 чрез TCP протокол.

За да активирате промените за rsyslog, последната стъпка е да рестартирате rsyslog на сървъра на MariaDB, за да активирате промените:

$ systemctl restart rsyslog

Сега rsyslog е правилно конфигуриран на изходния възел. Можем да тестваме чрез достъп до сървъра на MariaDB и извършваме някои дейности за генериране на одитни събития. Трябва да видите, че записите в регистъра на одита се препращат тук:

$ tail -f /var/log/mariadb-centralized-audit.log
Mar 26 12:56:18 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,69,0,CONNECT,,,0
Mar 26 12:56:18 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,69,489413,QUERY,,'select @@version_comment limit 1',0
Mar 26 12:56:19 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,69,489414,QUERY,,'show databases',0
Mar 26 12:56:37 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,69,0,DISCONNECT,,,0

Последни мисли

MariaDB Audit Plugin може да бъде конфигуриран по много начини, за да отговаря на вашите политики за сигурност и одит. Информацията за одит може да ви помогне да отстраните проблеми с производителността или приложенията и ви позволява да видите какви точно SQL заявки се обработват.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Как ELT() работи в MariaDB

  2. Как работи UNHEX() в MariaDB

  3. Как да открием дали дадена стойност съдържа поне една цифрова цифра в MariaDB

  4. Разлика между TRIM() и TRIM_ORACLE() в MariaDB

  5. Как да използвате механизма за отказване на MaxScale