របៀបបង្កើតមិត្តជាមួយ GOST R 57580 និងនិម្មិតកុងតឺន័រ។ ការឆ្លើយតបរបស់ធនាគារកណ្តាល (និងគំនិតរបស់យើងលើបញ្ហានេះ)

មិនយូរប៉ុន្មានយើងបានអនុវត្តការវាយតម្លៃមួយផ្សេងទៀតនៃការអនុលោមតាមតម្រូវការនៃ GOST R 57580 (តទៅនេះហៅថាសាមញ្ញ GOST) ។ អតិថិជនគឺជាក្រុមហ៊ុនដែលបង្កើតប្រព័ន្ធទូទាត់អេឡិចត្រូនិច។ ប្រព័ន្ធនេះគឺធ្ងន់ធ្ងរ៖ អ្នកប្រើប្រាស់ជាង 3 លាននាក់ ប្រតិបត្តិការច្រើនជាង 200 ជារៀងរាល់ថ្ងៃ។ ពួកគេយកសុវត្ថិភាពព័ត៌មានយ៉ាងខ្លាំងនៅទីនោះ។

ក្នុងអំឡុងពេលដំណើរការវាយតម្លៃ អតិថិជនបានប្រកាសថា នាយកដ្ឋានអភិវឌ្ឍន៍ បន្ថែមពីលើម៉ាស៊ីននិម្មិត គ្រោងនឹងប្រើប្រាស់ធុង។ ប៉ុន្តែជាមួយនឹងបញ្ហានេះអតិថិជនបានបន្ថែមថាមានបញ្ហាមួយ: នៅក្នុង GOST មិនមានពាក្យអំពី Docker ដូចគ្នាទេ។ តើ​ខ្ញុ​ុំ​គួរ​ធ្វើអ្វី? តើធ្វើដូចម្តេចដើម្បីវាយតម្លៃសុវត្ថិភាពនៃធុង?

វាជាការពិត GOST សរសេរតែអំពីការនិម្មិតផ្នែករឹង - អំពីរបៀបការពារម៉ាស៊ីននិម្មិត ឧបករណ៍ត្រួតពិនិត្យខ្ពស់ និងម៉ាស៊ីនមេ។ យើង​បាន​សុំ​ការ​បំភ្លឺ​ពី​ធនាគារ​កណ្តាល។ ចម្លើយធ្វើឱ្យយើងឆ្ងល់។

GOST និងនិម្មិត

ដើម្បីចាប់ផ្តើម អនុញ្ញាតឱ្យយើងរំលឹកថា GOST R 57580 គឺជាស្តង់ដារថ្មីមួយដែលបញ្ជាក់ "តម្រូវការសម្រាប់ការធានាសុវត្ថិភាពព័ត៌មានរបស់អង្គការហិរញ្ញវត្ថុ" (FI) ។ FIs ទាំងនេះរួមមានប្រតិបត្តិករ និងអ្នកចូលរួមនៃប្រព័ន្ធទូទាត់ អង្គការឥណទាន និងមិនមែនឥណទាន មជ្ឈមណ្ឌលប្រតិបត្តិការ និងបោសសំអាត។

ចាប់ពីថ្ងៃទី 1 ខែមករា ឆ្នាំ 2021 ស្ថាប័ន FIs ត្រូវបានតម្រូវឱ្យធ្វើ ការវាយតម្លៃនៃការអនុលោមតាមតម្រូវការនៃ GOST ថ្មី។. យើង ITGLOBAL.COM គឺជាក្រុមហ៊ុនសវនកម្មដែលធ្វើការវាយតម្លៃបែបនេះ។

GOST មានផ្នែករងដែលឧទ្ទិសដល់ការការពារបរិស្ថាននិម្មិត - លេខ 7.8 ។ ពាក្យ "និម្មិត" មិនត្រូវបានបញ្ជាក់នៅទីនោះទេ មិនមានការបែងចែកទៅជាផ្នែករឹង និងកុងតឺន័រនិម្មិតនិម្មិតទេ។ អ្នកឯកទេសផ្នែកព័ត៌មានវិទ្យាណាមួយនឹងនិយាយថាតាមទស្សនៈបច្ចេកទេសនេះមិនត្រឹមត្រូវទេ៖ ម៉ាស៊ីននិម្មិត (VM) និងកុងតឺន័រគឺជាបរិយាកាសខុសៗគ្នា ដោយមានគោលការណ៍ឯកោផ្សេងៗគ្នា។ តាមទស្សនៈនៃភាពងាយរងគ្រោះរបស់ម៉ាស៊ីនដែល VM និង Docker containers ត្រូវបានដាក់ពង្រាយ នេះក៏ជាភាពខុសគ្នាដ៏ធំមួយផងដែរ។

វាប្រែថាការវាយតម្លៃសុវត្ថិភាពព័ត៌មានរបស់ VMs និងកុងតឺន័រក៏គួរតែខុសគ្នាដែរ។

សំណួររបស់យើងទៅកាន់ធនាគារកណ្តាល

យើងបានបញ្ជូនពួកគេទៅនាយកដ្ឋានសន្តិសុខព័ត៌មាននៃធនាគារកណ្តាល (យើងបង្ហាញសំណួរជាទម្រង់អក្សរកាត់)។

1. តើធ្វើដូចម្តេចដើម្បីពិចារណាធុងនិម្មិតប្រភេទ Docker នៅពេលវាយតម្លៃការអនុលោមតាម GOST? តើវាត្រឹមត្រូវទេក្នុងការវាយតម្លៃបច្ចេកវិទ្យាស្របតាមផ្នែករង 7.8 នៃ GOST?
2. តើធ្វើដូចម្តេចដើម្បីវាយតម្លៃឧបករណ៍គ្រប់គ្រងធុងនិម្មិត? តើវាអាចទៅរួចទេក្នុងការប្រៀបធៀបពួកវាទៅនឹងសមាសធាតុនិម្មិតរបស់ម៉ាស៊ីនមេ ហើយវាយតម្លៃវាដោយអនុលោមតាមផ្នែករងដូចគ្នានៃ GOST?
3. តើខ្ញុំត្រូវវាយតម្លៃដោយឡែកពីគ្នាអំពីសុវត្ថិភាពនៃព័ត៌មាននៅក្នុង Docker containers ដែរឬទេ? បើដូច្នេះ តើការការពារសុវត្ថិភាពអ្វីខ្លះដែលគួរត្រូវបានពិចារណាសម្រាប់រឿងនេះ ក្នុងអំឡុងពេលដំណើរការវាយតម្លៃ?
4. ប្រសិនបើកុងតឺន័រស្មើនឹងហេដ្ឋារចនាសម្ព័ន្ធនិម្មិត ហើយត្រូវបានវាយតម្លៃដោយអនុផ្នែក 7.8 តើតម្រូវការ GOST សម្រាប់ការអនុវត្តឧបករណ៍សុវត្ថិភាពព័ត៌មានពិសេសត្រូវបានអនុវត្តយ៉ាងដូចម្តេច?

ការឆ្លើយតបរបស់ធនាគារកណ្តាល

ខាង​ក្រោម​នេះ​គឺ​ជា​សម្រង់​ចម្បង។

"GOST R 57580.1-2017 បង្កើតតម្រូវការសម្រាប់ការអនុវត្តតាមរយៈការអនុវត្តវិធានការបច្ចេកទេសទាក់ទងនឹងវិធានការខាងក្រោម ZI ផ្នែករង 7.8 នៃ GOST R 57580.1-2017 ដែលតាមគំនិតរបស់នាយកដ្ឋានអាចត្រូវបានពង្រីកទៅករណីនៃការប្រើប្រាស់និម្មិតកុងតឺន័រ។ បច្ចេកវិជ្ជាដោយគិតគូរដូចខាងក្រោមៈ

• ការអនុវត្តវិធានការ ZSV.1 - ZSV.11 សម្រាប់ការរៀបចំការកំណត់អត្តសញ្ញាណ ការផ្ទៀងផ្ទាត់ ការអនុញ្ញាត (ការគ្រប់គ្រងការចូលប្រើ) នៅពេលអនុវត្តការចូលប្រើឡូជីខលទៅកាន់ម៉ាស៊ីននិម្មិត និងសមាសភាគម៉ាស៊ីនមេនិម្មិតអាចខុសគ្នាពីករណីនៃការប្រើប្រាស់បច្ចេកវិទ្យានិម្មិតកុងតឺន័រ។ ដោយគិតពីចំណុចនេះ ដើម្បីអនុវត្តវិធានការមួយចំនួន (ឧទាហរណ៍ ZVS.6 និង ZVS.7) យើងជឿជាក់ថា វាគឺអាចធ្វើទៅបានដើម្បីផ្តល់អនុសាសន៍ថាស្ថាប័នហិរញ្ញវត្ថុបង្កើតវិធានការទូទាត់សងដែលនឹងបន្តគោលដៅដូចគ្នា។
• ការអនុវត្តវិធានការ ZSV.13 - ZSV.22 សម្រាប់ការរៀបចំ និងការគ្រប់គ្រងអន្តរកម្មព័ត៌មាននៃម៉ាស៊ីននិម្មិត ផ្តល់សម្រាប់ការបែងចែកបណ្តាញកុំព្យូទ័ររបស់អង្គការហិរញ្ញវត្ថុ ដើម្បីបែងចែករវាងវត្ថុផ្តល់ព័ត៌មានដែលអនុវត្តបច្ចេកវិទ្យានិម្មិត និងជាកម្មសិទ្ធិរបស់សៀគ្វីសុវត្ថិភាពផ្សេងៗគ្នា។ ដោយគិតពីចំណុចនេះ យើងជឿថា វាគឺជាទីប្រឹក្សាដើម្បីផ្តល់នូវការបែងចែកសមស្រប នៅពេលប្រើប្រាស់បច្ចេកវិជ្ជានិម្មិតកុងតឺន័រ (ទាំងទាក់ទងនឹងធុងនិម្មិតដែលអាចប្រតិបត្តិបាន និងទាក់ទងនឹងប្រព័ន្ធនិម្មិតដែលប្រើនៅកម្រិតប្រព័ន្ធប្រតិបត្តិការ);
• ការអនុវត្តវិធានការ ZSV.26, ZSV.29 - ZSV.31 ដើម្បីរៀបចំការការពាររូបភាពនៃម៉ាស៊ីននិម្មិតគួរតែត្រូវបានអនុវត្តដោយការស្រដៀងគ្នាផងដែរដើម្បីការពាររូបភាពមូលដ្ឋាន និងបច្ចុប្បន្ននៃធុងនិម្មិត។
• ការអនុវត្តវិធានការ ZVS.32 - ZVS.43 សម្រាប់ការកត់ត្រាព្រឹត្តិការណ៍សុវត្ថិភាពព័ត៌មានទាក់ទងនឹងការចូលប្រើម៉ាស៊ីននិម្មិត និងសមាសភាគនិម្មិតរបស់ម៉ាស៊ីនមេ គួរតែត្រូវបានអនុវត្តដោយការប្ៀបប្ដូចជាមួយផងដែរទាក់ទងនឹងធាតុនៃបរិស្ថាននិម្មិតដែលអនុវត្តបច្ចេកវិទ្យានិម្មិតកុងតឺន័រ។

តើ​វា​មានន័យ​យ៉ាង​ដូចម្តេច

ការសន្និដ្ឋានសំខាន់ៗចំនួនពីរពីការឆ្លើយតបរបស់នាយកដ្ឋានសន្តិសុខព័ត៌មានរបស់ធនាគារកណ្តាល៖

• វិធានការការពារធុងមិនខុសពីវិធានការការពារម៉ាស៊ីននិម្មិតទេ។
• វាកើតឡើងពីនេះ ដែលនៅក្នុងបរិបទនៃសន្តិសុខព័ត៌មាន ធនាគារកណ្តាលស្មើនឹងការនិម្មិតពីរប្រភេទ - Docker containers និង VMs ។

ការឆ្លើយតបក៏និយាយអំពី "វិធានការសំណង" ដែលត្រូវអនុវត្តដើម្បីបន្សាបការគំរាមកំហែង។ វាគ្រាន់តែមិនច្បាស់ថា "វិធានការសំណង" ទាំងនេះជាអ្វី និងរបៀបវាស់ស្ទង់ភាពគ្រប់គ្រាន់ ភាពពេញលេញ និងប្រសិទ្ធភាពរបស់ពួកគេ។

តើ​ជំហរ​របស់​ធនាគារ​កណ្តាល​មាន​បញ្ហា​អ្វី?

ប្រសិនបើអ្នកប្រើអនុសាសន៍របស់ធនាគារកណ្តាលកំឡុងពេលវាយតម្លៃ (និងការវាយតម្លៃដោយខ្លួនឯង) អ្នកត្រូវដោះស្រាយការលំបាកផ្នែកបច្ចេកទេស និងឡូជីខលមួយចំនួន។

• កុងតឺន័រដែលអាចប្រតិបត្តិបាននីមួយៗតម្រូវឱ្យមានការដំឡើងកម្មវិធីការពារព័ត៌មាន (IP) នៅលើវា៖ កំចាត់មេរោគ ការត្រួតពិនិត្យភាពសុចរិត ធ្វើការជាមួយកំណត់ហេតុ ប្រព័ន្ធ DLP (ការការពារការលេចធ្លាយទិន្នន័យ) ជាដើម។ ទាំងអស់នេះអាចត្រូវបានដំឡើងនៅលើ VM ដោយគ្មានបញ្ហាអ្វីទាំងអស់ ប៉ុន្តែក្នុងករណីកុងតឺន័រ ការដំឡើងសុវត្ថិភាពព័ត៌មានគឺជាការផ្លាស់ប្តូរមិនសមហេតុផល។ ធុងផ្ទុកមានចំនួនអប្បបរមានៃ "ឧបករណ៍រាងកាយ" ដែលត្រូវការសម្រាប់សេវាកម្មដំណើរការ។ ការដំឡើង SZI នៅក្នុងវាផ្ទុយពីអត្ថន័យរបស់វា។
• រូបភាពកុងតឺន័រគួរតែត្រូវបានការពារតាមគោលការណ៍ដូចគ្នា របៀបអនុវត្តនេះក៏មិនច្បាស់ដែរ។
• GOST តម្រូវឱ្យដាក់កម្រិតការចូលប្រើសមាសភាគនិម្មិតរបស់ម៉ាស៊ីនមេ ពោលគឺចំពោះអ្នកមើលការខុសត្រូវ។ តើអ្វីត្រូវបានចាត់ទុកថាជាសមាសភាគម៉ាស៊ីនមេនៅក្នុងករណី Docker? តើនេះមិនមានន័យថាកុងតឺន័រនីមួយៗត្រូវដំណើរការលើម៉ាស៊ីនដាច់ដោយឡែកទេឬ?
• ប្រសិនបើសម្រាប់និម្មិតនិម្មិតធម្មតា វាអាចកំណត់ VMs តាមវណ្ឌវង្កសុវត្ថិភាព និងផ្នែកបណ្តាញ បន្ទាប់មកក្នុងករណី Docker containers នៅក្នុង host តែមួយ នេះមិនមែនជាករណីនោះទេ។

នៅក្នុងការអនុវត្ត វាទំនងជាថាសវនករនីមួយៗនឹងវាយតម្លៃសុវត្ថិភាពនៃកុងតឺន័រតាមវិធីផ្ទាល់ខ្លួនរបស់គាត់ ដោយផ្អែកលើចំណេះដឹង និងបទពិសោធន៍ផ្ទាល់ខ្លួនរបស់គាត់។ ជាការប្រសើរណាស់ឬមិនវាយតម្លៃវាទាល់តែសោះប្រសិនបើមិនមានមួយឬផ្សេងទៀត។

ក្នុងករណី យើងនឹងបន្ថែមថាចាប់ពីថ្ងៃទី 1 ខែមករា ឆ្នាំ 2021 ពិន្ទុអប្បបរមាត្រូវតែមិនទាបជាង 0,7 ទេ។

ដោយវិធីនេះ យើងបង្ហោះការឆ្លើយតប និងយោបល់ជាទៀងទាត់ពីនិយតករទាក់ទងនឹងតម្រូវការនៃ GOST 57580 និងបទប្បញ្ញត្តិរបស់ធនាគារកណ្តាលនៅក្នុងរបស់យើង ឆានែល Telegram.

អ្វីដែលត្រូវធ្វើ

តាមគំនិតរបស់យើង អង្គការហិរញ្ញវត្ថុមានជម្រើសតែពីរប៉ុណ្ណោះសម្រាប់ការដោះស្រាយបញ្ហា។

1. ជៀសវាងការអនុវត្តធុង

ដំណោះស្រាយសម្រាប់អ្នកដែលត្រៀមខ្លួនរួចជាស្រេចក្នុងលទ្ធភាពប្រើប្រាស់តែ Hardware Virtualization ហើយក្នុងពេលតែមួយខ្លាចការវាយតម្លៃទាបយោងទៅតាម GOST និងការផាកពិន័យពីធនាគារកណ្តាល។

បូក៖ វាកាន់តែងាយស្រួលក្នុងការអនុលោមតាមតម្រូវការនៃផ្នែករង 7.8 នៃ GOST ។

ដក៖ យើង​នឹង​ត្រូវ​បោះបង់​ឧបករណ៍​អភិវឌ្ឍន៍​ថ្មី​ដែល​ផ្អែក​លើ​និម្មិត​កុងតឺន័រ ជាពិសេស Docker និង Kubernetes។

2. បដិសេធមិនអនុលោមតាមតម្រូវការនៃផ្នែករង 7.8 នៃ GOST

ប៉ុន្តែក្នុងពេលជាមួយគ្នានេះ សូមអនុវត្តការអនុវត្តល្អបំផុតក្នុងការធានាសុវត្ថិភាពព័ត៌មាននៅពេលធ្វើការជាមួយកុងតឺន័រ។ នេះគឺជាដំណោះស្រាយសម្រាប់អ្នកដែលផ្តល់តម្លៃដល់បច្ចេកវិទ្យាថ្មី និងឱកាសដែលពួកគេផ្តល់។ តាមរយៈ "ការអនុវត្តល្អបំផុត" យើងមានន័យថាស្តង់ដារ និងស្តង់ដារដែលទទួលស្គាល់ដោយឧស្សាហកម្មសម្រាប់ការធានាសុវត្ថិភាពនៃធុង Docker៖

• សុវត្ថិភាពនៃម៉ាស៊ីន OS ការកំណត់រចនាសម្ព័ន្ធត្រឹមត្រូវ ការកត់ត្រាការហាមឃាត់ការផ្លាស់ប្តូរទិន្នន័យរវាងកុងតឺន័រ។ល។
• ដោយប្រើមុខងារ Docker Trust ដើម្បីពិនិត្យមើលភាពត្រឹមត្រូវនៃរូបភាព និងការប្រើប្រាស់ម៉ាស៊ីនស្កេនភាពងាយរងគ្រោះដែលភ្ជាប់មកជាមួយ។
• យើងមិនត្រូវភ្លេចអំពីសុវត្ថិភាពនៃការចូលប្រើពីចម្ងាយ និងគំរូបណ្តាញទាំងមូលទេ៖ ការវាយប្រហារដូចជា ARP-spoofing និង MAC-flooding មិនត្រូវបានលុបចោលទេ។

បូក៖ មិនមានការរឹតបន្តឹងបច្ចេកទេសលើការប្រើប្រាស់កុងតឺន័រនិម្មិត។

ដក៖ មានប្រូបាប៊ីលីតេខ្ពស់ដែលនិយតករនឹងដាក់ទណ្ឌកម្មចំពោះការមិនអនុលោមតាមតម្រូវការ GOST ។

សេចក្តីសន្និដ្ឋាន

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

តើអ្នកនឹងធ្វើអ្វីក្នុងស្ថានភាពនេះ?

ប្រភព: www.habr.com