Beveiliging van gegevens is tegenwoordig een topprioriteit. Soms wordt het afgedwongen door externe regelgeving zoals PCI-DSS of HIPAA, soms is het omdat u geeft om de gegevens van uw klanten en uw reputatie. Er zijn tal van aspecten van beveiliging waarmee u rekening moet houden - netwerktoegang, beveiliging van het besturingssysteem, subsidies, codering enzovoort. In deze blogpost geven we je 10 tips waar je op moet letten bij het beveiligen van je MySQL- of MariaDB-installatie.
1. Gebruikers verwijderen zonder wachtwoord
MySQL kwam met een reeks vooraf gemaakte gebruikers, waarvan sommige zonder wachtwoord verbinding kunnen maken met de database of, erger nog, anonieme gebruikers. Dit is veranderd in MySQL 5.7, dat standaard alleen wordt geleverd met een root-account dat het wachtwoord gebruikt dat u tijdens de installatie kiest. Toch zijn er MySQL-installaties die zijn geüpgraded van eerdere versies en deze installaties behouden de legacy-gebruikers. Ook MariaDB 10.2 op Centos 7 wordt geleverd met anonieme gebruikers:
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)Zoals u kunt zien, zijn deze alleen beperkt tot toegang vanaf localhost, maar hoe dan ook, dergelijke gebruikers wilt u niet hebben. Hoewel hun privileges beperkt zijn, kunnen ze nog steeds enkele opdrachten uitvoeren die meer informatie over de database kunnen tonen - de versie kan bijvoorbeeld helpen bij het identificeren van andere aanvalsvectoren.
[[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
--------------Houd er rekening mee dat gebruikers met zeer eenvoudige wachtwoorden bijna net zo onveilig zijn als gebruikers zonder wachtwoord. Wachtwoorden zoals "wachtwoord" of "qwerty" zijn niet echt nuttig.
2. Strakke toegang op afstand
Allereerst is externe toegang voor superusers - dit wordt standaard geregeld bij het installeren van de nieuwste MySQL (5.7) of MariaDB (10.2) - alleen lokale toegang beschikbaar. Toch is het vrij gebruikelijk om te zien dat superusers om verschillende redenen beschikbaar zijn. De meest voorkomende, waarschijnlijk omdat de database wordt beheerd door mensen die hun werk gemakkelijker willen maken, dus ze zouden externe toegang tot hun databases toevoegen. Dit is geen goede aanpak, aangezien externe toegang het gemakkelijker maakt om potentiële (of geverifieerde) beveiligingsproblemen in MySQL te misbruiken - u hoeft niet eerst verbinding te maken met de host.
Nog een stap - zorg ervoor dat elke gebruiker alleen vanaf specifieke hosts verbinding kan maken met MySQL. U kunt altijd meerdere vermeldingen voor dezelfde gebruiker definiëren ([email protected], [email protected]), dit zou moeten helpen om de noodzaak voor jokertekens te verminderen ([email protected]'%').
3. Testdatabase verwijderen
De testdatabase is standaard beschikbaar voor elke gebruiker, vooral voor de anonieme gebruikers. Dergelijke gebruikers kunnen tabellen maken en ernaar schrijven. Dit kan op zichzelf al een probleem worden - elke schrijfbewerking zou wat overhead toevoegen en de databaseprestaties verminderen. Momenteel wordt, na de standaardinstallatie, alleen MariaDB 10.2 op Centos 7 hierdoor beïnvloed - Oracle MySQL 5.7 en Percona Server 5.7 hebben niet het 'test'-schema beschikbaar.
[[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)Het kan natuurlijk nog steeds gebeuren dat uw MySQL 5.7 is geüpgraded van eerdere versies waarin het 'test'-schema niet is verwijderd - u moet hier voor zorgen en controleren of u het hebt gemaakt.
4. Verduister de toegang tot MySQL
Het is bekend dat MySQL op poort 3306 draait en dat de superuser 'root' wordt genoemd. Om het nog moeilijker te maken, is het vrij eenvoudig om dit te veranderen. Tot op zekere hoogte is dit een voorbeeld van beveiliging door onduidelijkheid, maar het kan op zijn minst geautomatiseerde pogingen stoppen om toegang te krijgen tot de 'root'-gebruiker. Om de poort te wijzigen, moet u my.cnf bewerken en de variabele 'poort' op een andere waarde instellen. Wat betreft gebruikers:nadat MySQL is geïnstalleerd, moet u een nieuwe superuser maken (ALLES VERLENEN ... MET GRANT-OPTIE) en vervolgens bestaande '[email protected]'-accounts verwijderen.
5. Netwerkbeveiliging
Idealiter zou MySQL niet beschikbaar zijn via het netwerk en zouden alle verbindingen lokaal worden afgehandeld, via de Unix-socket. In sommige opstellingen is dit mogelijk - in dat geval kunt u de variabele 'skip-networking' toevoegen in my.cnf. Dit voorkomt dat MySQL enige TCP/IP-communicatie gebruikt, alleen Unix-socket zou beschikbaar zijn op Linux (Named pipes en gedeeld geheugen op Windows-hosts).
Meestal is een dergelijke strenge beveiliging echter niet haalbaar. In dat geval moet je op zoek naar een andere oplossing. Ten eerste kunt u uw firewall gebruiken om alleen verkeer van specifieke hosts naar de MySQL-server toe te staan. Bijvoorbeeld, applicatiehosts (hoewel ze in orde zouden moeten zijn met het bereiken van MySQL via proxy's), de proxylaag en misschien een beheerserver. Andere hosts in uw netwerk hebben waarschijnlijk geen directe toegang tot de MySQL-server nodig. Dit beperkt de mogelijkheden van aanvallen op uw database, voor het geval sommige hosts in uw netwerk zouden worden gecompromitteerd.
Als u toevallig proxy's gebruikt die reguliere expressies voor zoekopdrachten toestaan, kunt u deze gebruiken om het SQL-verkeer te analyseren en verdachte zoekopdrachten te blokkeren. Hoogstwaarschijnlijk zouden uw applicatiehosts "DELETE * FROM your_table;" niet moeten uitvoeren. op regelmatige basis. Als het nodig is om enkele gegevens te verwijderen, kan dit handmatig, lokaal, op de MySQL-instantie worden uitgevoerd. U kunt dergelijke regels maken met behulp van zoiets als ProxySQL:dergelijke query's blokkeren, herschrijven, omleiden. MaxScale geeft je ook een optie om zoekopdrachten te blokkeren op basis van reguliere expressies.
6. Audit-plug-ins
Als u geïnteresseerd bent in het verzamelen van gegevens over wie wat wanneer heeft uitgevoerd, zijn er verschillende audit-plug-ins beschikbaar voor MySQL. Als u MySQL Enterprise gebruikt, kunt u MySQL Enterprise Audit gebruiken, een uitbreiding op MySQL Enterprise. Percona en MariaDB hebben ook hun eigen versie van audit-plug-ins. Ten slotte kan de McAfee-plug-in voor MySQL ook worden gebruikt met verschillende versies van MySQL. Over het algemeen verzamelen die plug-ins min of meer dezelfde gegevens - gebeurtenissen verbinden en loskoppelen, uitgevoerde query's, geopende tabellen. Dit alles bevat informatie over welke gebruiker heeft deelgenomen aan een dergelijk evenement, van welke host het heeft ingelogd, wanneer het heeft plaatsgevonden enzovoort. De uitvoer kan XML of JSON zijn, dus het is veel gemakkelijker om het te ontleden dan de algemene loginhoud te ontleden (hoewel de gegevens nogal op elkaar lijken). Dergelijke uitvoer kan ook naar syslog worden gestuurd en verder naar een soort logserver voor verwerking en analyse.
7. LAAD GEGEVENS LOKAAL INFILE uitschakelen
Als zowel de server als de client de mogelijkheid hebben om LOAD DATA LOCAL INFILE uit te voeren, kan een client gegevens van een lokaal bestand naar een externe MySQL-server laden. Dit kan mogelijk helpen bij het lezen van bestanden waartoe de client toegang heeft - op een toepassingsserver zou men bijvoorbeeld toegang kunnen krijgen tot elk bestand waartoe de HTTP-server toegang heeft. Om dit te vermijden, moet u local-infile=0 instellen in de my.cnf
8. Bestandsrechten
Houd er rekening mee dat de MySQL-beveiliging ook afhangt van de instellingen van het besturingssysteem. MySQL slaat gegevens op in de vorm van bestanden. De MySQL-server schrijft veel informatie naar logboeken. Soms bevat deze informatie gegevens - bijvoorbeeld een langzame querylog, een algemeen logboek of een binair logboek. U moet ervoor zorgen dat deze informatie veilig is en alleen toegankelijk is voor gebruikers die er toegang toe moeten hebben. Meestal betekent dit dat alleen de root en de gebruiker onder wiens rechten MySQL draait, toegang moeten hebben tot alle MySQL-gerelateerde bestanden. Meestal is het een toegewijde gebruiker genaamd 'mysql'. U moet de MySQL-configuratiebestanden en alle door MySQL gegenereerde logboeken controleren en controleren of ze niet door andere gebruikers kunnen worden gelezen.
9. SSL en versleuteling van gegevens in transit
Voorkomen dat mensen toegang krijgen tot configuratie- en logbestanden is één ding. Het andere probleem is ervoor te zorgen dat gegevens veilig via het netwerk worden overgedragen. Met uitzondering van opstellingen waarbij alle clients lokaal zijn en Unix-socket gebruiken om toegang te krijgen tot MySQL, verlaten in de meeste gevallen gegevens die een resultaatset vormen voor een query, de server en worden ze via het netwerk naar de client verzonden. Gegevens kunnen ook tussen MySQL-servers worden uitgewisseld, bijvoorbeeld via standaard MySQL-replicatie of binnen een Galera-cluster. Netwerkverkeer kan worden opgespoord en op die manier worden uw gegevens zichtbaar.
Om dit te voorkomen, is het mogelijk om SSL te gebruiken om het verkeer te versleutelen, zowel server- als client-side. U kunt een SSL-verbinding maken tussen een client en een MySQL-server. U kunt ook een SSL-verbinding maken tussen uw master en uw slaves, of tussen de nodes van een Galera-cluster. Dit zorgt ervoor dat alle gegevens die worden overgedragen veilig zijn en niet kunnen worden opgesnoven door een aanvaller die toegang heeft gekregen tot uw netwerk.
De MySQL-documentatie behandelt in detail hoe u SSL-codering instelt. Als u het te omslachtig vindt, kan ClusterControl u helpen om met een paar klikken een veilige omgeving voor MySQL-replicatie of Galera-cluster te implementeren:
10. Versleuteling van gegevens in rust
Het beveiligen van gegevens in transit met behulp van SSL-codering lost het probleem slechts gedeeltelijk op. U moet ook zorgen voor gegevens in rust - alle gegevens die in de database zijn opgeslagen. Versleuteling van gegevens in rust kan ook een vereiste zijn voor beveiligingsvoorschriften zoals HIPAA of PCI DSS. Een dergelijke versleuteling kan op meerdere niveaus worden geïmplementeerd - u kunt de hele schijf versleutelen waarop de bestanden zijn opgeslagen. U kunt alleen de MySQL-database versleutelen via functionaliteit die beschikbaar is in de nieuwste versies van MySQL of MariaDB. Versleuteling kan ook in de toepassing worden geïmplementeerd, zodat de gegevens worden versleuteld voordat ze in de database worden opgeslagen. Elke optie heeft zijn voor- en nadelen:schijfversleuteling kan alleen helpen wanneer schijven fysiek worden gestolen, maar de bestanden zouden niet worden versleuteld op een actieve databaseserver. MySQL-databaseversleuteling lost dit probleem op, maar het kan de toegang tot gegevens niet voorkomen wanneer het root-account wordt gecompromitteerd. Versleuteling op applicatieniveau is het meest flexibel en veilig, maar dan verlies je de kracht van SQL - het is vrij moeilijk om versleutelde kolommen te gebruiken in WHERE- of JOIN-clausules.
Alle smaken van MySQL bieden een soort data-at-rest-codering. Oracle's MySQL maakt gebruik van transparante gegevenscodering om InnoDB-tabelruimten te coderen. Dit is beschikbaar in het commerciële MySQL Enterprise-aanbod. Het biedt een optie om InnoDB-tabelruimten te versleutelen, andere bestanden die ook gegevens in een of andere vorm opslaan (bijvoorbeeld binaire logs, algemeen log, log query-log) zijn niet versleuteld. Hierdoor kan de toolchain (MySQL Enterprise Backup maar ook xtrabackup, mysqldump, mysqlbinlog) correct werken met een dergelijke setup.
Vanaf MySQL 5.7.11 kreeg de communityversie van MySQL ook ondersteuning voor InnoDB-tabelruimteversleuteling. Het belangrijkste verschil met het enterprise-aanbod is de manier waarop de sleutels worden opgeslagen - sleutels bevinden zich niet in een beveiligde kluis, wat vereist is voor naleving van de regelgeving. Dit betekent dat het vanaf Percona Server 5.7.11 ook mogelijk is om InnoDB-tabelruimte te versleutelen. In de onlangs gepubliceerde Percona Server 5.7.20 is ondersteuning toegevoegd voor het versleutelen van binaire logs. Het is ook mogelijk om te integreren met de Hashicorp Vault-server via een keyring_vault-plug-in, waarbij de functies die beschikbaar zijn in Oracle's MySQL Enterprise-editie overeenkomen (en zelfs uitbreiden - binaire logcodering).
MariaDB heeft ondersteuning toegevoegd voor gegevenscodering in 10.1.3 - het is een afzonderlijke, verbeterde implementatie. Het geeft je de mogelijkheid om niet alleen InnoDB-tabelruimten te versleutelen, maar ook InnoDB-logbestanden. Als gevolg hiervan zijn gegevens veiliger, maar sommige hulpprogramma's werken niet in een dergelijke configuratie. Xtrabackup werkt niet met gecodeerde redo-logs - MariaDB heeft een vork gemaakt, MariaDB Backup, die ondersteuning voor MariaDB-codering toevoegt. Er zijn ook problemen met mysqlbinlog.
Het maakt niet uit welke MySQL-smaak je gebruikt, zolang het een recente versie is, heb je opties om data-at-rest-codering te implementeren via de databaseserver, zodat je gegevens extra beveiligd zijn.
Het beveiligen van MySQL of MariaDB is niet triviaal, maar we hopen dat deze 10 tips je op weg helpen.
Samenvatting
In het huidige landschap is gegevensbeveiliging een topprioriteit voor elke databasebeheerder. Of uw motivatie nu de naleving van wettelijke vereisten is of het beschermen van uw klanten en de reputatie van uw bedrijf, deze tien tips voor het beveiligen van uw MySQL- en MariaDB-databases zullen u helpen uw infrastructuur verder te beveiligen en u gemoedsrust te geven.
Er zijn tal van maatregelen waarmee u rekening moet houden om ervoor te zorgen dat uw database-infrastructuur veilig is. In dit bericht hebben we de basisprincipes behandeld, zoals gegevenscodering, netwerktoegangscontrole, gebruikersauthenticatie en -rechten, beveiliging van het besturingssysteem en meer.
Automatiseringssoftware voor databasebeheer, zoals ClusterControl, kan een geweldig hulpmiddel zijn bij uw algehele inspanningen op het gebied van databasebeveiliging. Als u op zoek bent naar een diepere duik in elke stap die u moet nemen om uw MySQL-databases te beveiligen, bekijk dan zeker deel 1 en deel 2 van onze serie over het beveiligen van MySQL. Volg ons op Twitter, LinkedIn en abonneer je op onze nieuwsbrief voor updates om op de hoogte te blijven van andere best practices voor databasebeheer.