MySQL-Übersicht härten

Da gibt es nichts zu beschönigen: Es gibt Angreifer, die in wenigen Minuten das gesamte Internet scannen und Passwörter innerhalb von Sekunden knacken können. Es ist zwar manchmal erforderlich, eine Datenbank über ein öffentliches IP-Netzwerk zugänglich zu machen, aber dies macht Ihre Datenbank exponentiell anfälliger. Eine Möglichkeit, die Risiken öffentlicher IP-Adressen zu minimieren, besteht darin, den Datenbankzugriff auf eine begrenzte Anzahl von IP-Adressen zu beschränken.

Die bessere Lösung besteht darin, nur den Zugriff innerhalb einer Virtual Private Cloud (VPC) und nur Operatorverbindungen innerhalb eines Bastion Hosts zuzulassen. In Google Cloud wird diese Lösung als private IP-Adresse bezeichnet. Wenn auf Ihre MySQL-Instanz nur innerhalb einer VPC zugegriffen werden kann, muss ein Angreifer zuerst die VPC durchbrechen, bevor er versuchen kann, die Instanz zu durchbrechen.

Für jede Nebenversion von MySQL gibt es Versionshinweise und sie enthalten fast immer einen Abschnitt zu Sicherheitsupdates. Wenn Ihre Instanz mehrere Versionen veraltet ist, gibt es mehrere Versionen von Sicherheitsfixes, die Ihre Datenbank nicht hat.

Neben der Behebung von Sicherheitsproblemen im Laufe der Zeit bietet MySQL auch regelmäßig neue, völlig neue Sicherheitsfeatures. MySQL 8.0 bietet zum Beispiel viele Möglichkeiten, MySQL-Schemas und Nutzer zu härten, z. B. Rollen, fehlgeschlagenes Anmelde-Tracking und zufällige Passwörter.

Angenommen, Sie arbeiten in einem Café und möchten einige Abfragen ausführen, damit Sie über das kostenlose WLAN des Geschäfts eine Verbindung zu MySQL herstellen. Wenn Sie TLS (Transport Layer Security) nicht verwendet haben, wird Ihr Nutzername und Passwort über TCP (The Transmission Control Protocol, eines der Hauptprotokolle des Internets) gesendet. Erzwingen Sie TLS auf Ihrer MySQL-Instanz und arbeiten Sie mit Ihrem Latte-Laut, ohne sich Sorgen machen zu müssen, ob andere Kunden im Netzwerk ausspionieren.

SQL-Injection

Oft ist nicht die Datenbank, sondern die Anwendung am anfälligsten für Angriffe. Viele Anwendungen sind Opfer von SQL-Einschleusungsangriffen, bei denen ein Angreifer schädliche Eingaben einfügt, die als gültige SQL-Anweisung betrachtet werden. Der beste Schutz gegen diese Angriffe besteht darin, beim Erstellen von SQL-Anweisungen vorbereitete Anweisungen zu verwenden, statt Nutzereingaben mit SQL-Anweisungen zu verketten.

Secrets in Ihrem Repository

Unzählige Datenbanken wurden gehackt, weil ein Entwickler versehentlich seinen Nutzernamen und sein Passwort in das Quellcode-Repository übertragen hat. Verwenden Sie stattdessen ein Tool wie Secret Manager von Google Cloud, das alle Arten von Secrets verwaltet, einschließlich Ihres Datenbankpassworts.

Passwörter protokollieren

Mit den Filtertools Ihres Logging-Frameworks können Sie das Passwort Ihrer Datenbank aus Ihren Anwendungslogs herausfiltern. Beispiele hierfür sind Log4j-Filter oder Rails-ParameterFilter. Für die meisten Logging-Frameworks sollte jedoch ein Äquivalent vorhanden sein. Ist dies nicht der Fall, müssen Sie darauf achten, dass Ihre Anwendungslogs sicher sind, damit Ihre Datenbank sicher ist.

Erwägen Sie eine Passwortvalidierung, um dafür zu sorgen, dass alle Passwörter in Ihrer Datenbank ausreichend komplex sind. Für Anwendungspasswörter sollten sie lang und komplex sein und häufig rotiert werden. Secret-Manager sind besonders nützlich, damit Sie sich keine komplexen und häufig wechselnden Passwörter merken müssen. 

Wenn ein Mensch (und keine Anwendung) einen Datenbanknutzer verwendet, halten Sie sich an die NIST-Standards und priorisieren Sie die Länge vor allen anderen. Ablaufdaten von Passwörtern und übermäßig komplexe Passwortanforderungen veranlassen häufig dazu, dass Nutzer ihren Arbeitsspeicher an Klartextdateien und Notizen senden, was den Zweck dieser Regeln untergräbt. 

Noch besser ist die Nutzung der IAM-Authentifizierung für Nicht-Anwendungsnutzer. Die IAM-Authentifizierung delegiert die Verbindungsherstellung an das IAM-Angebot von Google Cloud. Dies bedeutet, dass das Risiko nur auf den IAM-Nutzer und nicht auf den IAM-Nutzer und den Datenbanknutzer minimiert wird.

Schließlich wird der Datenbank-Passwort von MySQL standardmäßig als Hash festgelegt. Das bedeutet, dass Nutzer mit demselben Passwort identische Authentifizierungsstrings haben. Dadurch werden schwache Passwörter mit einem Regenbogentabellenangriff einfach geknackt. Die beiden MySQL-Nutzer haben denselben authentication_string (Authentifizierungsstring).

Sie sollten das Flag „default_authentication_plugin“ auf „Caching_sha2_password“ setzen. Dadurch wird sichergestellt, dass zwei Nutzer mit demselben Passwort einen anderen Hash haben. Die beiden Nutzer haben im folgenden Beispiel unterschiedliche Authentication_string-Werte.

Eine Zugriffsbeschränkung bedeutet nicht nur, sich den Zugriff von außen zu sichern. Es bedeutet auch eine regelmäßige Prüfung des Zugriffs von innen.

Anwendung prüfen: Wenn nur aus den Rechnungs-, Produkt- und Kundentabellen gelesen wird, ist ein Zugriff auf alles andere wirklich nötig? Wenn Sie den Root-Zugriff auf Ihre Datenbank zulassen, kann ein Angreifer enorme Schäden an Ihrer Datenbank verursachen. Denken Sie stattdessen an jede Anforderung Ihrer Instanz, notieren Sie die erforderlichen Berechtigungen und erstellen Sie dann für jede Instanz einen Datenbanknutzer. Wenn ein Angreifer Ihre Datenbank unter einem dieser Datenbanknutzer verletzt, schränken Sie den Schadensumfang ein.

Nutzer prüfen: Wie viele Nutzer Ihrer Datenbank benötigen Administratorberechtigungen für Ihre Instanzen? Wie viele dieser Nutzer befinden sich noch in Ihrer Organisation, sind inaktiven Projekten zugeordnet oder selbst inaktiv? Zugriffstokens können zu Datenlecks führen. Die Insiderbedrohung ist für die meisten Systeme ein Dauerbrenner. Wenn Sie so wenig Nutzer wie möglich haben, kann Ihre Instanz vor dieser Art von Problemen schützen.

Administrator überprüfen: Sie sollten Nutzer wie „Root“ oder „Admin“ entfernen oder umbenennen. Dies sind einfache Ziele für Angreifer. Wenn sie nicht existieren, ist es in Ihrem System noch schwieriger, sie zu hacken. Dies wird als Sicherheit durch Verdunkelung bezeichnet. Dies sollte nicht die erste Verteidigungslinie sein, bietet aber auch eine dünne Sicherheitsebene für Ihre MySQL-Datenbank.

Regelmäßige Datensicherungen und überprüfbare Datenwiederherstellungspläne sind für eine fehlerfreie Datenbankverwaltung von entscheidender Bedeutung. Aber auch bei regulären Sicherungen können Sie alle Daten verlieren, die nach der letzten Sicherung geschrieben wurden. Einer der Vorteile der MySQL-Umgebung ist die Wiederherstellung zu einem bestimmten Zeitpunkt (PITR). Aktivieren Sie binäre Logs in Ihren Cloud SQL for MySQL-Instanzen, um PITR zu ermöglichen.

Wenn Sie alle oben genannten Schritte ausgeführt haben, sind Sie gut vorbereitet und bestens geschützt. Ohne Sicherheitsmaßnahmen wäre ein kontinuierliches Sicherheitsdesign nicht erforderlich – die Datenbankprüfung. Mit dem Cloud SQL for MySQL-Audit-Plug-in können Sie ungewöhnliches Verhalten im Falle einer Sicherheitslücke verfolgen.

Wenn Sie die obigen Schritte ausführen, ist es für einen Angreifer wesentlich schwieriger, einen Datenbankverstoß zu erleiden. Ein Angreifer müsste in Ihre Anwendung eindringen und hoffen, dass der Datenbanknutzer der Anwendung genügend Privilegien für seinen Angriff hat. Oder er müsste in Ihre VPC eindringen, einen bestehenden Benutzernamen finden, das Passwort knacken und hoffen, dass dieser Nutzer genügend Privilegien hat, um seinen Angriff durchzuführen. Währenddessen können Sie sich MySQL-Datenbanklogs oder Audit-Logs ansehen, um das normale Verhalten der Datenbank zu überwachen und entsprechend zu reagieren.

Das bedeutet Sicherheit von Grund auf. Angreifer werden immer wieder versuchen, Maschinen auszunutzen. Daher ist es wichtig, Ihr System mit so vielen Sicherheitsebenen wie möglich zu entwerfen, um Ihre Datenbank zu schützen.