Gan ragweld dechrau ymrestriad newydd ar gyfer y cwrs Rydym wedi paratoi cyfieithiad o erthygl ddefnyddiol i chi.
Ymddangosodd Amgryptio Data Tryloyw (TDE) yn a MySQL ers cryn amser. Ond ydych chi erioed wedi meddwl sut mae'n gweithio o dan y cwfl a pha effaith y gall TDE ei chael ar eich gweinydd? Yn y gyfres hon o erthyglau byddwn yn edrych ar sut mae TDE yn gweithio'n fewnol. Gadewch i ni ddechrau gyda storfa allweddol, gan fod hyn yn ofynnol er mwyn i unrhyw amgryptio weithio. Yna byddwn yn edrych yn agosach ar sut mae amgryptio yn gweithio yn Percona Server ar gyfer MySQL / MySQL a pha nodweddion ychwanegol sydd gan Percona Server ar gyfer MySQL.
Cylch allweddi MySQL
Mae keyring yn ategion sy'n caniatáu i'r gweinydd ymholi, creu, a dileu allweddi mewn ffeil leol (keyring_file) neu ar weinydd pell (fel HashiCorp Vault). Mae allweddi bob amser yn cael eu storio'n lleol er mwyn cyflymu eu hadalw.
Gellir rhannu ategion yn ddau gategori:
- Storfa leol. Er enghraifft, ffeil leol (rydym yn galw hyn yn gylch allweddi sy'n seiliedig ar ffeil).
- Storio o bell. Er enghraifft, Vault Server (rydym yn galw hwn yn gylch allweddi sy'n seiliedig ar weinydd).
Mae'r gwahaniad hwn yn bwysig oherwydd bod gwahanol fathau o storio yn ymddwyn ychydig yn wahanol, nid yn unig wrth storio ac adalw allweddi, ond hefyd wrth eu rhedeg.
Wrth ddefnyddio storfa ffeil, wrth gychwyn, mae holl gynnwys y storfa yn cael ei lwytho i'r storfa: id allwedd, defnyddiwr allweddol, math o allwedd, a'r allwedd ei hun.
Yn achos storfa ochr y gweinydd (fel Vault Server), dim ond yr id allwedd a'r defnyddiwr allweddol sy'n cael eu llwytho wrth gychwyn, felly nid yw cael yr holl allweddi yn arafu'r cychwyn. Mae allweddi'n cael eu llwytho'n ddiog. Hynny yw, dim ond pan fydd ei angen mewn gwirionedd y caiff yr allwedd ei hun ei lwytho o Vault. Ar ôl ei lawrlwytho, caiff yr allwedd ei storio yn y cof fel nad oes angen ei chyrchu trwy gysylltiadau TLS â'r Vault Server yn y dyfodol. Nesaf, gadewch i ni edrych ar ba wybodaeth sy'n bresennol yn y storfa allweddol.
Mae'r wybodaeth allweddol yn cynnwys y canlynol:
- id allweddol — dynodwr allwedd, er enghraifft:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - math allweddol — math allweddol yn seiliedig ar yr algorithm amgryptio a ddefnyddiwyd, gwerthoedd posibl: “AES”, “RSA” neu “DSA”.
- hyd allweddol — hyd allweddol mewn beit, AES: 16, 24 neu 32, RSA 128, 256, 512 a DSA 128, 256 neu 384.
- defnyddiwr - perchennog yr allwedd. Os mai system yw'r allwedd, er enghraifft, Master Key, yna mae'r maes hwn yn wag. Os yw allwedd yn cael ei chreu gan ddefnyddio keyring_udf, yna mae'r maes hwn yn nodi perchennog yr allwedd.
- yr allwedd ei hun
Mae'r allwedd yn cael ei hadnabod yn unigryw gan y pâr: key_id, defnyddiwr.
Mae gwahaniaethau hefyd o ran storio a dileu allweddi.
Mae storio ffeiliau yn gyflymach. Efallai eich bod chi'n meddwl mai dim ond ysgrifennu'r allwedd i ffeil unwaith y mae storfa allweddi, ond na, mae mwy yn digwydd yma. Pryd bynnag y gwneir addasiad storio ffeiliau, caiff copi wrth gefn o'r holl gynnwys ei greu gyntaf. Dywedwch mai my_biggest_secrets yw enw'r ffeil, yna bydd y copi wrth gefn yn my_biggest_secrets.backup. Nesaf, caiff y storfa ei newid (mae allweddi'n cael eu hychwanegu neu eu dileu) ac, os yw popeth yn llwyddiannus, caiff y storfa ei ailosod i ffeil. Mewn achosion prin, fel methiant gweinydd, efallai y gwelwch y ffeil wrth gefn hon. Mae'r ffeil wrth gefn yn cael ei ddileu y tro nesaf y bydd yr allweddi yn cael eu llwytho (fel arfer ar ôl i'r gweinydd gael ei ailgychwyn).
Wrth gadw neu ddileu allwedd mewn storfa gweinydd, rhaid i'r storfa gysylltu â'r gweinydd MySQL gyda'r gorchmynion “anfon yr allwedd” / “gofyn am ddileu allwedd”.
Gadewch i ni fynd yn ôl at gyflymder cychwyn y gweinydd. Yn ogystal â'r ffaith bod y gladdgell ei hun yn effeithio ar y cyflymder lansio, mae yna hefyd y mater o faint o allweddi o'r gladdgell y mae angen eu hadfer wrth gychwyn. Wrth gwrs, mae hyn yn arbennig o bwysig ar gyfer storio gweinydd. Wrth gychwyn, mae'r gweinydd yn gwirio pa allwedd sydd ei hangen ar gyfer byrddau/gofodau bwrdd wedi'u hamgryptio ac yn gofyn am yr allwedd o'r storfa. Ar weinydd “glân” gydag amgryptio Master Key, rhaid cael un Prif Allwedd, y mae'n rhaid ei adfer o'r storfa. Fodd bynnag, efallai y bydd angen nifer fwy o allweddi, er enghraifft, pan fydd y gweinydd wrth gefn yn adfer copi wrth gefn o'r gweinydd sylfaenol. Mewn achosion o'r fath, dylid darparu cylchdroi'r Prif Allwedd. Ymdrinnir â hyn yn fanylach mewn erthyglau yn y dyfodol, er yma hoffwn nodi y gall gweinydd sy'n defnyddio Allweddi Meistr lluosog gymryd ychydig mwy o amser i gychwyn, yn enwedig wrth ddefnyddio storfa allweddi ochr y gweinydd.
Nawr, gadewch i ni siarad ychydig mwy am keyring_file. Pan oeddwn i'n datblygu keyring_file, roeddwn i hefyd yn poeni am sut i wirio am newidiadau keyring_file tra bod y gweinydd yn rhedeg. Yn 5.7, perfformiwyd y gwiriad yn seiliedig ar ystadegau ffeil, nad oedd yn ateb delfrydol, ac yn 8.0 fe'i disodlwyd gan wiriad SHA256.
Y tro cyntaf i chi redeg keyring_file, mae ystadegau ffeil a siec yn cael eu cyfrifo, sy'n cael eu cofio gan y gweinydd, a dim ond os ydyn nhw'n cyfateb y caiff newidiadau eu gweithredu. Pan fydd y ffeil yn newid, mae'r siec yn cael ei diweddaru.
Rydym eisoes wedi ymdrin â llawer o gwestiynau am gromgelloedd allweddol. Fodd bynnag, mae pwnc pwysig arall sy'n aml yn cael ei anghofio neu ei gamddeall: rhannu allweddi ar draws gweinyddwyr.
Beth ydw i'n ei olygu? Rhaid i bob gweinydd (er enghraifft, Percona Server) yn y clwstwr gael lleoliad ar wahân ar y Vault Server lle mae'n rhaid i Percona Server storio ei allweddi. Mae pob Prif Allwedd a gedwir yn y storfa yn cynnwys GUID y Gweinydd Percona o fewn ei ddynodwr. Pam ei fod yn bwysig? Dychmygwch mai dim ond un Gweinydd Vault sydd gennych ac mae pob Gweinyddwr Percona yn y clwstwr yn defnyddio'r Gweinydd Vault sengl hwnnw. Mae'r broblem yn ymddangos yn amlwg. Pe bai pob Gweinydd Percona yn defnyddio Allwedd Meistr heb ddynodwyr unigryw, megis id = 1, id = 2, ac ati, yna byddai pob gweinydd yn y clwstwr yn defnyddio'r un Prif Allwedd. Yr hyn y mae'r GUID yn ei ddarparu yw'r gwahaniaeth rhwng gweinyddwyr. Pam felly siarad am rannu allweddi rhwng gweinyddwyr os oes GUID unigryw eisoes yn bodoli? Mae yna ategyn arall - keyring_udf. Gyda'r ategyn hwn, gall defnyddiwr eich gweinydd storio ei allweddi ar y gweinydd Vault. Mae'r broblem yn digwydd pan fydd defnyddiwr yn creu allwedd ar server1, er enghraifft, ac yna'n ceisio creu allwedd gyda'r un ID ar server2, er enghraifft:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Arhoswch. Mae'r ddau weinydd yn defnyddio'r un Gweinydd Vault, oni ddylai'r swyddogaeth keyring_key_store fethu ar server2? Yn ddiddorol, os ceisiwch wneud yr un peth ar un gweinydd, byddwch yn derbyn gwall:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Mae hynny'n iawn, mae ROB_1 eisoes yn bodoli.
Gadewch i ni drafod yr ail enghraifft yn gyntaf. Fel y dywedasom yn gynharach, mae keyring_vault neu unrhyw ategyn cylch allweddi arall yn storio'r holl IDau allweddol yn y cof. Felly, ar ôl creu allwedd newydd, mae ROB_1 yn cael ei ychwanegu at server1, ac yn ogystal ag anfon yr allwedd hon i Vault, mae'r allwedd hefyd yn cael ei ychwanegu at y storfa. Nawr, pan geisiwn ychwanegu'r un allwedd yr eildro, mae keyring_vault yn gwirio a yw'r allwedd yn bodoli yn y storfa ac yn taflu gwall.
Yn yr achos cyntaf, mae'r sefyllfa'n wahanol. Mae gan Server1 a server2 storfa ar wahân. Ar ôl ychwanegu ROB_1 i'r storfa allwedd ar server1 a'r gweinydd Vault, mae'r storfa allwedd ar server2 allan o gysoni. Nid oes allwedd ROB_2 yn y storfa ar server1. Felly, mae'r allwedd ROB_1 wedi'i ysgrifennu i'r keyring_key_store ac i'r gweinydd Vault, sydd mewn gwirionedd yn trosysgrifo (!) y gwerth blaenorol. Nawr yr allwedd ROB_1 ar y gweinydd Vault yw 543210987654321. Yn ddiddorol, nid yw'r gweinydd Vault yn rhwystro gweithredoedd o'r fath ac yn trosysgrifo'r hen werth yn hawdd.
Nawr gallwn weld pam y gall rhaniad gweinydd yn Vault fod yn bwysig - pan fyddwch chi'n defnyddio keyring_udf ac eisiau storio allweddi yn Vault. Sut i gyflawni'r gwahaniad hwn ar weinydd Vault?
Mae dwy ffordd i rannu'n Vault. Gallwch greu gwahanol bwyntiau gosod ar gyfer pob gweinydd, neu ddefnyddio gwahanol lwybrau o fewn yr un pwynt gosod. Amlygir hyn orau gydag enghreifftiau. Felly gadewch i ni edrych ar y pwyntiau gosod unigol yn gyntaf:
--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 = (...)Yma gallwch weld bod gweinydd1 a server2 yn defnyddio gwahanol fannau gosod. Wrth rannu'r llwybrau, bydd y ffurfweddiad yn edrych fel hyn:
--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 = (...)Yn yr achos hwn, mae'r ddau weinydd yn defnyddio'r un pwynt gosod "mount_point", ond llwybrau gwahanol. Pan fyddwch chi'n creu'r gyfrinach gyntaf ar server1 gan ddefnyddio'r llwybr hwn, mae'r gweinydd Vault yn creu cyfeiriadur “server1” yn awtomatig. Ar gyfer server2 mae popeth yn debyg. Pan fyddwch chi'n dileu'r gyfrinach olaf yn mount_point/server1 neu mount_point/server2, mae'r gweinydd Vault hefyd yn dileu'r cyfeiriaduron hynny. Rhag ofn i chi ddefnyddio gwahaniad llwybr, rhaid i chi greu un pwynt gosod yn unig a newid y ffeiliau ffurfweddu fel bod y gweinyddwyr yn defnyddio llwybrau ar wahân. Gellir creu pwynt gosod gan ddefnyddio cais HTTP. Gan ddefnyddio CURL gellir gwneud hyn fel hyn:
curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTMae pob maes (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) yn cyfateb i baramedrau'r ffeil ffurfweddu. Wrth gwrs, gallwch chi ddefnyddio Vault utilities i wneud yr un peth. Ond mae'n haws awtomeiddio creu pwynt gosod. Gobeithio y bydd y wybodaeth hon yn ddefnyddiol i chi ac fe welwn ni chi yn yr erthyglau nesaf yn y gyfres hon.
Darllen mwy:
Ffynhonnell: hab.com