Einer der größten Faktoren und Grundlagen der Datenverwaltung ist die Sicherheit. Es empfiehlt sich, Datenbanksicherheit zu implementieren, wenn Sie Ihre Datenverwaltung für Unternehmen oder den Massenverbrauch involvieren.
Datensicherheit ist einer der wichtigsten Aspekte bei der Verwaltung einer Datenbank. Es spielt eine entscheidende Rolle, für die jedes Datenbankmanagement implementiert werden sollte. Wenn es korrekt implementiert und durchgeführt wird, verbessert das Ergebnis nicht nur Ihre Datensicherheit, sondern wirkt sich auch auf die Systemstabilität aus, verbessert den Entwicklungslebenszyklus, verbessert Ihre Datenkonformität und verbessert das Sicherheitsbewusstsein bis hinunter auf Ihre Teamebene. Jeder möchte nicht, dass seine Daten in die falschen Hände geraten. Wenn Daten verletzt werden, gefährdet dies nicht nur die Vertraulichkeit und Integrität Ihrer Daten, sondern setzt Ihr Unternehmen auch erheblichen finanziellen Risiken aus. Wenn Sie herausfinden, dass jemand bereits in Ihr System eingedrungen ist, ist das Gefühl der Unsicherheit und Angst vor den Konsequenzen für Sie selbst bei einer einfachen Datenbankverwaltungsimplementierung völlig unangenehm.
Die Feststellung, ob Ihre MySQL-Serververbindung sicher ist, hängt davon ab, wie sicher MySQL die Daten während der Übertragung überträgt. Mit einer unverschlüsselten Verbindung zwischen dem MySQL-Client und dem Server könnte jemand mit Zugriff auf das Netzwerk Ihren gesamten Datenverkehr beobachten und die Daten überprüfen, die zwischen Client und Server gesendet oder empfangen werden.
Wenn Sie Informationen sicher über ein Netzwerk übertragen müssen, ist eine unverschlüsselte Verbindung nicht akzeptabel. Um jegliche Art von Daten unlesbar zu machen, verwenden Sie Verschlüsselung. Verschlüsselungsalgorithmen müssen Sicherheitselemente enthalten, um vielen Arten bekannter Angriffe zu widerstehen, z. B. das Ändern der Reihenfolge verschlüsselter Nachrichten oder das zweimalige Wiedergeben von Daten.
Aber mein MySQL ist sicher, oder?
Zu glauben, dass Ihr MySQL sicher ist, ohne seine Stabilität und Schwachstellenprüfungen zu bestimmen, ist wie eine Religion. Du neigst dazu zu glauben, auch ohne es zu sehen, sogar ohne es zu berühren. Das Problem ist, dass MySQL eine Technologie ist und ihre Existenz nicht auf abstrakten Gedanken basiert. Es muss getestet werden, es muss sich erweisen, und es erfordert Sicherheit und folgt bewährten Verfahren, die auch von anderen getestet wurden.
Die Feststellung, ob Ihre MySQL-Serververbindungen, d. h. während der Übertragung, sicher oder verschlüsselt sind, hängt von "Wie haben Sie Ihre Datenbank eingerichtet?" ab. oder "Wer hat Ihre Datenbank eingerichtet?".
MySQL unterstützt verschlüsselte Verbindungen zwischen Clients und dem Server unter Verwendung des TLS-Protokolls (Transport Layer Security). TLS wird manchmal als SSL (Secure Sockets Layer) bezeichnet, aber MySQL verwendet das SSL-Protokoll eigentlich nicht für verschlüsselte Verbindungen, da seine Verschlüsselung schwach ist und SSL bereits zugunsten von TLS verworfen wurde. TLS verwendet Verschlüsselungsalgorithmen, um sicherzustellen, dass Daten, die über ein öffentliches Netzwerk empfangen werden, vertrauenswürdig sind. Es verfügt über Mechanismen zur Erkennung von Datenänderungen, -verlusten oder -wiederholungen. TLS enthält auch Algorithmen, die eine Identitätsprüfung unter Verwendung des X.509-Standards ermöglichen. SSL oder TLS werden synonym verwendet, aber für den Kontext der Verschlüsselung mit MySQL wird TLS verwendet, für das MySQL verschlüsselte Verbindungen mit den Protokollen TLSv1, TLSv1.1, TLSv1.2 und TLSv1.3 unterstützt.
X.509 ermöglicht es, jemanden im Internet zu identifizieren. Grundsätzlich sollte es eine Stelle namens „Certificate Authority“ (oder CA) geben, die elektronische Zertifikate jedem zuweist, der sie benötigt. Zertifikate basieren auf asymmetrischen Verschlüsselungsalgorithmen mit zwei Verschlüsselungsschlüsseln (einem öffentlichen Schlüssel und einem geheimen Schlüssel). Ein Zertifikatsinhaber kann das Zertifikat einer anderen Partei als Identitätsnachweis vorlegen. Ein Zertifikat besteht aus dem öffentlichen Schlüssel seines Besitzers. Alle mit diesem öffentlichen Schlüssel verschlüsselten Daten können nur mit dem entsprechenden geheimen Schlüssel entschlüsselt werden, der im Besitz des Inhabers des Zertifikats ist.
Genauso wie die Spartaner Skytale benutzten
Scytale ist dafür bekannt, dass es als Methode zum Verschlüsseln und Entschlüsseln einer Nachricht verwendet wird, die um 400 v. Chr. verwendet wurde. von den Spartanern. Sie schrieben eine Nachricht auf ein Blatt Papyrus (eine Art Papier), das um einen Stab gewickelt war. Der Empfänger kann die Nachricht nur entziffern, wenn der richtige Durchmesser und die richtige Größe des Personals vorhanden sind. Es dient als Möglichkeit, Nachrichten oder Daten an das Zielziel zu verschlüsseln und unbefugtes Extrahieren zu verhindern.
Genau wie bei MySQL ist die Verwendung von SSL/TLS-Protokollen und Chiffren eine Möglichkeit, zu verhindern, dass jemand Ihre Daten extrahiert oder Ihre Daten entführt, während sie die Leitung oder das Internet passieren.
Standardmäßig versuchen MySQL-Programme, eine Verbindung mit Verschlüsselung herzustellen, wenn der Server verschlüsselte Verbindungen unterstützt, und greifen auf eine unverschlüsselte Verbindung zurück, wenn keine verschlüsselte Verbindung hergestellt werden kann. Seit Version MySQL>=5.7 können TLS/SSL- und RSA-Dateien mit Unterstützung von Variablen erstellt bzw. generiert werden. Für MySQL-Distributionen, die mit OpenSSL kompiliert wurden, hat der MySQL-Server die Fähigkeit, fehlende SSL- und RSA-Dateien beim Start automatisch zu generieren. Die Systemvariablen auto_generate_certs, sha256_password_auto_generate_rsa_keys und caching_sha2_password_auto_generate_rsa_keys (Version>=8.0) steuern die automatische Generierung dieser Dateien. Diese Variablen sind standardmäßig aktiviert. Sie können beim Start aktiviert und überprüft, aber nicht zur Laufzeit festgelegt werden.
Standardmäßig sind diese Variablen auf EIN oder aktiviert gesetzt. Andernfalls können Benutzer das Dienstprogramm mysql_ssl_rsa_setup manuell aufrufen. Bei einigen Distributionstypen, wie RPM- und DEB-Paketen, erfolgt der Aufruf von mysql_ssl_rsa_setup während der Initialisierung des Datenverzeichnisses. In diesem Fall muss die MySQL-Distribution nicht mit OpenSSL kompiliert worden sein, solange der openssl-Befehl verfügbar ist.
Sobald diese Dateien verfügbar und/oder generiert sind, verwendet MySQL aus den folgenden Gründen immer noch keine Verschlüsselungsverbindungen. Wie bereits erwähnt, versuchen MySQL-Clientprogramme standardmäßig, eine verschlüsselte Verbindung herzustellen, wenn der Server verschlüsselte Verbindungen unterstützt, wobei eine weitere Kontrolle durch den --ssl-mode (oder --ssl <=5.7.11, da dies bereits veraltet ist) verfügbar ist. Möglichkeit:
-
Wenn die MySQL-Verbindung nicht mit --ssl-mode gekennzeichnet ist, ist der Standardwert standardmäßig auf eingestellt --ssl-mode=BEVORZUGT. Daher versuchen Clients, eine Verbindung mit Verschlüsselung herzustellen, und greifen auf eine unverschlüsselte Verbindung zurück, wenn keine verschlüsselte Verbindung hergestellt werden kann.
-
Mit --ssl-mode=REQUIRED benötigen Clients eine verschlüsselte Verbindung und schlagen fehl, wenn keine hergestellt werden kann.
-
Mit --ssl-mode=DISABLED verwenden Clients eine unverschlüsselte Verbindung.
-
Mit --ssl-mode=VERIFY_CA oder --ssl-mode=VERIFY_IDENTITY benötigen Clients eine verschlüsselte Verbindung und führen Sie auch eine Überprüfung anhand des Server-CA-Zertifikats und (mit VERIFY_IDENTITY) anhand des Server-Hostnamens in seinem Zertifikat durch.
Mit dem Standardmechanismus von MySQL, eine bevorzugte Verbindung zu verwenden, versucht es wahrscheinlich, die verschlüsselte oder gesicherte Verbindung zu verwenden, aber das lässt noch einige Dinge zu tun und zu bestimmen.
Wie bereits erwähnt, helfen die Variablen auto_generate_certs, sha256_password_auto_generate_rsa_keys und caching_sha2_password_auto_generate_rsa_keys (Version>=8.0) beim Generieren der erforderlichen SSL/TLS- und RSA-Dateien, wobei der normale Benutzer ohne solche Anforderungen während der Verbindung weiterhin bestehen muss unsicher. Erstellen wir beispielsweise einen Benutzer namens dbadmin.
mysql> create user 'dbadmin'@'192.168.40.%' identified by '[email protected]';
Query OK, 0 rows affected (0.01 sec)
mysql> GRANT ALL PRIVILEGES ON *.* TO 'dbadmin'@'192.168.40.%';
Query OK, 0 rows affected (0.01 sec)Überprüfen Sie dann, ob die Variablen korrekt gesetzt sind, die standardmäßig aktiviert sein sollten:
mysql> show global variables where variable_name in ('auto_generate_certs','sha256_password_auto_generate_rsa_keys','caching_sha2_password_auto_generate_rsa_keys');
+----------------------------------------------+-------+
| Variable_name | Value |
+----------------------------------------------+-------+
| auto_generate_certs | ON |
| caching_sha2_password_auto_generate_rsa_keys | ON |
| sha256_password_auto_generate_rsa_keys | ON |
+----------------------------------------------+-------+
3 rows in set (0.00 sec)Überprüfen, ob die Dateien entsprechend im Pfad /var/lib/mysql/ (oder dem Pfad von datadir für dieses MySQL) generiert werden:
$ find /var/lib/mysql -name "*.pem"
/var/lib/mysql/ca-key.pem
/var/lib/mysql/ca.pem
/var/lib/mysql/server-key.pem
/var/lib/mysql/server-cert.pem
/var/lib/mysql/client-key.pem
/var/lib/mysql/client-cert.pem
/var/lib/mysql/private_key.pem
/var/lib/mysql/public_key.pemÜberprüfen Sie dann, ob SSL-Dateien korrekt geladen werden:
mysql> show global variables like 'ssl%';
+---------------+-----------------+
| Variable_name | Value |
+---------------+-----------------+
| ssl_ca | ca.pem |
| ssl_capath | |
| ssl_cert | server-cert.pem |
| ssl_cipher | |
| ssl_crl | |
| ssl_crlpath | |
| ssl_fips_mode | OFF |
| ssl_key | server-key.pem |
+---------------+-----------------+
8 rows in set (0.00 sec)Bestimmen Sie die Sicherheit Ihrer Verbindung
Nun, das sieht gut aus. Es bedeutet auch, dass MySQL bereit ist, verschlüsselte Verbindungen zu akzeptieren. Aber die Verbindung mit MySQL wie angegeben soll standardmäßig --ssl-mode=PREFFERED verwenden, oder wenn --ssl-mode nicht angegeben ist, wird immer noch eine unverschlüsselte Verbindung verwendet. Siehe unten:
$ mysql [email protected] -h 192.168.40.110 -udbadmin -e "status;"|grep ssl -i
SSL: Nicht verwendet
Dies zeigt, dass es keine gesicherte Verbindung verwendet. Die Überprüfung der SSL-Sitzungsstatusvariablen, wenn Verschlüsselungen verwendet werden, ergibt leer:
mysql> show global status like 'ssl%';
+--------------------------------+--------------------------+
| Variable_name | Value |
+--------------------------------+--------------------------+
| Ssl_accept_renegotiates | 0 |
| Ssl_accepts | 2 |
| Ssl_callback_cache_hits | 0 |
| Ssl_cipher | |
| Ssl_cipher_list | |
| Ssl_client_connects | 0 |
| Ssl_connect_renegotiates | 0 |
| Ssl_ctx_verify_depth | 18446744073709551615 |
| Ssl_ctx_verify_mode | 5 |
| Ssl_default_timeout | 0 |
| Ssl_finished_accepts | 2 |
| Ssl_finished_connects | 0 |
| Ssl_server_not_after | Aug 28 12:48:46 2031 GMT |
| Ssl_server_not_before | Aug 30 12:48:46 2021 GMT |
| Ssl_session_cache_hits | 0 |
| Ssl_session_cache_misses | 0 |
| Ssl_session_cache_mode | SERVER |
| Ssl_session_cache_overflows | 0 |
| Ssl_session_cache_size | 128 |
| Ssl_session_cache_timeouts | 0 |
| Ssl_sessions_reused | 0 |
| Ssl_used_session_cache_entries | 0 |
| Ssl_verify_depth | 0 |
| Ssl_verify_mode | 0 |
| Ssl_version | |
+--------------------------------+--------------------------+
25 rows in set (0.002 sec)Erzwingen einer gesicherten Verbindung
Da es zeigt, dass die Verbindung immer noch nicht gesichert ist, führt MySQL die Variable require_secure_transport ein, die verlangt, dass alle herzustellenden Verbindungen verschlüsselt und gesichert sind. Alle Versuche, eine ungesicherte Verbindung herzustellen, schlagen fehl. Aktivieren Sie es beispielsweise auf dem Server:
mysql> set global require_secure_transport=1;
Query OK, 0 rows affected (0.00 sec)Der Versuch, sich als Client über eine unverschlüsselte Verbindung zu verbinden, schlägt fehl:
$ mysql [email protected] -h 192.168.40.110 -udbadmin
ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON.Um erfolgreich und sicher eine Verbindung herzustellen, müssen Sie die Variablen ssl-ca, ssl-cert, ssl-key angeben. Siehe unten:
$ mysql [email protected] -h 192.168.40.110 -udbadmin --ssl-ca=/tmp/pem/ca.pem --ssl-cert=/tmp/pem/server-cert.pem --ssl-key=/tmp/pem/server-key.pem -e "show global status like 'ssl%'\G"
*************************** 1. row ***************************
Variable_name: Ssl_accept_renegotiates
Value: 0
*************************** 2. row ***************************
Variable_name: Ssl_accepts
Value: 16
*************************** 3. row ***************************
Variable_name: Ssl_callback_cache_hits
Value: 0
*************************** 4. row ***************************
Variable_name: Ssl_cipher
Value: TLS_AES_256_GCM_SHA384
*************************** 5. row ***************************
Variable_name: Ssl_cipher_list
Value: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES256-SHA:CAMELLIA256-SHA:CAMELLIA128-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA
*************************** 6. row ***************************
Variable_name: Ssl_client_connects
Value: 0
*************************** 7. row ***************************
Variable_name: Ssl_connect_renegotiates
Value: 0
*************************** 8. row ***************************
Variable_name: Ssl_ctx_verify_depth
Value: 18446744073709551615
*************************** 9. row ***************************
Variable_name: Ssl_ctx_verify_mode
Value: 5
*************************** 10. row ***************************
Variable_name: Ssl_default_timeout
Value: 7200
*************************** 11. row ***************************
Variable_name: Ssl_finished_accepts
Value: 11
*************************** 12. row ***************************
Variable_name: Ssl_finished_connects
Value: 0
*************************** 13. row ***************************
Variable_name: Ssl_server_not_after
Value: Aug 28 12:48:46 2031 GMT
*************************** 14. row ***************************
Variable_name: Ssl_server_not_before
Value: Aug 30 12:48:46 2021 GMT
*************************** 15. row ***************************
Variable_name: Ssl_session_cache_hits
Value: 0
*************************** 16. row ***************************
Variable_name: Ssl_session_cache_misses
Value: 0
*************************** 17. row ***************************
Variable_name: Ssl_session_cache_mode
Value: SERVER
*************************** 18. row ***************************
Variable_name: Ssl_session_cache_overflows
Value: 0
*************************** 19. row ***************************
Variable_name: Ssl_session_cache_size
Value: 128
*************************** 20. row ***************************
Variable_name: Ssl_session_cache_timeouts
Value: 0
*************************** 21. row ***************************
Variable_name: Ssl_sessions_reused
Value: 0
*************************** 22. row ***************************
Variable_name: Ssl_used_session_cache_entries
Value: 0
*************************** 23. row ***************************
Variable_name: Ssl_verify_depth
Value: 18446744073709551615
*************************** 24. row ***************************
Variable_name: Ssl_verify_mode
Value: 5
*************************** 25. row ***************************
Variable_name: Ssl_version
Value: TLSv1.3Alternativ, wenn ein Benutzer beispielsweise mit REQUIRED SSL erstellt wird, sollte dieser Sie auch über SSL verbinden, unabhängig davon, dass require_secure_transport deaktiviert ist, was der Standardwert ist. Beachten Sie, dass, wenn require_secure_transport aktiviert ist, seine Funktion die SSL-Anforderungen pro Konto ergänzt, die Vorrang haben. Wenn daher ein Konto mit REQUIRE SSL definiert ist, ermöglicht die Aktivierung von require_secure_transport nicht, das Konto zu verwenden, um eine Verbindung über eine Unix-Socket-Datei herzustellen.
Sicherstellen, dass MySQL-Server-Bereitstellungen verschlüsselt und sicher sind
Sorglos ist das, worauf wir uns immer freuen, damit es keine anderen Probleme und Bedenken gibt, über die wir uns Sorgen machen müssen. ClusterControl stellt MySQL-Datenbanken über verschlüsselte Verbindungen bereit und generiert die SSL- und RSA-Zertifikate für Sie. Ein Screenshot unten zeigt Ihnen beispielsweise die Auftragsaktivität eines Create Cluster-Befehls von ClusterControl.
Es richtet die SSL- und RSA-Dateien ein und platziert sie in /etc/ mysql/certs/ Pfad wie unten:
mysql> show global variables like 'ssl%';
+---------------+--------------------------------+
| Variable_name | Value |
+---------------+--------------------------------+
| ssl_ca | /etc/mysql/certs/server_ca.crt |
| ssl_capath | |
| ssl_cert | /etc/mysql/certs/server.crt |
| ssl_cipher | |
| ssl_crl | |
| ssl_crlpath | |
| ssl_key | /etc/mysql/certs/server.key |
+---------------+--------------------------------+
7 rows in set (0.00 sec)Dann gruppiert ClusterControl auch die generierten SSL- und RSA-Dateien zentralisiert unter dem Navigationsbereich der Schlüsselverwaltung, wie unten gezeigt:
Nach der Bereitstellung müssen Sie nur noch Benutzer mit ERFORDERLICHEM SSL erstellen oder require_secure_transport haben, wenn Sie eine verschlüsselte und gesicherte Ebene für Ihre MySQL-Serververbindungen erzwingen möchten.
