ไทย

ciam
auth
การให้สิทธิ์

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

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

Gao

Founder

2/5/2023

หยุดเสียเวลาเป็นสัปดาห์กับการยืนยันตัวตนผู้ใช้

เปิดตัวแอปที่ปลอดภัยเร็วขึ้นด้วย Logto ผสานการยืนยันตัวตนผู้ใช้ภายในไม่กี่นาทีและมุ่งเน้นที่ผลิตภัณฑ์หลักของคุณ

เริ่มต้นใช้งาน

พื้นหลัง

ในบทความก่อนหน้า เราได้แนะนำแนวคิดของการรับรองตัวตน (AuthN) และการให้สิทธิ์ (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 เปรียบเทียบกับโมเดลการให้สิทธิ์อื่น ๆ อย่างไร?
จะนิยามโมเดลการให้สิทธิ์ระหว่างองค์กรต่าง ๆ ได้อย่างไร?

พื้นหลัง#

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

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

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

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

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

นิยามบทบาท#

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

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

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

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

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

พื้นหลัง#

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

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

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

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

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

นิยามบทบาท#

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

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

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

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

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

พื้นหลัง

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

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

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

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

นิยามสิทธิ์

นิยามบทบาท

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

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

เลเวล RBAC อื่น ๆ

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

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

พื้นหลัง

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

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

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

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

นิยามสิทธิ์

นิยามบทบาท

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

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

เลเวล RBAC อื่น ๆ

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

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