ในโลกของระบบซอฟต์แวร์ที่มีความเชื่อมโยงและข้อมูลที่ละเอียดอ่อนเพิ่มขึ้นอย่างต่อเนื่อง การพึ่งพาเพียงแค่การป้องกันด้วยไฟร์วอลล์หรือรหัสผ่านจึงไม่เพียงพออีกต่อไป นักพัฒนาระบบยุคใหม่จำเป็นต้องยกระดับแนวคิดด้านความปลอดภัยให้เป็นส่วนหนึ่งของการออกแบบสถาปัตยกรรมตั้งแต่เริ่มต้น แนวทางนี้คือสิ่งที่เรียกว่า “Defensive Design” หรือ ‘สถาปัตยกรรมการกีดกันงานโจมตี’ ซึ่งไม่ใช่มาตรการแก้ไขปัญหาเฉพาะหน้า แต่เป็นการวางรากฐานเพื่อรับมือกับภัยคุกคามที่ไม่รู้จัก
หลักการเชิงลึกของ Defensive Architecture
หัวใจสำคัญของ Defensive Design คือปรัชญาในการสันนิษฐานว่า ระบบจะต้องถูกโจมตีเสมอ ไม่ว่าจะมาจากแหล่งภายในภายนอกก็ตาม ดังนั้นทุกชั้น ทุกโมดูล และฟังก์ชันต่างๆ จะต้องได้รับการปกป้องหลายระดับ แทนที่จะมีกำแพงเหล็กหนาๆ เพียงจุดเดียว เราจะสร้างเครือข่ายปราการ (Defense in Depth) ที่มีความหลากหลาย เพื่อให้เมื่อผู้บุกรุกเจาะเข้าได้ถึงส่วนใดส่วนหนึ่ง ก็ยังคงเผชิญกับการตรวจสอบและการจำกัดอำนาจในขั้นตอนถัดไปอยู่ดี
- Zero Trust Model: หลักการที่ปฏิเสธสมบูรณ์แบบ โดยจะไม่เชื่อถือใครเลย ทั้งจากคน ผู้ใช้งานอุปกรณ์ แม้แต่ระบบที่เราคิดว่าเป็นพื้นที่ปลอดภัยที่สุด การพิสูจน์ตัวตนจึงเกิดขึ้นตลอดเวลาและมีการประเมินความเหมาะสมของการกระทำอย่างต่อเนื่อง
- Fail Securely by Default: หมายถึง เมื่อเกิดข้อผิดพลาดทางเทคนิคหรือสถาปัตยกรรมบางส่วนทำงานไม่ถูกต้องแทนที่จะทำให้ข้อมูลรั่วไหล หรือเปิดช่องโหว่โดยปริยาย ระบบควรอยู่ในสถานะปิดกั้น ปฏิเสธการให้บริการ จนกว่าปัญหาจะได้รับการแก้ไข นี่คือหลักปฏิบัติสำคัญในการเขียนโค้ดจัดการ Exception เสมอ
องค์ประกอบเชิงวิศวกรรมเพื่อเสริมแนวป้องกัน
จากการเป็นเพียงทฤษฎี Defensive Design ได้ถูกนำมาปรับใช้ผ่านกลไกหลายชั้น ตั้งแต่นโยบายระดับสูงจนถึงรายละเอียดของ API Call ในมุมมองของผู้เชี่ยวชาญด้านระบบ เราต้องให้ความสนใจกับจุดบอดเหล่านี้:
- Input Validation & Sanitization (Layer 7): ต้องตรวจสอบทุกอินพุต ไม่ว่าจะเป็นค่าส่งมาจาก $_GET, $_POST หรือแม้กระทั่ง URL Parameter ว่ามีรูปแบบที่คาดการณ์ได้หรือไม่ และล้างข้อมูลที่เป็นอันตรายออกก่อนเข้าสู่ฐานข้อมูลเสมอ เพื่อป้องกัน SQL Injection แนวคิดนี้ข้ามจากแค่เรื่อง Backend ไปรวมถึง Front-end ด้วย
- Principle of Least Privilege (PoLP): ทุกผู้ใช้งานและบริการจะต้องได้รับเฉพาะ