Datasäkerhet är en högsta prioritet i dessa dagar. Ibland upprätthålls det av externa regler som PCI-DSS eller HIPAA, ibland beror det på att du bryr dig om dina kunders data och ditt rykte. Det finns många aspekter av säkerhet som du måste tänka på - nätverksåtkomst, operativsystemsäkerhet, bidrag, kryptering och så vidare. I det här blogginlägget ger vi dig 10 tips om vad du ska titta på när du säkrar din MySQL- eller MariaDB-installation.
1. Ta bort användare utan 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. Detta har ändrats i MySQL 5.7 som som standard endast kommer med ett root-konto som använder det lösenord du väljer vid installationen. Ändå finns det MySQL-installationer som har uppgraderats från tidigare versioner och dessa installationer behåller de äldre användarna. MariaDB 10.2 på Centos 7 kommer också med anonyma användare:
MariaDB [(none)]> select user, host, password from mysql.user where user like '';
+------+-----------------------+----------+
| user | host | password |
+------+-----------------------+----------+
| | localhost | |
| | localhost.localdomain | |
+------+-----------------------+----------+
2 rows in set (0.00 sec)Som du kan se är de begränsade endast till åtkomst från localhost, men oavsett vill du inte ha sådana användare. Även om deras privilegier är begränsade kan de fortfarande köra vissa kommandon som kan visa mer information om databasen - versionen kan till exempel hjälpa till att identifiera ytterligare attackvektorer.
[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 19
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> \s
--------------
mysql Ver 15.1 Distrib 10.2.11-MariaDB, for Linux (x86_64) using readline 5.1
Connection id: 19
Current database:
Current user: [email protected]
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server: MariaDB
Server version: 10.2.11-MariaDB MariaDB Server
Protocol version: 10
Connection: Localhost via UNIX socket
Server characterset: latin1
Db characterset: latin1
Client characterset: utf8
Conn. characterset: utf8
UNIX socket: /var/lib/mysql/mysql.sock
Uptime: 12 min 14 sec
Threads: 7 Questions: 36 Slow queries: 0 Opens: 17 Flush tables: 1 Open tables: 11 Queries per second avg: 0.049
--------------Observera att användare med mycket enkla lösenord är nästan lika osäkra som användare utan något lösenord. Lösenord som "lösenord" eller "qwerty" är inte riktigt användbara.
2. Tight fjärråtkomst
Först av allt, fjärråtkomst för superanvändare - detta tas om hand som standard när du installerar den senaste MySQL (5.7) eller MariaDB (10.2) - endast lokal åtkomst är tillgänglig. Ändå är det ganska vanligt att se superanvändare vara tillgängliga av olika anledningar. Den vanligaste, förmodligen för att databasen hanteras av människor som vill göra sitt jobb enklare, så de skulle lägga till fjärråtkomst till sina databaser. Detta är inte ett bra tillvägagångssätt eftersom fjärråtkomst gör det lättare att utnyttja potentiella (eller verifierade) säkerhetsbrister i MySQL - du behöver inte få en anslutning till värden först.
Ett annat steg - se till att varje användare kan ansluta till MySQL endast från specifika värdar. Du kan alltid definiera flera poster för samma användare ([email protected], [email protected]), detta bör bidra till att minska behovet av jokertecken ([email protected]’%’).
3. Ta bort testdatabas
Testdatabasen är som standard 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 - alla skrivningar skulle lägga till lite overhead och minska databasprestanda. För närvarande, efter standardinstallationen, är det bara MariaDB 10.2 på Centos 7 som påverkas av detta - Oracle MySQL 5.7 och Percona Server 5.7 har inte "test"-schemat tillgängligt.
[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 13
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> USE test;
Database changed
MariaDB [test]> CREATE TABLE testtable (a INT);
Query OK, 0 rows affected (0.01 sec)
MariaDB [test]> INSERT INTO testtable VALUES (1), (2), (3);
Query OK, 3 rows affected (0.01 sec)
Records: 3 Duplicates: 0 Warnings: 0
MariaDB [test]> SELECT * FROM testtable;
+------+
| a |
+------+
| 1 |
| 2 |
| 3 |
+------+
3 rows in set (0.00 sec)Naturligtvis kan det fortfarande hända att din MySQL 5.7 har uppgraderats från tidigare versioner där 'test'-schemat inte togs bort - du bör ta hand om detta och kontrollera om du har det skapat.
4. Obfuskera åtkomst till MySQL
Det är välkänt att MySQL körs på port 3306, och dess superanvändare kallas 'root'. För att göra saker svårare är det ganska enkelt att ändra detta. Till viss del är detta ett exempel på säkerhet genom dunkel, men det kan åtminstone stoppa automatiserade försök att få tillgång till "root"-användaren. För att ändra port måste du redigera my.cnf och ställa in 'port'-variabeln till något annat värde. När det gäller användare - efter att MySQL har installerats, bör du skapa en ny superanvändare (GIVNA ALLA ... MED BILJANDEALTERNATIV) och sedan ta bort befintliga '[email protected]'-konton.
5. Nätverkssäkerhet
Helst skulle MySQL inte vara tillgängligt via nätverket och alla anslutningar skulle hanteras lokalt, genom Unix-uttaget. I vissa inställningar är detta möjligt - i så fall kan du lägga till variabeln 'skip-networking' i my.cnf. Detta kommer att förhindra MySQL från att använda någon TCP/IP-kommunikation, endast Unix-socket skulle vara tillgängligt på Linux (namngivna rör och delat minne på Windows-värdar).
Men för det mesta är en sådan sträng säkerhet inte möjlig. I så fall måste du hitta en annan lösning. Först kan du använda din brandvägg för att endast tillåta trafik från specifika värdar till MySQL-servern. Till exempel applikationsvärdar (även om de borde vara ok med att nå MySQL via proxyservrar), proxylagret och kanske en hanteringsserver. Andra värdar i ditt nätverk behöver förmodligen inte direktåtkomst till MySQL-servern. Detta kommer att begränsa möjligheterna att attackera din databas, om vissa värdar i ditt nätverk skulle äventyras.
Om du råkar använda proxyservrar som tillåter matchning av reguljära uttryck för frågor, kan du använda dem för att analysera SQL-trafiken och blockera misstänkta frågor. Dina programvärdar bör troligen inte köra "DELETE * FROM your_table;" regelbundet. Om det behövs för att ta bort vissa data kan det köras för hand, lokalt, på MySQL-instansen. Du kan skapa sådana regler med något som ProxySQL:blockera, skriva om, omdirigera sådana frågor. MaxScale ger dig också en möjlighet att blockera frågor baserade på reguljära uttryck.
6. Granska plugins
Om du är intresserad av att samla in data om vem som utförde vad och när, finns det flera granskningsplugins tillgängliga för MySQL. Om du använder MySQL Enterprise kan du använda MySQL Enterprise Audit som är ett tillägg till MySQL Enterprise. Percona och MariaDB har också sin egen version av revisionsplugin. Slutligen kan McAfee-plugin för MySQL också användas med olika versioner av MySQL. Generellt sett samlar dessa insticksprogram in mer eller mindre samma data - anslut och koppla från händelser, exekverade frågor, tabeller åtkomst. Allt detta innehåller information om vilken användare som deltog i en sådan händelse, från vilken värd den loggade från, när hände det och så vidare. Utdata kan vara XML eller JSON, så det är mycket lättare att analysera det än att analysera allmänt logginnehåll (även om data är ganska lika). Sådan utdata kan också skickas till syslog och, vidare, någon sorts loggserver för bearbetning och analys.
7. Inaktivera LOAD DATA LOCAL INFILE
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. 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 fil 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
8. Filrättigheter
Du måste komma ihåg att MySQL-säkerhet också beror på operativsystemets inställning. MySQL lagrar data i form av filer. MySQL-servern skriver massor av information till loggar. Ibland innehåller denna information data - långsam frågelogg, allmän logg eller binär logg, till exempel. Du måste se till att denna information är säker och tillgänglig endast för användare som måste komma åt den. Vanligtvis betyder det att endast roten och användaren under vars rättigheter MySQL körs ska ha tillgång till alla MySQL-relaterade filer. För det mesta är det en dedikerad användare som heter "mysql". Du bör kontrollera MySQL-konfigurationsfiler och alla loggar som genereras av MySQL och verifiera att de inte kan läsas av andra användare.
9. SSL och kryptering av data under transport
Att hindra människor från att komma åt konfigurations- och loggfiler är en sak. Den andra frågan är att se till att data överförs säkert över nätverket. Med undantag för inställningar där alla klienter är lokala och använder Unix-socket för att komma åt MySQL, i de flesta fall lämnar data som bildar en resultatuppsättning för en fråga servern och överförs till klienten över nätverket. Data kan också överföras mellan MySQL-servrar, till exempel via standard MySQLreplikering eller inom ett Galera-kluster. Nätverkstrafik kan sniffas, och på det sättet skulle din data exponeras.
För att förhindra att detta händer är det möjligt att använda SSL för att kryptera trafik, både server- och klientsidan. Du kan skapa en SSL-anslutning mellan en klient och en MySQL-server. Du kan också skapa en SSL-anslutning mellan din master och dina slavar, eller mellan noderna i ett Galera-kluster. Detta kommer att säkerställa att all data som överförs är säker och inte kan sniffas av en angripare som fått tillgång till ditt nätverk.
MySQL-dokumentationen täcker i detalj hur man ställer in SSL-kryptering. Om du tycker att det är för krångligt kan ClusterControl hjälpa dig att distribuera en säker miljö för MySQL-replikering eller Galera-kluster med ett par klick:
10. Kryptering av data i vila
Att säkra data under överföring med SSL-kryptering löser bara delvis problemet. Du måste också ta hand om data i vila - all data som finns lagrad i databasen. Data i vila kryptering kan också vara ett krav för säkerhetsbestämmelser som HIPAA eller PCI DSS. Sådan kryptering kan implementeras på flera nivåer - du kan kryptera hela disken som filerna lagras på. Du kan endast kryptera MySQL-databasen genom funktionalitet som är tillgänglig i de senaste versionerna av MySQL eller MariaDB. Kryptering kan också implementeras i applikationen, så att den krypterar data innan den lagras i databasen. Varje alternativ har sina för- och nackdelar:diskkryptering kan bara hjälpa när diskar är fysiskt stulna, men filerna skulle inte krypteras på en databasserver som körs. MySQL-databaskryptering löser det här problemet, men det kan inte förhindra åtkomst till data när root-kontot äventyras. Kryptering på applikationsnivå är den mest flexibla och säkraste, men då tappar du kraften i SQL - det är ganska svårt att använda krypterade kolumner i WHERE- eller JOIN-satser.
Alla varianter av MySQL ger någon form av data vid vila kryptering. Oracles MySQL använder Transparent Data Encryption för att kryptera InnoDB-tabellutrymmen. Detta är tillgängligt i det kommersiella MySQL Enterprise-erbjudandet. Det ger en möjlighet att kryptera InnoDB-tabellutrymmen, andra filer som också lagrar data i någon form (till exempel binära loggar, allmän logg, långsam frågelogg) är inte krypterade. Detta gör att verktygskedjan (MySQL Enterprise Backup men också xtrabackup, mysqldump, mysqlbinlog) fungerar korrekt med en sådan installation.
Från och med MySQL 5.7.11 fick communityversionen av MySQL även stöd för InnoDB-tabellutrymmeskryptering. Den största skillnaden jämfört med företagserbjudandet är hur nycklarna lagras - nycklar är inte placerade i ett säkert valv, vilket krävs för efterlevnad av regelverk. Detta innebär att från och med Percona Server 5.7.11 är det också möjligt att kryptera InnoDB-tabellutrymmet. I den nyligen publicerade Percona Server 5.7.20 har stöd för kryptering av binära loggar lagts till. Det är också möjligt att integrera med Hashicorp Vault-server via en keyring_vault-plugin, som matchar (och till och med utökar - binär loggkryptering) funktionerna som är tillgängliga i Oracles MySQL Enterprise-utgåva.
MariaDB lade till stöd för datakryptering i 10.1.3 - det är en separat, förbättrad implementering. Det ger dig möjligheten att inte bara kryptera InnoDB-tabellutrymmen, utan även InnoDB-loggfiler. Som ett resultat är data säkrare men vissa av verktygen fungerar inte i en sådan konfiguration. Xtrabackup kommer inte att fungera med krypterade redo-loggar - MariaDB skapade en gaffel, MariaDB Backup, som lägger till stöd för MariaDB-kryptering. Det finns också problem med mysqlbinlog.
Oavsett vilken MySQL-smak du använder, så länge det är en ny version, skulle du ha alternativ att implementera data i vila kryptering via databasservern, och se till att dina data är extra säkrade.
Att säkra MySQL eller MariaDB är inte trivialt, men vi hoppas att dessa 10 tips hjälper dig på vägen.
Sammanfattning
I dagens landskap är datasäkerhet en högsta prioritet för varje databasadministratör. Oavsett om din motivation är att följa regelverk eller att skydda dina kunder och ditt företags rykte, kommer dessa tio tips för att säkra dina MySQL- och MariaDB-databaser att hjälpa dig att ytterligare säkra din infrastruktur och ge dig sinnesfrid.
Det finns många åtgärder att tänka på när du säkerställer att din databasinfrastruktur är säker. I det här inlägget har vi täckt grunderna som datakryptering, nätverksåtkomstkontroller, användarautentisering och privilegier, operativsystemsäkerhet och mer.
Databashanteringsautomationsprogramvara, som ClusterControl, kan vara ett utmärkt verktyg för att hjälpa dig i din övergripande databassäkerhetssatsning. Om du letar efter en djupare dykning i varje steg du måste ta för att säkra dina MySQL-databaser, var noga med att kolla in del 1 och del 2 av vår serie om hur man säkrar MySQL. För att hålla dig informerad om andra bästa metoder för databashantering, följ oss på Twitter, LinkedIn och prenumerera på vårt nyhetsbrev för uppdateringar.