sql >> Databasteknik >  >> RDS >> MariaDB

Utforska de olika sätten att kryptera dina MariaDB-data

Att kryptera din MariaDB-databas, oavsett om det är under transport och i vila, är en av de viktigaste sakerna som en organisation bör överväga om du värdesätter din data.

Organisationer som hanterar finansiella transaktioner, medicinska journaler, konfidentiell information eller till och med personuppgifter måste kräva denna typ av dataskydd. I grund och botten kommer databaskryptering att omvandla din läsbara data till ett format som är oläsligt (eller åtminstone svårt att dekryptera) av alla obehöriga användare.

Genom att kryptera din data förhindras missbruk eller uppsåt från hackare eller obehörig personal som kan skada ditt företag. Okrypterad data är benägen att attackeras av hackare som injicerar skadlig data som kan skada din infrastruktur eller stjäla information. Quartz släppte nyligen en artikel om det största intrånget som hände i denna linje och det är alarmerande att data har stulits från miljarder konton under de senaste två decennierna.

Relaterade resurser Hur du krypterar dina MySQL- och MariaDB-säkerhetskopior Databassäkerhet - Säkerhetskopieringskryptering under transport och i vila uppdaterad:Bli en ClusterControl DBA - SSL-nyckelhantering och kryptering av MySQL-data under transport

I den här bloggen kommer vi att diskutera olika sätt att kryptera din MariaDB-data oavsett om det är i vila och under transport. Vi kommer att ge dig en grundläggande förståelse för kryptering och hur du använder den så att du kan använda dessa metoder för att hålla din data säker.

Kryptering av MariaDB-data:In-Transit

MariaDB använder som standard inte kryptering under dataöverföring över nätverket från server till klient. Men att använda standardinställningen kan provocera en potentiell hackare att avlyssna en osäkrad/okrypterad kanal. Om du arbetar i en isolerad eller mycket säker miljö kan detta standardtillstånd vara acceptabelt. Detta är dock inte idealiskt när din klient och ditt nätverk är på olika nätverk eftersom det ställer in din databas för en potentiell "man-in-the-middle"-attack.

För att undvika dessa attacker låter MariaDB dig kryptera data som överförs mellan servern och klienterna med hjälp av TLS-protokollet (Transport Layer Security) (tidigare känt som Secure Socket Layer eller SSL). För att börja måste du se till att din MariaDB-server kompilerades med TLS-stöd. Du kan verifiera detta genom att köra SHOW GLOBAL VARIABLES-satsen som visas nedan:

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)

Du kan bli förvirrad över hur SSL och TSL skiljer sig åt. Dokumentation kan använda termen SSL och variabler för konfiguration använder också ssl_* som prefix, dock stöder MariaDB endast sina säkra efterföljare och inte längre de äldre SSL-versionerna. Du kanske måste identifiera och använda rätt versioner av MariaDB som kräver rätt stöd för TLS-versioner som du behöver använda. Till exempel rekommenderar PCI DSS v3.2 att du använder en lägsta protokollversion av TLSv1.2 som gamla versioner av MariaDB stöder. Men med TLS 1.3, kräver OpenSSL 1.1.1, är snabbare på grund av ett mer effektivt handslag mellan de två systemen som kommunicerar och detta stöds sedan MariaDB 10.2.16 och MariaDB 10.3.8.

För att använda de chiffer som är tillgängliga för en specifik TLS-version kan du definiera den med --ssl-chifferet i mysqld kommando eller ssl-chiffer variabel i konfigurationsfilen. Observera att TLSv1.3-chiffer inte kan uteslutas när du använder OpenSSL, även om du använder systemvariabeln ssl_cipher.

Konfigurationsparametrar för att kryptera data under transport

För att kryptera dina data under överföring kan du göra följande kommandosekvens:

Skapa ett CA-certifikat

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.pem

Skapa ett servercertifikat

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.pem

Skapa ett klientcertifikat

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.pem

Notera att ditt Common Name (CN) i -subj argumentet måste vara unikt mot ditt CA-, server- och klientcertifikat som du genererar. Tekniskt sett kan CA och Server ha samma CN men det är bäst att göra den unik identifierare för dessa tre. Annars får du ett felmeddelande som sådant:

ERROR 2026 (HY000): SSL connection error: tlsv1 alert unknown ca

Okej, certifikat och nycklar är på plats. Du måste ange sökvägen med ssl_*-variablerna i din MySQL-konfigurationsfil (t.ex. /etc/my.cnf för RHEL-baserat OS eller /etc/mysql/my.cnf för Debian/Ubuntu OS). Se exempelkonfigurationen nedan:

[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.pem

Naturligtvis måste du ange rätt sökväg där du har placerat ditt certifikat och nycklar.

Placera sedan dessa parametrar under [client-mariadb] avsnitt av din konfigurationsfil som sådan nedan:

[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.pem

Som nämnts tidigare kan du ange vilken typ av chiffer som din SSL/TLS-konfiguration kan använda. Detta kan göras genom att specificera konfigurationsinställningarna nedan:

[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-SHA384

Eller så kan du använda följande konfiguration som sådan nedan:

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.

Den sista raden anger motsvarigheten till detta kommando:

openssl ciphers -v 'HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected]'

Detta kommer att utesluta svaga chiffer och de chiffer som är i prefixform som DHE-DSS-AES256-GCM-SHA384 chiffer till exempel.

Generera ditt certifikat med ClusterControl

Alternativt kan du använda ClusterControl för att generera certifikaten och nycklarna åt dig. För att göra detta kan du göra följande enligt nedan:

  1. Välj ditt MariaDB-kluster och gå sedan till Säkerhet fliken och välj SSL-kryptering. I mitt exempel nedan är detta ett MariaDB Galera Cluster:
  2. Välj SSL-kryptering och aktivera den. Du kommer att kunna skapa ett nytt certifikat eller välja ett befintligt. För det här exemplet kommer jag att välja alternativet "Skapa certifikat":
  3. Det sista steget är att konfigurera giltighetstiden för ditt certifikat. Se nedan: Om du klickar på "Starta om noder" kommer ClusterControl att utföra en rullande omstart. Observera att om du använder MariaDB 10.4 (som för närvarande finns på sin RC-version) kan du använda SSL utan att starta om din MariaDB-server. Använd bara kommandot FLUSH SSL som är en ny funktion som lagts till i MariaDB 10.4-versionen.

Ett annat sätt att hantera dina TLS/SSL-certifikat/nycklar, du kan också använda Nyckelhantering under ClusterControl. Kolla in den här bloggen för att lära dig mer om hur du gör detta.

Skapa din TLS/SSL MariaDB-användare

Om du trodde att du är klar så är du inte det. Du måste se till att dina användare måste använda SSL när de ansluter till servern. Den här användaren måste alltid interagera med servern via en privat kanal. Detta är mycket viktigt eftersom du måste se till att alla dina klienter kommer att interagera med din server på ett mycket säkert och privat sätt.

För att göra detta, gör bara följande exempel:

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)

Se till att kopiera certifikatet som du har genererat baserat på de föregående stegen när du ansluter till din klient/applikationsvärd.

Verifiera din anslutning

Att testa din anslutning om den är krypterad eller inte är mycket viktigt för att fastställa statusen. För att göra det kan du göra följande kommando nedan:

mysql -e "status"|grep -i 'cipher'
SSL:                    Cipher in use is DHE-RSA-AES256-GCM-SHA384

Alternativt har OpenSSL version 1.1.1 lagt till stöd för -starttls mysql . Det finns en tillgänglig statiskt kompilerad openssl-binär som du kan få här https://testssl.sh/openssl-1.0.2k-dev-chacha.pm.ipv6.Linux+FreeBSD.tar.gz (eller kolla in den här presentationen i PDF-format) . Sedan kan du göra följande kommando nedan:

echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pem

Exempelresultatet skulle se ut som nedan:

$ 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)
---
DONE
ClusterControlSingle Console för hela din databasinfrastrukturTa reda på vad mer som är nytt i ClusterControlInstallera ClusterControl GRATIS

Kryptering av MariaDB-data:At-Rest

Krypterad data som lagras fysiskt i din hårdvarulagring (dvs i vila) ger mer stabilitet och skydd mot dataintrång. Om en illvillig angripare kan logga in på din MariaDB-databas kan de läsa data i vanlig text. På samma sätt som att använda ett strängkommando i Linux, skulle du enkelt kunna hämta data från databasen. Dessutom tillför det mer fara om angriparen har en avancerad förståelse för filformatet för tabellutrymmet.

Kryptering i vila är ett extra skydd, men det är inte en ersättning för en bra brandvägg, starka lösenord, korrekta användarbehörigheter och kryptering under transport mellan klienten och servern.

MariaDB:s stöd för kryptering på tabeller och tabellutrymmen lades till i version 10.1.3. Med dina tabeller krypterade är dina data nästan omöjliga för någon att stjäla. Den här typen av kryptering gör också att din organisation kan följa myndighetsföreskrifter som GPDR.,

När du har aktiverat data-at-rest-kryptering i MariaDB, kommer tabeller som är definierade med ENCRYPTED=YES eller med innodb_encrypt_tables=ON att få dina lagrade data krypterade. Den dekrypteras endast när den nås via MariaDB:s databas, annars är informationen oläsbar.

Om du till exempel läser en data som är okrypterad, kommer den att visa dig som sådan:

$ 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.KK

men med krypterad data kommer ditt tabellutrymme inte att vara läsbart precis som exemplet nedan:

# strings user_logs.ibd |head -10
E?*Pa
[+YQ
KNmbUtQ
T_lPAW
\GbQ.
] e2
#Rsd
ywY%o
kdUY
{]~GE

Det är också anmärkningsvärt att MariaDB:s Data-At-Rest-kryptering lägger till en datastorleksoverhead på ungefär 3-5%. MariaDB-kryptering stöds också fullt ut när du använder lagringsmotorerna XtraDB och InnoDB. Kryptering stöds också för Aria-lagringsmotorn, men endast för tabeller skapade med ROW_FORMAT=PAGE (standard) och för den binära loggen (replikeringslogg). MariaDB tillåter till och med användaren flexibelt vad den ska kryptera. I XtraDB eller InnoDB kan man välja att kryptera:

  • allt — alla tabellutrymmen (med alla tabeller)
  • enskilda tabeller
  • allt, utom enskilda tabeller

Dessutom kan man välja att kryptera XtraDB/InnoDB-loggfiler (vilket rekommenderas).

MariaDB har sina begränsningar. Galera Cluster gcache, till exempel, är inte krypterad men den är planerad som en del av MariaDB 10.4-versionen. Du kan hitta en fullständig lista över begränsningar här.

Hur man ställer in och konfigurerar MariaDB för Data-At-Rest-kryptering

  1. Generera slumpmässiga krypteringsnycklar med kommandot openssl rand. 
    $ mkdir -p /etc/mysql/encryption
$ for i in {1..5}; do openssl rand -hex 32 >> /etc/mysql/encryption/keyfile;  done;
    Öppna och redigera nu filen /etc/mysql/encryption/keyfile och lägg till nyckel-ID:n som detta kommer att referera till när du skapar krypterade tabeller eftersom det är krypteringsnyckel-id. Se ENCRYPTION_KEY_ID för mer information. Följande format bör därför vara som följer:
    <encryption_key_id1>;<hex-encoded_encryption_key1>
<encryption_key_id2>;<hex-encoded_encryption_key2>
    In my example keyfile, this looks as the following:
    $ cat keyfile
1;687a90b4423c10417f2483726a5901007571c16331d2ee9534333fef4e323075
2;e7bf20f1cbde9632587c2996871cff74871890d19b49e273d13def123d781e17
3;9284c9c80da9a323b3ac2c82427942dfbf1718b57255cc0bc0e2c3d6f15ac3ac
4;abf80c3a8b10643ef53a43c759227304bcffa263700a94a996810b0f0459a580
5;bdbc5f67d34a4904c4adc9771420ac2ab2bd9c6af1ec532e960335e831f02933
  2. Låt oss skapa eller generera ett slumpmässigt lösenord med det liknande kommandot från steg 1:
    $ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key
  3. Innan du går vidare till nästa steg är det viktigt att notera följande detaljer om kryptering av nyckelfilen:
    • Den enda algoritm som MariaDB för närvarande stöder för att kryptera nyckelfilen är Cipher Block Chaining (CBC)-läge för Advanced Encryption Standard (AES).
    • Storleken på krypteringsnyckeln kan vara 128-bitar, 192-bitar eller 256-bitar.
    • Krypteringsnyckeln skapas från SHA-1-hash för krypteringslösenordet.
    • Krypteringslösenordet har en maxlängd på 256 tecken.
    För att nu kryptera nyckelfilen med kommandot openssl enc, kör följande kommando nedan:
    $ 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
  4. Lägg till följande variabler i din MySQL-konfigurationsfil (dvs. /etc/my.cnf på RHEL-baserat Linux OS eller /etc/mysql/my.cnf i Debian/Ubuntu Linux-baserat OS) 
    [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
  5. Starta om MariaDB Server nu 
    $ systemctl start mariadb

Verifiera och testa krypteringen

För att verifiera och testa krypteringen, skapa bara en exempeltabell. Skapa till exempel tabellen genom att göra följande SQL-satser nedan:

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)

Låt oss sedan lägga till lite data i tabellerna:

MariaDB [test]> insert into a values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2  Duplicates: 0  Warnings: 0
MariaDB [test]> insert into b values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2  Duplicates: 0  Warnings: 0

För att kontrollera och se vilka tabeller som är krypterade, kör bara följande SELECT fråga nedan:

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)

Att skapa InnoDB-tabellen behöver inte ange nyckelordet ENCRYPTED=YES. Den skapas automatiskt som vi angav i konfigurationsfilen för att ha innodb_encrypt_tables =PÅ.

Om du vill ange krypterings-id för tabellen som ska användas kan du också göra följande:

MariaDB [test]> CREATE TABLE c (i int) ENGINE=InnoDB ENCRYPTION_KEY_ID = 4;
Query OK, 0 rows affected (0.003 sec)

ENCRYPTION_KEY_ID togs från krypteringsnyckelfilen som vi genererade tidigare.

Dessutom, om du vill ha mer testning genom skal, kan du använda strängarna kommandot visade jag dig tidigare.

Ytterligare information om MariaDB-kryptering

Om din MariaDB-instans inte ska innehålla några okrypterade tabeller, ställ bara in variabeln i din my.cnf-konfigurationsfil i [mysqld] avsnitt enligt följande:

innodb_encrypt_tables = FORCE.

För binlog-kryptering, lägg bara till följande

encrypt_binlog = 1

InnoDB:s redo-logg är inte krypterad som standard. För att kryptera den, lägg till variabeln nedan efter [mysqld]-sektionen,

innodb-encrypt-log

Om du behöver kryptering för dina temporära tabeller och temporära filer på disken kan du lägga till följande:

encrypt-tmp-disk-tables=1
encrypt-tmp-files=1

  1. Förstå SQL-datatyper – Allt du behöver veta om SQL-datatyper

  2. Använd SET TEXTSIZE för att begränsa data som returneras för varje rad i SQL Server

  3. Återställ mysql-databasen från .frm-filer

  4. Kan Mysql dela en kolumn?