Sicherheit ist heute in der gesamten IT von größter Bedeutung. Von Zeit zu Zeit hören wir von Ransomware-Angriffen oder Datenlecks, die ihren Ursprung in nicht gesicherten Datenbanken oder IT-Infrastrukturen haben. Sie fragen sich vielleicht:Was sind die Best Practices bei der Architektur einer MySQL-Umgebung, damit Sie sich in Bezug auf Ihre Daten sicher fühlen können? Dann ist dieser Blog genau das Richtige für Sie. Bitte beachten Sie, dass wir das Thema nicht vollständig behandeln werden – dies würde eher in ein Whitepaper als in einen Blog passen. Wir werden unser Bestes tun, um die wichtigsten Aspekte der Sicherung Ihrer MySQL-Datenbank zu erwähnen. Die Idee hinter diesem Blog ist, dass der Leser weiß, was er oder sie nicht weiß, und ihm hilft, die Themen und Schlüsselwörter für die weitere Recherche zu identifizieren. Wir werden es mit Screenshots unseres Produkts ClusterControl veranschaulichen, das mit einer Vielzahl von Funktionen ausgestattet ist, darunter einige zur Datenbanksicherheit.
Netzwerk
Zunächst müssen wir MySQL irgendwo bereitstellen. Sei es eigenständige Instanz, asynchrone Primär-Replikat-Replikation oder eine der fortschrittlicheren, synchronen Replikationstopologien wie Galera oder InnoDB Cluster. Egal was es ist, es muss auf Netzwerkebene geschützt werden. Die Datenbank enthält die Daten, die in der Regel das wertvollste Gut einer ganzen Organisation sind.
Zugriff sichern
Datenbankinstanzen sollten sich niemals im öffentlichen Netzwerk befinden. Netzwerksegmente, in denen Datenbanken konfiguriert sind, sollten nur von einer begrenzten Anzahl anderer Netzwerke aus zugänglich sein. Die Faustregel lautet:Sollte ein bestimmter Knoten auf das Datenbanknetzwerk zugreifen können? Wenn die Antwort nein ist, sollten die Netzwerke getrennt werden.
Natürlich hängt alles von der genauen Einrichtung ab, aber in den häufigsten Fällen, in denen Sie Anwendungs-, Proxy-, Cache- und Datenbankschichten haben, wäre die typischste Einrichtung, dass nur der Proxy dazu in der Lage sein sollte um auf die Datenbank zuzugreifen. Alle anderen Entitäten sollten so konfiguriert werden, dass sie nur über die Proxy-Schicht auf die Datenbank zugreifen. Dieses Design ist in vielerlei Hinsicht gut. Neben der erhöhten Sicherheit trägt es auch dazu bei, die Komplexität der Datenbankebene vor der Anwendung zu verbergen.
Die Proxy-Schicht sollte der Datenbanktopologie folgen und die Datenbankknotenausfälle und Topologieänderungen handhaben. Eine Anwendung, die sich mit der Proxy-Schicht verbindet, sollte immer in der Lage sein, einen funktionierenden Datenbankknoten zu erreichen, der für den Typ der Anfrage relevant ist. Dasselbe gilt für die Cache-Schicht. Es kann in der Proxy-Schicht implementiert werden, einige Proxys wie ProxySQL erlauben Cache-Anforderungen innerhalb des Proxys, aber wenn es sich um eine separate Schicht handelt, die beispielsweise um Memcache oder Redis herum aufgebaut ist, sollte es immer über die Proxy-Schicht auf die Datenbank zugreifen.
Eine weitere Art von Knoten, die möglicherweise direkten Zugriff auf die Datenbankschicht haben müssen, sind Verwaltungsknoten - diejenigen, die von den Betriebsteams zum Verwalten der Datenbanken verwendet werden. Der Grund ist einfach:Einige der Wartungsaufgaben erfordern möglicherweise einen direkten Zugriff auf die Datenbanken. Dies können Skripte zur Aufgabenautomatisierung, Rolling Ansible Playbooks über die gesamte Datenbankflotte oder andere Aufgaben sein. In diesem Fall sollten natürlich Sicherheitsmaßnahmen vorhanden sein, um sicherzustellen, dass sich nur die Personen mit Zugriff bei einem solchen Verwaltungsknoten anmelden können.
Ein weiterer möglicher Typ von Knoten (obwohl dafür auch Verwaltungsknoten verwendet werden können), die möglicherweise Zugriff auf die Datenbank benötigen, sind Knoten, die an der Erfassung von Metriken und deren Präsentation für die Benutzer beteiligt sind – wir sprechen hier über Überwachung und Warnaktivitäten.
VPN
Für jede Art von Datenbankebene, die sich über mehrere Rechenzentren erstreckt, sollten Sie die Verwendung von VPN in Betracht ziehen, um sie zu verbinden. Offene, unverschlüsselte Verbindungen über ein WAN-Netzwerk sollten niemals vorkommen. Selbst das Einrichten der SSL-Verschlüsselung ist nicht die beste Option, da dafür der Zugriff zwischen der Datenbankschicht und dem WAN geöffnet werden müsste – SSL-Verbindungen zwischen Datenbankknoten erfordern, dass sie sich direkt verbinden können. VPN löst dieses Problem, indem es einen Mittelsmann hinzufügt, der eine sichere Methode zur Verbindung von Segmenten des Netzwerks der Datenbankebene schafft.
VPN sollte auch für jede Art von Benutzerzugriff auf das Netzwerk der Organisation obligatorisch sein, da es eine sichere Verbindung zwischen einer Arbeitsstation und dem Produktionsnetzwerk implementiert.
Firewall
Natürlich sollten wir bei der Sicherung des Netzwerks die Verwendung der Firewall in Betracht ziehen. Im Allgemeinen sollte jeder Datenbankknoten nur Verbindungen von einem definierten Satz von Quellen erhalten – Hostnamen und Ports. Auch die „erforderlichen“ Netzwerksegmente sollten nicht vollen Zugriff auf das Datenbanknetzwerk haben, sondern nur auf die benötigten Ports. Wenn der Proxy nur eine Verbindung zum Datenbankport herstellen muss, gibt es keinen Grund dafür, dass er auf einen anderen Port auf den Datenbankknoten zugreifen kann. Bitte beachten Sie auch, dass Sie nicht die Standardports verwenden sollten. Es ist offensichtlich Sicherheit durch Unklarheit - schließlich ist der Port irgendwo offen, aber es hilft, zumindest einige der Sicherheitsverletzungen zu bewältigen, die automatisierte Skripte verwenden. Es wird jemanden, der entschlossen ist, den Zugriff zu erhalten, nicht daran hindern, kann ihn jedoch verlangsamen (in Verbindung mit Port-Scanning-Erkennung und Anti-Scan-Maßnahmen), während automatisierte Angriffe am Erfolg gehindert werden.
Datenbanksicherheit
Das Netzwerk ist die erste Verteidigungslinie, es gibt andere Sicherheitsmaßnahmen und bewährte Verfahren, mit denen Sie Ihre Sicherheit noch weiter verbessern können. Einige davon können in der Datenbank selbst implementiert werden.
Benutzer und Hosts
Datenbanken selbst können verwendet werden, um Zugriffskontrollen und -beschränkungen zu implementieren. Für den Anfang können Sie eine hostbasierte Zugriffskontrolle implementieren, die andere Hosts als die kurze Liste von Knoten daran hindert, sich bei der Datenbank anzumelden. Wenn Sie eine Firewall verwendet haben, um den Zugriff zu beschränken, mag dies natürlich wie ein Duplikat klingen, aber es ist immer noch eine gute Idee, den Zugriff auf die Datenbank selbst zu beschränken - Sie wissen nie, wann eine Firewall versehentlich deaktiviert wird. In einem solchen Fall haben Sie immer noch eine zweite Schutzschicht.
Was Sie hier implementieren möchten, ist eine Liste von Datenbankbenutzern und Hosts, die auf die Datenbank zugreifen dürfen. Höchstwahrscheinlich sollten Sie am Ende einem oder mehreren Benutzern Zugriff von Hosts gewähren, die sich in der Proxy-Schicht befinden. Wie detailliert die Zugriffskontrolle ist, hängt von Ihrem Datenbanksystem ab. MySQL zum Beispiel erlaubt keine detaillierte Kontrolle über die Netzwerkmasken – es verwendet einfach /32, /24, /16 oder /8. In PostgreSQL hingegen können Sie jede Art von Netzwerkmaske verwenden.
Zuschüsse
Wenn Ihre Datenbank dies zulässt, sollte jeder Benutzer über einen definierten Satz von Berechtigungen verfügen - um sicherzustellen, dass die ihm zugewiesenen Berechtigungen das Minimum sind, das der Benutzer benötigt, um die Aktionen auszuführen, die er ausführen muss . Datenbanksysteme können unterschiedliche Sätze von Berechtigungen und unterschiedliche Ebenen davon haben. Typischerweise haben wir mehrere Berechtigungsebenen - global, die den gesamten Datenbankserver betreffen, Schemaebene - gegebene Benutzer können verschiedenen Schemas unterschiedliche Berechtigungen zugewiesen haben. Sie können Berechtigungen auf Tabellen- oder sogar auf Spaltenebene haben. Wie wir bereits erwähnt haben, besteht das Ziel darin, die minimalen Berechtigungen für jeden Benutzer zu erstellen. Sie werden wahrscheinlich mindestens einen Benutzer mit hohen Privilegien haben wollen - er würde verwendet, um die Datenbank zu verwalten. Solche Benutzer sollten streng eingeschränkt sein, wenn es um Konnektivität geht. Es sollte nicht erlaubt sein (und in der Tat keinem der Benutzer), sich von irgendeinem Standort aus zu verbinden – es sollte entweder ein lokaler Host oder ein bestimmter Verwaltungsknoten sein, der dazu bestimmt ist, Operationen auf der Datenbank durchzuführen.
Passwortverwaltung
Für jeden Benutzer in der Datenbank sollte ein Passwort definiert sein. Dies ist ein Kinderspiel. Das Passwort sollte in Form eines Hashs gespeichert werden. Sie sollten darauf achten, dass Sie zum Speichern der Passwörter den sichersten Hash-Algorithmus verwenden, den Ihre Datenbank zu bieten hat. Passwörter sollten weder leicht zu erraten noch für den Wörterbuchangriff anfällig sein. Bei einigen Datenbanksystemen, wie MySQL, können Sie genau definieren, welche Anforderungen Ihre Passwörter erfüllen müssen, damit sie verwendet werden können. Klein- und Großbuchstaben, Zahlen, Sonderzeichen, Länge des Passworts – all das ist wichtig, und wenn Sie einige Richtlinien zur Passwortstärke durchsetzen können, sollten Sie dies tun. Ein weiterer wichtiger Punkt ist die Passwortrotation. Passwörter sollten nicht einmalig und für die gesamte Lebensdauer der Datenbank erstellt werden, Sie sollten eine Richtlinie für die Passwortrotation haben. Auch hier können einige der Datenbanksysteme dies für Sie durchsetzen. Administratoren können möglicherweise neue Benutzerkonten mit erzwungener Kennwortrotation erstellen. Er kann möglicherweise auch die Passwortrotation für einen bestimmten Benutzer erzwingen.
Prüfprotokolle
Einige der Datenbanksysteme bieten Prüfprotokolle an - die Idee ist, so viele Informationen wie möglich über die Aktivität in der Datenbank zu sammeln. Wer und wann hat was gemacht? Welche Abfrage wurde von wem ausgeführt? Wer hat versucht, sich anzumelden, ist aber gescheitert? Von welchem Host? Idealerweise würden Protokolle mit solchen Informationen außerhalb der Datenbankknoten gespeichert. Sie können sie zur sicheren Aufbewahrung, weiteren Verarbeitung und besseren Suchfunktionen auf Ihren zentralen Protokollserver streamen.
SQL-Sicherheit
Wir haben Benutzer und Hosts erwähnt, aber der Angriff kann auch aus einer anderen Quelle erfolgen. Wenn Ihre Anwendung nicht ordnungsgemäß gesichert ist und die Eingabe nicht korrekt validiert wird, sind Sie möglicherweise mit Angriffen konfrontiert, die von Ihrer Website ausgehen. Wir sprechen hier von SQL-Injection. In einem solchen Fall sind Firewalls nicht wirklich nützlich, da die Abfrage von einer gültigen Quelle stammt (Ihrem Webserver und dann dem Proxy-Knoten). Das Zuweisen von Berechtigungen kann tatsächlich dazu beitragen, einige dieser Angriffe zu verhindern, ist jedoch keine ideale Lösung - schließlich benötigt Ihre Anwendung in den meisten Fällen einen Benutzer, der den Inhalt der Datenbank entfernen oder ändern kann. Ein solcher Benutzer kann, wenn er ausgenutzt wird, dazu benutzt werden, Schaden anzurichten. Es gibt mehrere Möglichkeiten, wie Sie versuchen können, dem Leckerli entgegenzuwirken.
SQL-Firewall
Der einfachste Weg, dies zu tun, ist die Implementierung einer SQL-Firewall. Es kann auf verschiedenen Ebenen und an verschiedenen Orten durchgeführt werden. Eine der Optionen ist die Verwendung von Load Balancern dafür. Einige von ihnen sind mit dieser Funktionalität zumindest leicht erreichbar, wenn sie nicht bereits implementiert sind. Die Idee dahinter ist, eine Liste von Abfragen zu erstellen, die Ihre Anwendung ausführt, und dann Ihren Proxy so zu konfigurieren, dass er nur diese Art von Datenverkehr durchlässt. Es ist nicht ideal, da Sie es rechtzeitig pflegen, neue Abfragen hinzufügen und alte entfernen müssen, die nicht mehr verwendet werden. Andererseits verhindert ein solches Regelwerk, dass nicht autorisierte Abfragen die Datenbank erreichen.
SQL-Injection-Erkennung
Eine weitere mögliche Option wäre die Implementierung der SQL-Injection-Erkennung in der Proxy-Schicht. Es gibt einige Lösungen, darunter ProxySQL, die so konfiguriert werden können, dass sie versuchen, eine SQL-Einschleusung im Datenverkehr zu erkennen, der sie durchläuft. Natürlich basiert alles auf Heuristik, so dass es zu Fehlalarmen führen kann, aber es kann eine gute Ergänzung zur SQL-Firewall sein.
In der Vergangenheit haben wir besprochen, wie Sie eine SQL-Firewall und SQL-Injection-Erkennung mit ProxySQL implementieren können, einem Loadbalancer, der von ClusterControl bereitgestellt werden kann:
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-one
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-two
Datensicherheit
Zu guter Letzt die Datensicherheit. Wir haben bisher besprochen, wie man die Datenbank härten kann, wie man den Zugriff darauf beschränkt und wie man verschiedene Arten von Angriffen verhindert, die von der Anwendung selbst kommen. Wir sollten immer noch den Schutz der Daten selbst berücksichtigen. Diese kann mehrere Schichten haben. Physische Sicherheit – Wenn Ihnen das Rechenzentrum gehört, stellen Sie sicher, dass es ordnungsgemäß abgesperrt ist. Wenn Sie externe ISPs oder Cloud-Anbieter verwenden, stellen Sie sicher, dass diese über angemessene Sicherheitsprotokolle verfügen, wenn es um den Zugriff auf die Hardware geht. Dann haben wir einen Server, eine VM oder was auch immer Sie verwenden. Die Daten befinden sich auf der Festplatte und werden lokal auf dem Server gespeichert. Daten werden zwischen der Anwendung, dem Proxy und der Datenbank übertragen. Daten werden zwischen Datenbankknoten durch Replikation übertragen. Daten werden als Backups extern gespeichert. Diese Daten sollten geschützt werden.
Sicherungen
Backups sollten immer verschlüsselt werden. Der Verschlüsselungsschlüssel sollte sorgfältig gepflegt und regelmäßig ausgetauscht werden.
Daten unterwegs
Daten, die übertragen werden, sollten verschlüsselt werden. Stellen Sie sicher, dass Sie Ihre Anwendung, Proxy-Schicht und Datenbank für die Verwendung von SSL oder TSL konfiguriert haben. Alle Mittel zur Übertragung der Daten zwischen den Datenbankknoten sollten ebenfalls gesichert und verschlüsselt werden. Das Ziel ist es, jede Art von Netzwerk-Sniffing sinnlos zu machen.
Daten im Ruhezustand
Schließlich die Daten selbst, gespeichert auf dem Datenbankknoten. Es sollte auch verschlüsselt werden. Es gibt ein paar Methoden, die Sie verwenden können, wenn Sie sich diesem Thema nähern. Erstens die Verschlüsselung auf Hostebene. Das Volume, auf dem sich das Datenverzeichnis der Datenbank befindet, kann verschlüsselt (und beim Booten entschlüsselt) werden. Datenbanken sind in der Regel auch mit Verschlüsselungsfunktionen ausgestattet. Was verschlüsselt werden kann, hängt von der genauen Lösung und dem Typ und der Version der Datenbank ab, aber in einigen Fällen sind die Optionen recht umfangreich. Tablespace-Verschlüsselung, Log-Verschlüsselung, manchmal sogar Verschlüsselung der In-Memory-Strukturen. Wenn Sie es richtig machen, reicht der Zugriff auf den Datenbankknoten nicht aus, um auf die Daten zuzugreifen.
Fazit
Wie wir bereits erwähnt haben, ist dieser Blog nicht als praktischer Leitfaden zur Datenbanksicherheit gedacht, aber wir haben die meisten Aspekte angesprochen, die Sie bei der Architektur Ihrer Datenbankumgebung berücksichtigen sollten, und wir hoffen Sie werden diesen Leitfaden nützlich finden.
