sql >> Database teknologi >  >> RDS >> MariaDB

Udforsk de forskellige måder at kryptere dine MariaDB-data på

Kryptering af din MariaDB-database, uanset om den er under transport og i hvile, er en af ​​de vigtigste ting, som en organisation bør overveje, hvis du værdsætter dine data.

Organisationer, der beskæftiger sig med finansielle transaktioner, lægejournaler, fortrolige oplysninger eller endda personlige data, skal kræve denne type databeskyttelse. Grundlæggende vil databasekryptering transformere dine læsbare data til et format, der er ulæseligt (eller i det mindste svært at dekryptere) af enhver uautoriseret bruger.

Kryptering af dine data forhindrer misbrug eller ondsindet hensigt fra hackere eller uautoriseret personale, der kan skade din virksomhed. Ukrypterede data er tilbøjelige til at blive angrebet af hackere, der injicerer ondsindede data, der kan beskadige din infrastruktur eller stjæle information. Quartz udgav for nylig en artikel om det største brud, der skete i denne retning, og det er alarmerende, at data er blevet stjålet fra milliarder af konti i løbet af de sidste to årtier.

Relaterede ressourcer Sådan krypterer du din MySQL- og MariaDB-sikkerhedskopier Databasesikkerhed - Backup-kryptering under transport og hvile opdateret:Bliv en ClusterControl DBA - SSL-nøglehåndtering og kryptering af MySQL-data under transport

I denne blog vil vi diskutere forskellige måder at kryptere dine MariaDB-data på, uanset om det er i hvile og under transport. Vi vil give dig en grundlæggende forståelse af kryptering og hvordan du bruger den, så du kan bruge disse metoder til at holde dine data sikre.

Kryptering af MariaDB-data:In-Transit

MariaDB bruger som standard ikke kryptering under datatransmission over netværket fra server til klient. Brug af standardopsætningen kan dog provokere en potentiel hacker til at aflytte en usikret/ukrypteret kanal. Hvis du arbejder i et isoleret eller meget sikkert miljø, kan denne standardtilstand være acceptabel. Dette er dog ikke ideelt, når din klient og netværk er på forskellige netværk, da det sætter din database op til et potentielt "man-in-the-middle"-angreb.

For at undgå disse angreb giver MariaDB dig mulighed for at kryptere data i transit mellem serveren og klienter ved hjælp af Transport Layer Security (TLS) protokollen (tidligere kendt som Secure Socket Layer eller SSL). For at starte skal du sikre dig, at din MariaDB-server er kompileret med TLS-understøttelse. Du kan bekræfte dette ved at køre SHOW GLOBAL VARIABLES-sætningen som vist nedenfor:

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 blive forvirret over, hvordan SSL og TSL adskiller sig. Dokumentation kan bruge udtrykket SSL og variabler til konfiguration bruger også ssl_* som præfiks, dog understøtter MariaDB kun dets sikre efterfølgere og ikke længere de ældre SSL-versioner. Du skal muligvis identificere og bruge de korrekte versioner af MariaDB, der kræver den rigtige support af TLS-versioner, du skal bruge. For eksempel anbefaler PCI DSS v3.2 at bruge en minimumsprotokolversion af TLSv1.2, som gamle versioner af MariaDB understøtter. Men med TLS 1.3, kræver OpenSSL 1.1.1, er det hurtigere på grund af et mere effektivt håndtryk mellem de to systemer, der kommunikerer, og dette er understøttet siden MariaDB 10.2.16 og MariaDB 10.3.8.

For at bruge de tilgængelige chiffer til en specifik TLS-version, kan du definere den ved hjælp af --ssl-cipher i mysqld kommando eller ssl-cipher variabel i konfigurationsfilen. Bemærk, at TLSv1.3-cifre ikke kan udelukkes, når du bruger OpenSSL, heller ikke ved at bruge systemvariablen ssl_cipher.

Konfigurationsparametre til kryptering af data under transport

For at kryptere dine data under transport kan du udføre sekvensen af ​​kommandoer nedenfor:

Generer et 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

Generer et 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

Generer et 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

Bemærk, at dit fælles navn (CN) i -subj argumentet skal være unikt i forhold til dit CA-, server- og klientcertifikat, du genererer. Teknisk set kan CA og Server have samme CN, men det er bedst at gøre det til en unik identifikator for disse tre. Ellers vil du modtage en fejlmeddelelse som sådan:

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

Okay, certifikater og nøgler er på plads. Du skal angive stien ved hjælp af ssl_*-variablerne i din MySQL-konfigurationsfil (f.eks. /etc/my.cnf for RHEL-baseret OS eller /etc/mysql/my.cnf for Debian/Ubuntu OS). Se eksempelkonfigurationen nedenfor:

[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

Du skal selvfølgelig angive den korrekte sti, hvor du har placeret dit certifikat og dine nøgler.

Placer derefter disse parametre under [client-mariadb] sektionen af ​​din konfigurationsfil som sådan nedenfor:

[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 tidligere nævnt kan du angive, hvilken type chiffer din SSL/TLS-konfiguration kan bruge. Dette kan gøres ved at angive konfigurationsopsætningen nedenfor:

[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 du kan bruge følgende konfiguration som sådan nedenfor:

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 sidste linje angiver ækvivalenten til denne kommando:

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

Dette vil udelukke svage cifre og de cifre, der er i præfiksform, såsom DHE-DSS-AES256-GCM-SHA384 ciffer for eksempel.

Generering af dit certifikat ved hjælp af ClusterControl

Alternativt kan du bruge ClusterControl til at generere certifikaterne og nøglerne for dig. For at gøre dette kan du gøre følgende som vist nedenfor:

  1. Vælg din MariaDB-klynge, og gå derefter til Sikkerhed fanen og vælg SSL-kryptering. I mit eksempel nedenfor er dette en MariaDB Galera Cluster:
  2. Vælg SSL-krypteringen, og aktiver den. Du vil være i stand til at oprette et nyt certifikat eller vælge et eksisterende. For denne prøve vil jeg vælge muligheden "Opret certifikat":
  3. Det sidste trin er at konfigurere udløbsdagene for dit certifikat. Se nedenunder: Hvis du klikker på "Genstart noder", vil ClusterControl udføre en rullende genstart. Bemærk, hvis du bruger MariaDB 10.4 (som i øjeblikket er på sin RC-version), kan du bruge SSL uden at genstarte din MariaDB-server. Brug blot FLUSH SSL-kommandoen, som er en ny funktion tilføjet i MariaDB 10.4-versionen.

En anden måde at håndtere dine TLS/SSL-certifikater/nøgler på, du kan også bruge Nøglestyring under ClusterControl. Tjek denne blog for at lære mere om, hvordan du gør dette.

Opret din TLS/SSL MariaDB-bruger

Hvis du troede, du var færdig, er du det ikke. Du skal sikre dig, at dine brugere skal bruge SSL, når de opretter forbindelse til serveren. Denne bruger skal altid interagere med serveren via en privat kanal. Dette er meget vigtigt, fordi du skal sørge for, at alle dine klienter interagerer med din server på en meget sikker og privat måde.

For at gøre dette skal du blot gøre følgende eksempel:

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)

Sørg for, at når du opretter forbindelse til din klient/applikationsvært, skal du kopiere det certifikat, du har genereret baseret på de foregående trin.

Bekræftelse af din forbindelse

At teste din forbindelse, om den er krypteret eller ej, er meget vigtig for at fastslå status. For at gøre det kan du udføre følgende kommando nedenfor:

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

Alternativt tilføjede OpenSSL version 1.1.1 understøttelse af -starttls mysql . Der er en tilgængelig statisk kompileret openssl binær, som du kan få her https://testssl.sh/openssl-1.0.2k-dev-chacha.pm.ipv6.Linux+FreeBSD.tar.gz (eller check denne præsentation i PDF-format) . Så kan du udføre følgende kommando nedenfor:

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

Eksempelresultatet ville være som nedenfor:

$ 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 for hele din databaseinfrastrukturFind ud af, hvad der ellers er nyt i ClusterControlInstaller ClusterControl GRATIS

Kryptering af MariaDB-data:At-Rest

Krypterede data, der er lagret fysisk inde i dit hardwarelager (dvs. i hvile), giver mere stabilitet og beskyttelse mod et databrud. Hvis en ondsindet angriber kan logge ind på din MariaDB-database, så kan de læse dataene i almindelig tekst. I lighed med at bruge en strengkommando i Linux, vil du nemt kunne hente dataene fra databasen. Desuden tilføjer det mere fare, hvis angriberen har en avanceret forståelse af tablespacets filformat.

Encryption at-rest er en ekstra beskyttelse, men det er ikke en erstatning for en god firewall, stærke adgangskoder, korrekte brugertilladelser og in-transit kryptering mellem klienten og serveren.

MariaDBs understøttelse af kryptering på tabeller og tablespaces blev tilføjet i version 10.1.3. Når dine tabeller er krypteret, er dine data næsten umulige for nogen at stjæle. Denne form for kryptering gør det også muligt for din organisation at overholde offentlige regler som f.eks. GPDR.,

Når du har aktiveret data-at-rest-kryptering i MariaDB, vil tabeller, der er defineret med ENCRYPTED=YES eller med innodb_encrypt_tables=ON, få dine lagrede data krypteret. Det dekrypteres kun, når det tilgås via MariaDBs database, ellers er dataene ulæselige.

Hvis du f.eks. læser en data, der er ukrypteret, vil den vise 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 krypterede data vil dit tablespace ikke være læsbart ligesom eksemplet nedenfor:

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

Det er også bemærkelsesværdigt, at MariaDB's Data-At-Rest-kryptering tilføjer en datastørrelsesoverhead på omkring 3-5%. MariaDB-kryptering er også fuldt understøttet, når du bruger XtraDB- og InnoDB-lagringsmotorerne. Kryptering understøttes også for Aria-lagringsmotoren, men kun for tabeller oprettet med ROW_FORMAT=PAGE (standard) og for den binære log (replikeringslog). MariaDB tillader endda brugeren fleksibelt i, hvad der skal krypteres. I XtraDB eller InnoDB kan man vælge at kryptere:

  • alt — alle tablespaces (med alle tabeller)
  • individuelle tabeller
  • alt, undtagen individuelle tabeller

Derudover kan man vælge at kryptere XtraDB/InnoDB logfiler (hvilket anbefales).

MariaDB har sine begrænsninger. Galera Cluster gcache, for eksempel, er ikke krypteret, men det er planlagt som en del af MariaDB 10.4-versionen. Du kan finde en komplet liste over begrænsninger her.

Sådan opsætter og konfigurerer du MariaDB til Data-At-Rest-kryptering

  1. Generer en tilfældig krypteringsnøgle ved hjælp af openssl rand-kommandoen. 
    $ mkdir -p /etc/mysql/encryption
$ for i in {1..5}; do openssl rand -hex 32 >> /etc/mysql/encryption/keyfile;  done;
    Åbn og rediger filen /etc/mysql/encryption/keyfile og tilføj nøgle-id'erne, som dette vil være reference til, når der oprettes krypterede tabeller, da det er krypteringsnøgle-id. Se ENCRYPTION_KEY_ID for flere detaljer. Følgende format bør derfor være som følger:
    <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. Lad os oprette eller generere en tilfældig adgangskode ved hjælp af den lignende kommando fra trin 1:
    $ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key
  3. Før du fortsætter til næste trin, er det vigtigt at være opmærksom på følgende detaljer om kryptering af nøglefilen:
    • Den eneste algoritme, som MariaDB i øjeblikket understøtter til at kryptere nøglefilen, er CBC-tilstand (Cipher Block Chaining) i Advanced Encryption Standard (AES).
    • Krypteringsnøglestørrelsen kan være 128-bit, 192-bit eller 256-bit.
    • Krypteringsnøglen er oprettet ud fra SHA-1-hashen til krypteringsadgangskoden.
    • Krypteringsadgangskoden har en maksimal længde på 256 tegn.
    Nu, for at kryptere nøglefilen ved hjælp af openssl enc-kommandoen, skal du køre følgende kommando nedenfor:
    $ 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. Tilføj følgende variabler i din MySQL-konfigurationsfil (dvs. /etc/my.cnf på RHEL-baseret Linux OS eller /etc/mysql/my.cnf i Debian/Ubuntu Linux-baseret 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. Genstart MariaDB Server nu 
    $ systemctl start mariadb

Bekræft og test krypteringen

For at verificere og teste krypteringen skal du blot oprette en prøvetabel. Opret f.eks. tabellen ved at udføre følgende SQL-sætninger nedenfor:

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)

Lad os derefter tilføje nogle data til tabellerne:

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

For at kontrollere og se, hvilke tabeller der er krypteret, skal du blot køre følgende SELECT forespørgsel nedenfor:

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)

Oprettelse af InnoDB-tabellen behøver ikke at angive nøgleordet ENCRYPTED=YES. Den oprettes automatisk, som vi har angivet i konfigurationsfilen til at have innodb_encrypt_tables =TIL.

Hvis du vil angive krypterings-id'et for den tabel, der skal bruges, kan du også gøre følgende:

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

ENCRYPTION_KEY_ID blev taget fra krypteringsnøglefilen, som vi genererede tidligere.

Derudover, hvis du ønsker mere test gennem shell, kan du bruge strengene kommando, jeg viste dig tidligere.

Yderligere oplysninger om MariaDB-kryptering

Hvis din MariaDB-instans ikke skal indeholde nogen ukrypterede tabeller, skal du blot opsætte variablen i din my.cnf-konfigurationsfil i [mysqld] afsnit som følger:

innodb_encrypt_tables = FORCE.

Til binlog-kryptering skal du blot tilføje følgende

encrypt_binlog = 1

InnoDBs redo-log er ikke krypteret som standard. For at kryptere den skal du blot tilføje variablen nedenfor efter [mysqld]-sektionen,

innodb-encrypt-log

Hvis du har brug for kryptering til dine midlertidige tabeller og midlertidige filer på disken, kan du tilføje følgende:

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

  1. Forår 2011 PostgreSQL-konferencer, USA/Canada

  2. Hvordan kan jeg tælle antallet af rækker, som en MySQL-forespørgsel returnerede?

  3. Denormalisering:Hvornår, hvorfor og hvordan

  4. Sådan sikrer du, at databaser sikkerhedskopieres regelmæssigt