อะไรบ้างที่อาจผิดพลาดได้กับ CI/CD pipelines?

การบูรณาการอย่างต่อเนื่องและการส่งมอบอย่างต่อเนื่อง (CI/CD) pipelineระบบอัตโนมัติเป็นรากฐานขององค์กรพัฒนาซอฟต์แวร์ใดๆ ที่สร้างซอฟต์แวร์ในรูปแบบ "สมัยใหม่" ระบบอัตโนมัติให้พลังมหาศาล แต่ผู้พัฒนาส่วนใหญ่มองข้ามความรับผิดชอบที่มาพร้อมกับมัน

ผู้พัฒนาใช่ เราใช้ CI/CD ความปลอดภัย อย่างจริงจังและควบคุมดูแลผู้ดูแลระบบโค้ดอย่างเข้มงวด ตรวจสอบ commitก่อนการควบรวม; งานและ pipelineเจ้าหน้าที่ระดับสูงเป็นผู้ดูแลข้อมูลเหล่านี้ และพวกเขาจะคอยป้องกันไม่ให้ความลับรั่วไหลออกไป pipelineและอุปกรณ์นั้นก็ได้รับการติดตั้งโดยบุคลากรที่มีความรู้ความชำนาญ จะมีอะไรผิดพลาดได้ล่ะ?

เรียนนักพัฒนาโปรแกรม CI/CD ระบบมีความซับซ้อน และมีช่องโหว่ให้ผู้ไม่ประสงค์ดีเข้ามาโจมตีได้ง่าย จึงควรระมัดระวังและอย่าประมาทเด็ดขาด

การตั้งค่าเริ่มต้นบางครั้งถูกเก็บไว้และกลายเป็นเพื่อนที่ดีที่สุดของแฮกเกอร์ ช่องโหว่ร้ายแรงอาจมีอยู่ในนั้น CI/CD pipeline แหล่งที่มา ในการกำหนดค่าของระบบ หรือโดยรอบกระบวนการและบริบทของ pipeline และกลไกการกระตุ้น

ในบทความนี้ เราจะลองสวมบทบาทเป็นตัวละครที่ไม่ดีดูบ้าง ลองจินตนาการว่าเรากำลังอ่านความคิดเห็นของ... เอ็ม3เอ็ม3เอ็น70 (Memento Mori?) และ ความโกรธเกรี้ยวในบึง อาจจะอยู่ในโลกออนไลน์มืดสักแห่ง ในภาษาที่ไม่ใช่ภาษาตะวันตก แต่จงอย่าลืมว่าความชั่วร้ายนั้นแพร่กระจายไปทั่วโลก

 

ในสมัยก่อนนั้นมันง่ายมาก...

เอ็ม3เอ็ม3เอ็น70: ย้อนกลับไปในยุคที่ธุรกิจของเราง่ายดายเหลือเกิน... ช่องโหว่ Zero-day หาได้ง่ายมาก แอปต่างๆ เปิดกว้างด้วยช่องโหว่ที่โจมตีได้ง่าย และเราสามารถย้ายไปยังแพลตฟอร์มอื่นได้อย่างรวดเร็ว

ความโกรธเกรี้ยวในบึงบ้าเอ๊ย! ยังมีคนเพี้ยนๆ อยู่บ้าง แต่ทุกอย่างเปลี่ยนไปแล้ว บริษัทใหญ่ๆ ให้ความสำคัญกับเรื่อง AppSec มากขึ้น

เอ็ม3เอ็ม3เอ็น70ใช่ แต่คนโง่กลุ่มใหม่คือนักพัฒนาซอฟต์แวร์ สำหรับเราแล้ว การใช้เครื่องมือที่พวกเขาใช้กันนั้นง่ายกว่ามาก โดยเฉพาะ 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 เหล่านั้นใช้งานได้จริง! เราทดสอบการเปลี่ยนแปลงเล็กน้อยในแอปก่อน จากนั้นก็เพิ่มลูกเล่นเข้าไป เพราะดูเหมือนพวกนั้นจะไม่รู้ตัว ได้ผล! แคมเปญที่ยอดเยี่ยมจริงๆ…

ผู้ไม่ประสงค์ดีใช้คีย์ AWS ในการอัปโหลดแอปพลิเคชันที่ดัดแปลงซึ่งมีมัลแวร์ จากนั้นจึงเรียกใช้คำสั่งปรับใช้โดยใช้ข้อมูลประจำตัวดังกล่าว ข้อมูลลับที่รั่วไหลออกมาพร้อมกับข้อมูลที่อยู่ในนั้น pipeline“แคมเปญอะไรเนี่ย!” น่าจะหมายความว่า Memento สร้างความเสียหายอย่างร้ายแรงให้กับเหยื่อผู้เคราะห์ร้ายนั่นเอง

สิ่งที่ Memento บอกเราในที่นี้คือ เมื่อเกิดการรั่วไหลของข้อมูลลับขึ้น เช่น คีย์การเข้าถึง AWS ในตัวอย่าง คุณจะต้องเพิกถอนข้อมูลลับนั้น (หมุนเวียนคีย์ที่กล่าวมาข้างต้น) ทันทีมีอยู่เสมอ หน้าต่างการเปิดรับแสง ระหว่างการรั่วไหล commit และการทำให้เป็นโมฆะอย่างลับๆ; การเขียนประวัติ Git ใหม่นั้นยาก (แม้แต่รัฐเผด็จการที่เข้มงวดที่สุดก็เคยพยายามเขียนประวัติศาสตร์ใหม่เช่นนี้ แต่ก็ไม่สำเร็จ) และอาจจะไม่ได้ผล (เพื่อนของเราอาจจะโคลนนิ่งข้อมูลก่อนที่คลังข้อมูลที่มีการรั่วไหลของข้อมูลลับจะเปิดเผย) commitหมุนแป้นพิมพ์ทันที และภาวนาไปพร้อมกับการอ่านบันทึกกิจกรรมของบัญชีเป้าหมายในช่วงเวลาที่กำหนด!

องค์กรต่างๆ น่าจะควร... ห้ามใช้ความลับระยะยาวใน CI/CD pipelinesและแทนที่ด้วยข้อมูลประจำตัวชั่วคราว ในตัวอย่างก่อนหน้านี้เกี่ยวกับการใช้คีย์ AWS ใน GitHub Actions การใช้ข้อมูลประจำตัวชั่วคราวจะปลอดภัยกว่า ผู้ให้บริการ OpenID Connect (OIDC) เพื่อขอรับข้อมูลประจำตัวชั่วคราวที่จำเป็นสำหรับการดำเนินการต่างๆ

ความโกรธเกรี้ยวในบึงคุณโชคดีจัง! การแอบปล่อยสคริปต์ที่มีคีย์แบบฮาร์ดโค้ดเป็นเรื่องปกติในสมัยก่อน แม้แต่ใน S3 bucket ที่เข้าถึงได้จากสาธารณะ สิ่งที่คุณต้องทำก็แค่สำรวจอ็อบเจ็กต์ใน bucket และใช้ grep ค้นหาสิ่งที่น่าสนใจ

บางครั้งพื้นที่ที่ใช้ในการปรับใช้ (ในตัวอย่างนี้คือ AWS S3 bucket) เปิดให้บุคคลภายนอกอ่านได้ เนื่องจากข้อผิดพลาดในการกำหนดค่า (ซึ่งตรวจไม่พบ) อะไรนะ ความโกรธเกรี้ยวในบึง สิ่งที่ใช้มีลักษณะประมาณนี้:

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>'"

น่าจะสร้างบัคเก็ตดังกล่าวขึ้นในเทมเพลตการจัดเตรียม ซึ่งสามารถสแกนหาช่องโหว่ด้านความปลอดภัยได้โดยอัตโนมัติ

การตั้งค่าเริ่มต้นของเครื่องมือนี้เป็นเหมือนของเล่นสำหรับเรา

เพื่อให้เห็นภาพชัดเจนขึ้น ลองมาพูดถึงเรื่องต่อไปนี้กัน เจนกิ้นส์ซึ่งเป็นหนึ่งในเครื่องมือ CI ที่ได้รับความนิยมมากที่สุด

ความโกรธเกรี้ยวในบึง: คุณจำช่องทำเครื่องหมาย “เปิดใช้งานความปลอดภัย” ใน Jenkins ได้ไหม และมีองค์กรกี่แห่งที่เลือกไม่เปิดใช้งานเพื่อความสะดวกสบาย? และ “ใครๆ ก็ทำอะไรก็ได้“การตั้งค่าสิทธิ์แบบรวมเป็นค่าเริ่มต้น? และปลั๊กอิน Jenkins ที่น่ารำคาญเหล่านั้น เช่น...” ปลั๊กอิน GitHub OAuthคนที่ตั้งค่าระบบเลือกทั้ง "ให้สิทธิ์อ่านแก่ผู้ใช้ที่เข้าสู่ระบบทั้งหมด" และ "ใช้สิทธิ์การเข้าถึงคลังเก็บข้อมูล GitHub" ทำให้เราสามารถเข้าถึงโปรเจ็กต์ทั้งหมดของพวกเขาได้

(ขออภัยด้วยนะ เจนกินส์ ที่ยกคุณมาเป็นตัวอย่าง 😉)

จงเชี่ยวชาญ (หรือแม้กระทั่งเสพติด) หลักการด้านความปลอดภัยอยู่เสมอ หนึ่งในนั้นคือ ปลอดภัยโดยค่าเริ่มต้น หลักการ: ระบบควบคุมควรตั้งค่าเริ่มต้นให้ปลอดภัยที่สุดเท่าที่จะเป็นไปได้ ความปลอดภัยควรถูกสร้างขึ้นมาตั้งแต่ต้น CI/CD เครื่องมือและ pipelineควรออกแบบระบบรักษาความปลอดภัยตั้งแต่เริ่มต้น ไม่ใช่คิดขึ้นมาทีหลัง แต่ความใช้งานง่ายและความสะดวกสบายมักขัดแย้งกับความปลอดภัย

สำหรับกรณีของ Jenkins ระบบการตรวจสอบสิทธิ์แบบในตัวนั้นเปราะบางเกินไป: ห้ามใช้กลไกการตรวจสอบสิทธิ์ในตัวของ Jenkins เด็ดขาดควรเลือกใช้กลไกของบุคคลที่สาม (SAML, LDAP, Google…) ร่วมกับปลั๊กอินกลยุทธ์การอนุญาตตามบทบาท ("RBAC") และควรระมัดระวังเป็นอย่างยิ่ง admin บัญชี

ดูแลจัดการงานให้ดีและ pipeline ไฟล์ต่างๆ ใน ​​Jenkins ได้รับการจัดการแล้ว เช่นเดียวกับ ปลั๊กอินการกำหนดค่าด้วยโค้ด และไฟล์การกำหนดค่าต่างๆ ซึ่งใช้กับการตั้งค่าของ Jenkins

ย้ายจากระบบโฮสต์ด้วยตนเอง CI/CD การเปลี่ยนจากระบบภายในองค์กรไปสู่ระบบ SaaS บนคลาวด์ช่วยลดความเสี่ยงบางประการและทำให้สามารถโยกย้ายข้อมูลภายในเครือข่ายองค์กรได้ แต่ก็เพิ่มความเสี่ยงอื่นๆ เข้ามาด้วย เช่น การต้องเปิดการเชื่อมต่อภายนอกระหว่างระบบภายในที่มีอยู่กับระบบภายนอก CI/CD เครื่องมือ

องค์กรควรใช้อำนาจcisการดูแลอย่างเหมาะสมในการทำให้แข็งตัว CI/CD ระบบจะเริ่มต้นด้วยการตั้งค่าที่เข้มงวดที่สุด และค่อยๆ เปิดสิทธิ์อนุญาตที่จำเป็นขั้นต่ำให้มากขึ้น pipeline ขั้นตอน

การกำหนดค่าความปลอดภัยใน CI/CD เครื่องมือเหล่านี้อาจมีความซับซ้อนมาก หลายเครื่องมือมีปลั๊กอินหรือส่วนขยายซึ่งมักมีช่องโหว่และจำเป็นต้องได้รับการอัปเดต

เครื่องมือสแกนหาความผิดพลาดในการตั้งค่าความปลอดภัยสำหรับเครื่องมือที่ซับซ้อนเช่นนี้ หรือโปรแกรมทดสอบประสิทธิภาพ อาจช่วยได้

การแทรกโค้ดเข้าไป pipeline คำสั่งเพื่อความสนุกและผลกำไร

เอ็ม3เอ็ม3เอ็น70คุณเคยใช้การดาวน์โหลดโค้ดที่ไม่น่าเชื่อถือ ซึ่งมีแอ็กชันและสคริปต์ที่เสี่ยงต่อการโจมตีแบบ Command Injection หรือไม่?

ส่วนนี้แสดงให้เห็นว่า 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 การใช้ทริกเกอร์เวิร์กโฟลว์โดยมีการเช็คเอาท์ Pull Request (PR) ที่ไม่น่าเชื่อถืออย่างชัดเจน เป็นแนวทางปฏิบัติที่อันตรายซึ่งอาจนำไปสู่การบุกรุกคลังเก็บข้อมูล ในตัวอย่างนี้ การผสมผสานที่ไม่พึงประสงค์ของ:

• pull_request_target อีเวนต์นี้ ซึ่งโดยค่าเริ่มต้นจะมีสิทธิ์ในการเขียนไปยังที่เก็บเป้าหมายและข้อมูลลับของที่เก็บเป้าหมาย แม้กระทั่งจากฟอร์กภายนอก และทำงานในบริบทของที่เก็บเป้าหมายของ PR
• ตรวจสอบโค้ด PR จากแหล่งเก็บโค้ดที่ไม่น่าเชื่อถือ
• เรียกใช้สคริปต์ใดๆ ที่อาจทำงานกับเนื้อหาที่อยู่ภายใต้การควบคุมของ PR เช่นในกรณีของ npm installและ
• ไม่ใช้เงื่อนไขในการกระตุ้น pull_request_target กิจกรรมจะทำงานก็ต่อเมื่อมีการกำหนดป้ายกำกับ "PR นี้ได้รับการตรวจสอบแล้ว" ให้กับ PR นั้น (ผู้ใช้ภายนอกไม่สามารถกำหนดป้ายกำกับให้กับ PR ได้)

ตัวอย่างที่สองคือการรับข้อมูลที่ไม่น่าเชื่อถือ (จากปัญหา ความคิดเห็น หรือ...) pull request) เป็นแหล่งที่มาของอาร์กิวเมนต์ที่ส่งไปยัง pipeline สั่งการผ่านนิพจน์ นี่คือ pipeline เวอร์ชันของช่องโหว่การแทรกคำสั่งระบบปฏิบัติการ

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

การดำเนินการ "run" จะสร้างสคริปต์เชลล์ชั่วคราวโดยอิงจากเทมเพลต โดยมี... $ มีการแทนที่ ทำให้เสี่ยงต่อการโจมตีด้วยการแทรกคำสั่งเชลล์ ผู้โจมตีที่มีบัญชี GitHub ปลอมสามารถสร้างปัญหาที่มีชื่อเรื่องได้ a"; bad_code_goes_here;#และตูม! 

ความโกรธเกรี้ยวในบึงโอ้ พวกนั้นเปิดช่องโหว่ให้มีการแทรกคำสั่งได้ง่ายๆ เพียงแค่เปิดประเด็นปัญหาขึ้นมา...

มีช่องโหว่ด้านการเรียกใช้โค้ดใน GitHub Actions เช่น ความคิดเห็นของกาจิระแก้ไขเรียบร้อยแล้ว โปรดอ่าน “ข้อมูลป้อนเข้าที่ไม่น่าเชื่อถือในเวิร์กโฟลว์ของ GitHub” สำหรับรายละเอียด

ข้อคิดจากเรื่องนี้: ห้ามคัดลอกและสร้าง Pull Request (PR) จากแหล่งที่ไม่น่าเชื่อถือโดยเด็ดขาด โดยไม่ตรวจสอบ PR นั้นก่อน คำว่า 'ไม่น่าเชื่อถือ' ในที่นี้ เว้นแต่จะมีการตรวจสอบแหล่งที่มาอย่างเข้มงวด อาจหมายถึงบัญชีนักพัฒนาซอฟต์แวร์ที่อาจถูกแฮ็กได้

 

เกิดการติดตั้งมัลแวร์โดยไม่ตั้งใจ!

การปรับใช้อย่างต่อเนื่อง นี่คือจุดสูงสุดของการใช้ระบบอัตโนมัติ แต่จุดสูงสุดนั้นอาจถูกขัดขวางได้เนื่องจากขาดการควบคุมการอนุมัติที่เหมาะสม pipeline ไหล.

ความเสี่ยงของการใช้งานระบบแบบอัตโนมัติเต็มรูปแบบตั้งแต่ต้นทาง commit ความเสี่ยงของการนำไปใช้กับระบบการผลิตนั้นรวมถึงความเป็นไปได้ที่โค้ดที่เป็นอันตรายจะถูกนำไปใช้ในสภาพแวดล้อมการผลิตโดยไม่ถูกตรวจพบ ตลอดจนความเป็นไปได้ที่ข้อผิดพลาดในกระบวนการนำไปใช้จะก่อให้เกิดการหยุดชะงักหรือการหยุดทำงาน

เพื่อลดความเสี่ยงเหล่านี้ มักแนะนำให้องค์กรต่างๆ ดำเนินการ "หยุดอย่างเด็ดขาด" ในกระบวนการปรับใช้ ซึ่งต้องใช้ขั้นตอนต่างๆ การอนุมัติของมนุษย์ ก่อนที่จะปล่อยเวอร์ชันใหม่ไปยังสภาพแวดล้อมปลายทาง

พวกเขากำลังปิดประตู

ความโกรธเกรี้ยวในบึง: รหัสผ่านเริ่มต้นแสนสนุกเหล่านั้นใน CI/CD เครื่องมือต่าง ๆ กำลังถูกลบออกไป การเข้าถึง /var/lib/jenkins/secrets/initialAdminPassword ตอนนี้มันไม่ใช่แนวทางที่จำเป็นอีกต่อไปแล้ว เพราะมีเครื่องมือมากมายที่รองรับการยืนยันตัวตนสองขั้นตอน (2FA) ซึ่งเป็นที่นิยมในช่วงโควิด และแม้แต่โปรแกรมเมอร์ที่ขี้เกียจที่สุดก็ยังใช้มัน!

เอ็ม3เอ็ม3เอ็น70เรากำลังต่อสู้กับ 2FA อยู่ แต่มันไม่ง่ายอย่างนั้น การโจมตีแบบ Spear-phishing ใส่พวกนั้นเป็นเรื่องยาก “Scatter Swine” ร่วมงานกับ Twilioการใช้คีย์ WebAuthn นั้นยากกว่ามาก อย่างน้อยเราก็สามารถลองดูได้ ขโมยคุกกี้เพื่อหลีกเลี่ยงการตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA)แต่จำเป็นต้องเจาะเข้าไปในกรอบความคิดของนักพัฒนาซอฟต์แวร์

การตรวจสอบสิทธิ์แบบหลายปัจจัย (Multi-Factor Authentication หรือ MFA) เป็นก้าวที่ดีในการลดความเสี่ยงจากการรั่วไหลของข้อมูลลับการตรวจสอบสิทธิ์ เครื่องมือ DevOps สมัยใหม่ส่วนใหญ่รองรับ MFA และคีย์การตรวจสอบสิทธิ์ภายใต้ WebAuthn / U2F (ดูเพิ่มเติม) โครงการ FIDO2(และอาจเป็นตัวเลือกที่ดีที่สุดสำหรับ MFA ใน DevOps หากมีการจัดการอย่างเหมาะสม)

ความโกรธเกรี้ยวในบึงพวก DevOps เริ่มตื่นตัวแล้ว พวกเขามีหลักการ "สิทธิ์ขั้นต่ำสุด" ฝังอยู่ในสายเลือด และพวกเขาไม่ใช่แค่คนเขียนโค้ดธรรมดาอีกต่อไปแล้ว ตอนนี้เราถูกจับได้คาหนังคาเขาโดยผู้ตรวจสอบแล้ว

ในความเป็นจริง pipelineตอนนี้ระบบมีความแข็งแกร่งกว่าเมื่อสองสามปีก่อนเล็กน้อย โดยได้ลบการกระทำและสคริปต์ที่อ่อนแอออกไป และเพิ่มขั้นตอนการทดสอบความปลอดภัยเพิ่มเติม ซึ่งสามารถตรวจจับแม้กระทั่งโปรแกรมปล่อยมัลแวร์ที่ซ่อนตัวอยู่ได้อย่างแนบเนียน commitและพัสดุที่เราปล้นมา

คำถามสำหรับผู้อ่าน: กระบวนการสร้างซอฟต์แวร์จากซอร์สโค้ดและนำไปใช้งานจริงนั้นมีความเสี่ยงหรือไม่? คุณมองเห็น DevOps ของคุณอยู่ในขั้นตอนนี้หรือไม่? ช่วงเวลาดีๆ ในอดีต เพื่อพวกคนชั่วเหรอ?

คำแนะนำสุดท้าย

จะเริ่มต้นจากตรงไหนดี CI/CD pipelines?

ข้อแนะนำแรกนั้นง่ายมาก: อย่างระมัดระวัง ทบทวน pipelines (พวกเขาเป็น) วิกฤติ (ทรัพยากร) สำหรับประเด็นด้านความปลอดภัย การตรวจสอบมีค่าใช้จ่ายสูงแต่จำเป็น และควรดำเนินการอย่างถูกต้อง ผู้ตรวจสอบควรทราบว่าต้องตรวจสอบอะไรบ้าง ทุกขั้นตอนต้องได้รับการตรวจสอบหาข้อบกพร่อง

บางทีการผสมผสานระหว่างผู้เชี่ยวชาญด้านการตรวจสอบและโปรแกรมสแกนมัลแวร์อัตโนมัติอาจช่วยได้

ข้อแนะนำที่สองคือ ฝึกอบรมนักพัฒนาที่เขียนโปรแกรม pipelineและรักษาความปลอดภัยให้กับพวกมันสิ่งที่ควรพิจารณา:

• วิธีจัดการการตรวจสอบสิทธิ์อย่างถูกต้องกับบริการภายในและบริการคลาวด์ โดยหลีกเลี่ยงปัญหาความยุ่งยากในการจัดการข้อมูลประจำตัวระยะยาว
• วิธีการจำกัด pipelineเฉพาะทรัพยากรที่จำเป็นต้องเข้าถึงเท่านั้น หลักการให้สิทธิ์ขั้นต่ำสุดจึงปรากฏให้เห็นอีกครั้ง
• วิธีการเขียนขั้นตอนในการสร้าง pipelineสามารถสร้างผลลัพธ์ซ้ำได้ เช่น การกำหนดเวอร์ชัน และการหลีกเลี่ยงช่องโหว่การโจมตีด้วยการแทรกคำสั่ง
• วิธีการอนุมัติการปรับใช้จากมุมมองด้านความปลอดภัย (ยังมีด้านอื่นๆ อีก!) : ความปลอดภัยด้านใดบ้าง standardควรจับคู่ค่าต่างๆ และวิธีการเพิ่มการตรวจสอบ/เกณฑ์ที่เกี่ยวข้องในนั้น pipelines.

ข้อเสนอแนะประการที่สามคือ กำหนดค่า CI/CD ระบบด้วยความระมัดระวังอย่างเหมาะสมการตรวจสอบสิทธิ์ที่เข้มงวด การไม่ใช้รหัสผ่านเริ่มต้นหรือการตั้งค่าที่ไม่ปลอดภัย การจำกัดสิทธิ์ให้น้อยที่สุด... ดูแลเรื่องช่องโหว่ในปลั๊กอินและส่วนขยายที่ติดตั้งไว้ นี่อาจเป็นหัวข้อหลักของโพสต์ถัดไป โปรดติดตามต่อไป

ข้อเสนอแนะข้อที่สี่คือ ใช้ประโยชน์จาก CI/CD pipelines สำหรับระบบอัตโนมัติด้านความปลอดภัยการวิเคราะห์ซอร์สโค้ด (SAST) การวิเคราะห์องค์ประกอบแหล่งที่มา (SCAเครื่องมือต่างๆ เช่น การสแกนการรั่วไหลของข้อมูลลับ เครื่องมือป้องกันมัลแวร์ เครื่องสแกนความปลอดภัยของคอนเทนเนอร์ หรือตัวตรวจจับอัตโนมัติขณะทำงาน (DAST และมัลแวร์) สามารถเรียกใช้เป็นประจำบนระบบได้ pipelineและองค์กรของคุณอาจบังคับใช้กฎหมายได้ standardเกี่ยวกับความคุ้มครองในการสแกนความปลอดภัยใน CI/CD.

โปรดจำไว้ว่า เครื่องมือเหล่านี้ยังคงต้องอาศัยการตรวจสอบจากผู้เชี่ยวชาญอยู่ดี มิเช่นนั้นคุณอาจเข้าใจผิดและมั่นใจเกินไป

หากคุณเชี่ยวชาญเรื่อง OWASP top-tens โครงการล่าสุดที่น่าสนใจคือ... OWASP 10 อันดับแรก CI/CD ความเสี่ยงด้านความปลอดภัย.

หมายเหตุข้อจำกัดความรับผิดชอบ

(1) ตัวอย่างในโพสต์นี้ใช้ GitHub เป็น SCMโดยใช้ AWS เป็นผู้ให้บริการคลาวด์ และ GitHub Actions หรือ Jenkins เป็น CI/CD เครื่องมือเหล่านี้ไม่ได้ด้อยกว่าหรือปลอดภัยกว่าเครื่องมือทางเลือกอื่นๆ ไม่มีเจตนาที่จะโจมตีหรือทำให้เสียชื่อเสียง! เครื่องมือเหล่านี้มีประสิทธิภาพสูงและจำเป็นต้องใช้ให้เหมาะสม

(2) เอ็ม3เอ็ม3เอ็น70 และ ความโกรธเกรี้ยวในบึง ตัวละครเหล่านี้เป็นตัวละครสมมติ ความคล้ายคลึงใดๆ กับบุคคลหรือกลุ่มบุคคล ไม่ว่าจะมีชีวิตอยู่หรือเสียชีวิตไปแล้ว เป็นเพียงเรื่องบังเอิญ... หรือไม่?

อ่านต่อ

• เฮย์มอร์, เอ. และคณะ “10 เรื่องราวจากชีวิตจริงเกี่ยวกับวิธีที่เราประนีประนอม” CI/CD pipelines "กลุ่มบริษัท NCC, มกราคม 2022
• configure-aws-credentials การกระทำของ GitHub และ การกำหนดค่า OpenID Connect ใน Amazon Web Services สำหรับรายละเอียดเกี่ยวกับวิธีการเรียกใช้คำสั่ง AWS เพื่อปรับใช้ในเวิร์กโฟลว์ของ GitHub
• โลบาเซฟสกี เจ. “การรักษาความปลอดภัยให้กับ GitHub Actions และเวิร์กโฟลว์ของคุณ ตอนที่ 1: การป้องกันคำขอเจาะระบบ”GitLab Security Lab, ธันวาคม 2020
• โลบาเซฟสกี เจ. “การรักษาความปลอดภัยให้กับ GitHub Actions และเวิร์กโฟลว์ของคุณ ตอนที่ 2: ข้อมูลนำเข้าที่ไม่น่าเชื่อถือ”GitLab Security Lab, มกราคม 2021
• โอวาเอสพี “OWASP 10 อันดับแรก” CI/CD ความเสี่ยงด้านความปลอดภัย”กรกฎาคม 2022
• ซอลท์เซอร์ เจ. และ ชโรเดอร์ เอ็ม. “การคุ้มครองข้อมูลในระบบคอมพิวเตอร์”เมษายน 1975 หลักการด้านความปลอดภัยได้พัฒนาไปพร้อมกับเทคโนโลยี แต่หลังจากผ่านไป 47 ปี แนวคิดด้านความปลอดภัยส่วนใหญ่ยังคงมีผลบังคับใช้อยู่
• ศูนย์วิทยาศาสตร์แห่งชาติสหราชอาณาจักร (UK NCSC) “รักษาความปลอดภัยในการสร้างและใช้งาน” pipeline"ศูนย์ความปลอดภัยทางไซเบอร์แห่งชาติสหราชอาณาจักร กุมภาพันธ์ 2019