STRIDE คือเฟรมเวิร์กการจำลองภัยคุกคามที่สร้างโดย Microsoft ซึ่งจัดกลุ่มความเสี่ยงด้านความปลอดภัยออกเป็นหกประเภท ได้แก่ การปลอมแปลงข้อมูล (Spoofing), การแก้ไขดัดแปลง (Tampering), การปฏิเสธความรับผิดชอบ (Repudiation), การเปิดเผยข้อมูล (Information Disclosure), การโจมตีแบบปฏิเสธการให้บริการ (Denial of Service) และการยกระดับสิทธิ์ (Elevation of Privilege) เฟรมเวิร์กนี้ช่วยให้นักพัฒนาสามารถถามคำถาม "อะไรบ้างที่อาจผิดพลาดได้?" ได้อย่างเป็นระบบในทุกขั้นตอนของวงจรชีวิตซอฟต์แวร์
เหตุใดนักพัฒนาซอฟต์แวร์ควรใช้โมเดลประเมินภัยคุกคาม STRIDE ในโครงการซอฟต์แวร์?
หากคุณกำลังจัดส่งโค้ด การจัดการ pipelineหรือการสัมผัส CI/CD ไม่ว่าในกรณีใด การสร้างแบบจำลองภัยคุกคาม STRIDE จำเป็นต้องเป็นส่วนหนึ่งของเครื่องมือของคุณ STRIDE ย่อมาจาก Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service และ Elevation of Privilege ซึ่งเป็นภัยคุกคามด้านความปลอดภัย 6 ประเภทที่นักพัฒนาต้องพิจารณาตลอดวงจรชีวิตของซอฟต์แวร์
สร้างขึ้นโดย Microsoft ในช่วงต้นทศวรรษ 2000กรอบการทำงานการสร้างแบบจำลองภัยคุกคาม STRIDE อาจดูเหมือนเป็นวิธีการแบบเก่า แต่จุดแข็งของมันอยู่ที่ความเรียบง่ายที่ไม่เปลี่ยนแปลงตามกาลเวลา: มันช่วยให้ทีมตั้งคำถามอย่างเป็นระบบว่า “อะไรบ้างที่อาจผิดพลาดได้?” แม้ว่าการส่งมอบซอฟต์แวร์จะพัฒนาไปมากแล้ว ด้วยสถาปัตยกรรมแบบคลาวด์เนทีฟ การใช้คอนเทนเนอร์ และอื่นๆ CI/CD pipelineดังนั้น STRIDE จึงยังคงมีความสำคัญอย่างยิ่ง และสอดคล้องกับความต้องการของ... อย่างสมบูรณ์แบบ DevSecOps สมัยใหม่ โดยนำเสนอวิธีการที่ใช้งานได้จริงและเป็นมิตรกับนักพัฒนา เพื่อระบุและแก้ไขความเสี่ยงด้านความปลอดภัยอย่างเชิงรุก
นี่ไม่ใช่แบบจำลองทางทฤษฎีที่สงวนไว้สำหรับการตรวจสอบหรือการวิเคราะห์หลังเกิดเหตุ แบบจำลองภัยคุกคาม STRIDE คือแผนที่ของคุณในการค้นหาจุดอ่อนก่อนที่ผู้โจมตีจะลงมือ ไม่ว่าคุณจะกำลังเขียนสคริปต์การปรับใช้ ตรวจสอบ หรือ... pull requestหรือการเชื่อมต่อบริการของบุคคลที่สาม STRIDE เปิดเผยช่องโหว่ที่ผู้โจมตีอาจใช้ประโยชน์ได้
DevSecOps หมายถึงการสร้างซอฟต์แวร์ที่ปลอดภัยตั้งแต่เริ่มต้น STRIDE ไม่ได้มีไว้เพื่อทำให้คุณช้าลง แต่มีไว้เพื่อลดปัญหาที่ไม่คาดคิดในภายหลังโดยการตรวจสอบสิ่งที่ถูกต้องในตอนนี้ การนำกรอบการทำงานการสร้างแบบจำลองภัยคุกคาม STRIDE มาใช้อย่างต่อเนื่องจะช่วยเสริมความสามารถของคุณในการคาดการณ์และแก้ไขปัญหาตั้งแต่เนิ่นๆ
สรุปโดยย่อ: หมวดหมู่ STRIDE ที่นักพัฒนาต้องเข้าใจ
โมเดลภัยคุกคาม STRIDE แบ่งภัยคุกคามออกเป็นหกประเภท โดยแต่ละประเภทสอดคล้องกับจุดอ่อนทั่วไปในซอฟต์แวร์และโครงสร้างพื้นฐาน
S: การปลอมแปลง เอกลักษณ์ (การแสร้งทำเป็นคนอื่น) ความเสี่ยง: ผู้ใช้หรือบริการที่ไม่ได้รับอนุญาตแอบอ้างเป็นบุคคลอื่น ตัวอย่างเช่น โปรแกรม CI runner ที่ถูกบุกรุกแอบอ้างเป็น deployer ที่น่าเชื่อถือและส่งการเปลี่ยนแปลงที่ไม่ปลอดภัย CI/CD สถานการณ์: ผู้โจมตีเข้าถึงเอเจนต์ CI และเรียกใช้งานโปรแกรมต่างๆ ที่ดูเหมือนจะมาจากสมาชิกทีมที่น่าเชื่อถือ
T: การงัดแงะ ความเสี่ยง: การเข้าถึงข้อมูลหรือโค้ด (การเข้าไปยุ่งเกี่ยวกับสิ่งของของคุณ) ผู้โจมตีทำการเปลี่ยนแปลงโค้ด การตั้งค่า หรือไฟล์ต่างๆ โดยที่ผู้โจมตีไม่รู้ตัว ตัวอย่างเช่น สคริปต์ที่ไม่พึงประสงค์ทำการแก้ไขอิมเมจคอนเทนเนอร์ระหว่างกระบวนการสร้าง CI/CD สถานการณ์: ขั้นตอนการสร้างระบบถูกเปลี่ยนแปลงโดยไม่แจ้งให้ทราบล่วงหน้า ทำให้ต้องปรับใช้ภาพดิสก์ที่ถูกแก้ไขจากแหล่งที่ไม่ได้รับอนุญาต
R: การปฏิเสธ (ไม่มีหลักฐานว่าใครทำอะไร) ความเสี่ยง: ขาดความรับผิดชอบหรือหลักฐานการตรวจสอบ ตัวอย่างเช่น การรวมไฟล์เกิดขึ้นโดยไม่ได้ตรวจสอบว่าใครเป็นผู้ให้การอนุมัติหรือเป็นผู้สร้างไฟล์นั้น CI/CD สถานการณ์: การสร้างและการปรับใช้ระบบทำงานโดยไม่บันทึกว่าใครเป็นผู้เริ่มต้น ทำให้ยากต่อการติดตามปัญหา
I: การเปิดเผยข้อมูล (การเปิดเผยความลับ) เสี่ยง: ข้อมูลสำคัญรั่วไหลในไฟล์บันทึก (log), ไฟล์สร้างโปรแกรม (build) หรือไฟล์ผลลัพธ์ (artifact) ตัวอย่างเช่น ข้อมูลลับถูกพิมพ์ลงในไฟล์บันทึกระหว่างการเรียกใช้สคริปต์ที่ล้มเหลว CI/CD สถานการณ์: ตัวแปรสภาพแวดล้อมที่มีข้อมูลลับถูกเปิดเผย pipeline บันทึกหรือข้อความแสดงข้อผิดพลาด
D: การปฏิเสธการให้บริการ ความเสี่ยง (การทำลายทรัพยากรของคุณ): กระบวนการหรือบริการบางอย่างไม่สามารถใช้งานได้เนื่องจากตรรกะที่ไม่ดีหรือการใช้งานในทางที่ผิด ตัวอย่างเช่น การวนลูปงานไม่สิ้นสุดทำให้คิว CI ติดขัด CI/CD สถานการณ์: การตั้งค่าที่ไม่ถูกต้อง pipeline มีการกระตุ้นการทำงานบ่อยเกินไป ทำให้ใช้ความจุของตัวรันเนอร์จนหมด
E: การยกระดับสิทธิพิเศษ ความเสี่ยง (การเข้าถึงข้อมูลเกินกว่าที่ได้รับอนุญาต): ผู้ใช้หรือบริการได้รับสิทธิ์ที่พวกเขาไม่ควรได้รับ ตัวอย่าง: A pipeline งานบางอย่างถูกเรียกใช้งานด้วยสิทธิ์การเข้าถึงระดับการผลิต ซึ่งไม่ควรจะเป็นเช่นนั้น CI/CD สถานการณ์: งานของผู้ร่วมงานคนหนึ่งถูกเรียกใช้ด้วยสิทธิ์ระดับสูงเนื่องจากการตั้งค่าการควบคุมการเข้าถึงไม่ถูกต้อง
ตารางอ้างอิงฉบับย่อสำหรับการสร้างแบบจำลองภัยคุกคามด้วย STRIDE ใน DevOps
| Category | ความเสี่ยงด้าน DevOps | ตัวอย่างในโลกแห่งความเป็นจริง |
|---|---|---|
| การปลอมแปลง | การแอบอ้างเป็นผู้ใช้หรือบริการอื่น | CI runner ปลอมตัวเป็น production deployer |
| การงัดแงะ | โค้ดหรือการเปลี่ยนแปลงการตั้งค่าที่ไม่ได้รับอนุญาต | สคริปต์ที่เป็นอันตรายในการติดตั้งใช้งาน pipeline |
| การปฏิเสธ | ไม่มีบันทึกหรือร่องรอยการตรวจสอบสำหรับการกระทำใดๆ | ผสานโดยไม่มี commit การลงนามหรือบันทึกการตรวจสอบ |
| การเปิดเผยข้อมูล | การรั่วไหลของข้อมูลลับในไฟล์บันทึกหรือไฟล์สร้างโปรแกรม | ข้อมูลประจำตัวถูกพิมพ์ลงในบันทึก CI แล้ว |
| Denial of Service | การหมดทรัพยากรหรือการหยุดชะงักของกระบวนการทำงาน | ซ้ำ pipeline งานต่างๆ มากมายจนนักวิ่งรับมือไม่ไหว |
| การยกระดับสิทธิพิเศษ | การให้สิทธิ์การเข้าถึงมากเกินไปแก่ผู้ใช้หรือกระบวนการ | dev pipeline โทเค็นที่มีสิทธิ์เข้าถึงเวอร์ชันใช้งานจริง |
การประยุกต์ใช้ STRIDE กับเวิร์กโฟลว์ DevOps
การปลอมแปลงใน DevOps CI/CD Pipelines
กระบวนการที่ไม่ได้รับอนุญาตแอบอ้างเป็นกระบวนการที่เชื่อถือได้ pipeline ขั้นตอนต่างๆ: บัญชีผู้ร่วมพัฒนาที่ถูกบุกรุกจะเผยแพร่โค้ดที่เป็นอันตรายโดยใช้ชื่อผู้ใช้ที่ดูเหมือนถูกต้อง การพึ่งพา: แพ็กเกจที่เป็นอันตรายจะใช้ชื่อที่คล้ายกับไลบรารีที่เป็นที่นิยม (typosquatting) เพื่อให้ดูน่าเชื่อถือ
การแทรกแซงใน DevOps CI/CD Pipelines
สคริปต์การปรับใช้ที่ถูกแก้ไขจะสลับคอนเทนเนอร์หรือแทรกคำสั่งที่ไม่พึงประสงค์ ที่เก็บ: บังคับพุช commitการข้ามขั้นตอนการตรวจสอบโค้ดและการแทรกช่องโหว่ ความสัมพันธ์: การอัปเดตไลบรารีที่เป็นอันตรายจะนำเสนอฟังก์ชันการทำงานที่ซ่อนอยู่
การปฏิเสธความรับผิดชอบใน DevOps CI/CD Pipelines
การปรับใช้จะถูกเรียกใช้โดยไม่บันทึกว่าใครเป็นผู้เริ่มต้น ที่เก็บ: ขาด commit การไม่ลงนามทำให้ไม่สามารถตรวจสอบที่มาของการเปลี่ยนแปลงได้ ข้อจำกัด: การเปลี่ยนแปลงแพ็กเกจถูกดึงมาโดยไม่มีบันทึกการเปลี่ยนแปลงหรือลายเซ็นที่ตรวจสอบได้
การเปิดเผยข้อมูลใน DevOps CI/CD Pipelines
ข้อมูลลับถูกเปิดเผยในเอาต์พุตบันทึกเนื่องจากการดีบักแบบละเอียด แหล่งที่มา: ไฟล์ .env หรือข้อมูลลับการกำหนดค่าโดยไม่ได้ตั้งใจ commitเชื่อมต่อกับระบบควบคุมเวอร์ชัน ส่วนประกอบที่จำเป็น: แพ็กเกจที่มีการตั้งค่าสิทธิ์ไม่ถูกต้องอาจทำให้ไฟล์สำคัญรั่วไหลได้
การโจมตีแบบปฏิเสธการให้บริการใน DevOps CI/CD Pipelines
ตัวรันเนอร์ทำงานหนักเกินไปเนื่องจากลูปทริกเกอร์ไม่สิ้นสุด ที่เก็บโค้ด: การมีส่วนร่วมที่เป็นอันตรายด้วยไฟล์ขนาดใหญ่มากหรือทริกเกอร์การสร้างที่ซับซ้อน การพึ่งพา: ไลบรารีแบบเรียกซ้ำหรือการปรับแต่งที่ไม่ดีใช้ทรัพยากรระบบมากเกินไป
การยกระดับสิทธิ์ใน DevOps CI/CD Pipelines
โทเค็นที่ใช้ร่วมกันช่วยให้งานที่ไม่ใช่ผู้ดูแลระบบสามารถทำงานด้านการดูแลระบบได้ แหล่งที่มา: Git hooks หรือสคริปต์อัตโนมัติทำงานด้วยสิทธิ์ที่ไม่จำเป็น ส่วนประกอบที่จำเป็น: ไลบรารีของบุคคลที่สามจะเรียกใช้สคริปต์การติดตั้งด้วยสิทธิ์ระดับรูทในระหว่างการสร้าง
ตัวอย่างประกอบ: ก่อนและหลังการใช้ STRIDE
ตัวอย่างการปฏิเสธความรับผิด: ไม่ลงนาม Commits
สิ่งที่กำลังได้รับการแก้ไข: ป้องกันการรวมข้อมูลที่ไม่ได้ตรวจสอบโดยการตรวจสอบยืนยัน commit ลายเซ็น
// Anyone can commit and push, no verification of who or with what identity
git commit -m "update deploy config"
git push origin main
// No branch protection: unsigned, unverified commits merge freely
// .github/settings.yml (missing or absent)ไม่มีลายเซ็น ไม่มีผู้ตรวจสอบที่จำเป็น และไม่มีวิธีใดที่จะพิสูจน์ได้ในภายหลังว่าใครเป็นผู้แก้ไข หรือว่ามีการแก้ไขเปลี่ยนแปลงระหว่างการส่งหรือไม่
// Commit signing enabled and enforced locally
git config commit.gpgsign true
git commit -S -m "update deploy config"
git push origin main
// Branch protection requires signed commits before merge
// .github/settings.yml
branches:
- name: main
protection:
required_signatures: true
required_pull_request_reviews:
required_approving_review_count: 1ตอนนี้ทุกๆ commit on main มีลายเซ็นที่ตรวจสอบได้ และไม่มีลายเซ็น commitข้อผิดพลาดจะถูกปฏิเสธในระดับสาขา ทำให้ช่องว่างการปฏิเสธสิ้นสุดลง
ตัวอย่างการเปิดเผยข้อมูล: ความลับในบันทึกข้อมูล
สิ่งที่กำลังได้รับการแก้ไข: ป้องกันการรั่วไหลของข้อมูลลับโดยหลีกเลี่ยงการพิมพ์ค่าตัวแปรสภาพแวดล้อมที่ละเอียดอ่อนโดยตรง
// CI job prints the secret directly to logs for "debugging"
steps:
- name: Deploy
run: |
echo "Using API key: $API_KEY"
curl -H "Authorization: Bearer $API_KEY" https://api.example.com/deployหากงานนี้ล้มเหลวหรือเพื่อนร่วมทีมมีสิทธิ์เข้าถึงบันทึกข้อมูล $API_KEY ขณะนี้ข้อมูลดังกล่าวอยู่ในรูปแบบข้อความธรรมดาในประวัติ CI ซึ่งทุกคนที่มีสิทธิ์อ่านสามารถมองเห็นได้ pipeline.
// Secret is referenced, never printed, and CI masks it by default
steps:
- name: Deploy
run: |
curl -H "Authorization: Bearer ${{ secrets.API_KEY }}" https://api.example.com/deploy
env:
API_KEY: ${{ secrets.API_KEY }}คีย์จะถูกดึงมาจากแหล่งเก็บข้อมูลลับของ CI ในระหว่างการทำงาน ไม่มีการแสดงผลออกทาง stdout และแพลตฟอร์ม CI ส่วนใหญ่จะซ่อนคีย์นั้นในบันทึกโดยอัตโนมัติ แม้ว่ามันจะปรากฏในเอาต์พุตโดยไม่ได้ตั้งใจก็ตาม
นักพัฒนาสามารถนำ STRIDE ไปใช้งานได้อย่างไรโดยไม่ต้องมีพื้นฐานด้านความปลอดภัย
ถ้าคุณทำงานด้าน DevSecOps การสร้างแบบจำลองภัยคุกคาม ควรกลายเป็นเรื่องที่ทำได้โดยอัตโนมัติ การใช้แบบจำลองภัยคุกคาม STRIDE เป็นแนวทางในการตรวจสอบและการตั้งค่าระบบอัตโนมัติ จะช่วยให้คุณสามารถคาดการณ์ปัญหาได้ก่อนที่จะเกิดขึ้นจริงในระบบการผลิต
คุณไม่จำเป็นต้องเป็นผู้เชี่ยวชาญด้านความปลอดภัย เพียงแค่ตั้งคำถามตามหลักการ STRIDE ในระหว่างขั้นตอนการทำงานปกติของคุณ:
ระหว่างการตรวจสอบโค้ด:
- มีใครสามารถปลอมแปลงตัวตนในที่นี้ได้หรือไม่?
- สามารถมีการดัดแปลงแก้ไขสิ่งนี้ได้หรือไม่?
ในระหว่าง CI/CD ทบทวน:
- มีการเปิดเผยความลับที่ไหนบ้างหรือไม่?
- ทุกการกระทำสามารถตรวจสอบย้อนหลังได้หรือไม่?
ระหว่างการวิเคราะห์ความสัมพันธ์:
- เราดึงข้อมูลมาจากแหล่งที่เชื่อถือได้หรือไม่?
- การพึ่งพาอาศัยกันนี้สามารถเพิ่มสิทธิ์การเข้าถึงได้หรือไม่?
จากนั้นก็ทำการอัตโนมัติในส่วนที่ทำได้:
- ใช้ลายเซ็น commits
- ดำเนินการลงนามอาร์ติแฟกต์
- ตั้งค่าการสแกนความลับ
- ตรวจสอบการอัปเดตการพึ่งพา
ขั้นตอนเล็กๆ เหล่านี้ช่วยให้สามารถนำแบบจำลองภัยคุกคาม STRIDE ไปใช้ได้อย่างมีประสิทธิภาพโดยไม่ต้องเสียค่าใช้จ่ายเพิ่มเติม
ก่อนที่จะนำการสร้างแบบจำลองภัยคุกคาม STRIDE มาใช้อย่างสม่ำเสมอ ควรทำความเข้าใจก่อนว่าควรใช้เมื่อใดและที่ใดในขั้นตอนการทำงานของคุณ
คู่มือฉบับสมบูรณ์สำหรับการปกป้องของคุณ CI/CD Pipeline
เรียนรู้วิธีการระบุ ป้องกัน และรับมือกับ CI/CD ความเสี่ยงด้านความปลอดภัย
การบูรณาการ STRIDE เข้าสู่กระบวนการสร้างแบบจำลองภัยคุกคาม
STRIDE เข้ากับวงจรการพัฒนาได้อย่างลงตัว ในฐานะเครื่องมือที่มีน้ำหนักเบาและใช้งานซ้ำได้ สำหรับการระบุภัยคุกคามด้านความปลอดภัยที่อาจเกิดขึ้นตั้งแต่เนิ่นๆ จะมีประสิทธิภาพสูงสุดเมื่อนำไปใช้อย่างสม่ำเสมอในขั้นตอนสำคัญๆ:
- ระหว่างการตรวจสอบโค้ดถามคำถามเช่น “ข้อมูลนี้สามารถปลอมแปลงหรือแก้ไขได้หรือไม่?” หรือ “มีบันทึกการตรวจสอบการเปลี่ยนแปลงนี้หรือไม่?”
- ขณะทำการตั้งค่า CI/CD Pipelinesประเมินว่า ความลับถูกเปิดเผยหากสามารถตรวจสอบย้อนกลับงานได้ หรือหากขอบเขตการอนุญาตกว้างเกินไป
- In การจัดการการพึ่งพาตรวจสอบว่าแพ็กเกจจากผู้พัฒนาภายนอกได้รับการตรวจสอบ รับรอง และปราศจากสคริปต์การติดตั้งที่เป็นอันตรายหรือการเข้าถึงที่มากเกินไปหรือไม่
- เมื่อวางแผนฟีเจอร์หรือบริการใหม่ๆใช้กรอบการสร้างแบบจำลองภัยคุกคาม STRIDE เป็นรายการตรวจสอบเพื่อระดมความคิดเกี่ยวกับสิ่งที่อาจผิดพลาดได้จากแต่ละหมวดหมู่ภัยคุกคาม
สิ่งนี้ทำให้การสร้างแบบจำลองภัยคุกคาม STRIDE เป็นส่วนหนึ่งของความพยายามด้านความปลอดภัยของคุณที่ใช้งานได้จริงและนำไปปฏิบัติได้ ไม่ใช่กระบวนการที่ยุ่งยากซับซ้อน แต่เป็นแนวคิดที่ฝังอยู่ในการพัฒนาและการดำเนินงาน DevOps ในแต่ละวันของคุณ
Xygeni สอดคล้องกับแต่ละหมวดหมู่ของ STRIDE อย่างไร
Xygeni ไม่เพียงแต่แจ้งเตือนความเสี่ยง แต่ยังดำเนินการแก้ไขความเสี่ยงเหล่านั้นอย่างครบวงจร pipeline.
นี่เป็นวิธีการ ของไซเกนี แผนที่การตรวจจับสำหรับแต่ละหมวดหมู่ STRIDE ในสภาพแวดล้อมจริง pipeline:
- การปลอมแปลง: ธงตรวจจับความผิดปกติของ Xygeni CI/CD การใช้โทเค็นในทางที่ผิดและการแอบอ้างตัวตนที่น่าเชื่อถือจะแจ้งเตือนทีมเพื่อให้มีการหมุนเวียนข้อมูลประจำตัวก่อนที่งานจะเริ่มทำงาน
- การงัดแงะ: ระบบตรวจจับการดัดแปลงโค้ดของ Xygeni จะระบุการเปลี่ยนแปลงที่ไม่ได้รับอนุญาตในไฟล์ YAML สำหรับการปรับใช้ ไฟล์บิลด์ และอื่นๆ IaC เทมเพลต และแจ้งให้ทีมทราบด้วยรายละเอียดเฉพาะ commit และไฟล์ที่ได้รับผลกระทบ
- การปฏิเสธ: ธง Xygeni ที่ไม่มีลายเซ็น commitและการผลักดันแบบบังคับที่ข้ามการป้องกันสาขา ทำให้ทีมสามารถมองเห็นและบังคับใช้ลายเซ็นได้commit นโยบายก่อนการควบรวมกิจการ
- การเปิดเผยข้อมูล: ระบบสแกนความลับของ Xygeni ตรวจจับข้อมูลประจำตัวที่ถูกเปิดเผยในบันทึก ข้อมูลโค้ด และประวัติ CI ตรวจสอบว่าข้อมูลเหล่านั้นยังคงใช้งานอยู่หรือไม่ และดำเนินการเพิกถอนโดยอัตโนมัติสำหรับประเภทความลับที่รองรับ
- การปฏิเสธการให้บริการ: ระบบตรวจจับความผิดปกติของ Xygeni ระบุสิ่งผิดปกติ CI/CD ระบบจะตรวจจับกิจกรรมที่ผิดปกติ เช่น ระยะเวลาการสร้างหรือความถี่ในการทำงานที่ไม่ปกติ และแจ้งเตือนทีมแบบเรียลไทม์
- การยกระดับสิทธิพิเศษ: ระบบตรวจสอบสิทธิ์ขั้นต่ำของ Xygeni จะระบุผู้ใช้ที่มีสิทธิ์มากเกินไปหรือผู้ใช้ที่ไม่ได้ใช้งาน และ CI/CD โทเค็น และนำเสนอโทเค็นเหล่านั้นเพื่อการแก้ไขผ่านทาง Health Check ลักษณะ
สรุป: STRIDE ทำให้การสร้างแบบจำลองภัยคุกคามเป็นเรื่องที่ใช้งานได้จริงสำหรับนักพัฒนา
กรอบการทำงานการสร้างแบบจำลองภัยคุกคาม STRIDE ช่วยให้นักพัฒนาสามารถมองเห็นความเสี่ยงได้อย่างชัดเจนและนำไปปฏิบัติได้จริงตั้งแต่เนิ่นๆ อย่าคิดมากเกินไป เพียงแค่ถามว่า “อะไรบ้างที่อาจผิดพลาดได้ในส่วนนี้?” สำหรับทุกส่วนของโค้ดและที่เก็บโค้ดของคุณ pipelineหรือความสัมพันธ์แบบพึ่งพา
เครื่องมือวิเคราะห์ภัยคุกคาม STRIDE ช่วยให้คุณแก้ไขข้อบกพร่องด้านความปลอดภัยก่อนที่จะเกิดขึ้นจริง และเครื่องมืออย่าง Xygeni ช่วยให้คุณดำเนินการดังกล่าวโดยอัตโนมัติโดยไม่เพิ่มอุปสรรคใดๆ
นำแบบจำลองภัยคุกคาม STRIDE มาเป็นส่วนหนึ่งของวิธีการเขียน ตรวจสอบ และส่งมอบโค้ดของคุณ การสร้างแบบจำลองภัยคุกคาม STRIDE อย่างต่อเนื่องจะช่วยให้คุณรักษาความปลอดภัยไว้ได้ pipelineมีความปลอดภัย แม้ว่าจะมีการขยายขนาดและพัฒนาไปเรื่อยๆ ก็ตาม
คำถามที่พบบ่อย
STRIDE ย่อมาจากอะไร?
การปลอมแปลงข้อมูล การดัดแปลงข้อมูล การปฏิเสธความรับผิดชอบ การเปิดเผยข้อมูล การโจมตีแบบปฏิเสธการให้บริการ และการยกระดับสิทธิ์ เป็น 6 หมวดหมู่ที่ Microsoft สร้างขึ้นเพื่อจัดระเบียบภัยคุกคามด้านความปลอดภัย
ฉันจำเป็นต้องมีพื้นฐานด้านความปลอดภัยเพื่อใช้ STRIDE หรือไม่?
ไม่ STRIDE ทำงานเหมือนเช็คลิสต์คำถาม เช่น “สามารถปลอมแปลงโค้ดส่วนนี้ได้หรือไม่?” หรือ “สามารถตรวจสอบที่มาของโค้ดได้หรือไม่?” ซึ่งนักพัฒนาสามารถนำไปใช้ในระหว่างการตรวจสอบโค้ดตามปกติได้ CI/CD องค์ประกอบ
STRIDE ยังคงมีความสำคัญสำหรับแอปพลิเคชันบนคลาวด์อยู่หรือไม่? CI/CD สภาพแวดล้อม?
ใช่แล้ว แม้ว่าจะถูกสร้างขึ้นก่อนยุคคอนเทนเนอร์ก็ตาม CI/CD คือ standardหมวดหมู่ทั้งหกของ STRIDE สอดคล้องโดยตรงกับยุคสมัยใหม่ pipeline ความเสี่ยงต่างๆ เช่น การใช้โทเค็นในทางที่ผิด การไม่ลงนาม commitและการเปิดเผยความลับ
