En af de største faktorer og grundlæggende elementer i datastyring er sikkerhed. Det er en god praksis at have databasesikkerhed implementeret, når du har din datastyring involveret til virksomheds- eller masseforbrug.
Datasikkerhed er et af de vigtigste aspekter ved administration af en database. Det spiller en afgørende rolle, som enhver databasestyring bør implementere. Når det er implementeret og udført korrekt, vil resultatet ikke kun forbedre din datasikkerhed, men også påvirke systemstabiliteten, forbedre udviklingens livscyklus, øge din dataoverholdelse og øge sikkerhedsbevidstheden ned til dit teamniveau. Alle ønsker ikke, at deres data havner i de forkerte hænder. Hvis data krænkes, risikerer det ikke kun dine datas fortrolighed og integritet, men lader også din organisation være åben over for betydelige økonomiske risici. Selv for blot en simpel databasestyringsimplementering, hvis du finder ud af, at nogen allerede har trængt ind i dit system, er følelsen af at være usikker og bange for, hvilke konsekvenser det vil give dig, totalt ubehageligt.
At bestemme, om din MySQL-serverforbindelse er sikker, afhænger af, hvor sikkert MySQL transmitterer data under transport. Med en ukrypteret forbindelse mellem MySQL-klienten og serveren kunne en person med adgang til netværket se al din trafik og inspicere de data, der sendes eller modtages mellem klient og server.
Når du skal flytte information over et netværk på en sikker måde, er en ukrypteret forbindelse uacceptabel. Brug kryptering for at gøre enhver form for data ulæselig. Krypteringsalgoritmer skal omfatte sikkerhedselementer for at modstå mange slags kendte angreb, såsom ændring af rækkefølgen af krypterede meddelelser eller genafspilning af data to gange.
Men min MySQL er sikker, ikke?
At tro på, at din MySQL er sikker uden at bestemme dens stabilitet og sårbarhedstjek, er som en religion. Du har en tendens til at tro selv uden at se det, selv uden at røre det. Problemet er, at MySQL er en teknologi, og dens eksistens er ikke baseret på abstrakte tanker. Det skal testes, det skal bevises, og det kræver sikkerhed og følger bedste praksis, som også er blevet testet af andre.
At bestemme, om dine MySQL-serverforbindelser, dvs. under transport er sikre, eller om den er krypteret, afhænger af "hvordan konfigurerede du din database?" eller "hvem har opsat din database?".
MySQL understøtter krypterede forbindelser mellem klienter og serveren ved hjælp af TLS (Transport Layer Security) protokollen. TLS omtales nogle gange som SSL (Secure Sockets Layer), men MySQL bruger faktisk ikke SSL-protokollen til krypterede forbindelser, fordi dens kryptering er svag, og SSL allerede er blevet forældet til fordel for TLS. TLS bruger krypteringsalgoritmer til at sikre, at data modtaget over et offentligt netværk kan stole på. Det har mekanismer til at registrere dataændring, tab eller genafspilning. TLS inkorporerer også algoritmer, der giver identitetsbekræftelse ved hjælp af X.509-standarden. SSL eller TLS bruges i flæng, men i forbindelse med kryptering med MySQL bruges TLS, hvor MySQL understøtter krypterede forbindelser ved hjælp af TLSv1-, TLSv1.1-, TLSv1.2- og TLSv1.3-protokollerne.
X.509 gør det muligt at identificere nogen på internettet. Grundlæggende bør der være en enhed kaldet en "Certificate Authority" (eller CA), der tildeler elektroniske certifikater til alle, der har brug for dem. Certifikater er afhængige af asymmetriske krypteringsalgoritmer, der har to krypteringsnøgler (en offentlig nøgle og en hemmelig nøgle). En certifikatejer kan fremvise certifikatet for en anden part som bevis for identitet. Et certifikat består af dets ejers offentlige nøgle. Alle data, der er krypteret med denne offentlige nøgle, kan kun dekrypteres ved hjælp af den tilsvarende hemmelige nøgle, som indehaves af ejeren af certifikatet.
Ligesom spartanerne brugte Scytale
Scytale er kendt for at blive brugt som en måde at kryptere og dekryptere en besked, som blev brugt omkring 400 f.Kr. af spartanerne. De ville skrive en besked på et ark papyrus (en type papir), der var viklet rundt om en stav. Modtageren kan kun tyde beskeden, hvis den korrekte diameter og størrelse på personalet. Det tjener som en måde at kryptere og undgå uautoriseret udtrækning af meddelelser eller data til måldestinationen.
Ligesom med MySQL er brug af SSL/TLS-protokoller og ciphers en måde at undgå, at nogen trækker dine data ud eller kaprer dine data, når de passerer ledningen eller over internettet.
Som standard forsøger MySQL-programmer at oprette forbindelse ved hjælp af kryptering, hvis serveren understøtter krypterede forbindelser, og falder tilbage til en ukrypteret forbindelse, hvis en krypteret forbindelse ikke kan etableres. Siden version MySQL>=5.7, kan TLS/SSL- og RSA-filer oprettes eller genereres med understøttelse af variabler. For MySQL-distributioner kompileret ved hjælp af OpenSSL, har MySQL-serveren mulighed for automatisk at generere manglende SSL- og RSA-filer ved opstart. Systemvariablerne auto_generate_certs, sha256_password_auto_generate_rsa_keys og caching_sha2_password_auto_generate_rsa_keys (version>=8.0), styrer automatisk generering af disse filer. Disse variabler er aktiveret som standard. De kan aktiveres ved opstart og inspiceres, men ikke indstilles ved kørsel.
Som standard er disse variabler sat til TIL eller aktiveret. Ellers kan brugere aktivere mysql_ssl_rsa_setup-værktøjet manuelt. For nogle distributionstyper, såsom RPM- og DEB-pakker, forekommer mysql_ssl_rsa_setup-indkaldelse under initialisering af databibliotek. I dette tilfælde behøver MySQL-distributionen ikke at være blevet kompileret ved hjælp af OpenSSL, så længe openssl-kommandoen er tilgængelig.
Når disse filer er tilgængelige og/eller genereret, vil MySQL stadig ikke bruge krypteringsforbindelser af følgende årsager. Som tidligere nævnt forsøger MySQL-klientprogrammer som standard at etablere en krypteret forbindelse, hvis serveren understøtter krypterede forbindelser, med yderligere kontrol tilgængelig via --ssl-tilstanden (eller --ssl <=5.7.11, da dette allerede er forældet) mulighed:
-
Som standard, hvis MySQL-forbindelse ikke er markeret med --ssl-mode, er standardværdien sat til --ssl-mode=Foretrukken. Derfor forsøger klienter at oprette forbindelse ved hjælp af kryptering og falder tilbage til en ukrypteret forbindelse, hvis en krypteret forbindelse ikke kan etableres.
-
Med --ssl-mode=KRÆVET kræver klienter en krypteret forbindelse og fejler, hvis en ikke kan etableres.
-
Med --ssl-mode=DEAKTIVERET bruger klienter en ukrypteret forbindelse.
-
Med --ssl-mode=VERIFY_CA eller --ssl-mode=VERIFY_IDENTITY kræver klienter en krypteret forbindelse og også udføre verifikation mod serverens CA-certifikat og (med VERIFY_IDENTITY) mod serverens værtsnavn i dets certifikat.
Med MySQL's standardmekanisme til at bruge en foretrukken forbindelse, forsøger den sandsynligvis at forsøge at bruge den krypterede eller sikrede forbindelse, men dette efterlader stadig nogle ting at gøre og bestemme.
Som tidligere nævnt hjælper variablerne auto_generate_certs, sha256_password_auto_generate_rsa_keys og caching_sha2_password_auto_generate_rsa_keys (version>=8.0) med at generere de nødvendige SSL/TLS- og RSA-filer, med den normale bruger uden sådanne krav under forbindelsen stadig usikker. Lad os for eksempel oprette en bruger kaldet 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)Bekræft derefter, om variablerne er indstillet korrekt, hvilket skal være aktiveret, som de er 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)Bekræftelse af, om filerne er genereret i overensstemmelse hermed i stien /var/lib/mysql/ (eller stien til datadir for denne 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.pemBekræft derefter, om SSL-filer er indlæst korrekt:
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)Bestem din forbindelses sikkerhed
Nu ser det godt ud. Det betyder også, at MySQL er klar til at acceptere krypterede forbindelser. Men at oprette forbindelse til MySQL, som den er, skal den som angivet bruge --ssl-mode=PREFFERED som standard, eller hvis --ssl-mode ikke er angivet, vil den stadig mislykkes med at bruge en ukrypteret forbindelse. Se nedenfor:
$ mysql [email protected] -h 192.168.40.110 -udbadmin -e "status;"|grep ssl -i
SSL: Ikke i brug
Dette afslører, at den ikke bruger en sikker forbindelse. Hvis du tjekker SSL-sessionens statusvariabler, hvis der bruges cifre, afsløres tom:
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)Håndhævelse af en sikker forbindelse
Da det afslører, at forbindelsen stadig ikke er sikret, introducerer MySQL variablen require_secure_transport, som kræver, at alle forbindelser, der skal oprettes, skal være krypteret og sikret. Ethvert forsøg på at oprette forbindelse til en usikret forbindelse mislykkes. For eksempel at aktivere det på serveren:
mysql> set global require_secure_transport=1;
Query OK, 0 rows affected (0.00 sec)Forsøg på at oprette forbindelse som en klient ved hjælp af en ukrypteret forbindelse vil mislykkes:
$ mysql [email protected] -h 192.168.40.110 -udbadmin
ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON.For at oprette forbindelse med succes og sikkert, skal du angive ssl-ca, ssl-cert, ssl-key-variablerne. Se nedenfor:
$ 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, hvis en bruger er oprettet med for eksempel PÅKRÆVET SSL, skulle det også forbinde dig med SSL, uanset at require_secure_transport er deaktiveret, hvilket er standardværdien. Vær opmærksom på, at hvis require_secure_transport er aktiveret, supplerer dens kapacitet SSL-kravene pr. konto, som har forrang. Derfor, hvis en konto er defineret med REQUIRE SSL, gør aktivering af require_secure_transport det ikke muligt at bruge kontoen til at oprette forbindelse ved hjælp af en Unix-socket-fil.
Sørg for, at MySQL-serverinstallationer er krypteret og sikre
Besværet er det, vi altid ser frem til, så der ikke er andre problemer og bekymringer at bekymre sig om. ClusterControl implementerer MySQL-databaser ved hjælp af krypterede forbindelser og genererer SSL- og RSA-certifikaterne for dig. For eksempel et skærmbillede nedenfor, der viser dig jobaktiviteten for en Create Cluster-kommando fra ClusterControl.
Den sætter SSL- og RSA-filerne op og placerer dem i /etc/ mysql/certs/-sti ligesom nedenfor:
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)Så grupperer ClusterControl også de genererede SSL- og RSA-filer på en centraliseret måde under navigationspanelet Key Management som vist nedenfor:
Når den er installeret, skal du blot oprette brugere med PÅKRÆVET SSL eller have require_secure_transport, hvis du vil gennemtvinge et krypteret og sikret lag til dine MySQL-serverforbindelser.