MariaDB Server Database Encryption Basics

Kryptering er en af de vigtigste sikkerhedsfunktioner for at holde dine data så sikre som muligt. Afhængigt af de data, du håndterer, er det ikke altid et must, men du bør i det mindste betragte det som en sikkerhedsforbedring i din organisation alligevel, og det anbefales faktisk at undgå datatyveri eller uautoriseret adgang.

I denne blog vil vi beskrive to grundlæggende typer kryptering, og hvordan man konfigurerer den på en MariaDB-server.

Hvad er datakryptering?

Der er to grundlæggende typer datakryptering:i hvile og under transport. Lad os se, hvad de betyder.

Data-at-rest-kryptering

Data, der er gemt i et system, er kendt som data-at-rest. Krypteringen af disse data består i at bruge en algoritme til at konvertere tekst eller kode til ulæselig. Du skal have en krypteringsnøgle for at afkode de krypterede data.

Kryptering af en hel database bør ske med forsigtighed, da det kan resultere i en alvorlig indvirkning på ydeevnen. Det er derfor klogt kun at kryptere individuelle felter eller tabeller.

Kryptering af data-at-rest beskytter dataene mod fysisk tyveri af harddiske eller uautoriseret fillageradgang. Denne kryptering overholder også datasikkerhedsforskrifter, især hvis der er lagret økonomiske eller sundhedsmæssige data på filsystemet.

Data-in-Transit-kryptering

Data, der overføres eller flyttes rundt mellem transaktioner, er kendt som data-in-transit. Dataene, der bevæger sig mellem serveren og klienten, mens du browser på websider, er et godt eksempel på denne form for data.

Da den altid er på farten, skal den beskyttes med korrekt kryptering for at undgå tyveri eller ændring af data, før den når sin destination.

Den ideelle situation til at beskytte data under transport er at få dataene krypteret, før de flytter sig og dekrypteres først, når de når den endelige destination.

MariaDB Data-at-Rest-kryptering

Krypteringen af tabeller og tablespaces blev tilføjet i MariaDB fra version 10.1, og den understøtter kryptering til XtraDB-, InnoDB- og Aria-lagringsmotorer og også til binære logfiler.

Du kan vælge forskellige måder at kryptere på:

Alle tabeller
Individuelle tabeller
Alt, undtagen individuelle tabeller

Ifølge dokumentationen har brug af kryptering en overhead på ca. 3-5 %, så det er vigtigt at have et testmiljø for at understrege det og se, hvordan det reagerer, for at undgå problemer i produktionen.

Sådan konfigureres Data-at-Rest-kryptering på MariaDB

Lad os tjekke en eksisterende "by"-tabel i en MariaDB-database:

$ strings city.ibd |headinfimumsupremuminfimumsupremum3ABW3KHMinfimumsupremumKabul AFGKabolQandahar AFGQandahar

Som du kan se, kan du læse data derfra uden problemer med f.eks. Strings Linux-kommandoen. Lad os nu se, hvordan man krypterer det.

Generer en krypteringsnøgle ved hjælp af openssl rand-kommandoen:

$ mkdir -p /etc/mysql/encryption$ for i i {1..4}; gør openssl rand -hex 32>> /etc/mysql/encryption/keyfile; udført;

Rediger den genererede fil /etc/mysql/encryption/keyfile og tilføj nøgle-id'erne, som der refereres til, når der oprettes krypterede tabeller. Formatet skal være som følger:

;;

Du kan redigere den ved at bruge sed linux-kommandoen på denne måde:

$ for i i {1..4}; do sed -i -e "$i s/^/$i;/" nøglefil; færdig

Så filen skulle være sådan her:

$ cat /etc/mysql/encryption/keyfile1;f237fe72e16206c0b0f6f43c3b3f4accc242564d77f5fe17bb621de388c193af2;0c0819a10fb366a5ea657a71759ee6a950ae8f25a5ba7400a91f59b63683edc53;ac9ea3a839596dbf52492d9ab6b180bf11a35f44995b2ed752c370d920a101694;72afc936e16a8df05cf994c7902e588de0d11ca7301f9715d00930aa7d5ff8ab

Generer nu en tilfældig adgangskode ved hjælp af den lignende openssl-kommando, som du så tidligere:

$ openssl rand -hex 128> /etc/mysql/encryption/keyfile.key

Før du fortsætter til næste trin, er det vigtigt at kende følgende detaljer om kryptering af nøglefilen:

Den eneste algoritme, som MariaDB i øjeblikket understøtter til at kryptere nøglefilen, er CBC-tilstanden (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:

$ 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

Til sidst skal du tilføje følgende parametre i din my.cnf-konfigurationsfil (placeret i /etc/ på RedHat-baseret OS eller /etc/mysql/ på Debian-baseret OS):

[mysqld]…################### DATABASEKRYPTERING ################# ##plugin_load_add =file_key_managementfile_key_management_filename =/etc/mysql/encryption/keyfile.encfile_key_management_filekey =FILE:/etc/mysql/encryption/keyfile.keyfile_key_management_encryption_algorithm =aes_cbcencrypt_binlog =1innodb_encrypt_tables =ONinnodb_encrypt_log =ONinnodb_encryption_threads =4innodb_encryption_rotate_key_age =0 …

Og genstart MariaDB-tjenesten for at tage ændringerne:

$ systemctl genstart mariadb

På dette tidspunkt er alt klar til at bruge krypteringsfunktionen. Lad os kryptere den samme tabel, som vi viste tidligere, "by". Til dette skal du bruge ALTER TABLE-sætningen, der indstiller parameteren ENCRYPTED i YES:

MariaDB [verden]> ALTER TABLE by ENCRYPTED=JA;Forespørgsel OK, 0 rækker påvirket (0,483 sek.)Records:0 Dubletter:0 Advarsler:0

Nu, hvis du prøver at få adgang til tabellen direkte fra filsystemet, vil du se noget som dette:

$ strings city.ibd |headPU%O!ybN)b9,{9WB4T3uG:?oiN,35sz8g)Qo(oq_A1k=-w

Som du kan se, er tabellen ulæselig. Du kan også angive krypteringsnøgle-id'et ved at tilføje parameteren ENCRYPTION_KEY_ID = i MySQL-kommandoen, hvor er ID-nummeret fra den tidligere oprettede nøglefil.

Nye tabeller vil blive krypteret som standard, da vi indstiller parameteren innodb_encrypt_tables til ON i my.cnf-konfigurationsfilen.

MariaDB Data-in-Transit-kryptering

MariaDB giver dig mulighed for at kryptere data-in-transit mellem serveren og klienter ved hjælp af Transport Layer Security-protokollen (TLS), tidligere kendt som Secure Socket Layer eller SSL.

Først og fremmest skal du sikre dig, at din MariaDB-server er kompileret med TLS-understøttelse. Du kan bekræfte dette ved at køre følgende SHOW GLOBAL VARIABLES-sætning:

MariaDB [(ingen)]> VIS GLOBALE VARIABLER SOM 'version_ssl_library';+--------------------------+------ ----------------------+| Variabelnavn | Værdi |+----------------------+------------------------ ---+| version_ssl_bibliotek | OpenSSL 1.1.1 11. sep. 2018 |+--------------------------+------------------------ ----------+1 række i sæt (0,001 sek.)

Og tjek, om det ikke er i brug i øjeblikket ved hjælp af SHOW VARIABLES-sætningen:

MariaDB [(ingen)]> VIS VARIABLER SOM '%ssl%';+---------------------+----- ----------------------------+| Variabelnavn | Værdi |+----------------------+------------------------ ---+| have_openssl | JA || have_ssl | DEAKTIVERET || ssl_ca | || ssl_capath | || ssl_cert | || ssl_cipher | || ssl_crl | || ssl_crlpath | || ssl_key | || version_ssl_bibliotek | OpenSSL 1.1.1 11. sep. 2018 |+--------------------------+------------------------ ----------+10 rækker i sæt (0,001 sek.)

Du kan også bekræfte SSL-statussen ved at bruge status MariaDB-kommandoen:

MariaDB [(ingen)]> status--------mysql Ver 15.1 Distrib 10.4.13-MariaDB, til debian-linux-gnu (x86_64) ved hjælp af readline 5.2 Forbindelses-id:22Aktuel database:Nuværende bruger:[email protected]:Ikke i brugAktuel personsøger:stdoutBrug af outfile:''Bruger afgrænser:;Server:MariaDBServer version:10.4.13-MariaDB-1:10.4.13-maria~bionic log mariadb.org binær distribution Protokolversion:10Forbindelse:Localhost via UNIX socketServer tegnsæt:latin1Db tegnsæt:latin1Klient tegnsæt:utf8Conn. tegnsæt:utf8UNIX socket:/var/lib/mysql/mysql.sockUptime:4 timer 28 min 25 secTråde:11 Spørgsmål:111668 Langsomme forespørgsler:0 Åbner:92 Skylletabeller:1 Åbne tabeller:85 forespørgsler pr. sekund:6. ------------

Sådan konfigureres data-in-transit-kryptering på MariaDB

Lad os oprette certifikatbiblioteket for at gemme alle certifikaterne:

$ mkdir -p /etc/mysql/certs

Lad os nu generere de CA-certifikater, der vil blive konfigureret til at kryptere forbindelsen:

$ openssl genrsa 2048> ca-key.pem$ openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.pem

Denne sidste kommando vil bede dig om at udfylde følgende oplysninger:

Landsnavn (2 bogstavskode) [AU]:Statens eller provinsens navn (fuldt navn) [En eller anden stat]:Lokalitetsnavn (f.eks. by) []:Organisationsnavn (f.eks. virksomhed) [Internet Widgits Pty Ltd]:Organisationsenhedsnavn (f.eks. sektion) []:Fælles navn (f.eks. server FQDN eller DIT navn) []:E-mail-adresse []:

Nu skal du generere servercertifikaterne:

$ openssl req -newkey rsa:2048 -nodes -keyout server-key.pem -out server-req.pem

Denne kommando vil bede dig om at udfylde de samme oplysninger som før plus en valgfri certifikatadgangskode.

$ 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

Og endelig skal du generere klientcertifikaterne:

$ openssl req -newkey rsa:2048 -nodes -keyout client-key.pem -out client-req.pem

Dette vil også bede dig om at udfylde oplysningerne og en valgfri certifikatadgangskode.

$ openssl rsa -in client-key.pem -out client-key.pem$ openssl x509 -req -in client-req.pem -CA ca-cert.pem -CAkey ca-key.pem - set_serial 01 -out client-cert.pem

Sørg for, at du bruger et andet fællesnavn på hvert certifikat, ellers virker det ikke, og du vil modtage en besked som:

FEJL 2026 (HY000):SSL-forbindelsesfejl:selvsigneret certifikat

På dette tidspunkt vil du have noget som dette:

$ ls /etc/mysql/certs/ca-cert.pem ca-key.pem client-cert.pem client-key.pem client-req.pem server-cert.pem server-key.pem server-req.pem

Og du kan validere certifikaterne ved at bruge følgende kommando:

$ openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pemserver-cert.pem:OKclient-cert.pem:OK

Så lad os nu konfigurere det i my.cnf-konfigurationsfilen (placeret i /etc/ på RedHat-baseret OS eller /etc/mysql/ på Debian-baseret OS):

[mysqld]ssl_ca=/etc/mysql/certs/ca-cert.pemssl_cert=/etc/mysql/certs/server-cert.pemssl_key=/etc/mysql/certs/server-key.pem[ client-mariadb]ssl_ca =/etc/mysql/certs/ca-cert.pemssl_cert=/etc/mysql/certs/client-cert.pemssl_key=/etc/mysql/certs/client-key.pem

Sørg for, at du tilføjer det under den tilsvarende sektion (mysqld og client-mariadb).

Skift certifikatets ejer og genstart databasetjenesten:

$ chown mysql.mysql /etc/mysql/certs/$ systemctl genstart mariadb

Hvis du derefter tager et kig på VIS VARIABLER-outputtet, skulle du have dette:

MariaDB [(ingen)]> VIS VARIABLER SOM '%ssl%';+---------------------+----- ----------------------------+| Variabelnavn | Værdi |+----------------------+------------------------ ----------+| have_openssl | JA || have_ssl | JA || ssl_ca | /etc/mysql/certs/ca-cert.pem || ssl_capath | || ssl_cert | /etc/mysql/certs/server-cert.pem || ssl_cipher | || ssl_crl | || ssl_crlpath | || ssl_key | /etc/mysql/certs/server-key.pem || version_ssl_bibliotek | OpenSSL 1.1.1 11. sep. 2018 |+--------------------------+------------------------ ---------------+10 rækker i sæt (0,001 sek.)

Lad os nu oprette en bruger med parameteren REQUIRE SSL for at bruge den:

MariaDB [(ingen)]> TILDEL ALLE PRIVILEGIER PÅ *.* TIL 's9s'@'%' IDENTIFICERET AF 'root123' KRÆVER SSL;Forespørgsel OK, 0 rækker påvirket (0,005 sek.)

Hvis du bruger denne bruger til at få adgang til databasen og kontrollere statuskommandoen, vil du se SSL i brug:

MariaDB [(ingen)]> status--------mysql Ver 15.1 Distrib 10.4.13-MariaDB, til debian-linux-gnu (x86_64) ved hjælp af readline 5.2 Forbindelses-id:15Aktuel database:Nuværende bruger:[email protected]:Cipher i brug er TLS_AES_256_GCM_SHA384Aktuel personsøger:stdoutUsing outfile:''Bruger afgrænser:;Server:MariaDBServer version:10.10.4a.4.13-MariaDB bionic-log mariadb.org binær distribution Protokolversion:10Forbindelse:127.0.0.1 via TCP/IPServer tegnsæt:latin1Db tegnsæt:latin1Klient tegnsæt:utf8Conn. tegnsæt:utf8TCP-port:3306Opetid:16 sek. Tråde:11 Spørgsmål:136 Langsomme forespørgsler:0 Åbner:17 Skylletabeller:1 Åbne tabeller:11 Forespørgsler pr. sekund gns.:8.500--------------

 Sådan aktiverer du SSL-kryptering med ClusterControl
 En anden måde, og endda en nemmere måde, at aktivere SSL på din MariaDB-database er ved at bruge ClusterControl. Vi antager, at du har ClusterControl installeret, og du administrerer din MariaDB-database ved hjælp af den, så gå til ClusterControl -> Vælg din MariaDB-klynge -> Sikkerhed -> SSL-kryptering -> Aktiver.
 Og det er det, du vil have din SSL-kryptering aktiveret i din MariaDB-database uden nogen manuel opgave.
 Begrænsninger af kryptering i hvile i MariaDB
 Der er nogle begrænsninger relateret til MariaDB at-rest-kryptering, der skal tages i betragtning:
  Metadata (f.eks. .frm-filer) og data sendt til klienten er ikke krypteret.
 Kun MariaDB-serveren ved, hvordan man dekrypterer dataene, især  mysqlbinlog kan kun læse krypterede binære logfiler, når --read-from-remote-server bruges.
 Percona XtraBackup kan ikke sikkerhedskopiere forekomster, der bruger krypteret InnoDB. Mariabackup kan dog sikkerhedskopiere krypterede instanser.
 
 
 Den diskbaserede Galera gcache er ikke krypteret i fællesskabsversionen af MariaDB Server, men denne fil er krypteret i MariaDB Enterprise Server 10.4.
 Revisionspluginnet kan ikke oprette krypteret output. Send det til syslog og konfigurer beskyttelsen der i stedet.
 Filbaseret generel forespørgselslog og langsom forespørgselslog kan ikke krypteres.
 Aria-loggen er ikke krypteret. Dette påvirker kun ikke-midlertidige Aria-tabeller.
 MariaDB-fejlloggen er ikke krypteret. Fejlloggen kan indeholde forespørgselstekst og data i nogle tilfælde, herunder nedbrud, påstandsfejl og tilfælde, hvor InnoDB/XtraDB skriver monitoroutput til loggen for at hjælpe med fejlretning. Det kan også sendes til syslog, hvis det er nødvendigt.
 
 Konklusion
 Beskyttelse af data-i-transit er lige så vigtigt som at beskytte data-at-rest, og selvom det ikke er et must i din organisation, bør du overveje at anvende det, da det kan hjælpe dig med at undgå data tyveri eller uautoriseret adgang.
 
 MariaDB har en ret nem måde at implementere det på ved at følge trinene nævnt tidligere, men det er helt sikkert endnu nemmere at bruge ClusterControl.