ការត្រួតពិនិត្យសុវត្ថិភាពលើពពក

ការផ្លាស់ទីទិន្នន័យ និងកម្មវិធីទៅពពកបង្ហាញពីបញ្ហាប្រឈមថ្មីសម្រាប់ SOCs សាជីវកម្ម ដែលមិនតែងតែត្រៀមខ្លួនជាស្រេចក្នុងការត្រួតពិនិត្យហេដ្ឋារចនាសម្ព័ន្ធរបស់មនុស្សផ្សេងទៀត។ យោងតាម ​​Netoskope សហគ្រាសជាមធ្យម (ជាក់ស្តែងនៅសហរដ្ឋអាមេរិក) ប្រើប្រាស់សេវាកម្ម Cloud ផ្សេងៗគ្នាចំនួន 1246 ដែលស្មើនឹង 22% ច្រើនជាងឆ្នាំមុន។ សេវាកម្មពពក 1246 !!! 175 នៃពួកគេទាក់ទងនឹងសេវាកម្មធនធានមនុស្ស 170 ទាក់ទងនឹងទីផ្សារ 110 នៅក្នុងវិស័យទំនាក់ទំនង និង 76 ស្ថិតក្នុងផ្នែកហិរញ្ញវត្ថុ និង CRM ។ Cisco ប្រើសេវាកម្មពពកខាងក្រៅ "តែ" 700 ប៉ុណ្ណោះ។ ដូច្នេះ​ខ្ញុំ​យល់​ច្រឡំ​បន្តិច​ដោយ​លេខ​ទាំង​នេះ។ ប៉ុន្តែក្នុងករណីណាក៏ដោយ បញ្ហាមិនស្ថិតនៅជាមួយពួកគេទេ ប៉ុន្តែជាមួយនឹងការពិតដែលថា ពពកកំពុងចាប់ផ្តើមប្រើប្រាស់យ៉ាងសកម្មដោយក្រុមហ៊ុនចំនួនកើនឡើងដែលចង់មានសមត្ថភាពដូចគ្នាសម្រាប់ត្រួតពិនិត្យហេដ្ឋារចនាសម្ព័ន្ធពពកដូចនៅក្នុងបណ្តាញផ្ទាល់ខ្លួនរបស់ពួកគេ។ ហើយនិន្នាការនេះកំពុងកើនឡើង - យោងតាម នេះ​បើ​តាម​សភា​គណនី​អាមេរិក នៅឆ្នាំ 2023 មជ្ឈមណ្ឌលទិន្នន័យ 1200 នឹងត្រូវបិទនៅសហរដ្ឋអាមេរិក (6250 បានបិទរួចហើយ)។ ប៉ុន្តែការផ្លាស់ប្តូរទៅពពកមិនមែនគ្រាន់តែ "អនុញ្ញាតឱ្យយើងផ្លាស់ទីម៉ាស៊ីនមេរបស់យើងទៅអ្នកផ្តល់សេវាខាងក្រៅ។" ស្ថាបត្យកម្ម IT ថ្មី កម្មវិធីថ្មី ដំណើរការថ្មី ការរឹតបន្តឹងថ្មី... ទាំងអស់នេះនាំមកនូវការផ្លាស់ប្តូរយ៉ាងសំខាន់ចំពោះការងាររបស់ IT មិនត្រឹមតែប៉ុណ្ណោះទេ ថែមទាំងសុវត្ថិភាពព័ត៌មានផងដែរ។ ហើយប្រសិនបើអ្នកផ្តល់សេវាបានរៀនពីរបៀបដើម្បីទប់ទល់នឹងការធានាសុវត្ថិភាពនៃពពកខ្លួនឯង (ជាសំណាងល្អមានការណែនាំជាច្រើន) បន្ទាប់មកជាមួយនឹងការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានលើពពក ជាពិសេសនៅលើវេទិកា SaaS មានការលំបាកយ៉ាងខ្លាំងដែលយើងនឹងនិយាយអំពី។

ឧបមាថាក្រុមហ៊ុនរបស់អ្នកបានផ្លាស់ប្តូរផ្នែកនៃហេដ្ឋារចនាសម្ព័ន្ធរបស់ខ្លួនទៅកាន់ពពក... ឈប់។ មិនមែនវិធីនេះទេ។ ប្រសិនបើហេដ្ឋារចនាសម្ព័ន្ធត្រូវបានផ្ទេរ ហើយឥឡូវនេះអ្នកគ្រាន់តែគិតអំពីរបៀបដែលអ្នកនឹងត្រួតពិនិត្យវា នោះអ្នកបានបាត់បង់ហើយ។ លុះត្រាតែវាជា Amazon, Google ឬ Microsoft (ហើយបន្ទាប់មកជាមួយនឹងការកក់ទុក) អ្នកប្រហែលជាមិនមានលទ្ធភាពច្រើនក្នុងការត្រួតពិនិត្យទិន្នន័យ និងកម្មវិធីរបស់អ្នកទេ។ វាល្អប្រសិនបើអ្នកត្រូវបានផ្តល់ឱកាសឱ្យធ្វើការជាមួយកំណត់ហេតុ។ ពេលខ្លះទិន្នន័យព្រឹត្តិការណ៍សុវត្ថិភាពនឹងមាន ប៉ុន្តែអ្នកនឹងមិនអាចចូលប្រើវាបានទេ។ ឧទាហរណ៍ Office 365. ប្រសិនបើអ្នកមានអាជ្ញាប័ណ្ណ E1 ថោកបំផុត នោះព្រឹត្តិការណ៍សុវត្ថិភាពមិនមានសម្រាប់អ្នកទាល់តែសោះ។ ប្រសិនបើអ្នកមានអាជ្ញាប័ណ្ណ E3 ទិន្នន័យរបស់អ្នកត្រូវបានរក្សាទុកត្រឹមតែ 90 ថ្ងៃប៉ុណ្ណោះ ហើយប្រសិនបើអ្នកមានអាជ្ញាប័ណ្ណ E5 រយៈពេលនៃកំណត់ហេតុអាចប្រើបានមួយឆ្នាំ (ទោះជាយ៉ាងណាក៏ដោយ នេះក៏មានចំនុចពិសេសរបស់វាទាក់ទងនឹងតម្រូវការដាច់ដោយឡែកពីគ្នាផងដែរ។ ស្នើសុំមុខងារមួយចំនួនសម្រាប់ធ្វើការជាមួយកំណត់ហេតុពីការគាំទ្ររបស់ Microsoft) ។ ដោយវិធីនេះ អាជ្ញាប័ណ្ណ E3 គឺខ្សោយជាងក្នុងលក្ខខណ្ឌនៃមុខងារត្រួតពិនិត្យជាងការផ្លាស់ប្តូរសាជីវកម្ម។ ដើម្បីសម្រេចបានកម្រិតដូចគ្នា អ្នកត្រូវការអាជ្ញាប័ណ្ណ E5 ឬអាជ្ញាប័ណ្ណអនុលោមភាពកម្រិតខ្ពស់បន្ថែម ដែលអាចត្រូវការប្រាក់បន្ថែមដែលមិនត្រូវបានរាប់បញ្ចូលទៅក្នុងគំរូហិរញ្ញវត្ថុរបស់អ្នកសម្រាប់ការផ្លាស់ប្តូរទៅហេដ្ឋារចនាសម្ព័ន្ធពពក។ ហើយនេះគ្រាន់តែជាឧទាហរណ៍មួយនៃការប៉ាន់ស្មានមិនដល់នៃបញ្ហាទាក់ទងនឹងការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានលើពពក។ នៅក្នុងអត្ថបទនេះ ដោយមិនធ្វើពុតជាពេញលេញទេ ខ្ញុំចង់ទាក់ទាញការយកចិត្តទុកដាក់ចំពោះចំណុចមួយចំនួនដែលគួរត្រូវយកមកពិចារណានៅពេលជ្រើសរើសអ្នកផ្តល់សេវាពពកតាមទស្សនៈសុវត្ថិភាព។ ហើយនៅចុងបញ្ចប់នៃអត្ថបទ បញ្ជីត្រួតពិនិត្យនឹងត្រូវបានផ្តល់ឱ្យដែលមានតម្លៃបំពេញមុនពេលពិចារណាថាបញ្ហានៃការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានពពកត្រូវបានដោះស្រាយ។

មានបញ្ហាធម្មតាមួយចំនួនដែលនាំឱ្យមានឧប្បត្តិហេតុនៅក្នុងបរិស្ថានពពក ដែលសេវាកម្មសន្តិសុខព័ត៌មានមិនមានពេលឆ្លើយតប ឬមិនឃើញពួកវាទាល់តែសោះ៖

• កំណត់ហេតុសុវត្ថិភាពមិនមានទេ។ នេះគឺជាស្ថានភាពធម្មតាមួយ ជាពិសេសក្នុងចំណោមអ្នកលេងថ្មីថ្មោងនៅក្នុងទីផ្សារដំណោះស្រាយលើពពក។ ប៉ុន្តែអ្នកមិនគួរបោះបង់ពួកគេភ្លាមៗនោះទេ។ អ្នកលេងតូចៗ ជាពិសេសអ្នកក្នុងស្រុក មានភាពរសើបចំពោះតម្រូវការរបស់អតិថិជន ហើយអាចអនុវត្តមុខងារដែលត្រូវការមួយចំនួនបានយ៉ាងឆាប់រហ័ស ដោយផ្លាស់ប្តូរផែនទីបង្ហាញផ្លូវដែលបានអនុម័តសម្រាប់ផលិតផលរបស់ពួកគេ។ បាទ/ចាស វានឹងមិនមែនជា analogue នៃ GuardDuty ពី Amazon ឬម៉ូឌុល "Proactive Protection" ពី Bitrix នោះទេ ប៉ុន្តែយ៉ាងហោចណាស់ក៏មានអ្វីមួយដែរ។
• សុវត្ថិភាព​ព័ត៌មាន​មិន​ដឹង​ថា​កំណត់ហេតុ​ត្រូវ​បាន​រក្សា​ទុក​នៅ​ទី​ណា ឬ​មិន​មាន​ការ​ចូល​ប្រើប្រាស់​ពួកវា​ទេ។ នៅទីនេះវាចាំបាច់ក្នុងការចូលទៅក្នុងការចរចាជាមួយអ្នកផ្តល់សេវាពពក - ប្រហែលជាគាត់នឹងផ្តល់ព័ត៌មានបែបនេះប្រសិនបើគាត់ចាត់ទុកអតិថិជនសំខាន់ចំពោះគាត់។ ប៉ុន្តែ​ជាទូទៅ វា​មិនល្អ​ខ្លាំង​ទេ​នៅពេល​ការចូល​ប្រើ​កំណត់ហេតុ​ត្រូវបាន​ផ្តល់ “​ដោយ​ការសម្រេចចិត្ត​ពិសេស​”​។
• វាក៏កើតឡើងផងដែរដែលអ្នកផ្តល់សេវាពពកមានកំណត់ហេតុ ប៉ុន្តែពួកគេផ្តល់នូវការត្រួតពិនិត្យ និងការកត់ត្រាព្រឹត្តិការណ៍ដែលមានកម្រិត ដែលមិនគ្រប់គ្រាន់ក្នុងការរកឃើញឧប្បត្តិហេតុទាំងអស់។ ឧទាហរណ៍ អ្នកអាចទទួលបានតែកំណត់ហេតុនៃការផ្លាស់ប្តូរនៅលើគេហទំព័រ ឬកំណត់ហេតុនៃការព្យាយាមផ្ទៀងផ្ទាត់អ្នកប្រើប្រាស់ ប៉ុន្តែមិនមែនព្រឹត្តិការណ៍ផ្សេងទៀតទេ ឧទាហរណ៍អំពីចរាចរណ៍បណ្តាញ ដែលនឹងលាក់បាំងពីអ្នកនូវស្រទាប់ទាំងមូលនៃព្រឹត្តិការណ៍ដែលបង្ហាញពីការប៉ុនប៉ងលួចចូលហេដ្ឋារចនាសម្ព័ន្ធពពករបស់អ្នក។ .
• មានកំណត់ហេតុ ប៉ុន្តែការចូលប្រើពួកវាគឺពិបាកក្នុងការធ្វើស្វ័យប្រវត្តិកម្ម ដែលបង្ខំឱ្យពួកគេត្រួតពិនិត្យមិនបន្ត ប៉ុន្តែតាមកាលវិភាគ។ ហើយប្រសិនបើអ្នកមិនអាចទាញយកកំណត់ហេតុដោយស្វ័យប្រវត្តិទេនោះ ការទាញយកកំណត់ហេតុជាឧទាហរណ៍ក្នុងទម្រង់ Excel (ដូចអ្នកផ្តល់ដំណោះស្រាយពពកក្នុងស្រុកមួយចំនួន) អាចនាំឱ្យមានការស្ទាក់ស្ទើរចំពោះផ្នែកនៃសេវាកម្មសន្តិសុខព័ត៌មានសាជីវកម្មក្នុងការ tinker ជាមួយពួកគេ។
• គ្មានការត្រួតពិនិត្យកំណត់ហេតុទេ។ នេះប្រហែលជាហេតុផលមិនច្បាស់លាស់បំផុតសម្រាប់ការកើតឡើងនៃឧប្បត្តិហេតុសុវត្ថិភាពព័ត៌មាននៅក្នុងបរិស្ថានពពក។ វាហាក់បីដូចជាមានកំណត់ហេតុ ហើយវាអាចទៅរួចក្នុងការចូលប្រើពួកវាដោយស្វ័យប្រវត្តិ ប៉ុន្តែគ្មាននរណាម្នាក់ធ្វើបែបនេះទេ។ ហេតុអ្វី?

បានចែករំលែកគំនិតសុវត្ថិភាពលើពពក

ការផ្លាស់ប្តូរទៅពពកគឺតែងតែជាការស្វែងរកតុល្យភាពរវាងបំណងប្រាថ្នាដើម្បីរក្សាការគ្រប់គ្រងលើហេដ្ឋារចនាសម្ព័ន្ធ និងការផ្ទេរវាទៅដៃដែលមានជំនាញវិជ្ជាជីវៈជាងរបស់អ្នកផ្តល់សេវាពពកដែលមានជំនាញក្នុងការថែរក្សាវា។ ហើយនៅក្នុងវិស័យសុវត្ថិភាពពពក តុល្យភាពនេះក៏ត្រូវតែស្វែងរកផងដែរ។ ជាងនេះទៅទៀត អាស្រ័យលើគំរូនៃការចែកចាយសេវាពពកដែលបានប្រើ (IaaS, PaaS, SaaS) សមតុល្យនេះនឹងខុសគ្នាគ្រប់ពេលវេលា។ ក្នុងករណីណាក៏ដោយ យើងត្រូវតែចងចាំថា អ្នកផ្តល់សេវាពពកទាំងអស់សព្វថ្ងៃនេះ ធ្វើតាមអ្វីដែលហៅថា ទំនួលខុសត្រូវរួម និងគំរូសុវត្ថិភាពព័ត៌មានរួមគ្នា។ Cloud ទទួលខុសត្រូវចំពោះរឿងមួយចំនួន ហើយចំពោះអ្នកផ្សេងទៀត អតិថិជនទទួលខុសត្រូវ ដោយដាក់ទិន្នន័យ កម្មវិធីរបស់គាត់ ម៉ាស៊ីននិម្មិត និងធនធានផ្សេងទៀតនៅក្នុងពពក។ វានឹងមិនមានការប្រុងប្រយ័ត្នក្នុងការរំពឹងថាតាមរយៈការចូលទៅកាន់ពពក យើងនឹងផ្លាស់ប្តូរការទទួលខុសត្រូវទាំងអស់ទៅកាន់អ្នកផ្តល់សេវា។ ប៉ុន្តែ​វា​ក៏​ជា​រឿង​មិន​ល្អ​ដែរ​ក្នុង​ការ​បង្កើត​សុវត្ថិភាព​ទាំង​អស់​ដោយ​ខ្លួន​ឯង​នៅ​ពេល​ផ្លាស់ទី​ទៅ​ពពក។ តុល្យភាពត្រូវបានទាមទារ ដែលនឹងអាស្រ័យលើកត្តាជាច្រើន៖ - យុទ្ធសាស្ត្រគ្រប់គ្រងហានិភ័យ គំរូគំរាមកំហែង យន្តការសុវត្ថិភាពដែលមានសម្រាប់អ្នកផ្តល់សេវាពពក ច្បាប់។ល។

ឧទាហរណ៍ ការចាត់ថ្នាក់នៃទិន្នន័យដែលបានបង្ហោះក្នុងពពកគឺតែងតែជាទំនួលខុសត្រូវរបស់អតិថិជន។ អ្នកផ្តល់សេវាពពក ឬអ្នកផ្តល់សេវាខាងក្រៅអាចជួយគាត់តែជាមួយឧបករណ៍ដែលនឹងជួយសម្គាល់ទិន្នន័យក្នុងពពក កំណត់អត្តសញ្ញាណការបំពាន លុបទិន្នន័យដែលបំពានច្បាប់ ឬបិទបាំងវាដោយប្រើវិធីមួយឬវិធីផ្សេងទៀត។ ម្យ៉ាងវិញទៀត សុវត្ថិភាពរូបវន្តគឺតែងតែទទួលខុសត្រូវរបស់អ្នកផ្តល់សេវាពពក ដែលវាមិនអាចចែករំលែកជាមួយអតិថិជនបានទេ។ ប៉ុន្តែអ្វីគ្រប់យ៉ាងដែលនៅចន្លោះទិន្នន័យ និងហេដ្ឋារចនាសម្ព័ន្ធរូបវន្ត គឺជាប្រធានបទនៃការពិភាក្សានៅក្នុងអត្ថបទនេះ។ ឧទាហរណ៍ ភាពអាចរកបាននៃពពកគឺជាការទទួលខុសត្រូវរបស់អ្នកផ្តល់សេវា ហើយការបង្កើតច្បាប់ជញ្ជាំងភ្លើង ឬការបើកការអ៊ិនគ្រីបគឺជាការទទួលខុសត្រូវរបស់អតិថិជន។ នៅក្នុងអត្ថបទនេះ យើងនឹងព្យាយាមពិនិត្យមើលថាតើយន្តការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានអ្វីខ្លះដែលត្រូវបានផ្តល់ដោយអ្នកផ្តល់សេវាពពកដ៏ពេញនិយមជាច្រើននៅក្នុងប្រទេសរុស្ស៊ីនាពេលបច្ចុប្បន្ននេះ តើលក្ខណៈពិសេសអ្វីខ្លះនៃការប្រើប្រាស់របស់ពួកគេ ហើយនៅពេលណាដែលវាមានតម្លៃក្នុងការរកមើលដំណោះស្រាយលើផ្ទៃខាងក្រៅ (ឧទាហរណ៍ Cisco E- mail Security) ដែលពង្រីកសមត្ថភាពរបស់ cloud របស់អ្នកទាក់ទងនឹងសុវត្ថិភាពតាមអ៊ីនធឺណិត។ ក្នុងករណីខ្លះ ជាពិសេសប្រសិនបើអ្នកកំពុងអនុវត្តតាមយុទ្ធសាស្ត្រពហុពពក អ្នកនឹងមិនមានជម្រើសអ្វីក្រៅពីប្រើដំណោះស្រាយត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានខាងក្រៅនៅក្នុងបរិស្ថានពពកជាច្រើនក្នុងពេលតែមួយ (ឧទាហរណ៍ Cisco CloudLock ឬ Cisco Stealthwatch Cloud)។ ជាការប្រសើរណាស់, ក្នុងករណីខ្លះអ្នកនឹងដឹងថាអ្នកផ្តល់សេវាពពកដែលអ្នកបានជ្រើសរើស (ឬដាក់លើអ្នក) មិនផ្តល់សមត្ថភាពត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានទាល់តែសោះ។ នេះ​ជា​រឿង​មិន​សប្បាយ​ចិត្ត ប៉ុន្តែ​ក៏​មិន​តិច​ដែរ ព្រោះ​វា​អនុញ្ញាត​ឱ្យ​អ្នក​វាយ​តម្លៃ​បាន​គ្រប់គ្រាន់​ពី​កម្រិត​ហានិភ័យ​ដែល​ទាក់ទង​នឹង​ការ​ធ្វើ​ការ​ជាមួយ​ពពក​នេះ។

វដ្តជីវិតតាមដានសុវត្ថិភាពតាមពពក

ដើម្បីតាមដានសុវត្ថិភាពនៃពពកដែលអ្នកប្រើ អ្នកមានជម្រើសបីប៉ុណ្ណោះ៖

• ពឹងផ្អែកលើឧបករណ៍ដែលផ្តល់ដោយអ្នកផ្តល់សេវាពពករបស់អ្នក
• ប្រើដំណោះស្រាយពីភាគីទីបីដែលនឹងត្រួតពិនិត្យវេទិកា IaaS, PaaS ឬ SaaS ដែលអ្នកប្រើ
• បង្កើតហេដ្ឋារចនាសម្ព័ន្ធត្រួតពិនិត្យពពកផ្ទាល់ខ្លួនរបស់អ្នក (សម្រាប់តែវេទិកា IaaS/PaaS)។

តោះមើលថាតើជម្រើសទាំងនេះនីមួយៗមានលក្ខណៈពិសេសអ្វីខ្លះ។ ប៉ុន្តែជាដំបូង យើងត្រូវយល់អំពីក្របខ័ណ្ឌទូទៅដែលនឹងត្រូវបានប្រើនៅពេលត្រួតពិនិត្យវេទិកាពពក។ ខ្ញុំនឹងគូសបញ្ជាក់ពីធាតុផ្សំសំខាន់ៗចំនួន 6 នៃដំណើរការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាននៅក្នុងពពក៖

• ការរៀបចំហេដ្ឋារចនាសម្ព័ន្ធ។ ការកំណត់កម្មវិធីចាំបាច់ និងហេដ្ឋារចនាសម្ព័ន្ធសម្រាប់ការប្រមូលព្រឹត្តិការណ៍សំខាន់ៗសម្រាប់សុវត្ថិភាពព័ត៌មានចូលទៅក្នុងកន្លែងផ្ទុក។
• ការប្រមូល។ នៅដំណាក់កាលនេះ ព្រឹត្តិការណ៍សុវត្ថិភាពត្រូវបានប្រមូលផ្តុំពីប្រភពផ្សេងៗសម្រាប់ការបញ្ជូនបន្តបន្ទាប់ទៀតសម្រាប់ដំណើរការ ការផ្ទុក និងការវិភាគ។
• ការព្យាបាល។ នៅដំណាក់កាលនេះ ទិន្នន័យត្រូវបានបំប្លែង និងពង្រឹងដើម្បីជួយសម្រួលដល់ការវិភាគជាបន្តបន្ទាប់។
• ការផ្ទុក។ សមាសភាគនេះទទួលខុសត្រូវចំពោះការរក្សាទុករយៈពេលខ្លី និងរយៈពេលវែងនៃទិន្នន័យដែលបានដំណើរការ និងទិន្នន័យឆៅដែលបានប្រមូល។
• ការវិភាគ។ នៅដំណាក់កាលនេះ អ្នកមានសមត្ថភាពក្នុងការរកឃើញឧប្បត្តិហេតុ និងឆ្លើយតបដោយស្វ័យប្រវត្តិ ឬដោយដៃ។
• ការរាយការណ៍។ ដំណាក់កាលនេះជួយបង្កើតសូចនាករសំខាន់ៗសម្រាប់អ្នកពាក់ព័ន្ធ (ការគ្រប់គ្រង អ្នកសវនករ អ្នកផ្តល់សេវាពពក អតិថិជន។ល។) ដែលជួយយើងធ្វើការសម្រេចចិត្តជាក់លាក់ ឧទាហរណ៍ ការផ្លាស់ប្តូរអ្នកផ្តល់សេវា ឬពង្រឹងសុវត្ថិភាពព័ត៌មាន។

ការយល់ដឹងអំពីសមាសធាតុទាំងនេះនឹងអនុញ្ញាតឱ្យអ្នកសម្រេចចិត្តយ៉ាងឆាប់រហ័សនាពេលអនាគតនូវអ្វីដែលអ្នកអាចយកពីអ្នកផ្តល់សេវារបស់អ្នក និងអ្វីដែលអ្នកនឹងត្រូវធ្វើដោយខ្លួនឯង ឬដោយមានការចូលរួមពីអ្នកប្រឹក្សាខាងក្រៅ។

សេវាកម្មពពកដែលភ្ជាប់មកជាមួយ

ខ្ញុំបានសរសេរខាងលើរួចហើយថា សេវាពពកជាច្រើនសព្វថ្ងៃនេះមិនផ្តល់សមត្ថភាពត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានណាមួយឡើយ។ ជាទូទៅ ពួកគេមិនយកចិត្តទុកដាក់ច្រើនចំពោះប្រធានបទនៃសុវត្ថិភាពព័ត៌មាននោះទេ។ ជាឧទាហរណ៍ សេវាកម្មដ៏ពេញនិយមមួយរបស់រុស្ស៊ីសម្រាប់ការផ្ញើរបាយការណ៍ទៅកាន់ភ្នាក់ងាររដ្ឋាភិបាលតាមរយៈអ៊ីនធឺណិត (ខ្ញុំនឹងមិនប្រាប់ឈ្មោះរបស់វាជាពិសេសទេ)។ ផ្នែកទាំងមូលអំពីសុវត្ថិភាពនៃសេវាកម្មនេះទាក់ទងនឹងការប្រើប្រាស់ CIPF ដែលមានការបញ្ជាក់។ ផ្នែកសុវត្ថិភាពព័ត៌មាននៃសេវាពពកក្នុងស្រុកមួយផ្សេងទៀតសម្រាប់ការគ្រប់គ្រងឯកសារអេឡិចត្រូនិកគឺមិនខុសគ្នាទេ។ វានិយាយអំពីវិញ្ញាបនបត្រសោសាធារណៈ ការគ្រីបដែលមានការបញ្ជាក់ ការលុបបំបាត់ភាពងាយរងគ្រោះនៃគេហទំព័រ ការការពារប្រឆាំងនឹងការវាយប្រហារដោយ DDoS ការប្រើជញ្ជាំងភ្លើង ការបម្រុងទុក និងសូម្បីតែការធ្វើសវនកម្មសុវត្ថិភាពព័ត៌មានជាប្រចាំ។ ប៉ុន្តែមិនមានពាក្យណាមួយអំពីការត្រួតពិនិត្យ ឬអំពីលទ្ធភាពនៃការចូលទៅកាន់ព្រឹត្តិការណ៍សុវត្ថិភាពព័ត៌មានដែលអាចចាប់អារម្មណ៍សម្រាប់អតិថិជនរបស់អ្នកផ្តល់សេវានេះទេ។

ជាទូទៅ តាមរយៈវិធីដែលអ្នកផ្តល់សេវាពពកពណ៌នាអំពីបញ្ហាសុវត្ថិភាពព័ត៌មាននៅលើគេហទំព័ររបស់ខ្លួន និងក្នុងឯកសាររបស់វា អ្នកអាចយល់ថាតើវាត្រូវការបញ្ហានេះយ៉ាងធ្ងន់ធ្ងរប៉ុណ្ណា។ ឧទាហរណ៍ ប្រសិនបើអ្នកអានសៀវភៅណែនាំសម្រាប់ផលិតផល "ការិយាល័យរបស់ខ្ញុំ" មិនមានពាក្យអំពីសុវត្ថិភាពទាល់តែសោះ ប៉ុន្តែនៅក្នុងឯកសារសម្រាប់ផលិតផលដាច់ដោយឡែក "ការិយាល័យរបស់ខ្ញុំ។ KS3” ដែលត្រូវបានរចនាឡើងដើម្បីការពារប្រឆាំងនឹងការចូលប្រើដោយគ្មានការអនុញ្ញាត មានបញ្ជីធម្មតានៃចំណុចនៃលំដាប់ទី 17 នៃ FSTEC ដែល “My Office.KS3” អនុវត្ត ប៉ុន្តែវាមិនត្រូវបានពិពណ៌នាអំពីរបៀបដែលវាអនុវត្តវា ហើយសំខាន់បំផុតគឺរបៀប បញ្ចូលយន្តការទាំងនេះជាមួយសន្តិសុខព័ត៌មានសាជីវកម្ម។ ប្រហែលជាឯកសារបែបនេះមាន ប៉ុន្តែខ្ញុំមិនបានរកឃើញវានៅក្នុងដែនសាធារណៈនៅលើគេហទំព័រ "ការិយាល័យរបស់ខ្ញុំ" ទេ។ ថ្វីត្បិតតែខ្ញុំមិនមានលទ្ធភាពទទួលបានព័ត៌មានសម្ងាត់នេះ?...

សម្រាប់ Bitrix ស្ថានភាពគឺប្រសើរជាង។ ឯកសារពិពណ៌នាអំពីទម្រង់នៃកំណត់ហេតុព្រឹត្តិការណ៍ និងគួរឱ្យចាប់អារម្មណ៍ កំណត់ហេតុការឈ្លានពាន ដែលមានព្រឹត្តិការណ៍ទាក់ទងនឹងការគំរាមកំហែងដែលអាចកើតមានចំពោះវេទិកាពពក។ ពីទីនោះអ្នកអាចទាញ IP អ្នកប្រើប្រាស់ ឬឈ្មោះភ្ញៀវ ប្រភពព្រឹត្តិការណ៍ ពេលវេលា ភ្នាក់ងារអ្នកប្រើប្រាស់ ប្រភេទព្រឹត្តិការណ៍។ល។ ពិតមែន អ្នកអាចធ្វើការជាមួយព្រឹត្តិការណ៍ទាំងនេះពីផ្ទាំងបញ្ជារបស់ពពកខ្លួនឯង ឬផ្ទុកទិន្នន័យក្នុងទម្រង់ MS Excel ។ ឥឡូវនេះវាពិបាកក្នុងការធ្វើស្វ័យប្រវត្តិកម្មជាមួយកំណត់ហេតុ Bitrix ហើយអ្នកនឹងត្រូវធ្វើការងារមួយចំនួនដោយដៃ (ការបង្ហោះរបាយការណ៍ និងផ្ទុកវាទៅក្នុង SIEM របស់អ្នក)។ ប៉ុន្តែប្រសិនបើយើងចាំថា រហូតមកដល់ពេលថ្មីៗនេះ ឱកាសបែបនេះមិនមានទេ នោះគឺជាការរីកចំរើនដ៏អស្ចារ្យ។ ក្នុងពេលជាមួយគ្នានេះ ខ្ញុំចង់កត់សម្គាល់ថាអ្នកផ្តល់សេវាពពកបរទេសជាច្រើនផ្តល់នូវមុខងារស្រដៀងគ្នា "សម្រាប់អ្នកចាប់ផ្តើមដំបូង" - មើលកំណត់ហេតុដោយភ្នែករបស់អ្នកតាមរយៈផ្ទាំងបញ្ជា ឬផ្ទុកទិន្នន័យទៅខ្លួនអ្នក (ទោះជាយ៉ាងណាក៏ដោយ ភាគច្រើនផ្ទុកទិន្នន័យនៅក្នុង . ទម្រង់ csv មិនមែន Excel) ។

ដោយមិនគិតពីជម្រើសគ្មានកំណត់ហេតុទេ អ្នកផ្តល់សេវាពពកជាធម្មតាផ្តល់ឱ្យអ្នកនូវជម្រើសបីសម្រាប់ការត្រួតពិនិត្យព្រឹត្តិការណ៍សុវត្ថិភាព - ផ្ទាំងគ្រប់គ្រង ការផ្ទុកទិន្នន័យ និងការចូលប្រើ API ។ ទីមួយហាក់ដូចជាដោះស្រាយបញ្ហាជាច្រើនសម្រាប់អ្នក ប៉ុន្តែនេះមិនមែនជាការពិតទាំងស្រុងនោះទេ - ប្រសិនបើអ្នកមានទស្សនាវដ្ដីជាច្រើន អ្នកត្រូវប្តូររវាងអេក្រង់ដែលបង្ហាញពួកវា ដោយបាត់បង់រូបភាពទាំងមូល។ លើសពីនេះ អ្នកផ្តល់សេវាពពកទំនងជាមិនផ្តល់ឱ្យអ្នកនូវសមត្ថភាពក្នុងការទាក់ទងព្រឹត្តិការណ៍សុវត្ថិភាព ហើយជាទូទៅវិភាគវាតាមទស្សនៈសុវត្ថិភាព (ជាធម្មតាអ្នកកំពុងដោះស្រាយជាមួយទិន្នន័យឆៅ ដែលអ្នកត្រូវយល់ដោយខ្លួនឯង)។ មានករណីលើកលែង ហើយយើងនឹងនិយាយអំពីពួកគេបន្ថែមទៀត។ ជាចុងក្រោយ វាមានតម្លៃសួរថាតើព្រឹត្តិការណ៍អ្វីខ្លះដែលត្រូវបានកត់ត្រាដោយអ្នកផ្តល់សេវាពពករបស់អ្នក ក្នុងទម្រង់បែបណា ហើយតើពួកវាត្រូវគ្នានឹងដំណើរការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានរបស់អ្នកយ៉ាងដូចម្តេច? ឧទាហរណ៍ ការកំណត់អត្តសញ្ញាណ និងការផ្ទៀងផ្ទាត់អ្នកប្រើប្រាស់ និងភ្ញៀវ។ Bitrix ដូចគ្នាអនុញ្ញាតឱ្យអ្នក ដោយផ្អែកលើព្រឹត្តិការណ៍ទាំងនេះ ដើម្បីកត់ត្រាកាលបរិច្ឆេទ និងពេលវេលានៃព្រឹត្តិការណ៍ ឈ្មោះអ្នកប្រើប្រាស់ ឬភ្ញៀវ (ប្រសិនបើអ្នកមានម៉ូឌុល "ការវិភាគគេហទំព័រ") វត្ថុដែលបានចូលប្រើ និងធាតុផ្សេងទៀតធម្មតាសម្រាប់គេហទំព័រ។ . ប៉ុន្តែសេវាសន្តិសុខព័ត៌មានសាជីវកម្មអាចត្រូវការព័ត៌មានអំពីថាតើអ្នកប្រើប្រាស់បានចូលប្រើពពកពីឧបករណ៍ដែលអាចទុកចិត្តបានដែរឬទេ (ឧទាហរណ៍ នៅក្នុងបណ្តាញសាជីវកម្ម កិច្ចការនេះត្រូវបានអនុវត្តដោយ Cisco ISE)។ ចុះកិច្ចការសាមញ្ញដូចជាមុខងារ Geo-IP ដែលនឹងជួយកំណត់ថាតើគណនីអ្នកប្រើប្រាស់សេវាពពកត្រូវបានលួចដែរឬទេ? ហើយទោះបីជាអ្នកផ្តល់សេវាពពកផ្តល់ឱ្យអ្នកក៏ដោយ នេះមិនគ្រប់គ្រាន់ទេ។ Cisco CloudLock ដូចគ្នាមិនគ្រាន់តែវិភាគទីតាំងភូមិសាស្ត្រប៉ុណ្ណោះទេ ប៉ុន្តែប្រើការរៀនម៉ាស៊ីនសម្រាប់រឿងនេះ និងវិភាគទិន្នន័យប្រវត្តិសាស្ត្រសម្រាប់អ្នកប្រើប្រាស់ម្នាក់ៗ និងតាមដានភាពមិនប្រក្រតីផ្សេងៗក្នុងការព្យាយាមកំណត់អត្តសញ្ញាណ និងការផ្ទៀងផ្ទាត់។ មានតែ MS Azure ប៉ុណ្ណោះដែលមានមុខងារស្រដៀងគ្នា (ប្រសិនបើអ្នកមានការជាវសមរម្យ)។

មានការលំបាកមួយទៀត - ដោយសារសម្រាប់អ្នកផ្តល់សេវាពពកជាច្រើន ការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានគឺជាប្រធានបទថ្មីដែលពួកគេទើបតែចាប់ផ្តើមដោះស្រាយ ពួកគេកំពុងផ្លាស់ប្តូរអ្វីមួយនៅក្នុងដំណោះស្រាយរបស់ពួកគេឥតឈប់ឈរ។ ថ្ងៃនេះពួកគេមានកំណែ API មួយ ថ្ងៃស្អែកមួយទៀត ថ្ងៃស្អែក ទីបី។ អ្នកក៏ត្រូវត្រៀមខ្លួនសម្រាប់រឿងនេះដែរ។ ដូចគ្នាដែរជាមួយនឹងមុខងារ ដែលអាចផ្លាស់ប្តូរ ដែលត្រូវតែយកមកពិចារណានៅក្នុងប្រព័ន្ធត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានរបស់អ្នក។ ជាឧទាហរណ៍ Amazon ដំបូងមានសេវាកម្មត្រួតពិនិត្យព្រឹត្តិការណ៍លើពពកដាច់ដោយឡែកពីគ្នា - AWS CloudTrail និង AWS CloudWatch ។ បន្ទាប់មក សេវាកម្មដាច់ដោយឡែកសម្រាប់ត្រួតពិនិត្យព្រឹត្តិការណ៍សុវត្ថិភាពព័ត៌មានបានបង្ហាញខ្លួន - AWS GuardDuty ។ បន្ទាប់ពីពេលខ្លះ Amazon បានចាប់ផ្តើមប្រព័ន្ធគ្រប់គ្រងថ្មី Amazon Security Hub ដែលរួមមានការវិភាគទិន្នន័យដែលទទួលបានពី GuardDuty, Amazon Inspector, Amazon Macie និងមួយចំនួនផ្សេងទៀត។ ឧទាហរណ៍មួយទៀតគឺឧបករណ៍រួមបញ្ចូលកំណត់ហេតុ Azure ជាមួយ SIEM - AzLog ។ វាត្រូវបានប្រើប្រាស់យ៉ាងសកម្មដោយអ្នកលក់ SIEM ជាច្រើន រហូតដល់ឆ្នាំ 2018 ក្រុមហ៊ុន Microsoft បានប្រកាសពីការបញ្ឈប់ការអភិវឌ្ឍន៍ និងការគាំទ្ររបស់ខ្លួន ដែលប្រឈមមុខនឹងអតិថិជនជាច្រើនដែលបានប្រើឧបករណ៍នេះដោយមានបញ្ហា (យើងនឹងនិយាយអំពីរបៀបដែលវាត្រូវបានដោះស្រាយនៅពេលក្រោយ)។

ដូច្នេះ សូមតាមដានដោយប្រុងប្រយ័ត្ននូវមុខងារត្រួតពិនិត្យទាំងអស់ដែលអ្នកផ្តល់សេវាពពករបស់អ្នកផ្តល់ជូនអ្នក។ ឬពឹងផ្អែកលើអ្នកផ្តល់ដំណោះស្រាយខាងក្រៅដែលនឹងដើរតួជាអន្តរការីរវាង SOC របស់អ្នក និងពពកដែលអ្នកចង់ត្រួតពិនិត្យ។ បាទ វានឹងមានតម្លៃថ្លៃជាង (ទោះបីជាមិនមែនជានិច្ចក៏ដោយ) ប៉ុន្តែអ្នកនឹងផ្លាស់ប្តូរទំនួលខុសត្រូវទាំងអស់ទៅលើស្មារបស់នរណាម្នាក់។ ឬមិនមែនទាំងអស់?.. ចូរយើងចងចាំនូវគោលគំនិតនៃសុវត្ថិភាពរួមគ្នា ហើយយល់ថាយើងមិនអាចផ្លាស់ប្តូរអ្វីបានទេ - យើងនឹងត្រូវយល់ដោយឯករាជ្យថាតើអ្នកផ្តល់សេវាពពកផ្សេងៗគ្នាផ្តល់ការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាននៃទិន្នន័យ កម្មវិធី ម៉ាស៊ីននិម្មិត និងធនធានផ្សេងទៀតរបស់អ្នកយ៉ាងដូចម្តេច។ រៀបចំនៅលើពពក។ ហើយយើងនឹងចាប់ផ្តើមជាមួយនឹងអ្វីដែល Amazon ផ្តល់ជូននៅក្នុងផ្នែកនេះ។

ឧទាហរណ៍៖ ការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាននៅក្នុង IaaS ផ្អែកលើ AWS

បាទ/ចាស៎ ខ្ញុំយល់ថា Amazon មិនមែនជាគំរូដ៏ល្អបំផុតនោះទេ ដោយសារតែវាជាសេវាកម្មរបស់អាមេរិក ហើយវាអាចត្រូវបានរារាំងជាផ្នែកមួយនៃការប្រយុទ្ធប្រឆាំងនឹងភាពជ្រុលនិយម និងការផ្សព្វផ្សាយព័ត៌មានដែលត្រូវបានហាមឃាត់នៅក្នុងប្រទេសរុស្ស៊ី។ ប៉ុន្តែនៅក្នុងការបោះពុម្ពផ្សាយនេះ ខ្ញុំគ្រាន់តែចង់បង្ហាញពីរបៀបដែលវេទិកាពពកផ្សេងគ្នាខុសគ្នានៅក្នុងសមត្ថភាពត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានរបស់ពួកគេ និងអ្វីដែលអ្នកគួរយកចិត្តទុកដាក់នៅពេលផ្ទេរដំណើរការសំខាន់ៗរបស់អ្នកទៅពពកតាមទស្សនៈសុវត្ថិភាព។ ជាការប្រសើរណាស់, ប្រសិនបើអ្នកអភិវឌ្ឍន៍រុស្ស៊ីមួយចំនួននៃដំណោះស្រាយពពករៀនអ្វីដែលមានប្រយោជន៍សម្រាប់ខ្លួនគេ, នោះនឹងអស្ចារ្យណាស់។

រឿងដំបូងដែលត្រូវនិយាយគឺថា Amazon មិនមែនជាបន្ទាយដែលមិនអាចជ្រាបចូលបានទេ។ ឧប្បត្តិហេតុផ្សេងៗកើតឡើងជាទៀងទាត់ចំពោះអតិថិជនរបស់គាត់។ ឧទាហរណ៍ ឈ្មោះ អាស័យដ្ឋាន ថ្ងៃខែឆ្នាំកំណើត និងលេខទូរស័ព្ទរបស់អ្នកបោះឆ្នោត 198 លាននាក់ត្រូវបានលួចពី Deep Root Analytics ។ ក្រុមហ៊ុនអ៊ីស្រាអែល Nice Systems បានលួចកំណត់ត្រា 14 លាននៃអតិថិជន Verizon ។ ទោះជាយ៉ាងណាក៏ដោយ សមត្ថភាពភ្ជាប់មកជាមួយរបស់ AWS អនុញ្ញាតឱ្យអ្នករកឃើញនូវឧប្បត្តិហេតុដ៏ធំទូលាយមួយ។ ឧទាហរណ៍:

• ផលប៉ះពាល់លើហេដ្ឋារចនាសម្ព័ន្ធ (DDoS)
• ការសម្របសម្រួលថ្នាំង (ការចាក់ពាក្យបញ្ជា)
• ការសម្របសម្រួលគណនី និងការចូលប្រើប្រាស់ដោយគ្មានការអនុញ្ញាត
• ការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ និងភាពងាយរងគ្រោះ
• ចំណុចប្រទាក់ និង API ដែលមិនមានសុវត្ថិភាព។

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

ដើម្បីកំណត់អត្តសញ្ញាណឧប្បត្តិហេតុ អ្នកអាចប្រើសេវាកម្មត្រួតពិនិត្យផ្សេងៗគ្នាជាច្រើនដែលបង្កើតឡើងដោយ Amazon (ទោះបីជាវាច្រើនតែត្រូវបានបំពេញបន្ថែមដោយឧបករណ៍ខាងក្រៅដូចជា osquery ក៏ដោយ)។ ដូច្នេះនៅក្នុង AWS សកម្មភាពរបស់អ្នកប្រើប្រាស់ទាំងអស់ត្រូវបានត្រួតពិនិត្យ ដោយមិនគិតពីរបៀបដែលពួកគេត្រូវបានអនុវត្ត - តាមរយៈកុងសូលគ្រប់គ្រង បន្ទាត់ពាក្យបញ្ជា SDK ឬសេវាកម្ម AWS ផ្សេងទៀត។ កំណត់ត្រាទាំងអស់នៃសកម្មភាពរបស់គណនី AWS នីមួយៗ (រួមទាំងឈ្មោះអ្នកប្រើប្រាស់ សកម្មភាព សេវាកម្ម ប៉ារ៉ាម៉ែត្រសកម្មភាព និងលទ្ធផល) និងការប្រើប្រាស់ API មានតាមរយៈ AWS CloudTrail។ អ្នកអាចមើលព្រឹត្តិការណ៍ទាំងនេះ (ដូចជាការចូលកុងសូល AWS IAM) ពីកុងសូល CloudTrail វិភាគពួកវាដោយប្រើ Amazon Athena ឬ "ប្រភពខាងក្រៅ" ពួកវាទៅកាន់ដំណោះស្រាយខាងក្រៅដូចជា Splunk, AlienVault ជាដើម។ កំណត់ហេតុ AWS CloudTrail ត្រូវបានដាក់ក្នុងធុង AWS S3 របស់អ្នក។

សេវាកម្ម AWS ពីរផ្សេងទៀតផ្តល់នូវសមត្ថភាពត្រួតពិនិត្យសំខាន់ៗមួយចំនួនទៀត។ ទីមួយ Amazon CloudWatch គឺជាសេវាកម្មត្រួតពិនិត្យសម្រាប់ធនធាន និងកម្មវិធី AWS ដែលអនុញ្ញាតឱ្យអ្នកកំណត់អត្តសញ្ញាណភាពមិនប្រក្រតីផ្សេងៗនៅក្នុងពពករបស់អ្នក។ សេវាកម្ម AWS ដែលមានស្រាប់ទាំងអស់ ដូចជា Amazon Elastic Compute Cloud (servers) Amazon Relational Database Service (databases) Amazon Elastic MapReduce (ការវិភាគទិន្នន័យ) និងសេវាកម្ម Amazon 30 ផ្សេងទៀត ប្រើ Amazon CloudWatch ដើម្បីរក្សាទុកកំណត់ហេតុរបស់ពួកគេ។ អ្នកអភិវឌ្ឍន៍អាចប្រើ API បើកចំហពី Amazon CloudWatch ដើម្បីបន្ថែមមុខងារត្រួតពិនិត្យកំណត់ហេតុទៅកាន់កម្មវិធី និងសេវាកម្មផ្ទាល់ខ្លួន ដែលអនុញ្ញាតឱ្យពួកគេពង្រីកវិសាលភាពនៃការវិភាគព្រឹត្តិការណ៍នៅក្នុងបរិបទសុវត្ថិភាព។

ទីពីរ សេវាកម្មកំណត់ហេតុលំហូរ VPC អនុញ្ញាតឱ្យអ្នកវិភាគចរាចរបណ្តាញដែលបានផ្ញើ ឬទទួលដោយម៉ាស៊ីនមេ AWS របស់អ្នក (ខាងក្រៅ ឬខាងក្នុង) ក៏ដូចជារវាងសេវាមីក្រូ។ នៅពេលដែលធនធាន AWS VPC របស់អ្នកធ្វើអន្តរកម្មជាមួយបណ្តាញ កំណត់ហេតុលំហូរ VPC កត់ត្រាព័ត៌មានលម្អិតអំពីចរាចរណ៍បណ្តាញ រួមទាំងចំណុចប្រទាក់បណ្តាញប្រភព និងទិសដៅ ក៏ដូចជាអាសយដ្ឋាន IP ច្រក ពិធីការ ចំនួនបៃ និងចំនួនកញ្ចប់ព័ត៌មានដែលអ្នក ឃើញ។ អ្នកដែលមានបទពិសោធន៍ជាមួយសុវត្ថិភាពបណ្តាញមូលដ្ឋាននឹងទទួលស្គាល់ថាវាស្រដៀងទៅនឹងខ្សែស្រឡាយ NetFlowដែលអាចត្រូវបានបង្កើតឡើងដោយកុងតាក់ រ៉ោតទ័រ និងជញ្ជាំងភ្លើងកម្រិតសហគ្រាស។ កំណត់ហេតុទាំងនេះមានសារៈសំខាន់សម្រាប់គោលបំណងត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាន ពីព្រោះមិនដូចព្រឹត្តិការណ៍អំពីសកម្មភាពរបស់អ្នកប្រើប្រាស់ និងកម្មវិធីទេ ពួកវាក៏អនុញ្ញាតឱ្យអ្នកមិនខកខានអន្តរកម្មបណ្តាញនៅក្នុងបរិស្ថានពពកឯកជននិម្មិត AWS ផងដែរ។

សរុបមក សេវាកម្ម AWS ទាំងបីនេះ—AWS CloudTrail, Amazon CloudWatch, និង VPC Flow Logs—រួមគ្នាផ្តល់នូវការយល់ដឹងដ៏មានអានុភាពចំពោះការប្រើប្រាស់គណនី អាកប្បកិរិយាអ្នកប្រើប្រាស់ ការគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធ សកម្មភាពកម្មវិធី និងសេវាកម្ម និងសកម្មភាពបណ្តាញរបស់អ្នក។ ឧទាហរណ៍ ពួកវាអាចត្រូវបានប្រើដើម្បីរកមើលភាពមិនប្រក្រតីដូចខាងក្រោម៖

• ការព្យាយាមស្កេនគេហទំព័រ ស្វែងរក backdoors ស្វែងរកភាពងាយរងគ្រោះតាមរយៈការផ្ទុះនៃ "404 errors" ។
• ការវាយប្រហារដោយការចាក់ (ឧទាហរណ៍ ការចាក់ SQL) តាមរយៈការផ្ទុះនៃ "500 errors"។
• ឧបករណ៍វាយប្រហារដែលគេស្គាល់គឺ sqlmap, nikto, w3af, nmap ជាដើម។ តាមរយៈការវិភាគនៃវាលភ្នាក់ងារអ្នកប្រើប្រាស់។

Amazon Web Services ក៏បានបង្កើតសេវាកម្មផ្សេងទៀតសម្រាប់គោលបំណងសន្តិសុខតាមអ៊ីនធឺណិត ដែលអនុញ្ញាតឱ្យអ្នកដោះស្រាយបញ្ហាជាច្រើនទៀត។ ឧទាហរណ៍ AWS មានសេវាកម្មភ្ជាប់មកជាមួយសម្រាប់គោលនយោបាយ និងការកំណត់រចនាសម្ព័ន្ធ - AWS Config ។ សេវាកម្មនេះផ្តល់នូវការធ្វើសវនកម្មជាបន្តបន្ទាប់នៃធនធាន AWS របស់អ្នក និងការកំណត់រចនាសម្ព័ន្ធរបស់វា។ សូមលើកឧទាហរណ៍សាមញ្ញមួយ៖ ចូរនិយាយថាអ្នកចង់ធ្វើឱ្យប្រាកដថាពាក្យសម្ងាត់របស់អ្នកប្រើត្រូវបានបិទនៅលើម៉ាស៊ីនមេរបស់អ្នកទាំងអស់ ហើយការចូលប្រើគឺអាចធ្វើទៅបានដោយផ្អែកលើវិញ្ញាបនបត្រប៉ុណ្ណោះ។ AWS Config ធ្វើឱ្យវាងាយស្រួលក្នុងការពិនិត្យមើលវាសម្រាប់ម៉ាស៊ីនមេរបស់អ្នកទាំងអស់។ មានគោលការណ៍ផ្សេងទៀតដែលអាចត្រូវបានអនុវត្តចំពោះម៉ាស៊ីនមេពពករបស់អ្នក៖ "គ្មានម៉ាស៊ីនមេអាចប្រើច្រក 22" "មានតែអ្នកគ្រប់គ្រងប៉ុណ្ណោះដែលអាចផ្លាស់ប្តូរច្បាប់ជញ្ជាំងភ្លើង" ឬ "មានតែអ្នកប្រើប្រាស់ Ivashko ប៉ុណ្ណោះដែលអាចបង្កើតគណនីអ្នកប្រើប្រាស់ថ្មី ហើយគាត់អាចធ្វើវាបានតែនៅថ្ងៃអង្គារប៉ុណ្ណោះ។ " នៅរដូវក្តៅឆ្នាំ 2016 សេវាកម្ម AWS Config ត្រូវបានពង្រីកដើម្បីធ្វើឱ្យការរកឃើញការរំលោភលើគោលការណ៍ដែលបានបង្កើតដោយស្វ័យប្រវត្តិ។ ច្បាប់កំណត់រចនាសម្ព័ន្ធ AWS គឺជាសំណើកំណត់រចនាសម្ព័ន្ធជាបន្តសម្រាប់សេវាកម្ម Amazon ដែលអ្នកប្រើ ដែលបង្កើតព្រឹត្តិការណ៍ ប្រសិនបើគោលការណ៍ដែលត្រូវគ្នាត្រូវបានបំពាន។ ឧទាហរណ៍ ជំនួសឱ្យការដំណើរការសំណួរកំណត់រចនាសម្ព័ន្ធ AWS ជាទៀងទាត់ ដើម្បីផ្ទៀងផ្ទាត់ថាថាសទាំងអស់នៅលើម៉ាស៊ីនមេនិម្មិតត្រូវបានអ៊ិនគ្រីប ច្បាប់កំណត់រចនាសម្ព័ន្ធ AWS អាចត្រូវបានប្រើដើម្បីពិនិត្យមើលថាសម៉ាស៊ីនមេជាបន្តបន្ទាប់ ដើម្បីធានាថាលក្ខខណ្ឌនេះត្រូវបានបំពេញ។ ហើយសំខាន់បំផុត នៅក្នុងបរិបទនៃការបោះពុម្ពផ្សាយនេះ ការបំពានណាមួយបង្កើតព្រឹត្តិការណ៍ដែលអាចវិភាគបានដោយសេវាកម្មសុវត្ថិភាពព័ត៌មានរបស់អ្នក។

AWS ក៏មានសមមូលទៅនឹងដំណោះស្រាយសន្តិសុខព័ត៌មានសាជីវកម្មប្រពៃណី ដែលបង្កើតព្រឹត្តិការណ៍សុវត្ថិភាពដែលអ្នកអាច និងគួរវិភាគផងដែរ៖

• ការរកឃើញការឈ្លានពាន - AWS GuardDuty
• ការគ្រប់គ្រងព័ត៌មានលេចធ្លាយ - AWS Macie
• EDR (ទោះបីជាវានិយាយអំពីចំណុចបញ្ចប់នៅក្នុងពពកចម្លែកបន្តិច) - AWS Cloudwatch + ប្រភពបើកចំហរ osquery ឬដំណោះស្រាយ GRR
• ការវិភាគលើបណ្តាញ - AWS Cloudwatch + AWS VPC Flow
• ការវិភាគ DNS - AWS Cloudwatch + AWS Route53
• AD - សេវាកម្មថតឯកសារ AWS
• ការគ្រប់គ្រងគណនី - AWS IAM
• SSO - AWS SSO
• ការវិភាគសុវត្ថិភាព - អធិការ AWS
• ការគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធ - AWS Config
• WAF - AWS WAF ។

ខ្ញុំនឹងមិនរៀបរាប់លម្អិតអំពីសេវាកម្ម Amazon ទាំងអស់ដែលអាចមានប្រយោជន៍ក្នុងបរិបទនៃសុវត្ថិភាពព័ត៌មាននោះទេ។ រឿងចំបងគឺត្រូវយល់ថាពួកវាទាំងអស់អាចបង្កើតព្រឹត្តិការណ៍ដែលយើងអាច និងគួរតែវិភាគក្នុងបរិបទនៃសុវត្ថិភាពព័ត៌មាន ដោយប្រើប្រាស់សម្រាប់គោលបំណងនេះទាំងសមត្ថភាពដែលភ្ជាប់មកជាមួយរបស់ Amazon ផ្ទាល់ និងដំណោះស្រាយខាងក្រៅ ឧទាហរណ៍ SIEM ដែលអាច យកព្រឹត្តិការណ៍សុវត្ថិភាពទៅកាន់មជ្ឈមណ្ឌលត្រួតពិនិត្យរបស់អ្នក ហើយវិភាគវានៅទីនោះ រួមជាមួយនឹងព្រឹត្តិការណ៍ពីសេវាកម្មពពកផ្សេងទៀត ឬពីហេដ្ឋារចនាសម្ព័ន្ធខាងក្នុង បរិវេណ ឬឧបករណ៍ចល័ត។

ក្នុងករណីណាក៏ដោយ វាទាំងអស់ចាប់ផ្តើមជាមួយនឹងប្រភពទិន្នន័យដែលផ្តល់ឱ្យអ្នកនូវព្រឹត្តិការណ៍សុវត្ថិភាពព័ត៌មាន។ ប្រភពទាំងនេះរួមបញ្ចូល ប៉ុន្តែមិនកំណត់ចំពោះ៖

• CloudTrail - ការប្រើប្រាស់ API និងសកម្មភាពអ្នកប្រើប្រាស់
• ទីប្រឹក្សាដែលជឿទុកចិត្ត - ការត្រួតពិនិត្យសុវត្ថិភាពប្រឆាំងនឹងការអនុវត្តល្អបំផុត
• កំណត់រចនាសម្ព័ន្ធ - សារពើភ័ណ្ឌ និងការកំណត់រចនាសម្ព័ន្ធគណនី និងការកំណត់សេវាកម្ម
• កំណត់ហេតុលំហូរ VPC - ការតភ្ជាប់ទៅចំណុចប្រទាក់និម្មិត
• IAM - សេវាកម្មកំណត់អត្តសញ្ញាណ និងការផ្ទៀងផ្ទាត់
• កំណត់ហេតុចូលប្រើ ELB - ផ្ទុកតុល្យភាព
• អធិការ - ភាពងាយរងគ្រោះនៃកម្មវិធី
• S3 - ការផ្ទុកឯកសារ
• CloudWatch - សកម្មភាពកម្មវិធី
• SNS គឺជាសេវាកម្មជូនដំណឹង។

ក្រុមហ៊ុន Amazon ខណៈពេលដែលផ្តល់ជូននូវជួរនៃប្រភពព្រឹត្តិការណ៍ និងឧបករណ៍សម្រាប់ជំនាន់របស់ពួកគេ គឺមានកម្រិតខ្លាំងណាស់នៅក្នុងសមត្ថភាពរបស់ខ្លួនក្នុងការវិភាគទិន្នន័យដែលប្រមូលបាននៅក្នុងបរិបទនៃសុវត្ថិភាពព័ត៌មាន។ អ្នកនឹងត្រូវសិក្សាដោយឯករាជ្យនូវកំណត់ហេតុដែលមាន ដោយស្វែងរកសូចនាករពាក់ព័ន្ធនៃការសម្របសម្រួលនៅក្នុងពួកគេ។ AWS Security Hub ដែល Amazon ទើបតែដាក់ឱ្យដំណើរការថ្មីៗនេះ មានគោលបំណងដោះស្រាយបញ្ហានេះដោយក្លាយជា Cloud SIEM សម្រាប់ AWS ។ ប៉ុន្តែរហូតមកដល់ពេលនេះវាគ្រាន់តែជាការចាប់ផ្តើមនៃដំណើររបស់វាប៉ុណ្ណោះ ហើយត្រូវបានកំណត់ទាំងចំនួនប្រភពដែលវាដំណើរការ និងដោយការរឹតបន្តឹងផ្សេងទៀតដែលបង្កើតឡើងដោយស្ថាបត្យកម្ម និងការជាវ Amazon ផ្ទាល់។

ឧទាហរណ៍៖ ការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាននៅក្នុង IaaS ផ្អែកលើ Azure

ខ្ញុំ​មិន​ចង់​ចូល​ទៅ​ក្នុង​ការ​ជជែក​ដេញ​ដោល​គ្នា​យ៉ាង​យូរ​អំពី​អ្នក​ផ្តល់​សេវា​ពពក​ទាំង​បី​មួយ​ណា (Amazon, Microsoft ឬ Google) ល្អ​ជាង (ជាពិសេស​ដោយសារ​ពួកគេ​ម្នាក់ៗ​នៅ​មាន​ចំណុច​ជាក់លាក់​រៀងៗ​ខ្លួន ហើយ​ស័ក្តិសម​សម្រាប់​ការ​ដោះស្រាយ​បញ្ហា​ផ្ទាល់​ខ្លួន)។ ចូរយើងផ្តោតលើសមត្ថភាពត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានដែលអ្នកលេងទាំងនេះផ្តល់។ វាត្រូវតែត្រូវបានទទួលស្គាល់ថា Amazon AWS គឺជាផ្នែកមួយដំបូងគេនៅក្នុងផ្នែកនេះ ហើយដូច្នេះបានឈានទៅមុខឆ្ងាយបំផុតទាក់ទងនឹងមុខងារសុវត្ថិភាពព័ត៌មានរបស់វា (ទោះបីជាមនុស្សជាច្រើនទទួលស្គាល់ថាពួកគេពិបាកប្រើក៏ដោយ)។ ប៉ុន្តែនេះមិនមានន័យថាយើងនឹងមិនអើពើនឹងឱកាសដែល Microsoft និង Google ផ្តល់ឱ្យយើងនោះទេ។

ផលិតផល Microsoft តែងតែត្រូវបានសម្គាល់ដោយ "ភាពបើកចំហ" របស់ពួកគេហើយនៅក្នុង Azure ស្ថានភាពគឺស្រដៀងគ្នា។ ឧទាហរណ៍ប្រសិនបើ AWS និង GCP តែងតែបន្តពីគំនិតនៃ "អ្វីដែលមិនត្រូវបានអនុញ្ញាតត្រូវបានហាមឃាត់" នោះ Azure មានវិធីសាស្រ្តផ្ទុយគ្នាពិតប្រាកដ។ ឧទាហរណ៍ នៅពេលបង្កើតបណ្តាញនិម្មិតនៅក្នុងពពក និងម៉ាស៊ីននិម្មិតនៅក្នុងនោះ ច្រក និងពិធីការទាំងអស់ត្រូវបានបើក និងអនុញ្ញាតតាមលំនាំដើម។ ដូច្នេះហើយ អ្នកនឹងត្រូវចំណាយការខិតខំប្រឹងប្រែងបន្ថែមទៀតលើការដំឡើងដំបូងនៃប្រព័ន្ធគ្រប់គ្រងការចូលប្រើក្នុងពពកពី Microsoft ។ ហើយ​នេះ​ក៏​ដាក់​លក្ខខណ្ឌ​តឹងរ៉ឹង​បន្ថែម​ទៀត​លើ​អ្នក​ក្នុង​លក្ខខណ្ឌ​នៃ​ការ​តាមដាន​សកម្មភាព​ក្នុង​ពពក Azure។

AWS មានលក្ខណៈពិសេសមួយដែលទាក់ទងនឹងការពិតដែលថានៅពេលដែលអ្នកត្រួតពិនិត្យធនធាននិម្មិតរបស់អ្នក ប្រសិនបើពួកវាមានទីតាំងនៅក្នុងតំបន់ផ្សេងៗគ្នា នោះអ្នកមានការលំបាកក្នុងការរួមបញ្ចូលព្រឹត្តិការណ៍ទាំងអស់ និងការវិភាគបង្រួបបង្រួមរបស់ពួកគេ ដើម្បីលុបបំបាត់ដែលអ្នកត្រូវងាកទៅរកល្បិចផ្សេងៗ ដូចជា បង្កើតកូដផ្ទាល់ខ្លួនរបស់អ្នកសម្រាប់ AWS Lambda ដែលនឹងដឹកជញ្ជូនព្រឹត្តិការណ៍រវាងតំបន់។ Azure មិនមានបញ្ហានេះទេ - យន្តការកំណត់ហេតុសកម្មភាពរបស់វាតាមដានសកម្មភាពទាំងអស់នៅទូទាំងស្ថាប័នទាំងមូលដោយមិនមានការរឹតបន្តឹង។ អនុវត្តដូចគ្នាចំពោះ AWS Security Hub ដែលត្រូវបានបង្កើតឡើងដោយ Amazon នាពេលថ្មីៗនេះ ដើម្បីបង្រួបបង្រួមមុខងារសុវត្ថិភាពជាច្រើននៅក្នុងមជ្ឈមណ្ឌលសន្តិសុខតែមួយ ប៉ុន្តែមានតែនៅក្នុងតំបន់របស់វាប៉ុណ្ណោះ ដែលទោះជាយ៉ាងណាក៏មិនពាក់ព័ន្ធសម្រាប់ប្រទេសរុស្ស៊ីដែរ។ Azure មានមជ្ឈមណ្ឌលសន្តិសុខផ្ទាល់ខ្លួនដែលមិនត្រូវបានចងដោយការរឹតបន្តឹងក្នុងតំបន់ដោយផ្តល់នូវការចូលប្រើមុខងារសុវត្ថិភាពទាំងអស់នៃវេទិកាពពក។ ជាងនេះទៅទៀត សម្រាប់ក្រុមក្នុងស្រុកផ្សេងៗគ្នា វាអាចផ្តល់នូវសំណុំសមត្ថភាពការពាររបស់ខ្លួន រួមទាំងព្រឹត្តិការណ៍សុវត្ថិភាពដែលគ្រប់គ្រងដោយពួកគេ។ AWS Security Hub នៅតែស្ថិតនៅលើផ្លូវឆ្ពោះទៅរកភាពស្រដៀងនឹង Azure Security Center។ ប៉ុន្តែវាមានតម្លៃបន្ថែមការហោះហើរនៅក្នុងមួន - អ្នកអាចច្របាច់ចេញពី Azure ជាច្រើននៃអ្វីដែលបានពិពណ៌នាពីមុននៅក្នុង AWS ប៉ុន្តែនេះត្រូវបានធ្វើយ៉ាងងាយស្រួលបំផុតសម្រាប់តែ Azure AD, Azure Monitor និង Azure Security Center ប៉ុណ្ណោះ។ យន្តការសុវត្ថិភាព Azure ផ្សេងទៀតទាំងអស់ រួមទាំងការវិភាគព្រឹត្តិការណ៍សុវត្ថិភាព មិនទាន់ត្រូវបានគ្រប់គ្រងតាមមធ្យោបាយងាយស្រួលបំផុតនៅឡើយទេ។ បញ្ហាត្រូវបានដោះស្រាយមួយផ្នែកដោយ API ដែលជ្រៀតចូលគ្រប់សេវាកម្ម Microsoft Azure ប៉ុន្តែវានឹងត្រូវការការខិតខំប្រឹងប្រែងបន្ថែមពីអ្នកក្នុងការរួមបញ្ចូលពពករបស់អ្នកជាមួយ SOC របស់អ្នក និងវត្តមានរបស់អ្នកឯកទេសដែលមានសមត្ថភាព (តាមពិតទៅដូចជា SIEM ផ្សេងទៀតដែលធ្វើការជាមួយ cloud APIs)។ SIEMs មួយចំនួនដែលនឹងត្រូវបានពិភាក្សានៅពេលក្រោយបានគាំទ្រ Azure រួចហើយ ហើយអាចធ្វើស្វ័យប្រវត្តិកម្មនៃការត្រួតពិនិត្យវា ប៉ុន្តែវាក៏មានការលំបាកផ្ទាល់ខ្លួនផងដែរ - មិនមែនពួកគេទាំងអស់អាចប្រមូលកំណត់ហេតុទាំងអស់ដែល Azure មាននោះទេ។

ការប្រមូល និងការត្រួតពិនិត្យព្រឹត្តិការណ៍នៅក្នុង Azure ត្រូវបានផ្តល់ជូនដោយប្រើសេវាកម្ម Azure Monitor ដែលជាឧបករណ៍ចម្បងសម្រាប់ការប្រមូល រក្សាទុក និងវិភាគទិន្នន័យនៅក្នុង Microsoft cloud និងធនធានរបស់វា - ឃ្លាំង Git, containers, virtual machines, applications ។ល។ ទិន្នន័យទាំងអស់ដែលប្រមូលបានដោយ Azure Monitor ត្រូវបានបែងចែកជាពីរប្រភេទ - រង្វាស់ដែលប្រមូលបានក្នុងពេលវេលាជាក់ស្តែង និងពិពណ៌នាអំពីសូចនាករប្រតិបត្តិការសំខាន់ៗនៃ Azure cloud និងកំណត់ហេតុដែលមានទិន្នន័យដែលបានរៀបចំចូលទៅក្នុងកំណត់ត្រាដែលបង្ហាញពីទិដ្ឋភាពជាក់លាក់នៃសកម្មភាពនៃធនធាន និងសេវាកម្មរបស់ Azure ។ លើសពីនេះទៀត ដោយប្រើ API អ្នកប្រមូលទិន្នន័យ សេវាកម្មត្រួតពិនិត្យ Azure អាចប្រមូលទិន្នន័យពីប្រភព REST ណាមួយដើម្បីបង្កើតសេណារីយ៉ូត្រួតពិនិត្យផ្ទាល់ខ្លួនរបស់វា។

នេះគឺជាប្រភពព្រឹត្តិការណ៍សុវត្ថិភាពមួយចំនួនដែល Azure ផ្តល់ជូនអ្នក ហើយអ្នកអាចចូលប្រើបានតាមរយៈ Azure Portal, CLI, PowerShell, ឬ REST API (និងមួយចំនួនប៉ុណ្ណោះតាមរយៈ Azure Monitor/Insight API)៖

• កំណត់ហេតុសកម្មភាព - កំណត់ហេតុនេះឆ្លើយសំណួរបុរាណនៃ "អ្នកណា" "អ្វី" និង "ពេលណា" ទាក់ទងនឹងប្រតិបត្តិការសរសេរណាមួយ (PUT, POST, DELETE) នៅលើធនធានពពក។ ព្រឹត្តិការណ៍ទាក់ទងនឹងការចូលអាន (GET) មិនត្រូវបានរាប់បញ្ចូលក្នុងកំណត់ហេតុនេះទេ ដូចជាមួយចំនួនផ្សេងទៀតដែរ។
• កំណត់ហេតុវិភាគ - មានទិន្នន័យអំពីប្រតិបត្តិការដែលមានធនធានជាក់លាក់មួយរួមបញ្ចូលនៅក្នុងការជាវរបស់អ្នក។
• ការរាយការណ៍ Azure AD - មានទាំងសកម្មភាពអ្នកប្រើប្រាស់ និងសកម្មភាពប្រព័ន្ធទាក់ទងនឹងការគ្រប់គ្រងក្រុម និងអ្នកប្រើប្រាស់។
• Windows Event Log និង Linux Syslog - មានព្រឹត្តិការណ៍ពីម៉ាស៊ីននិម្មិតដែលបង្ហោះក្នុងពពក។
• ម៉ែត្រ - មាន telemetry អំពីដំណើរការ និងស្ថានភាពសុខភាពនៃសេវាកម្មពពក និងធនធានរបស់អ្នក។ វាស់វែងរាល់នាទី និងរក្សាទុក។ ក្នុងរយៈពេល 30 ថ្ងៃ។
• កំណត់ហេតុលំហូរក្រុមសុវត្ថិភាពបណ្តាញ - មានទិន្នន័យអំពីព្រឹត្តិការណ៍សុវត្ថិភាពបណ្តាញដែលប្រមូលបានដោយប្រើសេវាកម្មឃ្លាំមើលបណ្តាញ និងការត្រួតពិនិត្យធនធាននៅកម្រិតបណ្តាញ។
• កំណត់ហេតុផ្ទុក - មានព្រឹត្តិការណ៍ទាក់ទងនឹងការចូលទៅកាន់កន្លែងផ្ទុក។

សម្រាប់ការត្រួតពិនិត្យ អ្នកអាចប្រើ SIEMs ខាងក្រៅ ឬ Azure Monitor ដែលភ្ជាប់មកជាមួយ និងផ្នែកបន្ថែមរបស់វា។ យើងនឹងនិយាយអំពីប្រព័ន្ធគ្រប់គ្រងព្រឹត្តិការណ៍សុវត្ថិភាពព័ត៌មាននៅពេលក្រោយ ប៉ុន្តែសម្រាប់ពេលនេះសូមមើលអ្វីដែល Azure ខ្លួនវាផ្តល់ឱ្យយើងសម្រាប់ការវិភាគទិន្នន័យនៅក្នុងបរិបទនៃសុវត្ថិភាព។ អេក្រង់សំខាន់សម្រាប់អ្វីគ្រប់យ៉ាងដែលទាក់ទងនឹងសុវត្ថិភាពនៅក្នុង Azure Monitor គឺ Log Analytics Security and Audit Dashboard (កំណែឥតគិតថ្លៃគាំទ្រចំនួនកំណត់នៃការផ្ទុកព្រឹត្តិការណ៍សម្រាប់តែមួយសប្តាហ៍ប៉ុណ្ណោះ)។ ផ្ទាំងគ្រប់គ្រងនេះត្រូវបានបែងចែកជា 5 ផ្នែកសំខាន់ៗដែលមើលឃើញស្ថិតិសង្ខេបនៃអ្វីដែលកំពុងកើតឡើងនៅក្នុងបរិយាកាសពពកដែលអ្នកកំពុងប្រើ៖

• ដែនសុវត្ថិភាព - សូចនាករបរិមាណសំខាន់ៗដែលទាក់ទងនឹងសុវត្ថិភាពព័ត៌មាន - ចំនួនឧប្បត្តិហេតុ ចំនួនថ្នាំងដែលត្រូវបានសម្របសម្រួល ថ្នាំងដែលមិនបានជួសជុល ព្រឹត្តិការណ៍សុវត្ថិភាពបណ្តាញ។ល។
• បញ្ហាគួរឱ្យកត់សម្គាល់ - បង្ហាញចំនួន និងសារៈសំខាន់នៃបញ្ហាសុវត្ថិភាពព័ត៌មានសកម្ម
• ការរកឃើញ - បង្ហាញលំនាំនៃការវាយប្រហារដែលប្រើប្រឆាំងនឹងអ្នក។
• Threat Intelligence - បង្ហាញព័ត៌មានភូមិសាស្ត្រនៅលើថ្នាំងខាងក្រៅដែលកំពុងវាយប្រហារអ្នក។
• សំណួរសុវត្ថិភាពទូទៅ - សំណួរធម្មតាដែលនឹងជួយអ្នកក្នុងការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានរបស់អ្នកកាន់តែប្រសើរ។

ផ្នែកបន្ថែមរបស់ Azure Monitor រួមមាន Azure Key Vault (ការការពារសោគ្រីបនៅក្នុងពពក) ការវាយតម្លៃមេរោគ (ការវិភាគការការពារប្រឆាំងនឹងកូដព្យាបាទនៅលើម៉ាស៊ីននិម្មិត) Azure Application Gateway Analytics (ការវិភាគក្នុងចំណោមរបស់ផ្សេងទៀត កំណត់ហេតុជញ្ជាំងភ្លើងពពក) ជាដើម។ . ឧបករណ៍ទាំងនេះដែលសំបូរទៅដោយច្បាប់ជាក់លាក់សម្រាប់ដំណើរការព្រឹត្តិការណ៍ អនុញ្ញាតឱ្យអ្នកមើលឃើញទិដ្ឋភាពផ្សេងៗនៃសកម្មភាពនៃសេវាកម្មពពក រួមទាំងសុវត្ថិភាព និងកំណត់អត្តសញ្ញាណគម្លាតមួយចំនួនពីប្រតិបត្តិការ។ ប៉ុន្តែដូចដែលកើតឡើងជាញឹកញាប់ មុខងារបន្ថែមណាមួយតម្រូវឱ្យមានការជាវបង់ប្រាក់ដែលត្រូវគ្នា ដែលនឹងទាមទារការវិនិយោគហិរញ្ញវត្ថុដែលត្រូវគ្នាពីអ្នក ដែលអ្នកត្រូវរៀបចំផែនការជាមុន។

Azure មានសមត្ថភាពត្រួតពិនិត្យការគំរាមកំហែងដែលភ្ជាប់មកជាមួយជាច្រើន ដែលត្រូវបានបញ្ចូលទៅក្នុង Azure AD, Azure Monitor និង Azure Security Center ។ ឧទាហរណ៍ ក្នុងចំណោមពួកគេ ការរកឃើញអន្តរកម្មនៃម៉ាស៊ីននិម្មិតជាមួយ IP ព្យាបាទដែលគេស្គាល់ (ដោយសារវត្តមាននៃការរួមបញ្ចូលជាមួយសេវាកម្ម Threat Intelligence ពី Microsoft) ការរកឃើញមេរោគនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធពពក ដោយទទួលការជូនដំណឹងពីម៉ាស៊ីននិម្មិតដែលបង្ហោះក្នុងពពក ពាក្យសម្ងាត់ ស្មានការវាយប្រហារ” នៅលើម៉ាស៊ីននិម្មិត ភាពងាយរងគ្រោះក្នុងការកំណត់រចនាសម្ព័ន្ធនៃប្រព័ន្ធកំណត់អត្តសញ្ញាណអ្នកប្រើប្រាស់ ការចូលទៅក្នុងប្រព័ន្ធពីអ្នកអនាមិក ឬថ្នាំងដែលមានមេរោគ ការលេចធ្លាយគណនី ការចូលទៅក្នុងប្រព័ន្ធពីទីតាំងមិនធម្មតា។ល។ Azure ថ្ងៃនេះគឺជាអ្នកផ្តល់សេវាពពកមួយក្នុងចំណោមអ្នកផ្តល់សេវាពពកមួយចំនួនដែលផ្តល់ឱ្យអ្នកនូវសមត្ថភាពនៃ Threat Intelligence ដើម្បីបង្កើននូវព្រឹត្តិការណ៍សុវត្ថិភាពព័ត៌មានដែលប្រមូលបាន។

ដូចដែលបានរៀបរាប់ខាងលើ មុខងារសុវត្ថិភាព ហើយជាលទ្ធផល ព្រឹត្តិការណ៍សុវត្ថិភាពដែលបង្កើតឡើងដោយវាមិនមានសម្រាប់អ្នកប្រើប្រាស់ទាំងអស់ស្មើគ្នាទេ ប៉ុន្តែទាមទារការជាវជាក់លាក់ដែលរួមបញ្ចូលមុខងារដែលអ្នកត្រូវការ ដែលបង្កើតព្រឹត្តិការណ៍សមស្របសម្រាប់ការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាន។ ជាឧទាហរណ៍ មុខងារមួយចំនួនដែលបានពិពណ៌នានៅក្នុងកថាខណ្ឌមុនសម្រាប់ការត្រួតពិនិត្យភាពមិនប្រក្រតីនៅក្នុងគណនីគឺមានតែនៅក្នុងអាជ្ញាប័ណ្ណបុព្វលាភ P2 សម្រាប់សេវាកម្ម Azure AD ប៉ុណ្ណោះ។ បើគ្មានវាទេ អ្នកដូចជាក្នុងករណី AWS នឹងត្រូវវិភាគព្រឹត្តិការណ៍សុវត្ថិភាពដែលប្រមូលបាន "ដោយដៃ"។ ហើយផងដែរ អាស្រ័យលើប្រភេទនៃអាជ្ញាប័ណ្ណ Azure AD មិនមែនព្រឹត្តិការណ៍ទាំងអស់នឹងមានសម្រាប់ការវិភាគនោះទេ។

នៅលើវិបផតថល Azure អ្នកអាចគ្រប់គ្រងសំណួរស្វែងរកទាំងពីរសម្រាប់កំណត់ហេតុដែលអ្នកចាប់អារម្មណ៍ និងរៀបចំផ្ទាំងគ្រប់គ្រងដើម្បីមើលឃើញសូចនាករសុវត្ថិភាពព័ត៌មានសំខាន់ៗ។ លើសពីនេះទៀតនៅទីនោះអ្នកអាចជ្រើសរើសផ្នែកបន្ថែម Azure Monitor ដែលអនុញ្ញាតឱ្យអ្នកពង្រីកមុខងារនៃកំណត់ហេតុ Azure Monitor និងទទួលបានការវិភាគកាន់តែស៊ីជម្រៅនៃព្រឹត្តិការណ៍ពីទិដ្ឋភាពសុវត្ថិភាព។

ប្រសិនបើអ្នកត្រូវការមិនត្រឹមតែសមត្ថភាពក្នុងការធ្វើការជាមួយកំណត់ហេតុប៉ុណ្ណោះទេប៉ុន្តែមជ្ឈមណ្ឌលសុវត្ថិភាពដ៏ទូលំទូលាយសម្រាប់វេទិកាពពក Azure របស់អ្នក រួមទាំងការគ្រប់គ្រងគោលនយោបាយសុវត្ថិភាពព័ត៌មាន នោះអ្នកអាចនិយាយអំពីតម្រូវការក្នុងការធ្វើការជាមួយ Azure Security Center ដែលជាមុខងារមានប្រយោជន៍ភាគច្រើន។ អាចរកបានសម្រាប់ប្រាក់មួយចំនួន ឧទាហរណ៍ ការរកឃើញការគំរាមកំហែង ការត្រួតពិនិត្យនៅខាងក្រៅ Azure ការវាយតម្លៃការអនុលោម។ល។ (នៅក្នុងកំណែឥតគិតថ្លៃ អ្នកគ្រាន់តែអាចចូលទៅកាន់ការវាយតម្លៃសុវត្ថិភាព និងការណែនាំសម្រាប់ការលុបបំបាត់បញ្ហាដែលបានកំណត់)។ វាបង្រួបបង្រួមបញ្ហាសន្តិសុខទាំងអស់នៅកន្លែងតែមួយ។ ជាការពិត យើងអាចនិយាយអំពីកម្រិតសុវត្ថិភាពព័ត៌មានខ្ពស់ជាង Azure Monitor ផ្តល់ឱ្យអ្នក ព្រោះក្នុងករណីនេះទិន្នន័យដែលប្រមូលបានទូទាំងរោងចក្រ cloud របស់អ្នកត្រូវបានពង្រឹងដោយប្រើប្រភពជាច្រើនដូចជា Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) និង Microsoft Security Response Center (MSRC) ដែលការរៀនម៉ាស៊ីនទំនើបៗ និងក្បួនដោះស្រាយការវិភាគអាកប្បកិរិយាត្រូវបានដាក់បញ្ចូលគ្នា ដែលចុងក្រោយគួរតែបង្កើនប្រសិទ្ធភាពនៃការរកឃើញ និងឆ្លើយតបទៅនឹងការគំរាមកំហែង។ .

Azure ក៏មាន SIEM របស់ខ្លួនផងដែរ - វាបានបង្ហាញខ្លួននៅដើមឆ្នាំ 2019 ។ នេះគឺជា Azure Sentinel ដែលពឹងផ្អែកលើទិន្នន័យពី Azure Monitor ហើយក៏អាចរួមបញ្ចូលជាមួយផងដែរ។ ដំណោះស្រាយសុវត្ថិភាពខាងក្រៅ (ឧទាហរណ៍ NGFW ឬ WAF) បញ្ជីដែលកំពុងតែរីកចម្រើនឥតឈប់ឈរ។ លើសពីនេះ តាមរយៈការរួមបញ្ចូលនៃ Microsoft Graph Security API អ្នកមានសមត្ថភាពក្នុងការភ្ជាប់ព័ត៌មានអំពីការគំរាមកំហែងរបស់អ្នកផ្ទាល់ទៅកាន់ Sentinel ដែលបង្កើនសមត្ថភាពសម្រាប់ការវិភាគឧប្បត្តិហេតុនៅក្នុងពពក Azure របស់អ្នក។ វាអាចត្រូវបានអះអាងថា Azure Sentinel គឺជា SIEM "ដើម" ដំបូងដែលបានបង្ហាញខ្លួនពីអ្នកផ្តល់សេវាពពក (Splunk ឬ ELK ដូចគ្នា ដែលអាចបង្ហោះក្នុងពពក ឧទាហរណ៍ AWS នៅតែមិនត្រូវបានបង្កើតឡើងដោយអ្នកផ្តល់សេវាពពកបែបប្រពៃណី) ។ Azure Sentinel and Security Center អាចត្រូវបានគេហៅថា SOC សម្រាប់ Azure cloud ហើយអាចត្រូវបានកំណត់ចំពោះពួកគេ (ជាមួយនឹងការកក់ជាក់លាក់) ប្រសិនបើអ្នកលែងមានហេដ្ឋារចនាសម្ព័ន្ធណាមួយ ហើយអ្នកបានផ្ទេរធនធានកុំព្យូទ័ររបស់អ្នកទាំងអស់ទៅ cloud ហើយវានឹងក្លាយជា Microsoft cloud Azure ។

ប៉ុន្តែដោយសារសមត្ថភាពដែលភ្ជាប់មកជាមួយរបស់ Azure (ទោះបីជាអ្នកមានការជាវ Sentinel) ជាញឹកញាប់មិនគ្រប់គ្រាន់សម្រាប់គោលបំណងនៃការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាន និងការរួមបញ្ចូលដំណើរការនេះជាមួយនឹងប្រភពនៃព្រឹត្តិការណ៍សុវត្ថិភាពផ្សេងទៀត (ទាំងពពក និងខាងក្នុង) មាន ត្រូវការនាំចេញទិន្នន័យដែលបានប្រមូលទៅប្រព័ន្ធខាងក្រៅ ដែលអាចរួមបញ្ចូល SIEM ។ នេះត្រូវបានធ្វើទាំងការប្រើប្រាស់ API និងការប្រើប្រាស់ផ្នែកបន្ថែមពិសេស ដែលបច្ចុប្បន្នមានជាផ្លូវការសម្រាប់តែ SIEM ខាងក្រោមប៉ុណ្ណោះ - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight និង ELK ។ រហូតមកដល់ពេលថ្មីៗនេះ មាន SIEM បែបនេះកាន់តែច្រើន ប៉ុន្តែចាប់ពីថ្ងៃទី 1 ខែមិថុនា ឆ្នាំ 2019 ក្រុមហ៊ុន Microsoft បានឈប់គាំទ្រឧបករណ៍រួមបញ្ចូលកំណត់ហេតុ Azure (AzLog) ដែលនៅពេលព្រឹកព្រលឹមនៃអត្ថិភាពនៃ Azure និងក្នុងករណីដែលមិនមានស្តង់ដារធម្មតានៃការធ្វើការជាមួយកំណត់ហេតុ (Azure ម៉ូនីទ័រមិនទាន់មាននៅឡើយទេ) ធ្វើឱ្យវាមានភាពងាយស្រួលក្នុងការរួមបញ្ចូល SIEM ខាងក្រៅជាមួយ Microsoft cloud ។ ឥឡូវនេះស្ថានភាពបានផ្លាស់ប្តូរហើយ Microsoft ណែនាំវេទិកា Azure Event Hub ជាឧបករណ៍រួមបញ្ចូលដ៏សំខាន់សម្រាប់ SIEMs ផ្សេងទៀត។ មនុស្សជាច្រើនបានអនុវត្តការរួមបញ្ចូលបែបនេះរួចហើយ ប៉ុន្តែត្រូវប្រយ័ត្ន - ពួកគេប្រហែលជាមិនចាប់យកកំណត់ហេតុ Azure ទាំងអស់ទេ ប៉ុន្តែមានតែមួយចំនួនប៉ុណ្ណោះ (មើលក្នុងឯកសារសម្រាប់ SIEM របស់អ្នក)។

បញ្ចប់ដំណើរកំសាន្តខ្លីៗទៅកាន់ Azure ខ្ញុំចង់ផ្តល់នូវអនុសាសន៍ទូទៅអំពីសេវាកម្មពពកនេះ - មុនពេលអ្នកនិយាយអ្វីអំពីមុខងារត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាននៅក្នុង Azure អ្នកគួរតែកំណត់រចនាសម្ព័ន្ធពួកវាដោយប្រុងប្រយ័ត្ន ហើយសាកល្បងថាពួកគេធ្វើការដូចដែលបានសរសេរក្នុងឯកសារ និង ដូចដែលអ្នកប្រឹក្សាបានប្រាប់អ្នកថា Microsoft (ហើយពួកគេអាចមានទស្សនៈផ្សេងគ្នាលើមុខងារនៃមុខងារ Azure)។ ប្រសិនបើអ្នកមានធនធានហិរញ្ញវត្ថុ អ្នកអាចច្របាច់យកព័ត៌មានមានប្រយោជន៍ជាច្រើនពី Azure ទាក់ទងនឹងការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាន។ ប្រសិនបើធនធានរបស់អ្នកមានកម្រិត នោះដូចក្នុងករណី AWS ដែរ អ្នកនឹងត្រូវពឹងផ្អែកលើកម្លាំងផ្ទាល់ខ្លួនរបស់អ្នក និងទិន្នន័យឆៅដែល Azure Monitor ផ្តល់ឱ្យអ្នក។ ហើយចងចាំថាមុខងារត្រួតពិនិត្យជាច្រើនត្រូវចំណាយប្រាក់ ហើយវាជាការប្រសើរជាងក្នុងការស្គាល់ខ្លួនអ្នកជាមួយនឹងគោលការណ៍កំណត់តម្លៃជាមុន។ ឧទាហរណ៍ ដោយមិនគិតថ្លៃ អ្នកអាចរក្សាទុកទិន្នន័យរយៈពេល 31 ថ្ងៃរហូតដល់អតិបរមា 5 GB សម្រាប់អតិថិជនម្នាក់ - លើសពីតម្លៃទាំងនេះនឹងតម្រូវឱ្យអ្នកដកប្រាក់បន្ថែម (ប្រហែល $2+ សម្រាប់រក្សាទុករាល់ GB បន្ថែមពីអតិថិជន និង $0,1 សម្រាប់ រក្សាទុក 1 GB រៀងរាល់ខែបន្ថែម) ។ ការធ្វើការជាមួយកម្មវិធី telemetry និងម៉ែត្រក៏អាចត្រូវការថវិកាបន្ថែម ក៏ដូចជាការធ្វើការជាមួយការជូនដំណឹង និងការជូនដំណឹង (ដែនកំណត់ជាក់លាក់គឺអាចរកបានដោយឥតគិតថ្លៃ ដែលប្រហែលជាមិនគ្រប់គ្រាន់សម្រាប់តម្រូវការរបស់អ្នក)។

ឧទាហរណ៍៖ ការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាននៅក្នុង IaaS ផ្អែកលើ Google Cloud Platform

Google Cloud Platform មើលទៅក្មេងជាងបើធៀបនឹង AWS និង Azure ប៉ុន្តែនេះគឺល្អមួយផ្នែក។ មិនដូច AWS ដែលបង្កើនសមត្ថភាពរបស់ខ្លួន រួមទាំងសុវត្ថិភាពជាបណ្តើរៗ ដែលមានបញ្ហាជាមួយនឹងការធ្វើមជ្ឈិម។ GCP ដូចជា Azure ត្រូវបានគ្រប់គ្រងបានល្អជាងនៅកណ្តាល ដែលកាត់បន្ថយកំហុស និងពេលវេលាអនុវត្តនៅទូទាំងសហគ្រាស។ តាមទស្សនៈសុវត្ថិភាព GCP គឺគ្រប់គ្រាន់ហើយរវាង AWS និង Azure ។ គាត់ក៏មានការចុះឈ្មោះព្រឹត្តិការណ៍តែមួយសម្រាប់អង្គការទាំងមូលដែរ ប៉ុន្តែវាមិនពេញលេញទេ។ មុខងារមួយចំនួននៅតែស្ថិតក្នុងទម្រង់បេតា ប៉ុន្តែបន្តិចម្តងៗ កង្វះនេះគួរតែត្រូវបានលុបចោល ហើយ GCP នឹងក្លាយជាវេទិកាដែលមានភាពចាស់ទុំជាងមុនទាក់ទងនឹងការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាន។

ឧបករណ៍សំខាន់សម្រាប់ការកត់ត្រាព្រឹត្តិការណ៍នៅក្នុង GCP គឺ Stackdriver Logging (ស្រដៀងទៅនឹង Azure Monitor) ដែលអនុញ្ញាតឱ្យអ្នកប្រមូលព្រឹត្តិការណ៍ឆ្លងកាត់ហេដ្ឋារចនាសម្ព័ន្ធពពកទាំងមូលរបស់អ្នក (ក៏ដូចជាពី AWS) ។ តាមទស្សនៈសុវត្ថិភាពនៅក្នុង GCP អង្គការនីមួយៗ គម្រោង ឬថតឯកសារមានកំណត់ហេតុចំនួនបួន៖

• សកម្មភាពអ្នកគ្រប់គ្រង - មានព្រឹត្តិការណ៍ទាំងអស់ដែលទាក់ទងនឹងការចូលប្រើរដ្ឋបាល ឧទាហរណ៍ ការបង្កើតម៉ាស៊ីននិម្មិត ការផ្លាស់ប្តូរសិទ្ធិចូលប្រើប្រាស់។ល។ កំណត់ហេតុនេះតែងតែត្រូវបានសរសេរដោយមិនគិតពីបំណងប្រាថ្នារបស់អ្នក ហើយរក្សាទុកទិន្នន័យរបស់វាសម្រាប់រយៈពេល 400 ថ្ងៃ។
• ការចូលប្រើទិន្នន័យ - មានព្រឹត្តិការណ៍ទាំងអស់ដែលទាក់ទងនឹងការធ្វើការជាមួយទិន្នន័យដោយអ្នកប្រើប្រាស់ពពក (ការបង្កើត ការកែប្រែ ការអាន។ល។)។ តាមលំនាំដើម កំណត់ហេតុនេះមិនត្រូវបានសរសេរទេ ដោយសារបរិមាណរបស់វាកើនឡើងយ៉ាងលឿន។ សម្រាប់ហេតុផលនេះ, ជីវិតធ្នើរបស់វាគឺត្រឹមតែ 30 ថ្ងៃប៉ុណ្ណោះ។ លើសពីនេះទៀត មិនមែនអ្វីៗទាំងអស់ត្រូវបានសរសេរនៅក្នុងទស្សនាវដ្តីនេះទេ។ ឧទាហរណ៍ ព្រឹត្តិការណ៍ដែលទាក់ទងនឹងធនធានដែលអាចចូលប្រើជាសាធារណៈសម្រាប់អ្នកប្រើប្រាស់ទាំងអស់ ឬដែលអាចចូលប្រើបានដោយមិនចាំបាច់ចូលទៅក្នុង GCP មិនត្រូវបានសរសេរទៅវាទេ។
• ព្រឹត្តិការណ៍ប្រព័ន្ធ - មានព្រឹត្តិការណ៍ប្រព័ន្ធមិនទាក់ទងនឹងអ្នកប្រើប្រាស់ ឬសកម្មភាពរបស់អ្នកគ្រប់គ្រងដែលផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធធនធានពពក។ វាតែងតែត្រូវបានសរសេរ និងរក្សាទុករយៈពេល 400 ថ្ងៃ។
• តម្លាភាពនៃការចូលប្រើគឺជាឧទាហរណ៍តែមួយគត់នៃកំណត់ហេតុដែលចាប់យកសកម្មភាពទាំងអស់របស់បុគ្គលិក Google (ប៉ុន្តែមិនទាន់មានសម្រាប់សេវាកម្ម GCP ទាំងអស់) ដែលចូលប្រើហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកជាផ្នែកនៃភារកិច្ចការងាររបស់ពួកគេ។ កំណត់ហេតុនេះត្រូវបានរក្សាទុករយៈពេល 400 ថ្ងៃ ហើយមិនមានសម្រាប់អតិថិជន GCP ទាំងអស់នោះទេ ប៉ុន្តែលុះត្រាតែមានលក្ខខណ្ឌមួយចំនួនត្រូវបានបំពេញ (ទាំងការគាំទ្រកម្រិតមាស ឬផ្លាទីន ឬវត្តមាននៃតួនាទី 4 នៃប្រភេទជាក់លាក់ដែលជាផ្នែកមួយនៃការគាំទ្រសាជីវកម្ម)។ មុខងារស្រដៀងគ្នានេះក៏មានផងដែរ ឧទាហរណ៍នៅក្នុង Office 365 - Lockbox ។

ឧទាហរណ៍នៃកំណត់ហេតុ៖ តម្លាភាពនៃការចូលប្រើ

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

ការចូលប្រើកំណត់ហេតុទាំងនេះអាចធ្វើទៅបានតាមវិធីជាច្រើន (តាមរបៀបដូចគ្នានឹង Azure និង AWS ដែលបានពិភាក្សាពីមុន) - តាមរយៈចំណុចប្រទាក់អ្នកមើលកំណត់ហេតុ តាមរយៈ API តាមរយៈ Google Cloud SDK ឬតាមរយៈទំព័រសកម្មភាពនៃគម្រោងរបស់អ្នកដែលអ្នក មានចំណាប់អារម្មណ៍លើព្រឹត្តិការណ៍។ តាមរបៀបដូចគ្នាពួកគេអាចនាំចេញទៅកាន់ដំណោះស្រាយខាងក្រៅសម្រាប់ការវិភាគបន្ថែម។ ក្រោយមកទៀតត្រូវបានធ្វើដោយការនាំចេញកំណត់ហេតុទៅកាន់ BigQuery ឬ Cloud Pub/Sub storage។

បន្ថែមពីលើ Stackdriver Logging វេទិកា GCP ក៏ផ្តល់ជូននូវមុខងារត្រួតពិនិត្យ Stackdriver ដែលអនុញ្ញាតឱ្យអ្នកត្រួតពិនិត្យរង្វាស់សំខាន់ៗ (ប្រតិបត្តិការ MTBF សុខភាពរួម។ល។) នៃសេវាកម្ម និងកម្មវិធីពពក។ ទិន្នន័យដែលបានដំណើរការ និងមើលឃើញអាចធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការស្វែងរកបញ្ហានៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធពពករបស់អ្នក រួមទាំងនៅក្នុងបរិបទនៃសុវត្ថិភាពផងដែរ។ ប៉ុន្តែគួរកត់សំគាល់ថាមុខងារនេះនឹងមិនមានភាពសម្បូរបែបនៅក្នុងបរិបទនៃសុវត្ថិភាពព័ត៌មាននោះទេ ចាប់តាំងពីថ្ងៃនេះ GCP មិនមាន analogue នៃ AWS GuardDuty ដូចគ្នា ហើយមិនអាចកំណត់អត្តសញ្ញាណអាក្រក់ក្នុងចំណោមព្រឹត្តិការណ៍ដែលបានចុះឈ្មោះទាំងអស់ (Google បានបង្កើត Event Threat Detection, ប៉ុន្តែ​វា​នៅ​ស្ថិត​ក្រោម​ការ​អភិវឌ្ឍ​នៅ​ក្នុង​បេតា ហើយ​វា​លឿន​ពេក​ក្នុង​ការ​និយាយ​អំពី​អត្ថប្រយោជន៍​របស់​វា)។ Stackdriver Monitoring អាច​ត្រូវ​បាន​ប្រើ​ជា​ប្រព័ន្ធ​សម្រាប់​រក​ឃើញ​ភាព​មិន​ប្រក្រតី ដែល​បន្ទាប់​មក​នឹង​ត្រូវ​បាន​ស៊ើបអង្កេត​ដើម្បី​រក​មូលហេតុ​នៃ​ការ​កើត​ឡើង​របស់​វា។ ប៉ុន្តែដោយសារកង្វះបុគ្គលិកដែលមានលក្ខណៈសម្បត្តិគ្រប់គ្រាន់ក្នុងវិស័យសន្តិសុខព័ត៌មាន GCP នៅលើទីផ្សារ កិច្ចការនេះបច្ចុប្បន្នមើលទៅពិបាកណាស់។

វាក៏មានតម្លៃផងដែរក្នុងការផ្តល់នូវបញ្ជីនៃម៉ូឌុលសុវត្ថិភាពព័ត៌មានមួយចំនួនដែលអាចប្រើបាននៅក្នុង GCP cloud របស់អ្នក ហើយដែលស្រដៀងនឹងអ្វីដែល AWS ផ្តល់ជូន៖

• Cloud Security Command Center គឺជា analogue នៃ AWS Security Hub និង Azure Security Center ។
• Cloud DLP - ការរកឃើញ និងការកែសម្រួលដោយស្វ័យប្រវត្តិ (ឧ. ការបិទបាំង) នៃទិន្នន័យដែលបានបង្ហោះក្នុងពពក ដោយប្រើគោលការណ៍ចាត់ថ្នាក់ដែលបានកំណត់ជាមុនជាង 90 ។
• Cloud Scanner គឺជាម៉ាស៊ីនស្កេនសម្រាប់ភាពងាយរងគ្រោះដែលគេស្គាល់ (XSS, Flash Injection, unpatched libraries ។ល។) នៅក្នុង App Engine, Compute Engine និង Google Kubernetes ។
• Cloud IAM - គ្រប់គ្រងការចូលប្រើធនធាន GCP ទាំងអស់។
• Cloud Identity - គ្រប់គ្រងអ្នកប្រើប្រាស់ GCP ឧបករណ៍ និងគណនីកម្មវិធីពីកុងសូលតែមួយ។
• Cloud HSM - ការការពារសោគ្រីប។
• សេវាកម្មគ្រប់គ្រងសោរពពក - ការគ្រប់គ្រងសោគ្រីបនៅក្នុង GCP ។
• ការគ្រប់គ្រងសេវាកម្ម VPC - បង្កើតបរិវេណសុវត្ថិភាពជុំវិញធនធាន GCP របស់អ្នកដើម្បីការពារពួកគេពីការលេចធ្លាយ។
• Titan Security Key - ការការពារប្រឆាំងនឹងការបន្លំ។

ម៉ូឌុលទាំងនេះជាច្រើនបង្កើតព្រឹត្តិការណ៍សុវត្ថិភាពដែលអាចផ្ញើទៅកាន់កន្លែងផ្ទុក BigQuery សម្រាប់ការវិភាគ ឬនាំចេញទៅកាន់ប្រព័ន្ធផ្សេងទៀត រួមទាំង SIEM ផងដែរ។ ដូចដែលបានរៀបរាប់ខាងលើ GCP គឺជាវេទិកាដែលកំពុងអភិវឌ្ឍយ៉ាងសកម្ម ហើយឥឡូវនេះ Google កំពុងអភិវឌ្ឍម៉ូឌុលសុវត្ថិភាពព័ត៌មានថ្មីមួយចំនួនសម្រាប់វេទិការបស់ខ្លួន។ ក្នុងចំណោមនោះមាន Event Threat Detection (ឥឡូវមាននៅក្នុងបេតា) ដែលស្កេនការកត់ត្រា Stackdriver ក្នុងការស្វែងរកដាននៃសកម្មភាពដែលមិនមានការអនុញ្ញាត (ស្រដៀងទៅនឹង GuardDuty នៅក្នុង AWS) ឬ Policy Intelligence (មាននៅក្នុងអាល់ហ្វា) ដែលនឹងអនុញ្ញាតឱ្យអ្នកបង្កើតគោលការណ៍ឆ្លាតវៃសម្រាប់ ការចូលប្រើធនធាន GCP ។

ខ្ញុំបានធ្វើការសង្ខេបអំពីសមត្ថភាពត្រួតពិនិត្យដែលភ្ជាប់មកជាមួយនៅក្នុងវេទិកាពពកដ៏ពេញនិយម។ ប៉ុន្តែតើអ្នកមានអ្នកឯកទេសដែលអាចធ្វើការជាមួយ "ឆៅ" កំណត់ហេតុអ្នកផ្តល់សេវា IaaS (មិនមែនគ្រប់គ្នាត្រៀមខ្លួនជាស្រេចដើម្បីទិញសមត្ថភាពកម្រិតខ្ពស់នៃ AWS ឬ Azure ឬ Google) ទេ? លើសពីនេះ មនុស្សជាច្រើនស្គាល់សុភាសិតថា "ទុកចិត្ត ប៉ុន្តែផ្ទៀងផ្ទាត់" ដែលជាការពិតជាងពេលណាទាំងអស់នៅក្នុងវិស័យសន្តិសុខ។ តើ​អ្នក​ជឿជាក់​លើ​សមត្ថភាព​ដែល​មាន​ស្រាប់​របស់​ក្រុមហ៊ុន​ផ្ដល់​ពពក​ដែល​ផ្ញើ​ព្រឹត្តិការណ៍​សុវត្ថិភាព​ព័ត៌មាន​ដល់​អ្នក​កម្រិត​ណា? តើ​ពួកគេ​ផ្តោត​លើ​សុវត្ថិភាព​ព័ត៌មាន​កម្រិតណា​?

ពេលខ្លះវាមានតម្លៃក្នុងការមើលដំណោះស្រាយត្រួតពិនិត្យហេដ្ឋារចនាសម្ព័ន្ធពពកត្រួតគ្នា ដែលអាចបំពេញបន្ថែមសុវត្ថិភាពពពកដែលភ្ជាប់មកជាមួយ ហើយជួនកាលដំណោះស្រាយបែបនេះគឺជាជម្រើសតែមួយគត់ដើម្បីទទួលបានការយល់ដឹងអំពីសុវត្ថិភាពទិន្នន័យ និងកម្មវិធីរបស់អ្នកដែលបង្ហោះក្នុងពពក។ លើសពីនេះ ពួកវាមានភាពងាយស្រួលជាងមុន ដោយសារពួកគេធ្វើកិច្ចការទាំងអស់ក្នុងការវិភាគកំណត់ហេតុចាំបាច់ដែលបង្កើតឡើងដោយសេវាកម្មពពកផ្សេងៗគ្នាពីអ្នកផ្តល់សេវាពពកផ្សេងៗគ្នា។ ឧទាហរណ៏នៃដំណោះស្រាយត្រួតលើគ្នាបែបនេះគឺ Cisco Stealthwatch Cloud ដែលផ្តោតលើកិច្ចការតែមួយ - ការត្រួតពិនិត្យភាពមិនប្រក្រតីនៃសុវត្ថិភាពព័ត៌មាននៅក្នុងបរិស្ថានពពក រួមទាំងមិនត្រឹមតែ Amazon AWS, Microsoft Azure និង Google Cloud Platform ប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានពពកឯកជនផងដែរ។

ឧទាហរណ៍៖ ការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានដោយប្រើ Stealthwatch Cloud

AWS ផ្តល់នូវវេទិកាកុំព្យូទ័រដែលអាចបត់បែនបាន ប៉ុន្តែភាពបត់បែននេះធ្វើឱ្យវាកាន់តែងាយស្រួលសម្រាប់ក្រុមហ៊ុនក្នុងការធ្វើកំហុសដែលនាំឱ្យមានបញ្ហាសុវត្ថិភាព។ ហើយគំរូសុវត្ថិភាពព័ត៌មានដែលបានចែករំលែករួមចំណែកដល់បញ្ហានេះប៉ុណ្ណោះ។ ដំណើរការកម្មវិធីនៅក្នុងពពកជាមួយនឹងភាពងាយរងគ្រោះដែលមិនស្គាល់ (អ្នកដែលស្គាល់អាចត្រូវបានប្រយុទ្ធ ឧទាហរណ៍ដោយ AWS Inspector ឬ GCP Cloud Scanner) ពាក្យសម្ងាត់ខ្សោយ ការកំណត់មិនត្រឹមត្រូវ អ្នកខាងក្នុង។ល។ ហើយអ្វីៗទាំងអស់នេះត្រូវបានឆ្លុះបញ្ចាំងនៅក្នុងឥរិយាបទនៃធនធានពពក ដែលអាចត្រូវបានត្រួតពិនិត្យដោយ Cisco Stealthwatch Cloud ដែលជាប្រព័ន្ធត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាន និងប្រព័ន្ធរកឃើញការវាយប្រហារ។ ពពកសាធារណៈ និងឯកជន។

មុខងារសំខាន់មួយរបស់ Cisco Stealthwatch Cloud គឺសមត្ថភាពក្នុងការធ្វើម៉ូដែលអង្គភាព។ ជាមួយវា អ្នកអាចបង្កើតគំរូកម្មវិធី (នោះគឺការក្លែងធ្វើជិតដល់ពេលជាក់ស្តែង) នៃធនធានពពកនីមួយៗរបស់អ្នក (វាមិនមានបញ្ហាថាតើវាជា AWS, Azure, GCP ឬអ្វីផ្សេងទៀតទេ)។ ទាំងនេះអាចរួមបញ្ចូលម៉ាស៊ីនមេ និងអ្នកប្រើប្រាស់ ក៏ដូចជាប្រភេទធនធានជាក់លាក់ចំពោះបរិស្ថានពពករបស់អ្នក ដូចជាក្រុមសុវត្ថិភាព និងក្រុមខ្នាតស្វ័យប្រវត្តិ។ ម៉ូដែលទាំងនេះប្រើការស្ទ្រីមទិន្នន័យដែលមានរចនាសម្ព័ន្ធដែលផ្តល់ដោយសេវាកម្មពពកជាការបញ្ចូល។ ឧទាហរណ៍ សម្រាប់ AWS ទាំងនេះអាចជាកំណត់ហេតុលំហូរ VPC, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda និង AWS IAM ។ ការបង្កើតគំរូអង្គភាពរកឃើញតួនាទី និងឥរិយាបថនៃធនធានណាមួយរបស់អ្នកដោយស្វ័យប្រវត្តិ (អ្នកអាចនិយាយអំពីការធ្វើកម្រងព័ត៌មានសកម្មភាពលើពពកទាំងអស់)។ តួនាទីទាំងនេះរួមមានឧបករណ៍ចល័ត Android ឬ Apple, ម៉ាស៊ីនមេ Citrix PVS, ម៉ាស៊ីនមេ RDP, ច្រកផ្លូវសំបុត្រ, ម៉ាស៊ីនភ្ញៀវ VoIP, ម៉ាស៊ីនមេស្ថានីយ, ឧបករណ៍បញ្ជាដែន ជាដើម។ បន្ទាប់មក វាបន្តតាមដានឥរិយាបថរបស់ពួកគេ ដើម្បីកំណត់ថាតើនៅពេលណាដែលអាកប្បកិរិយាគ្រោះថ្នាក់ ឬគំរាមកំហែងសុវត្ថិភាពកើតឡើង។ អ្នកអាចកំណត់អត្តសញ្ញាណការទាយពាក្យសម្ងាត់ ការវាយប្រហារដោយ DDoS ការលេចធ្លាយទិន្នន័យ ការចូលប្រើពីចម្ងាយខុសច្បាប់ សកម្មភាពកូដព្យាបាទ ការស្កេនភាពងាយរងគ្រោះ និងការគំរាមកំហែងផ្សេងៗទៀត។ ឧទាហរណ៍ នេះជាអ្វីដែលរកឃើញការប៉ុនប៉ងចូលប្រើពីចម្ងាយពីប្រទេសដែលមានលក្ខណៈធម្មតាសម្រាប់ស្ថាប័នរបស់អ្នក (កូរ៉េខាងត្បូង) ទៅកាន់ចង្កោម Kubernetes តាមរយៈ SSH មើលទៅដូច៖

ហើយនេះគឺជាអ្វីដែលការលេចធ្លាយព័ត៌មានដែលត្រូវបានចោទប្រកាន់ពីមូលដ្ឋានទិន្នន័យ Postgress ទៅកាន់ប្រទេសមួយដែលយើងមិនធ្លាប់ជួបប្រទះពីមុនមក មើលទៅហាក់ដូចជា៖

ទីបំផុត នេះជាអ្វីដែលការប៉ុនប៉ង SSH ដែលបរាជ័យច្រើនពេកពីប្រទេសចិន និងឥណ្ឌូនេស៊ីពីឧបករណ៍ពីចម្ងាយខាងក្រៅមើលទៅដូច៖

ឬឧបមាថាម៉ាស៊ីនមេនៅក្នុង VPC តាមគោលការណ៍ មិនដែលក្លាយជាគោលដៅចូលពីចម្ងាយទេ។ ចូរសន្មតបន្ថែមទៀតថាកុំព្យូទ័រនេះជួបប្រទះការចូលពីចម្ងាយ ដោយសារការផ្លាស់ប្តូរខុសនៅក្នុងគោលការណ៍ច្បាប់ជញ្ជាំងភ្លើង។ មុខងារគំរូរបស់អង្គភាពនឹងរកឃើញ និងរាយការណ៍ពីសកម្មភាពនេះ (“ការចូលប្រើពីចម្ងាយមិនធម្មតា”) ក្នុងពេលជាក់ស្តែង ហើយចង្អុលទៅការហៅទៅកាន់ AWS CloudTrail, Azure Monitor ឬ GCP Stackdriver Logging API ជាក់លាក់ (រួមទាំងឈ្មោះអ្នកប្រើប្រាស់ កាលបរិច្ឆេទ និងពេលវេលា ក្នុងចំណោមព័ត៌មានលម្អិតផ្សេងទៀត ) ដែលបានជំរុញឱ្យមានការផ្លាស់ប្តូរទៅច្បាប់ ITU ។ ហើយ​ព័ត៌មាន​នេះ​អាច​ផ្ញើ​ទៅ SIEM ដើម្បី​ធ្វើ​ការ​វិភាគ។

សមត្ថភាពស្រដៀងគ្នានេះត្រូវបានអនុវត្តសម្រាប់បរិយាកាសពពកណាមួយដែលគាំទ្រដោយ Cisco Stealthwatch Cloud៖

ការបង្កើតគំរូអង្គភាពគឺជាទម្រង់តែមួយគត់នៃស្វ័យប្រវត្តិកម្មសុវត្ថិភាពដែលអាចបង្ហាញបញ្ហាដែលមិនស្គាល់ពីមុនជាមួយមនុស្ស ដំណើរការ ឬបច្ចេកវិទ្យារបស់អ្នក។ ឧទាហរណ៍ វាអនុញ្ញាតឱ្យអ្នករកឃើញ ក្នុងចំណោមរបស់ផ្សេងទៀត បញ្ហាសុវត្ថិភាពដូចជា៖

• មាននរណាម្នាក់បានរកឃើញ backdoor នៅក្នុងកម្មវិធីដែលយើងប្រើ?
• តើមានកម្មវិធី ឬឧបករណ៍ភាគីទីបីណាមួយនៅក្នុងពពករបស់យើងទេ?
• តើ​អ្នក​ប្រើ​ដែល​មាន​ការ​អនុញ្ញាត​បំពាន​សិទ្ធិ​ឬ?
• តើមានកំហុសក្នុងការកំណត់រចនាសម្ព័ន្ធដែលអនុញ្ញាតឱ្យចូលប្រើពីចម្ងាយ ឬការប្រើប្រាស់ធនធានដោយអចេតនាផ្សេងទៀតដែរឬទេ?
• តើមានការលេចធ្លាយទិន្នន័យពីម៉ាស៊ីនមេរបស់យើងទេ?
• តើមាននរណាម្នាក់កំពុងព្យាយាមភ្ជាប់ជាមួយយើងពីទីតាំងភូមិសាស្ត្រ atypical?
• តើ​ពពក​របស់​យើង​ឆ្លង​មេរោគ​កូដ​អាក្រក់​ឬ?

ព្រឹត្តិការណ៍សុវត្ថិភាពព័ត៌មានដែលបានរកឃើញអាចត្រូវបានផ្ញើជាទម្រង់សំបុត្រដែលត្រូវគ្នាទៅកាន់ Slack, Cisco Spark, ប្រព័ន្ធគ្រប់គ្រងឧប្បត្តិហេតុ PagerDuty ហើយថែមទាំងផ្ញើទៅកាន់ SIEMs ផ្សេងៗ រួមទាំង Splunk ឬ ELK ផងដែរ។ ដើម្បីសង្ខេប យើងអាចនិយាយបានថា ប្រសិនបើក្រុមហ៊ុនរបស់អ្នកប្រើយុទ្ធសាស្ត្រពហុពពក និងមិនត្រូវបានកំណត់ចំពោះអ្នកផ្តល់សេវាពពកណាមួយទេ សមត្ថភាពត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានដែលបានពិពណ៌នាខាងលើ នោះការប្រើ Cisco Stealthwatch Cloud គឺជាជម្រើសដ៏ល្អមួយក្នុងការទទួលបានសំណុំត្រួតពិនិត្យរួមមួយ។ សមត្ថភាពសម្រាប់អ្នកលេងពពកឈានមុខគេ - Amazon, Microsoft និង Google ។ អ្វីដែលគួរឱ្យចាប់អារម្មណ៍បំផុតនោះគឺថា ប្រសិនបើអ្នកប្រៀបធៀបតម្លៃសម្រាប់ Stealthwatch Cloud ជាមួយនឹងអាជ្ញាប័ណ្ណកម្រិតខ្ពស់សម្រាប់ការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាននៅក្នុង AWS, Azure ឬ GCP វាអាចបង្ហាញថាដំណោះស្រាយ Cisco នឹងមានតម្លៃថោកជាងសមត្ថភាពដែលភ្ជាប់មកជាមួយរបស់ Amazon, Microsoft ។ និងដំណោះស្រាយ Google ។ វា​ជា​ការ​ខុស​គ្នា ប៉ុន្តែ​វា​ជា​ការ​ពិត។ ហើយពពកកាន់តែច្រើន និងសមត្ថភាពរបស់វាដែលអ្នកប្រើ នោះអត្ថប្រយោជន៍នៃដំណោះស្រាយរួមនឹងកាន់តែច្បាស់។

លើសពីនេះទៀត Stealthwatch Cloud អាចត្រួតពិនិត្យពពកឯកជនដែលដាក់ពង្រាយក្នុងស្ថាប័នរបស់អ្នក ឧទាហរណ៍ ដោយផ្អែកលើធុង Kubernetes ឬដោយការត្រួតពិនិត្យលំហូរ Netflow ឬចរាចរបណ្តាញដែលទទួលបានតាមរយៈការឆ្លុះបញ្ចាំងនៅក្នុងឧបករណ៍បណ្តាញ (សូម្បីតែផលិតក្នុងស្រុក) ទិន្នន័យ AD ឬម៉ាស៊ីនមេ DNS ជាដើម។ ទិន្នន័យទាំងអស់នេះនឹងសំបូរទៅដោយព័ត៌មាន Threat Intelligence ដែលប្រមូលបានដោយ Cisco Talos ដែលជាក្រុមអ្នកស្រាវជ្រាវការគំរាមកំហែងផ្នែកសន្តិសុខតាមអ៊ីនធឺណិតដ៏ធំបំផុតរបស់ពិភពលោក។

នេះអនុញ្ញាតឱ្យអ្នកអនុវត្តប្រព័ន្ធត្រួតពិនិត្យរួមសម្រាប់ទាំងពពកសាធារណៈ និងកូនកាត់ ដែលក្រុមហ៊ុនរបស់អ្នកអាចប្រើ។ ព័ត៌មានដែលប្រមូលបានបន្ទាប់មកអាចត្រូវបានវិភាគដោយប្រើសមត្ថភាពដែលភ្ជាប់មកជាមួយរបស់ Stealthwatch Cloud ឬផ្ញើទៅកាន់ SIEM របស់អ្នក (Splunk, ELK, SumoLogic និងមួយចំនួនផ្សេងទៀតត្រូវបានគាំទ្រតាមលំនាំដើម)។

ជាមួយនេះ យើងនឹងបញ្ចប់ផ្នែកដំបូងនៃអត្ថបទ ដែលខ្ញុំបានពិនិត្យមើលឧបករណ៍ដែលភ្ជាប់មកជាមួយ និងខាងក្រៅសម្រាប់ត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មាននៃវេទិកា IaaS/PaaS ដែលអនុញ្ញាតឱ្យយើងរកឃើញ និងឆ្លើយតបយ៉ាងឆាប់រហ័សចំពោះឧប្បត្តិហេតុដែលកើតឡើងនៅក្នុងបរិស្ថានពពកដែល សហគ្រាសរបស់យើងបានជ្រើសរើស។ នៅក្នុងផ្នែកទីពីរ យើងនឹងបន្តប្រធានបទ ហើយពិនិត្យមើលជម្រើសសម្រាប់ការត្រួតពិនិត្យប្រព័ន្ធ SaaS ដោយប្រើឧទាហរណ៍នៃ Salesforce និង Dropbox ហើយយើងក៏នឹងព្យាយាមសង្ខេប និងដាក់អ្វីគ្រប់យ៉ាងរួមគ្នាដោយបង្កើតប្រព័ន្ធត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានរួមសម្រាប់អ្នកផ្តល់សេវាពពកផ្សេងៗគ្នា។

ប្រភព: www.habr.com