สิ่งที่คุณควรรวมไว้ด้วยเมื่อสร้าง Threat Model ครั้งถัดไป

ขณะนี้เราที่ DisruptOps กำลังจัดทำ threat model ของเราเอง ผมจึงถือโอกาสทบทวนแนวทางต่าง ๆ อีกครั้ง สิ่งหนึ่งที่เห็นได้ชัดเจนอย่างรวดเร็วคือ เอกสารหรือเครื่องมือ threat modeling แทบทุกชิ้นที่ผมเคยเห็นไม่ได้ครอบคลุมถึง CI/CD pipeline เลย

นี่. คือ. ปัญหา. จงรวม pipeline ของคุณไว้ใน threat model ด้วย

ตลอดไม่กี่ปีที่ผ่านมา ผมได้ประเมินความปลอดภัยบนคลาวด์ด้วยตัวเองมาแล้วหลายสิบครั้ง นอกเหนือจากงานที่ปรึกษาด้านอื่น ๆ ผมกำหนดให้ development/deployment pipeline อยู่ในขอบเขตการประเมินเสมอ และบ่อยครั้งที่จุดนี้เองคือแหล่งของปัญหาด้านความปลอดภัยที่ใหญ่ที่สุด สภาพแวดล้อมคลาวด์ที่คุณคิดว่าปลอดภัยสูงสุดก็ไม่ต่างจากบ้านไพ่ หากใครสักคนสามารถเปลี่ยนแปลงโครงสร้างพื้นฐานระดับรากฐานได้เพียงแค่แก้ไข template สักแห่ง หรือเจาะเอาคีย์ที่จัดเก็บไว้ไปได้

threat model ส่วนใหญ่เริ่มต้นจาก data flow diagram หรือสถาปัตยกรรม ซึ่งใช้ไล่ดูแอปพลิเคชันเพื่อจำลองภัยคุกคามได้ (ส่วนตัวผมชอบ STRIDE ซึ่งมาจาก Microsoft) แนวทางนี้ครอบคลุมการทำงานของแอปพลิเคชัน แต่ไม่ครอบคลุม pipeline

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

ตัวอย่างเช่น มีใครสามารถปลอมแปลง API call เข้าไปยัง Jenkins เพื่อสั่งให้เกิดการเปลี่ยนแปลงในแอปพลิเคชันระดับ production ได้หรือไม่ (เป็นไปได้สูง ด้วยวิธีที่ Jenkins มักถูกตั้งค่า) แล้วการปฏิเสธความรับผิดชอบต่อการเปลี่ยนแปลง job เทียบกับการเปลี่ยนแปลงโค้ดล่ะ หรือการยกระดับสิทธิ์ภายใน pipeline ล่ะ

โดยทั่วไป pipeline มักผ่านการตรวจสอบด้านความปลอดภัยได้ไม่ดีนัก เราจึงจะกล่าวถึงเรื่องนี้ในบทความชุดพื้นฐานด้านความปลอดภัยในโอกาสต่อไป คงไม่น่าแปลกใจหากผมจะแนะนำให้วาง guardrail ทั้งกับการ deploy ผ่าน pipeline และกับโครงสร้างพื้นฐานที่เชื่อมต่ออยู่ เพื่อลดความเสี่ยง ตัวอย่างเช่น CI server ของคุณไม่ควรเปิดสู่สาธารณะหรือเปิดสู่สาธารณะได้เลย คุณสามารถใช้ guardrail ที่เสริมกำลังกัน เพื่อให้มั่นใจว่าเซิร์ฟเวอร์อยู่บน network segment ที่ไม่มี Internet Gateway และว่า security group ของคุณไม่อนุญาตการเข้าถึงจากสาธารณะ (ดียิ่งกว่านั้น ควรกำหนดให้ CI server อยู่หลัง elastic load balancer เสมอ)

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