En av de viktigaste faktorerna och grunderna för datastyrning är säkerhet. Det är en god praxis att ha databassäkerhet implementerad närhelst du har din datahantering involverad för företags- eller masskonsumtion.
Datasäkerhet är en av de viktigaste aspekterna av att administrera en databas. Det spelar en avgörande roll som varje databashantering bör implementera. När det är implementerat och gjort på rätt sätt ska resultatet förbättra inte bara din datasäkerhet utan också påverka systemstabiliteten, förbättra utvecklingens livscykel, öka din dataefterlevnad och förbättra säkerhetsmedvetenheten ner till teamnivå. Alla vill inte att deras data hamnar i fel händer. Om data kränks riskerar det inte bara din datas konfidentialitet och integritet utan lämnar också din organisation öppen för betydande ekonomiska risker. Även för en enkel implementering av databashantering, om du upptäcker att någon redan har gjort intrång i ditt system, är känslan av att vara osäker och rädd för vilka konsekvenser som ska ge dig totalt obehaglig.
Att avgöra om din MySQL-serveranslutning är säker beror på hur säkert MySQL överför data under transport. Med en okrypterad anslutning mellan MySQL-klienten och servern kan någon med åtkomst till nätverket titta på all din trafik och inspektera data som skickas eller tas emot mellan klient och server.
När du måste flytta information över ett nätverk på ett säkert sätt är en okrypterad anslutning oacceptabel. Använd kryptering för att göra all slags data oläslig. Krypteringsalgoritmer måste innehålla säkerhetselement för att motstå många typer av kända attacker som att ändra ordningen på krypterade meddelanden eller spela upp data två gånger.
Men min MySQL är säker, eller hur?
Att tro att din MySQL är säker utan att bestämma dess stabilitet och sårbarhetskontroller är som en religion. Du tenderar att tro även utan att se det, även utan att röra det. Problemet är att MySQL är en teknologi och dess existens är inte baserad på abstrakta tankar. Det måste testas, det måste bevisas, och det kräver säkerhet och följer bästa praxis som också har testats av andra.
Att avgöra om dina MySQL-serveranslutningar, dvs under transport är säkra eller om den är krypterad, beror på "hur konfigurerade du din databas?" eller "vem har konfigurerat din databas?".
MySQL stöder krypterade anslutningar mellan klienter och servern med TLS-protokollet (Transport Layer Security). TLS kallas ibland för SSL (Secure Sockets Layer) men MySQL använder faktiskt inte SSL-protokollet för krypterade anslutningar eftersom dess kryptering är svag och SSL redan har fasats ut till förmån för TLS. TLS använder krypteringsalgoritmer för att säkerställa att data som tas emot via ett offentligt nätverk kan litas på. Den har mekanismer för att upptäcka dataändring, förlust eller uppspelning. TLS innehåller också algoritmer som ger identitetsverifiering med X.509-standarden. SSL eller TLS används omväxlande men för kryptering med MySQL används TLS där MySQL stöder krypterade anslutningar med protokollen TLSv1, TLSv1.1, TLSv1.2 och TLSv1.3.
X.509 gör det möjligt att identifiera någon på Internet. I grundläggande termer bör det finnas någon enhet som kallas "certifikatutfärdare" (eller CA) som tilldelar elektroniska certifikat till alla som behöver dem. Certifikat förlitar sig på asymmetriska krypteringsalgoritmer som har två krypteringsnycklar (en offentlig nyckel och en hemlig nyckel). En certifikatägare kan visa upp certifikatet för en annan part som bevis på identitet. Ett certifikat består av dess ägares publika nyckel. All data som krypteras med denna offentliga nyckel kan endast dekrypteras med motsvarande hemliga nyckel, som innehas av certifikatets ägare.
Precis som spartanerna använde Scytale
Scytale är känt för att användas som ett sätt att kryptera och dekryptera ett meddelande som användes runt 400 f.Kr. av spartanerna. De skulle skriva ett meddelande på ett ark papyrus (en typ av papper) som var virad runt en stav. Mottagaren kan bara tyda meddelandet om personalens diameter och storlek är korrekt. Det fungerar som ett sätt att kryptera och undvika obehörig extrahering av meddelanden eller data till måldestinationen.
Precis som med MySQL är användning av SSL/TLS-protokoll och chiffer ett sätt att undvika att någon extraherar din data eller kapar din data när den passerar tråden eller över internet.
Som standard försöker MySQL-program att ansluta med kryptering om servern stöder krypterade anslutningar, och faller tillbaka till en okrypterad anslutning om en krypterad anslutning inte kan upprättas. Eftersom version MySQL>=5.7 kan TLS/SSL- och RSA-filer skapas eller genereras med stöd av variabler. För MySQL-distributioner kompilerade med OpenSSL har MySQL-servern förmågan att automatiskt generera saknade SSL- och RSA-filer vid start. Auto_generate_certs, sha256_password_auto_generate_rsa_keys och caching_sha2_password_auto_generate_rsa_keys (version>=8.0), systemvariabler styr automatisk generering av dessa filer. Dessa variabler är aktiverade som standard. De kan aktiveras vid start och inspekteras men inte ställas in vid körning.
Som standard är dessa variabler inställda på PÅ eller aktiverade. Annars kan användare anropa mysql_ssl_rsa_setup-verktyget manuellt. För vissa distributionstyper, som RPM- och DEB-paket, sker mysql_ssl_rsa_setup-anrop under initiering av datakatalog. I det här fallet behöver MySQL-distributionen inte ha kompilerats med OpenSSL så länge som kommandot openssl är tillgängligt.
När dessa filer är tillgängliga och/eller genererade kommer MySQL fortfarande inte att använda krypteringsanslutningar av följande skäl. Som nämnts tidigare försöker MySQL-klientprogram som standard upprätta en krypterad anslutning om servern stöder krypterade anslutningar, med ytterligare kontroll tillgänglig via --ssl-läget (eller --ssl <=5.7.11 eftersom detta redan är föråldrat) alternativ:
-
Som standard, om MySQL-anslutning inte är flaggad med --ssl-mode, är standardvärdet satt till --ssl-mode=FÖREDRAG. Därför försöker klienter att ansluta med kryptering och faller tillbaka till en okrypterad anslutning om en krypterad anslutning inte kan upprättas.
-
Med --ssl-mode=REQUIRED kräver klienter en krypterad anslutning och misslyckas om en inte kan upprättas.
-
Med --ssl-mode=DISABLED använder klienter en okrypterad anslutning.
-
Med --ssl-mode=VERIFY_CA eller --ssl-mode=VERIFY_IDENTITY kräver klienter en krypterad anslutning och utför även verifiering mot serverns CA-certifikat och (med VERIFY_IDENTITY) mot serverns värdnamn i dess certifikat.
Med standardmekanismen för MySQL för att använda en föredragen anslutning, försöker den troligen att försöka använda den krypterade eller säkrade anslutningen, men detta lämnar fortfarande några saker att göra och att avgöra.
Som nämnts tidigare hjälper variablerna auto_generate_certs, sha256_password_auto_generate_rsa_keys och caching_sha2_password_auto_generate_rsa_keys (version>=8.0) till att generera de nödvändiga SSL/TLS- och RSA-filerna, med den normala användaren utan sådana krav under anslutningen. osäker. Låt oss till exempel skapa en användare som heter 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)Verifiera sedan om variablerna är korrekt inställda, vilket bör vara aktiverat som standard:
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)Verifiera om filerna genereras i enlighet med sökvägen /var/lib/mysql/ (eller sökvägen till datadir för denna MySQL):
$ 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.pemKontrollera sedan om SSL-filer är korrekt laddade:
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)Fastställ din anslutnings säkerhet
Nu ser det här bra ut. Det betyder också att MySQL är redo att acceptera krypterade anslutningar. Men att ansluta till MySQL som den är, som sagt ska den använda --ssl-mode=PREFFERED som standard, eller om --ssl-mode inte är specificerat kommer det fortfarande att misslyckas med att använda en okrypterad anslutning. Se nedan:
$ mysql [email protected] -h 192.168.40.110 -udbadmin -e "status;"|grep ssl -i
SSL: Används inte
Detta avslöjar att den inte använder en säker anslutning. Om du kontrollerar SSL-sessionens statusvariabler om några chiffer används visas tomma:
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)Tillämpa en säker anslutning
Eftersom det avslöjar att anslutningen fortfarande inte är säker, introducerar MySQL variabeln require_secure_transport som kräver att alla anslutningar som ska göras ska vara krypterade och säkrade. Alla försök att ansluta för en osäkrad anslutning misslyckas. Till exempel, aktivera det på servern:
mysql> set global require_secure_transport=1;
Query OK, 0 rows affected (0.00 sec)Att försöka ansluta som en klient med en okrypterad anslutning kommer att misslyckas:
$ mysql [email protected] -h 192.168.40.110 -udbadmin
ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON.För att ansluta framgångsrikt och säkert måste du ange variablerna ssl-ca, ssl-cert, ssl-key. Se nedan:
$ 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.3Alternativt, om en användare skapas med t.ex. REQUIRED SSL, bör det också ansluta dig med SSL oavsett om require_secure_transport är inaktiverat, vilket är dess standardvärde. Observera att, om require_secure_transport är aktiverat, kompletterar dess kapacitet SSL-kraven per konto, som har företräde. Därför, om ett konto är definierat med REQUIRE SSL, gör aktivering av require_secure_transport det inte möjligt att använda kontot för att ansluta med en Unix-socket-fil.
Se till att MySQL-serverdistributioner är krypterade och säkra
Besvärsfritt är det vi alltid ser fram emot så att det inte finns några andra problem och bekymmer att oroa sig för. ClusterControl distribuerar MySQL-databaser med krypterade anslutningar och genererar SSL- och RSA-certifikat åt dig. Till exempel en skärmdump nedan som visar jobbaktiviteten för ett Skapa kluster-kommando från ClusterControl.
Det ställer in SSL- och RSA-filerna och placerar dem i /etc/ mysql/certs/ sökväg precis som nedan:
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)Då grupperar ClusterControl också de genererade SSL- och RSA-filerna på ett centraliserat sätt under navigeringspanelen för nyckelhantering som visas nedan:
När det väl har distribuerats behöver du antingen skapa användare med KRÄVLIG SSL eller ha require_secure_transport om du vill genomdriva ett krypterat och säkert lager för dina MySQL-serveranslutningar.