CIAM 102: การให้สิทธิ์และการควบคุมการเข้าถึงตามบทบาท

พื้นหลัง#

ในบทความก่อนหน้า เราได้แนะนำแนวคิดของการรับรองตัวตน (AuthN) และการให้สิทธิ์ (AuthZ) พร้อมกับคำศัพท์ที่น่าปวดหัว: อัตลักษณ์, องค์กร, ผู้เช่า, ฯลฯ

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

ทำไมเราต้องการการให้สิทธิ์?#

Notion เป็นตัวอย่างที่ดี สำหรับแต่ละหน้าที่คุณเป็นเจ้าของ คุณสามารถเลือกที่จะเก็บเป็นส่วนตัว เข้าถึงได้เฉพาะคุณ หรือแชร์กับเพื่อน หรือแม้แต่สาธารณะ

หรือ สำหรับร้านหนังสือออนไลน์ คุณต้องการให้ทุกคนสามารถดูหนังสือทั้งหมดได้ แต่ลูกค้าให้ดูเฉพาะคำสั่งซื้อของตัวเอง และผู้ขายจัดการได้เฉพาะหนังสือในร้านของตัวเอง

AuthZ และ AuthN เป็นส่วนประกอบที่จำเป็นของโมเดลธุรกิจที่ซับซ้อน มักทำงานร่วมกัน; AuthZ ตรวจสอบการเข้าถึงของผู้ใช้ ในขณะที่ AuthN ตรวจสอบตัวตน ทั้งสองจำเป็นสำหรับระบบที่ปลอดภัย

โมเดลการให้สิทธิ์พื้นฐาน#

นี่คือหนึ่งในโมเดล AuthZ ที่พบบ่อยที่สุด: ถ้า IDENTITY ทำ ACTION ใน RESOURCE แล้ว ACCEPT หรือ DENY

ในตัวอย่าง Notion โมเดลคือ PERSON ทำ VIEW ใน PAGE.

ถ้าหน้าเป็นส่วนตัว:

• คุณจะได้รับ ACCEPT เมื่อทำ VIEW ใน PAGE ของคุณ
• คนอื่นทั้งหมดควรได้รับ DENY เมื่อทำ VIEW ใน PAGE ของคุณ

ตามความเห็นพ้องของอุตสาหกรรม ได้พัฒนาเทคโนโลยีการให้สิทธิ์ต่างๆ เช่น การควบคุมการเข้าถึงตามบทบาท (RBAC), การควบคุมการเข้าถึงตามคุณลักษณะ (ABAC) วันนี้ เรามุ่งเน้นที่NIST RBAC model เลเวล 1: Flat RBAC

การควบคุมการเข้าถึงตามบทบาท#

ลองขยายตัวอย่างร้านหนังสือ สมมติว่าเรามีลูกค้าจำนวนมาก แต่มีเพียงผู้ขายคนเดียว:

• ลูกค้าสามารถดูและสั่งซื้อหนังสือ รวมทั้งดูคำสั่งซื้อของตนเองได้
• ผู้ขายสามารถดู สร้าง และลบหนังสือ รวมทั้งจัดการคำสั่งซื้อลูกค้าได้

นิยามทรัพยากร#

ใน Logto ทรัพยากร (เช่น API Resource) มักเป็นตัวแทนของชุดของหน่วยหรือรายการ เนื่องจากจำเป็นต้องใช้ URL ที่ถูกต้องเป็นตัวบ่งชี้ ดังนั้นเรานิยามสองทรัพยากร:

• หนังสือ: https://api.bookstore.io/books
• คำสั่งซื้อ: https://api.bookstore.io/orders

หนึ่งในข้อดีของการบังคับใช้รูปแบบ URL คือสามารถแผนที่ไปยังที่อยู่จริงของบริการ API ของคุณ ซึ่งช่วยเพิ่มการอ่านและการจดจำเมื่อรวมเข้ากับส่วนประกอบอื่น ๆ ในระบบ

นิยามสิทธิ์#

เนื่องจากเราได้นำเสนอแนวคิดของทรัพยากร ใน Logto เราก็บังคับว่าสิทธิ์ต้องเป็นของทรัพยากร ในทางกลับกัน ทรัพยากรสามารถมีสิทธิ์

ลองเพิ่มสิทธิ์ให้ทรัพยากร:

• หนังสือ: read, create, delete
• คำสั่งซื้อ: read, read:self, create:self, delete

แม้ว่าจะไม่มีข้อกำหนดชื่อของสิทธิ์ แต่เรามีข้อตกลงดังนี้:

ในขณะที่ <action> จำเป็นต้องอธิบายสิทธิ์ :<target> สามารถละเว้นในการอธิบายเป้าหมายทั่วไป เช่น หน่วยหรือรายการทั้งหมดในทรัพยากร ตัวอย่างเช่น:

• สิทธิ์ read ในทรัพยากรหนังสือหมายถึงการปฏิบัติการในการอ่านหนังสือใด ๆ
• สิทธิ์ create:self ในทรัพยากรคำสั่งซื้อหมายถึงการปฏิบัติการในการสร้างคำสั่งซื้อที่เป็นของผู้ใช้ปัจจุบัน

นิยามบทบาท#

โดยสรุปแล้ว บทบาทคือกลุ่มของสิทธิ์ ลองสร้างสองบทบาท customer และ seller และกำหนดสิทธิ์ให้กับพวกเขา:

คุณอาจสังเกตเห็นว่าการกำหนดสิทธิ์ให้บทบาทเป็นความสัมพันธ์หลายต่อหลาย

กำหนดบทบาทให้ผู้ใช้#

เช่นเดียวกับการกำหนดสิทธิ์ให้บทบาท การกำหนดบทบาทให้ผู้ใช้ก็เป็นความสัมพันธ์หลายต่อหลายเช่นกัน ดังนั้น คุณสามารถกำหนดบทบาทหลายบทบาทให้กับผู้ใช้คนเดียว และบทบาทเดียวสามารถถูกกำหนดให้กับผู้ใช้หลายคน

เชื่อมต่อจุด#

นี่คือแผนภาพความสัมพันธ์ที่สมบูรณ์สำหรับโมเดล RBAC เลเวล 1 ใน Logto:

ในโมเดล RBAC สิทธิ์เป็น "บวก" เสมอ หมายความว่าการตัดสินใจการให้สิทธิ์นั้นง่าย: หากผู้ใช้มีสิทธิ์แล้วอนุญาต; มิฉะนั้น ปฏิเสธ

สมมติว่า Alice มีบทบาท seller, Bob และ Carol มีบทบาท customer เราจะอธิบายการกระทำในภาษาธรรมชาติแรก จากนั้นเขียนใหม่เป็นรูปแบบการให้สิทธิ์มาตรฐาน: IDENTITY ทำ ACTION ใน RESOURCE สุดท้ายให้ข้อสรุป

• Alice ต้องการเพิ่มหนังสือใหม่เพื่อขาย:
  • ผู้ใช้ Alice ทำ create ในทรัพยากรหนังสือ (https://api.bookstore.io/books).
  • เนื่องจาก Alice ได้รับสิทธิ์ create ของหนังสือตามบทบาท seller ผลลัพธ์คือ ✅ ACCEPT
• Alice ต้องการดูคำสั่งซื้อทั้งหมดเพื่อดูว่าการขายตรงตามความคาดหวังหรือไม่:
  • ผู้ใช้ Alice ทำ read ในทรัพยากรคำสั่งซื้อ (https://api.bookstore.io/orders).
  • เนื่องจาก Alice ได้รับสิทธิ์ read ของคำสั่งซื้อตามบทบาท seller ผลลัพธ์คือ ✅ ACCEPT
• Bob ต้องการเรียกดูรายการหนังสือเพื่อดูว่ามีหนังสือที่เขาต้องการซื้อไหม
  • ผู้ใช้ Bob ทำ read ในทรัพยากรหนังสือ (https://api.bookstore.io/books).
  • เนื่องจาก Bob ได้รับสิทธิ์ read ของหนังสือตามบทบาท customer ผลลัพธ์คือ ✅ ACCEPT
• Bob ต้องการดูคำสั่งซื้อของ Carol
  • เนื่องจากเป็นคำสั่งซื้อของผู้อื่น สิทธิ์ read:self ของ Orders จึงไม่ทำงานที่นี่
  • ผู้ใช้ Bob ทำ read ในทรัพยากรคำสั่งซื้อ (https://api.bookstore.io/order).
  • เนื่องจาก Bob ไม่มีสิทธิ์ read ของคำสั่งซื้อ ผลลัพธ์คือ ❌ DENY

เลเวล RBAC อื่น ๆ#

โมเดล NIST RBAC มีสี่ระดับ:

• Flat RBAC
• Hierarchical RBAC
• Constrained RBAC
• Symmetric RBAC

ดูเพิ่มเติมที่ เอกสาร หากคุณสนใจ

Logto ปัจจุบันมีการนำเลเวล 1 มาใช้และจะก้าวไปสู่เลเวลที่สูงขึ้นตามความคิดเห็นของชุมชน อย่าลังเลที่จะแจ้งให้เราทราบหากระดับที่สูงขึ้นเหมาะสมกับความต้องการของคุณ!

ในภาคปฏิบัติ#

นอกเหนือจากทฤษฎี เรายังมีงานด้านเทคนิคที่หนักแน่นที่ต้องทำให้เสร็จเพื่อให้โมเดลทำงานได้ตามที่คาดหวัง:

• การพัฒนาคลายแอนด์เซิร์ฟเวอร์การยืนยันตัวตน
• การออกแบบฐานข้อมูลสำหรับ RBAC
• การตรวจสอบผ่านบริการต่าง ๆ
• การรักษาความปลอดภัยและการปฏิบัติตามมาตรฐานเปิด
• การจัดการบทบาท สิทธิ์ และทรัพยากร และการมอบหมาย

ไม่ต้องตกใจ เราคิดถึงประเด็นนี้แล้วและได้เพิ่มการสนับสนุนที่สามารถใช้ได้ทันทีเพื่อครอบคลุมทั้งหมดนี้ ตรวจสอบสูตร🔐 RBAC เพื่อเรียนรู้วิธีใช้ RBAC ใน Logto

หมายเหตุปิดท้าย#

RBAC เป็นโมเดลการจัดการการเข้าถึงที่ทรงพลังสำหรับหลายกรณี แต่ไม่มีวิธีแก้ปัญหาทุกอย่าง เรายังคงมีคำถามบางข้อ:

• ฉันต้องการระดับ RBAC สูงหรือไม่?
• RBAC เปรียบเทียบกับโมเดลการให้สิทธิ์อื่น ๆ อย่างไร?
• จะนิยามโมเดลการให้สิทธิ์ระหว่างองค์กรต่าง ๆ ได้อย่างไร?