Ag súil le tosú ar chlárú nua don chúrsa Tá aistriúchán ar alt úsáideach ullmhaithe againn duit.
Bhí Criptiú Sonraí Trédhearcacha (TDE) le feiceáil i agus MySQL le tamall maith. Ach ar smaoinigh tú riamh ar conas a oibríonn sé faoin gcochall agus cén tionchar is féidir a bheith ag TDE ar do fhreastalaí? Sa tsraith alt seo féachfaimid ar conas a oibríonn TDE go hinmheánach. Let tús le stóráil eochair, ós rud é seo ag teastáil le haghaidh aon criptithe a bheith ag obair. Ansin déanfaimid breathnú níos géire ar an gcaoi a n-oibríonn criptiú i Freastalaí Percona do MySQL / MySQL agus cad iad na gnéithe breise atá ag Percona Server do MySQL.
Fáinne Eochracha MySQL
Is forlíontáin iad keyring a ligeann don fhreastalaí eochracha a fhiosrú, a chruthú agus a scriosadh i gcomhad áitiúil (keyring_file) nó ar fhreastalaí cianda (cosúil le HashiCorp Vault). Cuirtear eochracha i dtaisce go háitiúil i gcónaí chun iad a aisghabháil.
Is féidir forlíontáin a roinnt ina dhá chatagóir:
- Stóráil áitiúil. Mar shampla, comhad áitiúil (tugaimid fáinne eochracha bunaithe ar chomhad air seo).
- Stóráil iargúlta. Mar shampla, Vault Server (tugaimid fáinne eochracha bunaithe ar fhreastalaí air seo).
Tá an scaradh seo tábhachtach toisc go n-iompraíonn cineálacha éagsúla stórála beagán difriúil, ní hamháin nuair a bhíonn eochracha á stóráil agus á n-aisghabháil, ach freisin nuair a bhíonn siad á reáchtáil.
Nuair a bhíonn stóráil comhad á úsáid, nuair a bhíonn sé tosaithe, déantar inneachar iomlán na stórála a luchtú isteach sa taisce: eochair-aitheantas, eochairúsáideoir, cineál eochrach, agus an eochair féin.
I gcás stór ar thaobh an fhreastalaí (cosúil le Vault Server), ní luchtaítear ach an t-aitheantas eochrach agus an t-úsáideoir eochrach ag am tosaithe, mar sin ní mhoillíonn fáil na heochracha go léir an tosaithe. Tá na heochracha luchtaithe go leisciúil. Is é sin, ní dhéantar an eochair féin a luchtú ó Vault ach amháin nuair a bhíonn gá leis. Nuair a bheidh sí íoslódáilte, tá an eochair i dtaisce sa chuimhne ionas nach gá í a rochtain trí naisc TLS leis an bhFreastalaí Vault sa todhchaí. Ansin, déanaimis féachaint ar an bhfaisnéis atá i láthair sa stór eochair.
Tá na nithe seo a leanas san eochairfhaisnéis:
- eochair-aitheantas — aitheantóir eochrach, mar shampla:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - cineál eochair — cineál eochrach bunaithe ar an algartam criptithe a úsáideadh, luachanna féideartha: “AES”, “RSA” nó “DSA”.
- fad eochair — fad eochrach i mbearta, AES: 16, 24 nó 32, RSA 128, 256, 512 agus DSA 128, 256 nó 384.
- faoi úsáideoir - úinéir an eochair. Más córas í an eochair, mar shampla, Máistir Eochair, tá an réimse seo folamh. Má chruthaítear eochair le keyring_udf, sainaithníonn an réimse seo úinéir na heochrach.
- an eochair féin
Aithníonn an péire an eochair go uathúil: key_id, úsáideoir.
Tá difríochtaí ann freisin maidir le heochracha a stóráil agus a scriosadh.
Tá stóráil comhad níos tapúla. B'fhéidir go gceapfá nach bhfuil i gceist le stór eochair ach eochair an chomhaid a scríobh uair amháin, ach níl, tá níos mó ar siúl anseo. Aon uair a dhéantar modhnú stórála comhad, cruthaítear cóip chúltaca den ábhar ar fad ar dtús. Ligean le rá go bhfuil an comhad ar a dtugtar my_biggest_secrets, ansin beidh an chóip chúltaca a bheith my_biggest_secrets.backup. Ansin, athraítear an taisce (cuirtear eochracha leis nó scriostar iad) agus, má éiríonn le gach rud, athshocraítear an taisce go comhad. I gcásanna neamhchoitianta, mar theip ar fhreastalaí, seans go bhfeicfidh tú an comhad cúltaca seo. Scriostar an comhad cúltaca an chéad uair eile a luchtaítear na heochracha (go hiondúil tar éis an freastalaí a atosú).
Agus eochair i stór freastalaí á sábháil nó á scriosadh, ní mór don stóras nascadh leis an bhfreastalaí MySQL leis na horduithe “seol an eochair” / “iarr scriosadh eochrach”.
Fillfimid ar luas tosaithe an fhreastalaí. Chomh maith leis an bhfíric go bhfuil tionchar ag an luas seolta ag an cruinneachán féin, tá ceist ann freisin cé mhéad eochair ón cruinneachán is gá a aisghabháil ag am tosaithe. Ar ndóigh, tá sé seo tábhachtach go háirithe le haghaidh stórála freastalaí. Ag am tosaithe, seiceálann an freastalaí an eochair atá ag teastáil le haghaidh táblaí/spásanna boird criptithe agus iarrann sé an eochair ón stóras. Ar fhreastalaí “glan” le criptiú Máistir-Eochair, ní mór Máistir Eochair amháin a bheith ann, a chaithfear a aisghabháil ón stóras. Mar sin féin, d'fhéadfadh go mbeadh gá le líon níos mó eochracha, mar shampla, nuair a bhíonn an freastalaí cúltaca ag athchóiriú cúltaca ón bhfreastalaí bunscoile. I gcásanna den sórt sin, ba cheart rothlú an Mháistir-Eochair a sholáthar. Clúdófar é seo níos mine in ailt amach anseo, cé gur mhaith liom a thabhairt faoi deara anseo go bhféadfadh sé go dtógfadh sé beagán níos faide chun freastalaí a úsáideann Máistir-Eochracha iolracha a thosú, go háirithe nuair a bhíonn stór eochair taobh an fhreastalaí á úsáid.
Anois, déanaimis labhairt beagán níos mó faoi keyring_file. Nuair a bhí keyring_file á fhorbairt agam, bhí imní orm freisin faoi conas a sheiceáil le haghaidh athruithe keyring_file agus an freastalaí ag rith. I 5.7, rinneadh an seiceáil bunaithe ar staitisticí comhaid, rud nach raibh ina réiteach idéalach, agus i 8.0 cuireadh seic SHA256 ina ionad.
An chéad uair a ritheann tú keyring_file, ríomhtar staitisticí comhaid agus seic, a chuimhníonn an freastalaí, agus ní chuirtear athruithe i bhfeidhm ach amháin má mheaitseálann siad. Nuair a athraíonn an comhad, déantar an seic a nuashonrú.
Tá go leor ceisteanna clúdaithe againn cheana féin maidir le boghtaí tábhachtacha. Mar sin féin, tá ábhar tábhachtach eile a dhéantar dearmad nó míthuiscint go minic: eochracha a roinnt ar fud na freastalaithe.
Cad atá i gceist agam? Caithfidh suíomh ar leith a bheith ag gach freastalaí (mar shampla, Percona Server) sa bhraisle ar an bhFreastalaí Vault ina gcaithfidh Percona Server a chuid eochracha a stóráil. Tá GUID an Fhreastalaí Percona laistigh dá aitheantóir i ngach Máistireochair a shábháiltear sa stóras. Cén fáth a bhfuil sé tábhachtach? Samhlaigh nach bhfuil ach Freastalaí cruinneachán amháin agat agus go n-úsáideann gach Freastalaí Percona sa bhraisle an Freastalaí cruinneachán singil. Is cosúil go bhfuil an fhadhb soiléir. Dá n-úsáidfeadh gach Freastalaí Percona Máistir Eochair gan aitheantóirí uathúla, mar shampla id = 1, id = 2, etc., d'úsáidfeadh gach freastalaí sa bhraisle an Máistir Eochair chéanna. Is é an rud a sholáthraíonn an GUID ná an t-idirdhealú idir freastalaithe. Cén fáth mar sin labhairt faoi eochracha a roinnt idir freastalaithe má tá GUID uathúil ann cheana féin? Tá breiseán eile ann - keyring_udf. Leis an mbreiseán seo, is féidir le d'úsáideoir freastalaí a n-eochracha a stóráil ar an bhfreastalaí Vault. Tarlaíonn an fhadhb nuair a chruthaíonn úsáideoir eochair ar server1, mar shampla, agus ansin déanann sé iarracht eochair a chruthú leis an ID céanna ar server2, mar shampla:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Fan. Tá an Freastalaí Vault céanna á úsáid ag an dá fhreastalaí, nár cheart go dteipfeadh ar an bhfeidhm keyring_key_store ar server2? Suimiúil go leor, má dhéanann tú iarracht an rud céanna a dhéanamh ar fhreastalaí amháin, gheobhaidh tú earráid:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Sin ceart, tá ROB_1 ann cheana féin.
Déanaimis an dara sampla a phlé ar dtús. Mar a dúirt muid níos luaithe, déanann keyring_vault nó breiseán eochairfháinne ar bith eile gach eochair-aitheantas a thaisceadh i gcuimhne. Mar sin, tar éis eochair nua a chruthú, cuirtear ROB_1 le server1, agus chomh maith leis an eochair seo a sheoladh chuig Vault, cuirtear an eochair leis an taisce freisin. Anois, nuair a dhéanaimid iarracht an eochair chéanna a chur leis an dara huair, seiceálann keyring_vault an bhfuil an eochair sa taisce agus caitheann sé earráid.
Sa chéad chás tá an scéal difriúil. Tá taisce ar leith ag Server1 agus server2. Tar éis ROB_1 a chur leis an taisce eochrach ar server1 agus ar an bhfreastalaí Vault, níl an taisce eochrach ar server2 as sioncronú. Níl aon eochair ROB_2 sa taisce ar server1. Mar sin, scríobhtar an eochair ROB_1 chuig an keyring_key_store agus chuig an bhfreastalaí Vault, a fhorscríobhann (!) an luach roimhe seo. Anois is í an eochair ROB_1 ar an bhfreastalaí Vault ná 543210987654321. Díol spéise é nach gcuireann an freastalaí Vault bac ar ghníomhartha den sórt sin agus déanann sé an seanluach a fhorscríobh go héasca.
Anois is féidir linn a fheiceáil cén fáth gur féidir le deighilt freastalaí i Vault a bheith tábhachtach - nuair a bhíonn keyring_udf á úsáid agat agus gur mhaith leat eochracha a stóráil i Vault. Conas an scaradh seo a bhaint amach ar fhreastalaí cruinneachán?
Tá dhá bhealach ann le deighilt isteach i Cruinneachán. Is féidir leat pointí gléasta éagsúla a chruthú do gach freastalaí, nó cosáin éagsúla a úsáid laistigh den phointe suite céanna. Is fearr é seo a léiriú le samplaí. Mar sin déanaimis féachaint ar na pointí mount aonair ar dtús:
--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 = (...)Anseo is féidir leat a fheiceáil go bhfuil server1 agus server2 ag baint úsáide as pointí gléasta éagsúla. Agus na cosáin á scoilteadh, beidh cuma mar seo ar an gcumraíocht:
--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 = (...)Sa chás seo, úsáideann an dá fhreastalaí an pointe mount céanna "mount_point", ach cosáin éagsúla. Nuair a chruthaíonn tú an chéad rún ar server1 ag baint úsáide as an gcosán seo, cruthaíonn an freastalaí Vault eolaire “freastalaí1” go huathoibríoch. Do server2 tá gach rud cosúil. Nuair a scriosann tú an rún deireanach in mount_point/server1 nó mount_point/server2, scriosann an freastalaí Vault na heolairí sin freisin. I gcás go n-úsáideann tú scaradh cosáin, níor cheart duit ach pointe mount amháin a chruthú agus na comhaid cumraíochta a athrú ionas go n-úsáideann na freastalaithe cosáin ar leith. Is féidir pointe gléasta a chruthú trí iarratas HTTP a úsáid. Ag baint úsáide as CURL is féidir é seo a dhéanamh mar seo:
curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTFreagraíonn gach réimse (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) do pharaiméadair an chomhaid chumraíochta. Ar ndóigh, is féidir leat fóntais Vault a úsáid chun an rud céanna a dhéanamh. Ach tá sé níos éasca cruthú pointe mount a uathoibriú. Tá súil agam go mbeidh an t-eolas seo úsáideach duit agus feicfidh muid tú sna chéad ailt eile sa tsraith seo.
Leigh Nios mo:
Foinse: will.com