కోర్సు కోసం కొత్త నమోదు ప్రారంభానికి ఎదురుచూస్తూ మేము మీ కోసం ఉపయోగకరమైన కథనం యొక్క అనువాదాన్ని సిద్ధం చేసాము.
పారదర్శక డేటా ఎన్‌క్రిప్షన్ (TDE) కనిపించింది మరియు కొంతకాలం MySQL. అయితే ఇది హుడ్ కింద ఎలా పని చేస్తుందో మరియు మీ సర్వర్‌పై TDE ఎలాంటి ప్రభావం చూపుతుందో మీరు ఎప్పుడైనా ఆలోచించారా? ఈ కథనాల శ్రేణిలో మేము TDE అంతర్గతంగా ఎలా పనిచేస్తుందో చూద్దాం. కీ స్టోరేజ్‌తో ప్రారంభిద్దాం, ఎందుకంటే ఏదైనా ఎన్‌క్రిప్షన్ పని చేయడానికి ఇది అవసరం. MySQL/MySQL కోసం పెర్కోనా సర్వర్‌లో ఎన్‌క్రిప్షన్ ఎలా పని చేస్తుందో మరియు MySQL కోసం పెర్కోనా సర్వర్ ఏ అదనపు ఫీచర్లను కలిగి ఉందో మేము నిశితంగా పరిశీలిస్తాము.
MySQL కీరింగ్
కీరింగ్ అనేది స్థానిక ఫైల్ (keyring_file) లేదా రిమోట్ సర్వర్‌లో (హాషికార్ప్ వాల్ట్ వంటివి) కీలను ప్రశ్నించడానికి, సృష్టించడానికి మరియు తొలగించడానికి సర్వర్‌ను అనుమతించే ప్లగిన్‌లు. కీలు వాటి పునరుద్ధరణను వేగవంతం చేయడానికి ఎల్లప్పుడూ స్థానికంగా కాష్ చేయబడతాయి.
ప్లగిన్‌లను రెండు వర్గాలుగా విభజించవచ్చు:
- స్థానిక నిల్వ. ఉదాహరణకు, లోకల్ ఫైల్ (దీనిని మేము ఫైల్ ఆధారిత కీరింగ్ అని పిలుస్తాము).
- రిమోట్ నిల్వ. ఉదాహరణకు, వాల్ట్ సర్వర్ (మేము దీనిని సర్వర్-ఆధారిత కీరింగ్ అని పిలుస్తాము).
ఈ విభజన ముఖ్యమైనది ఎందుకంటే వివిధ రకాలైన నిల్వలు కొద్దిగా భిన్నంగా ప్రవర్తిస్తాయి, కీలను నిల్వ చేసేటప్పుడు మరియు తిరిగి పొందేటప్పుడు మాత్రమే కాకుండా, వాటిని అమలు చేస్తున్నప్పుడు కూడా.
ఫైల్ స్టోరేజ్‌ని ఉపయోగిస్తున్నప్పుడు, స్టార్టప్‌లో, స్టోరేజ్‌లోని మొత్తం కంటెంట్‌లు కాష్‌లోకి లోడ్ చేయబడతాయి: కీ ఐడి, కీ యూజర్, కీ రకం మరియు కీ కూడా.
సర్వర్ సైడ్ స్టోర్ (వాల్ట్ సర్వర్ వంటివి) విషయంలో, స్టార్టప్‌లో కీ ఐడి మరియు కీ యూజర్ మాత్రమే లోడ్ చేయబడతారు, కాబట్టి అన్ని కీలను పొందడం వల్ల స్టార్టప్ నెమ్మదించదు. కీలు బద్ధకంగా లోడ్ చేయబడ్డాయి. అంటే, కీ వాస్తవానికి అవసరమైనప్పుడు మాత్రమే వాల్ట్ నుండి లోడ్ చేయబడుతుంది. డౌన్‌లోడ్ చేసిన తర్వాత, కీ మెమరీలో కాష్ చేయబడుతుంది, తద్వారా భవిష్యత్తులో వాల్ట్ సర్వర్‌కు TLS కనెక్షన్‌ల ద్వారా యాక్సెస్ చేయవలసిన అవసరం ఉండదు. తర్వాత, కీ స్టోర్‌లో ఏ సమాచారం ఉందో చూద్దాం.
కీలక సమాచారం క్రింది వాటిని కలిగి ఉంది:
- కీ id - కీ ఐడెంటిఫైయర్, ఉదాహరణకు:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - కీ రకం — ఉపయోగించిన ఎన్‌క్రిప్షన్ అల్గారిథమ్ ఆధారంగా కీ రకం, సాధ్యమయ్యే విలువలు: “AES”, “RSA” లేదా “DSA”.
- కీ పొడవు — బైట్‌లలో కీ పొడవు, AES: 16, 24 లేదా 32, RSA 128, 256, 512 మరియు DSA 128, 256 లేదా 384.
- యూజర్ - కీ యజమాని. కీ సిస్టమ్ అయితే, ఉదాహరణకు, మాస్టర్ కీ, అప్పుడు ఈ ఫీల్డ్ ఖాళీగా ఉంటుంది. keyring_udf ఉపయోగించి కీ సృష్టించబడితే, ఈ ఫీల్డ్ కీ యజమానిని గుర్తిస్తుంది.
- కీ కూడా
ఈ జంట ద్వారా కీ ప్రత్యేకంగా గుర్తించబడుతుంది: key_id, వినియోగదారు.
కీలను నిల్వ చేయడం మరియు తొలగించడంలో కూడా తేడాలు ఉన్నాయి.
ఫైల్ నిల్వ వేగంగా ఉంటుంది. కీ స్టోర్ ఫైల్‌కి కీని ఒకసారి వ్రాస్తోందని మీరు అనుకోవచ్చు, కానీ లేదు, ఇక్కడ ఇంకా ఎక్కువ జరుగుతోంది. ఫైల్ నిల్వ మార్పు చేసినప్పుడల్లా, మొత్తం కంటెంట్ యొక్క బ్యాకప్ కాపీ మొదట సృష్టించబడుతుంది. ఫైల్‌ని my_biggest_secrets అని అనుకుందాం, అప్పుడు బ్యాకప్ కాపీ my_biggest_secrets.backup అవుతుంది. తరువాత, కాష్ మార్చబడుతుంది (కీలు జోడించబడతాయి లేదా తొలగించబడతాయి) మరియు ప్రతిదీ విజయవంతమైతే, కాష్ ఫైల్‌కి రీసెట్ చేయబడుతుంది. సర్వర్ వైఫల్యం వంటి అరుదైన సందర్భాల్లో, మీరు ఈ బ్యాకప్ ఫైల్‌ను చూడవచ్చు. తదుపరిసారి కీలు లోడ్ అయినప్పుడు బ్యాకప్ ఫైల్ తొలగించబడుతుంది (సాధారణంగా సర్వర్ పునఃప్రారంభించిన తర్వాత).
సర్వర్ స్టోరేజ్‌లో కీని సేవ్ చేస్తున్నప్పుడు లేదా తొలగించేటప్పుడు, స్టోరేజ్ తప్పనిసరిగా MySQL సర్వర్‌కు “కీని పంపండి” / “కీ తొలగింపును అభ్యర్థించండి” అనే ఆదేశాలతో కనెక్ట్ చేయాలి.
సర్వర్ స్టార్టప్ స్పీడ్‌కి తిరిగి వద్దాం. ప్రయోగ వేగం ఖజానా ద్వారానే ప్రభావితమవుతుంది అనే వాస్తవంతో పాటు, స్టార్టప్‌లో వాల్ట్ నుండి ఎన్ని కీలను తిరిగి పొందాలి అనే సమస్య కూడా ఉంది. వాస్తవానికి, సర్వర్ నిల్వ కోసం ఇది చాలా ముఖ్యమైనది. ప్రారంభంలో, సర్వర్ ఎన్‌క్రిప్టెడ్ టేబుల్‌లు/టేబుల్‌స్పేస్‌ల కోసం ఏ కీ అవసరమో తనిఖీ చేస్తుంది మరియు నిల్వ నుండి కీని అభ్యర్థిస్తుంది. మాస్టర్ కీ ఎన్‌క్రిప్షన్‌తో కూడిన “క్లీన్” సర్వర్‌లో, తప్పనిసరిగా ఒక మాస్టర్ కీ ఉండాలి, అది తప్పనిసరిగా నిల్వ నుండి తిరిగి పొందబడుతుంది. అయినప్పటికీ, పెద్ద సంఖ్యలో కీలు అవసరం కావచ్చు, ఉదాహరణకు, బ్యాకప్ సర్వర్ ప్రాథమిక సర్వర్ నుండి బ్యాకప్‌ను పునరుద్ధరించినప్పుడు. అటువంటి సందర్భాలలో, మాస్టర్ కీ యొక్క భ్రమణాన్ని అందించాలి. భవిష్యత్ కథనాలలో ఇది మరింత వివరంగా వివరించబడుతుంది, అయినప్పటికీ బహుళ మాస్టర్ కీలను ఉపయోగించే సర్వర్ ప్రారంభించడానికి కొంత సమయం పట్టవచ్చని నేను ఇక్కడ గమనించాలనుకుంటున్నాను, ప్రత్యేకించి సర్వర్ సైడ్ కీ స్టోర్‌ని ఉపయోగిస్తున్నప్పుడు.
ఇప్పుడు keyring_file గురించి కొంచెం ఎక్కువ మాట్లాడుకుందాం. నేను keyring_fileని డెవలప్ చేస్తున్నప్పుడు, సర్వర్ రన్ అవుతున్నప్పుడు keyring_file మార్పులను ఎలా తనిఖీ చేయాలనే దాని గురించి కూడా నేను ఆందోళన చెందాను. 5.7లో, ఫైల్ గణాంకాల ఆధారంగా తనిఖీ నిర్వహించబడింది, ఇది సరైన పరిష్కారం కాదు మరియు 8.0లో అది SHA256 చెక్‌సమ్‌తో భర్తీ చేయబడింది.
మీరు మొదటిసారి keyring_fileని అమలు చేసినప్పుడు, ఫైల్ గణాంకాలు మరియు చెక్‌సమ్ లెక్కించబడతాయి, వీటిని సర్వర్ గుర్తుంచుకుంటుంది మరియు మార్పులు సరిపోలితే మాత్రమే వర్తిస్తాయి. ఫైల్ మారినప్పుడు, చెక్‌సమ్ నవీకరించబడుతుంది.
కీ వాల్ట్‌ల గురించి మేము ఇప్పటికే చాలా ప్రశ్నలను కవర్ చేసాము. అయినప్పటికీ, తరచుగా మరచిపోయే లేదా తప్పుగా అర్థం చేసుకునే మరొక ముఖ్యమైన అంశం ఉంది: సర్వర్‌లలో కీలను భాగస్వామ్యం చేయడం.
నేను చెప్పేది ఏమిటంటే? క్లస్టర్‌లోని ప్రతి సర్వర్ (ఉదాహరణకు, పెర్కోనా సర్వర్) తప్పనిసరిగా వాల్ట్ సర్వర్‌లో ప్రత్యేక స్థానాన్ని కలిగి ఉండాలి, దీనిలో పెర్కోనా సర్వర్ తప్పనిసరిగా దాని కీలను నిల్వ చేయాలి. నిల్వలో సేవ్ చేయబడిన ప్రతి మాస్టర్ కీ దాని ఐడెంటిఫైయర్‌లో Percona సర్వర్ యొక్క GUIDని కలిగి ఉంటుంది. ఇది ఎందుకు ముఖ్యమైనది? మీకు ఒకే ఒక వాల్ట్ సర్వర్ ఉందని మరియు క్లస్టర్‌లోని అన్ని పెర్కోనా సర్వర్లు ఈ ఒక్క వాల్ట్ సర్వర్‌ని ఉపయోగిస్తాయని ఊహించండి. సమస్య స్పష్టంగా కనిపిస్తోంది. అన్ని Percona సర్వర్లు id = 1, id = 2, మొదలైన ప్రత్యేక ఐడెంటిఫైయర్‌లు లేకుండా మాస్టర్ కీని ఉపయోగిస్తే, క్లస్టర్‌లోని అన్ని సర్వర్లు ఒకే మాస్టర్ కీని ఉపయోగిస్తాయి. GUID అందించేది సర్వర్‌ల మధ్య వ్యత్యాసం. ప్రత్యేకమైన GUID ఇప్పటికే ఉన్నట్లయితే సర్వర్‌ల మధ్య కీలను భాగస్వామ్యం చేయడం గురించి ఎందుకు మాట్లాడాలి? మరొక ప్లగ్ఇన్ ఉంది - keyring_udf. ఈ ప్లగ్ఇన్‌తో, మీ సర్వర్ వినియోగదారు వారి కీలను వాల్ట్ సర్వర్‌లో నిల్వ చేయవచ్చు. వినియోగదారు సర్వర్ 1లో కీని సృష్టించినప్పుడు సమస్య ఏర్పడుతుంది, ఉదాహరణకు, సర్వర్ 2లో అదే IDతో కీని సృష్టించడానికి ప్రయత్నించినప్పుడు, ఉదాహరణకు:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1వేచి ఉండండి. రెండు సర్వర్లు ఒకే వాల్ట్ సర్వర్‌ని ఉపయోగిస్తున్నాయి, సర్వర్2లో keyring_key_store ఫంక్షన్ విఫలం కాకూడదా? ఆసక్తికరంగా, మీరు ఒక సర్వర్‌లో అదే చేయడానికి ప్రయత్నిస్తే, మీరు ఎర్రర్‌ను అందుకుంటారు:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0అది నిజం, ROB_1 ఇప్పటికే ఉంది.
ముందుగా రెండవ ఉదాహరణను చర్చిద్దాం. మేము ఇంతకు ముందే చెప్పినట్లుగా, keyring_vault లేదా ఏదైనా ఇతర కీరింగ్ ప్లగ్ఇన్ మెమరీలోని అన్ని కీ IDలను కాష్ చేస్తుంది. కాబట్టి, కొత్త కీని సృష్టించిన తర్వాత, ROB_1 సర్వర్ 1కి జోడించబడుతుంది మరియు ఈ కీని వాల్ట్‌కి పంపడంతో పాటు, కీ కాష్‌కి కూడా జోడించబడుతుంది. ఇప్పుడు, మేము అదే కీని రెండవసారి జోడించడానికి ప్రయత్నించినప్పుడు, keyring_vault కీ కాష్‌లో ఉందో లేదో తనిఖీ చేస్తుంది మరియు లోపాన్ని విసురుతుంది.
మొదటి సందర్భంలో, పరిస్థితి భిన్నంగా ఉంటుంది. సర్వర్ 1 మరియు సర్వర్ 2 ప్రత్యేక కాష్‌లను కలిగి ఉన్నాయి. సర్వర్1 మరియు వాల్ట్ సర్వర్‌లోని కీ కాష్‌కి ROB_1ని జోడించిన తర్వాత, సర్వర్2లోని కీ కాష్ సమకాలీకరించబడలేదు. సర్వర్2లోని కాష్‌లో ROB_1 కీ లేదు. అందువలన, ROB_1 కీ keyring_key_store మరియు వాల్ట్ సర్వర్‌కు వ్రాయబడుతుంది, ఇది వాస్తవానికి మునుపటి విలువను (!) ఓవర్‌రైట్ చేస్తుంది. ఇప్పుడు వాల్ట్ సర్వర్‌లోని ROB_1 కీ 543210987654321. ఆసక్తికరంగా, వాల్ట్ సర్వర్ అటువంటి చర్యలను నిరోధించదు మరియు పాత విలువను సులభంగా ఓవర్‌రైట్ చేస్తుంది.
వాల్ట్‌లో సర్వర్ విభజన ఎందుకు ముఖ్యమైనదో ఇప్పుడు మనం చూడవచ్చు - మీరు keyring_udfని ఉపయోగిస్తున్నప్పుడు మరియు వాల్ట్‌లో కీలను నిల్వ చేయాలనుకున్నప్పుడు. వాల్ట్ సర్వర్‌లో ఈ విభజనను ఎలా సాధించాలి?
వాల్ట్‌గా విభజించడానికి రెండు మార్గాలు ఉన్నాయి. మీరు ప్రతి సర్వర్‌కు వేర్వేరు మౌంట్ పాయింట్లను సృష్టించవచ్చు లేదా ఒకే మౌంట్ పాయింట్‌లో వేర్వేరు మార్గాలను ఉపయోగించవచ్చు. ఇది ఉదాహరణలతో ఉత్తమంగా వివరించబడింది. కాబట్టి ముందుగా వ్యక్తిగత మౌంట్ పాయింట్లను చూద్దాం:
--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 = (...)సర్వర్1 మరియు సర్వర్2 వేర్వేరు మౌంట్ పాయింట్లను ఉపయోగిస్తున్నట్లు ఇక్కడ మీరు చూడవచ్చు. మార్గాలను విభజించేటప్పుడు, కాన్ఫిగరేషన్ ఇలా కనిపిస్తుంది:
--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 = (...)ఈ సందర్భంలో, రెండు సర్వర్లు ఒకే మౌంట్ పాయింట్ "మౌంట్_పాయింట్"ని ఉపయోగిస్తాయి, కానీ వేర్వేరు మార్గాలు. మీరు ఈ మార్గాన్ని ఉపయోగించి సర్వర్1లో మొదటి రహస్యాన్ని సృష్టించినప్పుడు, వాల్ట్ సర్వర్ స్వయంచాలకంగా “సర్వర్1” డైరెక్టరీని సృష్టిస్తుంది. సర్వర్ 2 కోసం ప్రతిదీ సమానంగా ఉంటుంది. మీరు mount_point/server1 లేదా mount_point/server2లో చివరి రహస్యాన్ని తొలగించినప్పుడు, Vault సర్వర్ ఆ డైరెక్టరీలను కూడా తొలగిస్తుంది. మీరు పాత్ సెపరేషన్‌ని ఉపయోగిస్తే, మీరు తప్పనిసరిగా ఒక మౌంట్ పాయింట్‌ను మాత్రమే సృష్టించాలి మరియు కాన్ఫిగరేషన్ ఫైల్‌లను మార్చాలి, తద్వారా సర్వర్లు ప్రత్యేక మార్గాలను ఉపయోగిస్తాయి. HTTP అభ్యర్థనను ఉపయోగించి మౌంట్ పాయింట్‌ని సృష్టించవచ్చు. CURLని ఉపయోగించి దీన్ని ఇలా చేయవచ్చు:
curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTఅన్ని ఫీల్డ్‌లు (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) కాన్ఫిగరేషన్ ఫైల్ యొక్క పారామితులకు అనుగుణంగా ఉంటాయి. వాస్తవానికి, మీరు అదే చేయడానికి వాల్ట్ యుటిలిటీలను ఉపయోగించవచ్చు. కానీ మౌంట్ పాయింట్ యొక్క సృష్టిని ఆటోమేట్ చేయడం సులభం. ఈ సమాచారం మీకు ఉపయోగకరంగా ఉంటుందని నేను ఆశిస్తున్నాను మరియు ఈ సిరీస్‌లోని తదుపరి కథనాలలో మిమ్మల్ని చూస్తాము.
ఇంకా చదవండి:
మూలం: www.habr.com