คู่มือที่สมบูรณ์เกี่ยวกับการควบคุมการเข้าถึงตามบทบาท (RBAC): การออกแบบสิทธิ์การเข้าถึง การจัดการบทบาท และการอนุญาตที่ปลอดภัยด้วยการใช้งาน CMS ในทางปฏิบัติ
คุณกำลังประสบปัญหาในการสร้างระบบการอนุญาตที่ปลอดภัยและสามารถขยายได้สำหรับแอปพลิเคชันของคุณหรือไม่? การควบคุมการเข้าถึงตามบทบาท (RBAC) เป็นมาตรฐานอุตสาหกรรมสำหรับการจัดการสิทธิ์ของผู้ใช้ แต่การทำให้ถูกต้องอาจเป็นเรื่องท้าทาย บทเรียนนี้จะแสดงวิธีการสร้างระบบ RBAC ที่แข็งแกร่งโดยใช้ตัวอย่างระบบการจัดการเนื้อหาจริง (CMS)
ด้วยการทำตามไกด์นี้ คุณจะได้เรียนรู้:
โค้ดต้นฉบับทั้งหมดสำหรับบทเรียนนี้มีอยู่บน GitHub
การควบคุมการเข้าถึงตามบทบาทมากกว่าการกำหนดสิทธิ์ให้ผู้ใช้ เป็นการสร้างวิธีการเชิงโครงสร้างเพื่อการอนุญาตที่สมดุลความปลอดภัยกับการบำรุงรักษา
คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับ What is RBAC ใน Auth Wiki
นี่คือหลักการสำคัญที่เราจะปฏิบัติตามในการนำไปใช้:
สิทธิ์ที่ละเอียดยิบให้คุณมีการควบคุมที่แม่นยำว่า ผู้ใช้สามารถทำอะไรได้บ้างในระบบของคุณ แทนที่จะใช้ระดับการเข้าถึงกว้างๆ เช่น "admin" หรือ "user" เรากำหนดการกระทำเฉพาะที่ผู้ใช้สามารถทำได้บนทรัพยากร ตัวอย่างเช่น:
read:articles - ดูบทความในระบบcreate:articles - สร้างบทความใหม่update:articles - แก้ไขบทความที่มีอยู่publish:articles - เปลี่ยนสถานะการเผยแพร่ของบทความการเป็นเจ้าของทรัพยากรเป็นแนวคิดพื้นฐานในการออกแบบการอนุญาตของ CMS ของเรา ในขณะที่ RBAC กำหนดว่าบทบาทต่างๆ สามารถทำการกระทำใดได้บ้าง เจ้าของเพิ่มมิติส่วนตัวในการควบคุมการเข้าถึง:
update:articles ผู้เขียนยังคงสามารถแก้ไขบทความของตนเองได้วิธีการสองชั้นนี้ (บทบาท + การเป็นเจ้าของ) สร้างระบบที่มีสัญชาตญาณและปลอดภัยขึ้น ผู้เผยแพร่และผู้ดูแลยังคงสามารถจัดการเนื้อหาทั้งหมดผ่านสิทธิ์บทบาทของพวกเขาในขณะที่ผู้เขียนยังคงควบคุมงานของตนเองได้
เริ่มต้นด้วยการออกแบบฟังก์ชั่นหลักของ CMS ผ่าน API endpoints ของมัน:
สำหรับแต่ละ endpoint เราจำเป็นต้องพิจารณาสองแง่มุมของการควบคุมการเข้าถึง:
นี่คือวิธีที่เราจะจัดการการเข้าถึงสำหรับแต่ละ endpoint:
| Endpoint | ตรรกะการควบคุมการเข้าถึง |
|---|---|
| GET /api/articles | - ทุกคนที่มีสิทธิ์ list:articles หรือผู้แต่งสามารถดูบทความของตนเองได้ |
| GET /api/articles/:id | - ทุกคนที่มีสิทธิ์ read:articles หรือผู้เขียนบทความ |
| POST /api/articles | - ทุกคนที่มีสิทธิ์ create:articles |
| PATCH /api/articles/:id | - ทุกคนที่มีสิทธิ์ update:articles หรือผู้เขียนบทความ |
| DELETE /api/articles/:id | - ทุกคนที่มีสิทธิ์ delete:articles หรือผู้เขียนบทความ |
| PATCH /api/articles/:id/published | - เฉพาะผู้ใช้ที่มีสิทธิ์ publish:articles |
ตามความต้องการของ API เราสามารถกำหนดสิทธิ์เหล่านี้:
| Permission | คำอธิบาย |
|---|---|
| list:articles | ดูรายการบทความทั้งหมดในระบบ |
| read:articles | อ่านเนื้อหาของบทความใดๆ |
| create:articles | สร้างบทความใหม่ |
| update:articles | แก้ไขบทความใดๆ |
| delete:articles | ลบบทความใดๆ |
| publish:articles | เปลี่ยนสถานะการเผยแพร่ |
สังเกตว่าสิทธิ์เหล่านี้ต้องการเพียงเมื่อเข้าถึงทรัพยากรที่คุณไม่ได้เป็นเจ้าของ ผู้เป็นเจ้าของบทความสามารถทำได้โดยอัตโนมัติ:
read:articles)update:articles)delete:articles)เมื่อเรากำหนด API และสิทธิ์เสร็จแล้ว เราสามารถสร้างบทบาทที่รวบรวมสิทธิ์เหล่านี้อย่างมีเหตุผล:
| Permission/Role | 👑 ผู้ดูแลระบบ | 📝 ผู้เผยแพร่ | ✍️ ผู้เขียน |
|---|---|---|---|
| คำอธิบาย | การเข้าถึงระบบทั้งหมดสำหรับการจัดการเนื้อหาทั้งหมด | สามารถดูบทความและควบคุมสถานะการเผยแพร่ | สามารถสร้างบทความใหม่ในระบบ |
| list:articles | ✅ | ✅ | ❌ |
| read:articles | ✅ | ✅ | ❌ |
| create:articles | ✅ | ❌ | ✅ |
| update:articles | ✅ | ❌ | ❌ |
| delete:articles | ✅ | ❌ | ❌ |
| publish:articles | ✅ | ✅ | ❌ |
หมายเหตุ: ผู้เขียนมีสิทธิ์ read/update/delete บทความของตนเองโดยอัตโนมัติ โดยไม่คำนึงถึงสิทธิ์บทบาท
แต่ละบทบาทถูกออกแบบด้วยความรับผิดชอบเฉพาะ:
โครงสร้างบทบาทนี้สร้างการแยกแยะความรับผิดชอบที่ชัดเจน:
ก่อนที่คุณจะเริ่ม คุณจำเป็นต้องสร้างบัญชีใน Logto Cloud หรือคุณสามารถใช้ Logto ด้วยตัวเองโดยใช้ Logto OSS version
แต่สำหรับบทเรียนนี้เราจะใช้ Logto Cloud เพื่อความสะดวก
list:articlesread:articlescreate:articlesupdate:articlespublish:articlesdelete:articles
ไปที่บทบาทใน Logto Console เพื่อสร้างบทบาทต่อไปนี้สำหรับ CMS
read:articles, list:articles, publish:articlescreate:articles
ไปที่ส่วน "การจัดการผู้ใช้" ใน Logto Console เพื่อสร้างผู้ใช้
ในแท็บ "บทบาท" ของรายละเอียดผู้ใช้ คุณสามารถมอบบทบาทให้กับผู้ใช้ได้
ในตัวอย่างของเรา เราสร้างผู้ใช้ 3 คนพร้อมบทบาทดังนี้:
ตอนนี้เราได้ตั้งค่า RBAC ใน Logto แล้ว เราสามารถเริ่มรวมเข้ากับส่วนหน้า
ก่อนอื่น ทำตาม Logto Quick Starts เพื่อรวม Logto เข้ากับแอปพลิเคชันของคุณ
ในตัวอย่างของเรา เราใช้ React เพื่อตัวอย่าง
หลังจากที่คุณได้ติดตั้ง Logto ในแอปพลิเคชันของคุณแล้ว เราจำเป็นต้องเพิ่มการกำหนดค่า RBAC เพื่อให้ Logto ใช้งานได้
อย่าลืมออกจากระบบและเข้าสู่ระบบใหม่เพื่อให้การเปลี่ยนแปลงนี้มีผลหากคุณได้เข้าสู่ระบบแล้ว
เวลาที่ผู้ใช้ลงชื่อเข้าใช้ด้วย Logto และขอเครื่องหมายการเข้าถึงสำหรับทรัพยากร API ที่ระบุด้านบน Logto จะเพิ่มขอบเขต (สิทธิ์) ที่เกี่ยวข้องกับบทบาทของผู้ใช้ลงในเครื่องหมายการเข้าถึง
คุณสามารถใช้ getAccessTokenClaims จากฮุก useLogto เพื่อดึงขอบเขตจากเครื่องหมายการเข้าถึง
และคุณสามารถใช้ userScopes เพื่อตรวจสอบว่าผู้ใช้มีสิทธิ์ในการเข้าถึงทรัพยากรหรือไม่
ตอนนี้ถึงเวลาในการรวม Logto RBAC เข้ากับส่วนหลังของคุณ
ก่อนอื่น เราจำเป็นต้องเพิ่มมิดเดิลแวร์ในส่วนหลัง เพื่อตรวจสอบสิทธิ์ของผู้ใช้ ตรวจสอบว่าผู้ใช้ได้เข้าสู่ระบบหรือไม่ และตรวจสอบว่าพวกเขามีสิทธิ์ที่จำเป็นในการเข้าถึง API บางอย่างหรือไม่
ในส่วนของมิดเดิลแวร์นี้ เราตรวจสอบว่าคำขอจากส่วนหน้ามีเครื่องหมายการเข้าถึงที่ถูกต้องหรือไม่ และตรวจสอบว่าผู้ใช้มีสิทธิ์ที่จำเป็นในการเข้าถึง API บางอย่างหรือไม่
เหตุผลที่เราตรวจสอบทรัพยากร API เนื่องจากทรัพยากร API ของเราจริงๆ แล้วแทนทรัพยากรของส่วนหลัง CMS ของเรา และสิทธิ์การเข้าถึง CMS ทั้งหมดของเราถูกเชื่อมโยงกับทรัพยากร API นี้
เนื่องจากทรัพยากร API นี้แทนทรัพยากร CMS ใน Logto ในโค้ดส่วนหน้าของเรา เราจึงเพิ่มเครื่องหมายเข้าถึงที่สอดคล้องกันเมื่อทำการร้องขอ API ไปยังส่วนหลัง:
ตอนนี้เราสามารถใช้มิดเดิลแวร์ requireAuth เพื่อปกป้อง API endpoints ของเรา
สำหรับ API ที่ควรเข้าถึงได้เฉพาะผู้ใช้ที่มีสิทธิ์ที่เฉพาะเจาะจง เราสามารถเพิ่มการจำกัดโดยตรงในมิดเดิลแวร์ได้ เช่น API การสร้างบทความควรเข้าถึงได้เฉพาะผู้ใช้ที่มีสิทธิ์ create:articles เท่านั้น:
สำหรับ API ที่ต้องตรวจสอบทั้งสิทธิ์และการเป็นเจ้าของทรัพยากร เราสามารถใช้ฟังก์ชัน hasScopes ได้ เช่น ใน API การแสดงรายการบทความ ผู้ใช้ที่มีสิทธิ์ list:articles สามารถเข้าถึงบทความทั้งหมดได้ ในขณะที่ผู้เขียนสามารถเข้าถึงบทความที่เขาเป็นผู้สร้างเท่านั้น:
ถึงจุดนี้เราได้ดำเนินการ RBAC เสร็จสมบูรณ์แล้ว คุณสามารถตรวจสอบ โค้ดต้นฉบับทั้งหมด เพื่อดูการดำเนินการทั้งหมดได้
ตอนนี้ลองทดสอบการใช้ CMS RBAC ของเราโดยใช้ผู้ใช้สามคนที่เราเพิ่งสร้างขึ้น
ก่อนอื่นลงชื่อเข้าใช้ในบทบาทของ Alex และ Charles แล้วสร้างบทความจะได้รับบทความใหม่
เนื่องจาก Alex มีบทบาทผู้ดูแลระบบ พวกเขาสามารถสร้าง ลบ แก้ไข เผยแพร่ และดูบทความทั้งหมด
Charles ที่มีบทบาทผู้เขียน สามารถสร้างบทความของเขาเองและสามารถดู แก้ไข และลบบทความที่เขาเป็นเจ้าของเท่านั้น
Bob ในบทบาทผู้เผยแพร่ สามารถดูบทความทั้งหมดและจัดการการเผยแพร่แต่ไม่สามารถสร้าง แก้ไข หรือ ลบได้
ยินดีด้วย! คุณได้เรียนรู้วิธีการใช้ระบบ RBAC ที่แข็งแกร่งในแอปพลิเคชันของคุณ
สำหรับกรณีที่ซับซ้อนมากขึ้น เช่น การสร้างแอปพลิเคชัน multi-tenant, Logto มีการสนับสนุนที่ครอบคลุมสำหรับองค์กร เข้าไปดูที่คำแนะนำของเราได้ที่ Build a multi-tenant SaaS application: A complete guide from design to implementation เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับการควบคุมการเข้าถึงในระดับองค์กร
การเขียนโค้ดที่มีความสุข! 🚀