การยืนยันตัวตน (Authentication) และการกำหนดสิทธิ์ (Authorization) ในสถาปัตยกรรมไมโครเซอร์วิส
(microservices.io)ซีรีส์นี้กล่าวถึงวิธีการนำการยืนยันตัวตน (Authentication) และการกำหนดสิทธิ์ (Authorization) ไปใช้งานในสถาปัตยกรรมไมโครเซอร์วิส
บทความนี้จะอธิบายภาพรวมทั้งหมด พร้อมเปรียบเทียบความแตกต่างกับแอปพลิเคชันแบบเดี่ยว (Monolithic)
แอปพลิเคชันตัวอย่าง: RealGuard.io
RealGuard.io เป็นแพลตฟอร์มระบบรักษาความปลอดภัยเชิงพาณิชย์ ที่ใช้จัดการการควบคุมอุปกรณ์รักษาความปลอดภัยและการแจ้งเตือน
ผู้ใช้สังกัดบริษัทผู้ขาย บริษัทลูกค้า และผู้ให้บริการมอนิเตอร์ ซึ่งแต่ละกลุ่มมีสิทธิ์เข้าถึงแตกต่างกัน
การยืนยันตัวตนและการกำหนดสิทธิ์ในสถาปัตยกรรม Monolithic
โครงสร้างแบบ Monolithic ประกอบด้วยแอปพลิเคชันหนึ่งตัวและฐานข้อมูลหนึ่งชุด โดยการยืนยันตัวตนถูกทำผ่าน session token
การกำหนดสิทธิ์ทำงานในโครงสร้างดังนี้:
isAllowed(user, operation, resource)
ตัวอย่าง:
isAllowed(user, "disarm", SecuritySystem(ID))
โมเดลการกำหนดสิทธิ์ 4 แบบ
- RBAC: การควบคุมการเข้าถึงตามบทบาท — ตัดสินสิทธิ์จากบทบาทที่มอบให้ผู้ใช้
- ReBAC: การควบคุมการเข้าถึงตามความสัมพันธ์ — ตัดสินการเข้าถึงจากความสัมพันธ์ระหว่างผู้ใช้กับทรัพยากร
- ABAC: การควบคุมการเข้าถึงตามแอตทริบิวต์ — ตัดสินจากแอตทริบิวต์ของผู้ใช้ ทรัพยากร และสภาพแวดล้อม
- โมเดลผสม: ผสานทั้ง 3 แบบเข้าด้วยกันเพื่อสร้างนโยบายที่ซับซ้อนได้
ตัวอย่างการกำหนดสิทธิ์และสิทธิ์ตามบทบาท
| Operation | Required Role |
|---|---|
| getAlarmSystem() | SecuritySystemViewer |
| armSystem() | SecuritySystemArmer |
| disarmSystem() | SecuritySystemDisarmer |
| cancelSystem() | SecuritySystemAlarmCanceller |
นอกจากบทบาทเฉพาะแล้ว ยังอาจมีเงื่อนไขเพิ่มเติม เช่น ข้อจำกัดตามเวลางาน (ABAC) หรือการมีอยู่ในรายการแจ้งเตือน
ตำแหน่งที่ใช้ตรวจสอบการกำหนดสิทธิ์
- โครงสร้างพื้นฐานเครือข่าย: สามารถตรวจสอบสิทธิ์แบบง่ายได้ใน service mesh, ingress controller เป็นต้น
- REST API handler: จัดการการกำหนดสิทธิ์ระดับคำขอแบบ coarse-grained
- ตรรกะโดเมน: จัดการการกำหนดสิทธิ์ตามเงื่อนไขที่ซับซ้อน
- ชั้นการเข้าถึง DB: กรองสิทธิ์ภายใน SQL (มีประสิทธิภาพกับงานปริมาณมาก)
การกำหนดสิทธิ์ใน UI
UI ไม่สามารถบังคับใช้การกำหนดสิทธิ์ได้โดยตรง แต่สามารถปรับปรุง UX ได้ด้วยการแสดงหรือปิดใช้งานปุ่ม/ฟีเจอร์ตามสิทธิ์ของผู้ใช้
การยืนยันตัวตนในสถาปัตยกรรมไมโครเซอร์วิส
BFF (Backend For Frontend) รับผิดชอบการล็อกอินและการจัดการเซสชัน
เนื่องจากแต่ละไมโครเซอร์วิสทำงานแยกอิสระ จึงไม่สามารถเข้าถึงข้อมูลผู้ใช้จากเซสชันได้โดยตรง และต้องส่งต่อข้อมูลผู้ใช้ผ่านโทเคน เช่น JWT
การกำหนดสิทธิ์ในสถาปัตยกรรมไมโครเซอร์วิส
คำขอจะถูกส่งต่อในลำดับ BFF → SecurityService และสามารถตรวจสอบการกำหนดสิทธิ์ได้ใน 3 ตำแหน่งต่อไปนี้:
- BFF: สามารถกำหนดสิทธิ์ระดับคำขอตามเส้นทางและเมธอด โดยอิงจากข้อมูลเซสชัน
- Inter-service Network: service mesh ดำเนินการกำหนดสิทธิ์บางส่วนโดยอิงจาก JWT
- ภายในแต่ละเซอร์วิส: ทำการกำหนดสิทธิ์ในตรรกะโดเมนและชั้นการเข้าถึง DB
ความยากของการกำหนดสิทธิ์แบบกระจาย
เนื่องจากแต่ละเซอร์วิสไม่ได้มีข้อมูลที่จำเป็นทั้งหมดอยู่ในฐานข้อมูลของตัวเอง จึงอาจต้องเรียก API ของเซอร์วิสอื่นเพื่อใช้ในการกำหนดสิทธิ์
แม้จะพยายามแก้ด้วย JWT แต่ก็มีปัญหาเรื่องขนาดโทเคนและต้นทุนในการตรวจสอบ
สรุป
- การยืนยันตัวตนคือการตรวจสอบตัวตนของผู้ใช้ ส่วนการกำหนดสิทธิ์คือการตัดสินว่ามีสิทธิ์หรือไม่
- แพตเทิร์น
isAllowed(user, operation, resource)คือหัวใจของการกำหนดสิทธิ์ - ใช้โมเดล RBAC, ReBAC และ ABAC ร่วมกันเพื่อสร้างระบบกำหนดสิทธิ์
- ใน Monolithic การกำหนดสิทธิ์ทำได้ง่ายกว่าเพราะเข้าถึงฐานข้อมูลชุดเดียวได้
- ในไมโครเซอร์วิส ข้อมูลที่ใช้กำหนดสิทธิ์กระจายอยู่หลายจุด ทำให้การพัฒนาซับซ้อนกว่า
ยังไม่มีความคิดเห็น