ឈ្មោះរបស់ខ្ញុំគឺ Denis Rozhkov ខ្ញុំជាប្រធានផ្នែកអភិវឌ្ឍន៍កម្មវិធីនៅក្រុមហ៊ុន Gazinformservice ក្នុងក្រុមផលិតផល ចាតូបា. ច្បាប់ និងបទប្បញ្ញត្តិសាជីវកម្មកំណត់តម្រូវការជាក់លាក់សម្រាប់សុវត្ថិភាពនៃការផ្ទុកទិន្នន័យ។ គ្មាននរណាម្នាក់ចង់ឱ្យភាគីទីបីទទួលបានព័ត៌មានសម្ងាត់ទេ ដូច្នេះបញ្ហាខាងក្រោមមានសារៈសំខាន់សម្រាប់គម្រោងណាមួយ៖ ការកំណត់អត្តសញ្ញាណ និងការផ្ទៀងផ្ទាត់ ការគ្រប់គ្រងការចូលប្រើទិន្នន័យ ការធានានូវភាពត្រឹមត្រូវនៃព័ត៌មាននៅក្នុងប្រព័ន្ធ ការកត់ត្រាព្រឹត្តិការណ៍សុវត្ថិភាព។ ដូច្នេះខ្ញុំចង់និយាយអំពីចំណុចគួរឱ្យចាប់អារម្មណ៍មួយចំនួនទាក់ទងនឹងសុវត្ថិភាព DBMS ។

អត្ថបទនេះត្រូវបានរៀបចំឡើងដោយផ្អែកលើសុន្ទរកថានៅ @DatabasesMeetup, រៀបចំ ដំណោះស្រាយពពក Mail.ru. បើមិនចង់អានអាចមើលបាន៖

អត្ថបទនឹងមានបីផ្នែក៖

• វិធីធានាការតភ្ជាប់។
• តើអ្វីជាសវនកម្មនៃសកម្មភាព និងរបៀបកត់ត្រាអ្វីដែលកំពុងកើតឡើងនៅលើផ្នែកមូលដ្ឋានទិន្នន័យ ហើយភ្ជាប់ទៅវា។
• របៀបការពារទិន្នន័យនៅក្នុង Database ខ្លួនវា និងបច្ចេកវិទ្យាអ្វីខ្លះដែលអាចរកបានសម្រាប់ការនេះ។

ធាតុផ្សំបីនៃសុវត្ថិភាព DBMS៖ ការការពារការតភ្ជាប់ សវនកម្មសកម្មភាព និងការការពារទិន្នន័យ

ការធានាការតភ្ជាប់របស់អ្នក។

អ្នកអាចភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យដោយផ្ទាល់ ឬដោយប្រយោលតាមរយៈកម្មវិធីបណ្តាញ។ តាមក្បួនមួយ អ្នកប្រើប្រាស់អាជីវកម្ម ពោលគឺអ្នកដែលធ្វើការជាមួយ DBMS ធ្វើអន្តរកម្មជាមួយវាដោយប្រយោល។

មុននឹងនិយាយអំពីការការពារការតភ្ជាប់ អ្នកត្រូវឆ្លើយសំណួរសំខាន់ៗដែលកំណត់ពីរបៀបដែលវិធានការសុវត្ថិភាពនឹងត្រូវរៀបចំឡើង៖

• តើអ្នកប្រើប្រាស់អាជីវកម្មម្នាក់ស្មើនឹងអ្នកប្រើប្រាស់ DBMS ម្នាក់ទេ?
• ថាតើការចូលប្រើទិន្នន័យ DBMS ត្រូវបានផ្តល់តែតាមរយៈ API ដែលអ្នកគ្រប់គ្រង ឬថាតើតារាងត្រូវបានចូលប្រើដោយផ្ទាល់។
• ថាតើ DBMS ត្រូវបានបែងចែកទៅជាផ្នែកការពារដាច់ដោយឡែក អ្នកណាធ្វើអន្តរកម្មជាមួយវា និងរបៀប។
• ថាតើការរួមបញ្ចូល/ប្រូកស៊ី និងស្រទាប់កម្រិតមធ្យមត្រូវបានប្រើប្រាស់ ដែលអាចផ្លាស់ប្តូរព័ត៌មានអំពីរបៀបដែលការតភ្ជាប់ត្រូវបានបង្កើតឡើង និងអ្នកដែលកំពុងប្រើមូលដ្ឋានទិន្នន័យ។

ឥឡូវ​យើង​មើល​ថា​តើ​ឧបករណ៍​ណា​ខ្លះ​អាច​ត្រូវ​បាន​ប្រើ​ដើម្បី​ធានា​ការ​តភ្ជាប់៖

1. ប្រើដំណោះស្រាយថ្នាក់ជញ្ជាំងភ្លើងមូលដ្ឋានទិន្នន័យ។ ស្រទាប់ការពារបន្ថែមមួយនឹង យ៉ាងហោចណាស់ បង្កើនតម្លាភាពនៃអ្វីដែលកំពុងកើតឡើងនៅក្នុង DBMS ហើយអតិបរមា អ្នកនឹងអាចផ្តល់ការការពារទិន្នន័យបន្ថែម។
2. ប្រើគោលការណ៍ពាក្យសម្ងាត់។ ការប្រើប្រាស់របស់ពួកគេអាស្រ័យលើរបៀបដែលស្ថាបត្យកម្មរបស់អ្នកត្រូវបានសាងសង់។ ក្នុងករណីណាក៏ដោយ ពាក្យសម្ងាត់មួយនៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធនៃកម្មវិធីបណ្តាញដែលភ្ជាប់ទៅ DBMS មិនគ្រប់គ្រាន់សម្រាប់ការការពារទេ។ មានឧបករណ៍ DBMS មួយចំនួនដែលអនុញ្ញាតឱ្យអ្នកត្រួតពិនិត្យថាអ្នកប្រើប្រាស់ និងពាក្យសម្ងាត់តម្រូវឱ្យធ្វើបច្ចុប្បន្នភាព។

   អ្នកអាចអានបន្ថែមអំពីមុខងារវាយតម្លៃអ្នកប្រើប្រាស់ នៅទីនេះអ្នកក៏អាចស្វែងយល់អំពី MS SQL Vulnerability Assessmen ផងដែរ។ នៅទីនេះ. 

3. ពង្រឹងបរិបទនៃសម័យប្រជុំជាមួយនឹងព័ត៌មានចាំបាច់។ ប្រសិនបើវគ្គនេះមានភាពស្រអាប់ អ្នកមិនយល់ថាអ្នកណាកំពុងធ្វើការនៅក្នុង DBMS ក្នុងក្របខ័ណ្ឌរបស់វា អ្នកអាចបន្ថែមព័ត៌មានអំពីអ្នកដែលកំពុងធ្វើអ្វី និងហេតុអ្វីនៅក្នុងក្របខ័ណ្ឌនៃប្រតិបត្តិការដែលកំពុងដំណើរការ។ ព័ត៌មាននេះអាចត្រូវបានគេមើលឃើញនៅក្នុងសវនកម្ម។
4. កំណត់រចនាសម្ព័ន្ធ SSL ប្រសិនបើអ្នកមិនមានការបែងចែកបណ្តាញរវាង DBMS និងអ្នកប្រើប្រាស់ចុងក្រោយទេ វាមិននៅក្នុង VLAN ដាច់ដោយឡែកនោះទេ។ ក្នុងករណីបែបនេះ វាជាការចាំបាច់ដើម្បីការពារឆានែលរវាងអ្នកប្រើប្រាស់ និង DBMS ខ្លួនឯង។ ឧបករណ៍សុវត្ថិភាពក៏មាននៅក្នុងប្រភពបើកចំហផងដែរ។

តើវានឹងប៉ះពាល់ដល់ដំណើរការរបស់ DBMS យ៉ាងដូចម្តេច?

សូមក្រឡេកមើលឧទាហរណ៍នៃ PostgreSQL ដើម្បីមើលពីរបៀបដែល SSL ប៉ះពាល់ដល់ការផ្ទុកស៊ីភីយូ បង្កើនពេលវេលា និងបន្ថយ TPS និងថាតើវានឹងប្រើប្រាស់ធនធានច្រើនដែរឬទេ ប្រសិនបើអ្នកបើកវា។

ការផ្ទុក PostgreSQL ដោយប្រើ pgbench គឺជាកម្មវិធីដ៏សាមញ្ញមួយសម្រាប់ដំណើរការការធ្វើតេស្តដំណើរការ។ វាប្រតិបត្តិនូវលំដាប់តែមួយនៃពាក្យបញ្ជាម្តងហើយម្តងទៀត ប្រហែលជានៅក្នុងវគ្គមូលដ្ឋានទិន្នន័យស្របគ្នា ហើយបន្ទាប់មកគណនាអត្រាប្រតិបត្តិការជាមធ្យម។

សាកល្បង 1 ដោយគ្មាន SSL និងប្រើ SSL - ការតភ្ជាប់ត្រូវបានបង្កើតឡើងសម្រាប់ប្រតិបត្តិការនីមួយៗ៖

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require 
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

សាកល្បង 2 ដោយគ្មាន SSL និងប្រើ SSL - ប្រតិបត្តិការទាំងអស់ត្រូវបានអនុវត្តក្នុងការតភ្ជាប់តែមួយ៖

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

ការកំណត់ផ្សេងទៀត។:

scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000

លទ្ធផល​តេ​ស្ត:

 
គ្មាន SSL
SSL ដែលបាន

ការតភ្ជាប់ត្រូវបានបង្កើតឡើងសម្រាប់រាល់ប្រតិបត្តិការ

ភាពយឺតយ៉ាវជាមធ្យម
171.915 ម។ វិ
187.695 ម។ វិ

tps រួមទាំងការភ្ជាប់ទំនាក់ទំនង
58.168112
53.278062

tps ដោយមិនរាប់បញ្ចូលការតភ្ជាប់ដែលបង្កើត
64.084546
58.725846

ស៊ីភីយូ
24%
28%

ប្រតិបត្តិការទាំងអស់ត្រូវបានអនុវត្តក្នុងការតភ្ជាប់តែមួយ

ភាពយឺតយ៉ាវជាមធ្យម
6.722 ម។ វិ
6.342 ម។ វិ

tps រួមទាំងការភ្ជាប់ទំនាក់ទំនង
1587.657278
1576.792883

tps ដោយមិនរាប់បញ្ចូលការតភ្ជាប់ដែលបង្កើត
1588.380574
1577.694766

ស៊ីភីយូ
17%
21%

នៅពេលផ្ទុកពន្លឺ ឥទ្ធិពលនៃ SSL គឺអាចប្រៀបធៀបទៅនឹងកំហុសក្នុងការវាស់វែង។ ប្រសិនបើចំនួនទិន្នន័យដែលបានផ្ទេរគឺធំណាស់ ស្ថានភាពអាចខុសគ្នា។ ប្រសិនបើយើងបង្កើតការតភ្ជាប់មួយក្នុងមួយប្រតិបត្តិការ (នេះគឺកម្រណាស់ ជាធម្មតាការតភ្ជាប់ត្រូវបានចែករំលែករវាងអ្នកប្រើប្រាស់) អ្នកមានចំនួនច្រើននៃការតភ្ជាប់/ការផ្តាច់ ផលប៉ះពាល់អាចនឹងធំជាងបន្តិច។ នោះគឺវាអាចមានហានិភ័យនៃការថយចុះនៃការអនុវត្ត ទោះជាយ៉ាងណាក៏ដោយ ភាពខុសគ្នាគឺមិនធំដូចការមិនប្រើការការពារនោះទេ។

សូមចំណាំថាមានភាពខុសប្លែកគ្នាខ្លាំង ប្រសិនបើអ្នកប្រៀបធៀបរបៀបប្រតិបត្តិការ៖ អ្នកកំពុងធ្វើការក្នុងវគ្គតែមួយ ឬក្នុងរបៀបផ្សេងគ្នា។ នេះអាចយល់បាន៖ ធនធានត្រូវបានចំណាយលើការបង្កើតការតភ្ជាប់នីមួយៗ។

យើងមានករណីមួយនៅពេលដែលយើងភ្ជាប់ Zabbix នៅក្នុងរបៀបជឿទុកចិត្ត នោះគឺ md5 មិនត្រូវបានពិនិត្យ មិនចាំបាច់មានការផ្ទៀងផ្ទាត់ទេ។ បន្ទាប់មកអតិថិជនបានស្នើសុំឱ្យបើករបៀបផ្ទៀងផ្ទាត់ md5 ។ វាធ្វើឱ្យស៊ីភីយូមានបន្ទុកធ្ងន់ ហើយដំណើរការធ្លាក់ចុះ។ យើងចាប់ផ្តើមស្វែងរកវិធីដើម្បីបង្កើនប្រសិទ្ធភាព។ ដំណោះស្រាយមួយក្នុងចំណោមដំណោះស្រាយដែលអាចកើតមានចំពោះបញ្ហាគឺ អនុវត្តការរឹតបន្តឹងបណ្តាញ បង្កើត VLAN ដាច់ដោយឡែកសម្រាប់ DBMS បន្ថែមការកំណត់ដើម្បីធ្វើឱ្យវាច្បាស់ថាអ្នកណាកំពុងភ្ជាប់ពីកន្លែងណា និងលុបការផ្ទៀងផ្ទាត់។ អ្នកក៏អាចបង្កើនប្រសិទ្ធភាពការកំណត់ការផ្ទៀងផ្ទាត់ដើម្បីកាត់បន្ថយការចំណាយនៅពេលបើកការផ្ទៀងផ្ទាត់ ប៉ុន្តែ ជាទូទៅ ការប្រើប្រាស់វិធីសាស្រ្តផ្សេងគ្នា ការផ្ទៀងផ្ទាត់ប៉ះពាល់ដល់ដំណើរការ និងទាមទារឱ្យមានការពិចារណាលើកត្តាទាំងនេះនៅពេលរចនាថាមពលកុំព្យូទ័ររបស់ម៉ាស៊ីនមេ (ផ្នែករឹង) សម្រាប់ DBMS ។

សេចក្តីសន្និដ្ឋាន៖ នៅក្នុងដំណោះស្រាយមួយចំនួន សូម្បីតែការផ្ទៀងផ្ទាត់តិចតួចក្នុងការផ្ទៀងផ្ទាត់អាចប៉ះពាល់យ៉ាងខ្លាំងដល់គម្រោងហើយវាមិនល្អនៅពេលដែលវាច្បាស់តែនៅពេលអនុវត្តនៅក្នុងផលិតកម្មប៉ុណ្ណោះ។

សវនកម្មសកម្មភាព

សវនកម្មអាចមិនត្រឹមតែ DBMS ប៉ុណ្ណោះទេ។ សវនកម្មគឺអំពីការទទួលបានព័ត៌មានអំពីអ្វីដែលកំពុងកើតឡើងនៅក្នុងផ្នែកផ្សេងៗ។ វាអាចជា database firewall ឬប្រព័ន្ធប្រតិបត្តិការដែល DBMS ត្រូវបានបង្កើតឡើង។

នៅក្នុងកម្រិតសហគ្រាសពាណិជ្ជកម្ម DBMSs អ្វីគ្រប់យ៉ាងគឺល្អជាមួយនឹងការធ្វើសវនកម្ម ប៉ុន្តែនៅក្នុងប្រភពបើកចំហ - មិនតែងតែទេ។ នេះជាអ្វីដែល PostgreSQL មាន៖

• កំណត់​ហេតុ​លំនាំដើម - ការ​ចូល​ក្នុង​ការ​ចូល;
• ផ្នែកបន្ថែម៖ pgaudit - ប្រសិនបើការកត់ត្រាលំនាំដើមមិនគ្រប់គ្រាន់សម្រាប់អ្នក អ្នកអាចប្រើការកំណត់ដាច់ដោយឡែកដែលដោះស្រាយបញ្ហាមួយចំនួន។

បន្ថែមលើរបាយការណ៍ក្នុងវីដេអូ៖

msgstr "ការ​កត់ត្រា​សេចក្តីថ្លែងការណ៍​មូលដ្ឋាន​អាច​ត្រូវ​បាន​ផ្តល់​ដោយ​កន្លែង​កត់ត្រា​ស្តង់ដារ​ជាមួយ log_statement = all ។

នេះអាចទទួលយកបានសម្រាប់ការត្រួតពិនិត្យ និងការប្រើប្រាស់ផ្សេងទៀត ប៉ុន្តែមិនផ្តល់កម្រិតនៃព័ត៌មានលម្អិតដែលជាធម្មតាទាមទារសម្រាប់សវនកម្មនោះទេ។

វាមិនគ្រប់គ្រាន់ទេក្នុងការមានបញ្ជីនៃប្រតិបត្តិការទាំងអស់ដែលបានអនុវត្តនៅលើមូលដ្ឋានទិន្នន័យ។

វាក៏គួរមានលទ្ធភាពស្វែងរកសេចក្តីថ្លែងការណ៍ជាក់លាក់ដែលចាប់អារម្មណ៍ចំពោះសវនករ។

ការកត់ត្រាតាមស្តង់ដារបង្ហាញពីអ្វីដែលអ្នកប្រើបានស្នើសុំ ខណៈពេលដែល pgAudit ផ្តោតលើព័ត៌មានលម្អិតនៃអ្វីដែលបានកើតឡើងនៅពេលដែលមូលដ្ឋានទិន្នន័យបានដំណើរការសំណួរ។

ជាឧទាហរណ៍ សវនករប្រហែលជាចង់ផ្ទៀងផ្ទាត់ថាតារាងជាក់លាក់មួយត្រូវបានបង្កើតនៅក្នុងបង្អួចថែទាំឯកសារ។

នេះអាចហាក់ដូចជាកិច្ចការសាមញ្ញមួយជាមួយនឹងការធ្វើសវនកម្មមូលដ្ឋាន និង grep ប៉ុន្តែចុះយ៉ាងណាបើអ្នកត្រូវបានបង្ហាញជាមួយឧទាហរណ៍នេះ (ដោយចេតនាច្រឡំ)៖

ធ្វើ$$
ចាប់ផ្តើម
ប្រតិបត្តិ 'បង្កើតការនាំចូលតារាង' || 'ant_table (id int)';
END$$;

ការកត់ត្រាស្តង់ដារនឹងផ្តល់ឱ្យអ្នកនូវចំណុចនេះ៖

កំណត់ហេតុ៖ សេចក្តីថ្លែងការណ៍៖ ធ្វើ $$
ចាប់ផ្តើម
ប្រតិបត្តិ 'បង្កើតការនាំចូលតារាង' || 'ant_table (id int)';
END$$;

វាបង្ហាញថាការស្វែងរកតារាងចំណាប់អារម្មណ៍អាចទាមទារចំណេះដឹងអំពីកូដមួយចំនួនក្នុងករណីដែលតារាងត្រូវបានបង្កើតដោយថាមវន្ត។

នេះ​មិន​ល្អ​ទេ ព្រោះ​វា​ជា​ការ​ល្អ​ក្នុង​ការ​ស្វែង​រក​តាម​ឈ្មោះ​តារាង។

នេះជាកន្លែងដែល pgAudit ងាយស្រួល។

សម្រាប់ការបញ្ចូលដូចគ្នា វានឹងបង្កើតលទ្ធផលនេះនៅក្នុងកំណត់ហេតុ៖

សវនកម្ម៖ Session,33,1,FUNCTION,DO,,,"DO $$
ចាប់ផ្តើម
ប្រតិបត្តិ 'បង្កើតការនាំចូលតារាង' || 'ant_table (id int)';
END$$;"
សវនកម្ម៖ SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)

មិនត្រឹមតែប្លុក DO ត្រូវបានកត់ត្រាប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានអត្ថបទពេញលេញនៃ CREATE TABLE ដែលមានប្រភេទសេចក្តីថ្លែងការណ៍ ប្រភេទវត្ថុ និងឈ្មោះពេញ ដែលធ្វើឲ្យការស្វែងរកកាន់តែងាយស្រួល។

នៅពេលកត់ត្រាសេចក្តីថ្លែងការណ៍ SELECT និង DML pgAudit អាចត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីកត់ត្រាធាតុដាច់ដោយឡែកសម្រាប់ទំនាក់ទំនងនីមួយៗដែលយោងនៅក្នុងសេចក្តីថ្លែងការណ៍។

គ្មានការញែកត្រូវបានទាមទារដើម្បីស្វែងរកសេចក្តីថ្លែងការណ៍ទាំងអស់ដែលប៉ះតារាងជាក់លាក់មួយ(*) »។

តើវានឹងប៉ះពាល់ដល់ដំណើរការរបស់ DBMS យ៉ាងដូចម្តេច?

តោះដំណើរការការធ្វើតេស្តជាមួយនឹងការបើកសវនកម្មពេញលេញ ហើយមើលថាតើមានអ្វីកើតឡើងចំពោះការអនុវត្ត PostgreSQL ។ តោះបើកការកត់ត្រាទិន្នន័យអតិបរមាសម្រាប់ប៉ារ៉ាម៉ែត្រទាំងអស់។

យើងផ្លាស់ប្តូរស្ទើរតែគ្មានអ្វីនៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធនោះទេ អ្វីដែលសំខាន់បំផុតគឺត្រូវបើករបៀបបំបាត់កំហុស 5 ដើម្បីទទួលបានព័ត៌មានអតិបរមា។

postgresql.conf

log_destination = 'stderr'
loggging_collector = បើក
log_truncate_on_rotation = បើក
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = បំបាត់កំហុស ៥
log_min_error_statement = បំបាត់កំហុស ៥
log_min_duration_statement = 0
debug_print_parse=បើក
debug_print_rewritten = បើក
debug_print_plan=បើក
debug_pretty_print=បើក
log_checkpoints = បើក
log_connections = បើក
log_disconnections = បើក
log_duration = បើក
log_hostname = បើក
log_lock_wait = បើក
log_replication_commands = បើក
log_temp_files = 0
log_timezone = 'អឺរ៉ុប/មូស្គូ'

នៅលើ PostgreSQL DBMS ដែលមានប៉ារ៉ាម៉ែត្រ 1 CPU, 2,8 GHz, RAM 2 GB, HDD 40 GB យើងធ្វើតេស្ដផ្ទុកចំនួនបីដោយប្រើពាក្យបញ្ជា៖

$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmark

លទ្ធផល​តេ​ស្ត:

គ្មានការកត់ត្រាទេ។
ជាមួយនឹងការកាប់ឈើ

ពេលវេលាបំពេញមូលដ្ឋានទិន្នន័យសរុប
43,74 វិនាទី
53,23 វិនាទី

RAM
24%
40%

ស៊ីភីយូ
72%
91%

សាកល្បង 1 (50 ការតភ្ជាប់)

ចំនួនប្រតិបត្តិការក្នុងរយៈពេល 10 នាទី។
74169
32445

ប្រតិបត្តិការ/វិ
123
54

ភាពយឺតយ៉ាវជាមធ្យម
405 ms
925 ms

សាកល្បង 2 (150 ការតភ្ជាប់ជាមួយ 100 អាចធ្វើទៅបាន)

ចំនួនប្រតិបត្តិការក្នុងរយៈពេល 10 នាទី។
81727
31429

ប្រតិបត្តិការ/វិ
136
52

ភាពយឺតយ៉ាវជាមធ្យម
550 ms
1432 ms

អំពីទំហំ

ទំហំ DB
2251 មេកាបៃ។
2262 មេកាបៃ។

ទំហំកំណត់ហេតុមូលដ្ឋានទិន្នន័យ
0 MB
4587 MB

បន្ទាត់ខាងក្រោម៖ សវនកម្មពេញលេញគឺមិនសូវល្អទេ។ ទិន្នន័យដែលបានមកពីការធ្វើសវនកម្មនឹងមានទំហំធំដូចទិន្នន័យនៅក្នុងមូលដ្ឋានទិន្នន័យខ្លួនឯង ឬសូម្បីតែច្រើនជាងនេះ។ បរិមាណនៃការកាប់ឈើដែលត្រូវបានបង្កើតនៅពេលធ្វើការជាមួយ DBMS គឺជាបញ្ហាទូទៅក្នុងផលិតកម្ម។

តោះមើលប៉ារ៉ាម៉ែត្រផ្សេងទៀត៖

• ល្បឿនមិនផ្លាស់ប្តូរច្រើនទេ: ដោយគ្មានការកត់ត្រា - 43,74 វិនាទីជាមួយនឹងការកាប់ឈើ - 53,23 វិនាទី។
• ដំណើរការ RAM និង CPU នឹងរងទុក្ខ ដោយសារអ្នកត្រូវការបង្កើតឯកសារសវនកម្ម។ នេះក៏គួរឱ្យកត់សម្គាល់ផងដែរនៅក្នុងផលិតភាព។

នៅពេលដែលចំនួននៃការតភ្ជាប់កើនឡើង ជាធម្មតាដំណើរការនឹងកាន់តែយ៉ាប់យ៉ឺនបន្តិច។

នៅក្នុងសាជីវកម្មដែលមានសវនកម្មវាកាន់តែពិបាកជាងនេះទៅទៀត៖

• មានទិន្នន័យច្រើន;
• ការធ្វើសវនកម្មគឺត្រូវការមិនត្រឹមតែតាមរយៈ syslog នៅក្នុង SIEM ប៉ុណ្ណោះទេ ប៉ុន្តែក៏មាននៅក្នុងឯកសារផងដែរ៖ ប្រសិនបើមានអ្វីមួយកើតឡើងចំពោះ syslog ត្រូវតែមានឯកសារនៅជិតមូលដ្ឋានទិន្នន័យដែលទិន្នន័យត្រូវបានរក្សាទុក។
• ត្រូវការធ្នើដាច់ដោយឡែកសម្រាប់សវនកម្ម ដើម្បីកុំឱ្យខ្ជះខ្ជាយថាស I/O ព្រោះវាត្រូវការកន្លែងច្រើន
• វាកើតឡើងដែលបុគ្គលិកសន្តិសុខព័ត៌មានត្រូវការស្តង់ដារ GOST នៅគ្រប់ទីកន្លែងពួកគេទាមទារអត្តសញ្ញាណរដ្ឋ។

ការរឹតបន្តឹងការចូលប្រើទិន្នន័យ

សូមក្រឡេកមើលបច្ចេកវិទ្យាដែលត្រូវបានប្រើដើម្បីការពារទិន្នន័យ និងចូលប្រើវានៅក្នុង DBMSs ពាណិជ្ជកម្ម និងប្រភពបើកចំហ។

អ្វីដែលអ្នកអាចប្រើជាទូទៅ៖

1. ការអ៊ិនគ្រីប និងការភាន់ច្រលំនៃនីតិវិធី និងមុខងារ (រុំ) - នោះគឺជាឧបករណ៍ និងឧបករណ៍ប្រើប្រាស់ដាច់ដោយឡែកដែលធ្វើឱ្យកូដដែលអាចអានបានមិនអាចអានបាន។ ពិតមែនហើយ វាមិនអាចផ្លាស់ប្តូរ ឬកែប្រែឡើងវិញបានទេ។ វិធីសាស្រ្តនេះជួនកាលត្រូវបានទាមទារយ៉ាងហោចណាស់នៅខាង DBMS - តក្កវិជ្ជានៃការរឹតបន្តឹងអាជ្ញាប័ណ្ណ ឬតក្កវិជ្ជាការអនុញ្ញាតត្រូវបានអ៊ិនគ្រីបយ៉ាងជាក់លាក់នៅកម្រិតនីតិវិធី និងមុខងារ។
2. ការកំណត់ភាពមើលឃើញនៃទិន្នន័យតាមជួរ (RLS) គឺជាពេលដែលអ្នកប្រើប្រាស់ផ្សេងគ្នាឃើញតារាងមួយ ប៉ុន្តែសមាសភាពផ្សេងគ្នានៃជួរដេកនៅក្នុងវា ពោលគឺអ្វីមួយមិនអាចបង្ហាញដល់នរណាម្នាក់នៅកម្រិតជួរដេកបានទេ។
3. ការកែសម្រួលទិន្នន័យដែលបានបង្ហាញ (ការបិទបាំង) គឺជាពេលដែលអ្នកប្រើប្រាស់នៅក្នុងជួរឈរមួយនៃតារាងមើលឃើញទិន្នន័យ ឬមានតែសញ្ញាផ្កាយ ពោលគឺសម្រាប់អ្នកប្រើប្រាស់មួយចំនួនព័ត៌មាននឹងត្រូវបានបិទ។ បច្ចេកវិជ្ជាកំណត់ថាតើអ្នកប្រើប្រាស់ណាមួយត្រូវបានបង្ហាញពីអ្វីដោយផ្អែកលើកម្រិតនៃការចូលប្រើរបស់ពួកគេ។
4. សុវត្ថិភាព DBA/Application DBA/DBA access control ជាជាងការរឹតបន្តឹងការចូលប្រើ DBMS ខ្លួនឯង ពោលគឺបុគ្គលិកសន្តិសុខព័ត៌មានអាចត្រូវបានបំបែកចេញពីអ្នកគ្រប់គ្រងមូលដ្ឋានទិន្នន័យ និងអ្នកគ្រប់គ្រងកម្មវិធី។ មានបច្ចេកវិទ្យាបែបនេះតិចតួចនៅក្នុងប្រភពបើកចំហ ប៉ុន្តែមានច្រើននៅក្នុង DBMSs ពាណិជ្ជកម្ម។ ពួកគេត្រូវការនៅពេលដែលមានអ្នកប្រើប្រាស់ជាច្រើនដែលមានសិទ្ធិចូលប្រើម៉ាស៊ីនមេដោយខ្លួនឯង។
5. ការរឹតបន្តឹងការចូលប្រើឯកសារនៅកម្រិតប្រព័ន្ធឯកសារ។ អ្នកអាចផ្តល់សិទ្ធិ និងសិទ្ធិចូលប្រើទៅកាន់ថត ដូច្នេះអ្នកគ្រប់គ្រងនីមួយៗអាចចូលប្រើបានតែទិន្នន័យចាំបាច់ប៉ុណ្ណោះ។
6. ការចូលប្រើជាកាតព្វកិច្ច និងការសម្អាតអង្គចងចាំ - បច្ចេកវិទ្យាទាំងនេះកម្រត្រូវបានប្រើប្រាស់ណាស់។
7. ការអ៊ិនគ្រីបពីចុងដល់ចុងដោយផ្ទាល់ពី DBMS គឺជាការអ៊ិនគ្រីបខាងម៉ាស៊ីនភ្ញៀវ ជាមួយនឹងការគ្រប់គ្រងសោរនៅលើផ្នែកម៉ាស៊ីនមេ។
8. ការអ៊ិនគ្រីបទិន្នន័យ។ ឧទាហរណ៍ ការអ៊ិនគ្រីបជួរឈរគឺនៅពេលដែលអ្នកប្រើយន្តការដែលអ៊ិនគ្រីបជួរឈរតែមួយនៃមូលដ្ឋានទិន្នន័យ។

តើវាប៉ះពាល់ដល់ដំណើរការរបស់ DBMS យ៉ាងដូចម្តេច?

សូមក្រឡេកមើលឧទាហរណ៍នៃការអ៊ិនគ្រីបជួរឈរនៅក្នុង PostgreSQL ។ មានម៉ូឌុល pgcrypto វាអនុញ្ញាតឱ្យអ្នករក្សាទុកវាលដែលបានជ្រើសរើសក្នុងទម្រង់ដែលបានអ៊ិនគ្រីប។ វាមានប្រយោជន៍នៅពេលដែលទិន្នន័យខ្លះមានតម្លៃ។ ដើម្បីអានវាលដែលបានអ៊ិនគ្រីប អតិថិជនបញ្ជូនសោឌិគ្រីប ម៉ាស៊ីនមេ ឌិគ្រីបទិន្នន័យ ហើយបញ្ជូនវាទៅម៉ាស៊ីនភ្ញៀវវិញ។ បើគ្មានកូនសោទេ គ្មាននរណាម្នាក់អាចធ្វើអ្វីជាមួយទិន្នន័យរបស់អ្នកបានទេ។

តោះសាកល្បងជាមួយ pgcrypto. ចូរយើងបង្កើតតារាងមួយដែលមានទិន្នន័យដែលបានអ៊ិនគ្រីប និងទិន្នន័យធម្មតា។ ខាងក្រោមនេះជាពាក្យបញ្ជាសម្រាប់បង្កើតតារាង ដែលនៅក្នុងជួរទីមួយមានពាក្យបញ្ជាដែលមានប្រយោជន៍ - ការបង្កើតផ្នែកបន្ថែមដោយខ្លួនវាផ្ទាល់ជាមួយនឹងការចុះឈ្មោះ DBMS៖

CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));

បន្ទាប់មក យើងព្យាយាមបង្កើតគំរូទិន្នន័យពីតារាងនីមួយៗ ហើយមើលពេលវេលាប្រតិបត្តិ។

ការជ្រើសរើសពីតារាងដោយគ្មានមុខងារអ៊ិនគ្រីប:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

នាឡិកាបញ្ឈប់ត្រូវបានបើក។

  លេខសម្គាល់ | អត្ថបទ១ | អត្ថបទ ២
——+——-+——-
១ | ១ | ១
១ | ១ | ១
១ | ១ | ១
...
៩៩៧ | ៩៩៧ | ៩៩៧
៩៩៧ | ៩៩៧ | ៩៩៧
៩៩៧ | ៩៩៧ | ៩៩៧
១០០០ | ១០០០ | ១០០០
(១០០០ ជួរ)

ពេលវេលា៖ 1,386 ms

ការជ្រើសរើសពីតារាងដែលមានមុខងារអ៊ិនគ្រីប៖

psql -c "timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txt

នាឡិកាបញ្ឈប់ត្រូវបានបើក។

  លេខសម្គាល់ | ឌិគ្រីប | ឌិគ្រីប
——+——————+————
១ | x1 | x31
១ | x2 | x32
៣ | x3 | x33
...
១ | x999 | x393939
៣ | x1000 | x31303030
(១០០០ ជួរ)

ពេលវេលា៖ 50,203 ms

លទ្ធផល​តេ​ស្ត:

 
ដោយគ្មានការអ៊ិនគ្រីប
Pgcrypto (ឌិគ្រីប)

គំរូ 1000 ជួរ
1,386 ms
50,203 ms

ស៊ីភីយូ
15%
35%

RAM
 
+ 5%

ការ​អ៊ិនគ្រីប​មាន​ឥទ្ធិពល​ខ្លាំង​លើ​ការ​អនុវត្ត។ វាអាចត្រូវបានគេមើលឃើញថាពេលវេលាបានកើនឡើងចាប់តាំងពីប្រតិបត្តិការនៃការឌិគ្រីបទិន្នន័យដែលបានអ៊ិនគ្រីប (ហើយការឌិគ្រីបជាធម្មតានៅតែត្រូវបានរុំដោយតក្កវិជ្ជារបស់អ្នក) ទាមទារធនធានសំខាន់ៗ។ នោះគឺគំនិតនៃការអ៊ិនគ្រីបជួរឈរទាំងអស់ដែលមានទិន្នន័យមួយចំនួនគឺ fraught ជាមួយនឹងការថយចុះនៃការអនុវត្ត។

ទោះយ៉ាងណាក៏ដោយ ការអ៊ិនគ្រីបមិនមែនជាគ្រាប់កាំភ្លើងដែលដោះស្រាយបញ្ហាទាំងអស់នោះទេ។ ទិន្នន័យដែលបានឌិគ្រីប និងសោឌិគ្រីបកំឡុងពេលដំណើរការឌិគ្រីប និងបញ្ជូនទិន្នន័យមានទីតាំងនៅលើម៉ាស៊ីនមេ។ ដូច្នេះ សោអាចត្រូវបានស្ទាក់ចាប់ដោយអ្នកដែលមានសិទ្ធិចូលដំណើរការពេញលេញទៅកាន់ម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យ ដូចជាអ្នកគ្រប់គ្រងប្រព័ន្ធ។

នៅពេលដែលមានកូនសោមួយសម្រាប់ជួរឈរទាំងមូលសម្រាប់អ្នកប្រើប្រាស់ទាំងអស់ (ទោះបីជាមិនមែនសម្រាប់ទាំងអស់ក៏ដោយ ប៉ុន្តែសម្រាប់អតិថិជននៃសំណុំមានកំណត់) នេះមិនតែងតែល្អ និងត្រឹមត្រូវនោះទេ។ នោះហើយជាមូលហេតុដែលពួកគេចាប់ផ្តើមធ្វើការអ៊ិនគ្រីបពីចុងដល់ចប់ នៅក្នុង DBMS ពួកគេបានចាប់ផ្តើមពិចារណាជម្រើសសម្រាប់ការអ៊ិនគ្រីបទិន្នន័យនៅលើផ្នែកម៉ាស៊ីនភ្ញៀវ និងផ្នែកម៉ាស៊ីនមេ ហើយឃ្លាំងផ្ទុកសោរដដែលបានបង្ហាញខ្លួន - ផលិតផលដាច់ដោយឡែកដែលផ្តល់ការគ្រប់គ្រងសោរនៅលើ DBMS ចំហៀង។

ឧទាហរណ៍នៃការអ៊ិនគ្រីបបែបនេះនៅក្នុង MongoDB

លក្ខណៈពិសេសសុវត្ថិភាពនៅក្នុង DBMS ពាណិជ្ជកម្ម និងប្រភពបើកចំហ

អនុគមន៍
វាយ
គោលការណ៍ពាក្យសម្ងាត់
សវនកម្ម
ការការពារកូដប្រភពនៃនីតិវិធី និងមុខងារ
RLS ។
ការអ៊ីនគ្រីប

ក្រុមហ៊ុន Oracle
ពាណិជ្ជកម្ម
+
+
+
+
+

MsSql
ពាណិជ្ជកម្ម
+
+
+
+
+

ចាតូបា
ពាណិជ្ជកម្ម
+
+
+
+
ផ្នែកបន្ថែម

PostgreSQL
ដោយឥតគិតថ្លៃ
ផ្នែកបន្ថែម
ផ្នែកបន្ថែម
-
+
ផ្នែកបន្ថែម

MongoDb
ដោយឥតគិតថ្លៃ
-
+
-
-
មាននៅក្នុងក្រុមហ៊ុន MongoDB តែប៉ុណ្ណោះ

តារាងនេះគឺនៅឆ្ងាយពីពេញលេញ ប៉ុន្តែស្ថានភាពគឺដូចនេះ៖ នៅក្នុងផលិតផលពាណិជ្ជកម្ម បញ្ហាសុវត្ថិភាពត្រូវបានដោះស្រាយអស់រយៈពេលជាយូរនៅក្នុងប្រភពបើកចំហ ជាក្បួនប្រភេទកម្មវិធីបន្ថែមមួយចំនួនត្រូវបានប្រើប្រាស់សម្រាប់សុវត្ថិភាព មុខងារជាច្រើនត្រូវបានបាត់។ ពេលខ្លះអ្នកត្រូវបន្ថែមអ្វីមួយ។ ឧទាហរណ៍ គោលការណ៍ពាក្យសម្ងាត់ - PostgreSQL មានផ្នែកបន្ថែមផ្សេងៗគ្នាជាច្រើន (1, 2, 3, 4, 5) ដែលអនុវត្តគោលការណ៍ពាក្យសម្ងាត់ ប៉ុន្តែតាមគំនិតរបស់ខ្ញុំ គ្មាននរណាម្នាក់ក្នុងចំណោមពួកគេគ្របដណ្តប់តម្រូវការទាំងអស់នៃផ្នែកសាជីវកម្មក្នុងស្រុកនោះទេ។

អ្វីដែលត្រូវធ្វើប្រសិនបើអ្នកមិនមានអ្វីដែលអ្នកត្រូវការគ្រប់ទីកន្លែង? ឧទាហរណ៍ អ្នកចង់ប្រើ DBMS ជាក់លាក់ដែលមិនមានមុខងារដែលអតិថិជនទាមទារ។

បន្ទាប់មកអ្នកអាចប្រើដំណោះស្រាយភាគីទីបីដែលធ្វើការជាមួយ DBMSs ផ្សេងៗគ្នា ឧទាហរណ៍ Crypto DB ឬ Garda DB ។ ប្រសិនបើយើងកំពុងនិយាយអំពីដំណោះស្រាយពីផ្នែកក្នុងស្រុកនោះពួកគេដឹងអំពី GOSTs ប្រសើរជាងនៅក្នុងប្រភពបើកចំហ។

ជម្រើសទីពីរគឺត្រូវសរសេរអ្វីដែលអ្នកត្រូវការដោយខ្លួនឯង អនុវត្តការចូលប្រើទិន្នន័យ និងការអ៊ិនគ្រីបក្នុងកម្មវិធីនៅកម្រិតនីតិវិធី។ ពិតវានឹងកាន់តែពិបាកជាមួយ GOST ។ ប៉ុន្តែជាទូទៅ អ្នកអាចលាក់ទិន្នន័យតាមតម្រូវការ ដាក់វានៅក្នុង DBMS បន្ទាប់មកទាញយកវា ហើយឌិគ្រីបវាតាមតម្រូវការ ត្រឹមកម្រិតកម្មវិធី។ ក្នុងពេលជាមួយគ្នានេះ គិតភ្លាមៗអំពីរបៀបដែលអ្នកនឹងការពារក្បួនដោះស្រាយទាំងនេះនៅក្នុងកម្មវិធី។ តាមគំនិតរបស់យើង នេះគួរតែធ្វើនៅកម្រិត DBMS ព្រោះវានឹងដំណើរការលឿនជាងមុន។

របាយការណ៍នេះត្រូវបានបង្ហាញជាលើកដំបូងនៅ @ ប្រជុំ​មូលដ្ឋាន​ទិន្នន័យ ដោយ Mail.ru Cloud Solutions ។ មើល видео ការសម្តែងផ្សេងទៀត និងជាវការប្រកាសព្រឹត្តិការណ៍នៅលើ Telegram ជុំវិញ Kubernetes នៅ Mail.ru Group.

តើមានអ្វីទៀតដែលត្រូវអានលើប្រធានបទ:

1. ច្រើនជាង Ceph៖ ការផ្ទុកប្លុកពពក MCS.
2. របៀបជ្រើសរើសមូលដ្ឋានទិន្នន័យសម្រាប់គម្រោង ដូច្នេះអ្នកមិនចាំបាច់ជ្រើសរើសម្តងទៀតទេ។.

ប្រភព: www.habr.com