sql >> Database >  >> RDS >> MariaDB

De verschillende manieren verkennen om uw MariaDB-gegevens te versleutelen

Het versleutelen van uw MariaDB-database, of deze nu onderweg of in rust is, is een van de belangrijkste dingen die een organisatie moet overwegen als u waarde hecht aan uw gegevens.

Organisaties die zich bezighouden met financiële transacties, medische dossiers, vertrouwelijke informatie of zelfs persoonlijke gegevens, moeten dit soort gegevensbescherming eisen. Fundamenteel zal databaseversleuteling uw leesbare gegevens omzetten in een formaat dat onleesbaar is (of op zijn minst moeilijk te ontsleutelen) door onbevoegde gebruikers.

Het versleutelen van uw gegevens voorkomt misbruik of kwade bedoelingen door hackers of onbevoegd personeel dat uw bedrijf zou kunnen schaden. Niet-versleutelde gegevens zijn vatbaar voor aanvallen door hackers die schadelijke gegevens injecteren die uw infrastructuur kunnen beschadigen of informatie kunnen stelen. Quartz heeft onlangs een artikel uitgebracht over de grootste inbreuk die in deze richting heeft plaatsgevonden en het is alarmerend dat er de afgelopen twee decennia gegevens zijn gestolen van miljarden accounts.

Gerelateerde bronnen Uw MySQL- en MariaDB-back-ups versleutelen Databasebeveiliging - back-upversleuteling tijdens transport en in rust bijgewerkt:word een ClusterControl DBA - SSL-sleutelbeheer en versleuteling van MySQL-gegevens in transit

In deze blog bespreken we verschillende manieren om uw MariaDB-gegevens te versleutelen, of deze nu in rust en onderweg zijn. We zullen u een basiskennis geven van encryptie en hoe u deze kunt gebruiken, zodat u deze benaderingen kunt gebruiken om uw gegevens veilig te houden.

MariaDB-gegevens versleutelen:tijdens het transport

MariaDB gebruikt standaard geen codering tijdens gegevensoverdracht via het netwerk van server naar client. Het gebruik van de standaardconfiguratie kan er echter toe leiden dat een potentiële hacker een onbeveiligd/niet-versleuteld kanaal afluistert. Als u in een geïsoleerde of sterk beveiligde omgeving werkt, kan deze standaardstatus acceptabel zijn. Dit is echter niet ideaal wanneer uw client en netwerk zich op een ander netwerk bevinden, omdat het uw database voorbereidt op een mogelijke 'man-in-the-middle'-aanval.

Om deze aanvallen te voorkomen, kunt u met MariaDB gegevens tijdens het transport tussen de server en clients coderen met behulp van het Transport Layer Security (TLS) -protocol (voorheen bekend als Secure Socket Layer of SSL). Om te beginnen, moet u ervoor zorgen dat uw MariaDB-server is gecompileerd met TLS-ondersteuning. U kunt dit verifiëren door de instructie SHOW GLOBAL VARIABLES uit te voeren, zoals hieronder weergegeven:

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)

U bent misschien in de war over hoe SSL en TSL verschillen. Documentatie kan de term SSL gebruiken en variabelen voor configuratie gebruikt ook ssl_* als prefix, maar MariaDB ondersteunt alleen zijn veilige opvolgers en niet langer de oudere SSL-versies. Mogelijk moet u de juiste versies van MariaDB identificeren en gebruiken die de juiste ondersteuning vereisen van de TLS-versies die u moet gebruiken. PCI DSS v3.2 raadt bijvoorbeeld aan om een ​​minimale protocolversie van TLSv1.2 te gebruiken die oude versies van MariaDB ondersteunen. Met TLS 1.3 is echter OpenSSL 1.1.1 vereist, het is sneller vanwege een efficiëntere handshake tussen de twee systemen die communiceren en dit wordt ondersteund sinds MariaDB 10.2.16 en MariaDB 10.3.8.

Om de versleutelingen te gebruiken die beschikbaar zijn voor een specifieke TLS-versie, kunt u deze definiëren met de --ssl-cijfer in de mysqld commando of ssl-cijfer variabele in het configuratiebestand. Houd er rekening mee dat TLSv1.3-coderingen niet kunnen worden uitgesloten bij gebruik van OpenSSL, zelfs niet door de systeemvariabele ssl_cipher te gebruiken.

Configuratieparameters om gegevens tijdens het transport te versleutelen

Om uw gegevens tijdens het transport te coderen, kunt u de onderstaande reeks opdrachten uitvoeren:

Een CA-certificaat genereren

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

Een servercertificaat genereren

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

Een klantcertificaat genereren

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

Houd er rekening mee dat uw algemene naam (CN) in de -subj argument moet uniek zijn voor uw CA-, server- en clientcertificaten die u genereert. Technisch gezien kunnen CA en Server dezelfde CN hebben, maar het is het beste om het een unieke identificatie voor deze drie te maken. Anders krijg je een foutmelding als volgt:

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

Oké, certificaten en sleutels zijn aanwezig. U moet het pad specificeren met behulp van de ssl_*-variabelen in uw MySQL-configuratiebestand (bijv. /etc/my.cnf voor op RHEL gebaseerd besturingssysteem of /etc/mysql/my.cnf voor Debian/Ubuntu OS). Zie de voorbeeldconfiguratie hieronder:

[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

Natuurlijk moet je het juiste pad specificeren waar je je certificaat en sleutels hebt geplaatst.

Plaats deze parameters dan onder de [client-mariadb] gedeelte van uw configuratiebestand als zodanig hieronder:

[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

Zoals eerder vermeld, kunt u specificeren welk type codering uw SSL/TLS-configuratie kan gebruiken. Dit kan gedaan worden door de configuratie hieronder op te geven:

[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

Of u kunt de volgende configuratie als zodanig hieronder gebruiken:

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.

De laatste regel geeft het equivalent van dit commando aan:

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

Dit sluit zwakke cijfers uit en die cijfers in de prefixvorm zoals DHE-DSS-AES256-GCM-SHA384 cijfer bijvoorbeeld.

Uw certificaat genereren met ClusterControl

Als alternatief kunt u ClusterControl gebruiken om de certificaten en sleutels voor u te genereren. Om dit te doen, kunt u het volgende doen, zoals hieronder te zien is:

  1. Selecteer uw MariaDB-cluster en ga vervolgens naar de Beveiliging en selecteer SSL-codering. In mijn voorbeeld hieronder is dit een MariaDB Galera-cluster:
  2. Selecteer de SSL-codering en schakel deze in. U kunt een nieuw certificaat maken of een bestaand certificaat kiezen. Voor dit voorbeeld kies ik de optie "Certificaat maken":
  3. De laatste stap is het configureren van de vervaldagen voor uw certificaat. Zie onder: Als u op "Restart Nodes" klikt, voert ClusterControl een rollende herstart uit. Let op, als u MariaDB 10.4 gebruikt (die momenteel in de RC-versie staat), kunt u SSL gebruiken zonder uw MariaDB-server opnieuw te starten. Gebruik gewoon de FLUSH SSL-opdracht, een nieuwe functie die is toegevoegd in MariaDB 10.4-versie.

Een andere manier om met uw TLS/SSL-certificaten/sleutels om te gaan, kunt u ook gebruiken met het Sleutelbeheer onder ClusterControl. Bekijk deze blog voor meer informatie over hoe je dit kunt doen.

Maak uw TLS/SSL MariaDB-gebruiker

Voor het geval je dacht dat je klaar was, dat is niet zo. U moet ervoor zorgen dat uw gebruikers SSL moeten gebruiken wanneer ze verbinding maken met de server. Deze gebruiker moet altijd communiceren met de server via een privékanaal. Dit is erg belangrijk omdat u ervoor moet zorgen dat al uw klanten op een zeer veilige en persoonlijke manier met uw server communiceren.

Om dit te doen, doet u het volgende voorbeeld:

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)

Zorg ervoor dat u bij het verbinden met uw client/toepassingshost het certificaat kopieert dat u hebt gegenereerd op basis van de vorige stappen.

Uw verbinding verifiëren

Het testen van uw verbinding of deze al dan niet versleuteld is, is erg belangrijk om de status te bepalen. Om dat te doen, kunt u de volgende opdracht hieronder uitvoeren:

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

Als alternatief heeft OpenSSL versie 1.1.1 ondersteuning toegevoegd voor -starttls mysql . Er is een statisch gecompileerde openssl-binary beschikbaar die u hier kunt krijgen https://testssl.sh/openssl-1.0.2k-dev-chacha.pm.ipv6.Linux+FreeBSD.tar.gz (of bekijk deze presentatie in PDF-formaat) . Dan kunt u de volgende opdracht hieronder uitvoeren:

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

Het voorbeeldresultaat ziet er als volgt uit:

$ 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 voor uw gehele database-infrastructuurOntdek wat er nog meer nieuw is in ClusterControlInstalleer ClusterControl GRATIS

MariaDB-gegevens versleutelen:in rust

Versleutelde gegevens die fysiek in uw hardware-opslag (d.w.z. in rust) zijn opgeslagen, bieden meer stabiliteit en bescherming tegen een datalek. Als een kwaadwillende aanvaller kan inloggen op uw MariaDB-database, kunnen ze de gegevens in platte tekst lezen. Net als bij het gebruik van een strings-opdracht in Linux, zou je de gegevens gemakkelijk uit de database kunnen halen. Bovendien voegt het meer gevaar toe als de aanvaller een geavanceerd begrip heeft van het bestandsformaat van de tablespace.

Encryptie in rust is een extra bescherming, maar het is geen vervanging voor een goede firewall, sterke wachtwoorden, correcte gebruikersrechten en codering tijdens het transport tussen de client en de server.

MariaDB's ondersteuning voor encryptie op tabellen en tablespaces is toegevoegd in versie 10.1.3. Omdat uw tabellen versleuteld zijn, is het bijna onmogelijk voor iemand om uw gegevens te stelen. Met dit type codering kan uw organisatie ook voldoen aan overheidsvoorschriften zoals GPDR.,

Zodra u data-at-rest-codering in MariaDB hebt ingeschakeld, zullen tabellen die zijn gedefinieerd met ENCRYPTED=YES of met innodb_encrypt_tables=ON, uw opgeslagen gegevens versleutelen. Het wordt alleen gedecodeerd wanneer het wordt geopend via MariaDB's database, anders zijn de gegevens onleesbaar.

Als u bijvoorbeeld gegevens leest die niet versleuteld zijn, ziet u dit als volgt:

$ 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

maar met versleutelde data is je tablespace niet leesbaar zoals in het onderstaande voorbeeld:

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

Het is ook opmerkelijk dat MariaDB's Data-At-Rest-codering een overhead voor gegevensomvang van ongeveer 3-5% toevoegt. MariaDB-codering wordt ook volledig ondersteund bij gebruik van de XtraDB- en InnoDB-opslagengines. Versleuteling wordt ook ondersteund voor de Aria-opslagengine, maar alleen voor tabellen die zijn gemaakt met ROW_FORMAT=PAGE (standaard) en voor het binaire logboek (replicatielogboek). MariaDB stelt de gebruiker zelfs flexibel in staat wat te versleutelen. In XtraDB of InnoDB kan men ervoor kiezen om te versleutelen:

  • alles — alle tablespaces (met alle tabellen)
  • individuele tafels
  • alles, behalve individuele tafels

Bovendien kan men ervoor kiezen om XtraDB/InnoDB-logbestanden te versleutelen (wat wordt aanbevolen).

MariaDB heeft zijn beperkingen. Galera Cluster gcache is bijvoorbeeld niet versleuteld, maar is gepland als onderdeel van de MariaDB 10.4-versie. Een volledige lijst met beperkingen vind je hier.

Hoe MariaDB in te stellen en te configureren voor data-at-rest-codering

  1. Genereer willekeurige coderingssleutels met de opdracht openssl rand. 
    $ mkdir -p /etc/mysql/encryption
$ for i in {1..5}; do openssl rand -hex 32 >> /etc/mysql/encryption/keyfile;  done;
    Open en bewerk nu het bestand /etc/mysql/encryption/keyfile en voeg de sleutel-ID's toe waarnaar dit zal verwijzen bij het maken van versleutelde tabellen, aangezien het de coderingssleutel-ID is. Zie ENCRYPTION_KEY_ID voor meer details. Daarom moet het volgende formaat als volgt zijn:
    <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. Laten we een willekeurig wachtwoord maken of genereren met de vergelijkbare opdracht uit stap 1:
    $ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key
  3. Voordat u doorgaat naar de volgende stap, is het belangrijk om kennis te nemen van de volgende details over het versleutelen van het sleutelbestand:
    • Het enige algoritme dat MariaDB momenteel ondersteunt om het sleutelbestand te versleutelen, is de Cipher Block Chaining (CBC)-modus van Advanced Encryption Standard (AES).
    • De grootte van de coderingssleutel kan 128-bits, 192-bits of 256-bits zijn.
    • De coderingssleutel wordt gemaakt op basis van de SHA-1-hash van het coderingswachtwoord.
    • Het coderingswachtwoord heeft een maximale lengte van 256 tekens.
    Om het sleutelbestand nu te versleutelen met de opdracht openssl enc, voert u de volgende opdracht hieronder uit:
    $ 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. Voeg de volgende variabelen toe aan uw MySQL-configuratiebestand (d.w.z. /etc/my.cnf op op RHEL gebaseerd Linux-besturingssysteem of /etc/mysql/my.cnf in op Debian/Ubuntu op Linux gebaseerd besturingssysteem) 
    [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. Herstart MariaDB Server nu 
    $ systemctl start mariadb

Controleer en test de versleuteling

Maak een voorbeeldtabel om de codering te verifiëren en te testen. Maak bijvoorbeeld de tabel door de volgende SQL-instructies hieronder uit te voeren:

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)

Laten we dan wat gegevens aan de tabellen toevoegen:

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

Om te controleren en te zien welke tabellen versleuteld zijn, voert u de volgende opdracht uit SELECT onderstaande vraag:

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)

Voor het maken van de InnoDB-tabel hoeft u het ENCRYPTED=YES-sleutelwoord niet op te geven. Het wordt automatisch gemaakt zoals we in het configuratiebestand hebben gespecificeerd om innodb_encrypt_tables =ON te hebben.

Als u het encryptie-ID van de te gebruiken tabel wilt specificeren, kunt u ook het volgende doen:

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

De ENCRYPTION_KEY_ID is afkomstig uit het coderingssleutelbestand dat we eerder hebben gegenereerd.

Bovendien, als u meer testen via shell wilt, kunt u de strings . gebruiken commando dat ik je eerder liet zien.

Aanvullende informatie over MariaDB-codering

Als uw MariaDB-instantie geen onversleutelde tabellen mag bevatten, stelt u gewoon de variabele in uw my.cnf-configuratiebestand in de [mysqld] in sectie als volgt:

innodb_encrypt_tables = FORCE.

Voeg voor binlog-codering het volgende toe

encrypt_binlog = 1

De redo-log van InnoDB is standaard niet versleuteld. Om het te versleutelen, voegt u de onderstaande variabele toe na de sectie [mysqld],

innodb-encrypt-log

Als u codering nodig heeft voor uw tijdelijke tabellen en tijdelijke bestanden op de schijf, kunt u het volgende toevoegen:

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

  1. Geavanceerde partitie-matching voor partitiegewijze join

  2. Een databaseback-up herstellen in OpenCart 1.5

  3. juiste syntaxis om te gebruiken in de buurt van '?'

  4. Hoe kan ik mijn ad-hoc SQL testen met parameters in het Postgres-queryvenster?