ProHoster > බ්ලොග් > පරිපාලනය > MySQL හි සංකේතනය: Keystore

MySQL හි සංකේතනය: Keystore

පාඨමාලාව සඳහා නව බඳවා ගැනීම් ආරම්භය අපේක්ෂාවෙන් "දත්ත සමුදාය" අපි ඔබට ප්රයෝජනවත් ලිපියක පරිවර්තනයක් සූදානම් කර ඇත.

MySQL හි සංකේතනය: Keystore

විනිවිද පෙනෙන දත්ත සංකේතනය (TDE) දර්ශනය විය MySQL සඳහා Percona සේවාදායකය සහ MySQL සෑහෙන කාලයක්. නමුත් එය ආවරණය යටතේ ක්‍රියා කරන ආකාරය සහ TDE ඔබේ සේවාදායකයට ඇති කළ හැකි බලපෑම ගැන ඔබ කවදා හෝ සිතා තිබේද? මෙම ලිපි මාලාවේදී අපි TDE අභ්‍යන්තරව ක්‍රියා කරන ආකාරය දෙස බලමු. ඕනෑම සංකේතනයක් ක්‍රියා කිරීමට මෙය අවශ්‍ය වන බැවින්, යතුරු ගබඩාවෙන් පටන් ගනිමු. ඉන්පසුව අපි MySQL/MySQL සඳහා Percona Server හි සංකේතනය ක්‍රියා කරන ආකාරය සහ MySQL සඳහා Percona Server සතුව ඇති අමතර විශේෂාංග මොනවාද යන්න සමීපව බලමු.

MySQL Keyring

යතුරුකරණය යනු දේශීය ගොනුවක (keyring_file) හෝ දුරස්ථ සේවාදායකයක (HashiCorp Vault වැනි) යතුරු විමසීමට, සෑදීමට සහ මකා දැමීමට සේවාදායකයට ඉඩ දෙන ප්ලගීන වේ. යතුරු සෑම විටම ඒවා ලබා ගැනීම වේගවත් කිරීම සඳහා දේශීයව හැඹිලිගත කර ඇත.

ප්ලගීන වර්ග දෙකකට බෙදිය හැකිය:

  • දේශීය ගබඩාව. උදාහරණයක් ලෙස, දේශීය ගොනුවක් (අපි මෙය ගොනු-පාදක යතුරුකරණයක් ලෙස හඳුන්වමු).
  • දුරස්ථ ගබඩාව. උදාහරණයක් ලෙස, Vault Server (අපි මෙය සේවාදායකය පදනම් කරගත් යතුරුකරණයක් ලෙස හඳුන්වමු).

මෙම වෙන්වීම වැදගත් වන්නේ විවිධ වර්ගයේ ගබඩා කිරීම් යතුරු ගබඩා කිරීමේදී සහ නැවත ලබා ගැනීමේදී පමණක් නොව ඒවා ක්‍රියාත්මක කිරීමේදීද තරමක් වෙනස් ලෙස හැසිරෙන බැවිනි.

ගොනු ගබඩාවක් භාවිතා කරන විට, ආරම්භයේදී, ගබඩාවේ සම්පූර්ණ අන්තර්ගතය හැඹිලියට පටවනු ලැබේ: යතුරු හැඳුනුම්පත, යතුරු පරිශීලකයා, යතුරු වර්ගය සහ යතුරම.

සේවාදායක පැත්තේ ගබඩාවකදී (Vault Server වැනි), ආරම්භයේදී යතුරු හැඳුනුම්පත සහ යතුරු පරිශීලකයා පමණක් පටවනු ලැබේ, එබැවින් සියලුම යතුරු ලබා ගැනීමෙන් ආරම්භය මන්දගාමී නොවේ. යතුරු කම්මැලි ලෙස පටවනු ලැබේ. එනම්, යතුර වෝල්ට් වෙතින් පටවනු ලබන්නේ එය ඇත්ත වශයෙන්ම අවශ්‍ය වූ විට පමණි. බාගත කළ පසු, යතුර මතකයේ හැඹිලිගත කර ඇති අතර එමඟින් එය අනාගතයේදී වෝල්ට් සේවාදායකයට 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, පරිශීලක.

යතුරු ගබඩා කිරීම සහ මකා දැමීමේ වෙනස්කම් ද ඇත.

ගොනු ගබඩා කිරීම වේගවත් වේ. යතුරු ගබඩාවක් ගොනුවක යතුර එක් වරක් ලියන බව ඔබ සිතනු ඇත, නමුත් නැත, මෙහි තවත් සිදුවෙමින් පවතී. ගොනු ගබඩා වෙනස් කිරීමක් සිදු කරන සෑම විටම, සියලුම අන්තර්ගතවල උපස්ථ පිටපතක් මුලින්ම සාදනු ලැබේ. අපි හිතමු ගොනුව my_biggest_secrets ලෙස හැඳින්වේ, එවිට උපස්ථ පිටපත my_biggest_secrets.backup වේවි. ඊළඟට, හැඹිලිය වෙනස් වේ (යතුරු එකතු කර හෝ මකා දමනු ලැබේ) සහ, සියල්ල සාර්ථක නම්, හැඹිලිය ගොනුවකට නැවත සකසනු ලැබේ. සේවාදායකයේ අසාර්ථක වීමක් වැනි දුර්ලභ අවස්ථාවන්හිදී, ඔබට මෙම උපස්ථ ගොනුව දැකිය හැක. උපස්ථ ගොනුව ඊළඟ වතාවේ යතුරු පූරණය වන විට මකා දමනු ලැබේ (සාමාන්‍යයෙන් සේවාදායකය නැවත ආරම්භ කිරීමෙන් පසුව).

සේවාදායක ආචයනයක යතුරක් සුරැකීමේදී හෝ මකා දැමීමේදී, ගබඩාව "යතුර යවන්න" / "යතුරු මකාදැමීම" යන විධානයන් සමඟ MySQL සේවාදායකයට සම්බන්ධ විය යුතුය.

අපි නැවත සේවාදායක ආරම්භක වේගය වෙත යමු. දියත් කිරීමේ වේගය සුරක්ෂිතාගාරය විසින්ම බලපානවාට අමතරව, ආරම්භයේදී සුරක්ෂිතාගාරයෙන් යතුරු කීයක් ලබා ගත යුතුද යන ගැටළුවද ඇත. ඇත්ත වශයෙන්ම, මෙය සේවාදායක ගබඩා කිරීම සඳහා විශේෂයෙන් වැදගත් වේ. ආරම්භයේදී, සේවාදායකය සංකේතනය කළ වගු/මේස අවකාශයන් සඳහා අවශ්‍ය යතුර පරීක්ෂා කර ගබඩාවෙන් යතුර ඉල්ලයි. Master Key සංකේතනය සහිත "පිරිසිදු" සේවාදායකයක, ගබඩාවෙන් ලබා ගත යුතු එක් ප්‍රධාන යතුරක් තිබිය යුතුය. කෙසේ වෙතත්, විශාල යතුරු සංඛ්‍යාවක් අවශ්‍ය විය හැකිය, උදාහරණයක් ලෙස, උපස්ථ සේවාදායකය ප්‍රාථමික සේවාදායකයෙන් උපස්ථයක් ප්‍රතිසාධනය කරන විට. එවැනි අවස්ථාවලදී, ප්රධාන යතුරේ භ්රමණය සැපයිය යුතුය. මෙය ඉදිරි ලිපි වලින් වඩාත් විස්තරාත්මකව ආවරණය කරනු ඇත, නමුත් මෙහිදී මම සටහන් කිරීමට කැමති බහු Master Keys භාවිතා කරන සේවාදායකයක් ආරම්භ කිරීමට ටිකක් වැඩි කාලයක් ගතවනු ඇත, විශේෂයෙන් සේවාදායක පැත්තේ යතුරු ගබඩාවක් භාවිතා කරන විට.

දැන් අපි keyring_file ගැන තව ටිකක් කතා කරමු. මම keyring_file සංවර්ධනය කරන විට, සේවාදායකය ක්‍රියාත්මක වන විට keyring_file වෙනස්කම් සඳහා පරීක්ෂා කරන්නේ කෙසේද යන්න පිළිබඳවද මම සැලකිලිමත් විය. 5.7 හි, පරික්‍ෂාව ගොනු සංඛ්‍යාලේඛන මත පදනම්ව සිදු කරන ලද අතර එය කදිම විසඳුමක් නොවූ අතර 8.0 හි එය SHA256 චෙක්සම් එකක් සමඟ ප්‍රතිස්ථාපනය විය.

ඔබ ප්‍රථම වරට keyring_file ධාවනය කරන විට, ගොනු සංඛ්‍යාලේඛන සහ චෙක්සම් ගණනය කරනු ලැබේ, ඒවා සේවාදායකය විසින් මතක තබා ගන්නා අතර වෙනස්කම් අදාළ වන්නේ ඒවා ගැළපෙන්නේ නම් පමණි. ගොනුව වෙනස් වූ විට, චෙක්සම් යාවත්කාලීන වේ.

අපි දැනටමත් ප්‍රධාන සුරක්ෂිතාගාර පිළිබඳ බොහෝ ප්‍රශ්න ආවරණය කර ඇත. කෙසේ වෙතත්, බොහෝ විට අමතක වූ හෝ වරදවා වටහා ගන්නා තවත් වැදගත් මාතෘකාවක් තිබේ: සේවාදායකයන් හරහා යතුරු බෙදාගැනීම.

මම අදහස් කරන්නේ? පොකුරේ ඇති සෑම සේවාදායකයකටම (උදාහරණයක් ලෙස, පර්කෝනා සේවාදායකය) වෝල්ට් සේවාදායකයේ වෙනම ස්ථානයක් තිබිය යුතු අතර එහි පර්කෝනා සේවාදායකය එහි යතුරු ගබඩා කළ යුතුය. ගබඩාවේ සුරකින ලද සෑම ප්‍රධාන යතුරකම එහි හැඳුනුම්කාරකය තුළ Percona සේවාදායකයේ GUID අඩංගු වේ. එය වැදගත් වන්නේ ඇයි? ඔබ සතුව ඇත්තේ එක් වෝල්ට් සේවාදායකයක් පමණක් බවත් පොකුරේ ඇති සියලුම පර්කෝනා සර්වර් එම තනි වෝල්ට් සේවාදායකය භාවිතා කරන බවත් සිතන්න. ගැටලුව පැහැදිලිව පෙනේ. සියලුම Percona සේවාදායකයන් id = 1, id = 2 වැනි අනන්‍ය හඳුනාගැනීම් නොමැතිව Master Key එකක් භාවිතා කළේ නම්, පොකුරේ ඇති සියලුම සේවාදායකයන් එකම Master Key එකක් භාවිතා කරයි. GUID සපයන්නේ සේවාදායකයන් අතර වෙනසයි. අද්විතීය GUID දැනටමත් පවතී නම් සේවාදායකයන් අතර යතුරු බෙදාගැනීම ගැන කතා කරන්නේ ඇයි? තවත් ප්ලගිනයක් ඇත - keyring_udf. මෙම ප්ලගිනය සමඟ, ඔබේ සේවාදායක පරිශීලකයාට ඔවුන්ගේ යතුරු වෝල්ට් සේවාදායකයේ ගබඩා කළ හැකිය. පරිශීලකයෙකු server1 හි යතුරක් සාදන විට ගැටළුව ඇතිවේ, උදාහරණයක් ලෙස, server2 හි එකම ID සමඟ යතුරක් සෑදීමට උත්සාහ කරන විට, උදාහරණයක් ලෙස:

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

ඉන්න. සේවාදායකයන් දෙකම එකම Vault සේවාදායකය භාවිතා කරයි, server2 හි 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 server1 වෙත එකතු කරනු ලබන අතර, මෙම යතුර Vault වෙත යැවීමට අමතරව, යතුරද හැඹිලියට එකතු වේ. දැන්, අපි එකම යතුර දෙවන වරට එක් කිරීමට උත්සාහ කරන විට, keyring_vault යතුර හැඹිලියේ තිබේදැයි පරීක්ෂා කර දෝෂයක් ඇති කරයි.

පළමු අවස්ථාවේ දී තත්වය වෙනස් ය. Server1 සහ server2 වෙනම හැඹිලි ඇත. Server1 සහ Vault සේවාදායකයේ යතුරු හැඹිලියට ROB_1 එකතු කිරීමෙන් පසුව, server2 හි යතුරු හැඹිලිය සමමුහුර්ත නොවේ. server2 හි හැඹිලියේ ROB_1 යතුරක් නොමැත. මේ අනුව, ROB_1 යතුර keyring_key_store වෙත සහ Vault සේවාදායකය වෙත ලියා ඇත, එය ඇත්ත වශයෙන්ම පෙර අගය (!) නැවත ලියයි. දැන් Vault සේවාදායකයේ ROB_1 යතුර 543210987654321 වේ. සිත්ගන්නා කරුණ නම්, Vault සේවාදායකය එවැනි ක්‍රියා අවහිර නොකරන අතර පැරණි අගය පහසුවෙන් නැවත ලියයි.

වෝල්ට් හි සේවාදායක කොටස් කිරීම වැදගත් වන්නේ මන්දැයි දැන් අපට පෙනේ - ඔබ keyring_udf භාවිතා කරන විට සහ වෝල්ට් හි යතුරු ගබඩා කිරීමට අවශ්‍ය විට. Vault සේවාදායකයක් මත මෙම වෙන්වීම ලබා ගන්නේ කෙසේද?

වෝල්ට් එකට කොටස් කිරීමට ක්රම දෙකක් තිබේ. ඔබට එක් එක් සේවාදායකය සඳහා විවිධ මවුන්ට් පොයින්ට් සෑදිය හැක, නැතහොත් එකම මවුන්ට් පොයින්ට් එක තුළ විවිධ මාවත් භාවිතා කරන්න. මෙය උදාහරණ සමඟින් වඩාත් හොඳින් පැහැදිලි වේ. එබැවින් අපි මුලින්ම තනි සවි කිරීම් ස්ථාන දෙස බලමු: 

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

මෙහිදී server1 සහ server2 විවිධ mount point භාවිතා කරන බව ඔබට දැක ගත හැක. මාර්ග බෙදීමේදී, වින්‍යාසය මේ ආකාරයෙන් පෙනෙනු ඇත:

--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 "mount_point" භාවිතා කරයි, නමුත් විවිධ මාර්ග භාවිතා කරයි. ඔබ මෙම මාර්ගය භාවිතා කරමින් server1 හි පළමු රහස නිර්මාණය කරන විට, Vault සේවාදායකය ස්වයංක්‍රීයව "server1" නාමාවලියක් නිර්මාණය කරයි. server2 සඳහා සෑම දෙයක්ම සමාන වේ. ඔබ 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) වින්‍යාස ගොනුවේ පරාමිතිවලට අනුරූප වේ. ඇත්ත වශයෙන්ම, ඔබට එයම කිරීමට වෝල්ට් උපයෝගිතා භාවිතා කළ හැකිය. නමුත් සවිකිරීමේ ස්ථානයක් නිර්මාණය කිරීම ස්වයංක්රීය කිරීම පහසුය. මෙම තොරතුරු ඔබට ප්‍රයෝජනවත් වනු ඇතැයි මම බලාපොරොත්තු වන අතර මෙම ලිපි මාලාවේ ඊළඟ ලිපි වලින් අපි ඔබව හමුවෙමු.

MySQL හි සංකේතනය: Keystore

තවත් කියවන්න:

මූලාශ්රය: www.habr.com

අදහස් එක් කරන්න