Databeskyttelse er et af de vigtigste aspekter ved administration af en database. Afhængigt af organisationsstrukturen, om du er udvikler, sysadmin eller DBA, skal du, hvis du administrerer produktionsdatabasen, overvåge data for uautoriseret adgang og brug. Formålet med sikkerhedsovervågning er todelt. Én, at identificere uautoriseret aktivitet på databasen. Og to, for at kontrollere, om databaser og deres konfigurationer på virksomhedsbasis er i overensstemmelse med sikkerhedspolitikker og -standarder.
I denne artikel vil vi opdele overvågning for sikkerhed i to kategorier. Den ene vil være relateret til revision af MySQL- og MariaDB-databaseaktiviteter. Den anden kategori handler om at overvåge dine forekomster for potentielle sikkerhedshuller.
Forespørgsels- og forbindelsespolitik-baseret overvågning
Kontinuerlig revision er en bydende opgave for at overvåge dit databasemiljø. Ved at revidere din database kan du opnå ansvarlighed for handlinger, der er foretaget, eller adgang til indhold. Desuden kan revisionen omfatte nogle kritiske systemkomponenter, såsom dem, der er forbundet med finansielle data for at understøtte et præcist sæt af regler som SOX eller EU's GDPR-forordning. Normalt opnås det ved at logge oplysninger om DB-operationer på databasen til en ekstern logfil.
Som standard er revision i MySQL eller MariaDB deaktiveret. Du og opnå det ved at installere yderligere plugins eller ved at fange alle forespørgsler med query_log parameteren. Den generelle forespørgselslogfil er en generel registrering af, hvad MySQL udfører. Serveren registrerer nogle oplysninger til denne log, når klienter opretter forbindelse eller afbryder forbindelsen, og den logger hver SQL-sætning, der modtages fra klienter. På grund af ydeevneproblemer og mangel på konfigurationsmuligheder er general_log ikke en god løsning til sikkerhedsrevisionsformål.
Hvis du bruger MySQL Enterprise, kan du bruge MySQL Enterprise Audit plugin, som er en udvidelse til den proprietære MySQL version. MySQL Enterprise Audit Plugin-plugin er kun tilgængelig med MySQL Enterprise, som er et kommercielt tilbud fra Oracle. Percona og MariaDB har lavet deres egne open source-versioner af revisionsplugin'et. Endelig kan McAfee plugin til MySQL også bruges med forskellige versioner af MySQL. I denne artikel vil vi fokusere på open source-plugins, selvom Enterprise-versionen fra Oracle ser ud til at være den mest robuste og stabile.
Karakteristik af MySQL Open Source Audit Plugins
Mens open source-audit-plugins udfører det samme arbejde som Enterprise-pluginnet fra Oracle - de producerer output med databaseforespørgsler og forbindelser - er der nogle store arkitektoniske forskelle.
MariaDB Audit Plugin – MariaDB Audit Plugin fungerer med MariaDB, MySQL (fra version 5.5.34 og 10.0.7) og Percona Server. MariaDB startede med at inkludere Audit Plugin som standard fra version 10.0.10 og 5.5.37, og det kan installeres i enhver version fra MariaDB 5.5.20. Det er det eneste plugin, der understøtter Oracle MySQL, Percona Server og MariaDB. Det er tilgængeligt på Windows og Linux platforme. Versioner, der starter fra 1.2, er mest stabile, og det kan være risikabelt at bruge versioner under det i dit produktionsmiljø.
McAfee MySQL Audit Plugin – Dette plugin bruger ikke MySQL audit API. Det blev for nylig opdateret til at understøtte MySQL 5.7. Nogle test viser, at API-baserede plugins kan give bedre ydeevne, men du skal tjekke det med dit miljø.
Percona Audit Log Plugin – Percona leverer en open source revisionsløsning, der installeres med Percona Server 5.5.37+ og 5.6.17+ som en del af installationsprocessen. Sammenlignet med andre open source-plugins har dette plugin flere rækkevidde-outputfunktioner, da det udsender XML, JSON og til syslog.
Da den har nogle interne kroge til serveren for at være funktionskompatibel med Oracles plugin, er den ikke tilgængelig som et selvstændigt plugin til andre versioner af MySQL.
Plugininstallation baseret på MariaDB revisionsudvidelse
Installationen af open source MySQL-plugins er ret ens for MariaDB-, Percona- og McAfee-versioner.
Percona og MariaDB tilføjer deres plugins som en del af standardserverens binære filer, så der er ingen grund til at downloade plugins separat. Percona-versionen understøtter kun officielt sin egen fork af MySQL, så der er ingen direkte download fra leverandørens websted (hvis du vil bruge dette plugin med MySQL, skal du hente plugin fra en Percona-serverpakke). Hvis du gerne vil bruge MariaDB-plugin'et med andre MySQL-gafler, kan du finde det fra https://downloads.mariadb.com/Audit-Plugin/MariaDB-Audit-Plugin/. McAfee-pluginnet er tilgængeligt på https://github.com/mcafee/mysql-audit/wiki/Installation.
Før du starter plugin-installationen, kan du kontrollere, om plugin'et er til stede i systemet. Placeringen af det dynamiske plugin (kræver ikke genstart af forekomsten) kan kontrolleres med:
SHOW GLOBAL VARIABLES LIKE 'plugin_dir';
+---------------+--------------------------+
| Variable_name | Value |
+---------------+--------------------------+
| plugin_dir | /usr/lib64/mysql/plugin/ |
+---------------+--------------------------+Tjek den mappe, der returneres på filsystemniveau, for at sikre, at du har en kopi af plugin-biblioteket. Hvis du ikke har server_audit.so eller server_audit.dll inde i /usr/lib64/mysql/plugin/, er det mere sandsynligt, at din MariaDB-version ikke understøttes og bør opgradere den til den nyeste version.
Syntaksen til at installere MariaDB-pluginnet er:
INSTALL SONAME 'server_audit';For at kontrollere installerede plugins skal du køre:
SHOW PLUGINS;
MariaDB [(none)]> show plugins;
+-------------------------------+----------+--------------------+--------------------+---------+
| Name | Status | Type | Library | License |
+-------------------------------+----------+--------------------+--------------------+---------+
| binlog | ACTIVE | STORAGE ENGINE | NULL | GPL |
| mysql_native_password | ACTIVE | AUTHENTICATION | NULL | GPL |
| mysql_old_password | ACTIVE | AUTHENTICATION | NULL | GPL |
| wsrep | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MRG_MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MEMORY | ACTIVE | STORAGE ENGINE | NULL | GPL |
| CSV | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
| CLIENT_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INDEX_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| TABLE_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| USER_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| PERFORMANCE_SCHEMA | ACTIVE | STORAGE ENGINE | NULL | GPL |
| InnoDB | ACTIVE | STORAGE ENGINE | NULL | GPL |
| INNODB_TRX | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_LOCKS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_LOCK_WAITS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMP | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
...
| INNODB_MUTEXES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_SYS_SEMAPHORE_WAITS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_TABLESPACES_ENCRYPTION | ACTIVE | INFORMATION SCHEMA | NULL | BSD |
| INNODB_TABLESPACES_SCRUBBING | ACTIVE | INFORMATION SCHEMA | NULL | BSD |
| Aria | ACTIVE | STORAGE ENGINE | NULL | GPL |
| SEQUENCE | ACTIVE | STORAGE ENGINE | NULL | GPL |
| user_variables | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| FEEDBACK | DISABLED | INFORMATION SCHEMA | NULL | GPL |
| partition | ACTIVE | STORAGE ENGINE | NULL | GPL |
| rpl_semi_sync_master | ACTIVE | REPLICATION | semisync_master.so | GPL |
| rpl_semi_sync_slave | ACTIVE | REPLICATION | semisync_slave.so | GPL |
| SERVER_AUDIT | ACTIVE | AUDIT | server_audit.so | GPL |
+-------------------------------+----------+--------------------+--------------------+---------+Hvis du har brug for yderligere oplysninger, så tjek PLUGINS-tabellen i informationsskema-databasen, som indeholder mere detaljerede oplysninger.
En anden måde at installere plugin på er at aktivere plugin i my.cnf og genstarte instansen. Et eksempel på en grundlæggende revisionsplugin-konfiguration fra MariaDB kunne være:
server_audit_events=CONNECT
server_audit_file_path=/var/log/mysql/audit.log
server_audit_file_rotate_size=1073741824
server_audit_file_rotations=8
server_audit_logging=ON
server_audit_incl_users=
server_audit_excl_users=
server_audit_output_type=FILE
server_audit_query_log_limit=1024Ovenstående indstilling skal placeres i my.cnf. Audit plugin vil oprette filen /var/log/mysql/audit.log, som vil rotere på størrelse 1GB, og der vil være otte rotationer, indtil filen er overskrevet. Filen vil kun indeholde oplysninger om forbindelser.
I øjeblikket er der seksten indstillinger, som du kan bruge til at justere MariaDB revisionsplugin.
server_audit_events
server_audit_excl_users
server_audit_file_path
server_audit_file_rotate_now
server_audit_file_rotate_size
server_audit_file_rotations
server_audit_incl_users
server_audit_loc_info
server_audit_logging
server_audit_mode
server_audit_output_type
Server_audit_query_log_limit
server_audit_syslog_facility
server_audit_syslog_ident
server_audit_syslog_info
server_audit_syslog_priorityBlandt dem kan du finde muligheder for at inkludere eller ekskludere brugere, indstille forskellige logningshændelser (CONNECT eller QUERY) og skifte mellem fil og syslog.
For at sikre, at plugin'et vil blive aktiveret ved serverstart, skal du indstille
plugin_load=server_audit=server_audit.so i dine my.cnf-indstillinger. En sådan konfiguration kan yderligere beskyttes af server_audit=FORCE_PLUS_PERMANENT, hvilket vil deaktivere plugin-afinstallationen.
UNINSTALL PLUGIN server_audit;
ERROR 1702 (HY000):
Plugin 'server_audit' is force_plus_permanent and can not be unloadedHer er nogle eksempler på indgange produceret af MariaDB audit plugin:
20180817 20:00:01,slave,cmon,cmon,31,0,DISCONNECT,information_schema,,0
20180817 20:47:01,slave,cmon,cmon,17,0,DISCONNECT,information_schema,,0
20180817 20:47:02,slave,cmon,cmon,19,0,DISCONNECT,information_schema,,0
20180817 20:47:02,slave,cmon,cmon,18,0,DISCONNECT,information_schema,,0
20180819 17:19:19,slave,cmon,cmon,12,0,CONNECT,information_schema,,0
20180819 17:19:19,slave,root,localhost,13,0,FAILED_CONNECT,,,1045
20180819 17:19:19,slave,root,localhost,13,0,DISCONNECT,,,0
20180819 17:19:20,slave,cmon,cmon,14,0,CONNECT,mysql,,0
20180819 17:19:20,slave,cmon,cmon,14,0,DISCONNECT,mysql,,0
20180819 17:19:21,slave,cmon,cmon,15,0,CONNECT,information_schema,,0
20180819 17:19:21,slave,cmon,cmon,16,0,CONNECT,information_schema,,0
20180819 19:00:01,slave,cmon,cmon,17,0,CONNECT,information_schema,,0
20180819 19:00:01,slave,cmon,cmon,17,0,DISCONNECT,information_schema,,0Skemaændringsrapport
Hvis du kun skal spore DDL-ændringer, kan du bruge ClusterControl Operational Report on Schema Change. Skemaændringsdetektionsrapporten viser eventuelle DDL-ændringer på din database. Denne funktionalitet kræver en ekstra parameter i ClusterControl-konfigurationsfilen. Hvis dette ikke er indstillet, vil du se følgende information:schema_change_detection_address er ikke indstillet i /etc/cmon.d/cmon_1.cnf. Når det er på plads, kan et eksempel output være som nedenfor:
Det kan sættes op med en tidsplan, og rapporterne kan sendes til modtagerne.
ClusterControl:Planlæg driftsrapport MySQL-databasesikkerhedsvurdering
Pakkeopgraderingstjek
Først vil vi starte med sikkerhedstjek. At være opdateret med MySQL-patches vil hjælpe med at reducere risici forbundet med kendte sårbarheder på MySQL-serveren. Du kan holde dit miljø opdateret ved at bruge leverandørernes pakkelager. Baseret på disse oplysninger kan du bygge dine egne rapporter eller bruge værktøjer som ClusterControl til at verificere dit miljø og advare dig om mulige opdateringer.
ClusterControl Upgrade Report indsamler oplysninger fra operativsystemet og sammenligner dem med pakker, der er tilgængelige i lageret. Rapporten er opdelt i fire afsnit; opgraderingsoversigt, databasepakker, sikkerhedspakker og andre pakker. Du kan hurtigt sammenligne, hvad du har installeret på dit system og finde en anbefalet opgradering eller patch.
ClusterControl:Opgraderingsrapport 
ClusterControl:Opgraderingsrapportdetaljer For at sammenligne dem manuelt kan du køre
SHOW VARIABLES WHERE variable_name LIKE "version";
Med sikkerhedsbulletiner som:
https://www.oracle.com/technetwork/topics/security/alerts-086861.html
https://nvd.nist.gov/view/vuln/search- resultater?adv_search=true&cves=on&cpe_vendor=cpe%3a%2f%3aoracle&cpe_produ
https://www.percona.com/doc/percona-server/SENESTE/release-notes/release-notes_index.html
https://downloads.mariadb.org/mariadb/+releases/
https://www.cvedetails.com/vulnerability-list/vendor_id-12010/Mariadb.html
https://www. cvedetails.com/vulnerability-list/vendor_id-13000/Percona.html
Eller leverandørlagre:
På Debian
sudo apt list mysql-serverPå RHEL/Centos
yum list | grep -i mariadb-serverKonti uden adgangskode
Tomme adgangskoder giver en bruger mulighed for at logge ind uden at bruge en adgangskode. MySQL plejede at komme med et sæt præ-oprettede brugere, hvoraf nogle kan oprette forbindelse til databasen uden adgangskode eller, endnu værre, anonyme brugere. Heldigvis har dette ændret sig i MySQL 5.7. Endelig kommer det kun med en root-konto, der bruger den adgangskode, du vælger på installationstidspunktet.
For hver række, der returneres fra revisionsproceduren, skal du angive en adgangskode:
SELECT User,host
FROM mysql.user
WHERE authentication_string='';Derudover kan du installere et plugin til validering af adgangskode og implementere en mere sikker politik:
INSTALL PLUGIN validate_password SONAME 'validate_password.so';
SHOW VARIABLES LIKE 'default_password_lifetime';
SHOW VARIABLES LIKE 'validate_password%';En god start kan være:
plugin-load=validate_password.so
validate-password=FORCE_PLUS_PERMANENT
validate_password_length=14
validate_password_mixed_case_count=1
validate_password_number_count=1
validate_password_special_char_count=1
validate_password_policy=MEDIUMDisse indstillinger afhænger naturligvis af dine forretningsbehov.
Fjernadgangsovervågning
At undgå brugen af jokertegn i værtsnavne hjælper med at kontrollere de specifikke placeringer, hvorfra en given bruger kan oprette forbindelse til og interagere med databasen.
Du bør sikre dig, at hver bruger kun kan oprette forbindelse til MySQL fra specifikke værter. Du kan altid definere flere indgange for den samme bruger, dette skulle være med til at reducere behovet for jokertegn.
Udfør følgende SQL-sætning for at vurdere denne anbefaling (sørg for, at der ikke returneres rækker):
SELECT user, host FROM mysql.user WHERE host = '%';Test database
Standard MySQL-installationen kommer med en ubrugt database kaldet test, og testdatabasen er tilgængelig for alle brugere, især for de anonyme brugere. Sådanne brugere kan oprette tabeller og skrive til dem. Dette kan potentielt blive et problem i sig selv - og skriver ville tilføje nogle overhead og reducere databasens ydeevne. Det anbefales, at testdatabasen slettes. For at afgøre, om testdatabasen er til stede, skal du køre:
SHOW DATABASES LIKE 'test';Hvis du bemærker, at testdatabasen er til stede, kan det være, at mysql_secure_installation scriptet, som sletter testdatabasen (såvel som andre sikkerhedsrelaterede aktiviteter), ikke blev udført.
INDLÆS DATAINFIL
Hvis både server og klient har mulighed for at køre LOAD DATA LOCAL INFILE, vil en klient være i stand til at indlæse data fra en lokal fil til en ekstern MySQL-server. Local_infile-parameteren dikterer, om filer placeret på MySQL-klientens computer kan indlæses eller vælges via LOAD DATA INFILE eller SELECT local_file.
Dette kan potentielt hjælpe med at læse filer, som klienten har adgang til - for eksempel på en applikationsserver kan man få adgang til alle data, som HTTP-serveren har adgang til. For at undgå det, skal du indstille local-infile=0 i my.cnf.
Kør følgende SQL-sætning og sørg for, at feltet Værdi er sat til OFF:
SHOW VARIABLES WHERE Variable_name = 'local_infile';Overvåg for ikke-krypterede tablespaces
Fra MySQL 5.7.11 understøtter InnoDB datakryptering for tabeller, der er gemt i file-per-table tablespaces. Denne funktion giver hvile-kryptering til fysiske tablespace-datafiler. For at undersøge om dine tabeller er blevet krypteret køres:
mysql> SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES
WHERE CREATE_OPTIONS LIKE '%ENCRYPTION="Y"%';
+--------------+------------+----------------+
| TABLE_SCHEMA | TABLE_NAME | CREATE_OPTIONS |
+--------------+------------+----------------+
| test | t1 | ENCRYPTION="Y" |
+--------------+------------+----------------+Som en del af krypteringen bør du også overveje kryptering af den binære log. MySQL-serveren skriver masser af information til binære logfiler.
Validering af krypteringsforbindelse
I nogle opsætninger bør databasen ikke være tilgængelig via netværket, hvis hver forbindelse administreres lokalt via Unix-socket. I sådanne tilfælde kan du tilføje 'skip-networking'-variablen i my.cnf. Spring over netværk forhindrer MySQL i at bruge enhver TCP/IP-forbindelse, og kun Unix-socket ville være mulig på Linux.
Dette er dog en ret sjælden situation, da det er almindeligt at få adgang til MySQL over netværket. Du skal derefter overvåge, at dine forbindelser er krypteret. MySQL understøtter SSL som et middel til at kryptere trafik både mellem MySQL-servere (replikering) og mellem MySQL-servere og klienter. Hvis du bruger Galera cluster, er lignende funktioner tilgængelige - både intra-cluster kommunikation og forbindelser med klienter kan krypteres ved hjælp af SSL. For at kontrollere, om du bruger SSL-kryptering, skal du køre følgende forespørgsler:
SHOW variables WHERE variable_name = 'have_ssl';
select ssl_verify_server_cert from mysql.slave_master_info;Det er det for nu. Dette er ikke en komplet liste. Lad os vide, hvis der er andre kontroller, du foretager i dag på dine produktionsdatabaser.