Jedním z největších faktorů a základů správy dat je zabezpečení. Je dobrým zvykem mít zavedené zabezpečení databáze vždy, když se vaše správa dat týká podnikové nebo hromadné spotřeby.
Zabezpečení dat je jedním z nejdůležitějších aspektů správy databáze. Hraje klíčovou roli, kterou by měla implementovat každá správa databáze. Když je implementován a proveden správně, výsledek zlepší nejen zabezpečení vašich dat, ale také ovlivní stabilitu systému, zlepší životní cyklus vývoje, zvýší shodu vašich dat a zvýší povědomí o zabezpečení až na úroveň vašeho týmu. Každý nechce, aby jeho data skončila ve špatných rukou. Pokud dojde k porušení dat, nejenže to ohrozí důvěrnost a integritu vašich dat, ale také vaši organizaci vystaví významným finančním rizikům. I při pouhé implementaci jednoduché správy databází, pokud zjistíte, že někdo již vnikl do vašeho systému, je pocit nejistoty a strachu z toho, jaké následky vám to přinese, naprosto nepříjemný.
Určení, zda je připojení k serveru MySQL bezpečné, závisí na tom, jak bezpečně MySQL přenáší data při přenosu. Díky nešifrovanému spojení mezi klientem MySQL a serverem může někdo s přístupem k síti sledovat veškerý váš provoz a kontrolovat data odesílaná nebo přijímaná mezi klientem a serverem.
Když musíte přesouvat informace přes síť bezpečným způsobem, je nešifrované připojení nepřijatelné. Aby byl jakýkoli druh dat nečitelný, použijte šifrování. Šifrovací algoritmy musí obsahovat bezpečnostní prvky, aby odolávaly mnoha druhům známých útoků, jako je změna pořadí šifrovaných zpráv nebo dvojnásobné přehrání dat.
Ale moje MySQL je v bezpečí, že?
Věřit, že vaše MySQL je bezpečné, aniž byste zjišťovali jeho stabilitu a kontrolu zranitelnosti, je jako náboženství. Máte sklon věřit, i když to nevidíte, dokonce aniž byste se toho dotkli. Problém je, že MySQL je technologie a její existence není založena na abstraktních myšlenkách. Musí být testován, musí být prokázán a vyžaduje bezpečnost a řídí se osvědčenými postupy, které byly testovány i ostatními.
Určení, zda jsou připojení k serveru MySQL, tj. přenosová připojení, bezpečná nebo šifrovaná, závisí na tom, "jak jste nastavili databázi?" nebo "kdo nastavil vaši databázi?".
MySQL podporuje šifrovaná spojení mezi klienty a serverem pomocí protokolu TLS (Transport Layer Security). TLS se někdy označuje jako SSL (Secure Sockets Layer), ale MySQL ve skutečnosti nepoužívá protokol SSL pro šifrovaná připojení, protože jeho šifrování je slabé a SSL již bylo zastaralé ve prospěch TLS. TLS používá šifrovací algoritmy k zajištění důvěryhodnosti dat přijatých přes veřejnou síť. Má mechanismy pro detekci změny, ztráty nebo přehrávání dat. TLS také zahrnuje algoritmy, které poskytují ověření identity pomocí standardu X.509. SSL nebo TLS se používají zaměnitelně, ale v kontextu šifrování s MySQL se používá TLS, pro které MySQL podporuje šifrovaná připojení pomocí protokolů TLSv1, TLSv1.1, TLSv1.2 a TLSv1.3.
X.509 umožňuje identifikovat někoho na internetu. V základních termínech by měla existovat nějaká entita zvaná „Certifikační autorita“ (nebo CA), která přiděluje elektronické certifikáty každému, kdo je potřebuje. Certifikáty se spoléhají na asymetrické šifrovací algoritmy, které mají dva šifrovací klíče (veřejný klíč a tajný klíč). Vlastník certifikátu může certifikát předložit jiné straně jako doklad totožnosti. Certifikát se skládá z veřejného klíče jeho vlastníka. Jakákoli data zašifrovaná pomocí tohoto veřejného klíče lze dešifrovat pouze pomocí odpovídajícího tajného klíče, který vlastní vlastník certifikátu.
Stejně jako Sparťané používali Scytale
Je známo, že Scytale se používá jako způsob šifrování a dešifrování zprávy, která se používala kolem roku 400 před naším letopočtem. od Sparťanů. Napsali zprávu na list papyru (druh papíru), který byl ovinut kolem hole. Příjemce může zprávu dešifrovat pouze v případě správného průměru a velikosti hole. Slouží jako způsob, jak zašifrovat a zabránit neoprávněné extrakci zpráv nebo dat do cílové destinace.
Stejně jako u MySQL je použití protokolů a šifer SSL/TLS způsob, jak se vyhnout tomu, aby někdo extrahoval vaše data nebo ukradl vaše data při jejich přenosu po drátě nebo přes internet.
Ve výchozím nastavení se programy MySQL pokoušejí o připojení pomocí šifrování, pokud server podporuje šifrovaná připojení, a pokud šifrované připojení nelze navázat, přejdou zpět na nešifrované připojení. Od verze MySQL>=5.7 lze soubory TLS/SSL a RSA vytvářet nebo generovat s podporou proměnných. U distribucí MySQL kompilovaných pomocí OpenSSL má server MySQL schopnost automaticky generovat chybějící soubory SSL a RSA při spuštění. Automatické generování těchto souborů řídí systémové proměnné auto_generate_certs, sha256_password_auto_generate_rsa_keys a caching_sha2_password_auto_generate_rsa_keys (verze>=8.0). Tyto proměnné jsou ve výchozím nastavení povoleny. Mohou být povoleny při spuštění a kontrolovány, ale nelze je nastavit za běhu.
Ve výchozím nastavení jsou tyto proměnné zapnuty nebo povoleny. Jinak mohou uživatelé vyvolat obslužný program mysql_ssl_rsa_setup ručně. U některých typů distribuce, jako jsou balíčky RPM a DEB, dochází během inicializace datového adresáře k vyvolání mysql_ssl_rsa_setup. V tomto případě nemusí být distribuce MySQL zkompilována pomocí OpenSSL, pokud je k dispozici příkaz openssl.
Jakmile budou tyto soubory dostupné a/nebo vygenerovány, MySQL stále nebude používat šifrovací připojení z následujících důvodů. Jak již bylo zmíněno dříve, klientské programy MySQL se ve výchozím nastavení pokoušejí navázat šifrované připojení, pokud server podporuje šifrovaná připojení, přičemž další kontrola je dostupná prostřednictvím režimu --ssl (nebo --ssl <=5.7.11, protože toto je již zastaralé). možnost:
-
Pokud připojení MySQL není označeno příznakem --ssl-mode, je výchozí hodnota nastavena na --ssl-mode=PREDFORMOVANÝ. Klienti se proto pokoušejí připojit pomocí šifrování a pokud nelze vytvořit šifrované připojení, vrátí se k nešifrovanému připojení.
-
S --ssl-mode=REQUIRED vyžadují klienti šifrované připojení a selžou, pokud je nelze navázat.
-
S --ssl-mode=DISABLED používají klienti nešifrované připojení.
-
S --ssl-mode=VERIFY_CA nebo --ssl-mode=VERIFY_IDENTITY vyžadují klienti šifrované připojení a také provést ověření podle certifikátu CA serveru a (s VERIFY_IDENTITY) podle názvu hostitele serveru v jeho certifikátu.
S výchozím mechanismem MySQL pro použití preferovaného připojení se pravděpodobně pokusí použít šifrované nebo zabezpečené připojení, ale stále to ponechává některé věci, které je třeba udělat a určit.
Jak již bylo zmíněno dříve, proměnné auto_generate_certs, sha256_password_auto_generate_rsa_keys a caching_sha2_password_auto_generate_rsa_keys (verze>=8.0) pomáhají generovat požadované soubory SSL/TLS a RSA, přičemž běžného uživatele by takové požadavky neměly vyžadovat. nejistý. Vytvořme například uživatele s názvem 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)Potom ověřte, zda jsou proměnné nastaveny správně, což by mělo být povoleno tak, jak jsou ve výchozím nastavení:
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)Ověření, zda jsou soubory generovány správně v cestě /var/lib/mysql/ (nebo v cestě datadir pro toto 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.pemPotom ověřte, zda jsou soubory SSL načteny správně:
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)Určete zabezpečení svého připojení
To vypadá dobře. Znamená to také, že MySQL je připravena přijímat šifrovaná připojení. Ale připojování k MySQL tak, jak je, jak je uvedeno, bude standardně používat --ssl-mode=PREFFERED, nebo pokud --ssl-mode není specifikováno, bude se stále používat nešifrované připojení. Viz níže:
$ mysql [email protected] -h 192.168.40.110 -udbadmin -e "status;"|grep ssl -i
SSL: Nepoužívá se
To ukazuje, že nepoužívá zabezpečené připojení. Kontrola proměnných stavu relace SSL, pokud jsou použity nějaké šifry, odhalí prázdné:
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)Vynucení zabezpečeného připojení
Protože to ukazuje, že připojení stále není zabezpečené, MySQL zavádí proměnnou require_secure_transport, která vyžaduje, aby všechna navazovaná připojení byla šifrována a zabezpečena. Všechny pokusy o připojení pro nezabezpečené připojení selžou. Například povolením na serveru:
mysql> set global require_secure_transport=1;
Query OK, 0 rows affected (0.00 sec)Pokus o připojení jako klient pomocí nešifrovaného připojení se nezdaří:
$ mysql [email protected] -h 192.168.40.110 -udbadmin
ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON.Abyste se mohli úspěšně a bezpečně připojit, musíte zadat proměnné ssl-ca, ssl-cert, ssl-key. Viz níže:
$ 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.3Alternativně, pokud je uživatel vytvořen například s POVINNÝM SSL, měl by vás také připojit pomocí SSL bez ohledu na to, že require_secure_transport je zakázána, což je jeho výchozí hodnota. Vezměte na vědomí, že pokud je povolena require_secure_transport, její funkce doplňuje požadavky SSL pro jednotlivé účty, které mají přednost. Pokud je tedy účet definován s REQUIRE SSL, povolení require_secure_transport neumožňuje použít účet pro připojení pomocí souboru soketu Unix.
Ujistěte se, že nasazení serveru MySQL je šifrované a bezpečné
Bezproblémové je to, na co se vždy těšíme, takže se nemusíte obávat žádných dalších problémů a starostí. ClusterControl nasazuje databáze MySQL pomocí šifrovaných připojení a generuje certifikáty SSL a RSA za vás. Například níže uvedený snímek obrazovky zobrazující aktivitu úlohy příkazu Create Cluster z ClusterControl.
Nastaví soubory SSL a RSA a umístí je do /etc/ cesta mysql/certs/ stejně jako níže:
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)Potom ClusterControl také seskupuje vygenerované soubory SSL a RSA centralizovaným způsobem pod navigačním panelem Key Management, jak je znázorněno níže:
Po nasazení stačí vytvořit uživatele s POVINNÝM SSL nebo mít require_secure_transport, pokud chcete pro připojení k serveru MySQL vynutit šifrovanou a zabezpečenou vrstvu.