AuthZ (การอนุญาต) คืออะไร?
สำรวจความหมายของ AuthZ, AuthN เปรียบเทียบกับ AuthZ, วิธีการทำงานของ AuthZ, และแนวปฏิบัติที่ดีที่สุดในการอนุญาต
สำรวจความหมายของ AuthZ, AuthN เปรียบเทียบกับ AuthZ, วิธีการทำงานของ AuthZ, และแนวปฏิบัติที่ดีที่สุดในการอนุญาต
AuthZ เป็นคำย่อของ การอนุญาต การอนุญาตเป็นกลไกที่แยกจาก การตรวจสอบสิทธิ์ ในขณะที่การตรวจสอบสิทธิ์ระบุว่าคุณคือใคร การอนุญาตจะกำหนดว่าคุณสามารถเข้าถึงทรัพยากรเฉพาะและทำการกระทำอะไรกับมันได้บ้าง
ในตัวอย่างในโลกจริง ทรัพยากรสามารถรวมถึงซอฟต์แวร์, ระบบ, เอกสาร, คำสั่งซื้อ, และทรัพย์สินต่าง ๆ การอนุญาตเพิ่มชั้นของการควบคุมโดยเฉพาะว่าใครสามารถเข้าถึงทรัพยากรต่าง ๆ เหล่านี้และภายใต้เงื่อนไขใดบ้าง
การอนุญาตแยกจากการตรวจสอบสิทธิ์ แต่หลายครั้งจะเชื่อมโยงกับมัน ตัวอย่างเช่น โปรโตคอลมาตรฐานเช่น OAuth 2.0, OIDC, และ SAML ผสานกลไกการอนุญาตที่ใช้งานตามโทเค็น
ในระบบการอนุญาตตามโทเค็น เซิร์ฟเวอร์การอนุญาตจะให้ access token แก่ผู้ใช้ โทเค็นนี้ซึ่งรวมถึงสิทธิ์จะกำหนดว่าผู้ใช้สามารถเข้าถึงทรัพยากรเฉพาะได้หรือไม่
การกำหนดสิทธิ์โดยตรงให้กับผู้ใช้อาจไม่มีประสิทธิภาพ โดยเฉพาะเมื่อมีเงื่อนไขที่ละเอียดอ่อนมากขึ้น จำเป็นต้องใช้การจัดการนโยบายการเข้าถึงสำหรับการจัดการสิทธิ์ที่ดีขึ้น
นี่คือขั้นตอนการทำงานในระดับสูงในการดำเนินงานของการอนุญาต:
หากต้องการทำความเข้าใจกับการไหลของการขออนุญาต OAuth 2.0 โดยละเอียด โปรดดูที่ การขออนุญาต
การควบคุมการเข้าถึงตามบทบาท (RBAC) ใช้บทบาทในการจัดการการเข้าถึง ผู้ใช้แต่ละคนจะถูกกำหนดบทบาทหนึ่งหรือหลายบทบาทที่กำหนดไว้ล่วงหน้า และทุกบทบาทจะรวมถึงชุดของสิทธิ์ การเข้าใจความสัมพันธ์ระหว่างผู้ให้บริการ (หรือผู้ใช้) บทบาท และสิทธิ์คือกุญแจสำคัญของ RBAC
ในการเข้าใจวิธีทำงานของการควบคุมการเข้าถึงตามบทบาท (RBAC) คุณต้องรู้เกี่ยวกับ:
user หรือ machine-to-machine applicationadmin memberread: order
การควบคุมการเข้าถึงตามคุณลักษณะ (ABAC) ใช้ในงานอนุญาตและรองรับสถานการณ์ที่มีความซับซ้อนมากขึ้นโดยการใช้คุณลักษณะเฉพาะของหน่วยงาน มากกว่าที่จะใช้อิงบทบาทอย่างเดียว
ตัวอย่างเช่น บริษัทหนึ่งจัดการแพลตฟอร์มแบ่งปันเอกสารระดับโลกที่พนักงานต้องการเข้าถึงเอกสารที่มีความอ่อนไหวตามบทบาทงาน, ที่ตั้ง, และระดับการจัดประเภทของเอกสาร
คุณลักษณะสามารถออกแบบได้ดังนี้:
ยังมีโมเดลการควบคุมการเข้าถึงอื่น ๆ เช่น การควบคุมการเข้าถึงตามนโยบาย (PBAC) ซึ่งมีจุดแข็งและข้อด้อยต่างกัน และการเลือกโมเดลขึ้นอยู่กับกรณีการใช้งานและความต้องการของคุณ
ซอฟต์แวร์ B2C มักต้องการบทบาทเฉพาะตามความต้องการทางธุรกิจ ตัวอย่างเช่น แอปจัดการร้านหนังสืออาจรวมถึงบทบาทที่มีความรับผิดชอบต่าง ๆ เช่น การจัดการทรัพยากรและบริการ
แอป B2B มักใช้สถาปัตยกรรมหลายผู้เช่าที่แต่ละผู้เช่าแทนองค์กร ในองค์กรต้องมีบทบาทเช่น admin และ member นี่คือที่ซึ่งการอนุญาต (AuthZ) มีบทบาทสำคัญในการจัดการผู้ใช้ในระดับองค์กร โดยมักใช้การควบคุมการเข้าถึงตามบทบาท (RBAC)
การสื่อสารเครื่องต่อเครื่อง เกิดขึ้นโดยตรงระหว่างบริการโดยไม่มีการโต้ตอบของมนุษย์ ตัวอย่างเช่น การเรียกใช้บริการ API โดย. มักเกี่ยวข้องกับโทเค็น (เช่น OAuth 2.0 access tokens) เพื่อให้เข้าถึงได้ปลอดภัย, แปรผัน, และระเอียด
ต่อไปนี้คือ แนวปฏิบัติที่ดีที่สุดสำหรับการอนุญาต (authZ) เพื่อให้แน่ใจว่าการควบคุมการเข้าถึงมีความปลอดภัยและมีประสิทธิภาพ:
หลักการของสิทธิพิเศษน้อยที่สุด
สิ่งนี้จะช่วยลดความเสี่ยงของการเข้าถึงหรือการสร้างความเสียหายที่ไม่ได้รับอนุญาตจากบัญชีผู้ใช้ที่ถูกคุกคาม ผู้ใช้และระบบควรเข้าถึงเฉพาะทรัพยากรและการกระทำที่จำเป็นสำหรับบทบาทของพวกเขา
ใช้การอนุญาตที่ใช้โทเค็น
การควบคุมการเข้าถึงที่ใช้โทเค็นให้ความยืดหยุ่นและการควบคุมที่ละเอียดมากขึ้นในขณะที่ยึดมาตรฐานเปิด ใช้โทเค็นที่ปลอดภัย (เช่น OAuth 2.0, JWTs) เพื่อให้เข้าถึงตามช่วงเวลาและขอบเขต
ตรวจสอบและติดตามเป็นประจำ
การตรวจสอบบันทึกการเข้าถึงและนโยบายการอนุญาตเป็นประจำเป็นสิ่งจำเป็นในการตรวจสอบความผิดปกติหรือสิทธิ์ที่ล้าสมัย
บังคับใช้การแยกหน้าที่
เริ่มต้นด้วยการกำหนดสิทธิ์ที่ละเอียดเช่นการกำหนดการกระทำและทรัพยากรเฉพาะ (เช่น อ่าน, เขียน, ลบ) เมื่อสร้างบทบาทให้ใช้ชื่อบทบาทที่ชัดเจนและบังคับใช้การแยกหน้าที่เพื่อลดความเสี่ยงของการฉ้อโกงหรือความผิดพลาดโดยผู้ใช้หนึ่งคน
รองรับหลายผู้ใช้ (ถ้าใช้ได้)
สำหรับระบบหลายผู้ผู้ เช่าความสำคัญของการแยกผู้เช่าเป็นสิ่งสำคัญ โดยการรวมกันกับการควบคุมการเข้าถึงตามบทบาท คุณสามารถบรรลุการแยกแหล่งข้อมูล เพื่อให้แน่ใจว่าบทบาทที่เหมาะสมสามารถเข้าถึงทรัพยากรได้เฉพาะในผู้เช่าของพวกเขา ซึ่งป้องกันการเข้าถึงที่ไม่ได้ตั้งใจหรือเป็นอันตรายต่อทรัพยากรของผู้เช่าอื่น
เพิกถอนการเข้าถึงแบบไดนามิก
เมื่อออกแบบระบบ AuthZ ของคุณให้มั่นใจว่าสิทธิ์สามารถปรับปรุงหรือเพิกถอนได้ทันทีหากเงื่อนไขเปลี่ยนแปลง (เช่น การปรับปรุงบทบาท หรือการยุติการจ้างงาน) สิ่งนี้สามารถทำได้ผ่านการตรวจสอบ API แบบไดนามิก การใช้เว็บฮุค หรือวิธีการอื่น ๆ เป้าหมายคือการป้องกันการเข้าถึงที่ไม่ได้รับอนุญาตในเวลาจริง
ความแตกต่างระหว่างการตรวจสอบสิทธิ์และการอนุญาตอยู่ที่วัตถุประสงค์และกระบวนการในโครงสร้างการระบุตัวตนและการเข้าถึง
AuthN (การตรวจสอบสิทธิ์) ตอบคำถามว่า “คุณคือใครและเป็นเจ้าของตัวตนใด” เป็นกระบวนการในการตรวจสอบตัวตนของผู้ใช้, บริการหรืออุปกรณ์ การตรวจสอบสิทธิ์ช่วยให้มั่นใจว่าหน่วยงานที่พยายามเข้าถึงระบบหรือทรัพยากรเป็นของจริง วิธีที่พบบ่อยได้แก่ รหัสผ่าน, ไบโอเมตริก และการตรวจสอบยืนยันสองปัจจัย (2FA) ตัวอย่างเช่น เมื่อคุณล็อกอินในบัญชีโดยใช้อีเมลและรหัสผ่าน ระบบจะยืนยันตัวตนของคุณผ่านการตรวจสอบสิทธิ์
AuthZ (การอนุญาต) ตอบคำถามว่า “คุณได้รับอนุญาตให้ทำอะไร?” เป็นกระบวนการในการอนุญาตหรือปฏิเสธการเข้าถึงทรัพยากรตามสิทธิ์หรือบทบาทของผู้ใช้ การอนุญาตเกิดขึ้นหลังจากการตรวจสอบสิทธิ์และกำหนดว่าจะให้กระทำใดสำหรับผู้ใช้ที่ผ่านการตรวจสอบ ตัวอย่างเช่น หลังจากล็อกอิน ผู้ใช้ที่เป็น admin อาจมีสิทธิ์ในการแก้ไขการตั้งค่า ขณะที่ผู้ใช้ทั่วไปสามารถดูเท่านั้น
โดยสรุป AuthN (การตรวจสอบสิทธิ์) ยืนยันตัวตน ขณะที่ AuthZ (การอนุญาต) กำหนดการเข้าถึง การตรวจสอบสิทธิ์เกิดขึ้นก่อน ตามมาด้วยการอนุญาตเพื่อให้ใช้ทรัพยากรได้อย่างปลอดภัยและเหมาะสม
Logto Cloud เสนอการบริการการอนุญาตที่สำคัญตามโปรโตคอลมาตรฐานเปิดเช่น OIDC, OAuth 2.0 และ SAML ฟีเจอร์รวมถึง การควบคุมการเข้าถึงตามบทบาท, องค์กร (หลายผู้เช่า), และ การอ้างสิทธิ์โทเค็นที่กำหนดเอง เพื่อตอบสนองความต้องการการอนุญาตของคุณจากมุมมองที่หลากหลาย