วิธีที่ DevSecOps มอบอำนาจให้นักพัฒนาพลเมือง

ภายในปี 2025 ทั้งหมด การสร้างข้อมูลทั่วโลก จะถึง 181 เซตตะไบต์ สำหรับองค์กร ข้อมูลดังกล่าวเป็นทรัพย์สินที่ช่วยให้พวกเขาใช้ประโยชน์จากแพลตฟอร์มเทคโนโลยีที่หลากหลาย เพื่อสร้างประสบการณ์ลูกค้าที่เป็นส่วนตัวสูง ซึ่งสร้างความภักดีและดึงดูดธุรกิจใหม่ๆ อย่างไรก็ตาม ประสบการณ์เหล่านี้ขึ้นอยู่กับโครงสร้างพื้นฐานคลาวด์ที่ใช้โหมดความปลอดภัยที่ใช้ร่วมกัน นั่นคือจุดที่ความเสี่ยงอยู่ และมันเพิ่มมากขึ้นเมื่อเทคโนโลยีเติบโตขึ้นเพื่อรวมกองทัพนักพัฒนาพลเมืองชุดใหม่ที่ใช้แพลตฟอร์มแบบเขียนโค้ดต่ำและไม่ต้องเขียนโค้ด

การทำความเข้าใจและการเอาชนะกรอบความคิดแบบสืบทอด 

Gartner ประมาณการว่าภายในปี 2025 แอปพลิเคชันระดับองค์กร 70% จะถูกสร้างขึ้นจากแพลตฟอร์มที่ใช้โค้ดน้อยและไม่ต้องเขียนโค้ด เช่น Salesforce และ ServiceNow การตอบสนองด้วยกรอบความคิดแบบอิงมรดกเป็นวิธีที่แน่นอนในการตั้งค่าแอประดับองค์กรมากกว่าสองในสามให้พร้อมรับความล้มเหลว   

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

เมื่อคุณมีกรอบความคิดแบบเดิม คุณจะถือว่าโครงสร้างพื้นฐานได้รับการตั้งค่าแล้ว แพลตฟอร์มนี้ปลอดภัยและมีการรักษาความปลอดภัยในตัว เชื่อถือได้ง่าย ๆ เพราะมีเทคโนโลยีอยู่ก่อนผู้ดูแลระบบ

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

สมมติว่านักพัฒนา Salesforce สร้างโปรแกรมการมอบหมายงานอัตโนมัติสำหรับลูกค้าเป้าหมายใหม่ พวกเขาใช้ภายใน Salesforce เพื่อมอบหมายงานภายใน และมันก็ไม่เป็นไร พวกเขาสามารถพึ่งพาความปลอดภัยของแพลตฟอร์มได้ พวกเขาตัดสินใจที่จะขยายเพื่อปรับปรุงระบบอัตโนมัติ พวกเขาเชื่อมต่อโปรแกรมนั้นกับ CRM ภายนอก เช่น ServiceNow, SAP หรือ Oracle แนวคิดเรื่องการสืบทอดเข้ามาครอบงำ: Salesforce ปลอดภัย ServiceNow, SAP หรือบุคคลที่สามปลอดภัย

ดังนั้น Salesforce + บุคคลที่สาม = ปลอดภัย

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

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

ทางออกเดียวคือนำการพัฒนานั้นกลับคืนสู่พื้นดินโดยกลับคืนสู่หลักการ DevSecOps

การสร้างกรอบงาน DevSecOps 

DevSecOps กรอบงานได้ถูกเขียน เขียนใหม่ และเขียนอีกครั้งตั้งแต่มีการสร้างแนวคิด ไม่จำเป็นต้องประดิษฐ์วงล้อขึ้นมาใหม่เมื่อทำการก่อตั้ง โดยเฉพาะเมื่อ SAFECode และ Cloud Security Alliance ได้สร้างเสาหลักไว้ XNUMX เสา คือ

1. ความรับผิดชอบร่วมกัน: การรักษาความปลอดภัยเป็นความรับผิดชอบของทุกคนในองค์กร แต่ผู้คนไม่สามารถปฏิบัติตามมาตรฐานที่พวกเขาไม่รู้ได้ ควรมอบหมายโอกาสในการขายเพื่อขับเคลื่อนนโยบายความปลอดภัยทางไซเบอร์และให้แน่ใจว่ามีการเผยแพร่ทั่วทั้งองค์กร  
2. การทำงานร่วมกันและการบูรณาการ: ความรู้ต้องแบ่งปันและถ่ายทอด ครึ่งหนึ่งของเหตุผลที่องค์กรต่างๆ ตกอยู่ในกรอบความคิดแบบเดิมก็คือ ทุกคนที่รู้จักระบบเก่าได้สูญสิ้นไปแล้ว การแบ่งปันความรู้อย่างต่อเนื่องช่วยขจัดปัญหานี้
3. การนำไปปฏิบัติจริง: การใช้งานเชิงปฏิบัติเชื่อมโยงกับประสบการณ์ของนักพัฒนา กระบวนการที่ยาก ธรรมดา และเทอะทะมักไม่ปฏิบัติตามเป็นเวลานาน การรักษาความปลอดภัยควรรวมอยู่ในแนวปฏิบัติในการพัฒนา — นั่นคือโค้ดทุกบรรทัดต้องมีการทดสอบ องค์กรที่มีประสิทธิภาพสูงจะนำสิ่งนั้นไปไกลกว่านี้โดยใช้เครื่องมือเพื่อทำให้โค้ดทดสอบแต่ละบรรทัดเป็นแบบอัตโนมัติ
4. การปฏิบัติตามกฎระเบียบและการพัฒนา: ข้อกำหนดการปฏิบัติตามควรเป็นแนวทางให้กับกระบวนการพัฒนาในลักษณะที่ไม่อนุญาตให้นักพัฒนาเบี่ยงเบนไปจากข้อกำหนดเหล่านั้น ตัวอย่างเช่น นักพัฒนาสถาบันการเงินจะทำงานบนแพลตฟอร์มที่ออกแบบมาให้สอดคล้องกับกฎหมาย Gramm-Leach-Bliley นักพัฒนาซอฟต์แวร์ไม่จำเป็นต้องทราบรายละเอียดของแต่ละบุคคลเพื่อให้เป็นไปตามข้อกำหนด เนื่องจากสิ่งเหล่านั้นถูกสร้างไว้ในแพลตฟอร์ม  
5. อัตโนมัติ: งานที่คาดเดาได้ ทำซ้ำได้ และมีปริมาณมากควรเป็นอัตโนมัติทุกครั้งที่เป็นไปได้ เพื่อขจัดภาระจากนักพัฒนา และลดความเสี่ยงของข้อผิดพลาดของมนุษย์
6. การตรวจสอบ: โครงสร้างพื้นฐานคลาวด์สมัยใหม่เปลี่ยนแปลงและเติบโต การติดตามสิ่งนี้เป็นสิ่งสำคัญ — โดยหลักการแล้ว จะต้องผ่านรูปแบบการจัดระบบบางรูปแบบที่ช่วยให้มองเห็นการเชื่อมต่อต่างๆ ทั้งหมดได้ในพริบตา

ใน รหัสต่ำหรือไม่มีเลย สิ่งแวดล้อม เสาหลักเหล่านี้ไม่ได้ตรงไปตรงมาอย่างที่ใครๆ คาดหวัง คนที่ใช้เครื่องมือเหล่านี้มักเป็นผู้เชี่ยวชาญด้านธุรกิจที่มีความคุ้นเคยกับพื้นฐานของ DevSecOps เพียงเล็กน้อย

รวบรวมผู้คน กระบวนการ และเทคโนโลยีเข้าด้วยกัน

การใช้แพลตฟอร์มแบบ low-code และ no-code สามารถช่วยปิดช่องว่างทักษะนี้ได้จริง พนักงานต้องการเรียนรู้ทักษะใหม่ๆ องค์กรต่างๆ สามารถรองรับสิ่งนั้นได้ด้วยการสร้างเฟรมเวิร์ก DevSecOps ที่มุ่งเน้นไปที่ผู้คน กระบวนการ และเทคโนโลยี 

• กระบวนการ: ในสภาพแวดล้อมแบบ Zero-Trust นักพัฒนาที่ใช้โค้ดน้อยและไม่ใช้โค้ดไม่จำเป็นต้องกังวลเกี่ยวกับการเชื่อมต่อที่เป็นอันตรายต่อความสมบูรณ์ของระบบเนื่องจากไม่สามารถทำเช่นนั้นได้ พวกเขาไม่มีอำนาจพื้นฐานภายนอกระบบที่แยกออกมา  
• คน: วัฒนธรรมแห่งความรับผิดชอบแตกต่างจากวัฒนธรรมแห่งการตำหนิ ความรับผิดชอบหมายถึงการที่บุคคลรู้สึกสบายใจที่จะเผชิญกับปัญหาหรือข้อผิดพลาด เนื่องจากการมุ่งเน้นไปที่ปัญหา ไม่ใช่ตัวบุคคล
• เทคโนโลยี: เทคโนโลยีเป็นอุปสรรคที่ใหญ่ที่สุดประการเดียวในการนำหลักการ DevSecOps ไปใช้อย่างเหมาะสม เนื่องจากอยู่นอกเหนือมือของนักพัฒนา พวกเขาต้องใช้สิ่งที่องค์กรมอบให้ หากเทคโนโลยีดังกล่าวใช้งานไม่ได้ นักพัฒนาจะคิดวิธีแก้ปัญหาที่ไม่ปลอดภัยหรือไม่ปลอดภัย โดยพื้นฐานแล้ว เทคโนโลยีนี้จะกลายเป็นเครื่องกำเนิดไอทีเงาขนาดใหญ่ตัวหนึ่ง

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