អ្វីដែលអាចខុសជាមួយ CI/CD pipelines?

ការធ្វើសមាហរណកម្មជាបន្តបន្ទាប់ និងការផ្តល់ជាបន្តបន្ទាប់ (CI/CD) pipelines គឺជាមូលដ្ឋានគ្រឹះនៃអង្គការផ្នែកទន់ណាមួយដែលបង្កើតកម្មវិធីតាមរបៀប "ទំនើប"។ ស្វ័យប្រវត្តិកម្មផ្តល់នូវថាមពលដ៏អស្ចារ្យ ប៉ុន្តែអ្នកអភិវឌ្ឍន៍ភាគច្រើនខកខានការទទួលខុសត្រូវដែលវាពាក់ព័ន្ធ។

អ្នកអភិវឌ្ឍន៍: មែនហើយ យើងយក CI/CD សន្ដិសុខ យ៉ាងម៉ត់ចត់ និងមានការគ្រប់គ្រងយ៉ាងរឹងមាំលើអ្នកថែទាំកូដ ពិនិត្យឡើងវិញ commitមុនពេលការរួមបញ្ចូលគ្នា; ការងារ និង pipelineត្រូវបានថែរក្សាដោយបុគ្គលិកជាន់ខ្ពស់ ពួកគេមើលថែមិនឱ្យលេចធ្លាយអាថ៌កំបាំងនៅក្នុង pipelines. ហើយឧបករណ៍នេះត្រូវបានដំឡើងដោយបុគ្គលិកដែលដឹងរឿងនេះ។ តើមានអ្វីអាចខុស?

អ្នកអភិវឌ្ឍន៍ជាទីគោរព, CI/CD ប្រព័ន្ធនានាមានភាពស្មុគស្មាញ។ ផ្ទៃវាយប្រហារដ៏ធំទូលាយរបស់វាទាក់ទាញជនអាក្រក់។ ជាការប្រសើរណាស់ដែលត្រូវប្រុងប្រយ័ត្ន និងកុំមានទំនុកចិត្តខ្លាំងពេក។

ការកំណត់រចនាសម្ព័ន្ធលំនាំដើមជួនកាលត្រូវបានរក្សាទុក ហើយក្លាយជាមិត្តល្អបំផុតសម្រាប់ពួក Hacker។ ចំណុចខ្វះខាតសំខាន់ៗអាចមានវត្តមាននៅក្នុង CI/CD pipeline ប្រភព នៅក្នុងការកំណត់រចនាសម្ព័ន្ធនៃប្រព័ន្ធ ឬជុំវិញដំណើរការ និងបរិបទនៃ pipeline និងរបៀបដែលវាត្រូវបានបង្កឡើង។

នៅក្នុងអត្ថបទនេះ យើងនឹងដាក់ខ្លួនយើងនៅក្នុងស្ថានភាពរបស់តួអង្គអាក្រក់។ ស្រមៃថាយើងកំពុងអានការសញ្ជឹងគិតរបស់ M3M3N70 (Memento Mori?) និង កំហឹងវាលភក់ កន្លែងណាមួយនៅក្នុងបណ្ដាញងងឹត ប្រហែលជាជាភាសាមិនមែនលោកខាងលិច ប៉ុន្តែកុំខកខានឲ្យសោះថាអំពើអាក្រក់កំពុងរីករាលដាលពាសពេញពិភពលោក។

 

កាលពីសម័យមុនវាងាយស្រួលណាស់…

M3M3N70ត្រលប់ទៅសម័យកាលដ៏ល្អពីមុនវិញ អាជីវកម្មរបស់យើងងាយស្រួលណាស់... Zero-days គឺជាផ្លែឈើដែលងាយស្រួលរក កម្មវិធីនានាបើកចំហរជាមួយនឹងចំណុចខ្សោយដែលងាយស្រួលកេងប្រវ័ញ្ច ហើយយើងអាចផ្លាស់ទីទៅចំហៀងបានភ្លាមៗ។

កំហឹងវាលភក់ហ៊ឺម! មនុស្ស​ល្ងង់​មួយ​ចំនួន​នៅ​ទីនោះ​នៅ​ឡើយ​ទេ ប៉ុន្តែ​អ្វីៗ​បាន​ផ្លាស់ប្ដូរ។ មនុស្ស​ធំៗ​បាន​រិះគន់​យ៉ាង​ខ្លាំង​ចំពោះ​រឿង AppSec នោះ។

M3M3N70មែន។ ប៉ុន្តែអ្នកល្ងង់ថ្មីគឺជាអ្នកអភិវឌ្ឍន៍។ សម្រាប់ពួកយើង វាកាន់តែងាយស្រួលក្នុងការស្វែងរកឧបករណ៍ដែលបុរសទាំងនេះប្រើ។ ជាពិសេស CI គឺជាអណ្តូងរ៉ែមាស! ថូខឹនចូលប្រើពពក SCM លិខិតសម្គាល់ ពាក្យសម្ងាត់មូលដ្ឋានទិន្នន័យផលិតកម្ម កូនសោឯកជន SSH លិខិតសម្គាល់របស់អ្នកប្រើប្រាស់ CI ផ្សេងទៀត... ការលោតពីរឿងអភិវឌ្ឍន៍ដ៏គួរឱ្យធុញទ្រាន់ទៅរឿងពិតគឺពិតជាមិនសំខាន់ទេ។

ស្វ័យប្រវត្តិកម្មសម្រាប់ការបង្កើត ការធ្វើតេស្ត និងការដាក់ពង្រាយកម្មវិធីជាមួយ CI/CD ឧបករណ៍នេះជារឿយៗត្រូវការបញ្ជូនអាថ៌កំបាំងទៅកាន់ពាក្យបញ្ជាជាជំហានៗ។ ហើយជារឿយៗវាត្រូវបានលេចធ្លាយ ជាមួយនឹងផលវិបាកដ៏អាក្រក់។

Pipelineត្រូវការអាថ៌កំបាំងដែលពេលខ្លះត្រូវបានលេចធ្លាយ

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

ប្រហែលជាពេលវេលាចាស់ល្អគឺត្រូវរកឃើញនៅក្នុងប្រវត្តិសាស្ត្រ Git .env ឯកសារ (អ្នកអភិវឌ្ឍន៍ភ្លេចបន្ថែមវាទៅ .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

ដែលត្រូវបានប្រើនៅក្នុងដំណើរការការងារ GitHub .github/deploy.yaml ដែលមានអ្វីមួយដូចនេះ៖

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70៖ អស្ចារ្យមែន! គ្រាប់ចុច aws ទាំងនោះដំណើរការហើយ! យើងបានសាកល្បងការផ្លាស់ប្តូរ inocuos នៅក្នុងកម្មវិធីជាមុនសិន បន្ទាប់មកបានបន្ថែម sting ព្រោះពួកគេហាក់ដូចជាមិនដឹងខ្លួន។ ប៊ីងហ្គោ! យុទ្ធនាការដ៏អស្ចារ្យមួយ...

ជនល្មើស​គ្រាន់តែ​ប្រើ​សោ AWS ដើម្បី​ផ្ទុក​ឡើង​នូវ​កម្មវិធី​ដែល​បាន​កែប្រែ​ជាមួយ​មេរោគ ហើយ​បន្ទាប់​មក​ដំណើរការ​ពាក្យបញ្ជា​ដាក់​ពង្រាយ​ជាមួយ​នឹង​ព័ត៌មាន​សម្ងាត់​បែប​នេះ។ អាថ៌កំបាំង​ដែល​លេច​ធ្លាយ រួម​ជាមួយ​ព័ត៌មាន​ដែល​មាន​នៅ​ក្នុង pipeline«យុទ្ធនាការដ៏អស្ចារ្យមួយ!» ប្រហែលជាមានន័យថា Memento បានបំផ្លាញភាពវឹកវរដល់ជនរងគ្រោះដ៏កំសត់។

អ្វីដែល Memento ប្រាប់យើងនៅទីនេះគឺថា នៅពេលដែលមានការលេចធ្លាយសម្ងាត់កើតឡើង ដូចជាសោចូលប្រើ AWS នៅក្នុងឧទាហរណ៍ អ្នកត្រូវតែលុបចោលសោសម្ងាត់នោះ (បង្វិលសោខាងលើ)។ ភ្លាមតែងតែមាន បង្អួចបង្ហាញ រវាងការលេចធ្លាយ commit និងការបដិសេធដោយសម្ងាត់; ការសរសេរប្រវត្តិ Git ឡើងវិញគឺពិបាកណាស់ (សូម្បីតែរដ្ឋផ្តាច់ការដ៏តឹងរ៉ឹងបំផុតក៏បានព្យាយាមសរសេរប្រវត្តិសាស្ត្រឡើងវិញបែបនេះដែរ តែគ្មានប្រយោជន៍ទេ) ហើយប្រហែលជាគ្មានប្រសិទ្ធភាព (មិត្តភក្តិរបស់យើងប្រហែលជាបានចម្លងមុនឃ្លាំងទិន្នន័យដែលមានការលេចធ្លាយសម្ងាត់) commit)។ បង្វិលគ្រាប់ចុចភ្លាមៗ ហើយអធិស្ឋានពេលកំពុងអានកំណត់ហេតុសកម្មភាពសម្រាប់គណនីគោលដៅក្នុងអំឡុងពេលបង្អួចប៉ះពាល់!

ប្រហែលជាអង្គការនានាគួរតែ ហាមឃាត់ការប្រើប្រាស់អាថ៌កំបាំងរយៈពេលវែងនៅក្នុង CI/CD pipelinesហើយជំនួសពួកវាដោយព័ត៌មានបញ្ជាក់អត្តសញ្ញាណបណ្ដោះអាសន្ន។ នៅក្នុងឧទាហរណ៍មុនជាមួយសោ AWS នៅក្នុងសកម្មភាព GitHub វាមានសុវត្ថិភាពជាងក្នុងការប្រើប្រាស់ អ្នកផ្តល់សេវា OpenID Connect (OIDC) ដើម្បីទទួលបានលិខិតបញ្ជាក់រយៈពេលខ្លីដែលត្រូវការសម្រាប់សកម្មភាព។

កំហឹងវាលភក់៖ អ្នកពិតជាមានសំណាងណាស់! ការលេចធ្លាយស្គ្រីបដែលមានសោរដែលបានអ៊ិនកូដរឹងគឺជាការអនុវត្តជាទូទៅនៅសម័យមុន សូម្បីតែនៅលើធុង S3 ដែលអាចចូលប្រើបានជាសាធារណៈក៏ដោយ។ អ្វីដែលអ្នកត្រូវធ្វើគឺឆ្លងកាត់វត្ថុនៅក្នុងធុង ហើយធ្វើការជីកយករ៉ែដើម្បីស្វែងរករបស់គួរឱ្យចាប់អារម្មណ៍។

ពេលខ្លះតំបន់ដែលប្រើសម្រាប់ដាក់ពង្រាយ (ធុង AWS S3 នៅក្នុងឧទាហរណ៍នេះ) ត្រូវបានបើកចំហសម្រាប់ការអានពីអ្នកខាងក្រៅ ដោយសារតែកំហុសក្នុងការកំណត់រចនាសម្ព័ន្ធ (ដែលមិនត្រូវបានរកឃើញ)។ អ្វី? កំហឹងវាលភក់ ដែលត្រូវបានប្រើគឺជាអ្វីមួយដូចនេះ៖

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

ធុងនេះទំនងជាត្រូវបានបង្កើតឡើងនៅក្នុងគំរូផ្ដល់ដែលអាចត្រូវបានស្កេនដោយស្វ័យប្រវត្តិសម្រាប់ចំណុចខ្វះខាតសុវត្ថិភាព។

ការកំណត់រចនាសម្ព័ន្ធលំនាំដើមរបស់ឧបករណ៍គឺជាប្រដាប់ក្មេងលេងសម្រាប់ពួកយើង

ដើម្បីផ្តល់ឧទាហរណ៍ជាក់ស្តែង ចូរយើងនិយាយអំពី Jenkinsដែលជាឧបករណ៍ CI ដ៏ពេញនិយមបំផុតមួយ។

កំហឹងវាលភក់តើអ្នកចាំប្រអប់ធីក "បើកដំណើរការសុវត្ថិភាព" នៅក្នុង Jenkins ទេ ហើយតើមានអង្គការប៉ុន្មានដែលបានជ្រើសរើសមិនធ្វើឱ្យវាសកម្មដើម្បីភាពងាយស្រួល? ហើយ "អ្នកណាក៏អាចធ្វើអ្វីៗបានដែរ"បន្សំការអនុញ្ញាតជាលំនាំដើម? ហើយកម្មវិធីជំនួយ Jenkins ដែលរំខានទាំងនោះ ដូចជា កម្មវិធីជំនួយ GitHub OAuthបុរសដែលបានកំណត់រចនាសម្ព័ន្ធវាបានជ្រើសរើសទាំង "ផ្តល់សិទ្ធិអានដល់អ្នកប្រើប្រាស់ដែលបានផ្ទៀងផ្ទាត់ទាំងអស់" និង "ប្រើសិទ្ធិឃ្លាំង GitHub" ដែលផ្តល់ឱ្យយើងនូវសិទ្ធិចូលប្រើគម្រោងទាំងអស់របស់ពួកគេ។

(សុំទោស Jenkins ដែលដាក់អ្នកជាឧទាហរណ៍ 😉)

ចូរ​រក្សា​ភាព​ស្ទាត់ជំនាញ (សូម្បីតែ​អ្នកញៀន) ចំពោះ​គោលការណ៍​សន្តិសុខ។ មួយ​គឺ សុវត្ថិភាពតាមលំនាំដើម គោលការណ៍៖ ការគ្រប់គ្រងគួរតែកំណត់តាមលំនាំដើមទៅតាមការកំណត់ដែលមានសុវត្ថិភាពបំផុតតាមដែលអាចធ្វើទៅបាន។ សុវត្ថិភាពគួរតែត្រូវបានបង្កើតឡើងនៅក្នុង CI/CD ឧបករណ៍និង pipelineតាំងពីដំបូងមកម្ល៉េះ ជាជាងការគិតគូរពីក្រោយ។ ប៉ុន្តែភាពងាយស្រួលប្រើប្រាស់ និងភាពងាយស្រួលជារឿយៗប៉ះទង្គិចជាមួយសុវត្ថិភាព។

ចំពោះករណី Jenkins ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវដែលភ្ជាប់មកជាមួយគឺផុយស្រួយពេក៖ កុំប្រើយន្តការផ្ទៀងផ្ទាត់ដែលភ្ជាប់មកជាមួយនៅក្នុង Jenkinsជ្រើសរើសយន្តការភាគីទីបី (SAML, LDAP, Google …) ជាមួយនឹងកម្មវិធីជំនួយ Role-based Authorization Strategy (“RBAC”)។ ហើយត្រូវប្រុងប្រយ័ត្នខ្ពស់ជាមួយ admin របស់អ្នក។

ថែរក្សារបៀបធ្វើការ និង pipeline ឯកសារនៅក្នុង Jenkins ត្រូវបានដោះស្រាយ។ ដូចគ្នានឹង កម្មវិធីជំនួយការកំណត់រចនាសម្ព័ន្ធជាកូដ និងឯកសារកំណត់រចនាសម្ព័ន្ធរបស់វា ដែលអនុវត្តចំពោះការកំណត់រចនាសម្ព័ន្ធ Jenkins។

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

អង្គការនានាគួរតែអនុវត្តcisការថែទាំត្រឹមត្រូវក្នុងការឡើងរឹង CI/CD ប្រព័ន្ធ ដោយចាប់ផ្តើមជាមួយនឹងការកំណត់ដែលមានការរឹតត្បិតបំផុត ហើយបើកបន្តិចម្តងៗជាមួយនឹងការអនុញ្ញាតអប្បបរមាដែលត្រូវការសម្រាប់ pipeline ជំហាន។

ការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពនៅក្នុង CI/CD ឧបករណ៍​ជាច្រើន​អាច​មាន​ភាពស្មុគស្មាញ។ ឧបករណ៍​ជាច្រើន​មាន​កម្មវិធី​ជំនួយ ឬ​ផ្នែក​បន្ថែម​ដែល​មាន​ចំណុចខ្សោយ​ភាគច្រើន ហើយ​ត្រូវការ​ធ្វើបច្ចុប្បន្នភាព។

ម៉ាស៊ីនស្កេនការកំណត់រចនាសម្ព័ន្ធសុវត្ថិភាពមិនត្រឹមត្រូវសម្រាប់ឧបករណ៍ស្មុគស្មាញបែបនេះ ឬស្តង់ដារអាចជួយបាន។

ការបញ្ចូលលេខកូដ pipeline ពាក្យបញ្ជាសម្រាប់ការសប្បាយ និងប្រាក់ចំណេញ

M3M3N70តើអ្នកធ្លាប់ប្រើ Untrusted Code Checkouts ដែលសកម្មភាព និងស្គ្រីបងាយរងគ្រោះដោយសារការចាក់ថ្នាំបញ្ជាដែរឬទេ?

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

ឧទាហរណ៍ដំបូងនៃអ លំហូរការងារ GitHub ដ៏អកុសល:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

បន្សំ pull_request_target ការបង្កកដំណើរការការងារជាមួយនឹងការទូទាត់ប្រាក់ជាក់លាក់នៃ PR ដែលមិនគួរឱ្យទុកចិត្តគឺជាការអនុវត្តដ៏គ្រោះថ្នាក់មួយដែលអាចនាំឱ្យមានការសម្របសម្រួលឃ្លាំង។ នៅក្នុងឧទាហរណ៍ ការរួមបញ្ចូលគ្នាដ៏អកុសលនៃ៖

• pull_request_target ព្រឹត្តិការណ៍ ដែលតាមលំនាំដើមមានការអនុញ្ញាតសរសេរទៅកាន់ឃ្លាំងគោលដៅ និងអាថ៌កំបាំងឃ្លាំងគោលដៅ សូម្បីតែពីសមខាងក្រៅក៏ដោយ ហើយដំណើរការក្នុងបរិបទនៃឃ្លាំងគោលដៅរបស់ PR។
• ពិនិត្យលេខកូដ PR ពីប្រភព, repo មិនគួរឱ្យទុកចិត្ត,
• បង្ក​ឲ្យ​មាន​ស្គ្រីប​ណាមួយ​ដែល​អាច​ដំណើរការ​លើ​ខ្លឹមសារ​ដែល​គ្រប់គ្រង​ដោយ PR ដូច​ក្នុង​ករណី​នៃ npm installនិង
• មិនប្រើលក្ខខណ្ឌណាមួយដើម្បីបង្កឲ្យមានការកើតឡើង pull_request_target ព្រឹត្តិការណ៍​ត្រូវ​ដំណើរការ​លុះត្រាតែ​ស្លាក 'PR នេះ​ត្រូវ​បាន​ត្រួតពិនិត្យ' មួយ​ចំនួន​ត្រូវ​បាន​កំណត់​ទៅ PR (អ្នកប្រើប្រាស់​ខាងក្រៅ​មិន​អាច​កំណត់​ស្លាក​ទៅ PR បាន​ទេ)។

ឧទាហរណ៍ទីពីរទទួលយកធាតុចូលដែលមិនគួរឱ្យទុកចិត្ត (ពីបញ្ហា មតិយោបល់ ឬ pull request) ជាប្រភពសម្រាប់អាគុយម៉ង់ដែលបានបញ្ជូនទៅ pipeline ពាក្យបញ្ជាតាមរយៈកន្សោម។ នេះគឺជា pipeline កំណែនៃភាពងាយរងគ្រោះនៃការចាក់បញ្ចូលពាក្យបញ្ជា OS។

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

ប្រតិបត្តិការ​ដំណើរការ​បង្កើត​ស្គ្រីប​សែល​បណ្ដោះអាសន្ន​ដែល​ផ្អែក​លើ​គំរូ ជាមួយ $ ជំនួស ដែលធ្វើឱ្យវាងាយរងគ្រោះដោយសារការចាក់បញ្ចូលពាក្យបញ្ជាសែល។ អ្នកវាយប្រហារដែលមានគណនី GitHub ក្លែងក្លាយអាចបង្កើតបញ្ហាជាមួយចំណងជើង a"; bad_code_goes_here;#, ហើយ​ប៊ូម! 

កំហឹងវាលភក់អូ! បុរសទាំងនោះកំពុងបើកទ្វារសម្រាប់ការចាក់បញ្ចូលពាក្យបញ្ជាដោយគ្រាន់តែបើកបញ្ហាមួយ...

មានភាពងាយរងគ្រោះនៃការប្រតិបត្តិកូដនៅក្នុងសកម្មភាព GitHub ដូចជា មតិយោបល់ gajira, ឥឡូវ​បាន​ជួសជុល​ហើយ។ សូម​អាន "ការបញ្ចូលដែលមិនគួរឱ្យទុកចិត្តនៅក្នុងដំណើរការការងារ GitHub" សម្រាប់ព័ត៌មានលម្អិតពេញលេញ។

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

 

ការដាក់ពង្រាយមេរោគដែលមិនបានគ្រោងទុកនៅទីនេះ!

ការដាក់ពង្រាយជាបន្តបន្ទាប់ គឺជាចំណុចកំពូលនៃស្វ័យប្រវត្តិកម្ម ប៉ុន្តែចំណុចកំពូលនោះអាចត្រូវបានរារាំងដោយកង្វះការគ្រប់គ្រងការអនុម័តសមស្របលើ pipeline លំហូរ។

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

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

ពួកគេកំពុងបិទទ្វារ

កំហឹងវាលភក់: ពាក្យសម្ងាត់លំនាំដើមដ៏រីករាយទាំងនោះនៅក្នុង CI/CD ឧបករណ៍​កំពុង​ត្រូវ​បាន​លុប​ចេញ។ ការ​ចូល​ប្រើប្រាស់ /var/lib/jenkins/secrets/initialAdminPassword ឥឡូវនេះគឺជាផ្លូវស្លាប់មួយ។ ឧបករណ៍ជាច្រើនឥឡូវនេះកំពុងផ្តល់ 2FA ដែល Covid បានធ្វើឱ្យមានប្រជាប្រិយភាព ហើយសូម្បីតែស្វាសរសេរកូដខ្ជិលបំផុតក៏កំពុងប្រើវាដែរ!

M3M3N70យើងកំពុងប្រយុទ្ធប្រឆាំងនឹង 2FA ប៉ុន្តែវាមិនងាយស្រួលនោះទេ។ វាពិបាកក្នុងការលួចបន្លំមនុស្សទាំងនោះ ព្រោះ “Scatter Swine” បានធ្វើជាមួយ Twilioជាមួយ​នឹង​សោ WebAuthn វា​ពិបាក​ជាង​ច្រើន។ យ៉ាង​ហោច​ណាស់ យើង​អាច​ព្យាយាម លួចខូឃីស៍ដើម្បីរំលង MFAប៉ុន្តែត្រូវចូលទៅក្នុងប្រអប់របស់អ្នកអភិវឌ្ឍន៍។

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

កំហឹងវាលភក់៖ ក្រុម DevOps កំពុងភ្ញាក់ឡើង។ ពួកគេមានរឿង "ឯកសិទ្ធិតិចតួចបំផុត" នៅក្នុងឈាមរបស់ពួកគេ។ ហើយពួកគេលែងជាស្វាសរសេរកូដទៀតហើយ។ ឥឡូវនេះ យើងត្រូវបានអ្នកវាយតម្លៃចាប់បានដោយខុសច្បាប់។

ជាការពិតណាស់, pipelines ឥឡូវនេះមានភាពរឹងមាំជាងពីរបីឆ្នាំមុនបន្តិច ជាមួយនឹងសកម្មភាព និងស្គ្រីបខ្សោយដែលត្រូវបានដកចេញ និងជាមួយនឹងជំហានសាកល្បងសុវត្ថិភាពបន្ថែមដែលថែមទាំងរកឃើញឧបករណ៍ទម្លាក់គ្រាប់បែករបស់យើងដែលលាក់ខ្លួននៅក្នុងភាពលួចលាក់ទៀតផង។ commits និងកញ្ចប់ដែលយើងបានលួចចូល។

សំណួរសម្រាប់អ្នកអាន៖ តើដំណើរការនៃការបង្កើតកម្មវិធីពីប្រភព និងការដាក់ពង្រាយទៅក្នុងផលិតកម្មជាអាជីវកម្មដែលមានហានិភ័យដែរឬទេ? តើអ្នកអាចមើលឃើញ DevOps របស់អ្នកនៅក្នុងដំណាក់កាលនៃ ពេលវេលាល្អៗ ចំពោះមនុស្សអាក្រក់?

អនុសាសន៍ចុងក្រោយ

កន្លែងដែលត្រូវចាប់ផ្តើមជាមួយ CI/CD pipelineស?

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

ប្រហែលជាការរួមបញ្ចូលគ្នារវាងអ្នកពិនិត្យជំនាញដែលបំពាក់ដោយម៉ាស៊ីនស្កេនកូដព្យាបាទដោយស្វ័យប្រវត្តិអាចជួយបាន។

អនុសាសន៍ទីពីរគឺ បណ្តុះបណ្តាលអ្នកអភិវឌ្ឍន៍ដែលសរសេរ pipelineនិងរក្សាសុវត្ថិភាពរបស់ពួកគេចំណុចដែលត្រូវពិចារណា៖

• របៀបដោះស្រាយការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវជាមួយសេវាកម្មផ្ទៃក្នុង និងសេវាកម្មពពក ដោយជៀសវាងការរំខាននៃការដោះស្រាយព័ត៌មានសម្គាល់អត្តសញ្ញាណរយៈពេលវែង។
• របៀបកំណត់ pipelineទៅកាន់សំណុំធនធានពិតប្រាកដដែលវាត្រូវការចូលប្រើ។ គោលការណ៍នៃឯកសិទ្ធិតិចបំផុតបានភ្លឺស្វាងម្តងទៀត។
• របៀបសរសេរជំហានដើម្បីធ្វើ pipelineអាចផលិតឡើងវិញបានដូចជាការភ្ជាប់កំណែ និងជៀសវាងភាពងាយរងគ្រោះនៃការចាក់ពាក្យបញ្ជា។
• របៀបអនុម័តការដាក់ពង្រាយពីទស្សនៈសុវត្ថិភាព (ពួកគេគឺជាអ្នកផ្សេងទៀត!): តើសន្តិសុខមួយណា standards គួរតែត្រូវបានផ្គូផ្គង និងរបៀបបន្ថែមការត្រួតពិនិត្យ/ច្រកទ្វារដែលត្រូវគ្នានៅក្នុង pipelines.

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

អនុសាសន៍ទីបួនគឺ អានុភាព CI/CD pipelines សម្រាប់ស្វ័យប្រវត្តិកម្មសុវត្ថិភាពការវិភាគកូដប្រភព (SAST), ការវិភាគសមាសភាពប្រភព (SCA), ការស្កេនការលេចធ្លាយអាថ៌កំបាំង ឧបករណ៍ប្រឆាំងមេរោគ ម៉ាស៊ីនស្កេនសុវត្ថិភាពកុងតឺន័រ ឬឧបករណ៍ចាប់សញ្ញាពេលដំណើរការដោយស្វ័យប្រវត្តិ (DAST និងមេរោគ) អាចត្រូវបានដំណើរការជាប្រចាំនៅលើ pipelineហើយអង្គការរបស់អ្នកអាចអនុវត្ត standardអំពីការគ្របដណ្តប់លើការស្កេនសុវត្ថិភាពនៅក្នុង CI/CD.

សូមរំលឹកថា ឧបករណ៍ទាំងនេះមិនទាន់លុបការពិនិត្យឡើងវិញរបស់អ្នកជំនាញចេញពីសមីការនៅឡើយទេ បើមិនដូច្នោះទេ អ្នកអាចមានអារម្មណ៍សុវត្ថិភាពមិនពិត។

ប្រសិនបើអ្នកពូកែខាង OWASP toptens គម្រោងថ្មីៗដ៏ល្អមួយគឺ OWASP កំពូល ១០ CI/CD ហានិភ័យសុវត្ថិភាព.

កំណត់ចំណាំការបដិសេធ

(1) ឧទាហរណ៍នៅក្នុងប្រកាសនេះកំពុងប្រើ GitHub ជា SCM, AWS ជាអ្នកផ្តល់សេវា cloud និង GitHub Actions ឬ Jenkins ជា CI/CD ឧបករណ៍។ ពួកវាមិនខ្សោយជាង/មានសុវត្ថិភាពជាងជម្រើសផ្សេងទៀតរបស់ពួកគេទេ។ គ្មានចេតនាអាក្រក់ទេ! ឧបករណ៍ទាំងនេះមានឥទ្ធិពលខ្លាំង ហើយត្រូវការប្រើប្រាស់ឱ្យបានត្រឹមត្រូវ។

(2​) M3M3N70 និង កំហឹងវាលភក់ គឺជាតួអង្គប្រឌិត។ ភាពស្រដៀងគ្នាណាមួយទៅនឹងមនុស្ស ឬក្រុមមនុស្ស ទាំងនៅរស់ ឬស្លាប់ គឺគ្រាន់តែជារឿងចៃដន្យប៉ុណ្ណោះ… ឬមួយក៏វាជារឿងចៃដន្យ?

ដើម្បីអានបន្ថែម

• ហៃម័រ, អេ. និងអ្នកដទៃទៀត។ «រឿងរ៉ាវពិតចំនួន ១០ អំពីរបៀបដែលយើងបានសម្របសម្រួល» CI/CD pipelines "ក្រុមហ៊ុន NCC, ខែមករា ឆ្នាំ២០២២។
• configure-aws-credentials សកម្មភាព GitHub និង ការកំណត់រចនាសម្ព័ន្ធ OpenID Connect នៅក្នុង Amazon Web Services សម្រាប់ព័ត៌មានលម្អិតអំពីរបៀបដំណើរការពាក្យបញ្ជា AWS សម្រាប់ការដាក់ពង្រាយនៅក្នុងលំហូរការងារ GitHub។
• ជេ. ឡូបាសេវស្គី “រក្សាសុវត្ថិភាពសកម្មភាព និងលំហូរការងារ GitHub របស់អ្នក ផ្នែកទី 1៖ ការទប់ស្កាត់សំណើ pwn”។ មន្ទីរពិសោធន៍សុវត្ថិភាព GitLab ខែធ្នូ ឆ្នាំ២០២០។
• ជេ. ឡូបាសេវស្គី “ការរក្សាសុវត្ថិភាពសកម្មភាព និងលំហូរការងារ GitHub របស់អ្នក ផ្នែកទី 2៖ ការបញ្ចូលដែលមិនគួរឱ្យទុកចិត្ត”។ មន្ទីរពិសោធន៍សុវត្ថិភាព GitLab ខែមករា ឆ្នាំ២០២១។
• អូវ៉ាសភី។ «OWASP កំពូលទាំង ១០» CI/CD ហានិភ័យសន្តិសុខ”ខែកក្កដា ឆ្នាំ២០២២។
• Saltzer J. និង Schroeder M. «ការការពារព័ត៌មាននៅក្នុងប្រព័ន្ធកុំព្យូទ័រ»ខែមេសា ឆ្នាំ 1975។ គោលការណ៍សន្តិសុខបានវិវត្តន៍ទៅតាមបច្ចេកវិទ្យា ប៉ុន្តែ 47 ឆ្នាំក្រោយមក គំនិតសន្តិសុខ និងសណ្តាប់ធ្នាប់សាធារណៈភាគច្រើននៅតែមានប្រសិទ្ធភាព។
• NCSC ចក្រភពអង់គ្លេស។ "ធានាសុវត្ថិភាពនៃការសាងសង់ និងការដាក់ពង្រាយ" pipeline"មជ្ឈមណ្ឌលសន្តិសុខតាមអ៊ីនធឺណិតជាតិចក្រភពអង់គ្លេស ខែកុម្ភៈ ឆ្នាំ២០១៩។