Ihre Datenbank-server enthält oft sensibelste Daten, wie vertrauliche Informationen für den Benutzer. Es ist wichtig, um Sicherheit zu implementieren best practices, um das Risiko minimieren, dass ein Angreifer Zugriff auf die Datenbank.
Dieser Leitfaden wird für die MySQL-insbesondere, da es die gebräuchlichsten, aber die meisten dieser Konzepte für jede Art von Datenbank—Sie benötigen nur andere Konfiguration zur Erzielung der gleichen Effekte.
Stellen Sie Sicher, dass Sie mysql_secure_installation
MySQL hat eine built-in-tool kann mit ein paar grundlegende Sicherheits-Aufgaben. Nachdem Sie MySQL installieren, führen Sie den folgenden Befehl in Ihrem terminal aus:
mysql_secure_installation
Dieser führt Sie durch ein paar Aufgaben—die Erstellung eines neuen Passworts, das entfernen von anonymen Benutzer-und test-Datenbanken, und deaktivieren Sie die remote-root-login. Danach wird Sie neu laden MySQL-config-für Sie, so sollten Sie die änderungen sofort sehen.
Sperren SSH
Dies nicht technisch haben nichts mit der Datenbank selbst; aber Ihre Datenbank ist nur so sicher, wie der server auf dem es läuft, so dass Sie wollen, um die notwendigen Schritte zu sperren, SSH und verhindern, dass die meisten der häufigsten Angriffsmethoden.
Sie können Lesen Sie unsere ausführliche Anleitung auf SSH-Sicherheit, um mehr zu erfahren, aber das wesentliche ist in wenigen Schritten:
- Deaktivieren Sie die Passwort-Anmeldung, verwenden Sie SSH-Schlüssel nur.
- Limit login fehlgeschlagen-versuche mit denyhosts zu verhindern, dass brute-force.
- Whitelist der Zugriff auf Vertrauenswürdige IP-Adressen.
- Root-login über SSH—diese Weise, die Angreifer müssen wissen, dass Ihr Benutzername.
- Einrichten von Multi-Faktor-Authentifizierung für SSH-wenn Sie wirklich paranoid.
Führen Sie eine Eigenständige Datenbank in ein Eigenes Subnetz
Anstelle einer lokalen Datenbank auf dem gleichen server, nginx läuft, ist es besser für die Sicherheit, um führen Sie Ihre Datenbank in ein eigenes Subnetz, das nur zugänglich ist durch die anderen Server in Ihrer private cloud. Viele cloud-Anbieter, einschließlich AWS, bieten diese Funktionen.
Das setup sieht wie folgt aus:
Ihrer Virtual Private Cloud (VPC) ist einfach die container, die alle Ihre AWS-Ressourcen ausgeführt werden. Dinge, die in dieser cloud können miteinander sprechen, um über Ihre privaten IP-Adressen, wie Geräte in Ihrem Zuhause interagieren würden.
Server im öffentlichen Subnetz öffentlichen IP-Adressen, und werden direkt für jeden zugänglich. Server in der privaten Subnetz haben nicht öffentliche IP-Adressen—nur eine private. Sie können immer noch Zugriff auf das internet, obwohl, durch die Verwendung von Network Address Translation, die gleiche Methode, die Ihre computer-Zugang hinter einem Heim-router.
Dies bedeutet, dass alle Server gestartet, die in der privaten Subnetz wird völlig unzugänglich von außen Angreifer. Der einzige Weg, Ihre Datenbank zugegriffen werden konnte, wenn der Webserver kompromittiert wird, und selbst dann wäre es immer noch ein Privileg-Eskalation.
Auf der Oberseite der Sicherheit Vorteile, die diese Konfiguration ist auch viel einfacher zu skalieren. Zum Beispiel, Sie haben könnte, vier web-Server mit WordPress, die alle mit einem einzigen autoritativen Datenbank-server. Auf diese Weise, alle vier web-Servern synchronisiert werden, und Sie können leicht skalieren nach oben und unten um die Nachfrage zu decken, ohne sich Gedanken über die Datenbank. Dies kann dazu führen, dass einige performance-Probleme aufgrund der Netzwerk-overhead, aber mit der richtigen multilayer-caching, das problem ist minimal im Vergleich zu den architektonischen Vorzügen.
Um MySQL nur verbindungen akzeptieren, die von privaten verbindungen, die Sie verwenden möchten, eine Netzmaske in Ihrem GRANT-Anweisung. Das funktioniert nicht mit CIDR—Schreibweise-nur die Netzmaske.
GRANT ALL ON Datenbank.* TO ‘user’@’10.0.1.0/255.255.255.0’ identified BY ‘Passwort’
Wenn Sie nur einen server, sollten Sie zumindest binden Sie Ihre Datenbank auf localhost, so dass es nicht zugänglich ist aus dem offenen internet sowieso.
Bind auf Localhost, falls Möglich (oder Zumindest einen Anderen Port)
Wenn Sie nicht Zugriff auf Ihre Datenbank-server aus nichts anderen als andere Prozesse auf der Maschine selbst, sperren Sie es nach unten, so dass es ist nicht über Netzwerk erreichbar. Natürlich funktioniert dies nur, wenn Sie haben einen server mit alles, und das ist nicht die beste Konfiguration in den ersten Platz.
Wenn Sie sich nicht binden an localhost, ist es eine gute Idee, ändern Sie die Standard-port, um etwas anderes.
Entweder Weg, Sie können dies ganz einfach durch die Bindung von MySQL auf localhost, das heißt, es wird nur das lauschen auf die loopback-Adresse, und nicht über irgendwelche offenen ports. Öffnen Sie /etc/mysql/my.conf in Ihrem Lieblings-text-editor, und fügen Sie die folgende Zeile im [mysqld] – Abschnitt:
bind-address = 127.0.0.1
Sie können auch ändern Sie die Standard-port von diesem gleichen Abschnitt:
Port=5000
Neu starten, MySQL, und Sie sollten sehen, die änderungen.
Beobachten Sie Ihre Shell-Geschichte
Die meisten Dinge, die Sie tun in Linux angemeldet sind. Wenn es einem Angreifer gelingt Zugriff auf diese log-Dateien, Sie könnten eskalieren, Ihre Privilegien durch das Auffinden der Passwörter, die in Ihnen gespeichert.
Dies kann passieren im wesentlichen zwei Möglichkeiten für MySQL, beide sind leicht vermeidbar. Die erste ist, wenn Sie sich in die MySQL—shell, die Sie nie wollen, um das Kennwort angeben, die als argument auf der Befehlszeile. Immer lassen Sie es leer, und lassen Sie die MySQL-Abfragen.
mysql -u root -p
Ansonsten, es ist sichtbar mit Hilfe der history-Befehl.
MySQL hat auch eine eigene history-Datei, gespeichert unter ~/.mysql_history. Dies natürlich nicht anmelden, das Passwort für den login, aber wenn Sie einen neuen Benutzer aus der MySQL-Kommandozeile, diese Aussage wird protokolliert—Passwort und alle. Sie wollen deaktivieren Sie diese Datei als Vorsichtsmaßnahme, wenn Sie jemals ändern von Benutzerkonten.
# cat /dev/null > ~/.mysql_history
Wenn Sie auf der AWS-Plattform, Betrachten Mit RDS
AWS ist Relational Database Service (RDS)ist ein vollständig verwalteter Datenbank in der cloud. Wenn Sie wollen nicht sorgen zu machen über das Datenbank-Sicherheit, und wollen einfach nur eine implementierbare Lösung, RDS (und alle AWS anderen managed database services) wird entfernt die Kopfschmerzen.
RDS verwendet AWS die eigene Identität und Access Management (IAM) system. IAM verwaltet Berechtigungen für alles, was Sie auf der AWS-Plattform. Jede Aktion im web-basierten Management-Konsole, CLI-Befehle und API-Anforderungen müssen alle gehen durch IAM. Jede Aktion wird blockiert, wenn der Benutzer oder eine Entität der Ausführung nicht die ausdrückliche Erlaubnis zum Zugriff auf die angegebene Ressource. Auf top von, dass, RDS ist standardmäßig privat, so dass Sie nicht haben, um sorgen über Angriffe aus dem offenen internet.
Sie werden noch am Ende mit standard-MySQL-Authentifizierung mit Benutzername und Kennwort für die Verbindung zur Datenbank selbst—IAM-einfach sichert alles, was über die Datenbank, wie die Konfiguration. Allerdings können Sie mithilfe von AWS, die Geheimnisse der Manager, das Ihnen erlaubt, ständig drehen, Sicherheits-Schlüssel, ohne code Umschichtungen, und hat errichtet in der integration für RDS zu Booten.
Wenn Sie möchten, können Sie auch schalten Sie die IAM-Datenbank-Authentifizierung, die Ihnen erlauben, zu umgehen, Kennwort auth insgesamt und nur IAM nutzen. Allerdings, fügt es ein gewisser Aufwand, und als solche, ist die rate-begrenzt auf 200 neue verbindungen pro Sekunde für MySQL.