Szyfrowanie bazy danych MariaDB, zarówno w drodze, jak i w spoczynku, jest jedną z najważniejszych rzeczy, które organizacja powinna rozważyć, jeśli cenisz swoje dane.
Organizacje, które zajmują się transakcjami finansowymi, dokumentacją medyczną, informacjami poufnymi, a nawet danymi osobowymi, muszą wymagać tego rodzaju ochrony danych. Zasadniczo szyfrowanie bazy danych przekształci czytelne dane do formatu, który jest nieczytelny (lub przynajmniej trudny do odszyfrowania) przez nieautoryzowanego użytkownika.
Szyfrowanie danych zapobiega nadużyciom lub złośliwym zamiarom hakerów lub nieupoważnionego personelu, które mogą zaszkodzić Twojej firmie. Nieszyfrowane dane są podatne na ataki hakerów, którzy wprowadzają złośliwe dane, które mogą uszkodzić infrastrukturę lub ukraść informacje. Firma Quartz opublikowała niedawno artykuł o największym włamaniu, które miało miejsce w tym kierunku i alarmuje, że w ciągu ostatnich dwóch dekad dane zostały skradzione z miliardów kont.
Powiązane zasoby Jak szyfrować kopie zapasowe MySQL i MariaDB Zabezpieczenia bazy danych — szyfrowanie kopii zapasowych podczas przesyłania i w spoczynku Zaktualizowane:Zostań administratorem danych ClusterControl — Zarządzanie kluczami SSL i szyfrowanie danych MySQL podczas przesyłaniaW tym blogu omówimy różne sposoby szyfrowania danych MariaDB, niezależnie od tego, czy są w stanie spoczynku, czy w drodze. Zapewnimy Ci podstawową wiedzę na temat szyfrowania i sposobu korzystania z niego, abyś mógł wykorzystać te podejścia, aby zapewnić bezpieczeństwo danych.
Szyfrowanie danych MariaDB:w drodze
MariaDB domyślnie nie używa szyfrowania podczas transmisji danych w sieci od serwera do klienta. Jednak użycie domyślnej konfiguracji może sprowokować potencjalnego hakera do podsłuchiwania niezabezpieczonego/nieszyfrowanego kanału. Jeśli pracujesz w odizolowanym lub bardzo bezpiecznym środowisku, ten stan domyślny może być akceptowalny. Nie jest to jednak idealne rozwiązanie, gdy klient i sieć znajdują się w różnych sieciach, ponieważ konfiguruje bazę danych na potencjalny atak typu „man-in-the-middle”.
Aby uniknąć tych ataków, MariaDB umożliwia szyfrowanie danych przesyłanych między serwerem a klientami przy użyciu protokołu Transport Layer Security (TLS) (wcześniej znanego jako Secure Socket Layer lub SSL). Aby rozpocząć, upewnij się, że serwer MariaDB został skompilowany z obsługą TLS. Możesz to sprawdzić, uruchamiając instrukcję SHOW GLOBAL VARIABLES, jak pokazano poniżej:
MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';
+---------------------+---------------------------------+
| Variable_name | Value |
+---------------------+---------------------------------+
| version_ssl_library | OpenSSL 1.0.1e-fips 11 Feb 2013 |
+---------------------+---------------------------------+
1 row in set (0.001 sec)Możesz być zdezorientowany tym, jak różnią się SSL i TSL. Dokumentacja może używać terminu SSL, a zmienne do konfiguracji również używają ssl_* jako prefiksu, jednak MariaDB obsługuje tylko jego bezpieczne następniki, a nie starsze wersje SSL. Może być konieczne zidentyfikowanie i używanie poprawnych wersji MariaDB, które wymagają odpowiedniej obsługi wersji TLS, których potrzebujesz. Na przykład PCI DSS v3.2 zaleca używanie minimalnej wersji protokołu TLSv1.2, obsługiwanej przez starsze wersje MariaDB. Jednak z TLS 1.3 wymaga OpenSSL 1.1.1, jest szybszy ze względu na bardziej wydajne uzgadnianie między dwoma systemami komunikującymi się i jest to obsługiwane od MariaDB 10.2.16 i MariaDB 10.3.8.
Aby wykorzystać szyfry dostępne dla określonej wersji TLS, możesz je zdefiniować za pomocą --ssl-cipher w mysqld polecenie lub szyfr SSL zmienna w pliku konfiguracyjnym. Zwróć uwagę, że szyfrów TLSv1.3 nie można wykluczyć podczas korzystania z OpenSSL, nawet przy użyciu zmiennej systemowej ssl_cipher.
Parametry konfiguracyjne do szyfrowania przesyłanych danych
Aby zaszyfrować przesyłane dane, możesz wykonać sekwencję poleceń wymienionych poniżej:
Wygeneruj certyfikat CA
openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 365000 -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server" -key ca-key.pem -out ca-cert.pemWygeneruj certyfikat serwera
openssl req -newkey rsa:2048 -days 365000 -nodes -keyout server-key.pem -out server-req.pem -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server"
openssl rsa -in server-key.pem -out server-key.pem
openssl x509 -req -in server-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pemWygeneruj certyfikat klienta
openssl req -newkey rsa:2048 -days 365000 -nodes -keyout client-key.pem -out client-req.pem -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=Client Server"
openssl rsa -in client-key.pem -out client-key.pem
openssl x509 -req -in client-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pemZwróć uwagę, że Twoje imię i nazwisko (CN) w -temacie argument musi być unikalny w stosunku do generowanych certyfikatów CA, serwera i klienta. Technicznie rzecz biorąc, CA i Server mogą mieć ten sam CN, ale najlepiej nadać mu unikalny identyfikator dla tych trzech. W przeciwnym razie otrzymasz taki błąd:
ERROR 2026 (HY000): SSL connection error: tlsv1 alert unknown caW porządku, certyfikaty i klucze są na swoim miejscu. Musisz określić ścieżkę, używając zmiennych ssl_* w pliku konfiguracyjnym MySQL (np. /etc/my.cnf dla systemu operacyjnego opartego na RHEL lub /etc/mysql/my.cnf dla systemu operacyjnego Debian/Ubuntu). Zobacz przykładową konfigurację poniżej:
[msqld]
...
ssl_ca=/etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/server-cert.pem
ssl_key=/etc/ssl/galera/self-gen/server-key.pemOczywiście musisz podać poprawną ścieżkę, w której umieściłeś swój certyfikat i klucze.
Następnie umieść te parametry pod [client-mariadb] sekcji pliku konfiguracyjnego, jak poniżej:
[client-mariadb]
ssl_ca = /etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/client-cert.pem
ssl_key=/etc/ssl/galera/self-gen/client-key.pemJak wspomniano wcześniej, możesz określić, jakiego typu szyfru może używać Twoja konfiguracja SSL/TLS. Można to zrobić, określając ustawienia konfiguracji poniżej:
[mysqld]
…
ssl_ca=/etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/server-cert.pem
ssl_key=/etc/ssl/galera/self-gen/server-key.pem
ssl-cipher=AES256-GCM-SHA384Lub możesz użyć następującej konfiguracji, jak poniżej:
ssl-cipher=TLSv1.2 ### This will use all Ciphers available in TLS v1.2
ssl-cipher=HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected] ### Will list strong ciphers available and exclude ciphers in prefix.Ostatnia linia oznacza odpowiednik tego polecenia:
openssl ciphers -v 'HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected]'Spowoduje to wykluczenie słabych szyfrów i tych w formie prefiksu, takich jak DHE-DSS-AES256-GCM-SHA384 na przykład szyfr.
Generowanie certyfikatu za pomocą ClusterControl
Alternatywnie możesz użyć ClusterControl do wygenerowania certyfikatów i kluczy. Aby to zrobić, możesz wykonać następujące czynności, jak pokazano poniżej:
- Wybierz swój klaster MariaDB, a następnie przejdź do sekcji Zabezpieczenia i wybierz Szyfrowanie SSL. W poniższym przykładzie jest to klaster MariaDB Galera:
- Wybierz szyfrowanie SSL i włącz je. Będziesz mógł utworzyć nowy certyfikat lub wybrać już istniejący. W tym przykładzie wybiorę opcję „Utwórz certyfikat”:
- Ostatnim krokiem jest skonfigurowanie dni wygaśnięcia certyfikatu. Zobacz poniżej:
Jeśli klikniesz „Uruchom ponownie węzły”, ClusterControl wykona restart kroczący. Zwróć uwagę, że jeśli używasz MariaDB 10.4 (która jest obecnie w wersji RC), możesz używać SSL bez ponownego uruchamiania serwera MariaDB. Wystarczy użyć polecenia FLUSH SSL, które jest nową funkcją dodaną w wersji MariaDB 10.4.
Innym sposobem obsługi certyfikatów/kluczy TLS/SSL jest użycie opcji Zarządzanie kluczami pod ClusterControl. Sprawdź ten blog, aby dowiedzieć się więcej o tym, jak to zrobić.
Utwórz swojego użytkownika TLS/SSL MariaDB
Na wypadek, gdybyś myślał, że skończyłeś, nie jesteś. Należy upewnić się, że użytkownicy muszą używać protokołu SSL, gdy łączą się z serwerem. Ten użytkownik będzie musiał zawsze komunikować się z serwerem za pośrednictwem kanału prywatnego. Jest to bardzo ważne, ponieważ musisz upewnić się, że wszyscy Twoi klienci będą komunikować się z Twoim serwerem w bardzo bezpieczny i prywatny sposób.
Aby to zrobić, wykonaj następujący przykład:
MariaDB [(none)]> CREATE USER [email protected]'192.168.10.200' IDENTIFIED BY '[email protected]';
Query OK, 0 rows affected (0.005 sec)MariaDB [(none)]> GRANT ALL ON *.* TO [email protected]'192.168.10.200' REQUIRE SSL;
Query OK, 0 rows affected (0.005 sec)Upewnij się, że po połączeniu się z hostem klienta/aplikacji skopiuj certyfikat wygenerowany na podstawie poprzednich kroków.
Weryfikacja połączenia
Testowanie połączenia, czy jest zaszyfrowane, czy nie, jest bardzo ważne, aby określić stan. Aby to zrobić, możesz wykonać następujące polecenie poniżej:
mysql -e "status"|grep -i 'cipher'
SSL: Cipher in use is DHE-RSA-AES256-GCM-SHA384Alternatywnie, OpenSSL w wersji 1.1.1 dodał obsługę -starttls mysql . Dostępny jest statycznie skompilowany plik binarny openssl, który można pobrać tutaj https://testssl.sh/openssl-1.0.2k-dev-chacha.pm.ipv6.Linux+FreeBSD.tar.gz (lub sprawdź tę prezentację w formacie PDF) . Następnie możesz wykonać następujące polecenie poniżej:
echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pemPrzykładowy wynik byłby taki jak poniżej:
$ echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pem
CONNECTED(00000003)
depth=1 C = PH, ST = Davao Del Sur, L = Davao City, O = Maximus Aleksandre, CN = CA Server
verify return:1
depth=0 C = PH, ST = Davao Del Sur, L = Davao City, O = Maximus Aleksandre, CN = DB Server
verify return:1
---
Certificate chain
0 s:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server
i:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
1 s:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
i:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDTDCCAjQCAQEwDQYJKoZIhvcNAQELBQAwazELMAkGA1UEBhMCUEgxFjAUBgNV
BAgMDURhdmFvIERlbCBTdXIxEzARBgNVBAcMCkRhdmFvIENpdHkxGzAZBgNVBAoM
Ek1heGltdXMgQWxla3NhbmRyZTESMBAGA1UEAwwJQ0EgU2VydmVyMCAXDTE5MDYx
MDAyMTMwNFoYDzMwMTgxMDExMDIxMzA0WjBrMQswCQYDVQQGEwJQSDEWMBQGA1UE
CAwNRGF2YW8gRGVsIFN1cjETMBEGA1UEBwwKRGF2YW8gQ2l0eTEbMBkGA1UECgwS
TWF4aW11cyBBbGVrc2FuZHJlMRIwEAYDVQQDDAlEQiBTZXJ2ZXIwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDNwFuoqJg8YlrDinxDZN4+JjFUTGlDfhmy
9H/1C4fZToegvd3RzU9mz3/Fgyuoez4szHDgkn7o4rqmKAH6tMm9R44qtBNGlxka
fn12PPXudDvij4A9C3nVatBJJXTSvSD4/eySY33kAS1DpKsgsTgKAKOsyadcvXYU
IP5nfFc7pxX/8qZADVmyeik4M+oLxO6ryurt0wmUhOmlz5zQghh9kFZLA49l+p95
m5D53d/O+Qj4HSb2ssZD2ZaRc2k4dMCVpa87xUbdP/VVLeu0J4BE3OJiwC0N1Jfi
ZpP2DOKljsklaAYQF+tPnWi5pgReEd47/ql0fNEjeheF/MJiJM1NAgMBAAEwDQYJ
KoZIhvcNAQELBQADggEBAAz7yB+UdNYJ1O5zJI4Eb9lL+vNVKhRJ8IfNrwKVbpAT
eQk9Xpn9bidfcd2gseqDTyixZhWjsjO2LXix7jRhH1DrJvhGQ7+1w36ujtzscTgy
ydLH90CnE/oZHArbBhmyuqmu041w5rB3PpI9i9SveezDrbVcaL+qeGo8s4ATB2Yr
Y3T3OTqw6o/7cTJJ8S1aXBLTyUq5HAtOTM2GGZMSYwVqUsmBHA3d7M8i7yp20RVH
78j1H6+/hSSY4SDhwr04pSkzmm6HTIBCgOYrmEV2sQ/YeMHqVrSplLRY3SZHvqHo
gbSnasOQAE1oJnSNyxt9CRRAghM/EHEnsA2OlFa9iXQ=
-----END CERTIFICATE-----
subject=/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server
issuer=/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
---
No client certificate CA names sent
Client Certificate Types: RSA fixed DH, DSS fixed DH, RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: DH, 2048 bits
---
SSL handshake has read 3036 bytes and written 756 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-GCM-SHA384
Session-ID: 46E0F6FA42779DB210B4DF921A68E9E4CC39ADD87D28118DB0073726B98C0786
Session-ID-ctx:
Master-Key: 2A2E6137929E733051BE060953049A0553F49C2F50A183EEC0C40F7EFB4E2749E611DF54A88417518A274EC904FB3CE6
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 4a dd f3 7f 1e b7 9e cb-77 58 b9 75 53 34 5c 61 J.......wX.uS4\a
0010 - 3a 4d 0e aa e2 6b 27 8e-11 ff be 24 ad 66 88 49 :M...k'....$.f.I
0020 - c1 ba 20 20 d8 9f d5 5c-23 9d 64 dc 97 f2 fa 77 .. ...\#.d....w
0030 - bf e6 26 1f 2c 98 ee 3b-71 66 0c 04 05 3e 54 c1 ..&.,..;qf...>T.
0040 - 88 b6 f7 a9 fd b8 f9 84-cd b8 99 9f 6e 50 3b 13 ............nP;.
0050 - 90 30 91 7d 48 ea 11 f7-3f b7 6b 65 2e ea 7e 61 .0.}H...?.ke..~a
0060 - 70 cd 4e b8 43 54 3d a0-aa dc e5 44 a7 41 3a 5e p.N.CT=....D.A:^
0070 - 3e cb 45 57 33 2b a4 8f-75 d8 ce a5 9e 00 16 50 >.EW3+..u......P
0080 - 24 aa 7a 54 f8 26 65 74-11 d7 f3 d6 66 3b 14 60 $.zT.&et....f;.`
0090 - 33 98 4a ef e2 17 ba 33-4e 7f 2b ce 46 d7 e9 11 3.J....3N.+.F...
Start Time: 1560133350
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONESzyfrowanie danych MariaDB:w spoczynku
Zaszyfrowane dane, które są fizycznie przechowywane w pamięci sprzętowej (tj. w spoczynku) zapewniają większą stabilność i ochronę przed naruszeniem danych. Jeśli złośliwy atakujący może zalogować się do Twojej bazy danych MariaDB, może odczytać dane w postaci zwykłego tekstu. Podobnie jak przy użyciu polecenia strings w Linuksie, będziesz w stanie łatwo pobrać dane z bazy danych. Co więcej, zwiększa to niebezpieczeństwo, jeśli atakujący ma zaawansowaną wiedzę na temat formatu pliku obszaru tabel.
Szyfrowanie w stanie spoczynku jest dodatkową ochroną, ale nie zastępuje dobrej zapory ogniowej, silnych haseł, poprawnych uprawnień użytkownika i szyfrowania w trakcie przesyłania między klientem a serwerem.
Obsługa MariaDB dla szyfrowania tabel i obszarów tabel została dodana w wersji 10.1.3. Ponieważ Twoje tabele są szyfrowane, kradzież Twoich danych jest prawie niemożliwa. Ten rodzaj szyfrowania umożliwia również Twojej organizacji zachowanie zgodności z przepisami rządowymi, takimi jak RODO.,
Po włączeniu szyfrowania danych w spoczynku w MariaDB, tabele zdefiniowane z ENCRYPTED=YES lub innodb_encrypt_tables=ON będą szyfrować przechowywane dane. Jest odszyfrowywany tylko wtedy, gdy uzyskuje się do niego dostęp za pośrednictwem bazy danych MariaDB, w przeciwnym razie dane są nieczytelne.
Na przykład, czytając dane, które są niezaszyfrowane, pokaże Ci się jako taki:
$ strings admin_logs.ibd|head -10
=r7N
infimum
supremum
infimum
supremum/
failThe verification code you entered is incorrect.KK
elmo1234failThe password or username you entered is invalidKK
elmo1234failThe password or username you entered is invalidKK
elmoasfdfailThe verification code you entered is incorrect.KK
safasffailThe verification code you entered is incorrect.KKale w przypadku zaszyfrowanych danych obszar tabel nie będzie czytelny, tak jak w poniższym przykładzie:
# strings user_logs.ibd |head -10
E?*Pa
[+YQ
KNmbUtQ
T_lPAW
\GbQ.
] e2
#Rsd
ywY%o
kdUY
{]~GEWarto również zauważyć, że szyfrowanie danych w stanie spoczynku MariaDB zwiększa obciążenie danych o około 3-5%. Szyfrowanie MariaDB jest również w pełni obsługiwane w przypadku korzystania z silników pamięci masowej XtraDB i InnoDB. Szyfrowanie jest również obsługiwane przez aparat pamięci masowej Aria, ale tylko w przypadku tabel utworzonych z ROW_FORMAT=PAGE (wartość domyślna) i dziennika binarnego (dziennik replikacji). MariaDB pozwala nawet użytkownikowi na elastyczne szyfrowanie. W XtraDB lub InnoDB można wybrać szyfrowanie:
- wszystko — wszystkie przestrzenie tabel (ze wszystkimi tabelami)
- poszczególne stoły
- wszystko, z wyjątkiem pojedynczych tabel
Dodatkowo można wybrać szyfrowanie plików dziennika XtraDB/InnoDB (co jest zalecane).
MariaDB ma swoje ograniczenia. Na przykład pamięć podręczna Galera Cluster nie jest szyfrowana, ale jest planowana jako część wersji MariaDB 10.4. Pełną listę ograniczeń znajdziesz tutaj.
Jak skonfigurować i skonfigurować MariaDB do szyfrowania danych w spoczynku
- Wygeneruj losowe klucze szyfrowania za pomocą polecenia openssl rand.
Teraz otwórz i edytuj plik /etc/mysql/encryption/keyfile i dodaj identyfikator klucza, do którego będzie się odwoływać podczas tworzenia zaszyfrowanych tabel, ponieważ jest to identyfikator klucza szyfrowania. Zobacz ENCRYPTION_KEY_ID, aby uzyskać więcej informacji. Dlatego następujący format powinien wyglądać następująco:$ mkdir -p /etc/mysql/encryption $ for i in {1..5}; do openssl rand -hex 32 >> /etc/mysql/encryption/keyfile; done;
In my example keyfile, this looks as the following:<encryption_key_id1>;<hex-encoded_encryption_key1> <encryption_key_id2>;<hex-encoded_encryption_key2>$ cat keyfile 1;687a90b4423c10417f2483726a5901007571c16331d2ee9534333fef4e323075 2;e7bf20f1cbde9632587c2996871cff74871890d19b49e273d13def123d781e17 3;9284c9c80da9a323b3ac2c82427942dfbf1718b57255cc0bc0e2c3d6f15ac3ac 4;abf80c3a8b10643ef53a43c759227304bcffa263700a94a996810b0f0459a580 5;bdbc5f67d34a4904c4adc9771420ac2ab2bd9c6af1ec532e960335e831f02933 - Utwórzmy lub wygenerujmy losowe hasło, używając podobnego polecenia z kroku 1:
$ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key - Przed przejściem do następnego kroku należy zwrócić uwagę na następujące szczegóły dotyczące szyfrowania pliku klucza:
- Jedynym algorytmem, który obecnie obsługuje MariaDB do szyfrowania pliku klucza, jest tryb szyfrowania bloków (CBC) Advanced Encryption Standard (AES).
- Rozmiar klucza szyfrowania może wynosić 128-bitów, 192-bitów lub 256-bitów.
- Klucz szyfrowania jest tworzony na podstawie skrótu SHA-1 hasła szyfrowania.
- Hasło szyfrowania ma maksymalną długość 256 znaków.
$ openssl enc -aes-256-cbc -md sha1 -pass file:/etc/mysql/encryption/keyfile.key -in /etc/mysql/encryption/keyfile -out /etc/mysql/encryption/keyfile.enc - Dodaj następujące zmienne do pliku konfiguracyjnego MySQL (np. /etc/my.cnf w systemie operacyjnym Linux opartym na RHEL lub /etc/mysql/my.cnf w systemie operacyjnym opartym na systemie Debian/Ubuntu Linux)
[mysqld] … #################### DATABASE ENCRYPTION ############################## plugin_load_add = file_key_management file_key_management_filename = /etc/mysql/encryption/keyfile.enc file_key_management_filekey = FILE:/etc/mysql/encryption/keyfile.key file_key_management_encryption_algorithm = aes_cbc encrypt_binlog = 1 innodb_encrypt_tables = ON innodb_encrypt_log = ON innodb_encryption_threads = 4 innodb_encryption_rotate_key_age = 0 # Do not rotate key - Uruchom ponownie serwer MariaDB teraz
$ systemctl start mariadb
Zweryfikuj i przetestuj szyfrowanie
Aby zweryfikować i przetestować szyfrowanie, po prostu utwórz przykładową tabelę. Na przykład utwórz tabelę, wykonując poniższe instrukcje SQL:
MariaDB [test]> CREATE TABLE a (i int) ENGINE=InnoDB ENCRYPTED=YES;
Query OK, 0 rows affected (0.018 sec)MariaDB [test]> CREATE TABLE b (i int) ENGINE=InnoDB;
Query OK, 0 rows affected (0.003 sec)Następnie dodajmy trochę danych do tabel:
MariaDB [test]> insert into a values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2 Duplicates: 0 Warnings: 0MariaDB [test]> insert into b values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2 Duplicates: 0 Warnings: 0Aby sprawdzić i zobaczyć, jakie tabele są zaszyfrowane, po prostu uruchom następujące polecenie SELECT zapytanie poniżej:
MariaDB [test]> SELECT * FROM information_schema.innodb_tablespaces_encryption\G
*************************** 1. row ***************************
SPACE: 4
NAME: mysql/gtid_slave_pos
ENCRYPTION_SCHEME: 1
KEYSERVER_REQUESTS: 1
MIN_KEY_VERSION: 1
CURRENT_KEY_VERSION: 1
KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
CURRENT_KEY_ID: 1
ROTATING_OR_FLUSHING: 0
*************************** 2. row ***************************
SPACE: 2
NAME: mysql/innodb_index_stats
ENCRYPTION_SCHEME: 1
KEYSERVER_REQUESTS: 1
MIN_KEY_VERSION: 1
CURRENT_KEY_VERSION: 1
KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
CURRENT_KEY_ID: 1
ROTATING_OR_FLUSHING: 0
*************************** 3. row ***************************
SPACE: 1
NAME: mysql/innodb_table_stats
ENCRYPTION_SCHEME: 1
KEYSERVER_REQUESTS: 1
MIN_KEY_VERSION: 1
CURRENT_KEY_VERSION: 1
KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
CURRENT_KEY_ID: 1
ROTATING_OR_FLUSHING: 0
*************************** 4. row ***************************
SPACE: 3
NAME: mysql/transaction_registry
ENCRYPTION_SCHEME: 1
KEYSERVER_REQUESTS: 0
MIN_KEY_VERSION: 1
CURRENT_KEY_VERSION: 1
KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
CURRENT_KEY_ID: 1
ROTATING_OR_FLUSHING: 0
*************************** 5. row ***************************
SPACE: 5
NAME: test/a
ENCRYPTION_SCHEME: 1
KEYSERVER_REQUESTS: 1
MIN_KEY_VERSION: 1
CURRENT_KEY_VERSION: 1
KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
CURRENT_KEY_ID: 1
ROTATING_OR_FLUSHING: 0
*************************** 6. row ***************************
SPACE: 6
NAME: test/b
ENCRYPTION_SCHEME: 1
KEYSERVER_REQUESTS: 1
MIN_KEY_VERSION: 1
CURRENT_KEY_VERSION: 1
KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
CURRENT_KEY_ID: 1
ROTATING_OR_FLUSHING: 0
6 rows in set (0.000 sec)Tworzenie tabeli InnoDB nie wymaga podawania słowa kluczowego ENCRYPTED=YES. Jest tworzony automatycznie, jak określiliśmy w pliku konfiguracyjnym, aby innodb_encrypt_tables =ON.
Jeśli chcesz określić identyfikator szyfrowania używanej tabeli, możesz również wykonać następujące czynności:
MariaDB [test]> CREATE TABLE c (i int) ENGINE=InnoDB ENCRYPTION_KEY_ID = 4;
Query OK, 0 rows affected (0.003 sec)ENCRYPTION_KEY_ID został pobrany z pliku klucza szyfrowania, który wygenerowaliśmy wcześniej.
Dodatkowo, jeśli chcesz przeprowadzić więcej testów przez powłokę, możesz użyć ciągów polecenie, które pokazałem ci wcześniej.
Dodatkowe informacje na temat szyfrowania MariaDB
Jeśli instancja MariaDB nie powinna zawierać żadnych niezaszyfrowanych tabel, po prostu skonfiguruj zmienną w pliku konfiguracyjnym my.cnf w [mysqld] sekcja w następujący sposób:
innodb_encrypt_tables = FORCE.Aby szyfrować binlog, po prostu dodaj następujące
encrypt_binlog = 1Dziennik przeróbek InnoDB nie jest domyślnie szyfrowany. Aby go zaszyfrować, po prostu dodaj zmienną poniżej po sekcji [mysqld],
innodb-encrypt-logJeśli potrzebujesz szyfrowania tymczasowych tabel na dysku i plików tymczasowych, możesz dodać:
encrypt-tmp-disk-tables=1
encrypt-tmp-files=1
