ការភ័យខ្លាច និងការស្អប់ខ្ពើមចំពោះ DevSecOps

យើងមានឧបករណ៍វិភាគកូដចំនួន 2 ឧបករណ៍សាកល្បងថាមវន្តចំនួន 4 សិប្បកម្មផ្ទាល់ខ្លួនរបស់យើង និងស្គ្រីបចំនួន 250 ។ វាមិនមែនថាអ្វីៗទាំងអស់នេះគឺចាំបាច់នៅក្នុងដំណើរការបច្ចុប្បន្ននោះទេ ប៉ុន្តែនៅពេលដែលអ្នកចាប់ផ្តើមអនុវត្ត DevSecOps អ្នកត្រូវតែទៅទីបញ្ចប់។

ប្រភព. អ្នកបង្កើតតួអង្គ៖ Justin Roiland និង Dan Harmon ។

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

អំពីអ្នកនិយាយ៖ Yuri Shabalin - ប្រធានស្ថាបត្យករសន្តិសុខនៅក្នុងក្រុមហ៊ុន សន្តិសុខដាវ. ទទួលខុសត្រូវចំពោះការអនុវត្ត SSDL សម្រាប់ការរួមបញ្ចូលជារួមនៃឧបករណ៍វិភាគកម្មវិធីទៅក្នុងប្រព័ន្ធអេកូឡូស៊ីនៃការអភិវឌ្ឍន៍ និងការសាកល្បង។ មានបទពិសោធន៍ ៧ឆ្នាំ ផ្នែកសន្តិសុខព័ត៌មាន។ បានធ្វើការនៅ Alfa-Bank, Sberbank និង Positive Technologies ដែលបង្កើតកម្មវិធី និងផ្តល់សេវាកម្ម។ វាគ្មិននៅក្នុងសន្និសីទអន្តរជាតិ ZerONnights, PHDays, RISSPA, OWASP ។

សុវត្ថិភាពកម្មវិធី៖ តើវានិយាយអំពីអ្វី?

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

ទិស SDL ឬ SDLC - វដ្តនៃការអភិវឌ្ឍន៍សុវត្ថិភាព - បង្កើតឡើងដោយក្រុមហ៊ុន Microsoft ។ ដ្យាក្រាមបង្ហាញគំរូ Canonical SDLC ដែលជាភារកិច្ចចម្បងគឺការចូលរួមសន្តិសុខនៅគ្រប់ដំណាក់កាលនៃការអភិវឌ្ឍន៍ ចាប់ពីតម្រូវការរហូតដល់ការចេញផ្សាយ និងការផលិត។ ក្រុមហ៊ុន Microsoft បានដឹងថាមានកំហុសច្រើនពេកនៅក្នុងឧស្សាហកម្មនេះ វាមានច្រើនទៀត និងអ្វីមួយដែលត្រូវធ្វើអំពីវា ហើយពួកគេបានស្នើរវិធីសាស្រ្តនេះ ដែលបានក្លាយជា Canonical ។

សុវត្ថិភាពកម្មវិធី និង SSDL មិនមានគោលបំណងស្វែងរកភាពងាយរងគ្រោះ ដូចដែលត្រូវបានគេជឿជាទូទៅនោះទេ ប៉ុន្តែដើម្បីការពារការកើតឡើងរបស់វា។ យូរៗទៅ វិធីសាស្រ្ត Canonical របស់ Microsoft ត្រូវបានកែលម្អ បង្កើត និងណែនាំឱ្យកាន់តែស៊ីជម្រៅ និងលម្អិតបន្ថែមទៀត។

Canonical SDLC ត្រូវបានលម្អិតយ៉ាងខ្លាំងនៅក្នុងវិធីសាស្រ្តផ្សេងៗ - OpenSAMM, BSIMM, OWASP ។ វិធីសាស្រ្តគឺខុសគ្នា ប៉ុន្តែជាទូទៅស្រដៀងគ្នា។

ការកសាងសុវត្ថិភាពនៅក្នុងគំរូនៃភាពចាស់ទុំ

ខ្ញុំចូលចិត្តវាជាងគេ BSIMM - ការកសាងសុវត្ថិភាពនៅក្នុងគំរូនៃភាពចាស់ទុំ. មូលដ្ឋាននៃវិធីសាស្រ្តគឺការបែងចែកនៃដំណើរការសុវត្ថិភាពកម្មវិធីទៅជា 4 domains: អភិបាលកិច្ច, Intelligence, SSDL Touchpoints និងការដាក់ពង្រាយ។ ដែននីមួយៗមានការអនុវត្តចំនួន 12 ដែលត្រូវបានតំណាងថាជា 112 សកម្មភាព។

សកម្មភាពនីមួយៗមាន 112 3 កម្រិតនៃភាពចាស់ទុំ៖ ចាប់ផ្តើម មធ្យម និងកម្រិតខ្ពស់។ អ្នកអាចសិក្សាផ្នែកអនុវត្តន៍ទាំង 12 ដោយផ្នែក ជ្រើសរើសអ្វីដែលសំខាន់សម្រាប់អ្នក ស្វែងយល់ពីរបៀបអនុវត្តពួកវា ហើយបន្ថែមធាតុបន្តិចម្តងៗ ឧទាហរណ៍ ការវិភាគកូដឋិតិវន្ត និងថាមវន្ត ឬការពិនិត្យកូដ។ អ្នកសរសេរផែនការមួយ ហើយធ្វើការដោយស្ងប់ស្ងាត់ទៅតាមវា ជាផ្នែកនៃការអនុវត្តសកម្មភាពដែលបានជ្រើសរើស។

ហេតុអ្វីបានជា DevSecOps

DevOps គឺជាដំណើរការទូទៅដែលមានទំហំធំ ដែលសុវត្ថិភាពត្រូវតែយកមកពិចារណា។

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

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

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

ការផ្លាស់ប្តូរទៅ DevSecOps

ពាក្យសំខាន់បំផុតនៅក្នុងវដ្តនៃការអភិវឌ្ឍន៍សុវត្ថិភាពគឺ "ដំណើរការ". អ្នក​ត្រូវ​យល់​ពី​ចំណុច​នេះ​មុន​ពេល​អ្នក​គិត​អំពី​ការ​ទិញ​ឧបករណ៍។

គ្រាន់តែបញ្ចូលឧបករណ៍ទៅក្នុងដំណើរការ DevOps គឺមិនគ្រប់គ្រាន់ទេ ទំនាក់ទំនង និងការយល់ដឹងរវាងអ្នកចូលរួមដំណើរការគឺមានសារៈសំខាន់។

មនុស្សសំខាន់ជាង មិនមែនឧបករណ៍ទេ។

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

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

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

ចាប់ផ្តើមជាមួយនឹងអ្វីដែលកំពុងប្រើ

មុនពេលទិញឧបករណ៍ថ្លៃ ៗ សូមក្រឡេកមើលអ្វីដែលអ្នកមានរួចហើយ។ ក្រុមហ៊ុននីមួយៗមានតម្រូវការសុវត្ថិភាពសម្រាប់ការអភិវឌ្ឍន៍ មានការត្រួតពិនិត្យ ការត្រួតពិនិត្យ - ហេតុអ្វីមិនបំប្លែងទាំងអស់នេះទៅជាទម្រង់ដែលអាចយល់បាន និងងាយស្រួលសម្រាប់មនុស្សគ្រប់គ្នា?

ជាធម្មតាតម្រូវការគឺក្រដាស Talmud ដែលស្ថិតនៅលើធ្នើ។ មាន​ករណី​មួយ​ពេល​យើង​មក​ក្រុមហ៊ុន​មួយ​ដើម្បី​មើល​ដំណើរ​ការ ហើយ​សុំ​មើល​តម្រូវការ​សុវត្ថិភាព​សម្រាប់​កម្មវិធី។ អ្នកឯកទេសដែលដោះស្រាយបញ្ហានេះបានចំណាយពេលយូរដើម្បីស្វែងរក៖

- ឥឡូវនេះ កន្លែងណាមួយក្នុងកំណត់ត្រាមានផ្លូវមួយដែលឯកសារនេះស្ថិតនៅ។

ជាលទ្ធផល យើងបានទទួលឯកសារមួយសប្តាហ៍ក្រោយមក។

សម្រាប់តម្រូវការ ការត្រួតពិនិត្យ និងរបស់ផ្សេងទៀត បង្កើតទំព័រមួយនៅលើ ឧ. Confluence - វាងាយស្រួលសម្រាប់មនុស្សគ្រប់គ្នា។

វាកាន់តែងាយស្រួលក្នុងការធ្វើកំណែទម្រង់អ្វីដែលអ្នកមានរួចហើយ ហើយប្រើវាដើម្បីចាប់ផ្តើម។

ប្រើជើងឯកសុវត្ថិភាព

ជាធម្មតានៅក្នុងក្រុមហ៊ុនជាមធ្យមដែលមានអ្នកអភិវឌ្ឍន៍ពី 100-200 នាក់ មានអ្នកឯកទេសសន្តិសុខម្នាក់ដែលអនុវត្តមុខងារជាច្រើន ហើយមិនមានពេលវេលាដើម្បីត្រួតពិនិត្យអ្វីៗទាំងអស់។ ទោះបីជាគាត់ព្យាយាមអស់ពីសមត្ថភាពក៏ដោយ គាត់តែម្នាក់ឯងនឹងមិនពិនិត្យមើលកូដទាំងអស់ដែលការអភិវឌ្ឍន៍បង្កើតនោះទេ។ ចំពោះករណីបែបនេះ គំនិតមួយត្រូវបានបង្កើតឡើង - ជើងឯកសន្តិសុខ.

Security Champions គឺជាមនុស្សនៅក្នុងក្រុមអភិវឌ្ឍន៍ដែលចាប់អារម្មណ៍លើសុវត្ថិភាពនៃផលិតផលរបស់អ្នក។

ជើងឯកសុវត្ថិភាពគឺជាចំណុចចូលទៅក្នុងក្រុមអភិវឌ្ឍន៍ ហើយអ្នកផ្សាយដំណឹងល្អផ្នែកសុវត្ថិភាពត្រូវបានបញ្ចូលទៅក្នុងមួយ។

ជាធម្មតា នៅពេលដែលអ្នកឯកទេសសុវត្ថិភាពមកក្រុមអភិវឌ្ឍន៍ ហើយចង្អុលបង្ហាញពីកំហុសនៅក្នុងកូដ គាត់ទទួលបានចម្លើយដ៏គួរឱ្យភ្ញាក់ផ្អើលមួយ៖

- ហើយ​តើ​អ្នក​ជា​នរណា? ខ្ញុំកំពុងជួបអ្នកជាលើកដំបូង។ អ្វីគ្រប់យ៉ាងគឺល្អជាមួយខ្ញុំ - មិត្តចាស់របស់ខ្ញុំបានឱ្យខ្ញុំ "អនុវត្ត" លើការពិនិត្យលេខកូដ យើងបន្តទៅមុខទៀត!

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

ដូចគ្នានេះផងដែរ អ្នកអភិវឌ្ឍន៍ដឹងពីកូដរបស់ពួកគេប្រសើរជាងអ្នកឯកទេសសុវត្ថិភាពណាមួយ។ សម្រាប់មនុស្សម្នាក់ដែលមានយ៉ាងហោចណាស់ 5 គម្រោងនៅក្នុងឧបករណ៍វិភាគឋិតិវន្ត ជាធម្មតាវាពិបាកក្នុងការចងចាំរាល់ការ nuances ទាំងអស់។ Security Champions ស្គាល់ផលិតផលរបស់ពួកគេ៖ អន្តរកម្មជាមួយអ្វី និងអ្វីដែលត្រូវមើលដំបូង - ពួកគេមានប្រសិទ្ធភាពជាង។

ដូច្នេះ សូមពិចារណាអនុវត្ត Security Champions និងពង្រីកឥទ្ធិពលនៃក្រុមសន្តិសុខរបស់អ្នក។ នេះក៏មានប្រយោជន៍សម្រាប់ម្ចាស់ជើងឯកខ្លួនឯងផងដែរ៖ ការអភិវឌ្ឍន៍វិជ្ជាជីវៈក្នុងវិស័យថ្មីមួយ ពង្រីកការយល់ដឹងបច្ចេកទេសរបស់គាត់ ធ្វើឱ្យប្រសើរឡើងនូវជំនាញបច្ចេកទេស ការគ្រប់គ្រង និងអ្នកដឹកនាំ ការបង្កើនតម្លៃទីផ្សារ។ នេះគឺជាធាតុមួយចំនួននៃវិស្វកម្មសង្គម "ភ្នែក" របស់អ្នកនៅក្នុងក្រុមអភិវឌ្ឍន៍។

ដំណាក់កាលសាកល្បង

គំរូ 20 ដល់ 80 និយាយថា 20% នៃកិច្ចខិតខំប្រឹងប្រែងបង្កើតបាន 80% នៃលទ្ធផល។ 20% នេះគឺជាការអនុវត្តការវិភាគកម្មវិធីដែលអាច និងគួរតែដោយស្វ័យប្រវត្តិ។ ឧទាហរណ៍នៃសកម្មភាពបែបនេះគឺការវិភាគឋិតិវន្ត - SAST, ការវិភាគថាមវន្ត - DAST и ការគ្រប់គ្រងប្រភពបើកចំហ. ខ្ញុំនឹងប្រាប់អ្នកឱ្យកាន់តែលម្អិតអំពីសកម្មភាព ក៏ដូចជាអំពីឧបករណ៍ លក្ខណៈពិសេសអ្វីខ្លះដែលយើងជួបប្រទះនៅពេលណែនាំពួកវាទៅក្នុងដំណើរការ និងរបៀបធ្វើវាឱ្យត្រឹមត្រូវ។

បញ្ហាចម្បងនៃឧបករណ៍

ខ្ញុំនឹងគូសបញ្ជាក់ពីបញ្ហាដែលពាក់ព័ន្ធសម្រាប់ឧបករណ៍ទាំងអស់ ហើយទាមទារឱ្យមានការយកចិត្តទុកដាក់។ ខ្ញុំ​នឹង​វិភាគ​វា​ឱ្យ​បាន​លម្អិត​បន្ថែម​ទៀត ដើម្បី​កុំ​ឱ្យ​ពួក​វា​បន្ត​ទៀត ។

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

កម្រិតខ្ពស់ អវិជ្ជមានមិនពិត ឬវិជ្ជមានក្លែងក្លាយ។ ផលិតផលទាំងអស់គឺខុសគ្នា ទាំងអស់ប្រើក្របខ័ណ្ឌផ្សេងគ្នា និងរចនាប័ទ្មសរសេរកូដផ្ទាល់ខ្លួនរបស់ពួកគេ។ នៅលើមូលដ្ឋានកូដ និងបច្ចេកវិទ្យាផ្សេងៗគ្នា ឧបករណ៍អាចបង្ហាញកម្រិតផ្សេងគ្នានៃ False Negative និង False Positive។ ដូច្នេះសូមក្រឡេកមើលអ្វីដែលពិតប្រាកដ នៃរបស់អ្នក ក្រុមហ៊ុន និងសម្រាប់ របស់អ្នក កម្មវិធីនឹងបង្ហាញលទ្ធផលល្អ និងអាចទុកចិត្តបាន។

គ្មានការរួមបញ្ចូលជាមួយឧបករណ៍ដែលមានស្រាប់. សូមក្រឡេកមើលឧបករណ៍នៅក្នុងលក្ខខណ្ឌនៃការរួមបញ្ចូលជាមួយនឹងអ្វីដែលអ្នកបានប្រើរួចហើយ។ ឧទាហរណ៍ ប្រសិនបើអ្នកមាន Jenkins ឬ TeamCity សូមពិនិត្យមើលការរួមបញ្ចូលឧបករណ៍ជាមួយកម្មវិធីនេះ មិនមែនជាមួយ GitLab CI ដែលអ្នកមិនប្រើនោះទេ។

កង្វះឬភាពស្មុគស្មាញហួសប្រមាណនៃការប្ដូរតាមបំណង។ ប្រសិនបើឧបករណ៍មិនមាន API នោះហេតុអ្វីបានជាវាត្រូវការ? អ្វីគ្រប់យ៉ាងដែលអាចធ្វើបាននៅក្នុងចំណុចប្រទាក់គួរតែមានតាមរយៈ API ។ តាមឧត្ដមគតិ ឧបករណ៍គួរតែមានសមត្ថភាពក្នុងការកំណត់ការត្រួតពិនិត្យតាមបំណង។

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

លក្ខណៈពិសេសនៃដំណើរការ

បន្ថែមពីលើលក្ខណៈពិសេសនៃឧបករណ៍យកទៅក្នុងគណនីលក្ខណៈពិសេសនៃដំណើរការអភិវឌ្ឍន៍។ ជាឧទាហរណ៍ ការរារាំងការអភិវឌ្ឍន៍គឺជាកំហុសទូទៅ។ សូមក្រឡេកមើលថាតើលក្ខណៈពិសេសផ្សេងទៀតគួរត្រូវបានយកមកពិចារណា និងអ្វីដែលក្រុមសន្តិសុខគួរតែយកចិត្តទុកដាក់។

ដើម្បីកុំឱ្យខកខានការអភិវឌ្ឍន៍ និងកាលបរិច្ឆេទកំណត់ សូមបង្កើត ច្បាប់ផ្សេងគ្នា និងខុសគ្នា បង្ហាញការបញ្ឈប់ - លក្ខណៈវិនិច្ឆ័យសម្រាប់ការបញ្ឈប់ដំណើរការបង្កើតនៅក្នុងវត្តមាននៃភាពងាយរងគ្រោះ - សម្រាប់បរិស្ថានផ្សេងៗគ្នា. ជាឧទាហរណ៍ យើងយល់ថាសាខាបច្ចុប្បន្នទៅកន្លែងអភិវឌ្ឍន៍ ឬ UAT ដែលមានន័យថាយើងមិនឈប់ ហើយនិយាយថា៖

"អ្នកមានភាពងាយរងគ្រោះនៅទីនេះ អ្នកនឹងមិនទៅណាទៀតទេ!"

នៅចំណុចនេះ វាមានសារៈសំខាន់ណាស់ក្នុងការប្រាប់អ្នកអភិវឌ្ឍន៍ថាមានបញ្ហាសុវត្ថិភាពដែលត្រូវការការយកចិត្តទុកដាក់។

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

- បុរសអ្នកមានបញ្ហាសូមយកចិត្តទុកដាក់ចំពោះពួកគេ។

នៅដំណាក់កាល UAT យើងបង្ហាញការព្រមានម្តងទៀតអំពីភាពងាយរងគ្រោះ ហើយនៅដំណាក់កាលចេញផ្សាយ យើងនិយាយថា៖

- បុរស យើង​បាន​ព្រមាន​អ្នក​ជា​ច្រើន​ដង អ្នក​មិន​បាន​ធ្វើ​អ្វី​ទេ យើង​នឹង​មិន​អនុញ្ញាត​ឱ្យ​អ្នក​ចេញ​ជាមួយ​នឹង​ការ​នេះ​។

ប្រសិនបើយើងនិយាយអំពីកូដ និងឌីណាមិក នោះចាំបាច់ត្រូវបង្ហាញ និងព្រមានអំពីភាពងាយរងគ្រោះនៃលក្ខណៈពិសេស និងកូដទាំងនោះដែលទើបតែត្រូវបានសរសេរនៅក្នុងលក្ខណៈពិសេសនេះ។ ប្រសិនបើអ្នកអភិវឌ្ឍន៍ផ្លាស់ទីប៊ូតុងមួយដោយ 3 ភីកសែល ហើយយើងប្រាប់គាត់ថាគាត់មានការចាក់ SQL នៅទីនោះ ដូច្នេះហើយចាំបាច់ត្រូវជួសជុលជាបន្ទាន់ វាខុសហើយ។ សូមក្រឡេកមើលតែអ្វីដែលត្រូវបានសរសេរឥឡូវនេះ និងការផ្លាស់ប្តូរដែលមកលើកម្មវិធី។

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

មិនមែនបញ្ហាគុណភាពកម្មវិធីទាំងអស់សុទ្ធតែជាបញ្ហាសុវត្ថិភាពនោះទេ។ ប៉ុន្តែបញ្ហាសុវត្ថិភាពទាំងអស់គឺទាក់ទងទៅនឹងគុណភាពកម្មវិធី។ Sherif Mansour, Expedia ។

ដោយសារភាពងាយរងគ្រោះទាំងអស់គឺជាពិការភាពដូចគ្នា ពួកវាគួរតែស្ថិតនៅកន្លែងតែមួយជាមួយនឹងពិការភាពនៃការអភិវឌ្ឍន៍ទាំងអស់។ ដូច្នេះភ្លេចអំពីរបាយការណ៍ និង PDF ដ៏គួរឱ្យខ្លាចដែលគ្មាននរណាម្នាក់អាន។

នៅពេលខ្ញុំធ្វើការនៅក្រុមហ៊ុនអភិវឌ្ឍន៍ ខ្ញុំបានទទួលរបាយការណ៍ពីឧបករណ៍វិភាគឋិតិវន្ត។ ខ្ញុំបើកវា រន្ធត់ចិត្ត ធ្វើកាហ្វេ ស្លឹកឈើ 350 ទំព័រ បិទវា ហើយបន្តការងារទៀត។ របាយការណ៍ធំគឺជារបាយការណ៍ស្លាប់. ជាធម្មតាពួកគេមិនទៅណាទេ អក្សរត្រូវបានលុប ភ្លេច បាត់ ឬអាជីវកម្មនិយាយថាវាទទួលយកហានិភ័យ។

អ្វី​ដែល​ត្រូវធ្វើ? យើងគ្រាន់តែបំប្លែងពិការភាពដែលបានបញ្ជាក់ដែលយើងបានរកឃើញទៅជាទម្រង់ដែលងាយស្រួលសម្រាប់ការអភិវឌ្ឍន៍ ឧទាហរណ៍ យើងដាក់ពួកវានៅក្នុងកំណត់ហេតុក្នុង Jira ។ យើងកំណត់អាទិភាពពិការភាព និងលុបបំបាត់ពួកវាតាមលំដាប់លំដោយជាអាទិភាព រួមជាមួយនឹងពិការភាពមុខងារ និងពិការភាពសាកល្បង។

ការវិភាគឋិតិវន្ត - SAST

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

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

Минусы - នេះគឺជាកង្វះការគាំទ្រសម្រាប់ភាសាចាំបាច់។

ការរួមបញ្ចូលចាំបាច់, ដែលគួរតែនៅក្នុងឧបករណ៍ តាមគំនិតរបស់ខ្ញុំ៖

• ឧបករណ៍រួមបញ្ចូលគ្នា៖ Jenkins, TeamCity និង Gitlab CI ។
• បរិយាកាសអភិវឌ្ឍន៍៖ Intellij IDEA, Visual Studio ។ វាកាន់តែងាយស្រួលសម្រាប់អ្នកអភិវឌ្ឍន៍មិនឱ្យរុករកចំណុចប្រទាក់ដែលមិនអាចយល់បានដែលនៅតែត្រូវចងចាំ ប៉ុន្តែដើម្បីមើលការរួមបញ្ចូលចាំបាច់ទាំងអស់ និងភាពងាយរងគ្រោះដែលគាត់បានរកឃើញត្រឹមត្រូវនៅកន្លែងធ្វើការក្នុងបរិយាកាសអភិវឌ្ឍន៍ផ្ទាល់ខ្លួនរបស់គាត់។
• ការពិនិត្យលេខកូដ៖ SonarQube និងការពិនិត្យដោយដៃ។
• អ្នកតាមដានពិការភាព៖ Jira និង Bugzilla ។

រូបភាពបង្ហាញពីអ្នកតំណាងដ៏ល្អបំផុតមួយចំនួននៃការវិភាគឋិតិវន្ត។

វាមិនមែនជាឧបករណ៍ដែលមានសារៈសំខាន់នោះទេ ប៉ុន្តែដំណើរការ ដូច្នេះមានដំណោះស្រាយ Open Source ដែលល្អសម្រាប់សាកល្បងដំណើរការផងដែរ។

SAST Open Source នឹងមិនស្វែងរកភាពងាយរងគ្រោះមួយចំនួនធំ ឬ DataFlows ដ៏ស្មុគស្មាញនោះទេ ប៉ុន្តែពួកវាអាច និងគួរត្រូវបានប្រើប្រាស់នៅពេលបង្កើតដំណើរការមួយ។ ពួកគេជួយឱ្យយល់ពីរបៀបដែលដំណើរការនឹងត្រូវបានសាងសង់ អ្នកណានឹងឆ្លើយតបចំពោះកំហុស អ្នកណានឹងរាយការណ៍ និងអ្នកណានឹងរាយការណ៍។ ប្រសិនបើអ្នកចង់អនុវត្តដំណាក់កាលដំបូងនៃការបង្កើតសុវត្ថិភាពនៃកូដរបស់អ្នក សូមប្រើដំណោះស្រាយប្រភពបើកចំហ។

តើនេះអាចរួមបញ្ចូលដោយរបៀបណា ប្រសិនបើអ្នកនៅដើមដំបូងនៃការធ្វើដំណើររបស់អ្នក ហើយមិនមានអ្វីទាំងអស់៖ គ្មាន CI គ្មាន Jenkins គ្មាន TeamCity? ចូរយើងពិចារណាការរួមបញ្ចូលទៅក្នុងដំណើរការ។

ការរួមបញ្ចូលកម្រិត CVS

ប្រសិនបើអ្នកមាន Bitbucket ឬ GitLab អ្នកអាចរួមបញ្ចូលនៅកម្រិត ប្រព័ន្ធកំណែស្របគ្នា។.

តាមព្រឹត្តិការណ៍ - ទាញសំណើ, ប្តេជ្ញាចិត្ត។ អ្នកស្កែនកូដ ហើយស្ថានភាពស្ថាបនាបង្ហាញថាតើការត្រួតពិនិត្យសុវត្ថិភាពបានឆ្លងកាត់ ឬបរាជ័យ។

មតិត្រឡប់។ ជាការពិតណាស់ មតិកែលម្អតែងតែត្រូវការ។ ប្រសិនបើអ្នកទើបតែធ្វើសន្តិសុខនៅចំហៀង ដាក់វានៅក្នុងប្រអប់មួយ ហើយមិនប្រាប់នរណាម្នាក់អំពីវា ហើយបន្ទាប់មកនៅចុងខែបានបោះចោលនូវកំហុសជាច្រើន - នេះមិនត្រឹមត្រូវ និងមិនល្អ។

ការរួមបញ្ចូលជាមួយប្រព័ន្ធត្រួតពិនិត្យកូដ

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

ការរួមបញ្ចូលជាមួយ SonarQube

មនុស្សជាច្រើនមាន ច្រកទ្វារគុណភាព នៅក្នុងលក្ខខណ្ឌនៃគុណភាពកូដ។ វាដូចគ្នានៅទីនេះ - អ្នកអាចបង្កើតច្រកដូចគ្នាសម្រាប់តែឧបករណ៍ SAST ប៉ុណ្ណោះ។ វានឹងមានចំណុចប្រទាក់ដូចគ្នា ច្រកទ្វារមានគុណភាពដូចគ្នា មានតែវានឹងត្រូវបានហៅ ច្រកទ្វារសុវត្ថិភាព. ហើយផងដែរ ប្រសិនបើអ្នកមានដំណើរការដោយប្រើ SonarQube អ្នកអាចបញ្ចូលអ្វីគ្រប់យ៉ាងនៅទីនោះបានយ៉ាងងាយស្រួល។

ការរួមបញ្ចូលនៅកម្រិត CI

អ្វីគ្រប់យ៉ាងនៅទីនេះក៏សាមញ្ញផងដែរ៖

• ស្មើរនឹងការធ្វើតេស្តស្វ័យប្រវត្តិ, ការធ្វើតេស្តឯកតា។
• ការបែងចែកតាមដំណាក់កាលអភិវឌ្ឍន៍: dev, test, prod. សំណុំ​ច្បាប់​ខុស​គ្នា ឬ​លក្ខខណ្ឌ​បរាជ័យ​ផ្សេង​គ្នា​អាច​ត្រូវ​បាន​រួម​បញ្ចូល៖ បញ្ឈប់​ការ​ជួប​ជុំ កុំ​បញ្ឈប់​ការ​ជួប​ជុំ។
• ការចាប់ផ្តើមធ្វើសមកាលកម្ម/អសមកាល. យើងកំពុងរង់ចាំការបញ្ចប់ការធ្វើតេស្តសុវត្ថិភាពឬអត់។ នោះគឺយើងទើបតែបើកដំណើរការពួកវា ហើយបន្តទៅមុខ ហើយបន្ទាប់មកយើងទទួលបានស្ថានភាពថាអ្វីគ្រប់យ៉ាងល្អឬអាក្រក់។

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

ជាឧទាហរណ៍ យើងបានយកគម្រោងធំមួយ ហើយសម្រេចចិត្តថាឥឡូវនេះយើងនឹងស្កេនវាជាមួយ SAST - យល់ព្រម។ យើងបានជំរុញគម្រោងនេះទៅក្នុង SAST វាផ្តល់ឱ្យយើងនូវភាពងាយរងគ្រោះចំនួន 20 ហើយដោយការសម្រេចចិត្តដ៏មុតមាំ យើងបានសម្រេចចិត្តថាអ្វីគ្រប់យ៉ាងគឺល្អ។ ភាពងាយរងគ្រោះចំនួន 000 គឺជាបំណុលបច្ចេកទេសរបស់យើង។ យើង​នឹង​ដាក់​បំណុល​ក្នុង​ប្រអប់​មួយ យើង​នឹង​ជម្រះ​វា​យឺតៗ ហើយ​បន្ថែម​កំហុស​ទៅ​លើ​កម្មវិធី​តាមដាន​ដែល​មាន​បញ្ហា។ តោះជួលក្រុមហ៊ុន ធ្វើអ្វីគ្រប់យ៉ាងដោយខ្លួនឯង ឬឱ្យ Security Champions ជួយយើង ហើយបំណុលបច្ចេកទេសនឹងថយចុះ។

ហើយភាពងាយរងគ្រោះដែលទើបនឹងកើតថ្មីទាំងអស់នៅក្នុងកូដថ្មីត្រូវតែត្រូវបានលុបចោលតាមរបៀបដូចគ្នាជាមួយនឹងកំហុសនៅក្នុងឯកតា ឬនៅក្នុងការធ្វើតេស្តស្វ័យប្រវត្តិ។ និយាយដោយទាក់ទងគ្នា ការជួបប្រជុំគ្នាបានចាប់ផ្តើម យើងបានដំណើរការវា ការធ្វើតេស្តចំនួនពីរ និងការធ្វើតេស្តសុវត្ថិភាពចំនួនពីរបានបរាជ័យ។ យល់ព្រម - យើងបានទៅមើលអ្វីដែលបានកើតឡើង ជួសជុលរឿងមួយ ជួសជុលរឿងមួយទៀត ដំណើរការវានៅពេលបន្ទាប់ - អ្វីគ្រប់យ៉ាងគឺល្អ គ្មានភាពងាយរងគ្រោះថ្មីលេចឡើង គ្មានការសាកល្បងណាមួយបរាជ័យឡើយ។ ប្រសិនបើកិច្ចការនេះកាន់តែស៊ីជម្រៅ ហើយអ្នកត្រូវយល់ឱ្យបានច្បាស់ ឬជួសជុលភាពងាយរងគ្រោះប៉ះពាល់ដល់ស្រទាប់ធំៗនៃអ្វីដែលស្ថិតនៅក្រោមក្រណាត់៖ កំហុសត្រូវបានបន្ថែមទៅកម្មវិធីតាមដានពិការភាព វាត្រូវបានផ្តល់អាទិភាព និងកែតម្រូវ។ ជាអកុសល ពិភពលោកមិនល្អឥតខ្ចោះទេ ហើយជួនកាលការសាកល្បងបរាជ័យ។

ឧទាហរណ៍នៃច្រកសុវត្ថិភាពគឺជា analogue នៃច្រកទ្វារគុណភាពមួយ ទាក់ទងនឹងវត្តមាន និងចំនួននៃភាពងាយរងគ្រោះនៅក្នុងកូដ។

យើងរួមបញ្ចូលជាមួយ SonarQube - កម្មវិធីជំនួយត្រូវបានដំឡើង អ្វីគ្រប់យ៉ាងគឺងាយស្រួល និងត្រជាក់ណាស់។

ការរួមបញ្ចូលជាមួយបរិស្ថានអភិវឌ្ឍន៍

ជម្រើសនៃការរួមបញ្ចូល៖

• កំពុងដំណើរការការស្កេនពីបរិយាកាសអភិវឌ្ឍន៍មុនពេលប្តេជ្ញាចិត្ត។
• មើលលទ្ធផល។
• ការវិភាគលទ្ធផល។
• ធ្វើសមកាលកម្មជាមួយម៉ាស៊ីនមេ។

នេះជាអ្វីដែលវាហាក់ដូចជាទទួលបានលទ្ធផលពីម៉ាស៊ីនមេ។

នៅក្នុងបរិយាកាសអភិវឌ្ឍន៍របស់យើង។ អាយឌីអេលអ៊ិនធឺលីច ធាតុបន្ថែមគ្រាន់តែលេចឡើងដែលប្រាប់អ្នកថាភាពងាយរងគ្រោះបែបនេះត្រូវបានរកឃើញក្នុងអំឡុងពេលស្កេន។ អ្នកអាចកែសម្រួលកូដភ្លាមៗ មើលការណែនាំ និង ក្រាហ្វលំហូរ. ទាំងអស់នេះមានទីតាំងនៅកន្លែងធ្វើការរបស់អ្នកអភិវឌ្ឍន៍ ដែលងាយស្រួលណាស់ - មិនចាំបាច់ធ្វើតាមតំណផ្សេងទៀត ហើយមើលអ្វីបន្ថែមនោះទេ។

បើកប្រភព

នេះជាប្រធានបទដែលខ្ញុំចូលចិត្ត។ មនុស្សគ្រប់គ្នាប្រើបណ្ណាល័យប្រភពបើកចំហ - ហេតុអ្វីបានជាសរសេរឈើច្រត់ និងកង់មួយដុំ នៅពេលដែលអ្នកអាចយកបណ្ណាល័យដែលត្រៀមរួចជាស្រេច ដែលអ្វីៗគ្រប់យ៉ាងត្រូវបានអនុវត្តរួចហើយ?

ជាការពិតណាស់ នេះជាការពិត ប៉ុន្តែបណ្ណាល័យក៏ត្រូវបានសរសេរដោយមនុស្សផងដែរ ពួកវាក៏រួមបញ្ចូលនូវហានិភ័យមួយចំនួន និងមានភាពងាយរងគ្រោះផងដែរដែលត្រូវបានរាយការណ៍ជាទៀងទាត់ ឬឥតឈប់ឈរ។ ដូច្នេះមានជំហានបន្ទាប់នៅក្នុងសុវត្ថិភាពកម្មវិធី - នេះគឺជាការវិភាគនៃសមាសភាគប្រភពបើកចំហ។

ការវិភាគប្រភពបើកចំហ - OSA

ឧបករណ៍រួមមានដំណាក់កាលធំបី។

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

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

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

លក្ខណៈពិសេស:

• គោលនយោបាយផ្សេងៗគ្នាសម្រាប់ដំណាក់កាលផ្សេងៗនៃការអភិវឌ្ឍន៍។
• ការត្រួតពិនិត្យសមាសធាតុនៅក្នុងបរិយាកាសឧស្សាហកម្ម។
• ការគ្រប់គ្រងបណ្ណាល័យក្នុងអង្គភាព។
• ការគាំទ្រសម្រាប់ប្រព័ន្ធសាងសង់ផ្សេងៗ និងភាសា។
• ការវិភាគរូបភាព Docker ។

ឧទាហរណ៍មួយចំនួននៃអ្នកដឹកនាំឧស្សាហកម្មដែលចូលរួមក្នុងការវិភាគប្រភពបើកចំហ។

ឥតគិតថ្លៃតែមួយគត់គឺនេះ។ ការត្រួតពិនិត្យភាពអាស្រ័យ ពី OWASP ។ អ្នកអាចបើកវានៅក្នុងដំណាក់កាលដំបូង មើលពីរបៀបដែលវាដំណើរការ និងអ្វីដែលវាគាំទ្រ។ ជាទូទៅ ទាំងនេះគឺជាផលិតផលពពកទាំងអស់ ឬនៅក្នុងបរិវេណ ប៉ុន្តែនៅពីក្រោយមូលដ្ឋានរបស់ពួកគេ ពួកគេនៅតែត្រូវបានបញ្ជូនទៅអ៊ីនធឺណិត។ ពួកគេ​មិន​ផ្ញើ​បណ្ណាល័យ​របស់អ្នក​ទេ ប៉ុន្តែ​ជា hashes ឬ​តម្លៃ​ផ្ទាល់​របស់​ពួកគេ​ដែល​ពួកគេ​គណនា និង​ស្នាម​មេដៃ​ទៅកាន់​ម៉ាស៊ីនមេ​របស់ពួកគេ​ដើម្បី​ទទួល​ព័ត៌មាន​អំពី​វត្តមាននៃ​ភាពងាយ​រងគ្រោះ។

ការរួមបញ្ចូលដំណើរការ

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

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

ការរួមបញ្ចូលជាមួយវត្ថុបុរាណ៖ Nexus និង JFrog ។

ការរួមបញ្ចូលទៅក្នុងបរិយាកាសអភិវឌ្ឍន៍។ ឧបករណ៍ដែលអ្នកជ្រើសរើសគួរតែមានការរួមបញ្ចូលជាមួយបរិស្ថានអភិវឌ្ឍន៍។ អ្នកអភិវឌ្ឍន៍ត្រូវតែមានសិទ្ធិចូលប្រើលទ្ធផលស្កេនពីកន្លែងធ្វើការរបស់គាត់ ឬសមត្ថភាពក្នុងការស្កែន និងពិនិត្យមើលកូដដោយខ្លួនឯងសម្រាប់ភាពងាយរងគ្រោះ មុនពេលចូលប្រើ CVS ។

ការរួមបញ្ចូលស៊ីឌី។ នេះគឺជាលក្ខណៈពិសេសដ៏ល្អមួយ ដែលខ្ញុំពិតជាចូលចិត្ត និងដែលខ្ញុំបាននិយាយរួចមកហើយ - ការត្រួតពិនិត្យការលេចចេញនូវភាពងាយរងគ្រោះថ្មីនៅក្នុងបរិយាកាសឧស្សាហកម្ម។ វាដំណើរការអ្វីមួយដូចនេះ។

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

• នៅពេលសាងសង់ យើងពិនិត្យមើលថាគ្មាននរណាម្នាក់បានរអិលអ្វីអាក្រក់នោះទេ សមាសធាតុទាំងអស់មានសុវត្ថិភាព ហើយគ្មាននរណាម្នាក់បាននាំមកនូវអ្វីដែលគ្រោះថ្នាក់នៅលើ flash drive នោះទេ។
• យើងមានតែសមាសធាតុដែលអាចទុកចិត្តបាននៅក្នុងឃ្លាំង។
• នៅពេលដាក់ពង្រាយ យើងពិនិត្យមើលកញ្ចប់ខ្លួនឯងម្តងទៀត៖ war, jar, DL ឬ Docker image ដើម្បីធានាថាវាអនុលោមតាមគោលការណ៍។
• នៅពេលចូលទៅក្នុងឧស្សាហកម្មនេះ យើងតាមដាននូវអ្វីដែលកំពុងកើតឡើងនៅក្នុងបរិយាកាសឧស្សាហកម្ម៖ ភាពងាយរងគ្រោះសំខាន់ៗលេចឡើង ឬមិនលេចឡើង។

ការវិភាគថាមវន្ត - DAST

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

ប្រព័ន្ធដូចគ្នាអនុញ្ញាតឱ្យអ្នកពិនិត្យមើលភាពងាយរងគ្រោះគំរូនៅក្នុងប្រភពបើកចំហ។ ដោយសារ DAST មិនដឹងថា Open Source មួយណាដែលយើងកំពុងប្រើ វាគ្រាន់តែបោះចោលគំរូ "ព្យាបាទ" និងវិភាគការឆ្លើយតបរបស់ម៉ាស៊ីនមេ៖

- បាទ មានបញ្ហា deserialization នៅទីនេះ ប៉ុន្តែមិនមែននៅទីនេះទេ។

មានហានិភ័យធំនៅក្នុងរឿងនេះ ពីព្រោះប្រសិនបើអ្នកធ្វើតេស្ដសុវត្ថិភាពនេះនៅលើកៅអីតែមួយដែលអ្នកសាកល្បងធ្វើការជាមួយ នោះរឿងមិនល្អអាចកើតឡើង។

• ការផ្ទុកខ្ពស់នៅលើបណ្តាញម៉ាស៊ីនមេកម្មវិធី។
• គ្មានការរួមបញ្ចូល។
• សមត្ថភាពក្នុងការផ្លាស់ប្តូរការកំណត់នៃកម្មវិធីដែលបានវិភាគ។
• មិនមានការគាំទ្រសម្រាប់បច្ចេកវិទ្យាចាំបាច់នោះទេ។
• ការលំបាកក្នុងការរៀបចំ។

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

- ប្រុសៗ លេងសើចទេ?! យើង​បាន​ផ្តល់​គណនី​ឱ្យ​អ្នក ហើយ​អ្នក​បាន​បង្កើត​ជំហរ​មួយ!

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

វាមានតម្លៃពិចារណាថាអ្នកអាចប្រើវាជា analogue នៃការធ្វើតេស្តបន្ទុក។ នៅដំណាក់កាលដំបូង អ្នកអាចបើកម៉ាស៊ីនស្កេនថាមវន្តដែលមាន 10-15 ខ្សែ ហើយមើលថាមានអ្វីកើតឡើង ប៉ុន្តែជាធម្មតា ដូចដែលការអនុវត្តបង្ហាញ គ្មានអ្វីល្អទេ។

ធនធានមួយចំនួនដែលយើងប្រើជាធម្មតា។

មានតម្លៃបន្លិច ឈុត Burp គឺជា "កាំបិតស្វីស" សម្រាប់អ្នកជំនាញសន្តិសុខណាមួយ។ មនុស្សគ្រប់គ្នាប្រើវាហើយវាងាយស្រួលណាស់។ កំណែសាកល្បងថ្មីនៃការបោះពុម្ពសហគ្រាសឥឡូវនេះត្រូវបានចេញផ្សាយ។ ប្រសិនបើមុននេះវាគ្រាន់តែជាឧបករណ៍ប្រើប្រាស់ឯករាជ្យជាមួយកម្មវិធីជំនួយ ឥឡូវនេះអ្នកអភិវឌ្ឍន៍កំពុងបង្កើតម៉ាស៊ីនមេធំមួយ ដែលវានឹងអាចគ្រប់គ្រងភ្នាក់ងារជាច្រើនបាន។ នេះល្អណាស់ ខ្ញុំណែនាំអ្នកឱ្យសាកល្បង។

ការរួមបញ្ចូលដំណើរការ

សមាហរណកម្មកើតឡើងយ៉ាងល្អ និងសាមញ្ញ៖ ចាប់ផ្តើមស្កេនបន្ទាប់ពីការដំឡើងជោគជ័យ កម្មវិធីសម្រាប់ឈរនិង ការស្កេនបន្ទាប់ពីការធ្វើតេស្តរួមបញ្ចូលជោគជ័យ.

ប្រសិនបើការរួមបញ្ចូលមិនដំណើរការ ឬមានមុខងារ stubs និងចំអក វាគ្មានន័យ និងគ្មានប្រយោជន៍អ្វីទេ - មិនថាយើងផ្ញើលំនាំបែបណាទេ ម៉ាស៊ីនមេនឹងនៅតែឆ្លើយតបតាមរបៀបដដែល។

• តាមឧត្ដមគតិ កន្លែងធ្វើតេស្តដាច់ដោយឡែក។
• មុនពេលធ្វើតេស្ត សូមសរសេរលំដាប់នៃការចូល។
• ការធ្វើតេស្តប្រព័ន្ធគ្រប់គ្រងគឺដោយដៃតែប៉ុណ្ណោះ។

ដំណើរការ

សង្ខេបបន្តិចអំពីដំណើរការជាទូទៅ និងអំពីការងាររបស់ឧបករណ៍នីមួយៗ ជាពិសេស។ កម្មវិធីទាំងអស់គឺខុសគ្នា - មួយដំណើរការប្រសើរជាងមុនជាមួយការវិភាគថាមវន្ត មួយទៀតជាមួយការវិភាគឋិតិវន្ត ទីបីជាមួយការវិភាគ OpenSource ការ pentests ឬអ្វីផ្សេងទៀតទាំងអស់គ្នា ឧទាហរណ៍ ព្រឹត្តិការណ៍ជាមួយ វ៉ា.

ដំណើរការនីមួយៗត្រូវការការគ្រប់គ្រង។

ដើម្បីយល់ពីរបៀបដែលដំណើរការដំណើរការ និងកន្លែងដែលវាអាចត្រូវបានកែលម្អ អ្នកត្រូវប្រមូលម៉ែត្រពីអ្វីគ្រប់យ៉ាងដែលអ្នកអាចទទួលបានដោយដៃរបស់អ្នក រួមទាំងរង្វាស់ផលិតកម្ម រង្វាស់ពីឧបករណ៍ និងពីឧបករណ៍តាមដានពិការភាព។

ព័ត៌មានណាមួយគឺមានប្រយោជន៍។ វាចាំបាច់ក្នុងការមើលពីមុំផ្សេងៗគ្នានៅកន្លែងដែលឧបករណ៍នេះឬឧបករណ៍នោះត្រូវបានប្រើប្រាស់ប្រសើរជាងមុន ដែលដំណើរការនេះធ្លាក់ចុះជាពិសេស។ វាអាចមានតម្លៃក្នុងការមើលពេលវេលាឆ្លើយតបនៃការអភិវឌ្ឍន៍ ដើម្បីមើលកន្លែងដែលត្រូវកែលម្អដំណើរការដោយផ្អែកលើពេលវេលា។ ទិន្នន័យកាន់តែច្រើន ផ្នែកកាន់តែច្រើនអាចត្រូវបានបង្កើតឡើងពីកម្រិតកំពូលរហូតដល់ព័ត៌មានលម្អិតនៃដំណើរការនីមួយៗ។

ចាប់តាំងពីអ្នកវិភាគឋិតិវន្ត និងថាមវន្តទាំងអស់មាន APIs ផ្ទាល់ខ្លួន វិធីសាស្ត្រចាប់ផ្តើមរបស់ពួកគេ គោលការណ៍ខ្លះមានកម្មវិធីកំណត់ពេល ខ្លះទៀតមិនមាន - យើងកំពុងសរសេរឧបករណ៍ AppSec Orchestratorដែលអនុញ្ញាតឱ្យអ្នកបង្កើតចំណុចចូលតែមួយទៅក្នុងដំណើរការទាំងមូលពីផលិតផល និងគ្រប់គ្រងវាពីចំណុចមួយ។

អ្នកគ្រប់គ្រង អ្នកអភិវឌ្ឍន៍ និងវិស្វករសុវត្ថិភាពមានចំណុចចូលមួយដែលពួកគេអាចមើលឃើញនូវអ្វីដែលកំពុងដំណើរការ កំណត់រចនាសម្ព័ន្ធ និងដំណើរការការស្កេន ទទួលលទ្ធផលស្កេន និងបញ្ជូនតម្រូវការ។ យើងកំពុងព្យាយាមផ្លាស់ទីឆ្ងាយពីការងារឯកសារ ដើម្បីបកប្រែអ្វីគ្រប់យ៉ាងទៅជាមនុស្ស ដែលត្រូវបានប្រើដោយការអភិវឌ្ឍន៍ - ទំព័រនៅលើ Confluence ជាមួយនឹងស្ថានភាព និងម៉ែត្រ ពិការភាពក្នុង Jira ឬនៅក្នុងកម្មវិធីតាមដានពិការភាពផ្សេងៗ ឬការរួមបញ្ចូលទៅក្នុងដំណើរការសមកាលកម្ម/អសមកាលនៅក្នុង CI / ស៊ីឌី។

ការយកសំខាន់ៗ

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

គុណភាពផលិតផល - គោលដៅរួម ទាំងសន្តិសុខ និងការអភិវឌ្ឍន៍។ យើងធ្វើរឿងមួយ យើងព្យាយាមធានាថាអ្វីៗដំណើរការបានត្រឹមត្រូវ ហើយមិនមានហានិភ័យកេរ្តិ៍ឈ្មោះ ឬការបាត់បង់ផ្នែកហិរញ្ញវត្ថុទេ។ នោះហើយជាមូលហេតុដែលយើងផ្សព្វផ្សាយវិធីសាស្រ្ត DevSecOps, SecDevOps ដើម្បីកែលម្អទំនាក់ទំនង និងកែលម្អគុណភាពនៃផលិតផល។

ចាប់ផ្តើមជាមួយនឹងអ្វីដែលអ្នកមានរួចហើយ៖ តម្រូវការ, ស្ថាបត្យកម្ម, ការត្រួតពិនិត្យផ្នែក, ការបណ្តុះបណ្តាល, ការណែនាំ។ មិនចាំបាច់អនុវត្តរាល់ការអនុវត្តភ្លាមៗចំពោះគម្រោងទាំងអស់នោះទេ - ផ្លាស់ទីម្តងហើយម្តងទៀត. មិនមានស្តង់ដារតែមួយទេ - ពិសោធន៍ ហើយសាកល្បងវិធីសាស្រ្ត និងដំណោះស្រាយផ្សេងៗ។

មានសញ្ញាស្មើគ្នារវាងពិការភាពសុវត្ថិភាពព័ត៌មាន និងពិការភាពមុខងារ.

ធ្វើអ្វីៗគ្រប់យ៉ាងដោយស្វ័យប្រវត្តិដែលផ្លាស់ទី។ អ្វីក៏ដោយដែលមិនផ្លាស់ទី ផ្លាស់ទីវា និងស្វ័យប្រវត្តិកម្មវា។ ប្រសិនបើអ្វីមួយត្រូវបានធ្វើដោយដៃ វាមិនមែនជាផ្នែកល្អនៃដំណើរការនោះទេ។ ប្រហែល​ជា​វា​មាន​តម្លៃ​ក្នុង​ការ​ពិនិត្យ​មើល​វា និង​ធ្វើ​ឱ្យ​វា​ស្វ័យប្រវត្តិ​ផង​ដែរ។

ប្រសិនបើទំហំនៃក្រុម IS តូច - ប្រើជើងឯកសុវត្ថិភាព.

ប្រហែល​ជា​អ្វី​ដែល​ខ្ញុំ​បាន​និយាយ​នឹង​មិន​ស័ក្តិសម​នឹង​អ្នក​ទេ ហើយ​អ្នក​នឹង​មាន​អ្វី​មួយ​ដោយ​ខ្លួន​ឯង - ហើយ​នោះ​ជា​ការ​ល្អ។ ប៉ុន្តែ ជ្រើសរើសឧបករណ៍ដោយផ្អែកលើតម្រូវការសម្រាប់ដំណើរការរបស់អ្នក។. កុំមើលអ្វីដែលសហគមន៍និយាយ ថាឧបករណ៍នេះអាក្រក់ ហើយឧបករណ៍នេះល្អ។ ប្រហែលជាការផ្ទុយនឹងជាការពិតសម្រាប់ផលិតផលរបស់អ្នក។

តម្រូវការសម្រាប់ឧបករណ៍។

• កម្រិតទាប វិជ្ជមានមិនពិត។
• ពេលវេលាវិភាគគ្រប់គ្រាន់។
• ភាពងាយស្រួលនៃការប្រើប្រាស់។
• ភាពអាចរកបាននៃការរួមបញ្ចូល។
• ការយល់ដឹងអំពីផែនទីបង្ហាញផ្លូវនៃការអភិវឌ្ឍន៍ផលិតផល។
• លទ្ធភាពនៃការប្ដូរឧបករណ៍តាមបំណង។

របាយការណ៍របស់ Yuri ត្រូវបានជ្រើសរើសជាអ្នកល្អបំផុតនៅ DevOpsConf 2018។ ដើម្បីស្គាល់គំនិតគួរឱ្យចាប់អារម្មណ៍ និងករណីជាក់ស្តែងបន្ថែមទៀត សូមមកកាន់ Skolkovo នៅថ្ងៃទី 27 និង 28 ខែឧសភា។ DevOpsConf នៅខាងក្នុង ពិធីបុណ្យ RIT++. ប្រសើរជាងនេះទៅទៀត ប្រសិនបើអ្នកត្រៀមខ្លួនចែករំលែកបទពិសោធន៍របស់អ្នករួចហើយ អនុវត្ត សម្រាប់របាយការណ៍រហូតដល់ថ្ងៃទី ២១ ខែមេសា។

ប្រភព: www.habr.com