Audit je sledování a zaznamenávání vybraných akcí databáze uživatelů. Obvykle se používá ke zkoumání podezřelé aktivity nebo sledování a shromažďování dat o konkrétních databázových aktivitách. Administrátor databáze může například shromažďovat statistiky o tom, které tabulky se aktualizují, kolik operací se provádí nebo kolik souběžných uživatelů se v konkrétních časech připojuje.
V tomto příspěvku na blogu se budeme zabývat základními aspekty auditování našich databázových systémů s otevřeným zdrojovým kódem, zejména MySQL, MariaDB, PostgreSQL a MongoDB. Tento článek je zaměřen na inženýry DevOps, kteří mají obvykle menší zkušenosti nebo zkušenosti s osvědčenými postupy auditu a dobrou správou dat při správě infrastruktury primárně pro databázové systémy.
Audit výpisů
Audit příkazů MySQL
MySQL má obecný protokol dotazů (nebo general_log), který v podstatě zaznamenává, co mysqld dělá. Server zapisuje informace do tohoto protokolu, když se klienti připojují nebo odpojují, a zaznamenává každý příkaz SQL přijatý od klientů. Obecný protokol dotazů může být velmi užitečný při odstraňování problémů, ale není ve skutečnosti vytvořen pro nepřetržité auditování. Má velký dopad na výkon a měl by být povolen pouze během krátkých časových úseků. Existují další možnosti, jak místo toho použít tabulky performance_schema.events_statements* nebo modul Audit Plugin.
Auditování příkazů PostgreSQL
Pro PostgreSQL můžete povolit log_statment na "all". Podporované hodnoty pro tento parametr jsou none (off), ddl, mod a all (všechny příkazy). Pro "ddl" protokoluje všechny příkazy definice dat, jako jsou příkazy CREATE, ALTER a DROP. Pro "mod" zaprotokoluje všechny příkazy DDL plus příkazy upravující data, jako jsou INSERT, UPDATE, DELETE, TRUNCATE a COPY FROM.
Pravděpodobně budete muset nakonfigurovat související parametry, jako je log_directory, log_filename, logging_collector a log_rotation_age, jak ukazuje následující příklad:
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement = 'all'
logging_collector = on
log_rotation_age = 10080 # 1 week in minutes Výše uvedené změny vyžadují restart PostgreSQL, proto si před použitím ve svém produkčním prostředí pečlivě naplánujte. Aktuální protokoly pak naleznete v adresáři pg_log. Pro PostgreSQL 12 je umístění na /var/lib/pgsql/12/data/pg_log/ . Všimněte si, že soubory protokolu mají tendenci se časem hodně zvětšovat a mohou výrazně zabírat místo na disku. Místo toho můžete také použít log_rotation_size, pokud máte omezený úložný prostor.
Audit výpisů MongoDB
Pro MongoDB existují 3 úrovně protokolování, které nám mohou pomoci auditovat prohlášení (operace nebo operace v termínu MongoDB):
-
Úroveň 0 – Toto je výchozí úroveň profilovače, kde profilovač neshromažďuje žádná data. Mongod do svého protokolu vždy zapisuje operace delší než je práh slowOpThresholdMs.
-
Úroveň 1 – Shromažďuje data profilování pouze pro pomalé operace. Ve výchozím nastavení jsou pomalé operace ty, které jsou pomalejší než 100 milisekund. Práh pro „pomalé“ operace můžete upravit pomocí volby runtime slowOpThresholdMs nebo příkazu setParameter.
-
Úroveň 2 – Shromažďuje profilovací data pro všechny databázové operace.
Chcete-li protokolovat všechny operace, nastavte db.setProfilingLevel(2, 1000), kde by měl profilovat všechny operace s operacemi, které trvají déle než definované milisekundy, v tomto případě je 1 sekunda (1000 ms) . Dotaz, který se má vyhledat v kolekci systémových profilů pro všechny dotazy, které trvaly déle než jednu sekundu, seřazený sestupně podle časového razítka, bude. Pro čtení operací můžeme použít následující dotaz:
mongodb> db.system.profile.find( { millis : { $gt:1000 } } ).sort( { ts : -1 } )Je zde také projekt Mongotail, který zjednodušuje proces profilování operací pomocí externího nástroje namísto dotazování přímo na kolekci profilů.
Mějte na paměti, že se nedoporučuje spouštět úplné auditování příkazů na produkčních databázových serverech, protože to obvykle představuje významný dopad na databázovou službu s obrovským objemem protokolování. Doporučeným způsobem je místo toho použít zásuvný modul pro audit databáze (jak je uvedeno níže), který poskytuje standardní způsob vytváření protokolů auditu, které jsou často vyžadovány pro splnění vládních, finančních nebo ISO certifikací.
Audit oprávnění pro MySQL, MariaDB a PostgreSQL
Auditování oprávnění kontroluje oprávnění a řízení přístupu k databázovým objektům. Řízení přístupu zajišťuje, že uživatelé přistupující k databázi jsou jednoznačně identifikováni a mohou přistupovat, aktualizovat nebo mazat data, na která mají nárok. Tato oblast je běžně přehlížena inženýrem DevOps, což dělá z nadměrného privilegování běžnou chybu při vytváření a udělování databázového uživatele.
Příklady nadměrně privilegovaných jsou:
-
Hostitelé přístupu uživatelů jsou povoleni z velmi širokého rozsahu, například udělení hostitele uživatele [email protected]' %', namísto individuální IP adresy.
-
Administrativní oprávnění jsou přidělována neadministrativním uživatelům databáze, například je přidělován uživatel databáze pro aplikaci s oprávněním SUPER nebo RELOAD.
-
Nedostatek kontroly zdrojů proti jakémukoli nadměrnému využívání, jako je Max. počet uživatelských připojení, Max. počet dotazů za hodinu nebo Max. Počet připojení za hodinu.
-
Povolit konkrétním uživatelům databáze přístup také k jiným schématům.
U MySQL, MariaDB a PostgreSQL můžete provádět audit oprávnění prostřednictvím informačního schématu dotazováním na tabulky související s udělením, rolí a oprávněními. Pro MongoDB použijte následující dotaz (vyžaduje akci viewUser pro ostatní databáze):
mongodb> db.getUsers( { usersInfo: { forAllDBs: true } } )ClusterControl poskytuje pěkné shrnutí oprávnění přiřazených uživateli databáze. Přejděte na Spravovat -> Schémata a uživatelé -> Uživatelé a získáte zprávu o oprávněních uživatelů spolu s pokročilými možnostmi, jako je Vyžaduje SSL, Maximální počet připojení za hodinu a tak dále.
ClusterControl podporuje auditování oprávnění pro MySQL, MariaDB a PostgreSQL pod stejným uživatelem rozhraní.
Auditování objektů schématu
Objekty schématu jsou logické struktury vytvořené uživateli. Příklady objektů schématu jsou tabulky, indexy, pohledy, rutiny, události, procedury, funkce, spouštěče a další. V zásadě jde o objekty, které obsahují data nebo se mohou skládat pouze z definice. Běžně by se dalo auditovat oprávnění spojená s objekty schématu, aby bylo možné zjistit špatná nastavení zabezpečení a pochopit vztahy a závislosti mezi objekty.
Pro MySQL a MariaDB existují information_schema a performance_schema, které můžeme použít k základnímu auditu objektů schématu. Performance_schema je trochu hloubka v instrumentaci, jak jeho název napovídá. MySQL však od verze 5.7.7 také obsahuje schéma sys, což je uživatelsky přívětivá verze performance_schema. Všechny tyto databáze jsou přímo přístupné a dotazovatelné klienty.
Pluginy/rozšíření pro audit databáze
Nejvíce doporučovaným způsobem provádění auditu příkazů je použití auditního pluginu nebo rozšíření, speciálně vytvořeného pro používanou databázovou technologii. MariaDB a Percona mají vlastní implementaci pluginu Audit, která se trochu liší od pluginu Audit MySQL dostupného v MySQL Enterprise. Záznamy auditu obsahují informace o operaci, která byla auditována, uživateli, který operaci provedl, a datum a čas operace. Záznamy mohou být uloženy buď v tabulce datového slovníku, nazývané databázový audit trail, nebo v souborech operačního systému, nazývaných audit trail operačního systému.
Pro PostgreSQL existuje pgAudit, rozšíření PostgreSQL, které poskytuje podrobné protokolování auditu relace a/nebo objektu prostřednictvím standardního protokolovacího zařízení PostgreSQL. Je to v podstatě vylepšená verze funkce log_statement PostgreSQL se schopností snadno vyhledávat a vyhledávat zachycená data pro audit podle standardního protokolu auditu.
MongoDB Enterprise (placené) a Percona Server pro MongoDB (zdarma) obsahují funkci auditu pro instance mongod a mongos. S povoleným auditováním bude server generovat auditní zprávy, které lze přihlásit do syslogu, konzole nebo souboru (formát JSON nebo BSON). Ve většině případů je vhodnější přihlásit se k souboru ve formátu BSON, kde je dopad na výkon menší než JSON. Tento soubor obsahuje informace o různých uživatelských událostech včetně autentizace, selhání autorizace a tak dále. Podrobnosti najdete v dokumentaci auditu.
Sledování auditu operačního systému
Je také důležité nakonfigurovat auditní záznamy operačního systému. Pro Linux by lidé běžně používali auditd. Auditd je komponenta uživatelského prostoru systému Linux Auditing System a je zodpovědná za zápis záznamů auditu na disk. Prohlížení protokolů se provádí pomocí nástrojů ausearch nebo aureport. Konfigurace pravidel auditu se provádí pomocí nástroje auditctl nebo přímou úpravou souborů pravidel.
Následující instalační kroky jsou naší běžnou praxí při nastavování jakéhokoli druhu serverů pro produkční použití:
$ yum -y install audit # apt install auditd python
$ mv /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.ori
$ cd /etc/audit/rules.d/
$ wget https://gist.githubusercontent.com/ashraf-s9s/fb1b674e15a5a5b41504faf76a08b4ae/raw/2764bf0e9bf25418bb86e33c13fb80356999d220/audit.rules
$ chmod 640 audit.rules
$ systemctl daemon-reload
$ systemctl start auditd
$ systemctl enable auditd
$ service auditd restartVšimněte si, že restart auditované služby posledního řádku je povinný, protože audit při načítání pravidel pomocí systemd nefunguje opravdu dobře. Systemd je však stále vyžadován k monitorování auditované služby. Během spouštění jsou pravidla v /etc/audit/audit.rules čtena pomocí auditctl. Samotný audit démon má některé možnosti konfigurace, které si může správce přát přizpůsobit. Najdete je v souboru auditd.conf.
Následující řádek je výstupem z nakonfigurovaného protokolu auditu:
$ ausearch -m EXECVE | grep -i 'password' | head -1
type=EXECVE msg=audit(1615377099.934:11838148): argc=7 a0="mysql" a1="-NAB" a2="--user=appdb1" a3="--password=S3cr3tPassw0rdKP" a4="-h127.0.0.1" a5="-P3306" a6=2D6553484F5720474C4F42414C205641524941424C4553205748455245205641524941424C455F4E414D4520494E20282776657273696F6E272C202776657273696F6E5F636F6D6D656E74272C2027646174616469722729Jak můžete vidět z výše uvedeného, je snadné najít čisté textové heslo pro MySQL ("--password=S3cr3tPassw0rdKP") pomocí nástroje ausearch, jak jej zachytil auditd. Tento druh zjišťování a auditování je zásadní pro zabezpečení naší databázové infrastruktury, kde je heslo s čistým textem v zabezpečeném prostředí nepřijatelné.
Poslední myšlenky
Protokol auditu nebo stopa jsou zásadním aspektem, který inženýři DevOps běžně přehlížejí při správě infrastruktur a systémů, nemluvě o databázovém systému, který je velmi kritickým systémem pro ukládání citlivých a důvěrných dat. Jakékoli odhalení nebo narušení vašich soukromých údajů může být pro firmu extrémně škodlivé a nikdo by si nepřál, aby se to stalo v současné době informačních technologií.