Ръководството за одит на база данни с отворен код на DevOps – всичко, което трябва да знаете

Одитирането е наблюдението и записването на избрани действия в базата данни на потребителите. Обикновено се използва за разследване на подозрителна дейност или наблюдение и събиране на данни за специфични дейности в базата данни. Например администраторът на базата данни може да събира статистически данни за това кои таблици се актуализират, колко операции се извършват или колко едновременни потребители се свързват в определени моменти.

В тази публикация в блога ще покрием основните аспекти на одита на нашите системи за бази данни с отворен код, особено MySQL, MariaDB, PostgreSQL и MongoDB. Тази статия е насочена към инженерите на DevOps, които обикновено имат по-малко опит или изложение в най-добрите практики за одит и добро управление на данните, когато управляват инфраструктурата предимно за системите за бази данни.

Одит на изявления

Одит на MySQL изявления

MySQL има общия регистър на заявките (или general_log), който основно записва какво прави mysqld. Сървърът записва информация в този журнал, когато клиентите се свързват или прекъсват връзката, и записва всеки SQL израз, получен от клиенти. Общият регистър на заявките може да бъде много полезен при отстраняване на неизправности, но всъщност не е създаден за непрекъснат одит. Той има голямо влияние върху производителността и трябва да бъде активиран само през кратки времеви интервали. Вместо това има други опции за използване на таблици performance_schema.events_statements* или добавка за одит.

Одит на PostgreSQL изявления

За PostgreSQL можете да активирате log_statment на "all". Поддържаните стойности за този параметър са none (off), ddl, mod и all (всички изрази). За "ddl" той регистрира всички изрази за дефиниране на данни, като изрази CREATE, ALTER и DROP. За "mod" той регистрира всички DDL оператори, плюс оператори за модифициране на данни като INSERT, UPDATE, DELETE, TRUNCATE и COPY FROM.

Вероятно трябва да конфигурирате свързаните параметри като log_directory, log_filename, logging_collector и log_rotation_age, както е показано в следния пример:

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 

Посочените по-горе промени изискват рестартиране на PostgreSQL, така че, моля, планирайте внимателно, преди да приложите към вашата производствена среда. След това можете да намерите текущите регистрационни файлове в директорията pg_log. За PostgreSQL 12 местоположението е /var/lib/pgsql/12/data/pg_log/. Имайте предвид, че регистрационните файлове са склонни да нарастват много с течение на времето и може да изядат значително дисковото пространство. Можете също да използвате log_rotation_size вместо това, ако имате ограничено място за съхранение.

Одит на изявления на MongoDB

За MongoDB има 3 нива на регистриране, които могат да ни помогнат да одитираме изразите (операции или операции в термина MongoDB):

• Ниво 0 – Това е нивото на профайлъра по подразбиране, където профайлърът не събира никакви данни. Монгодът винаги записва операции, по-дълги от прага slowOpThresholdMs в своя журнал.

• Ниво 1 – Събира данни за профилиране само за бавни операции. По подразбиране бавните операции са тези, които са по-бавни от 100 милисекунди. Можете да промените прага за „бавни“ операции с опцията slowOpThresholdMs по време на изпълнение или командата setParameter.

• Ниво 2 – Събира данни за профилиране за всички операции с базата данни.

За да регистрирате всички операции, задайте db.setProfilingLevel(2, 1000), където трябва да профилира всички операции с операции, които отнемат по-дълго от дефинираните милисекунди, в този случай е 1 секунда (1000 ms) . Заявката за търсене в колекцията на системните профили за всички заявки, които са отнели повече от една секунда, подредени по низходящо времеви печат, ще бъде. За да прочетем операциите, можем да използваме следната заявка:

mongodb> db.system.profile.find( { millis : { $gt:1000 } } ).sort( { ts : -1 } )

Също така, има проект Mongotail, който опростява процеса на профилиране на операцията с външен инструмент, вместо да се прави заявка директно към колекцията от профили.

Имайте предвид, че не се препоръчва извършването на пълен одит на изявления в сървърите на производствените бази данни, тъй като това обикновено оказва значително влияние върху услугата на базата данни с огромен обем записване. Препоръчителният начин е вместо това да използвате приставка за одит на база данни (както е показано по-долу), която предоставя стандартен начин за създаване на регистрационни файлове за одит, често изисквани за спазване на държавни, финансови или ISO сертификати.

Одит на привилегии за MySQL, MariaDB и PostgreSQL

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

Примери за свръхпривилегировани са:

• Хостовете за достъп на потребителя са разрешени от много широк диапазон, например предоставяне на потребителски хост [email protected]' %', вместо индивидуален IP адрес.

• Административните привилегии се присвояват на неадминистративни потребители на база данни, например се присвоява потребител на база данни за приложение с привилегия SUPER или RELOAD.

• Липса на контрол на ресурсите срещу всякакъв вид прекомерно използване като макс. потребителски връзки, макс. заявки на час или макс. Връзки на час.

• Позволете на конкретни потребители на база данни да имат достъп и до други схеми.

За MySQL, MariaDB и PostgreSQL можете да извършвате одит на привилегиите чрез информационната схема, като потърсите таблици, свързани с предоставянето, ролята и привилегиите. За MongoDB използвайте следната заявка (изисква действие viewUser за други бази данни):

mongodb> db.getUsers( { usersInfo: { forAllDBs: true } } )

ClusterControl предоставя хубаво обобщение на привилегиите, присвоени на потребител на база данни. Отидете на Управление -> Схеми и потребители -> Потребители и ще получите отчет за привилегиите на потребителите, заедно с разширените опции като Изисква SSL, Макс. връзки на час и така нататък.

ClusterControl поддържа одит на привилегиите за MySQL, MariaDB и PostgreSQL под един и същ потребител интерфейс.

Одит на обект на схема

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

За MySQL и MariaDB има information_schema и performance_schema, които можем да използваме основно за одит на обектите на схемата. Performance_schema е малко дълбочина в инструментите, както подсказва името му. Въпреки това, MySQL включва и sys схема от версия 5.7.7, която е удобна за потребителя версия на performance_schema. Всички тези бази данни са директно достъпни и могат да бъдат запитани от клиентите.

Плъгини/разширения за одит на базата данни

Най-препоръчителният начин за извършване на одит на изявления е чрез използване на плъгин или разширение за одит, специално създадени за използваната технология на база данни. MariaDB и Percona имат собствена реализация на добавка за одит, която е малко по-различна от приставката за одит на MySQL, налична в MySQL Enterprise. Одитните записи включват информация за одитираната операция, потребителя, изпълняващ операцията, и датата и часа на операцията. Записите могат да се съхраняват или в таблица с речник на данни, наречена следа за одит на базата данни, или във файлове на операционната система, наречена следа за одит на операционната система.

За PostgreSQL има pgAudit, разширение на PostgreSQL, което предоставя подробен протокол за одит на сесия и/или обект чрез стандартното средство за регистриране на PostgreSQL. По същество това е подобрена версия на функцията log_statement на PostgreSQL с възможност за лесно търсене и търсене на заснетите данни за одит, като следвате стандартния дневник за одит.

MongoDB Enterprise (платено) и Percona Server за MongoDB (безплатно) включват възможност за одит за mongod и mongos екземпляри. При активиран одит сървърът ще генерира съобщения за одит, които могат да бъдат влезли в системен журнал, конзола или файл (формат JSON или BSON). В повечето случаи е за предпочитане да влезете във файла във формат BSON, където въздействието върху производителността е по-малко от JSON. Този файл съдържа информация за различни потребителски събития, включително удостоверяване, откази при упълномощаване и т.н. Вижте документацията за одит за подробности.

Одит на операционната система

Важно е също да конфигурирате следите за одит на операционната система. За Linux хората обикновено използват auditd. Auditd е компонентът на потребителското пространство на системата за одит на Linux и отговаря за записването на записи за одит на диска. Прегледът на регистрационните файлове се извършва с помощните програми ausearch или aureport. Конфигурирането на правилата за одит се извършва с помощната програма auditctl или чрез директно модифициране на файловете с правила.

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

$ 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 restart

Обърнете внимание, че рестартирането на последния ред на услугата auditd е задължително, тъй като одитът не работи много добре при зареждане на правила със systemd. Въпреки това, systemd все още се изисква да наблюдава услугата auditd. По време на стартиране правилата в /etc/audit/audit.rules се четат от auditctl. Самият демон за одит има някои опции за конфигурация, които администраторът може да пожелае да персонализира. Те се намират във файла auditd.conf.

Следният ред е изход, взет от конфигуриран регистър на одита:

$ 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=2D6553484F5720474C4F42414C205641524941424C4553205748455245205641524941424C455F4E414D4520494E20282776657273696F6E272C202776657273696F6E5F636F6D6D656E74272C2027646174616469722729

Както можете да видите от горното, лесно е да забележите парола с чист текст за MySQL ("--password=S3cr3tPassw0rdKP") с помощта на помощната програма ausearch, заснета от auditd. Този вид откриване и одит са жизненоважни за защитата на нашата инфраструктура на базата данни, където паролата с чист текст е неприемлива в защитена среда.

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

Регистърът или проследяването на одита са жизненоважен аспект, който често се пренебрегва от инженерите на DevOps, когато управляват инфраструктури и системи, да не говорим за системата от бази данни, която е много критична система за съхраняване на чувствителни и поверителни данни. Всяко излагане или нарушаване на личните ви данни може да бъде изключително вредно за бизнеса и никой не би искал това да се случи в настоящата ера на информационните технологии.