ለትምህርቱ አዲስ ምዝገባ እንደሚጀምር በመጠባበቅ ላይ ለእርስዎ ጠቃሚ የሆነ ጽሑፍ ትርጉም አዘጋጅተናል.
ግልጽ የውሂብ ምስጠራ (TDE) በ ውስጥ ታየ እና MySQL ለተወሰነ ጊዜ። ነገር ግን በኮፍያ ስር እንዴት እንደሚሰራ እና TDE በአገልጋይዎ ላይ ምን ተጽእኖ ሊኖረው እንደሚችል አስበህ ታውቃለህ? በዚህ ተከታታይ መጣጥፎች ውስጥ TDE በውስጥ እንዴት እንደሚሰራ እንመለከታለን። ለማንኛውም ምስጠራ እንዲሰራ ይህ ስለሚያስፈልግ በቁልፍ ማከማቻ እንጀምር። ከዚያም ምስጠራ በፐርኮና አገልጋይ ለ MySQL/MySQL እንዴት እንደሚሰራ እና የፐርኮና አገልጋይ ለ MySQL ምን ተጨማሪ ባህሪያት እንዳሉት በዝርዝር እንመለከታለን።
MySQL ኪይንግ
ኪይንግ አገልጋዩ በአካባቢያዊ ፋይል (keyring_file) ወይም በርቀት አገልጋይ (እንደ HashiCorp Vault ያሉ) ቁልፎችን እንዲጠይቅ፣ እንዲፈጥር እና እንዲሰርዝ የሚፈቅዱ ተሰኪዎች ናቸው። ሰርስሮቻቸውን ለማፋጠን ቁልፎች ሁል ጊዜ በአገር ውስጥ ተደብቀዋል።
ተሰኪዎች በሁለት ምድቦች ሊከፈሉ ይችላሉ-
- የአካባቢ ማከማቻ. ለምሳሌ፣ የአካባቢ ፋይል (ይህንን በፋይል ላይ የተመሰረተ ቁልፍ መደወል ብለን እንጠራዋለን)።
- የርቀት ማከማቻ. ለምሳሌ ቮልት ሰርቨር (ይህንን በአገልጋይ ላይ የተመሰረተ ቁልፍ መደወል እንላለን)።
ይህ መለያየት አስፈላጊ ነው ምክንያቱም የተለያዩ የማከማቻ ዓይነቶች ቁልፎችን በማከማቸት እና በማንሳት ላይ ብቻ ሳይሆን በሚሰሩበት ጊዜም በመጠኑ የተለየ ባህሪ አላቸው.
የፋይል ማከማቻ ሲጠቀሙ፣ ሲጀመር፣ የማከማቻው አጠቃላይ ይዘቶች በመሸጎጫው ውስጥ ይጫናሉ፡ የቁልፍ መታወቂያ፣ የቁልፍ ተጠቃሚ፣ የቁልፍ አይነት እና ቁልፉ ራሱ።
በአገልጋይ ላይ የተመሰረተ ሱቅ (እንደ ቮልት ሰርቨር ያለ) ሲነሳ ቁልፍ መታወቂያ እና ቁልፍ ተጠቃሚ ብቻ ነው የሚጫነው ስለዚህ ሁሉንም ቁልፎች ማግኘት ጅምርን አያዘገየውም። ቁልፎች በስንፍና ተጭነዋል። ማለትም ቁልፉ ራሱ ከቮልት የሚጫነው በትክክል በሚያስፈልግበት ጊዜ ብቻ ነው። አንዴ ከወረደ በኋላ ቁልፉ በTLS ግንኙነት ከቮልት አገልጋዩ ጋር እንዳይገናኝ በማህደረ ትውስታ ውስጥ ተከማችቷል። በመቀጠል፣ በቁልፍ ማከማቻ ውስጥ ምን ዓይነት መረጃ እንደሚገኝ እንመልከት።
ዋናው መረጃ የሚከተሉትን ያካትታል:
- ቁልፍ መታወቂያ - ቁልፍ ለዪ፣ ለምሳሌ፡-
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፣ ተጠቃሚ።
ቁልፎችን በማከማቸት እና በመሰረዝ ላይም ልዩነቶች አሉ.
የፋይል ማከማቻ ፈጣን ነው። አንድ የቁልፍ መደብር በቀላሉ የፋይል ቁልፉን አንድ ጊዜ እየጻፈ ነው ብለው ያስቡ ይሆናል፣ ግን አይሆንም፣ እዚህ ተጨማሪ ነገር አለ። የፋይል ማከማቻ ማሻሻያ በተደረገ ቁጥር መጀመሪያ የሁሉም ይዘቶች ምትኬ ቅጂ ይፈጠራል። ፋይሉ የእኔ_ትልቅ_ምስጢሮች ይባላል እንበል፣ ከዚያ የመጠባበቂያ ቅጂው የእኔ_ትልቅ_ምስጢሮች.ባክአፕ ይሆናል። በመቀጠል, መሸጎጫው ይቀየራል (ቁልፎቹ ተጨምረዋል ወይም ይሰረዛሉ) እና ሁሉም ነገር ከተሳካ, መሸጎጫው ወደ ፋይል እንደገና ይጀመራል. እንደ አገልጋይ አለመሳካት ባሉ አልፎ አልፎ፣ ይህን የመጠባበቂያ ፋይል ሊያዩ ይችላሉ። የመጠባበቂያ ፋይሉ በሚቀጥለው ጊዜ ቁልፎቹ በሚጫኑበት ጊዜ ይሰረዛሉ (ብዙውን ጊዜ አገልጋዩ እንደገና ከተጀመረ በኋላ)።
በአገልጋይ ማከማቻ ውስጥ ቁልፍን ሲያስቀምጡ ወይም ሲሰርዙ ማከማቻው ከ MySQL አገልጋይ ጋር መገናኘት አለበት "ቁልፉን ላክ" / "ቁልፍ ስረዛን ይጠይቁ" በሚለው ትዕዛዝ.
ወደ አገልጋይ ጅምር ፍጥነት እንመለስ። የማስጀመሪያው ፍጥነት በራሱ ቮልት ላይ ተጽእኖ ከማሳደሩ በተጨማሪ፣ ሲነሳ ምን ያህል ቁልፎች ከቮልት ማግኘት እንዳለባቸውም ጭምር ነው። በእርግጥ ይህ በተለይ ለአገልጋይ ማከማቻ አስፈላጊ ነው። ሲጀመር አገልጋዩ ለተመሰጠሩ ጠረጴዛዎች/ጠረጴዛዎች የትኛው ቁልፍ እንደሚያስፈልግ ያጣራል እና ቁልፉን ከማከማቻው ይጠይቃል። ማስተር ቁልፍ ምስጠራ ባለው “ንፁህ” አገልጋይ ላይ አንድ ማስተር ቁልፍ መኖር አለበት፣ እሱም ከማከማቻው መውጣት አለበት። ነገር ግን፣ ብዙ ቁጥር ያላቸው ቁልፎች ሊያስፈልጉ ይችላሉ፣ ለምሳሌ፣ መጠባበቂያ አገልጋዩ ከዋናው አገልጋይ የመጠባበቂያ ቅጂ ወደነበረበት ሲመለስ። በእንደዚህ ዓይነት ሁኔታዎች, የማስተር ቁልፍ መዞር መሰጠት አለበት. ይህ ወደፊት በሚወጡት መጣጥፎች ላይ በበለጠ ዝርዝር ይብራራል፣ ምንም እንኳን እዚህ ላይ ብዙ ማስተር ቁልፎችን የሚጠቀም አገልጋይ በተለይም የአገልጋይ-ጎን ቁልፍ ማከማቻ ሲጠቀም ለመጀመር ትንሽ ጊዜ ሊወስድ እንደሚችል ልብ ማለት እፈልጋለሁ።
አሁን ስለ ኪይሪንግ_ፋይል ትንሽ እንነጋገር። የኪይሪንግ_ፋይል ልማትን እያዘጋጀሁ በነበረበት ጊዜ አገልጋዩ በሚሰራበት ጊዜ የኪይሪንግ_ፋይል ለውጦችን እንዴት ማረጋገጥ እንደምችል አሳስቦኝ ነበር። በ 5.7 ውስጥ, ቼኩ የተከናወነው በፋይል ስታቲስቲክስ መሰረት ነው, ይህም ተስማሚ መፍትሄ አልነበረም, እና በ 8.0 ውስጥ በ SHA256 ቼክ ተተካ.
ለመጀመሪያ ጊዜ ኪይሪንግ_ፋይል ሲያሄዱ የፋይል ስታቲስቲክስ እና ቼክ ድምር ይሰላሉ፣ እነዚህም በአገልጋዩ ይታወሳሉ፣ እና ለውጦች የሚተገበሩት ከተዛመደ ብቻ ነው። ፋይሉ ሲቀየር ቼክሱሙ ይዘምናል።
ስለ ቁልፍ ካዝናዎች ብዙ ጥያቄዎችን አስቀድመን ሸፍነናል። ሆኖም፣ ብዙ ጊዜ የሚረሳ ወይም ያልተረዳ ሌላ ጠቃሚ ርዕስ አለ፡ ቁልፎችን በአገልጋዮች ላይ ማጋራት።
ማለቴ? በክላስተር ውስጥ ያለ እያንዳንዱ አገልጋይ (ለምሳሌ ፐርኮና አገልጋይ) በቮልት አገልጋይ ላይ የፐርኮና አገልጋይ ቁልፎቹን የሚያከማችበት የተለየ ቦታ ሊኖረው ይገባል። በማከማቻው ውስጥ የተቀመጠ እያንዳንዱ ዋና ቁልፍ የፐርኮና አገልጋይ GUID በዪው ውስጥ ይይዛል። ለምን አስፈላጊ ነው? አንድ የቮልት አገልጋይ ብቻ እንዳለህ አስብ እና በክላስተር ውስጥ ያሉ ሁሉም የፐርኮና ሰርቨሮች ያንን ነጠላ ቮልት አገልጋይ ይጠቀማሉ። ችግሩ ግልጽ ይመስላል. ሁሉም የፐርኮና ሰርቨሮች ማስተር ቁልፍን ያለ ልዩ መለያዎች ለምሳሌ id = 1፣ id = 2፣ ወዘተ. ከተጠቀሙ በክላስተር ውስጥ ያሉ ሁሉም አገልጋዮች አንድ አይነት ማስተር ቁልፍ ይጠቀማሉ። GUID የሚያቀርበው በአገልጋዮች መካከል ያለው ልዩነት ነው። ልዩ GUID አስቀድሞ ካለ በአገልጋዮች መካከል ቁልፎችን ስለማጋራት ለምን ይናገሩ? ሌላ ተሰኪ አለ - keyring_udf. በዚህ ፕለጊን የአገልጋይ ተጠቃሚዎ ቁልፎቹን በቮልት አገልጋይ ላይ ማከማቸት ይችላል። ችግሩ የሚፈጠረው አንድ ተጠቃሚ ለምሳሌ በአገልጋይ 1 ላይ ቁልፍ ሲፈጥር እና በአገልጋይ 2 ላይ ተመሳሳይ መታወቂያ ያለው ቁልፍ ለመፍጠር ሲሞክር ነው፡- ለምሳሌ፡-
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1ጠብቅ. ሁለቱም አገልጋዮች አንድ አይነት የቮልት ሰርቨር እየተጠቀሙ ነው፣የkeyring_key_store ተግባር በአገልጋይ2 ላይ መክሸፍ የለበትም? የሚገርመው፣ በአንድ አገልጋይ ላይ ተመሳሳይ ነገር ለማድረግ ከሞከሩ፣ ስህተት ይደርስዎታል፡-
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0ትክክል ነው፣ ROB_1 አስቀድሞ አለ።
በመጀመሪያ ሁለተኛውን ምሳሌ እንወያይ። ቀደም ሲል እንደተናገርነው፣ keyring_vault ወይም ሌላ ማንኛውም የቁልፍ ማድረጊያ ፕለጊን ሁሉንም ቁልፍ መታወቂያዎች በማህደረ ትውስታ ውስጥ ይደብቃል። ስለዚህ፣ አዲስ ቁልፍ ከፈጠሩ በኋላ፣ ROB_1 ወደ አገልጋይ 1 ይጨመራል፣ እና ይህን ቁልፍ ወደ ቮልት ከመላክ በተጨማሪ ቁልፉ ወደ መሸጎጫው ይታከላል። አሁን፣ ተመሳሳዩን ቁልፍ ለሁለተኛ ጊዜ ለመጨመር ስንሞክር፣ keyring_vault ቁልፉ በካሼው ውስጥ መኖሩን ያረጋግጣል እና ስህተት ይጥላል።
በመጀመሪያው ሁኔታ ሁኔታው የተለየ ነው. አገልጋይ1 እና አገልጋይ2 የተለያዩ መሸጎጫዎች አሏቸው። ROB_1ን በserver1 እና በቮልት ሰርቨር ላይ ባለው ቁልፍ መሸጎጫ ላይ ካከሉ በኋላ በserver2 ላይ ያለው የቁልፍ መሸጎጫ ከመመሳሰል ውጭ ነው። በserver2 ላይ ባለው መሸጎጫ ውስጥ ምንም ROB_1 ቁልፍ የለም። ስለዚህም ROB_1 ቁልፉ ለቁልፍ_ቁልፍ_ስቶር እና ለቮልት ሰርቨር የተፃፈ ሲሆን ይህም የቀደመውን እሴት (!) ይተካል። አሁን በቮልት ሰርቨር ላይ ያለው 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 = (...)በዚህ አጋጣሚ ሁለቱም አገልጋዮች አንድ አይነት ተራራ ነጥብ "mount_point" ይጠቀማሉ፣ ግን የተለያዩ መንገዶች። ይህንን መንገድ ተጠቅመው በአገልጋይ1 ላይ የመጀመሪያውን ሚስጥር ሲፈጥሩ የቮልት አገልጋዩ በራስ ሰር የ"አገልጋይ1" ማውጫ ይፈጥራል። ለአገልጋይ2 ሁሉም ነገር ተመሳሳይ ነው። የመጨረሻውን ሚስጥር በ mount_point/server1 ወይም mount_point/server2 ሲሰርዙ የቮልት አገልጋዩ እነዛን ማውጫዎች ይሰርዛል። የዱካ መለያየትን ከተጠቀምክ አንድ የማማከሚያ ነጥብ ብቻ መፍጠር እና የውቅረት ፋይሎቹን በመቀየር አገልጋዮቹ የተለያዩ መንገዶችን መጠቀም አለብህ። የኤችቲቲፒ ጥያቄን በመጠቀም የመጫኛ ነጥብ ሊፈጠር ይችላል። 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) ከውቅር ፋይሉ ግቤቶች ጋር ይዛመዳሉ። እርግጥ ነው፣ ተመሳሳይ ለማድረግ የቮልት መገልገያዎችን መጠቀም ይችላሉ። ነገር ግን የተራራ ነጥብ መፍጠርን በራስ-ሰር ማድረግ ቀላል ነው። ይህ መረጃ ጠቃሚ ሆኖ እንዳገኙት ተስፋ አደርጋለሁ እናም በዚህ ተከታታይ መጣጥፎች ውስጥ እናያለን ።
ተጨማሪ ያንብቡ፡
ምንጭ: hab.com