Dataskydd är en av de viktigaste aspekterna av att administrera en databas. Beroende på organisationsstrukturen, om du är utvecklare, sysadmin eller DBA, om du hanterar produktionsdatabasen, måste du övervaka data för obehörig åtkomst och användning. Syftet med säkerhetsövervakningen är dubbelt. En, för att identifiera obehörig aktivitet på databasen. Och två, för att kontrollera om databaser ´och deras konfigurationer på företagsomfattande basis är kompatibla med säkerhetspolicyer och standarder.
I den här artikeln kommer vi att dela upp övervakning för säkerhet i två kategorier. En kommer att vara relaterad till revision av MySQL- och MariaDB-databasaktiviteter. Den andra kategorin kommer att handla om att övervaka dina instanser för potentiella säkerhetsluckor.
Fråge- och anslutningspolicybaserad övervakning
Kontinuerlig granskning är en absolut nödvändig uppgift för att övervaka din databasmiljö. Genom att granska din databas kan du ta ansvar för vidtagna åtgärder eller åtkomst till innehåll. Dessutom kan revisionen inkludera några kritiska systemkomponenter, till exempel de som är kopplade till finansiell data för att stödja en exakt uppsättning förordningar som SOX eller EU:s GDPR-förordning. Vanligtvis uppnås det genom att logga information om DB-operationer på databasen till en extern loggfil.
Som standard är granskning i MySQL eller MariaDB inaktiverad. Du och uppnå det genom att installera ytterligare plugins eller genom att fånga alla frågor med parametern query_log. Den allmänna frågeloggfilen är en allmän registrering av vad MySQL utför. Servern registrerar viss information till den här loggen när klienter ansluter eller kopplar från, och den loggar varje SQL-sats som tas emot från klienter. På grund av prestandaproblem och brist på konfigurationsalternativ är general_log inte en bra lösning för säkerhetsrevisionsändamål.
Om du använder MySQL Enterprise kan du använda MySQL Enterprise Audit-plugin som är ett tillägg till den proprietära MySQL-versionen. MySQL Enterprise Audit Plugin-plugin är endast tillgänglig med MySQL Enterprise, som är ett kommersiellt erbjudande från Oracle. Percona och MariaDB har skapat sina egna versioner av öppen källkod av revisionsplugin. Slutligen kan McAfee plugin för MySQL också användas med olika versioner av MySQL. I den här artikeln kommer vi att fokusera på plugins med öppen källkod, även om Enterprise-versionen från Oracle verkar vara den mest robusta och stabila.
Kännetecken för MySQL Open Source Audit Plugins
Även om granskningsinsticksprogram för öppen källkod gör samma jobb som Enterprise-plugin från Oracle - de producerar utdata med databasfrågor och anslutningar - finns det några stora arkitekturskillnader.
MariaDB Audit Plugin – MariaDB Audit Plugin fungerar med MariaDB, MySQL (från och med version 5.5.34 och 10.0.7) och Percona Server. MariaDB började inkludera Audit Plugin som standard från versionerna 10.0.10 och 5.5.37, och den kan installeras i valfri version från MariaDB 5.5.20. Det är den enda plugin som stöder Oracle MySQL, Percona Server och MariaDB. Det är tillgängligt på Windows och Linux-plattformar. Versioner som börjar från 1.2 är mest stabila och det kan vara riskabelt att använda versioner under den i din produktionsmiljö.
McAfee MySQL Audit Plugin – Denna plugin använder inte MySQL audit API. Den uppdaterades nyligen för att stödja MySQL 5.7. Vissa tester visar att API-baserade plugins kan ge bättre prestanda men du måste kontrollera det med din miljö.
Percona Audit Log Plugin – Percona tillhandahåller en revisionslösning med öppen källkod som installeras med Percona Server 5.5.37+ och 5.6.17+ som en del av installationsprocessen. Jämfört med andra plugin-program med öppen källkod har detta plugin fler funktioner för räckviddsutdata eftersom det matar ut XML, JSON och till syslog.
Eftersom den har några interna krokar till servern för att vara funktionskompatibel med Oracles plugin, är den inte tillgänglig som en fristående plugin för andra versioner av MySQL.
Plugininstallation baserad på MariaDB granskningstillägg
Installationen av MySQL-plugins med öppen källkod är ganska lik för MariaDB-, Percona- och McAfee-versioner.
Percona och MariaDB lägger till sina plugins som en del av standardserverbinärfilerna, så det finns inget behov av att ladda ner plugins separat. Percona-versionen stöder endast officiellt sin egen MySQL-gaffel så det finns ingen direkt nedladdning från leverantörens webbplats (om du vill använda denna plugin med MySQL måste du skaffa plugin från ett Percona-serverpaket). Om du vill använda MariaDB-pluginet med andra MySQL-gafflar kan du hitta det från https://downloads.mariadb.com/Audit-Plugin/MariaDB-Audit-Plugin/. McAfee-pluginet är tillgängligt på https://github.com/mcafee/mysql-audit/wiki/Installation.
Innan du startar plugin-installationen kan du kontrollera om plugin-programmet finns i systemet. Den dynamiska plugin-platsen (kräver inte omstart av instansen) kan kontrolleras med:
SHOW GLOBAL VARIABLES LIKE 'plugin_dir';
+---------------+--------------------------+
| Variable_name | Value |
+---------------+--------------------------+
| plugin_dir | /usr/lib64/mysql/plugin/ |
+---------------+--------------------------+Kontrollera katalogen som returneras på filsystemnivå för att se till att du har en kopia av pluginbiblioteket. Om du inte har server_audit.so eller server_audit.dll inuti /usr/lib64/mysql/plugin/, är det mer troligt att din MariaDB-version inte stöds och bör uppgradera den till senaste versionen..
Syntaxen för att installera MariaDB-plugin är:
INSTALL SONAME 'server_audit';För att kontrollera installerade plugins måste du köra:
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 |
+-------------------------------+----------+--------------------+--------------------+---------+Om du behöver ytterligare information, kontrollera PLUGINS-tabellen i informationsschemadatabasen som innehåller mer detaljerad information.
Ett annat sätt att installera plugin är att aktivera plugin i my.cnf och starta om instansen. Ett exempel på en grundläggande granskningspluginkonfiguration från MariaDB kan vara:
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=1024Inställningen ovan ska placeras i my.cnf. Granskningsplugin kommer att skapa filen /var/log/mysql/audit.log som kommer att rotera i storlek 1GB och det kommer att göras åtta rotationer tills filen skrivs över. Filen kommer endast att innehålla information om anslutningar.
För närvarande finns det sexton inställningar som du kan använda för att justera MariaDB granskningsplugin.
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_priorityBland dem kan du hitta alternativ för att inkludera eller utesluta användare, ställa in olika loggningshändelser (CONNECT eller QUERY) och växla mellan fil och syslog.
För att säkerställa att plugin-programmet kommer att vara aktiverat vid serverstart måste du ställa in
plugin_load=server_audit=server_audit.so i dina my.cnf-inställningar. Sådan konfiguration kan dessutom skyddas av server_audit=FORCE_PLUS_PERMANENT vilket kommer att inaktivera alternativet för avinstallation av plugin.
UNINSTALL PLUGIN server_audit;
ERROR 1702 (HY000):
Plugin 'server_audit' is force_plus_permanent and can not be unloadedHär är några exempelposter producerade av MariaDB granskningsplugin:
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,,0Schemaändringsrapport
Om du bara behöver spåra DDL-ändringar kan du använda ClusterControl Operational Report on Schema Change. Schema Change Detection Report visar eventuella DDL-ändringar i din databas. Denna funktion kräver ytterligare en parameter i ClusterControl-konfigurationsfilen. Om detta inte är inställt kommer du att se följande information:schema_change_detection_address är inte satt i /etc/cmon.d/cmon_1.cnf. När det väl är på plats kan ett exempelutdata se ut som nedan:
Det kan ställas in med ett schema och rapporterna skickas till mottagarna.
ClusterControl:Schemalägg driftsrapport MySQL-databassäkerhetsbedömning
Kontroll av paketuppgradering
Först börjar vi med säkerhetskontroller. Att vara uppdaterad med MySQL-korrigeringar kommer att bidra till att minska riskerna förknippade med kända sårbarheter som finns i MySQL-servern. Du kan hålla din miljö uppdaterad genom att använda leverantörernas paketförråd. Baserat på denna information kan du bygga dina egna rapporter eller använda verktyg som ClusterControl för att verifiera din miljö och varna dig om möjliga uppdateringar.
ClusterControl Upgrade Report samlar information från operativsystemet och jämför dem med paket som finns tillgängliga i förvaret. Rapporten är uppdelad i fyra avsnitt; uppgraderingssammanfattning, databaspaket, säkerhetspaket och andra paket. Du kan snabbt jämföra vad du har installerat på ditt system och hitta en rekommenderad uppgradering eller patch.
ClusterControl:Uppgraderingsrapport 
ClusterControl:Uppgraderingsrapportdetaljer För att jämföra dem manuellt kan du köra
SHOW VARIABLES WHERE variable_name LIKE "version";
Med säkerhetsbulletiner som:
https://www.oracle.com/technetwork/topics/security/alerts-086861.html
https://nvd.nist.gov/view/vuln/search- results?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 leverantörsförråd:
På Debian
sudo apt list mysql-serverPå RHEL/Centos
yum list | grep -i mariadb-serverKonton utan lösenord
Tomma lösenord tillåter en användare att logga in utan att använda ett lösenord. MySQL brukade komma med en uppsättning förskapade användare, av vilka några kan ansluta till databasen utan lösenord eller, ännu värre, anonyma användare. Lyckligtvis har detta ändrats i MySQL 5.7. Slutligen kommer det bara med ett root-konto som använder lösenordet du valde vid installationen.
För varje rad som returneras från granskningsproceduren, ställ in ett lösenord:
SELECT User,host
FROM mysql.user
WHERE authentication_string='';Dessutom kan du installera ett plugin för lösenordsvalidering och implementera en säkrare policy:
INSTALL PLUGIN validate_password SONAME 'validate_password.so';
SHOW VARIABLES LIKE 'default_password_lifetime';
SHOW VARIABLES LIKE 'validate_password%';En bra början kan vara:
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=MEDIUMNaturligtvis kommer dessa inställningar att bero på ditt företags behov.
Fjärråtkomstövervakning
Att undvika användningen av jokertecken i värdnamn hjälper till att kontrollera de specifika platser från vilka en given användare kan ansluta till och interagera med databasen.
Du bör se till att varje användare endast kan ansluta till MySQL från specifika värdar. Du kan alltid definiera flera poster för samma användare, detta bör bidra till att minska behovet av jokertecken.
Utför följande SQL-sats för att bedöma denna rekommendation (se till att inga rader returneras):
SELECT user, host FROM mysql.user WHERE host = '%';Testa databas
Standard MySQL-installationen kommer med en oanvänd databas som kallas test och testdatabasen är tillgänglig för alla användare, speciellt för anonyma användare. Sådana användare kan skapa tabeller och skriva till dem. Detta kan potentiellt bli ett problem i sig självt - och skriver skulle lägga till lite overhead och minska databasprestanda. Det rekommenderas att testdatabasen tas bort. För att avgöra om testdatabasen finns, kör:
SHOW DATABASES LIKE 'test';Om du märker att testdatabasen finns kan det bero på att mysql_secure_installation-skriptet som tar bort testdatabasen (liksom andra säkerhetsrelaterade aktiviteter) inte kördes.
LADDA DATAINFIL
Om både server och klient har förmågan att köra LOAD DATA LOCAL INFILE, kommer en klient att kunna ladda data från en lokal fil till en fjärransluten MySQL-server. Parametern local_infile bestämmer om filer som finns på MySQL-klientens dator kan laddas eller väljas via LOAD DATA INFILE eller SELECT local_file.
Detta kan potentiellt hjälpa till att läsa filer som klienten har tillgång till - till exempel på en applikationsserver kan man komma åt vilken data som helst som HTTP-servern har tillgång till. För att undvika det måste du ställa in local-infile=0 i my.cnf.
Kör följande SQL-sats och se till att fältet Värde är inställt på AV:
SHOW VARIABLES WHERE Variable_name = 'local_infile';Övervaka icke-krypterade tabellutrymmen
Från och med MySQL 5.7.11 stöder InnoDB datakryptering för tabeller lagrade i fil-per-tabell-tabellutrymmen. Den här funktionen tillhandahåller kryptering i viloläge för fysiska tabellutrymmesdatafiler. För att undersöka om dina tabeller har krypterats, kör:
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 av krypteringen bör du också överväga kryptering av den binära loggen. MySQL-servern skriver massor av information till binära loggar.
Verifiering av krypteringsanslutning
I vissa inställningar bör databasen inte vara tillgänglig via nätverket om varje anslutning hanteras lokalt, via Unix-uttaget. I sådana fall kan du lägga till variabeln "skip-nätverk" i my.cnf. Skip-nätverk förhindrar MySQL från att använda någon TCP/IP-anslutning, och endast Unix-socket skulle vara möjligt på Linux.
Detta är dock ganska sällsynt eftersom det är vanligt att komma åt MySQL över nätverket. Du måste sedan övervaka att dina anslutningar är krypterade. MySQL stöder SSL som ett sätt att kryptera trafik både mellan MySQL-servrar (replikering) och mellan MySQL-servrar och klienter. Om du använder Galera-kluster finns liknande funktioner tillgängliga - både intra-klusterkommunikation och anslutningar med klienter kan krypteras med SSL. Kör följande frågor för att kontrollera om du använder SSL-kryptering:
SHOW variables WHERE variable_name = 'have_ssl';
select ssl_verify_server_cert from mysql.slave_master_info;Det var allt för nu. Det här är inte en fullständig lista, låt oss veta om det finns några andra kontroller som du gör idag på dina produktionsdatabaser.