ការអ៊ិនគ្រីបនៅក្នុង MySQL៖ ឃ្លាំងសម្ងាត់

នៅក្នុងការរំពឹងទុកនៃការចាប់ផ្តើមនៃការចុះឈ្មោះថ្មីសម្រាប់វគ្គសិក្សា "មូលដ្ឋានទិន្នន័យ" យើងបានរៀបចំការបកប្រែអត្ថបទមានប្រយោជន៍សម្រាប់អ្នក។

ការអ៊ិនគ្រីបទិន្នន័យតម្លាភាព (TDE) បានបង្ហាញខ្លួននៅក្នុង ម៉ាស៊ីនមេ Percona សម្រាប់ MySQL និង MySQL សម្រាប់ពេលខ្លះ។ ប៉ុន្តែតើអ្នកធ្លាប់គិតអំពីរបៀបដែលវាដំណើរការនៅក្រោមក្រណាត់ ហើយតើ TDE អាចមានផលប៉ះពាល់អ្វីខ្លះលើម៉ាស៊ីនមេរបស់អ្នក? នៅក្នុងស៊េរីនៃអត្ថបទនេះ យើងនឹងពិនិត្យមើលពីរបៀបដែល TDE ធ្វើការខាងក្នុង។ ចូរចាប់ផ្តើមជាមួយនឹងការផ្ទុកគន្លឹះ ព្រោះថាវាទាមទារសម្រាប់ការអ៊ិនគ្រីបណាមួយដើម្បីដំណើរការ។ បន្ទាប់មកយើងនឹងពិនិត្យមើលឱ្យកាន់តែច្បាស់អំពីរបៀបដែលការអ៊ិនគ្រីបដំណើរការនៅក្នុងម៉ាស៊ីនមេ Percona សម្រាប់ MySQL/MySQL និងលក្ខណៈពិសេសបន្ថែមដែល Percona Server សម្រាប់ MySQL មាន។

សោ MySQL

Keyring គឺជាកម្មវិធីជំនួយដែលអនុញ្ញាតឱ្យម៉ាស៊ីនមេសួរ បង្កើត និងលុបសោនៅក្នុងឯកសារមូលដ្ឋាន (keyring_file) ឬនៅលើម៉ាស៊ីនមេពីចម្ងាយ (ដូចជា HashiCorp Vault)។ សោតែងតែត្រូវបានទុកក្នុងឃ្លាំងសម្ងាត់ ដើម្បីបង្កើនល្បឿននៃការទាញយករបស់ពួកគេ។

កម្មវិធីជំនួយអាចបែងចែកជាពីរប្រភេទ៖

• ការផ្ទុកក្នុងស្រុក។ ឧទាហរណ៍ ឯកសារ​មូលដ្ឋាន (យើង​ហៅ​វា​ថា​ឯកសារ​ដែល​មាន​មូលដ្ឋាន​លើ​កូនសោ)។
• ឧបករណ៍ផ្ទុកពីចម្ងាយ។ ឧទាហរណ៍ Vault Server (យើងហៅវាថាជា server-based keyring)។

ការបំបែកនេះគឺមានសារៈសំខាន់ព្រោះប្រភេទផ្សេងគ្នានៃការផ្ទុកមានឥរិយាបទខុសគ្នាបន្តិចបន្តួច មិនត្រឹមតែនៅពេលរក្សាទុក និងទាញយកសោប៉ុណ្ណោះទេ ប៉ុន្តែនៅពេលដំណើរការពួកវាផងដែរ។

នៅពេលប្រើកន្លែងផ្ទុកឯកសារ នៅពេលចាប់ផ្តើម មាតិកាទាំងមូលនៃកន្លែងផ្ទុកត្រូវបានផ្ទុកទៅក្នុងឃ្លាំងសម្ងាត់៖ លេខសម្គាល់គន្លឹះ អ្នកប្រើប្រាស់គន្លឹះ ប្រភេទសោ និងកូនសោខ្លួនឯង។

ក្នុងករណីហាងដែលមានមូលដ្ឋានលើម៉ាស៊ីនមេ (ដូចជា Vault Server) មានតែលេខសម្គាល់កូនសោ និងអ្នកប្រើប្រាស់គន្លឹះប៉ុណ្ណោះដែលត្រូវបានផ្ទុកនៅពេលចាប់ផ្តើម ដូច្នេះការទទួលបានកូនសោទាំងអស់មិនបន្ថយល្បឿននៃការចាប់ផ្តើមនោះទេ។ សោត្រូវបានផ្ទុកដោយខ្ជិល។ នោះគឺ សោខ្លួនវាត្រូវបានផ្ទុកពី Vault តែនៅពេលដែលវាត្រូវការពិតប្រាកដ។ នៅពេលទាញយករួច សោត្រូវរក្សាទុកក្នុងអង្គចងចាំ ដូច្នេះវាមិនចាំបាច់ចូលប្រើតាមរយៈការភ្ជាប់ TLS ទៅកាន់ Vault Server នាពេលអនាគត។ បន្ទាប់មកយើងពិនិត្យមើលថាតើព័ត៌មានអ្វីខ្លះដែលមានវត្តមាននៅក្នុងឃ្លាំងគន្លឹះ។

ព័ត៌មានសំខាន់ៗមានដូចខាងក្រោម៖

• លេខសម្គាល់គន្លឹះ - ការកំណត់អត្តសញ្ញាណសំខាន់ៗ ឧទាហរណ៍៖
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• ប្រភេទគន្លឹះ - ប្រភេទគ្រាប់ចុចផ្អែកលើក្បួនដោះស្រាយការអ៊ិនគ្រីបដែលបានប្រើ តម្លៃដែលអាចធ្វើបាន៖ “AES”, “RSA” ឬ “DSA” ។
• ប្រវែងកូនសោ - ប្រវែងគន្លឹះគិតជាបៃ AES៖ 16, 24 ឬ 32, RSA 128, 256, 512 និង DSA 128, 256 ឬ 384 ។
• អ្នក​ប្រើ - ម្ចាស់សោ។ ប្រសិនបើសោជាប្រព័ន្ធ ឧទាហរណ៍ Master Key នោះវាលនេះគឺទទេ។ ប្រសិនបើសោត្រូវបានបង្កើតដោយប្រើ keyring_udf នោះវាលនេះកំណត់អត្តសញ្ញាណម្ចាស់សោ។
• គន្លឹះខ្លួនឯង

សោត្រូវបានកំណត់អត្តសញ្ញាណដោយគូ៖ key_id អ្នកប្រើប្រាស់។

វាក៏មានភាពខុសគ្នាក្នុងការរក្សាទុក និងលុបសោផងដែរ។

ការផ្ទុកឯកសារកាន់តែលឿន។ អ្នក​ប្រហែល​ជា​គិត​ថា​ឃ្លាំង​សម្ងាត់​គឺ​គ្រាន់​តែ​សរសេរ​កូនសោ​ទៅ​ឯកសារ​តែ​ម្តង ប៉ុន្តែ​អត់​ទេ វា​មាន​ច្រើន​ទៀត​នៅ​ទីនេះ។ នៅពេលណាដែលការកែប្រែការផ្ទុកឯកសារត្រូវបានធ្វើឡើង ច្បាប់ចម្លងបម្រុងទុកនៃមាតិកាទាំងអស់ត្រូវបានបង្កើតដំបូង។ ចូរនិយាយថាឯកសារនេះត្រូវបានគេហៅថា my_biggest_secrets បន្ទាប់មកច្បាប់ចម្លងបម្រុងទុកនឹងក្លាយជា my_biggest_secrets.backup ។ បន្ទាប់មក ឃ្លាំងសម្ងាត់ត្រូវបានផ្លាស់ប្តូរ (គ្រាប់ចុចត្រូវបានបន្ថែម ឬលុប) ហើយប្រសិនបើអ្វីៗទាំងអស់ទទួលបានជោគជ័យ ឃ្លាំងសម្ងាត់ត្រូវបានកំណត់ឡើងវិញជាឯកសារ។ ក្នុងករណីដ៏កម្រ ដូចជាម៉ាស៊ីនមេបរាជ័យ អ្នកអាចឃើញឯកសារបម្រុងទុកនេះ។ ឯកសារបម្រុងទុកត្រូវបានលុបនៅពេលបន្ទាប់ដែលសោត្រូវបានផ្ទុក (ជាធម្មតាបន្ទាប់ពីម៉ាស៊ីនមេត្រូវបានចាប់ផ្តើមឡើងវិញ)។

នៅពេលរក្សាទុក ឬលុបសោនៅក្នុងម៉ាស៊ីនមេ ការផ្ទុកត្រូវតែភ្ជាប់ទៅម៉ាស៊ីនមេ MySQL ដោយប្រើពាក្យបញ្ជា "ផ្ញើសោ" / "ស្នើសុំការលុបសោ" ។

ចូរយើងត្រលប់ទៅល្បឿនចាប់ផ្តើមម៉ាស៊ីនមេវិញ។ បន្ថែមពីលើការពិតដែលថាល្បឿននៃការបើកដំណើរការត្រូវបានប៉ះពាល់ដោយតុដេកដោយខ្លួនឯង វាក៏មានបញ្ហាផងដែរអំពីចំនួនសោពីតុដេកដែលត្រូវការដើម្បីយកនៅពេលចាប់ផ្តើម។ ជាការពិតណាស់ នេះមានសារៈសំខាន់ជាពិសេសសម្រាប់ការផ្ទុកម៉ាស៊ីនមេ។ នៅពេលចាប់ផ្តើម ម៉ាស៊ីនមេពិនិត្យមើលថាតើសោមួយណាដែលត្រូវការសម្រាប់តារាង/ចន្លោះតារាងដែលបានអ៊ិនគ្រីប ហើយស្នើសុំសោពីកន្លែងផ្ទុក។ នៅលើម៉ាស៊ីនមេ "ស្អាត" ជាមួយនឹងការអ៊ិនគ្រីប Master Key ត្រូវតែមាន Master Key មួយ ដែលត្រូវតែទាញយកពីកន្លែងផ្ទុក។ ទោះយ៉ាងណាក៏ដោយ សោមួយចំនួនធំអាចត្រូវបានទាមទារ ជាឧទាហរណ៍ នៅពេលដែលម៉ាស៊ីនមេបម្រុងទុកកំពុងស្ដារការបម្រុងទុកពីម៉ាស៊ីនមេចម្បង។ ក្នុងករណីបែបនេះ ការបង្វិល Master Key គួរតែត្រូវបានផ្តល់ជូន។ វានឹងត្រូវបានរៀបរាប់លម្អិតបន្ថែមទៀតនៅក្នុងអត្ថបទនាពេលខាងមុខ ទោះបីជានៅទីនេះខ្ញុំចង់កត់សម្គាល់ថាម៉ាស៊ីនមេដែលប្រើ Master Keys ច្រើនអាចចំណាយពេលយូរបន្តិចដើម្បីចាប់ផ្តើម ជាពិសេសនៅពេលប្រើឃ្លាំងសម្ងាត់ផ្នែកខាងម៉ាស៊ីនមេ។

ឥឡូវនេះសូមនិយាយបន្ថែមទៀតអំពី keyring_file ។ នៅពេលខ្ញុំកំពុងបង្កើត keyring_file ខ្ញុំក៏មានការព្រួយបារម្ភអំពីរបៀបពិនិត្យមើលការផ្លាស់ប្តូរ keyring_file ខណៈពេលដែលម៉ាស៊ីនមេកំពុងដំណើរការ។ នៅក្នុង 5.7 ការត្រួតពិនិត្យត្រូវបានអនុវត្តដោយផ្អែកលើស្ថិតិឯកសារដែលមិនមែនជាដំណោះស្រាយដ៏ល្អហើយនៅក្នុង 8.0 វាត្រូវបានជំនួសដោយ checksum SHA256 ។

លើកដំបូងដែលអ្នកដំណើរការ keyring_file ស្ថិតិឯកសារ និង checksum ត្រូវបានគណនា ដែលត្រូវបានចងចាំដោយម៉ាស៊ីនមេ ហើយការផ្លាស់ប្តូរត្រូវបានអនុវត្តលុះត្រាតែពួកវាត្រូវគ្នា។ នៅពេលឯកសារផ្លាស់ប្តូរ មូលប្បទានប័ត្រត្រូវបានធ្វើបច្ចុប្បន្នភាព។

យើងបានគ្របដណ្តប់សំណួរជាច្រើនអំពីតុដេកសំខាន់ៗរួចហើយ។ ទោះយ៉ាងណាក៏ដោយ មានប្រធានបទសំខាន់មួយទៀតដែលជារឿយៗត្រូវបានបំភ្លេចចោល ឬមានការយល់ច្រឡំ៖ ការចែករំលែកសោរនៅលើម៉ាស៊ីនមេ។

តើខ្ញុំមានន័យយ៉ាងណា? ម៉ាស៊ីនមេនីមួយៗ (ឧទាហរណ៍ ម៉ាស៊ីនមេ Percona) នៅក្នុងចង្កោមត្រូវតែមានទីតាំងដាច់ដោយឡែកនៅលើ Vault Server ដែល Percona Server ត្រូវតែរក្សាទុកសោរបស់វា។ Master Key នីមួយៗដែលបានរក្សាទុកក្នុងការផ្ទុកមាន GUID របស់ម៉ាស៊ីនមេ Percona នៅក្នុងការកំណត់អត្តសញ្ញាណរបស់វា។ ហេតុអ្វីបានជាវាសំខាន់? ស្រមៃថាអ្នកមាន Vault Server តែមួយ ហើយ Percona Servers ទាំងអស់នៅក្នុង cluster ប្រើ Vault Server តែមួយនោះ។ បញ្ហាហាក់ដូចជាច្បាស់។ ប្រសិនបើម៉ាស៊ីនមេ Percona ទាំងអស់បានប្រើ Master Key ដោយគ្មានឧបករណ៍កំណត់អត្តសញ្ញាណតែមួយគត់ ដូចជា id = 1, id = 2 ។ល។ នោះម៉ាស៊ីនមេទាំងអស់នៅក្នុងចង្កោមនឹងប្រើ Master Key ដូចគ្នា។ អ្វីដែល GUID ផ្តល់ឱ្យគឺភាពខុសគ្នារវាងម៉ាស៊ីនមេ។ ហេតុអ្វីបានជាត្រូវនិយាយអំពីការចែករំលែកសោរវាងម៉ាស៊ីនមេ ប្រសិនបើ GUID តែមួយគត់មានរួចហើយ? មានកម្មវិធីជំនួយមួយទៀត - keyring_udf ។ ជាមួយនឹងកម្មវិធីជំនួយនេះ អ្នកប្រើប្រាស់ម៉ាស៊ីនមេរបស់អ្នកអាចរក្សាទុកសោរបស់ពួកគេនៅលើម៉ាស៊ីនមេ Vault ។ បញ្ហាកើតឡើងនៅពេលដែលអ្នកប្រើបង្កើតកូនសោនៅលើ server1 ជាឧទាហរណ៍ ហើយបន្ទាប់មកព្យាយាមបង្កើតកូនសោដែលមានលេខសម្គាល់ដូចគ្នានៅលើ server2 ឧទាហរណ៍៖

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

រង់ចាំ។ ម៉ាស៊ីនមេទាំងពីរកំពុងប្រើ Vault Server ដូចគ្នា តើមុខងារ keyring_key_store បរាជ័យនៅលើ server2 មែនទេ? គួរឱ្យចាប់អារម្មណ៍ ប្រសិនបើអ្នកព្យាយាមធ្វើដូចគ្នានៅលើម៉ាស៊ីនមេមួយ អ្នកនឹងទទួលបានកំហុសមួយ៖

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

ត្រូវហើយ ROB_1 មានរួចហើយ។

ចូរពិភាក្សាឧទាហរណ៍ទីពីរជាមុនសិន។ ដូចដែលយើងបាននិយាយមុននេះ keyring_vault ឬកម្មវិធីជំនួយ keyring ផ្សេងទៀតរក្សាទុកលេខសម្គាល់គន្លឹះទាំងអស់នៅក្នុងអង្គចងចាំ។ ដូច្នេះបន្ទាប់ពីបង្កើតកូនសោថ្មី ROB_1 ត្រូវបានបន្ថែមទៅ server1 ហើយបន្ថែមពីលើការផ្ញើកូនសោនេះទៅ Vault សោក៏ត្រូវបានបន្ថែមទៅក្នុងឃ្លាំងសម្ងាត់ផងដែរ។ ឥឡូវនេះ នៅពេលដែលយើងព្យាយាមបន្ថែមកូនសោដូចគ្នាជាលើកទីពីរ keyring_vault ពិនិត្យមើលថាតើសោមាននៅក្នុងឃ្លាំងសម្ងាត់ ហើយបោះកំហុស។

ក្នុងករណីដំបូងស្ថានភាពគឺខុសគ្នា។ Server1 និង server2 មានឃ្លាំងសម្ងាត់ដាច់ដោយឡែក។ បន្ទាប់ពីបន្ថែម ROB_1 ទៅក្នុងឃ្លាំងសម្ងាត់សំខាន់នៅលើ server1 និង Vault server ឃ្លាំងសម្ងាត់សំខាន់នៅលើ server2 គឺមិនសមកាលកម្មទេ។ មិនមានសោ ROB_2 នៅក្នុងឃ្លាំងសម្ងាត់នៅលើ server1 ទេ។ ដូច្នេះ សោ ROB_1 ត្រូវបានសរសេរទៅ keyring_key_store និងទៅម៉ាស៊ីនមេ Vault ដែលពិតជាសរសេរជាន់លើ (!) តម្លៃពីមុន។ ឥឡូវនេះសោ ROB_1 នៅលើម៉ាស៊ីនមេ Vault គឺ 543210987654321។ គួរឱ្យចាប់អារម្មណ៍ ម៉ាស៊ីនមេ Vault មិនទប់ស្កាត់សកម្មភាពបែបនេះទេ ហើយងាយស្រួលសរសេរជាន់លើតម្លៃចាស់។

ឥឡូវនេះយើងអាចដឹងថាហេតុអ្វីបានជាការបែងចែកម៉ាស៊ីនមេនៅក្នុង Vault អាចមានសារៈសំខាន់ - នៅពេលអ្នកកំពុងប្រើ keyring_udf ហើយចង់រក្សាទុកកូនសោនៅក្នុង Vault ។ តើធ្វើដូចម្តេចដើម្បីសម្រេចបាននូវការបំបែកនេះនៅលើម៉ាស៊ីនមេ Vault?

មានវិធីពីរយ៉ាងក្នុងការបែងចែកទៅក្នុង 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 កំពុងប្រើចំណុចម៉ោនផ្សេងគ្នា។ នៅពេលបំបែកផ្លូវ ការកំណត់នឹងមើលទៅដូចនេះ៖

--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" ប៉ុន្តែផ្លូវខុសគ្នា។ នៅពេលអ្នកបង្កើតការសម្ងាត់ដំបូងនៅលើ server1 ដោយប្រើផ្លូវនេះ Vault server នឹងបង្កើតថត "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) ត្រូវគ្នាទៅនឹងប៉ារ៉ាម៉ែត្រនៃឯកសារកំណត់រចនាសម្ព័ន្ធ។ ជាការពិតណាស់ អ្នកអាចប្រើឧបករណ៍ប្រើប្រាស់ Vault ដើម្បីធ្វើដូចគ្នា។ ប៉ុន្តែវាកាន់តែងាយស្រួលក្នុងការបង្កើតចំណុចម៉ោនដោយស្វ័យប្រវត្តិ។ ខ្ញុំសង្ឃឹមថាអ្នករកឃើញព័ត៌មាននេះមានប្រយោជន៍ ហើយយើងនឹងឃើញអ្នកនៅក្នុងអត្ថបទបន្ទាប់នៅក្នុងស៊េរីនេះ។

អាន​បន្ថែម:

• Sysbench និងការចែកចាយអថេរចៃដន្យ

ប្រភព: www.habr.com