Das Lesen des Titels dieses Blogbeitrags kann einige Fragen aufwerfen. SQL-Firewall – was ist das? Was tut es? Wozu brauche ich so etwas überhaupt? Nun, die Möglichkeit, bestimmte Abfragen zu blockieren, könnte sich in bestimmten Situationen als nützlich erweisen. Wenn Sie ProxySQL vor Ihren Datenbankservern verwenden, kann der Proxy alle gesendeten SQL-Anweisungen überprüfen. ProxySQL verfügt über eine ausgeklügelte Regel-Engine und kann Abfragen abgleichen, die zugelassen, blockiert, spontan umgeschrieben oder an einen bestimmten Datenbankserver weitergeleitet werden sollen. Sehen wir uns einige Beispiele an.
Sie haben einen dedizierten Slave, der von Entwicklern verwendet wird, um ihre Abfragen anhand von Produktionsdaten zu testen. Sie möchten sicherstellen, dass sich die Entwickler nur mit diesem bestimmten Host verbinden und nur AUSGEWÄHLTE Abfragen ausführen können.
Nehmen wir in einem anderen Fall an, dass Sie zu viele Unfälle mit Personen erlebt haben, die Schemaänderungen ausführen, und Sie möchten einschränken, welche Benutzer die ALTER-Anweisung ausführen können.
Lassen Sie uns abschließend über einen paranoiden Ansatz nachdenken, bei dem Benutzer nur einen vordefinierten Satz von Abfragen auf der weißen Liste ausführen dürfen.
In unserer Umgebung haben wir ein Replikations-Setup mit dem Master und zwei Slaves.
Vor unseren Datenbanken haben wir drei ProxySQL-Knoten, auf denen Keepalived Virtual IP verwaltet. Wir haben auch einen ProxySQL-Cluster konfiguriert (wie in diesem vorherigen Blog erläutert), sodass wir uns keine Gedanken darüber machen müssen, auf allen drei ProxySQL-Knoten dreimal Konfigurations- oder Abfrageregeländerungen vorzunehmen. Für die Abfrageregeln wird eine einfache Lese-Schreib-Aufteilung eingerichtet:
Werfen wir einen Blick darauf, wie ProxySQL mit seinem umfangreichen Abfrageregelmechanismus uns helfen kann, unsere Ziele in all diesen drei Fällen zu erreichen.
Sperren des Benutzerzugriffs auf eine einzelne Hostgruppe
Ein dedizierter Slave, der Entwicklern zur Verfügung steht – das ist keine ungewöhnliche Praxis. Solange Ihre Entwickler auf Produktionsdaten zugreifen können (und wenn ihnen dies z. B. aus Compliance-Gründen nicht gestattet ist, kann die Datenmaskierung, wie in unserem ProxySQL-Tutorial erläutert, hilfreich sein), kann ihnen dies helfen, Abfragen auf realen Daten zu testen und zu optimieren einstellen. Es kann auch hilfreich sein, Daten zu überprüfen, bevor Sie einige der Schemaänderungen ausführen. Ist meine Spalte beispielsweise wirklich eindeutig, bevor ein eindeutiger Index hinzugefügt wird?
Mit ProxySQL ist es ziemlich einfach, den Zugriff einzuschränken. Nehmen wir für den Anfang an, dass die Hostgruppe 30 den Slave enthält, auf den Entwickler zugreifen sollen.
Wir brauchen einen Benutzer, der von den Entwicklern verwendet wird, um auf diesen Slave zuzugreifen. Wenn Sie es bereits in ProxySQL haben, ist das in Ordnung. Wenn nicht, müssen Sie es möglicherweise entweder in ProxySQL importieren (wenn es in MySQL, aber nicht in ProxySQL erstellt wurde) oder an beiden Orten erstellen (wenn Sie einen neuen Benutzer erstellen). Lassen Sie uns mit der letzten Option fortfahren und einen neuen Benutzer erstellen.
Lassen Sie uns einen neuen Benutzer mit eingeschränkten Rechten sowohl für MySQL als auch für ProxySQL erstellen. Wir werden es in Abfrageregeln verwenden, um Traffic zu identifizieren, der von den Entwicklern kommt.
In dieser Abfrageregel leiten wir alle Abfragen, die vom dev_test-Benutzer ausgeführt werden, an die Hostgruppe 30 um. Wir möchten, dass diese Regel aktiv ist und als letzte geparst werden soll, daher haben wir „Übernehmen“ aktiviert. Wir haben die Regel-ID auch so konfiguriert, dass sie kleiner als die ID der ersten vorhandenen Regel ist, da wir möchten, dass diese Abfrage außerhalb der regulären Lese-/Schreib-Aufteilung ausgeführt wird.
Wie Sie sehen können, haben wir einen Benutzernamen verwendet, aber es gibt auch andere Optionen.
Wenn Sie vorhersagen können, welche Entwicklungshosts den Datenverkehr an die Datenbank senden (z. B. können Sie Entwickler einen bestimmten Proxy verwenden lassen, bevor sie die Datenbank erreichen können), können Sie auch die Option „Client-Adresse“ verwenden, um von diesem ausgeführte Abfragen abzugleichen einzelnen Host und leiten sie an eine korrekte Hostgruppe weiter.
Verhindern, dass Benutzer bestimmte Abfragen ausführen
Betrachten wir nun den Fall, in dem wir die Ausführung einiger bestimmter Befehle auf einen bestimmten Benutzer beschränken möchten. Dies kann praktisch sein, um sicherzustellen, dass die richtigen Personen einige der leistungsbeeinträchtigenden Abfragen wie Schemaänderungen ausführen können. ALTER ist die Abfrage, die wir in diesem Beispiel verwenden werden. Lassen Sie uns zunächst einen neuen Benutzer hinzufügen, der Schemaänderungen ausführen darf. Wir nennen es „admin_user“. Als nächstes müssen wir die erforderlichen Abfrageregeln erstellen.
Wir erstellen eine Abfrageregel, die den regulären Ausdruck „.*ALTER TABLE.*“ verwendet, um die Abfragen abzugleichen. Diese Abfrageregel sollte vor anderen Lese-/Schreib-Aufteilungsregeln ausgeführt werden. Wir haben ihr eine Regel-ID von 20 zugewiesen. Wir definieren eine Fehlermeldung, die an den Client zurückgegeben wird, falls diese Abfrageregel ausgelöst wird. Sobald dies erledigt ist, fahren wir mit einer anderen Abfrageregel fort.
Hier verwenden wir denselben regulären Ausdruck, um die Abfrage abzufangen, aber wir definieren keinen Fehlertext (was bedeutet, dass die Abfrage keinen Fehler zurückgibt). Wir definieren auch, welcher Benutzer es ausführen darf (in unserem Fall admin_user). Wir stellen sicher, dass diese Abfrage vor der vorherigen überprüft wird, daher haben wir ihr eine niedrigere Regel-ID von 19 zugewiesen.
Sobald diese beiden Abfrageregeln vorhanden sind, können wir testen, wie sie funktionieren. Versuchen wir, uns als Anwendungsbenutzer anzumelden und eine ALTER TABLE-Abfrage auszuführen:
[email protected]:~# mysql -P6033 -usbtest -ppass -h10.0.0.111
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 43160
Server version: 5.5.30 (ProxySQL)
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use sbtest;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> alter table sbtest1 add index (pad);
ERROR 1148 (42000): You are not allowed to execute ALTER
mysql> ^DByeWie erwartet konnten wir diese Abfrage nicht ausführen und erhielten eine Fehlermeldung. Versuchen wir nun, uns mit unserem „admin_user“ zu verbinden:
[email protected]:~# mysql -P6033 -uadmin_user -ppass -h10.0.0.111
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 43180
Server version: 5.5.30 (ProxySQL)
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use sbtest;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> alter table sbtest1 add index (pad);
Query OK, 0 rows affected (0.99 sec)
Records: 0 Duplicates: 0 Warnings: 0Wir haben es geschafft, ALTER auszuführen, als wir uns mit „admin_user“ angemeldet haben. Dies ist eine sehr einfache Methode, um sicherzustellen, dass nur bestimmte Personen Schemaänderungen an Ihren Datenbanken vornehmen können.
Erstellen einer Whitelist mit zulässigen Abfragen
Betrachten wir abschließend eine eng abgeschlossene Umgebung, in der nur vordefinierte Abfragen ausgeführt werden können. ProxySQL kann einfach verwendet werden, um ein solches Setup zu implementieren.
Zunächst müssen wir alle vorhandenen Abfrageregeln entfernen, bevor wir das implementieren können, was wir benötigen. Dann müssen wir eine Catch-All-Abfrageregel erstellen, die alle Abfragen blockiert:
Der Rest, den wir tun müssen, ist, Abfrageregeln für alle zulässigen Abfragen zu erstellen. Sie können eine Regel pro Abfrage ausführen. Oder Sie können reguläre Ausdrücke verwenden, wenn beispielsweise SELECTs immer ausgeführt werden können. Das Einzige, woran Sie denken müssen, ist, dass die Regel-ID kleiner als die Regel-ID dieser Catch-All-Regel sein muss, und sicherstellen, dass die Abfrage die Regel schließlich trifft, wenn „Anwenden“ aktiviert ist.
Wir hoffen, dass Ihnen dieser Blogbeitrag einen Einblick gegeben hat, wie Sie ClusterControl und ProxySQL verwenden können, um die Sicherheit zu verbessern und die Konformität Ihrer Datenbanken sicherzustellen.
