Datasikkerhed er en topprioritet i disse dage. Nogle gange håndhæves det af eksterne regler som PCI-DSS eller HIPAA, nogle gange er det fordi du bekymrer dig om dine kunders data og dit omdømme. Der er adskillige aspekter af sikkerhed, som du skal huske på - netværksadgang, operativsystemsikkerhed, tilskud, kryptering og så videre. I dette blogindlæg giver vi dig 10 tips til, hvad du skal se på, når du sikrer din MySQL- eller MariaDB-opsætning.
1. Fjern brugere uden adgangskode
MySQL plejede at komme med et sæt præ-oprettede brugere, hvoraf nogle kan oprette forbindelse til databasen uden en adgangskode eller, endnu værre, anonyme brugere. Dette er ændret i MySQL 5.7, som som standard kun kommer med en root-konto, der bruger den adgangskode, du vælger på installationstidspunktet. Alligevel er der MySQL-installationer, som blev opgraderet fra tidligere versioner, og disse installationer bevarer de gamle brugere. MariaDB 10.2 på Centos 7 kommer også med anonyme brugere:
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, er disse kun begrænset til adgang fra localhost, men uanset hvad ønsker du ikke at have sådan nogle brugere. Selvom deres privilegier er begrænsede, kan de stadig køre nogle kommandoer, som kan vise mere information om databasen - for eksempel kan versionen hjælpe med at identificere yderligere angrebsvektorer.
[[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
--------------Bemærk venligst, at brugere med meget enkle adgangskoder er næsten lige så usikre som brugere uden adgangskode. Adgangskoder som "adgangskode" eller "qwerty" er ikke rigtig nyttige.
2. Tæt fjernadgang
Først og fremmest fjernadgang for superbrugere - dette tages som standard ved installation af den nyeste MySQL (5.7) eller MariaDB (10.2) - kun lokal adgang er tilgængelig. Alligevel er det ret almindeligt at se superbrugere være tilgængelige af forskellige årsager. Den mest almindelige, sandsynligvis fordi databasen administreres af mennesker, der ønsker at gøre deres arbejde lettere, så de vil tilføje fjernadgang til deres databaser. Dette er ikke en god tilgang, da fjernadgang gør det nemmere at udnytte potentielle (eller verificerede) sikkerhedssårbarheder i MySQL - du behøver ikke at oprette forbindelse til værten først.
Et andet trin - sørg for, at hver bruger kun kan oprette forbindelse til MySQL fra specifikke værter. Du kan altid definere flere indgange for den samme bruger ([email protected], [email protected]), dette skulle være med til at reducere behovet for jokertegn ([email protected]'%').
3. Fjern testdatabase
Testdatabasen er som standard 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 - enhver skrivning ville tilføje nogle overhead og reducere databasens ydeevne. I øjeblikket, efter standardinstallationen, er det kun MariaDB 10.2 på Centos 7, der er påvirket af dette - Oracle MySQL 5.7 og Percona Server 5.7 har ikke 'test'-skemaet tilgængeligt.
[[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)Det kan selvfølgelig stadig ske, at din MySQL 5.7 er blevet opgraderet fra tidligere versioner, hvor 'test'-skemaet ikke blev fjernet - du bør tage dig af dette og tjekke, om du har det oprettet.
4. Tilsløret adgang til MySQL
Det er velkendt, at MySQL kører på port 3306, og dens superbruger hedder 'root'. For at gøre tingene sværere, er det ganske enkelt at ændre dette. Til en vis grad er dette et eksempel på sikkerhed gennem uklarhed, men det kan i det mindste stoppe automatiserede forsøg på at få adgang til 'root'-brugeren. For at ændre port skal du redigere my.cnf og indstille 'port' variabel til en anden værdi. Med hensyn til brugere - efter MySQL er installeret, skal du oprette en ny superbruger (GIV ALLE ... MED TILDELINGSMULIGHED) og derefter fjerne eksisterende '[email protected]'-konti.
5. Netværkssikkerhed
Ideelt set ville MySQL ikke være tilgængelig via netværket, og alle forbindelser ville blive håndteret lokalt gennem Unix-stikket. I nogle opsætninger er dette muligt – i så fald kan du tilføje variablen ‘skip-networking’ i my.cnf. Dette vil forhindre MySQL i at bruge enhver TCP/IP-kommunikation, kun Unix-socket ville være tilgængelig på Linux (navngivne rør og delt hukommelse på Windows-værter).
Det meste af tiden er en sådan stram sikkerhed dog ikke mulig. I så fald skal du finde en anden løsning. For det første kan du bruge din firewall til kun at tillade trafik fra specifikke værter til MySQL-serveren. For eksempel applikationsværter (selvom de burde være ok med at nå MySQL gennem proxyer), proxylaget og måske en administrationsserver. Andre værter i dit netværk har sandsynligvis ikke brug for direkte adgang til MySQL-serveren. Dette vil begrænse mulighederne for angreb på din database, hvis nogle værter i dit netværk ville blive kompromitteret.
Hvis du tilfældigvis bruger proxyer, der tillader matchning af regulære udtryk for forespørgsler, kan du bruge dem til at analysere SQL-trafikken og blokere mistænkelige forespørgsler. Mest sandsynligt bør dine applikationsværter ikke køre "DELETE * FROM your_table;" regelmæssigt. Hvis det er nødvendigt at fjerne nogle data, kan det udføres manuelt, lokalt, på MySQL-instansen. Du kan oprette sådanne regler ved at bruge noget som ProxySQL:blokere, omskrive, omdirigere sådanne forespørgsler. MaxScale giver dig også mulighed for at blokere forespørgsler baseret på regulære udtryk.
6. Revisionsplugins
Hvis du er interesseret i at indsamle data om, hvem der udførte hvad og hvornår, er der flere audit plugins tilgængelige til MySQL. Hvis du bruger MySQL Enterprise, kan du bruge MySQL Enterprise Audit, som er en udvidelse til MySQL Enterprise. Percona og MariaDB har også deres egen version af audit plugins. Endelig kan McAfee plugin til MySQL også bruges med forskellige versioner af MySQL. Generelt indsamler disse plugins mere eller mindre de samme data - tilslut og afbryd begivenheder, udførte forespørgsler, tabeller, der er tilgået. Alt dette indeholder information om, hvilken bruger der deltog i en sådan begivenhed, fra hvilken vært den loggede fra, hvornår det skete og så videre. Outputtet kan være XML eller JSON, så det er meget nemmere at parse det end at parse generelt logindhold (selvom dataene er ret ens). Sådanne output kan også sendes til syslog og yderligere en form for logserver til behandling og analyse.
7. Deaktiver LOAD DATA LOCAL INFILE
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. 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 enhver fil, som HTTP-serveren har adgang til. For at undgå det, skal du indstille local-infile=0 i my.cnf
8. Filprivilegier
Du skal huske på, at MySQL-sikkerhed også afhænger af operativsystemets opsætning. MySQL gemmer data i form af filer. MySQL-serveren skriver masser af information til logfiler. Nogle gange indeholder denne information data - for eksempel langsom forespørgselslog, generel log eller binær log. Du skal sørge for, at disse oplysninger er sikre og kun tilgængelige for brugere, der skal have adgang til dem. Typisk betyder det, at kun roden og brugeren, under hvis rettigheder MySQL kører, skal have adgang til alle MySQL-relaterede filer. Det meste af tiden er det en dedikeret bruger kaldet 'mysql'. Du bør kontrollere MySQL-konfigurationsfiler og alle logfiler, der er genereret af MySQL, og verificere, at de ikke kan læses af andre brugere.
9. SSL og kryptering af data i transit
At forhindre folk i at få adgang til konfigurations- og logfiler er én ting. Det andet problem er at sikre, at data overføres sikkert over netværket. Med undtagelse af opsætninger, hvor alle klienterne er lokale og bruger Unix-socket til at få adgang til MySQL, forlader data, som danner et resultatsæt for en forespørgsel, i de fleste tilfælde serveren og overføres til klienten over netværket. Data kan også overføres mellem MySQL-servere, for eksempel via standard MySQLreplikering eller inden for en Galera-klynge. Netværkstrafik kan sniffes, og på den måde vil dine data blive afsløret.
For at forhindre dette i at ske, er det muligt at bruge SSL til at kryptere trafik, både server- og klientsiden. Du kan oprette en SSL-forbindelse mellem en klient og en MySQL-server. Du kan også oprette en SSL-forbindelse mellem din master og dine slaver eller mellem noderne i en Galera-klynge. Dette vil sikre, at alle data, der overføres, er sikre og ikke kan sniffes af en angriber, der har fået adgang til dit netværk.
MySQL-dokumentationen dækker i detaljer, hvordan du opsætter SSL-kryptering. Hvis du finder det for besværligt, kan ClusterControl hjælpe dig med at implementere et sikkert miljø til MySQL-replikering eller Galera-klynge med et par klik:
10. Kryptering af data i hvile
Sikring af data i transit ved hjælp af SSL-kryptering løser kun delvist problemet. Du skal også passe på data i hvile - alle de data, der er gemt i databasen. Data i hvile kryptering kan også være et krav for sikkerhedsbestemmelser som HIPAA eller PCI DSS. En sådan kryptering kan implementeres på flere niveauer - du kan kryptere hele disken, hvorpå filerne er gemt. Du kan kun kryptere MySQL-databasen gennem funktionalitet, der er tilgængelig i de seneste versioner af MySQL eller MariaDB. Kryptering kan også implementeres i applikationen, så den krypterer dataene, inden de lagres i databasen. Hver mulighed har sine fordele og ulemper:diskkryptering kan kun hjælpe, når diske bliver stjålet fysisk, men filerne vil ikke blive krypteret på en kørende databaseserver. MySQL-databasekryptering løser dette problem, men det kan ikke forhindre adgang til data, når root-kontoen er kompromitteret. Kryptering på applikationsniveau er det mest fleksible og sikre, men så mister du kraften i SQL - det er ret svært at bruge krypterede kolonner i WHERE- eller JOIN-klausuler.
Alle varianter af MySQL giver en slags data i hvile kryptering. Oracles MySQL bruger Transparent Data Encryption til at kryptere InnoDB-tablespaces. Dette er tilgængeligt i det kommercielle MySQL Enterprise-tilbud. Det giver mulighed for at kryptere InnoDB-tablespaces, andre filer, som også gemmer data i en eller anden form (for eksempel binære logfiler, generel log, langsom forespørgselslog) er ikke krypteret. Dette gør det muligt for værktøjskæden (MySQL Enterprise Backup men også xtrabackup, mysqldump, mysqlbinlog) at fungere korrekt med en sådan opsætning.
Fra MySQL 5.7.11 fik fællesskabsversionen af MySQL også understøttelse af InnoDB tablespace-kryptering. Den største forskel i forhold til virksomhedens tilbud er måden nøglerne opbevares på - nøgler er ikke placeret i en sikker boks, hvilket er påkrævet for at overholde lovgivningen. Det betyder, at fra Percona Server 5.7.11 er det også muligt at kryptere InnoDB tablespace. I den nyligt udgivne Percona Server 5.7.20 er der tilføjet understøttelse af kryptering af binære logfiler. Det er også muligt at integrere med Hashicorp Vault-server via et keyring_vault-plugin, der matcher (og endda udvider - binær logkryptering) de funktioner, der er tilgængelige i Oracles MySQL Enterprise-udgave.
MariaDB tilføjede understøttelse af datakryptering i 10.1.3 - det er en separat, forbedret implementering. Det giver dig mulighed for ikke kun at kryptere InnoDB-tablespaces, men også InnoDB-logfiler. Som et resultat er data mere sikre, men nogle af værktøjerne fungerer ikke i en sådan konfiguration. Xtrabackup vil ikke fungere med krypterede redo-logfiler - MariaDB oprettede en gaffel, MariaDB Backup, som tilføjer understøttelse af MariaDB-kryptering. Der er også problemer med mysqlbinlog.
Lige meget hvilken MySQL-variant du bruger, så længe det er en nyere version, vil du have muligheder for at implementere data i hvile-kryptering via databaseserveren, og sikre dig, at dine data er yderligere sikret.
At sikre MySQL eller MariaDB er ikke trivielt, men vi håber, at disse 10 tips vil hjælpe dig på vej.
Oversigt
I nutidens landskab er datasikkerhed en topprioritet for enhver databaseadministrator. Uanset om din motivation er overholdelse af lovkrav eller beskyttelse af dine kunder og din virksomheds omdømme, vil disse ti tips til at sikre dine MySQL- og MariaDB-databaser hjælpe dig yderligere med at sikre din infrastruktur og give dig ro i sindet.
Der er adskillige forholdsregler at overveje, når du skal sikre, at din databaseinfrastruktur er sikker. I dette indlæg har vi dækket det grundlæggende, såsom datakryptering, netværksadgangskontrol, brugergodkendelse og privilegier, operativsystemsikkerhed og mere.
Databasestyringsautomatiseringssoftware, som ClusterControl, kan være et fantastisk værktøj til at hjælpe med din overordnede databasesikkerhedsindsats. Hvis du leder efter et dybere dyk ned i hvert trin, du skal tage for at sikre dine MySQL-databaser, skal du sørge for at tjekke del 1 og del 2 af vores serie om Sådan sikrer du MySQL. Følg os på Twitter, LinkedIn og abonner på vores nyhedsbrev for opdateringer for at holde dig informeret om andre bedste praksisser for databasestyring.