In afwagting van die begin van 'n nuwe inskrywing vir die kursus het 'n vertaling van 'n nuttige artikel vir jou voorberei.
Deursigtige data-enkripsie (TDE) het verskyn in en MySQL vir 'n geruime tyd nou. Maar het u al ooit daaraan gedink hoe dit onder die enjinkap werk en watter impak TDE op u bediener kan hê? In hierdie artikelreeks gaan ons kyk hoe TDE intern werk. Kom ons begin met sleutelberging, aangesien dit nodig is vir enige enkripsie om te werk. Dan sal ons nader kyk na hoe enkripsie werk in Percona Server vir MySQL/MySQL en watter bykomende kenmerke beskikbaar is in Percona Server vir MySQL.
MySQL-sleutelring
Sleutelhouers is inproppe wat die bediener toelaat om navraag te doen, sleutels te skep en uit te vee in 'n plaaslike lêer (keyring_file) of op 'n afgeleë bediener (byvoorbeeld in HashiCorp Vault). Sleutels word altyd plaaslik gekas om herwinning te bespoedig.
Inproppe kan in twee kategorieë verdeel word:
- Plaaslike berging. Byvoorbeeld, 'n plaaslike lêer (ons noem dit 'n lêer-gebaseerde sleutelring).
- afstandberging. Byvoorbeeld Vault Server (ons noem dit 'n bediener-gebaseerde sleutelring).
Hierdie skeiding is belangrik omdat verskillende bergingstipes effens anders optree, nie net wanneer sleutels gestoor en herwin word nie, maar ook wanneer hulle begin.
Wanneer lêerberging gebruik word, word al die inhoud van die berging in die kas gelaai by opstart: sleutel-ID, sleutelgebruiker, sleuteltipe en die sleutel self.
In die geval van 'n back-end-winkel (byvoorbeeld die Vault-bediener), word slegs die sleutel-ID en sleutelgebruiker by opstart gelaai, dus om al die sleutels te kry, vertraag nie die opstart nie. Sleutels word luilekker gelaai. Dit wil sê, die sleutel self word slegs vanaf Vault gelaai wanneer dit werklik nodig is. Nadat die sleutel afgelaai is, word die sleutel in die geheue gestoor sodat dit in die toekoms nie nodig is om toegang daartoe te verkry deur TLS-verbindings na die Vault Server nie. Oorweeg dan watter inligting in die sleutelstoor teenwoordig is.
Sleutelinligting bevat die volgende:
- sleutel id - sleutel identifiseerder, byvoorbeeld:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - sleutel tipe - sleuteltipe gebaseer op die enkripsiealgoritme wat gebruik word, moontlike waardes: "AES", "RSA" of "DSA".
- sleutellengte - sleutellengte in grepe, AES: 16, 24 of 32, RSA 128, 256, 512 en DSA 128, 256 of 384.
- gebruiker is die eienaar van die sleutel. As die sleutel 'n stelselsleutel is, soos Hoofsleutel, dan is hierdie veld leeg. As die sleutel met sleutelring_udf geskep is, dui hierdie veld die eienaar van die sleutel aan.
- die sleutel self
Die sleutel word uniek deur die paar geïdentifiseer: sleutel_id, gebruiker.
Daar is ook verskille in sleutelberging en -skrap.
Lêerberging is vinniger. Jy mag dalk dink dat die sleutelstoor net 'n eenmalige skryf van die sleutel tot 'n lêer is, maar dit is nie - hier is meer aan die gang. Wanneer 'n lêerberging gewysig word, word alle inhoud eers gerugsteun. Kom ons sê die lêer word my_biggest_secrets genoem, dan sal die rugsteun my_biggest_secrets.backup wees. Vervolgens word die kas verander (sleutels word bygevoeg of verwyder) en as alles suksesvol is, word die kas in 'n lêer gestort. In seldsame gevalle, soos 'n bedienerongeluk, kan u hierdie rugsteunlêer sien. Die rugsteunlêer word uitgevee die volgende keer as die sleutels gelaai word (gewoonlik na 'n bediener herbegin).
Wanneer 'n sleutel in die bedienerwinkel gestoor of uitgevee word, moet die winkel aan die MySQL-bediener koppel met die "stuur die sleutel" / "versoek sleuteluitvee"-opdragte.
Kom ons keer terug na bediener se opstartspoed. Benewens die feit dat die kluis self die opstartspoed beïnvloed, is daar ook die vraag hoeveel sleutels van die kluis by opstart verkry moet word. Dit is natuurlik veral belangrik vir bedienerbergings. By opstart kontroleer die bediener watter sleutel benodig word vir die geënkripteerde tabelle/tafelruimtes en versoek die sleutel van die berging. Op 'n "skoon" bediener met 'n Hoofsleutel - daar moet een Hoofsleutel vir enkripsie wees, wat uit die stoor gehaal moet word. Meer sleutels kan egter vereis word, byvoorbeeld wanneer 'n rugsteun vanaf die primêre bediener na 'n bystandbediener herstel word. In sulke gevalle moet Master Key rotasie verskaf word. Dit sal in meer besonderhede in toekomstige artikels bespreek word, alhoewel ek hier wil opmerk dat 'n bediener wat veelvuldige hoofsleutels gebruik, 'n bietjie langer kan neem om te begin, veral wanneer 'n bedienersleutelwinkel gebruik word.
Kom ons praat nou 'n bietjie meer oor keyring_file. Toe ek die sleutelring_lêer ontwerp het, was ek ook bekommerd oor hoe om te kyk vir sleutelring_lêerveranderinge terwyl die bediener loop. In 5.7 is die kontrole uitgevoer op grond van lêerstatistieke, wat nie ideaal was nie, en in 8.0 is dit vervang met 'n SHA256 kontrolesom.
Die eerste keer dat sleutelring_lêer uitgevoer word, word die lêerstatistieke en kontrolesom deur die bediener bereken en onthou, en veranderinge word slegs toegepas as hulle ooreenstem. Wanneer die lêer verander, word die kontrolesom opgedateer.
Ons het reeds baie vrae oor sleutelwinkels gedek. Daar is egter nog 'n belangrike onderwerp wat dikwels vergeet of verkeerd verstaan word - die deel van sleutels oor bedieners.
Wat ek bedoel? Elke bediener (byvoorbeeld Percona Server) in die groepie moet 'n aparte ligging op die Vault Server hê waarin Percona Server sy sleutels moet stoor. Elke hoofsleutel wat in die kluis gestoor word, bevat die Percona Server GUID binne sy ID. Hoekom is dit belangrik? Stel jou voor dat jy net een Vault Server het en alle Percona Servers in die cluster gebruik hierdie enkele Vault Server. Die probleem lyk voor die hand liggend. As alle Percona-bedieners 'n hoofsleutel gebruik sonder unieke identifiseerders, soos id = 1, id = 2, ens., dan sal alle bedieners in die groep dieselfde hoofsleutel gebruik. Dit is wat die GUID verskaf - die onderskeid tussen bedieners. Hoekom dan praat oor die deel van sleutels tussen bedieners as daar reeds 'n unieke GUID is? Daar is nog 'n inprop - sleutelring_udf. Met hierdie inprop kan 'n gebruiker van jou bediener hul sleutels op die Vault-bediener stoor. Die probleem kom voor wanneer 'n gebruiker 'n sleutel skep, byvoorbeeld op bediener1, en dan probeer om 'n sleutel met dieselfde ID op bediener2 te skep, byvoorbeeld:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Wag. Albei bedieners gebruik dieselfde Vault Server, moet die sleutelring_sleutel_winkel-funksie nie op bediener2 misluk nie? Interessant genoeg, as jy probeer om dieselfde op dieselfde bediener te doen, sal jy 'n fout kry:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Dis reg, ROB_1 bestaan reeds.
Kom ons bespreek eers die tweede voorbeeld. Soos ons vroeër gesê het, kas keyring_vault of enige ander kluis-inprop (sleutelring) alle sleutel-ID's in die geheue. Dus, nadat 'n nuwe sleutel geskep is, word ROB_1 by bediener1 gevoeg, en benewens die stuur van hierdie sleutel na Vault, word die sleutel ook by die kas gevoeg. Nou, wanneer ons probeer om dieselfde sleutel 'n tweede keer by te voeg, kyk keyring_vault of die sleutel in die kas bestaan en gooi 'n fout.
In die eerste geval is die situasie anders. Bediener1 en bediener2 het aparte kas. Nadat ROB_1 by die sleutelkas op bediener1 en die Vault-bediener gevoeg is, is die sleutelkas op bediener2 nie gesinchroniseer nie. Die kas op bediener2 bevat nie die ROB_1-sleutel nie. Die ROB_1-sleutel word dus na die sleutelring_sleutel_winkel en na die Vault-bediener geskryf, wat eintlik die vorige waarde oorskryf (!). Nou is die sleutel ROB_1 op die Vault-bediener 543210987654321. Interessant genoeg, die Vault-bediener blokkeer nie sulke aksies nie en skryf maklik die ou waarde oor.
Nou sien ons hoekom segregasie deur bediener in Vault belangrik kan wees wanneer jy keyring_udf gebruik en sleutels in Vault wil stoor. Hoe om so 'n skeiding in die Vault-bediener te verskaf?
Daar is twee maniere om op Vault te partisieer. Jy kan verskillende bergpunte vir elke bediener skep, of verskillende paaie binne dieselfde monteerpunt gebruik. Die beste manier om dit te wys is met voorbeelde. Kom ons kyk dus eers na die individuele monteringspunte:
--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 = (...)Hier kan jy sien dat bediener1 en bediener2 verskillende monteringspunte gebruik. Met padskeiding sal die konfigurasie soos volg lyk:
--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 = (...)In hierdie geval gebruik beide bedieners dieselfde monteerpunt "mount_point" maar verskillende paaie. Wanneer jy die eerste geheim op bediener1 met hierdie pad skep, skep die Vault-bediener outomaties 'n "bediener1"-gids. Vir bediener 2 is alles dieselfde. Wanneer jy die laaste geheim in mount_point/server1 of mount_point/server2 uitvee, vee die Vault-bediener ook daardie gidse uit. As u gesplete paaie gebruik, moet u slegs een monteringspunt skep en die konfigurasielêers verander sodat die bedieners aparte paaie gebruik. 'n Bergpunt kan geskep word met 'n HTTP-versoek. Met CURL kan dit so gedoen word:
curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTAlle velde (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) stem ooreen met die parameters van die konfigurasielêer. Natuurlik kan jy die Vault-nutsprogramme gebruik om dieselfde te doen. Maar dit is makliker om die skepping van 'n bergpunt te outomatiseer. Ek hoop jy vind hierdie inligting nuttig en sien jou in die volgende artikels in hierdie reeks.
Lees meer:
Bron: will.com