การสแกน IaC: โอกาสการเรียนรู้ที่ยอดเยี่ยมและถูกมองข้าม

ทุกสิ่งที่คุณอ่านเกี่ยวกับโครงสร้างพื้นฐานในรูปแบบโค้ด (IaC) จะมุ่งเน้นไปที่วิธีการทำงานหรือเหตุผลที่คุณต้องการให้แน่ใจว่าโครงสร้างพื้นฐานกำลังสร้างในแบบที่คุณต้องการสร้างจริงๆ

สิ่งเหล่านี้เป็นพื้นที่สำคัญ แต่เราคิดมากพอแล้วหรือยังว่าเราจะใช้วิธีการนี้ในองค์กรของเราอย่างไร?

As เมลินดา มาร์กส์ จาก ESG ระบุในรายงานของบริษัท “83% ขององค์กรประสบปัญหาการกำหนดค่าเทมเพลต IaC ผิดพลาดเพิ่มขึ้น” ในขณะที่พวกเขายังคงนำเทคโนโลยีนี้มาใช้

เรารู้จากงานที่ทำโดย Cloud Security Alliance (“ภัยคุกคามยอดนิยมต่อการประมวลผลแบบคลาวด์: Egregious Eleven“) และอื่นๆ การกำหนดค่าที่ไม่ถูกต้องยังคงเป็นความเสี่ยงสูงสุดในระบบคลาวด์

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

สำหรับทีมเล็กๆ ทีมที่ Dev และ Ops บิตของปรัชญา DevOps มารวมกัน นั่นก็สมเหตุสมผล IaC อนุญาตให้ทีมเล็กๆ เหล่านี้ใช้ภาษาเดียวกัน — โค้ด — เพื่ออธิบายทุกสิ่งที่พวกเขาทำอยู่

นี่คือเหตุผลที่เราเห็นนามธรรมในระดับที่สูงกว่าเครื่องมืออย่าง Terraform หรือ AWS CloudFormation ใน AWS CDK และโครงการอย่าง cdk8s. นามธรรมระดับสูงเหล่านั้นสะดวกสบายกว่าสำหรับนักพัฒนา

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

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

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

ด้วยเหตุนี้ความกังวลด้านความปลอดภัยจึงมักบานปลายมากขึ้น

เครื่องมือส่วนใหญ่ - เชิงพาณิชย์หรือโอเพ่นซอร์ส - มุ่งเน้นไปที่การระบุสิ่งที่ผิดปกติกับเทมเพลตโครงสร้างพื้นฐาน
เป็นโครงสร้างที่ดี การทำ นี้
คงจะแย่ เครื่องมือเหล่านี้มีจุดมุ่งหมายเพื่อสร้างผลลัพธ์เหล่านี้โดยเป็นส่วนหนึ่งของไปป์ไลน์การบูรณาการ/การจัดส่งอย่างต่อเนื่อง (CI/CD) อย่างต่อเนื่อง

นั่นเป็นการเริ่มต้นที่ดี แต่มันสะท้อนปัญหาภาษาเดียวกัน

ใครกำลังพูดและใครกำลังฟัง?

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

สำหรับนักพัฒนา สิ่งที่มักเกิดขึ้นคือพวกเขาจะปรับการกำหนดค่าเพื่อให้การทดสอบ IaC ผ่าน

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

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

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

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

ตัวอย่างเช่น เมื่อการสแกนแจ้งว่ากฎของกลุ่มความปลอดภัยไม่มีคำอธิบาย เหตุใดจึงสำคัญ การได้รับการแจ้งเตือนว่า “เพิ่มคำอธิบายสำหรับบริบท” ไม่ได้ช่วยให้ใครสร้างผลงานได้ดีขึ้น

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

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

เกี่ยวกับผู้เขียน

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