Şîfrekirin li MySQL: Keystore

Li hêviya destpêkirina qeydek nû ya ji bo qursê "Datebase" Me ji we re wergera gotareke kêrhatî amade kiriye.

Şîfrekirina Daneyên Transparent (TDE) tê de xuya bû Pêşkêşkara Percona ji bo MySQL û MySQL ji bo demek pir dirêj. Lê gelo we qet fikirî ku ew çawa di binê kapê de dixebite û TDE dikare çi bandorê li servera we bike? Di vê rêzika gotaran de em ê binihêrin ka TDE çawa di hundurê xwe de dixebite. Ka em bi hilanîna mifteyê dest pê bikin, ji ber ku ev ji bo xebitandina her şîfrekirinê hewce ye. Dûv re em ê ji nêz ve binihêrin ka çawa şîfrekirin di Percona Server-ê de ji bo MySQL / MySQL dixebite û kîjan taybetmendiyên din ên Percona Server ji bo MySQL hene.

MySQL Keyring

Keyring pêvek in ku destûrê didin server ku di pelek herêmî de (keyring_file) an li ser serverek dûr (wek HashiCorp Vault) bipirse, biafirîne û jêbibe. Bişkojk her gav li herêmî têne tomar kirin da ku bilezkirina wan zûtir bikin.

Plugin dikarin li du kategoriyan bêne dabeş kirin:

• Depoya herêmî. Mînakî, pelek herêmî (em jê re dibêjin keyring-based file).
• Depokirina dûr. Mînakî, Vault Server (em jê re dibêjin keyring-based server).

Ev veqetandin girîng e ji ber ku cûreyên cûda yên hilanînê hinekî cûda tevdigerin, ne tenê dema hilanîn û kişandina mifteyan, lê di heman demê de dema ku wan dimeşînin.

Dema ku hilanînek pelê bikar tînin, piştî destpêkirinê, tevahiya naveroka hilanînê di cacheyê de tê barkirin: nasnama mifteyê, bikarhênerê sereke, celebê mifteyê, û mifteyê bixwe.

Di mijara firotgehek-based serverê de (wekî Vault Server), di destpêkê de tenê nasnameya mifteyê û bikarhênerê sereke têne barkirin, ji ber vê yekê girtina hemî bişkokan destpêkirinê hêdî nake. Keys bi tembelî têne barkirin. Ango, mift bixwe ji Vault tenê gava ku ew bi rastî hewce be tê barkirin. Piştî dakêşandin, mift di bîranînê de tê hilanîn da ku di pêşerojê de ne hewce ye ku ew bi girêdanên TLS-ê bi Servera Vault-ê re were gihandin. Dûv re, em binihêrin ka çi agahdarî di firotgeha mifteyê de heye.

Agahiyên sereke yên jêrîn hene:

• key id - Nasnameya sereke, wek nimûne:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• type key - Cureya mifteyê li ser bingeha algorîtmaya şîfrekirinê ya hatî bikar anîn, nirxên gengaz: "AES", "RSA" an "DSA".
• dirêjahiya mifteyê - Dirêjahiya mifteyê bi byte, AES: 16, 24 an 32, RSA 128, 256, 512 û DSA 128, 256 an 384.
• bikaranîvan - xwediyê key. Ger kilît sîstem be, bo nimûne, Key Key, wê hingê ev qad vala ye. Ger mifteyek bi karanîna keyring_udf were afirandin, wê hingê ev qad xwediyê miftê nas dike.
• mifta xwe

Miftek yekta ji hêla cotê ve tête nas kirin: key_id, bikarhêner.

Cûdahî di hilanîn û jêbirina mifteyan de jî hene.

Hilberîna pelan zûtir e. Hûn dikarin bifikirin ku firotgehek mifteyê bi tenê carekê mifteya pelê dinivîse, lê na, li vir bêtir diqewime. Kengê ku guheztinek hilanîna pelê were çêkirin, pêşî kopiyek paşvekêşana hemî naverokê tê afirandin. Em bêjin pelê bi navê my_biggest_secrets tê gotin, wê hingê kopiya paşvekişandinê dê bibe my_biggest_secrets.backup. Dûv re, cache tê guheztin (bişkok têne zêdekirin an jêbirin) û heke her tişt serketî be, cache li pelek tê vegerandin. Di rewşên hindik de, wek têkçûna serverê, dibe ku hûn vê pelê hilanînê bibînin. Dosya hilanînê dema ku bişkok têne barkirin (bi gelemperî piştî ku server ji nû ve tê destpêkirin) tê jêbirin.

Dema ku mifteyek di hilanînek serverê de hilanîn an jêbirin, pêdivî ye ku hilanîn bi fermanên "mifteyê bişîne" / "daxwaza jêbirina mifteyê" bi servera MySQL ve were girêdan.

Ka em vegerin ser leza destpêkirina serverê. Digel vê yekê ku leza destpêkirinê ji hêla kaxez bixwe ve tê bandor kirin, di heman demê de pirsgirêkek heye ku di destpêkê de çend kilît ji kavilê bêne derxistin. Bê guman, ev bi taybetî ji bo hilanîna serverê girîng e. Di destpêkirinê de, server kontrol dike ka kîjan mifteyê ji bo tabloyên / cîhên sifrê yên şîfrekirî hewce dike û mifteyê ji hilanînê daxwaz dike. Li ser serverek "paqij" bi şîfrekirina Master Key, divê yek Key Key hebe, ku divê ji hilanînê were derxistin. Lêbelê, dibe ku hejmareke mezin a bişkokan hewce bike, mînakî, dema ku servera hilanînê ji servera bingehîn hilanînê vedigire. Di rewşên weha de, zivirîna Mifteya Master divê were peyda kirin. Ev ê di gotarên pêşerojê de bi hûrgulî were nixumandin, her çend li vir ez dixwazim bi bîr bixim ku serverek ku pir Bişkojkên Master bikar tîne dibe ku destpêkek piçûktir bigire, nemaze dema ku dikanek mifteya serverê bikar tîne.

Naha em hinekî bêtir li ser keyring_file biaxivin. Dema ku min keyring_file pêşve dixist, ez di heman demê de fikar bûm ka meriv çawa guheztinên keyring_file dema ku server dixebite kontrol bikim. Di 5.7 de, kontrol li ser bingeha statîstîkên pelan hate kirin, ku ne çareseriyek îdeal bû, û di 8.0 de ew bi kontrolek SHA256 hate guheztin.

Cara yekem ku hûn keyring_file dimeşînin, statîstîkên pelan û berhevokek kontrolê têne hesibandin, ku ji hêla serverê ve têne bîranîn, û guhertin tenê heke li hev bikin têne sepandin. Dema ku pel diguhere, checksum tê nûve kirin.

Me berê jî gelek pirsan li ser kaxezên sereke vegirtiye. Lêbelê, mijarek din a girîng heye ku pir caran tê ji bîr kirin an xelet tê fam kirin: parvekirina mifteyên li ser serveran.

Mebesta min çi ye? Pêdivî ye ku her serverek (mînak, Pêşkêşkara Percona) di komê de cîhek cihêreng li ser Pêşkêşkara Vault hebe ku tê de Pêşkêşkara Percona divê kilîtên xwe hilîne. Her Mifteya Masterê ya ku di hilanînê de hatî tomarkirin GUID-a Pêşkêşkara Percona di nav nasnameya xwe de vedihewîne. Çima girîng e? Bifikirin ku we tenê serverek Vault heye û hemî Pêşkêşkerên Percona di komê de wê servera Vault yekane bikar tînin. Pirsgirêk eşkere xuya dike. Heke hemî Pêşkêşkerên Percona Key Key bêyî nasnameyên yekta bikar bînin, wek id = 1, id = 2, hwd., wê hingê hemî pêşkêşkerên di komê de dê heman Key Master bikar bînin. Ya ku GUID peyda dike cûdahiya di navbera serveran de ye. Wê hingê çima li ser parvekirina mifteyên di navbera serveran de heke GUID-ya bêhempa jixwe hebe biaxivin? Pêvekek din heye - keyring_udf. Bi vê pêvekê, bikarhênerê servera we dikare mifteyên xwe li ser servera Vault hilîne. Pirsgirêk dema ku bikarhênerek mifteyek li ser server1 diafirîne, mînakî, û dûv re hewl dide ku mifteyek bi heman nasnameyê li ser server2 biafirîne, mînakî:

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

Payin. Her du pêşkêşker heman Pêşkêşkara Vault bikar tînin, ma fonksiyona keyring_key_store li ser server2 têk nabe? Balkêş e, heke hûn hewl bidin ku heman tiştî li ser serverek bikin, hûn ê xeletiyek bistînin:

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

Rast e, ROB_1 jixwe heye.

Werin em pêşî li mînaka duyemîn nîqaş bikin. Wekî ku me berê jî got, keyring_vault an pêveka din a keyring hemî nasnameyên sereke di bîranînê de vedişêre. Ji ber vê yekê, piştî afirandina mifteyek nû, ROB_1 li server1 tê zêdekirin, û ji bilî şandina vê mifteyê ji Vault re, mift li cache jî tê zêdekirin. Naha, gava ku em hewl didin ku carek din heman mifteyê lê zêde bikin, keyring_vault kontrol dike ka kilît di cache de heye û xeletiyek derdixe.

Di rewşa yekem de rewş cuda ye. Server1 û server2 keşeyên cuda hene. Piştî lêzêdekirina ROB_1 li cacheya mifteyê ya li ser server1 û servera Vault, cacheya mifteyê li ser server2 ji hevdengiyê dernakeve. Di kaşê de li ser server2 mifteya ROB_1 tune. Bi vî rengî, mifteya ROB_1 li keyring_key_store û ji servera Vault re tê nivîsandin, ku bi rastî nirxa berê (!) dinivîse. Naha mifteya ROB_1 li ser servera Vault-ê 543210987654321 e. Balkêş e ku servera Vault kiryarên weha asteng nake û bi hêsanî nirxa kevin dinivîse.

Naha em dikarin bibînin ka çima dabeşkirina serverê li Vault dikare girîng be - gava ku hûn keyring_udf bikar tînin û dixwazin bişkokan li Vault hilînin. Meriv çawa vê veqetandinê li ser serverek Vault bi dest dixe?

Du awayên dabeşkirina nav Vault hene. Hûn dikarin ji bo her serverek nuqteyên cihêreng biafirînin, an jî di heman xala çiyê de rêyên cûda bikar bînin. Ev herî baş bi mînakan tê diyar kirin. Ji ber vê yekê ka em pêşî li xalên mountkirina kesane binêrin:

--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 = (...)

Li vir hûn dikarin bibînin ku server1 û server2 nuqteyên cûda yên mount bikar tînin. Dema ku riyan veqetînin, veavakirin dê wiha xuya bike:

--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 = (...)

Di vê rewşê de, her du server heman xala çiyê "mount_point" bikar tînin, lê rêyên cûda. Dema ku hûn bi karanîna vê rêyê li ser server1 raza yekem diafirînin, servera Vault bixweber pelrêçek "server1" diafirîne. Ji bo server2 her tişt wekhev e. Gava ku hûn sira paşîn di mount_point/server1 an mount_point/server2 de jêbirin, servera Vault jî wan pelrêçan jî jê dike. Ger hûn veqetandina rê bikar bînin, divê hûn tenê xalek mountê biafirînin û pelên vesazkirinê biguhezînin da ku server rêyên cuda bikar bînin. Xalek mount dikare bi karanîna daxwazek HTTP were afirandin. Bi karanîna CURL ev dikare bi vî rengî were kirin:

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

Hemî zevî (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) bi pîvanên pelê veavakirinê re têkildar in. Bê guman, hûn dikarin karûbarên Vault bikar bînin ku heman bikin. Lê hêsantir e ku meriv çêkirina xalek çiyê otomatîk bike. Ez hêvî dikim ku hûn vê agahiyê kêrhatî bibînin û em ê we di gotarên paşîn ên vê rêzê de bibînin.

Zêdetir bixwînin:

• Sysbench û belavkirina guherbarên random

Source: www.habr.com