ការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវ៖ ហានិភ័យស្ងាត់ៗនៅក្នុង Stack របស់អ្នក

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

ការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវនៃសុវត្ថិភាពនៅតែជាចំណុចខ្សោយមួយក្នុងចំណោមចំណុចខ្សោយដែលត្រូវបានគេមើលរំលងបំផុត ប៉ុន្តែរីករាលដាលយ៉ាងទូលំទូលាយបំផុតនៅក្នុងការអភិវឌ្ឍន៍កម្មវិធីទំនើប។ ប្រសិនបើអ្នកធ្លាប់សួរថា តើការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវនៃសុវត្ថិភាពជាអ្វី ឬបានរំលងវានៅក្នុងផ្នែកការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវនៃសុវត្ថិភាព OWASP នៃបញ្ជីកំពូលទាំង 10 វាដល់ពេលដែលត្រូវពិនិត្យមើលឱ្យកាន់តែច្បាស់។ ពី Kubernetes ដែលបានបង្ហាញ។ dashboardទៅនឹងព័ត៌មានសម្គាល់អ្នកគ្រប់គ្រងលំនាំដើមនៅក្នុងបរិស្ថានពពក ហានិភ័យនេះគឺកើតមានញឹកញាប់ជាងអ្វីដែលអ្នកអភិវឌ្ឍន៍ជាច្រើនបានដឹង។

ទោះបីជាមានកូដរឹងក៏ដោយ សេវាកម្មដែលត្រូវបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវតែមួយ ធុង S3 ដែលអនុញ្ញាតច្រើនពេក ឬរបៀបបំបាត់កំហុសដែលត្រូវបានបំភ្លេចចោលអាចបង្ហាញទិន្នន័យរសើប ឬបើកផ្លូវសម្រាប់អ្នកវាយប្រហារ។ បញ្ហាទាំងនេះមិនមែនគ្រាន់តែជាទ្រឹស្តីនោះទេ ការរំលោភបំពានពិតប្រាកដច្រើនតែកើតចេញពីកំហុសក្នុងការកំណត់រចនាសម្ព័ន្ធជាមូលដ្ឋាននៅក្នុង CI/CD pipelines, Dockerfiles ឬគំរូហេដ្ឋារចនាសម្ព័ន្ធជាកូដ។

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

តើការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវជាអ្វី?

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

ដើម្បីដាក់វាគ្រាន់តែ, តើការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវជាអ្វី? វាជាពេលដែលបរិស្ថានរបស់អ្នកដំណើរការ ប៉ុន្តែវាបើកចំហរសម្រាប់ការរំលោភបំពាន។

ការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាព OWASP មិនត្រឹមត្រូវស្ថិតនៅត្រង់ A05 នៅក្នុង ផ្នែក OWASP កំពូល ១០ហើយសម្រាប់ហេតុផលល្អ។ វាគ្របដណ្តប់លើសេណារីយ៉ូជាច្រើនប្រភេទ ចាប់ពី cloud buckets ដែលត្រូវបានកំណត់ជាសាធារណៈ រហូតដល់បាត់ headers សុវត្ថិភាព រហូតដល់បណ្ណាល័យហួសសម័យដែលមានបន្ទះអ្នកគ្រប់គ្រងបើកចំហ។

អ្វីដែលធ្វើឱ្យវាមានគ្រោះថ្នាក់ជាពិសេសនោះគឺវាងាយស្រួលមើលរំលងណាស់។ អ្នកអភិវឌ្ឍន៍ផ្តោតលើការសរសេរកូដដែលមានសុវត្ថិភាព ប៉ុន្តែជារឿយៗភ្លេចថាឯកសារកំណត់រចនាសម្ព័ន្ធ CI/CD អថេរ ការអនុញ្ញាតកុងតឺន័រ និងច្រកដែលបង្ហាញគឺមានសារៈសំខាន់ដូចគ្នា។

នេះគឺជាឧទាហរណ៍មួយចំនួននៃពិភពពិត៖

ធុង AWS S3 អាចចូលប្រើបានជាសាធារណៈដោយមិនចាំបាច់ផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ
Kubernetes dashboard អាចទាក់ទងបានតាមរយៈអ៊ីនធឺណិតដោយមិនចាំបាច់ login
Jenkins បានកំណត់រចនាសម្ព័ន្ធជាមួយពាក្យសម្ងាត់លំនាំដើម
ទំព័រកំហុសលម្អិតនៅក្នុងផលិតកម្មបង្ហាញដានជង់

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

ហេតុអ្វីបានជាការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវគឺជាភាពងាយរងគ្រោះពិតប្រាកដ

នៅពេលមើលដំបូង ការកំណត់រចនាសម្ព័ន្ធខុសបន្តិចបន្តួចអាចហាក់ដូចជាមិនមែនជាការគំរាមកំហែងនោះទេ។ ទោះជាយ៉ាងណាក៏ដោយ ភាពងាយរងគ្រោះនៃការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវ អាចក្លាយជាការវាយប្រហារពេញលេញយ៉ាងឆាប់រហ័ស ជាពិសេសនៅក្នុងបរិស្ថានដែលមានមូលដ្ឋានលើ cloud និង containerized ដែលសេវាកម្មនានាត្រូវបានភ្ជាប់គ្នាទៅវិញទៅមក។

អ្នកវាយប្រហារច្រើនតែស្កេនរក៖

បើកច្រកដែលបង្ហាញឧបករណ៍អភិវឌ្ឍន៍ដូចជា Kibana ឬ Jenkins
បឋមកថាដែលត្រូវបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវដែលអនុញ្ញាតឱ្យមានការសរសេរស្គ្រីបឆ្លងគេហទំព័រ (XSS)
ទ្រព្យសកម្មពពកសាធារណៈ (ឧ. S3, GCS) កំណត់ទៅ "អាន/សរសេរ" សម្រាប់អ្នកណាម្នាក់
លក្ខិណា .git ថតឯកសារ ឬបង្ហាញ .env ឯកសារនៅក្នុងគម្រោង GitHub

លើសពីនេះ ពួកគេមិនចាំបាច់កេងប្រវ័ញ្ចតក្កវិជ្ជាកម្មវិធីរបស់អ្នកទេ។ ផ្ទុយទៅវិញ ពួកគេពឹងផ្អែកលើលំនាំដើមរបស់អ្នក ទង់ដែលអ្នកភ្លេច ឬបន្ទះអ្នកគ្រប់គ្រងដែលមិនទាន់បានជួសជុលរបស់អ្នក។

របាយការណ៍ឆ្នាំ ២០១៣ ក្រុមហ៊ុន IBM X-Force រកឃើញថា ការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវបានបណ្តាលឱ្យមាន 25% នៃឧប្បត្តិហេតុសុវត្ថិភាព cloud ទាំងអស់ដែលធ្វើឱ្យពួកវាក្លាយជាប្រភេទគំរាមកំហែងលើពពកទូទៅបំផុតទីពីរ នៅពីក្រោយការគ្រប់គ្រងអត្តសញ្ញាណមិនបានល្អ។

ចូរយើងវិភាគរឿងនេះដោយសង្ខេប៖

ការកំណត់	មិនមានសុវត្ថិភាពតាមលំនាំដើម	ការកំណត់រចនាសម្ព័ន្ធរឹង
ផ្ទាំងគ្រប់គ្រង	បានបើកដំណើរការដោយគ្មាន login	បានផ្ទៀងផ្ទាត់ និងដាក់កម្រិត IP
ធុង S3	ការចូលប្រើជាសាធារណៈ	ឯកជនជាមួយច្បាប់ IAM
Dockerfile	ប្រើអ្នកប្រើប្រាស់ជា root	ដំណើរការជាមិនមែនជា root
Jenkins	កំណត់អត្តសញ្ញាណលំនាំដើម	RBAC និងថូខឹនដែលបានអនុវត្ត

ដោយសារតែបញ្ហាទាំងនេះច្រើនតែមិនត្រូវបានរកឃើញក្នុងអំឡុងពេលធ្វើតេស្តធម្មតា ពួកវាក្លាយជាផ្នែកមួយនៃផ្ទៃវាយប្រហារ ដោយអង្គុយស្ងៀមស្ងាត់នៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នករហូតដល់មាននរណាម្នាក់រកឃើញវា។ នោះហើយជាមូលហេតុដែលការព្យាបាល ការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវ ដូចជាភាពងាយរងគ្រោះពិតប្រាកដមួយគឺចាំបាច់សម្រាប់ក្រុម DevOps និង AppSec ទំនើបៗ។

ឧទាហរណ៍នៃភាពងាយរងគ្រោះនៃការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវ អ្នកអភិវឌ្ឍន៍ច្រើនតែខកខាន

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

ការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវនៅក្នុងកុងតឺន័រ និងឯកសារ Docker

កំពុងដំណើរការជា root ជំនួសឲ្យអ្នកប្រើប្រាស់ដែលមិនមានសិទ្ធិ
ការបង្ហាញពីច្រកខាងក្នុងនៅក្នុង Dockerfile or docker-compose.yml
ការទុកចំណុចបញ្ចប់នៃការត្រួតពិនិត្យសុខភាពមិនត្រូវបានការពារ

ចំណុចខ្សោយនៃការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាព Cloud មិនត្រឹមត្រូវនៅក្នុងការផ្ទុក និងហេដ្ឋារចនាសម្ព័ន្ធ

S3 ធុង ជាមួយការអនុញ្ញាត "អានជាសាធារណៈ" ឬ "សរសេរជាសាធារណៈ"
ធុង GCP ឬ Azure blobs ត្រូវបានលាតត្រដាងតាមរយៈ IAM ដែលត្រូវបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ
Terraform ឯកសារដែលខ្វះការរឹតបន្តឹងការចូលប្រើ ឬការអ៊ិនគ្រីប

CI/CD pipeline បញ្ហាដែលបណ្តាលមកពីការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវ

ជេនឃីន ឬ GitLab CI ដែលមានការចូលប្រើអនាមិកត្រូវបានបើក
អាថ៌កំបាំងត្រូវបានរក្សាទុកជាអត្ថបទធម្មតានៅក្នុង pipeline លាក់ទុក។
របាយការណ៍គ្របដណ្តប់ការធ្វើតេស្ត ឬម៉ាស៊ីនស្កេនកូដដែលបង្ហាញផ្លូវខាងក្នុង

ឧទាហរណ៍ទូទៅនៃការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពកម្មវិធីគេហទំព័រមិនត្រឹមត្រូវ

របៀបកែកំហុសត្រូវបានបើកនៅក្នុង Flask, Djangoឬ អ៊ិចស្ព្រេស
សារកំហុសលម្អិតៗដែលបង្ហាញពីដានជង់ ឬព័ត៌មានលម្អិតអំពីបរិស្ថាន
បាត់បឋមកថាសុវត្ថិភាព HTTP (X-Content-Type-Options, Strict-Transport-Securityល។ )

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

ប្រសិនបើវាអាចចូលប្រើបាន និងត្រូវបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ វាងាយរងគ្រោះ។

របៀបការពារភាពងាយរងគ្រោះនៃការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវនៅក្នុង DevOps

ការបង្ការ ការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវ មិនមែននិយាយអំពីការបន្ថែមឧបករណ៍ថ្មីនោះទេ។ វានិយាយអំពីការធ្វើឱ្យការកំណត់រចនាសម្ព័ន្ធដែលមានសុវត្ថិភាពជាលំនាំដើមនៅក្នុងគ្រប់បរិស្ថានទាំងអស់ ចាប់ពីការអភិវឌ្ឍន៍រហូតដល់ផលិតកម្ម។ ខាងក្រោមនេះជារបៀប៖

១. Harden ខកខានការបង់រំលស់មុនកាលកំណត់

ចាប់ផ្តើមជាមួយការកំណត់សុវត្ថិភាពនៅក្នុង Dockerfiles, Helm charts និង Terraform scripts របស់អ្នក។ ជៀសវាងការបង្ហាញសេវាកម្មនៅលើ 0.0.0.0 លុះត្រាតែចាំបាច់បំផុត។ លុបព័ត៌មានសម្គាល់គំរូ អាថ៌កំបាំងកន្លែងដាក់ និងផ្លូវសាកល្បងមុនពេលចុចកូដ។

២. ការចូលប្រើប្រាស់ដោយចាក់សោរ

តែងតែអនុវត្តការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ និងការគ្រប់គ្រងការចូលប្រើផ្អែកលើតួនាទី (RBAC)។ ប្រសិនបើឧបករណ៍ CI ឬអ្នកគ្រប់គ្រងរបស់អ្នក dashboard មិនចាំបាច់ប៉ះពាល់នឹងអ៊ីនធឺណិតទេ ដាក់កម្រិតការចូលប្រើតាមរយៈបញ្ជីអនុញ្ញាត IP ឬ VPN។

៣. ស្កេនឯកសារកំណត់រចនាសម្ព័ន្ធដោយស្វ័យប្រវត្តិ

ប្រើឧបករណ៍ដែលអាចវិភាគបាន IaC - ហេដ្ឋារចនាសម្ព័ន្ធជាក្រម, តារាង Helm និង Dockerfiles ក្នុងអំឡុងពេល pull requestsការវិភាគឋិតិវន្តនៃការកំណត់រចនាសម្ព័ន្ធរបស់អ្នកគឺមានសារៈសំខាន់ដូចគ្នានឹងការស្កេនកូដកម្មវិធីរបស់អ្នកដែរ។

៤. គ្រប់គ្រងអាថ៌កំបាំងដោយសុវត្ថិភាព

រក្សាទុកព័ត៌មានសម្ងាត់នៅក្នុងកម្មវិធីគ្រប់គ្រងការសម្ងាត់ មិនមែននៅក្នុងកូដ ឬឯកសារបរិស្ថានរបស់អ្នកទេ។ លើសពីនេះ សូមប្តូរការសម្ងាត់ជាប្រចាំ និងធ្វើសវនកម្មកំណត់ហេតុចូលប្រើ ដើម្បីរកឃើញការរំលោភបំពាន។

៥. ផ្ទៀងផ្ទាត់ទល់នឹងស្តង់ដារ

ប្រើស្តង់ដារដូចជា CIS, NIST, និង OpenSSF កាតពិន្ទុដើម្បីពិនិត្យមើលគម្រោងរបស់អ្នក និង pipelines សម្រាប់ចំណុចខ្វះខាតទូទៅនៃការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ។

៦. ស្វ័យប្រវត្តិកម្មជាមួយ Guardrails

ជំនួសឲ្យការពឹងផ្អែកលើការពិនិត្យដោយដៃ សូមអនុវត្តការកំណត់រចនាសម្ព័ន្ធដែលមានសុវត្ថិភាពតាមរយៈការធ្វើស្វ័យប្រវត្តិ CI/CD guardrailsឧទាហរណ៍ ការបង្កើតបរាជ័យនៅពេលដែលធនធានពពកសាធារណៈមិនបំពេញតាមគោលការណ៍របស់អ្នក។

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

ប្រើ Xygeni ដើម្បីទប់ស្កាត់ការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវនៅក្នុង CI/CD Pipelines

ការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវគឺជាចំណុចខ្សោយមួយក្នុងចំណោមចំណុចខ្សោយទូទៅបំផុត ដែលត្រូវបានមើលរំលង ប៉ុន្តែ Xygeni ប្រែក្លាយវាទៅជាអ្វីមួយដែលអ្នកអាចរកឃើញ ជួសជុល និងការពារដោយស្វ័យប្រវត្តិ។

នេះជារបៀបដែល Xygeni ជួយក្រុម DevOps បញ្ឈប់ការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវមុនពេលពួកគេឈានដល់ផលិតកម្ម៖

1. IaC Security ការស្កេនក្នុងពេលវេលាជាក់ស្តែង

ការស្កេន Xygeni ឯកសារ Terraform, Helm, Kubernetes និង Docker របស់អ្នកនៅលើគ្រប់ commit និង pull requestវាបង្ហាញពីការកំណត់រចនាសម្ព័ន្ធដែលមានហានិភ័យដូចជា៖

រន្ធដែលលាតត្រដាង ឬការភ្ជាប់ 0.0.0.0
ខ្វះការអនុញ្ញាតផ្អែកលើតួនាទី
បាត់ការបែងចែកបណ្តាញ ឬការអ៊ិនគ្រីប

2. CI/CD Guardrails ដើម្បីរារាំងការបង្កើតដែលត្រូវបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ

ប្រសិនបើរបស់អ្នក pipeline លាតត្រដាងអាថ៌កំបាំង ប្រើប្រាស់ព័ត៌មានសម្គាល់លំនាំដើម ឬទុកឯកសារសំខាន់ៗឱ្យបើកចំហ Xygeni អាចរារាំងការបង្កើតដោយស្វ័យប្រវត្តិ។ អ្នកកំណត់ច្បាប់ យើងនឹងអនុវត្តវា។

៣. ការរកឃើញការរសាត់នៃការកំណត់រចនាសម្ព័ន្ធ

Xygeni ត្រួតពិនិត្យបរិស្ថានរបស់អ្នកសម្រាប់ការផ្លាស់ប្តូរដែលគ្មានការអនុញ្ញាត។ ប្រសិនបើធុងផ្ទុកទិន្នន័យភ្លាមៗក្លាយជាសាធារណៈ ឬទង់បំបាត់កំហុសត្រូវបានបើកដំណើរការឡើងវិញ អ្នកនឹងដឹងមុនពេលវាក្លាយជាឧប្បត្តិហេតុ។

៤. គោលការណ៍ជាកូដសម្រាប់លំនាំដើមដែលមានសុវត្ថិភាព

ដំបូងឡើយ សូមប្រើ Xygeni's guardrails ដើម្បីកំណត់ឱ្យច្បាស់នូវអត្ថន័យនៃ "សុវត្ថិភាពតាមលំនាំដើម" សម្រាប់ក្រុមរបស់អ្នក។ ជាលទ្ធផល អ្នកអាចរារាំងការរួមបញ្ចូលគ្នាដែលមានហានិភ័យ ជូនដំណឹងអំពីការរំលោភលើគោលការណ៍ និងរក្សាការអនុលោមតាម ទាំងអស់នេះដោយមិនចាំបាច់សរសេរស្គ្រីបផ្ទាល់ខ្លួន។

៥. ការរួមបញ្ចូលការគ្រប់គ្រងអាថ៌កំបាំង

លើសពីនេះ Xygeni រកឃើញអាថ៌កំបាំងដែលបានអ៊ិនកូដរឹង ថូខឹនដែលលេចធ្លាយ ឬឯកសារយោងដែលមិនមានសុវត្ថិភាពនៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធ CI របស់អ្នក។ វាក៏រួមបញ្ចូលយ៉ាងរលូនជាមួយ Vaults និង KMS ដើម្បីផ្ទៀងផ្ទាត់ និងជួសជុលព័ត៌មានសម្ងាត់ណាមួយដែលលាតត្រដាង។

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

ត្រៀមខ្លួនរួចរាល់ហើយឬនៅដើម្បីបញ្ឈប់ការកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវនៅប្រភព?
សាកល្បង Xygeni ដោយឥតគិតថ្លៃរយៈពេល 14 ថ្ងៃ ហើយមើលថាតើវាងាយស្រួលប៉ុណ្ណាក្នុងការរារាំងអ្វីដែលអ្នកដទៃខកខាន។