MariaDB
 sql >> Baza danych >  >> RDS >> MariaDB

Korzystanie z wtyczki dziennika audytu Percona do zabezpieczania baz danych

Dlaczego musisz używać wtyczki audytu dla swojej bazy danych?

Kontrola w bazie danych nie odbiega od jej znaczenia, ponieważ ma tę samą konotację, tj. Inspekcję, badanie i ocenę takich zdarzeń/transakcji bazy danych, które są rejestrowane lub wykonywane w Twojej bazie danych. W rzeczywistości zwiększa to wykonalność dla baz danych, zwłaszcza jako funkcja bezpieczeństwa, ponieważ zaleca, aby strona administracyjna była wrażliwa na zarządzanie danymi i ich przetwarzanie. Obejmuje odpowiedzialność i odpowiedzialność za zarządzanie danymi.

Audyt bazy danych wymaga, aby każda transakcja (tj. DDL i DML) była rejestrowana, aby rejestrować ślady i uzyskać pełny przegląd tego, co dzieje się podczas operacji na bazie danych. Te operacje mogą uwzględniać następujące kwestie:

  • Zapewnia możliwość monitorowania i debugowania w celu zwiększenia wydajności po stronie aplikacji
  • Bezpieczeństwo i zgodność z prywatnością danych, np. PCI DSS, HIPAA, RODO itp.
  • Zapewnia możliwość autonomii danych charakterystycznej dla środowisk z wieloma dzierżawcami. Pozwala im to na analizę danych w celu rozróżnienia i filtrowania transakcji na podstawie wrażliwości i prywatności pod kątem bezpieczeństwa i wydajności.
  • Kieruje działaniami administracyjnymi, aby uniemożliwić użytkownikom bazy danych wykonywanie nieodpowiednich działań w oparciu o podejrzaną aktywność dochodzeniową lub ograniczone przez swoją rolę. Oznacza to, że użytkownicy odczytujący, na przykład, powinni mieć prawo tylko do pobierania danych i tylko ograniczonego dostępu do określonych baz danych, za które są odpowiedzialni lub w ograniczonym zakresie zgodnie z ich rolą zawodową.

Co to jest wtyczka dziennika audytu Percona?

Poprzednie podejścia do audytu transakcji lub zdarzeń działających w Twojej bazie danych mogą być trudnym podejściem. Włączenie ogólnego pliku dziennika lub użycie wolnego dziennika zapytań. Nie jest to idealne podejście, więc wtyczka dziennika audytu zapewnia większą elastyczność i konfigurowalne parametry, aby wypełnić lukę. Percona twierdzi, że ich wtyczka dziennika audytu jest alternatywą dla MySQL Enterprise Audit. Chociaż to prawda, istnieje zastrzeżenie, że wtyczka dziennika audytu Percony nie jest dostępna do instalacji dla Oracle MySQL. Ten plik binarny nie jest dostępny do pobrania, ale można go łatwo zainstalować, po prostu kopiując istniejący plik audit_log.so z istniejącej instalacji Percona Server lub Percona XtraDB Cluster. Najlepiej zalecić użycie lub skopiowanie istniejącego pliku audit_log.so tej samej wersji Percona Server z wersją społecznościową MySQL. Jeśli więc docelową wersją społeczności MySQL jest 8.x, użyj również audit_log.so z wersji Percona Server 8.x. W dalszej części tego bloga pokażemy, jak to zrobić w społecznościowej wersji MySQL.

Wtyczka dziennika audytu Percona jest oczywiście oprogramowaniem typu open source i jest dostępna bezpłatnie. Jeśli więc Twoja aplikacja korporacyjna korzysta z wewnętrznej bazy danych, takiej jak Percona Server lub waniliowy MySQL, możesz użyć tej wtyczki. MySQL Enterprise Audit jest dostępny tylko dla MySQL Enterprise Server i jest dostępny w cenie. Ponadto Percona stale aktualizuje i konserwuje to oprogramowanie, co stanowi ogromną zaletę, ponieważ dostępna jest jakakolwiek większa wersja wcześniejszego MySQL. Percona wyda również w oparciu o swoją główną wersję, co będzie miało wpływ na aktualizacje i przetestowane funkcje, a także na narzędzie wtyczki dziennika audytu. Dlatego wszelkie niezgodności z poprzednimi wersjami powinny być również aktualizowane, aby działały z najnowszą i bezpieczną wersją MySQL.

Wtyczka dziennika audytu Percona jest oznaczona jako jedno z narzędzi bezpieczeństwa, ale wyjaśnijmy to ponownie. To narzędzie służy do kontroli dzienników. Jego jedynym celem jest rejestrowanie śladów transakcji z Twojej bazy danych. Nie stosuje zapory ani nie stosuje środków zapobiegawczych w celu blokowania określonych użytkowników. To narzędzie służy głównie do audytu logów i wykorzystania do analizy transakcji w bazie danych.

Korzystanie z wtyczki dziennika audytu Percona

W tej sekcji omówimy, jak zainstalować, używać i jak korzystna może być wtyczka, szczególnie w rzeczywistych sytuacjach.

Instalowanie wtyczki

Percona posiada różne źródła plików binarnych swojej bazy danych. Po prawidłowym zainstalowaniu serwera bazy danych standardowa instalacja umieści obiekt współdzielony wtyczki dziennika audytu w /usr/lib64/mysql/plugin/audit_log.so. Zainstalowanie wtyczki jako sposobu na jej włączenie na serwerze Percona/MySQL można wykonać, wykonując poniższe czynności. Te czynności wykonuje się za pomocą Percona Server 8.0,

mysql> select @@version_comment, @@version\G

*************************** 1. row ***************************

@@version_comment: Percona Server (GPL), Release 12, Revision 7ddfdfe

        @@version: 8.0.21-12

1 row in set (0.00 sec)

W takim razie kroki są następujące:

  1. Najpierw sprawdź, czy wtyczka istnieje, czy nie

## Sprawdź, czy wtyczka jest włączona lub zainstalowana

mysql> select * from information_schema.PLUGINS where PLUGIN_NAME like '%audit%';

Empty set (0.00 sec)



mysql> show variables like 'audit%';

Empty set (0.00 sec)

  1. Zainstaluj wtyczkę

## Sprawdź, gdzie znajdują się wtyczki

mysql> show variables like 'plugin%';

+---------------+--------------------------+

| Variable_name | Value                    |

+---------------+--------------------------+

| plugin_dir    | /usr/lib64/mysql/plugin/ |

+---------------+--------------------------+

1 row in set (0.00 sec)



mysql> \! ls -a /usr/lib64/mysql/plugin/audit_log.so

/usr/lib64/mysql/plugin/audit_log.so

## Gotowe i zainstaluj

mysql> INSTALL PLUGIN audit_log SONAME 'audit_log.so';

Query OK, 0 rows affected (0.01 sec)

  1. Zweryfikuj ponownie

mysql> select * from information_schema.PLUGINS where PLUGIN_NAME like '%audit%'\G

*************************** 1. row ***************************

           PLUGIN_NAME: audit_log

        PLUGIN_VERSION: 0.2

         PLUGIN_STATUS: ACTIVE

           PLUGIN_TYPE: AUDIT

   PLUGIN_TYPE_VERSION: 4.1

        PLUGIN_LIBRARY: audit_log.so

PLUGIN_LIBRARY_VERSION: 1.10

         PLUGIN_AUTHOR: Percona LLC and/or its affiliates.

    PLUGIN_DESCRIPTION: Audit log

        PLUGIN_LICENSE: GPL

           LOAD_OPTION: ON

1 row in set (0.00 sec)



mysql> show variables like 'audit%';

+-----------------------------+---------------+

| Variable_name               | Value         |

+-----------------------------+---------------+

| audit_log_buffer_size       | 1048576       |

| audit_log_exclude_accounts  |               |

| audit_log_exclude_commands  |               |

| audit_log_exclude_databases |               |

| audit_log_file              | audit.log     |

| audit_log_flush             | OFF           |

| audit_log_format            | OLD           |

| audit_log_handler           | FILE          |

| audit_log_include_accounts  |               |

| audit_log_include_commands  |               |

| audit_log_include_databases |               |

| audit_log_policy            | ALL           |

| audit_log_rotate_on_size    | 0             |

| audit_log_rotations         | 0             |

| audit_log_strategy          | ASYNCHRONOUS  |

| audit_log_syslog_facility   | LOG_USER      |

| audit_log_syslog_ident      | percona-audit |

| audit_log_syslog_priority   | LOG_INFO      |

+-----------------------------+---------------+

18 rows in set (0.00 sec)

Instalacja wtyczki Percona Audit w wersji społecznościowej MySQL

Podczas instalacji na wersjach Oracle MySQL, jak wspomnieliśmy powyżej, zawsze dopasuj do wersji Percona Server, z której pochodzi plik audit_log.so. Na przykład mam następujące wersje MySQL poniżej,

nodeB $  mysqld --version

/usr/sbin/mysqld  Ver 8.0.22 for Linux on x86_64 (MySQL Community Server - GPL)

Mój serwer Percona to

nodeA $ mysqld --version

/usr/sbin/mysqld  Ver 8.0.21-12 for Linux on x86_64 (Percona Server (GPL), Release 12, Revision 7ddfdfe)

Wszystko, co musisz zrobić, to skopiować ze źródła Percona na serwer, na którym masz zainstalowany MySQL Community Server.

nodeA $ scp /usr/lib64/mysql/plugin/audit_log.so nodeB:/tmp/

Następnie przejdź do /usr/lib64/mysql/plugin, dla którego mają być zlokalizowane wtyczki.

[email protected] > show global variables like 'plugin%';

+---------------+--------------------------+

| Variable_name | Value                    |

+---------------+--------------------------+

| plugin_dir    | /usr/lib64/mysql/plugin/ |

+---------------+--------------------------+

1 row in set (0.00 sec)



nodeB $ mv /tmp/audit_log.so /usr/lib64/mysql/plugin

Cała reszta, możesz wykonać czynności opisane powyżej, aby kontynuować instalację lub włączenie wtyczki logowania Percona Audit dla serwera społeczności MySQL.

Konfiguracja i zarządzanie wtyczką dziennika audytu Percona

Wtyczka dziennika audytu Percona jest bardzo elastycznym narzędziem, które można bardzo konfigurować lub dostosowywać do własnych wymagań podczas rejestrowania połączeń z bazą danych lub transakcji. Jest to implementacja w stylu liniowym dla danej konfiguracji, więc nawet jeśli można ją elastycznie dostosować za pomocą podanych parametrów, tylko te podane wartości będą rejestrowane i kontrolowane przez cały czas działania bazy danych i domyślnie odbywa się to asynchronicznie. Wszystkie zmienne parametrów w tej wtyczce są ważne, ale poniżej znajdują się najważniejsze parametry, których możesz użyć do konfiguracji wtyczki:

  • audit_log_strategy — Używany do określenia strategii dziennika kontroli i gdy audit_log_handler jest ustawiony na FILE. co może mieć jedną z następujących wartości: 
    • ASYNCHRONICZNY - (domyślnie) log przy użyciu bufora pamięci, nie usuwaj wiadomości, jeśli bufor jest pełny
    • PERFORMANCE - loguj używając bufora pamięci, usuwaj wiadomości jeśli bufor jest pełny
    • SEMISYNCHRONOUS - loguj bezpośrednio do pliku, nie opróżniaj i nie synchronizuj każdego zdarzenia
    • SYNCHRONICZNY - loguj się bezpośrednio do pliku, opróżniaj i synchronizuj każde zdarzenie
  • audit_log_file - Nazwa pliku, który ma być używany do przechowywania dzienników kontroli, domyślnie jest to plik ${datadir}/audit.log. Możesz użyć względnej ścieżki do pliku z datadir twojej bazy danych lub bezwzględnej ścieżki do pliku.
  • audit_log_flush - Przydatne, gdy trzeba opróżnić dziennik, np. w połączeniu z logrotate
  • audit_log_buffer_size - Domyślnie dziennik audytu Percona rejestruje ślady do domyślnego dziennika plików. Ta zmienna jest przydatna, gdy audit_log_handler =PLIK i audit_log_strategy =ASYCHRONICZNY lub WYDAJNOŚĆ. Gdy jest ustawiony, służy do określenia rozmiaru bufora pamięci używanego do logowania. Pozwala to uniknąć spadku wydajności, gdy włączone są logi audytu.
  • audit_log_format - Format, aby określić podczas rejestrowania lub zapisywania informacji w pliku dziennika kontroli. Akceptuje formaty STARY/NOWY (na podstawie formatu XML), JSON i CSV. Jest to bardzo przydatne, zwłaszcza gdy później dołączysz do innych zewnętrznych narzędzi, aby pobrać dzienniki kontrolne, które obsługują określone formaty.
  • audit_log_exclude_accounts /audit_log_include_accounts — Służy do określenia listy użytkowników, których można dołączyć lub wykluczyć, zgodnie z nazwą parametru. Akceptuje NULL, w przeciwnym razie listę oddzieloną przecinkami w formacie [email protected] lub 'użytkownik'@'host'. Te zmienne wzajemnie się wykluczają, więc jedna lub druga musi być nieustawiona (tj. wartość to NULL)
  • audit_log_include_commands /audit_log_exclude_commands  — służy do określania listy poleceń (w postaci NULL lub listy rozdzielanej przecinkami), dla których stosowane jest filtrowanie według typu polecenia SQL. Zmienne te wzajemnie się wykluczają, więc jedna lub druga musi być nieustawiona (tj. wartość to NULL). Aby uzyskać listę typów poleceń SQL w MySQL lub Percona, wykonaj następujące czynności:
    • włącz zmienną performance_schema=ON w swoim my.cnf (wymaga ponownego uruchomienia serwera bazy danych)
    • Uruchom następujące zapytanie:SELECT GROUP_CONCAT(SUBSTRING_INDEX(nazwa, '/', -1) ORDER BY nazwa) sql_statement FROM performance_schema.setup_instruments WHERE nazwa LIKE "statement/sql/%"\G
  • audit_log_include_databases /audit_log_exclude_databases — służy do określania filtrowania według nazwy bazy danych oraz w połączeniu z audit_log_{include,exclude}_commands do filtrowania listy poleceń, aby uzyskać bardziej szczegółowe dane podczas rejestrowania podczas audytu dzienników. Te zmienne wzajemnie się wykluczają, więc jedna lub druga musi być nieustawiona (tj. wartość to NULL).
  • audit_log_policy — Służy do określania, które zdarzenia mają być rejestrowane. Z technicznego punktu widzenia można ustawić tę zmienną dynamicznie, aby włączyć lub wyłączyć (ustawić wartość na BRAK) dla rejestrowania kontroli. Możliwe wartości to:
    • WSZYSTKIE - wszystkie zdarzenia będą rejestrowane
    • LOGINY - logowane będą tylko loginy
    • ZAPYTANIA — rejestrowane będą tylko zapytania
    • BRAK — żadne zdarzenia nie będą rejestrowane

Zarządzanie wtyczką dziennika audytu

Jak wspomniano, domyślny plik dziennika trafia do ${data_dir}/audit.log i używa formatu XML, tak jak mój przykład poniżej:

[[email protected] ~]# ls /var/lib/mysql/audit.log  | xargs tail -28

<AUDIT_RECORD

  NAME="Ping"

  RECORD="28692714_2020-10-28T19:12:18"

  TIMESTAMP="2020-10-29T09:39:56Z"

  COMMAND_CLASS="error"

  CONNECTION_ID="10"

  STATUS="0"

  SQLTEXT=""

  USER="cmon[cmon] @  [192.168.10.200]"

  HOST=""

  OS_USER=""

  IP="192.168.10.200"

  DB="information_schema"

/>

<AUDIT_RECORD

  NAME="Query"

  RECORD="28692715_2020-10-28T19:12:18"

  TIMESTAMP="2020-10-29T09:39:56Z"

  COMMAND_CLASS="show_status"

  CONNECTION_ID="10"

  STATUS="0"

  SQLTEXT="SHOW GLOBAL STATUS"

  USER="cmon[cmon] @  [192.168.10.200]"

  HOST=""

  OS_USER=""

  IP="192.168.10.200"

  DB="information_schema"

/>

Teraz zajmijmy się zarządzaniem wtyczką Percona Audit Log w prawdziwym scenariuszu. Zainspirowani pracą bloga Dani z Percony, rozważmy zmianę następujących zmiennych w my.cnf,

[[email protected] ~]# grep -i 'audit' /etc/my.cnf

## Audit Log

audit_log_format=JSON

audit_log_strategy=PERFORMANCE

audit_log_policy=QUERIES

audit_log_exclude_databases=s9s

Więc utwórzmy następującą bazę danych i tabele,

CREATE DATABASE s9s;

CREATE TABLE `audit_records` ( `id` int unsigned NOT NULL AUTO_INCREMENT,  `audit_record` json,   PRIMARY KEY (`id`) ) ENGINE=InnoDB;

Więc użyjmy nazwanego potoku lub FIFO w Linuksie do zebrania logów gotowych do audytu, ale których później możemy użyć w miarę możliwości. 

$ mkfifo /tmp/s9s_fifo

$ exec 1<>/tmp/s9s_fifo

$ tail -f /var/lib/mysql/audit.log 1>/tmp/s9s_fifo 2>&1

Then, let's insert any logs to our table `s9s`.`audit_records` using the following script below,

#/bin/bash

pipe=/tmp/s9s_fifo

while true; do

    if read line <$pipe; then 

if [[ "$line" == 'quit' ]]; then 

break

fi 

mysql --show-warnings -vvv -e "INSERT INTO s9s.audit_records (audit_record) VALUES(\"${line//\"/\\\"}\")" 

    fi

done

Potem spróbowałem uruchomić test porównawczy za pomocą sysbench. Teraz z następującymi wpisami, które mam,

mysql> select count(1) from audit_records\G

*************************** 1. row ***************************

count(1): 37856

1 row in set (0.11 sec)

Mogę przeprowadzać audyty za pomocą JSON, co umożliwia mi przeprowadzanie audytów i dochodzeń, a nawet analizy wydajności mojej bazy danych. Na przykład

mysql> SELECT top10_select_insert from ((select audit_record->"$.audit_record" as top10_select_insert from audit_records  where audit_record->"$.audit_record.command_class" in ('select') order by audit_records.id desc limit 10) union all (select audit_record->"$.audit_record" as top10_select_insert from audit_records  where audit_record->"$.audit_record.command_class" in ('insert')  order by audit_records.id desc limit 10)) AS b\G

*************************** 1. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263176_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "SELECT DISTINCT c FROM sbtest1 WHERE id BETWEEN 5001 AND 5100 ORDER BY c", "timestamp": "2020-10-29T11:11:56Z", "command_class": "select", "connection_id": "25143"}

*************************** 2. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263175_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "SELECT c FROM sbtest4 WHERE id BETWEEN 4875 AND 4974 ORDER BY c", "timestamp": "2020-10-29T11:11:56Z", "command_class": "select", "connection_id": "25143"}

*************************** 3. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263174_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "SELECT SUM(k) FROM sbtest1 WHERE id BETWEEN 5017 AND 5116", "timestamp": "2020-10-29T11:11:56Z", "command_class": "select", "connection_id": "25143"}

*************************** 4. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263173_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "SELECT c FROM sbtest8 WHERE id BETWEEN 4994 AND 5093", "timestamp": "2020-10-29T11:11:56Z", "command_class": "select", "connection_id": "25153"}

*************************** 5. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263172_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "SELECT c FROM sbtest3 WHERE id=4976", "timestamp": "2020-10-29T11:11:56Z", "command_class": "select", "connection_id": "25153"}

*************************** 6. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263171_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "SELECT c FROM sbtest3 WHERE id=5018", "timestamp": "2020-10-29T11:11:56Z", "command_class": "select", "connection_id": "25153"}

*************************** 7. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263170_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "SELECT c FROM sbtest3 WHERE id=5026", "timestamp": "2020-10-29T11:11:56Z", "command_class": "select", "connection_id": "25153"}

*************************** 8. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263169_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "SELECT c FROM sbtest3 WHERE id=5711", "timestamp": "2020-10-29T11:11:56Z", "command_class": "select", "connection_id": "25153"}

*************************** 9. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263168_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "SELECT c FROM sbtest3 WHERE id=5044", "timestamp": "2020-10-29T11:11:56Z", "command_class": "select", "connection_id": "25153"}

*************************** 10. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263167_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "SELECT c FROM sbtest3 WHERE id=5637", "timestamp": "2020-10-29T11:11:56Z", "command_class": "select", "connection_id": "25153"}

*************************** 11. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263151_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "INSERT INTO sbtest9 (id, k, c, pad) VALUES (4998, 4986, '02171032529-62046503057-07366460505-11685363597-46873502976-33077071866-44215205484-05994642442-06380315383-02875729800', '19260637605-33008876390-94789070914-09039113107-89863581488')", "timestamp": "2020-10-29T11:11:56Z", "command_class": "insert", "connection_id": "25124"}

*************************** 12. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263133_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "INSERT INTO sbtest8 (id, k, c, pad) VALUES (6081, 4150, '18974493622-09995560953-16579360264-35381241173-70425414992-87533708595-45025145447-98882906947-17081170077-49181742629', '20737943314-90440646708-38143024644-95915967543-47972430163')", "timestamp": "2020-10-29T11:11:56Z", "command_class": "insert", "connection_id": "25133"}

*************************** 13. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263126_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "INSERT INTO sbtest2 (id, k, c, pad) VALUES (5014, 5049, '82143477938-07198858971-84944276583-28705099377-04269543238-74209284999-24766869883-70274359968-19384709611-56871076616', '89380034594-52170436945-89656244047-48644464580-26885108397')", "timestamp": "2020-10-29T11:11:56Z", "command_class": "insert", "connection_id": "25135"}

*************************** 14. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263119_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "INSERT INTO sbtest5 (id, k, c, pad) VALUES (4995, 3860, '07500343929-19373180618-48491497019-86674883771-87861925606-04683804124-03278606074-05397614513-84175620410-77007118978', '19374966620-11798221232-19991603086-34443959669-69834306417')", "timestamp": "2020-10-29T11:11:56Z", "command_class": "insert", "connection_id": "25142"}

*************************** 15. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263112_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "INSERT INTO sbtest10 (id, k, c, pad) VALUES (5766, 5007, '46189905191-42872108894-20541866044-43286474408-49735155060-20388245380-67571749662-72179825415-56363344183-47524887111', '24559469844-22477386116-04417716308-05721823869-32876821172')", "timestamp": "2020-10-29T11:11:56Z", "command_class": "insert", "connection_id": "25137"}

*************************** 16. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263083_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "INSERT INTO sbtest7 (id, k, c, pad) VALUES (5033, 4986, '20695843208-59656863439-60406010814-11793724813-45659184103-02803540858-01466094684-30557262345-15801610791-28290093674', '14178983572-33857930891-42382490524-21373835727-23623125230')", "timestamp": "2020-10-29T11:11:56Z", "command_class": "insert", "connection_id": "25118"}

*************************** 17. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263076_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "INSERT INTO sbtest1 (id, k, c, pad) VALUES (5029, 5016, '72342762580-04669595160-76797241844-46205057564-77659988460-00393018079-89701448932-22439638942-02011990830-97695117676', '13179789120-16401633552-44237908265-34585805608-99910166472')", "timestamp": "2020-10-29T11:11:56Z", "command_class": "insert", "connection_id": "25121"}

*************************** 18. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263036_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "INSERT INTO sbtest1 (id, k, c, pad) VALUES (5038, 5146, '62239893938-24763792785-75786071570-64441378769-99060498468-07437802489-36899434285-44705822299-70849806976-77287283409', '03220277005-21146501539-10986216439-83162542410-04253248063')", "timestamp": "2020-10-29T11:11:55Z", "command_class": "insert", "connection_id": "25127"}

*************************** 19. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326263018_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "INSERT INTO sbtest4 (id, k, c, pad) VALUES (5004, 5028, '15487433957-59189974170-83116468418-96078631606-58760747556-09307871236-40520753062-17596570189-73692856496-38267942694', '98937710805-24695902707-05013528796-18454393948-39118534483')", "timestamp": "2020-10-29T11:11:55Z", "command_class": "insert", "connection_id": "25129"}

*************************** 20. row ***************************

top10_select_insert: {"db": "sbtest", "ip": "192.168.10.200", "host": "", "name": "Query", "user": "cmon[cmon] @  [192.168.10.200]", "record": "326262989_2020-10-29T10:35:07", "status": 0, "os_user": "", "sqltext": "INSERT INTO sbtest3 (id, k, c, pad) VALUES (5015, 5030, '30613877119-41343977889-67711116708-96041306890-46480766663-68231747217-07404586739-83073703805-75534384550-12407169697', '65220283880-37505643788-94809192635-84679347406-74995175373')", "timestamp": "2020-10-29T11:11:55Z", "command_class": "insert", "connection_id": "25139"}

20 rows in set (0.00 sec)

Zbierz swoje dzienniki kontrolne za pomocą innych narzędzi

Teraz, gdy możesz analizować dane wyjściowe swoich dzienników kontroli, możesz zacząć włączać je do innych narzędzi zewnętrznych i rozpocząć agregację z bieżącym środowiskiem lub stosem technologicznym, o ile odczytuje lub obsługuje JSON. Na przykład za pomocą ELK (Elasticsearch, Logstash Kibana) do analizowania i scentralizowania dzienników. Możesz również spróbować zintegrować z Graylog lub Fluentd. Z drugiej strony możesz stworzyć własną przeglądarkę i włączyć ją do aktualnej konfiguracji oprogramowania. Korzystanie z dziennika audytu Percona sprawia, że ​​te rzeczy są możliwe do wykonania większej ilości analiz z wysoką produktywnością, a także oczywiście wykonalne i rozszerzalne.


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

  1. Rozważania dotyczące bezpieczeństwa wdrożeń MariaDB w środowisku chmury hybrydowej

  2. Jak działa MICROSECOND() w MariaDB

  3. Jak PERIOD_DIFF() działa w MariaDB

  4. Jak działa UPPER() w MariaDB

  5. Jak TO_SECONDS() działa w MariaDB?