Verschlësselung an MySQL: Keystore

An der Erwaardung vum Start vun enger neier Aschreiwung fir de Cours "Datebank" Mir hunn eng Iwwersetzung vun engem nëtzlechen Artikel fir Iech virbereet.

Verschlësselung an MySQL: Keystore

Transparent Dateverschlësselung (TDE) erschéngt am Percona Server fir MySQL a MySQL fir eng laang Zäit. Awer hutt Dir schons geduecht wéi et ënner der Hood funktionnéiert a wéi en Impakt TDE op Ärem Server kann hunn? An dëser Serie vun Artikelen wäerte mir kucken wéi TDE intern funktionnéiert. Loosst eis mat Schlëssellagerung ufänken, well dëst ass erfuerderlech fir all Verschlësselung ze funktionnéieren. Da wäerte mir e méi no kucken wéi d'Verschlësselung am Percona Server fir MySQL / MySQL funktionnéiert a wéi eng zousätzlech Funktiounen Percona Server fir MySQL huet.

MySQL Schlësselring

Keyring sinn Plugins déi de Server erlaben Schlësselen an enger lokaler Datei (keyring_file) oder op engem Remote Server (wéi HashiCorp Vault) ze froen, erstellen an ze läschen. Schlëssele ginn ëmmer lokal cache fir hir Erhuelung ze beschleunegen.

Plugins kënnen an zwou Kategorien opgedeelt ginn:

  • Lokal Lagerung. Zum Beispill, eng lokal Datei (mir nennen dëst e Fichier-baséiert Schlësselring).
  • Fernlagerung. Zum Beispill, Vault Server (mir nennen dëst e Server-baséiert Schlësselring).

Dës Trennung ass wichteg, well verschidden Aarte vu Späichere sech liicht anescht behuelen, net nëmme beim Späicheren an zréckzéien vun Schlësselen, awer och wann se lafen.

Wann Dir eng Dateilagerung benotzt, beim Start, gëtt de ganzen Inhalt vun der Späichere an de Cache gelueden: Schlëssel ID, Schlëssel Benotzer, Schlësseltyp an de Schlëssel selwer.

Am Fall vun engem Server-Säit Store (wéi Vault Server), sinn nëmmen d'Schlëssel-ID an de Schlësselbenotzer beim Start gelueden, sou datt all d'Schlësselen net de Start verlangsamen. Schlëssele sinn faul gelueden. Dat ass, de Schlëssel selwer gëtt nëmme vu Vault gelueden wann et tatsächlech gebraucht gëtt. Eemol erofgeluede gëtt de Schlëssel am Gedächtnis gespäichert, sou datt et an Zukunft net iwwer TLS Verbindunge mam Vault Server zougänglech ass. Als nächst kucke mer wéi eng Informatioun am Schlësselgeschäft präsent ass.

Déi Schlësselinformatioun enthält déi folgend:

  • Schlëssel id - Schlëssel Identifizéierer, zum Beispill:
    INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
  • Schlësseltyp - Schlësseltyp baséiert op dem benotzte Verschlësselungsalgorithmus, méiglech Wäerter: "AES", "RSA" oder "DSA".
  • Schlëssel Längt - Schlëssellängt a Bytes, AES: 16, 24 oder 32, RSA 128, 256, 512 an DSA 128, 256 oder 384.
  • Benotzersäit - Besëtzer vum Schlëssel. Wann de Schlëssel System ass, zum Beispill, Master Key, dann ass dëst Feld eidel. Wann e Schlëssel mat keyring_udf erstallt gëtt, identifizéiert dëst Feld de Besëtzer vum Schlëssel.
  • de Schlëssel selwer

De Schlëssel gëtt eenzegaarteg vum Pair identifizéiert: key_id, Benotzer.

Et ginn och Differenzen am Späicheren a Läschen Schlësselen.

Dateilagerung ass méi séier. Dir mengt vläicht datt e Schlësselgeschäft einfach eng Kéier de Schlëssel vun engem Fichier schreift, awer nee, et gëtt méi lass hei. Wann ëmmer eng Dateiespäichermodifikatioun gemaach gëtt, gëtt eng Backupkopie vun all Inhalt fir d'éischt erstallt. Loosst eis soen datt d'Datei my_biggest_secrets genannt gëtt, da gëtt d'Backupkopie my_biggest_secrets.backup. Als nächst gëtt de Cache geännert (Schlëssel ginn derbäigesat oder geläscht) a wann alles erfollegräich ass, gëtt de Cache op eng Datei zréckgesat. A rare Fäll, wéi zum Beispill e Serverfehler, kënnt Dir dës Backupdatei gesinn. D'Backupdatei gëtt d'nächst Kéier geläscht wann d'Schlësselen gelueden sinn (normalerweis nodeems de Server nei gestart ass).

Wann Dir e Schlëssel an enger Serverlagerung späichert oder läscht, muss d'Späichere mam MySQL-Server verbannen mat de Kommandoen "Schécken de Schlëssel" / "Schlësselläsche froen".

Komme mer zréck op d'Server Startupgeschwindegkeet. Zousätzlech zu der Tatsaach, datt d'Startgeschwindegkeet vum Vault selwer beaflosst gëtt, ass et och d'Fro wéivill Schlësselen aus dem Vault musse beim Start erofgeholl ginn. Natierlech ass dëst besonnesch wichteg fir Serverlagerung. Beim Start iwwerpréift de Server wéi ee Schlëssel fir verschlësselte Dëscher/Tablespaces erfuerderlech ass a freet de Schlëssel aus der Späichere. Op engem "propperen" Server mat Master Key Verschlësselung muss et ee Master Key sinn, deen aus der Späichere muss zréckgeholl ginn. Wéi och ëmmer, eng méi grouss Zuel vu Schlësselen kann erfuerderlech sinn, zum Beispill wann de Backupserver e Backup vum primäre Server restauréiert. An esou Fäll, Rotatioun vun der Master Key soll zur Verfügung gestallt ginn. Dëst wäert méi am Detail an zukünfteg Artikelen ofgedeckt ginn, och wann ech hei bemierken datt e Server mat Multiple Master Keys e bësse méi laang daueren kann fir opzemaachen, besonnesch wann Dir e Server-Säit Schlësselgeschäft benotzt.

Loosst eis elo e bësse méi iwwer keyring_file schwätzen. Wann ech war Entwécklungslänner keyring_file, Ech war och besuergt iwwer wéi fir Keyring_file Ännerungen ze kontrolléieren iwwerdeems de Server leeft. Am 5.7 gouf de Scheck op Basis vu Dateistatistiken gemaach, wat net eng ideal Léisung war, an am 8.0 gouf et mat engem SHA256 Checksum ersat.

Déi éischte Kéier Dir keyring_file lafen, Fichier Statistiken an engem checksum berechent, déi vum Server erënneren, an Ännerungen nëmmen applizéiert wann se Match. Wann d'Datei ännert, gëtt de Checksum aktualiséiert.

Mir hu scho vill Froen iwwer Schlësselgewässer ofgedeckt. Wéi och ëmmer, et gëtt en anert wichtegt Thema dat dacks vergiess oder falsch verstanen ass: Schlësselen iwwer Serveren deelen.

Wat mengen ech? All Server (zum Beispill Percona Server) am Stärekoup muss eng separat Plaz um Vault Server hunn, an deem Percona Server seng Schlësselen späichere muss. All Master Key gespäichert an der Späichere enthält de GUID vum Percona Server a sengem Identifizéierer. Firwat ass et wichteg? Stellt Iech vir datt Dir nëmmen ee Vault Server hutt an all Percona Serveren am Cluster benotze dësen eenzegen Vault Server. De Problem schéngt evident. Wann all Percona Server e Master Key ouni eenzegaarteg Identifizéierer benotzt, wéi id = 1, id = 2, etc., da géifen all Server am Cluster dee selwechte Master Key benotzen. Wat de GUID ubitt ass den Ënnerscheed tëscht Serveren. Firwat schwätzt dann iwwer d'Schlësselen tëscht Serveren ze deelen wann en eenzegaartegen GUID schonn existéiert? Et gëtt en anere Plugin - keyring_udf. Mat dësem Plugin kann Äre Server Benotzer hir Schlësselen um Vault Server späicheren. De Problem geschitt wann e Benotzer e Schlëssel op Server1 erstellt, zum Beispill, a probéiert dann e Schlëssel mat der selwechter ID op Server2 ze kreéieren, zum Beispill:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

Waart. Béid Server benotze dee selwechte Vault Server, sollt d'keyring_key_store Funktioun net op Server2 falen? Interessanterweis, wann Dir probéiert datselwecht op engem Server ze maachen, kritt Dir e Feeler:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

Dat ass richteg, ROB_1 existéiert schonn.

Loosst d'éischt dat zweet Beispill diskutéieren. Wéi mir virdru gesot hunn, keyring_vault oder all aner Schlësselring Plugin cache all Schlëssel IDen an Erënnerung. Also, nodeems Dir en neie Schlëssel erstallt hutt, gëtt ROB_1 op Server1 bäigefüügt, an zousätzlech fir dëse Schlëssel op Vault ze schécken, gëtt de Schlëssel och an de Cache bäigefüügt. Elo, wa mir probéieren dee selwechte Schlëssel eng zweete Kéier ze addéieren, kontrolléiert keyring_vault ob de Schlëssel am Cache existéiert a werft e Feeler.

Am éischte Fall ass d'Situatioun anescht. Server1 an Server2 hunn separat Cache. Nodeems Dir ROB_1 an de Schlëssel Cache op Server1 an de Vault Server bäigefüügt huet, ass de Schlëssel Cache op Server2 net synchroniséiert. Et gëtt kee ROB_2 Schlëssel am Cache um Server1. Sou gëtt de ROB_1 Schlëssel op de keyring_key_store an op de Vault-Server geschriwwe, deen tatsächlech de virege Wäert iwwerschreift (!). Elo ass de ROB_1-Schlëssel um Vault-Server 543210987654321. Interessanterweis blockéiert de Vault-Server net sou Aktiounen an iwwerschreift einfach den alen Wäert.

Elo kënne mir gesinn firwat d'Serverpartitionéierung am Vault wichteg ka sinn - wann Dir keyring_udf benotzt a Schlësselen am Vault späichere wëllt. Wéi dës Trennung op engem Vault Server z'erreechen?

Et ginn zwou Weeër fir an Vault ze partitionéieren. Dir kënnt verschidde Montéierungspunkte fir all Server erstellen, oder verschidde Weeër am selwechte Mountpunkt benotzen. Dëst ass am beschten mat Beispiller illustréiert. Also loosst eis déi eenzel Montéierungspunkte fir d'éischt kucken:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)

--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)

Hei kënnt Dir gesinn datt Server1 a Server2 verschidde Montéierungspunkte benotzen. Wann Dir d'Weeër opdeelt, gesäit d'Konfiguratioun esou aus:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)

An dësem Fall benotzen béid Serveren dee selwechte Mountpunkt "mount_point", awer verschidde Weeër. Wann Dir dat éischt Geheimnis op Server1 mat dësem Wee erstellt, erstellt de Vault Server automatesch e "server1" Verzeichnis. Fir Server2 ass alles ähnlech. Wann Dir de leschte Geheimnis am mount_point/server1 oder mount_point/server2 läscht, läscht de Vault-Server och dës Verzeichnisser. Am Fall wou Dir Wee Trennung benotzt, sollt Dir nëmmen ee Mountpunkt erstellen an d'Konfiguratiounsdateien änneren, sou datt d'Server separat Weeër benotzen. E Mountpunkt ka mat enger HTTP-Ufro erstallt ginn. Mat CURL kann dat esou gemaach ginn:

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

All Felder (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) entspriechen de Parameteren vun der Configuratiounsdatei. Natierlech kënnt Dir Vault Utilities benotzen fir datselwecht ze maachen. Awer et ass méi einfach d'Schafung vun engem Mountpunkt ze automatiséieren. Ech hoffen Dir fannt dës Informatioun nëtzlech a mir gesinn Iech an den nächsten Artikelen an dëser Serie.

Verschlësselung an MySQL: Keystore

Liest méi:

Source: will.com

Setzt e Commentaire