หลักแห่งการออกแบบระบบอย่างมั่นคงปลอดภัย (Secure Design Principles)

ธนาคารรายใหญ่มีกฎระเบียบข้อบังคับในการคัดเลือกผู้ให้บริการหลายข้อ ทั้งในแง่ขีดความสามารถและความมั่นคงทางการเงินของบริษัท แต่เมื่อมีการจัดซื้อจัดจ้างผลิตภัณฑ์หรือบริการไปแล้ว รายละเอียดของหนังสือสัญญาเน้นไปที่คุณสมบัติและ Requirement ที่ต้องการเพียงอย่างเดียว แต่กลับไม่มีเนื้อหาบังคับผู้ให้บริการหรือผู้จัดหาผลิตภัณฑ์แก้ไขประเด็นด้านความมั่นคงปลอดภัยหากเกิดปัญหาหรือประเด็นในด้านดังกล่าวในอนาคต

เหลือเชื่อ แต่เกิดขึ้นจริง!

บริษัทผลิตซอฟต์แวร์ CMS ที่ใช้สำหรับบริหารจัดการเว็บไซต์ อยู่ในตลาดมานานหลายปี มีลูกค้าองค์กรใช้งานหลายต่อหลายแห่งให้ความสำคัญกับความมั่นคงปลอดภัยต่ำมาก เมื่อเกิดประเด็นด้านความมั่นคงปลอดภัยเกิดขึ้น บริษัทดังกล่าวกลับทำการแก้ไข Source Code เฉพาะประเด็นที่ถูกตรวจพบใน Environment ขององค์กรที่ใช้งานแห่งนั้นเท่านั้นแต่ไม่เคยนำไปแก้ไขหรือ Update ซอฟต์แวร์ CMS Version ที่เอาไปขายให้กับลูกค้ารายอื่น ๆ เลย

เหลือเชื่อ แต่เกิดขึ้นจริง!

เหตุการณ์ข้างต้น ถ้าพิจารณาให้ถี่ถ้วนก็จะพบว่าล้วนก่อให้เกิดต้นทุนทั้งสิ้น ไม่ว่าจะเป็นต้นทุนที่เป็นเม็ดเงิน ต้นทุนด้านเวลา ต้นทุนการจัดการ หรือแม้กระทั่งต้นทุนการเสียโอกาส การยกตัวอย่างมาข้างต้นไม่ได้มีจุดประสงค์เพื่อเสนอความคิดในเชิงบริภาษ แต่อยากจะเล่าให้ทุกคนได้รู้จักนำหลักการด้าน Security ไปใช้ตั้งแต่ขั้นตอนการออกแบบไปเลย ลดปัญหาที่ตามมาในภายหลังโดย Concept แบบนี้เราจะเรียกว่า Secure Design Principles ซึ่งหลาย ๆ คนคงเคยได้ยินแนวความคิดเรื่องการออกแบบระบบอย่างมั่นคงปลอดภัยมาบ้างแล้ว และเชื่อเถอะว่าเรากำลังใช้แนวความคิดดังกล่าวอยู่ด้วยเช่นกัน

เรื่องของการออกแบบระบบอย่างมั่นคงปลอดภัยมีการพูดถึงมานานกว่า 40 ปีแล้ว หลังจากการปล่อยยาน Apollo 13 ในปี 1970 มาได้ 4 ปี วงการ Computer Science ก็มีการตีพิมพ์งานที่ชื่อ "The Protection of Information in Computer Systems" โดยนัก Computer Scientist 2 คนได้แก่ Jerome Saltzer และ Michael Schroeder โดย Paper นี้พูดถึงกลไกการป้องกันข้อมูลในระบบคอมพิวเตอร์โดยเน้นไปที่การออกแบบเป็นหลัก

แล้วหลักการที่ว่ามีอะไรบ้าง

หลักการที่จะกล่าวถึง ผู้ดูแลระบบ นักพัฒนา โปรแกรมเมอร์ หรือ Software Architect ควรรู้จักหลักการดังต่อไปนี้

1. Economy of mechanism: "Keep the design as simple and small as possible" หมายถึงการออกแบบระบบให้เรียบง่ายและมีขนาดไม่ใหญ่จนเกินไปนัก เหตุผลก็คือระบบใด ๆ ที่ต้องการความมั่นคงปลอดภัยจำเป็นอย่างยิ่งที่จะต้องได้รับการตรวจสอบและกำกับ การที่ระบบเรียบง่ายและไม่ซับซ้อนจึงเป็นสิ่งจำเป็น
2. Fail-safe Default: "Base access decisions on permission rather than exclusion" คือการออกแบบให้ระบบตัดสินใจเรื่อง Access Control โดยใช้หลัก Whitelist คือ ให้ใครทำอะไรบ้าง เข้าถึง resource อะไรและเข้าใช้งานด้วยวิธีไหน หากไม่ได้อยู่ใน Whitelist ระบบก็จะไม่อนุญาตโดยปริยาย ตรงกันข้ามการใช้ Blacklist หรือการระบุว่าไม่ให้ใครทำอะไรบ้าง ในระยะยาวการ Maintain จะทำได้ลำบากเพราะมีวิธีหลีกเลี่ยงซิกแซกใหม่ ๆ ที่เราต้องใส่เพิ่มเข้าไปใน blacklist เสมอ
3. Complete mediation: "Every access to every object must be checked for authority." ข้อนี้ต้องการให้มีการตรวจสอบสิทธิ์ก่อนการเข้าถึง Object ที่ต้องการเสมอ เช่นก่อนการเข้าถึง Database, เข้าถึง Table และเข้าถึง Record ของข้อมูลที่ต้องการ ระบบต้องพิจารณาว่าผู้ใช้มีสิทธิ์หรือไม่ ช่องโหว่ด้าน Access Control มากกว่า 90% ที่ผมเคยพบจากงานเจาะระบบตามที่ต่าง ๆ มักละเลยข้อนี้ Concept ดูเหมือนง่ายก็จริงแต่การ Implement ต้องรอบคอบ
4. Least privilege: "Every program and every user of the system should operate using the least set of privileges necessary to complete the job." ข้อนี้ตรงไปตรงมา หากผู้ดูแลระบบหรือนักพัฒนาระบบมี Concept ในการให้สิทธิ์หรือครอบครองสิทธิ์ในระดับต่ำที่สุดเท่าที่จำเป็นต่อการทำงาน ความเสี่ยงในหลาย ๆ เรื่องย่อมลดระดับความรุนแรงไปได้มาก
5. Least common mechanism: "Minimize the amount of mechanism common to more than one user and depended on by all users." พูดง่าย ๆ ก็คือให้จำกัดสิ่งที่มีผู้ใช้หลาย ๆ คนใช้ร่วมกัน เพราะเมื่อ Component นั้นเกิดปัญหาขึ้นมา มันจะกระทบผู้ใช้งานจำนวนมากหรืออาจส่งผลกระทบกับทั้งระบบ ตัวอย่างที่มีการนำหลักการนี้ไปใช้ที่เห็นได้อย่างชัดเจนคือ Kernel Module เมื่อผู้ใช้ต้องการใช้ Module ใด ๆ ก็สามารถที่จะ Load Module นั้น ๆ เข้าไปโดยไม่ต้อง Reboot และมากกว่านั้นคือไม่ทำให้ Kernel Image ใหญ่เกินไปและเปลี่ยนแปลงได้ยาก หากจะฝัง Function ทุก ๆ อย่างเข้าไปในตัว Kernel ตั้งแต่ต้น
6. Psychological acceptability: "It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly." จุดประสงค์ของข้อนี้คือตั้งใจให้ Design ของระบบง่ายต่อการใช้งาน โดยเฉพาะพวก Security Features ต้อง User Friendly ไม่เป็นอุปสรรคต่อการตั้งค่าใช้งาน ไม่งั้นผู้ใช้จะไม่ยอมใช้
7. Compromise Recording เป็น Feature ที่มีไว้เพื่อทำให้เจ้าของระบบรู้ว่าระบบถูกโจมตี เช่นการ Enable ให้ระบบเก็บ Audit Trail ต่าง ๆ จำพวก Login, Access, Modify เพื่อตรวจสอบกิจกรรมที่ไม่พึงประสงค์ อย่างไรก็ตามมันมีความเป็นไปได้ที่ผู้โจมตีจะสามารถทำลายร่องรอยเหล่านั้นได้

นอกเหนือจากที่กล่าวถึงใน Paper แล้วก็ยังมีหลักการที่สำคัญอื่น ๆ ที่มักกล่าวถึงเป็นประจำในการออกแบบระบบให้มั่นคงปลอดภัย ที่พวกเราควรรู้จักก็จะมี

• Defense in Depth ที่ต้องสร้าง Layer of Defense หลายระดับเพื่อว่าเมื่อ Protection ชั้นหนึ่งถูกทำลายก็ยังมีชั้นอื่น ๆ อยู่
• Fail-secure เมื่อระบบเกิดปัญหา ก็ยังคงต้องรักษาระดับ Security ของมันอยู่ และสุดท้าย
• Design for updating ที่ผู้พัฒนาระบบควรออกแบบให้ระบบสามารถทำ Security Update ได้

secure-design-principles

Margaret Hamilton ในปี 1969 นักพัฒนาระบบและ Software ของ NASA ยืนข้าง ๆ Source Code ของโครงการ Apollo ไม่ต้องบอกก็รู้ว่า Security และ Safety สำคัญเพียงไร [รูปจาก Wikipedia]

หลักแห่งการออกแบบระบบอย่างมั่นคงปลอดภัย (Secure Design Principles) ดูคร่าว ๆ ก็ดูเหมือนง่าย แต่ก็มีความลุ่มลึกในตัวของมันเอง สามารถประยุกต์ใช้ได้หลากหลาย ปัญหาด้าน Security Issue ที่เคยพบและที่แก้ไม่สำเร็จโดยมากเพราะแก้ไม่ตรงจุด หรือไม่พบ ‘ที่เกิดเหตุ’ เมื่อผู้รับผิดชอบมองผิด เข้าใจประเด็นผิดไปก็มักไปแก้ปัญหาที่ปลายเหตุ การออกแบบระบบอย่างไรให้มีความมั่นคงปลอดภัย จึงเป็นจุดเริ่มต้นหรือ ‘ที่เกิดเหตุ’ ที่เหมาะสมที่สุด