สารบัญ
Zero Trust คือแนวทางปฏิวัติวงการที่ท้าทายแนวคิดเรื่องความไว้วางใจโดยปริยายแบบเก่าๆ โดยเรียกร้องให้มีการตรวจสอบและยืนยันอย่างต่อเนื่อง Zero Trust จึงปรากฏขึ้นเป็นแสงแห่งความหวังในเขาวงกตแห่งความซับซ้อน Software Supply Chain Security (SSCS) ซึ่งความไว้วางใจเป็นสิ่งที่มีค่าอย่างยิ่ง การละทิ้งสมมติฐานแบบเก่าๆ และหันมาพิจารณาผู้ใช้ อุปกรณ์ และแอปพลิเคชันทุกตัวอย่างรอบคอบ โดยเฉพาะอย่างยิ่งในการรักษาความสมบูรณ์ของซอฟต์แวร์และแหล่งเก็บข้อมูล—องค์ประกอบพื้นฐานของซอฟต์แวร์ที่ปลอดภัยร่วมเดินทางไปกับเราสู่โลกแห่งความปลอดภัยที่มั่นคงไร้สั่นคลอน ในขณะที่เราเจาะลึกเข้าไปในโลกของ Zero Trust และ SSCSที่ซึ่งความไว้วางใจต้องได้รับมาจากการกระทำ ไม่ใช่การสันนิษฐานเอาเอง
ความไว้วางใจเป็นศูนย์ใน SSCSยกระดับความปลอดภัยด้วยความซื่อสัตย์สุจริตอย่างไม่เปลี่ยนแปลง
Zero Trust ได้กลายเป็นกรอบการรักษาความปลอดภัยที่ได้รับการยอมรับอย่างกว้างขวาง องค์กรหลายแห่งได้นำหลักการของ Zero Trust มาใช้เพื่อปรับปรุงสถานะความปลอดภัยของตนในโลกดิจิทัลที่เชื่อมโยงถึงกันและซับซ้อนมากขึ้น ตามข้อมูลจากแหล่งหนึ่ง การสำรวจอาร์มิส33% ของผู้เชี่ยวชาญด้านไอทีคาดว่าองค์กรของตนจะนำโมเดล Zero Trust มาใช้ในปี 2023 แนวคิดนี้มีความสำคัญอย่างยิ่งในด้านต่างๆ ดังนี้ SSCSซึ่งความสมบูรณ์ของไฟล์ซอฟต์แวร์และที่เก็บข้อมูลของไฟล์เหล่านั้นมีความสำคัญอย่างยิ่ง
เมื่อเราหันความสนใจไปที่ขอบเขตของ Software Supply Chain Security (SSCSในส่วนนี้ เราจะมุ่งเน้นไปที่ความสมบูรณ์ของซอฟต์แวร์และแหล่งเก็บข้อมูลที่จัดเก็บซอฟต์แวร์เหล่านั้น ในขอบเขตนี้ ความไว้วางใจไม่ใช่สิ่งที่เกิดขึ้นเอง แต่เป็นผลโดยตรงจากความซื่อสัตย์สุจริตที่ไม่เปลี่ยนแปลง เมื่อซอฟต์แวร์เคลื่อนที่ผ่านแหล่งเก็บข้อมูลต่างๆ ผ่านการพัฒนาและการบูรณาการอย่างต่อเนื่อง พวกมันจะร่วมกันกำหนดรูปร่างของผลิตภัณฑ์ขั้นสุดท้าย
ในกระบวนการที่ซับซ้อนนี้ การรับประกันความสมบูรณ์ไร้ที่ติของโบราณวัตถุและแหล่งเก็บรักษาเหล่านี้มีความสำคัญยิ่ง เนื่องจากความสมบูรณ์นี้เองที่สร้างความไว้วางใจ
โมเดล Zero Trust ตั้งอยู่บนสมมติฐานที่ว่าภัยคุกคามสามารถเกิดขึ้นได้ทั้งภายนอกและภายในเครือข่ายขององค์กร โดยเน้นย้ำว่าความไว้วางใจไม่ควรเป็นไปโดยปริยาย
หลักการสำคัญของปรัชญา Zero Trust ในบริบทของห่วงโซ่อุปทานซอฟต์แวร์ ได้แก่:
- ตรวจสอบทุกอย่าง อย่าไว้ใจอะไรทั้งนั้น หลักการนี้เป็นรากฐานสำคัญของ Zero Trust และใช้ได้กับห่วงโซ่อุปทานซอฟต์แวร์ด้วยเช่นกัน ทุกๆ ส่วนประกอบของซอฟต์แวร์ ตั้งแต่ซอร์สโค้ดไปจนถึงไฟล์ไบนารีที่ใช้งานจริง ควรได้รับการตรวจสอบความถูกต้องและความสมบูรณ์ก่อนนำไปใช้งาน
- การเข้าถึงสิทธิ์ขั้นต่ำสุด ให้สิทธิ์การเข้าถึงแก่ผู้ใช้และระบบเฉพาะเท่าที่จำเป็นต่อการปฏิบัติงานเท่านั้น วิธีนี้จะช่วยลดความเสี่ยงจากการโจมตีและป้องกันผู้ไม่ประสงค์ดีจากการเข้าถึงทรัพยากรที่สำคัญ
การติดตามและวิเคราะห์อย่างต่อเนื่อง Zero Trust ไม่ใช่แนวทางการรักษาความปลอดภัยแบบตั้งค่าแล้วไม่ต้องดูแลอีกต่อไป แต่ต้องมีการตรวจสอบและวิเคราะห์ห่วงโซ่อุปทานซอฟต์แวร์อย่างต่อเนื่องเพื่อระบุและตอบสนองต่อภัยคุกคาม
จะนำหลักการ Zero Trust มาใช้ในห่วงโซ่อุปทานซอฟต์แวร์ได้อย่างไร?
มาตรการป้องกัน: การเสริมความแข็งแกร่งให้กับกระบวนการผลิตซอฟต์แวร์
เพื่อนำ Zero Trust ไปใช้อย่างมีประสิทธิภาพใน SSCSดังนั้น มาตรการป้องกันที่ครอบคลุมจึงเป็นสิ่งสำคัญ การปกป้องกระบวนการผลิตซอฟต์แวร์จากการดัดแปลงที่เป็นอันตรายและการป้องกันการนำโค้ดอัปเดตที่เป็นอันตรายเข้ามา จำเป็นต้องใช้กลยุทธ์การป้องกันที่สำคัญ:
การควบคุมการเข้าถึง:
- นำระบบควบคุมการเข้าถึงตามบทบาท (RBAC) มาใช้เพื่อจำกัดการเข้าถึงคลังเก็บโค้ดและสภาพแวดล้อมการสร้างโปรแกรม โดยอิงตามบทบาทและสิทธิ์ของผู้ใช้
- ใช้การยืนยันตัวตนสองขั้นตอน (2FA) เพื่อเพิ่มความแข็งแกร่งในการยืนยันตัวตนและทำให้ผู้โจมตีเข้าถึงข้อมูลโดยไม่ได้รับอนุญาตได้ยากขึ้น
- ใช้หลักการเข้าถึงแบบจำกัดสิทธิ์ขั้นต่ำ เพื่อให้ผู้ใช้ สคริปต์ หรือระบบเชื่อมต่อต่างๆ สามารถเข้าถึงเฉพาะทรัพยากรที่จำเป็นต่อการทำงานของตนเท่านั้น
การลงนามเอกสาร:
- กำหนดให้ต้องมีการลงนามสำหรับซอฟต์แวร์ทุกเวอร์ชันที่จะนำไปใช้งานจริง
- ใช้หน่วยงานออกลายเซ็นที่เชื่อถือได้ (CA) เพื่อตรวจสอบความถูกต้องของลายเซ็นในแต่ละส่วนประกอบ
- นำระบบตรวจสอบลายเซ็นอัตโนมัติมาใช้เพื่อให้มั่นใจว่าไฟล์ซอฟต์แวร์ทั้งหมดได้รับการลงนามก่อนที่จะนำไปใช้งาน
ด้วยการนำระบบการลงนามมาใช้ องค์กรต่างๆ สามารถลดความเสี่ยงที่โค้ดที่เป็นอันตรายจะแทรกซึมเข้ามาในห่วงโซ่อุปทานซอฟต์แวร์ได้
การตรวจจับโค้ดที่เป็นอันตราย:
- ใช้การวิเคราะห์แบบคงที่เพื่อตรวจจับโค้ดที่เป็นอันตรายใน pipelineและสิ่งประดิษฐ์ทางซอฟต์แวร์
- นำเทคนิคแซนด์บ็อกซ์และเทคนิคอื่นๆ มาใช้เพื่อแยกและวิเคราะห์ส่วนประกอบซอฟต์แวร์ก่อนที่จะนำไปใช้งานจริง
การรับประกันความสมบูรณ์: การรักษาความบริสุทธิ์ของส่วนประกอบซอฟต์แวร์
ความไว้วางใจเป็นศูนย์ใน SSCS ขอบเขตของการดำเนินการนี้ครอบคลุมมากกว่าแค่การป้องกันการโจมตีที่เป็นอันตราย แต่ยังรวมถึงการรับประกันความสมบูรณ์ของซอฟต์แวร์อย่างไม่เปลี่ยนแปลงตลอดวงจรการพัฒนา ซึ่งประกอบด้วย:
การติดตามแหล่งที่มาและการรับรอง:
- พัฒนาระบบเพื่อติดตามที่มาและการแก้ไขของซอฟต์แวร์ทุกส่วนตลอดวงจรการพัฒนา ซึ่งสามารถทำได้โดยใช้วิธีการต่างๆ เช่น เทคโนโลยีบล็อกเชน การทำลายน้ำดิจิทัล และลายเซ็นแบบแฮช
- ใช้การติดตามแหล่งที่มาเพื่อระบุและตรวจสอบกิจกรรมที่น่าสงสัยในห่วงโซ่อุปทานซอฟต์แวร์ ตัวอย่างเช่น หากมีการดัดแปลงซอฟต์แวร์โดยไม่ได้รับอนุญาต การติดตามแหล่งที่มาสามารถใช้เพื่อติดตามแหล่งที่มาของการดัดแปลงและดำเนินการแก้ไขได้
ด้วยการติดตามที่มาและการดัดแปลงของซอฟต์แวร์ องค์กรต่างๆ สามารถทำให้ผู้โจมตีซ่อนกิจกรรมที่เป็นอันตรายได้ยากขึ้น ตัวอย่างเช่น หาก SolarWinds ได้นำระบบติดตามที่มามาใช้ ก็จะสามารถระบุแหล่งที่มาของโค้ดที่เป็นอันตรายที่ถูกแทรกเข้าไปใน Orion SDK ได้ง่ายขึ้น
การสร้างที่สามารถทำซ้ำได้:
- สร้างสภาพแวดล้อมการสร้างซอฟต์แวร์ที่สามารถสร้างผลลัพธ์ซ้ำได้ โดยสร้างไฟล์ซอฟต์แวร์ที่เหมือนกันทุกประการจากซอร์สโค้ดเดียวกัน สามารถทำได้โดยใช้เครื่องมือต่างๆ เช่น Docker และ Packer เพื่อสร้างสภาพแวดล้อมการสร้างซอฟต์แวร์ที่ไม่สามารถเปลี่ยนแปลงได้
- ใช้การสร้างเวอร์ชันที่ทำซ้ำได้เพื่อตรวจสอบความสมบูรณ์ของซอฟต์แวร์ในแต่ละขั้นตอนของวงจรการพัฒนา ตัวอย่างเช่น คุณสามารถใช้ค่าตรวจสอบ (checksum) เพื่อตรวจสอบว่าซอฟต์แวร์นั้นไม่ได้ถูกแก้ไขเปลี่ยนแปลงนับตั้งแต่ถูกสร้างขึ้น
ด้วยการนำระบบการสร้างซอฟต์แวร์ที่สามารถทำซ้ำได้มาใช้ องค์กรต่างๆ สามารถลดความเสี่ยงที่โค้ดที่เป็นอันตรายจะถูกแทรกเข้าไปในห่วงโซ่อุปทานซอฟต์แวร์ระหว่างกระบวนการสร้างได้ ตัวอย่างเช่น ในปี 2020 ซอฟต์แวร์ SolarWinds Orion ถูกกลุ่มจารกรรมทางไซเบอร์ชาวรัสเซียโจมตี ผู้โจมตีสามารถแทรกโค้ดที่เป็นอันตรายเข้าไปในซอฟต์แวร์ ซึ่งต่อมาได้ถูกเผยแพร่ไปยังลูกค้าของ SolarWinds ทั่วโลก การโจมตีครั้งนี้ประสบความสำเร็จเนื่องจากสภาพแวดล้อมการสร้างซอฟต์แวร์ของ SolarWinds ไม่สามารถทำซ้ำได้
หาก SolarWinds ได้นำระบบการสร้างเวอร์ชันที่สามารถสร้างซ้ำได้มาใช้ในการโจมตี ผู้โจมตีก็จะไม่สามารถแทรกโค้ดที่เป็นอันตรายเข้าไปในซอฟต์แวร์ได้โดยไม่ถูกตรวจจับ
การตรวจสอบความสมบูรณ์ของสิ่งประดิษฐ์:
ใช้ลายเซ็นดิจิทัลและแฮชเข้ารหัสลับเพื่อตรวจสอบความถูกต้องของส่วนประกอบซอฟต์แวร์ในแต่ละขั้นตอนของวงจรการพัฒนา สามารถทำได้โดยใช้เครื่องมือต่างๆ เช่น Xygeni Build Security.
- ใช้การตรวจสอบความสมบูรณ์ของไฟล์ซอฟต์แวร์เพื่อตรวจจับการแก้ไขที่ไม่ได้รับอนุญาตต่อไฟล์ซอฟต์แวร์ ตัวอย่างเช่น หากไฟล์ซอฟต์แวร์ถูกแก้ไขโดยไม่ได้รับอนุญาต การตรวจสอบความสมบูรณ์ของไฟล์ซอฟต์แวร์จะตรวจพบการเปลี่ยนแปลงและสร้างการแจ้งเตือน
ด้วยการนำมาตรการตรวจสอบความสมบูรณ์ของสิ่งประดิษฐ์มาใช้ องค์กรต่างๆ สามารถลดความเสี่ยงที่โค้ดที่เป็นอันตรายจะแทรกซึมเข้ามาในห่วงโซ่อุปทานซอฟต์แวร์ในทุกขั้นตอนของกระบวนการพัฒนาและการส่งมอบได้
ด้านล่างนี้เป็นตัวอย่างวิธีการบูรณาการมาตรการต่างๆ เข้าด้วยกัน CI/CD pipeline:
- 1. การตรวจสอบผู้ใช้ผู้ใช้เข้าสู่ระบบโดยใช้การยืนยันตัวตนสองขั้นตอน (2FA) เพื่อเพิ่มความปลอดภัย
- 2. การตรวจสอบการควบคุมการเข้าถึงตามบทบาท (RBAC): การจัดการซอร์สโค้ด (SCMระบบจะตรวจสอบว่าผู้ใช้มีสิทธิ์ที่จำเป็นหรือไม่ commit การเปลี่ยนแปลง
- 3 รหัส Commit: ผู้ใช้ที่ได้รับอนุญาต commitมีการเปลี่ยนแปลงโค้ดใหม่ในที่เก็บโค้ด ทำให้เกิดการเปลี่ยนแปลงขึ้น CI/CD pipeline.
- 4. การตรวจสอบการปฏิบัติตามข้อกำหนดและการประกันคุณภาพ: โค้ดดังกล่าวได้รับการทดสอบเพื่อให้เป็นไปตามมาตรฐานการเขียนโค้ด standardและการประกันคุณภาพโดยรวม
- 5. ความลับ & IaC การสแกน: การขอ pipeline ตรวจสอบหาข้อมูลลับที่ถูกกำหนดไว้ตายตัว เช่น รหัสผ่านหรือคีย์ API เพื่อป้องกันการละเมิดความปลอดภัย
- 6. การตรวจจับโค้ดที่เป็นอันตรายเครื่องมือวิเคราะห์แบบคงที่ (Static analysis tools) จะสแกนโค้ดเบสเพื่อหารูปแบบที่บ่งชี้ถึงโค้ดที่เป็นอันตราย เช่น แบ็กดอร์ หรือภัยคุกคามด้านความปลอดภัยอื่นๆ เพื่อให้มั่นใจในความสมบูรณ์และความปลอดภัยของโค้ด
- 7. การสแกนช่องโหว่: การขอ pipeline สแกนโค้ดเบสและส่วนประกอบต่างๆ เพื่อหาช่องโหว่ที่ทราบแล้ว
- 8. การตรวจสอบความถูกต้องของลายเซ็น: ลายเซ็นของส่วนประกอบทั้งหมดที่ใช้ในการผสานรวมจะได้รับการตรวจสอบความถูกต้อง เพื่อให้มั่นใจในความน่าเชื่อถือ
- 9. การสร้างเอกสารรับรองเมื่อการทดสอบทั้งหมดเสร็จสิ้นอย่างประสบความสำเร็จ ระบบจะสร้างรายงานรับรอง ซึ่งรับรองความปลอดภัยและความสมบูรณ์ของผลิตภัณฑ์ขั้นสุดท้าย
- 10. การเตรียมการจัดจำหน่ายผลิตภัณฑ์: ผลิตภัณฑ์ที่ผ่านการรับรองพร้อมสำหรับการจัดจำหน่ายให้กับลูกค้าปลายทาง เพื่อให้มั่นใจว่าลูกค้าจะได้รับผลิตภัณฑ์ที่ปลอดภัยและได้รับการตรวจสอบแล้ว
ความสามารถในการปรับตัวและความอเนกประสงค์: กรอบแนวคิดสำหรับสภาพแวดล้อมที่หลากหลาย
กรอบการทำงาน Zero Trust สำหรับ SSCS ต้องมีความแข็งแกร่งและปรับตัวได้ รองรับสภาพแวดล้อมการพัฒนาซอฟต์แวร์ที่หลากหลาย ตั้งแต่สถาปัตยกรรมไมโครเซอร์วิสบนคลาวด์ไปจนถึงแบบดั้งเดิม on-premiseระบบต่างๆ การปฏิบัติตาม standard โครงสร้างหลักฐาน เช่น เมตาเดตาและลายเซ็นดิจิทัล ช่วยให้สามารถทำงานร่วมกันได้ และผสานรวมเข้ากับเครื่องมือรักษาความปลอดภัยที่มีอยู่ได้อย่างราบรื่น
ในยุคที่การละเมิดความปลอดภัยและช่องโหว่ต่างๆ เพิ่มมากขึ้น การนำแนวคิด Zero Trust มาใช้ในบริบทของ... Software Supply Chain Security เป็นการดำเนินการเชิงรุกเพื่อรักษาความสมบูรณ์และความน่าเชื่อถือของซอฟต์แวร์ของคุณ ด้วยการบูรณาการมาตรการป้องกันและรับรองความสมบูรณ์ในทุกระดับ องค์กรต่างๆ สามารถสร้างระบบซอฟต์แวร์ที่ปลอดภัย ยืดหยุ่น และเชื่อถือได้ ปกป้องสินทรัพย์ดิจิทัลและเสริมสร้างความแข็งแกร่งให้กับห่วงโซ่อุปทานซอฟต์แวร์เพื่อรับมือกับภัยคุกคามที่อาจเกิดขึ้น
ศูนย์ความไว้วางใจและ SSCS ร่วมกันสร้างรากฐานที่แข็งแกร่งสำหรับกลยุทธ์ด้านความปลอดภัยเป็นอันดับแรกในอนาคตที่ความปลอดภัยมีความสำคัญยิ่ง องค์กรต่างๆ สามารถรับมือกับระบบนิเวศดิจิทัลที่เปลี่ยนแปลงอยู่ตลอดเวลาได้อย่างมั่นใจและยืดหยุ่น โดยมุ่งเน้นที่ความซื่อสัตย์และความน่าเชื่อถือ
