Why Design Matters for Security
ทำไมการออกแบบจึงสำคัญต่อความปลอดภัย? บทนี้ตั้งคำถามเพื่อกระตุกกระบวนทัศน์ดั้งเดิมว่า "เหตุใดเราจึงควรหยุดพยายามเขียนโค้ดไล่จับแฮกเกอร์ แต่หันมาตั้งหน้าตั้งตาออกแบบระบบให้ดีแทน?"
คำตอบจากบทนี้: แนวทางดั้งเดิมที่เน้นการเพิ่ม "ฟังก์ชันดักจับไวรัส/สคริปต์" มักล้มเหลวเพราะไม่มีใครคาดเดาภัยคุกคามในอนาคตได้ทั้งหมด แต่เมื่อเรา ขับเคลื่อนความปลอดภัยด้วยการออกแบบโมเดลโดเมนที่แม่นยำ ตัวโครงสร้างการออกแบบนั่นเองที่จะเป็นเกราะกำบัง และตัดช่องโหว่ออกไปตั้งแต่วินาทีแรกที่สร้างวัตถุ โดยไม่ต้องเขียนโค้ด Security เพิ่มเติมเลยแม้แต่บรรทัดเดียว!
นี่คือจุดเริ่มต้นวันแรกของการเดินทาง 14 วัน บนเส้นทางสถาปัตยกรรมความปลอดภัยที่แท้จริง
Day 1 จาก 14 วัน — เข้าสู่ Part 1: Introduction บทที่ 1 วางรากฐานและปรับ Mindset
รื้อถอนความคิดว่าความปลอดภัยคือภาระ มาเข้าใจว่า Security คือผลพลอยได้ธรรมชาติของการออกแบบที่ดี
เรื่องราวและมโนทัศน์เชิงลึก (Analogies & Narrative Scenarios)
📖 เรื่องราวจริงในประวัติศาสตร์
ย้อนกลับไปในประเทศสวีเดน ปี ค.ศ. 1854 ธนาคาร Öst-Götha Bank ต้องการสร้างความมั่นใจสูงสุดให้แก่ลูกค้าในการจัดเก็บทรัพย์สิน จึงสั่งทำ "แม่กุญแจตู้นิรภัยรุ่นพิเศษ" ที่ซับซ้อน สะเดาะยากที่สุด และผลิตด้วยเทคโนโลยีชั้นสูงในยุคนั้น
🧠 ถอดรหัสสู่โลกซอฟต์แวร์ (Mental Model)
เมื่อเจอปัญหา <script>alert(42);</script> ใน Username นักพัฒนาจะเขียน validateForXSS(username) เพื่อไล่ลบคำอันตรายออก ซึ่งมักล้มเหลวเพราะ:
- Explicit Security Focus: Security มักแพ้เรื่อง Deadline เสมอ
- Everyone must be an expert: คาดหวังให้โปรแกรมเมอร์ทุกคนต้องรู้ทันทุกช่องโหว่
- The Unknowable Threats: ป้องกันการโจมตีรูปแบบใหม่ที่ยังไม่เคยพบไม่ได้
แทนที่จะถามว่าจะดักจับ XSS อย่างไร เราเปลี่ยนไปถาม Domain Expert ว่า: "ในบริบทธุรกิจเรา Username ที่ถูกต้องคืออะไร?"
เมื่อสร้างคลาส Username ที่คุมกฎนี้ สคริปต์ <script> จะถูกปฏิเสธทันทีตั้งแต่ตอนสร้างวัตถุ โดยที่ไม่ต้องเขียนโค้ดตรวจ XSS เลย!
Billion Laughs Attack: การโจมตีด้วย XML Internal Entities นิยามซ้อนกันซ้ำๆ: lol9 ขยายเป็น 10 lol8 ➔ ขยายเป็น 1,000,000,000 (หนึ่งพันล้าน) lol ทำให้ไฟล์ขนาด < 1 KB พองตัวล้นแรมหลาย Gigabytes จนระบบล่ม (DoS)
ปิดการใช้งาน DTD (Doctype Declaration) และ External Entities บน XML Parser
สแกนหาคำว่า <!ENTITY ในสตรีม Token สั้นๆ หากพบให้ตัดทิ้งทันทีก่อนเริ่ม Heavy Parsing
จำกัดทรัพยากรระดับ Operation เช่น ตั้ง Timeout และจำกัด RAM ไม่เกิน 50MB
แบบฝึกหัดปฏิบัติตามสถานการณ์จริง (Hands-on Refactoring)
// โค้ดเดิม: ใช้ String รับ Username และไล่ตรวจจับ XSS public class User { private final Long id; private final String username; public User(Long id, String username) { notNull(id); notNull(username); // เสี่ยงต่อภัยคุกคามรูปแบบใหม่ที่ไม่รู้จัก! this.id = id; this.username = ValidationUtils .validateForXSS(username); } }
ValidationUtils ไม่รู้จัก สคริปต์อันตรายจะเล็ดลอดเข้าไปในระบบทันที
// โค้ดใหม่: แยก Username เป็น Domain Primitive public final class Username { private final String value; public Username(String raw) { notNull(raw, "Username cannot be null"); final String trimmed = raw.trim(); inclusiveBetween(4, 40, trimmed.length(), "Length must be 4-40 chars"); matchesPattern(trimmed, "^[A-Za-z0-9_-]+$", "Only alphanumeric, _ and - allowed"); this.value = trimmed; } public String value() { return value; } } public class User { private final Long id; private final Username username; // รับประกันว่า Valid เสมอ public User(Long id, Username username) { this.id = notNull(id); this.username = notNull(username); } }
User สะอาดขึ้น ไม่ต้องพึ่งพา ValidationUtils และสคริปต์อย่าง <script> ถูกบล็อกทิ้งตั้งแต่ขั้นตอนสร้างอ็อบเจกต์โดยอัตโนมัติ
ชุดควิซประเมินความรู้ประจำวัน
ตอบปุ๊บ รู้ผลเฉลยทันที พร้อมคำอธิบายและเกจสะสมพลังงาน Energy Charge
ทดสอบความรู้ Day 1 สำเร็จแล้ว!
สรุปการเชื่อมโยงกลับสู่ Chapter 1 — Why design matters for security
เรื่องราวของแม่กุญแจ Öst-Götha Bank, การสร้างคลาส Username Domain Primitive, และการรับมือ Billion Laughs XML ในวันนี้ ล้วนพิสูจน์ให้เห็นอย่างชัดเจนว่า "ทำไมการออกแบบจึงสำคัญต่อความปลอดภัย" เพราะการวิ่งไล่แก้ช่องโหว่ความปลอดภัยทีหลังเปรียบเหมือนการตามเปลี่ยนแม่กุญแจโดยปล่อยให้บานพับประตูหลวม แต่ถ้าเรา ออกแบบโดเมนให้แม่นยำตั้งแต่วินาทีแรก (Driven Security through Design) โครงสร้างของโค้ดนั่นเองที่จะตัดภัยคุกคามออกไปและสร้างความปลอดภัยให้แก่ระบบอย่างยั่งยืนครับ!