29 มกราคม 2559

Secure Software Design 101: Need to Know

การออกแบบซอฟต์แวร์ให้มั่นคงปลอดภัยในในหัวข้อนี้ เป็นเรื่องของการเข้าถึงข้อมูล และเกี่ยวข้องกับเรื่องการรักษาความลับ (Confidentiality) โดยตรง หลักการนี้กล่าวว่า ถึงแม้ว่าใครก็ตามได้รับอนุญาตให้เข้าถึงข้อมูลไม่ว่าจะเป็นชั้นความลับระดับใดก็ตาม ก็ไม่สามารถเห็นข้อมูลนั้นได้จนกว่าจะมีความจำเป็นที่ต้องรู้ข้อมูล (Need to Know) เพื่อที่จะใช้ในการปฏิบัติงาน และไม่จำเป็นต้องเห็นข้อมูลทุกอย่าง เว้นแต่ข้อมูลที่เกี่ยวข้อง

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

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

Need to Know มักจะถูกใช้สับสนกับ Least Privilege เนื่องจากเป็นเรื่องการควบคุมสิทธิ์เช่นเดียวกัน โดยข้อแตกต่างจะสรุปได้ดังนี้
ข้อเปรียบเทียบ Need to Know Least Privilege
การเข้าถึง อ่านเท่านั้น อ่าน เขียน สั่งให้ทำงาน เป็นต้น
Object ข้อมูลเท่านั้น ข้อมูล แฟ้ม บริการ กระบวนการ เป็นต้น
Security Foundation Confidentiality Confidentiality, Integrity
การควบคุมการเข้าถึงข้อมูล ระดับ Record & Field ระดับSchema (อาจถึงระดับ Field)
สิทธิ์ ตามที่ได้รับมอบหมาย(Assignment) ตามบทบาท(Role)

จำไว้เสมอว่า Subject ควรได้รับข้อมูลเฉพาะที่จำเป็นต้องรู้เพื่อทำงานตามหน้าที่ที่ได้รับมอบหมายเท่านั้น

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


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) จะมีน้อยเท่านั้น

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