27 มกราคม 2559

Secure Software Design 101: Least Privilege

ในการออกแบบทางด้าน Security สิ่งหนึ่งที่มักจะพูดถึงก็คือเรื่องการให้สิทธิ (Authorization) เพื่อทำงานใดๆ ไม่ว่าจะเป็นระดับผู้ใช้ (User) หรือกระบวนการ (Process) ซึ่งเราเรียกรวมกันว่าประธานหรือผู้กระทำ (ขอใช้ทับศัพท์ว่า Subject or Actor) กระทำการใดๆ ต่อข้อมูล บริการ (Service) หรือแม้แต่กระบวนการ (Process) ด้วยกันเอง ซึ่งเรียกรวมๆ กันว่ากรรม (ขอใช้ทับศัพท์ว่า Object) ซึ่งสามารถเขียนเป็นตัวอย่างการรวมกันของ ประธาน กริยา กรรม ได้เช่น
ประธาน (Subject)กริยา (Access)กรรม (Object)
ผู้ใช้ (User)
โปรแกรม (Program)
กระบวนการ(Process)
อ่าน (Read)
เขียน (Write)
สั่งให้ทำงาน(Execute)
แฟ้มข้อมูล (File)
ฐานข้อมูล(Database)
บริการ (Service)
กระบวนการ(Process)
ทรัพยากร(Resource)

การออกแบบการให้สิทธินั้นมีแนวคิดเพื่อความมั่นคงปลอดภัยก็คือการให้สิทธิ Subject ดำเนินการต่อ Object น้อยที่สุดเท่าที่จะทำงานได้สำเร็จตามวัตถุประสงค์ หรือที่เรียกว่า Least Privilege เช่น Web Application ซึ่งทำงานกับ Database เพียงแค่ insert, select, update, delete ก็ควรจะสร้าง Database User ให้กับ Web Application นั้นให้มีสิทธิ์เท่าที่ทำงานดังกล่าวได้ ไม่ใช่ปล่อยให้ใช้ User ที่มีสิทธิ์สูงเช่น SA, root, SYS หรือ Schema Owner หรือ User ที่สามารถใช้คำสั่งจัดการ Schema ของข้อมูล (DDL: Data Definition Language) เช่น create, alter, drop เป็นต้น

สิทธิดังกล่าวข้างต้นเป็นสิทธิในเชิงวิธีการเข้าถึง แต่ยังมีในเชิงปริมาณที่ต้องคำนึงถึงคือจำนวนและชนิดของ Object ที่เข้าใช้งาน หลักการ Lease Privilege ก็ครอบคลุมในมิตินี้ด้วย กล่าวคือหาก Subject ไม่มีความจำเป็นที่ต้องทำงานกับ Object ใด ก็ควรห้ามการเข้าถึง Object นั้นๆ ด้วย

การให้สิทธิ์แก่ Subject มากเท่าไรก็เป็นการเพิ่มพื้นที่ในการโจมตี (Attack Surface) ต่อ Object มากเท่านั้นและเมื่อ Subject โดนยึดได้ (Compromised) Object ก็มีโอกาสถูกกระทำตามสิทธิที่ให้แก่ Subject ไว้

จำไว้เสมอว่า ให้ Subject มีสิทธิยิ่งน้อยเท่าไรความเสี่ยงในการที่ Subject จะถูกสวมรอยเพื่อใช้ทำงานผิดวัตถุประสงค์หรือทำงานผิดพลาดโดยไม่ตั้งใจ (User Error) จะมีน้อยเท่านั้น

ตอนที่เกี่ยวข้อง


ไม่มีความคิดเห็น:

แสดงความคิดเห็น