โมเดลการควบคุมการเข้าถึง RBAC และ ABAC ที่ควรรู้

บทนำ#

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

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

การควบคุมการเข้าถึงตามบทบาท (RBAC) ถูกนำเสนอครั้งแรกในช่วงต้นทศวรรษ 1990 การสร้างโมเดลนี้เป็นที่เครดิตของ David Ferraiolo และ Rick Kuhn ในบทความ ที่ตีพิมพ์ในปี 1992 ตั้งแต่นั้นมา RBAC ได้กลายเป็นหนึ่งในโมเดลการควบคุมการเข้าถึงที่ใช้ในอุตสาหกรรมมากที่สุด

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

องค์ประกอบสำคัญของ RBAC#

• ทรัพยากร: ทรัพยากรเป็นเอนทิตีที่ผู้ใช้สามารถเข้าถึงได้ ทรัพยากรสามารถเป็นอะไรก็ได้ตั้งแต่ไฟล์ ฐานข้อมูล API หรือเอนทิตีระบบอื่น ๆ ที่ต้องได้รับการป้องกัน
• สิทธิ์: สิทธิ์เป็นการกระทำเฉพาะที่ผู้ใช้สามารถทำบนทรัพยากรได้ เช่น สร้าง แก้ไข ลบ ดู คำจำกัดความของสิทธิ์อาจเปลี่ยนแปลงได้ขึ้นอยู่กับระบบ ในกรณีส่วนใหญ่ สิทธิ์จะถูกกำหนดที่ระดับของทรัพยากรด้วยความละเอียดขั้นต่ำ
• บทบาท: บทบาทเป็นการรวบรวมของสิทธิ์ที่กำหนดการทำงานของผู้ใช้ ตัวอย่างเช่น บทบาทผู้ดูแลระบบอาจมีสิทธิ์ในการสร้าง แก้ไข และลบทรัพยากร ขณะที่บทบาทผู้ชมอาจมีสิทธิ์ในการดูทรัพยากร
• ผู้ใช้: ผู้ใช้เป็นเอนทิตีที่สามารถถูกกำหนดบทบาทหนึ่งหรือมากกว่านั้น ผู้ใช้จะได้รับการเข้าถึงทรัพยากรตามสิทธิ์ที่เชื่อมโยงกับบทบาทที่พวกเขาได้รับ

รูปแบบ RBAC ต่างๆ#

มีหลายรูปแบบของ RBAC ที่ขยายโมเดลพื้นฐานเพื่อรองรับความต้องการควบคุมการเข้าถึงที่ซับซ้อนมากขึ้น:

• RBAC0: โมเดลพื้นฐานที่ผู้ใช้ได้รับบทบาทและบทบาทได้รับสิทธิ์
• RBAC1: เพิ่มแนวคิดของลำดับชั้นบทบาท บทบาทสามารถสืบต่อสิทธิ์จากบทบาทอื่นๆ ได้ รู้จักกันอีกชื่อว่า Hierarchical RBAC
• RBAC2: เพิ่มข้อจำกัดให้บทบาท ข้อจำกัดสามารถใช้เพื่อกำหนดเงื่อนไขเพิ่มเติมที่ต้องพอใจก่อนที่ผู้ใช้จะถูกกำหนดบทบาท รู้จักกันอีกชื่อว่า Constraint-based RBAC
• RBAC3: รวมคุณสมบัติของ RBAC1 และ RBAC2 มันรองรับทั้งลำดับชั้นบทบาทและข้อจำกัด

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับรูปแบบต่างๆ เหล่านี้ อ้างถึง โมเดล RBAC และการพัฒนาของพวกมัน

ข้อดีของ RBAC#

• ความเรียบง่าย: RBAC เข้าใจได้ง่ายและนำไปใช้ง่าย การกำหนดสิทธิ์ให้บทบาทและบทบาทให้ผู้ใช้ง่ายๆ
• ประสิทธิภาพ: มันทำให้การจัดการนโยบายการควบคุมการเข้าถึงง่ายขึ้นโดยการจัดกลุ่มผู้ใช้ตามบทบาทของพวกเขา และง่ายในการเพิ่มหรือเอาผู้ใช้ออกจากบทบาทโดยไม่ต้องเปลี่ยนนโยบายการควบคุมการเข้าถึง โดยเฉพาะในองค์กรขนาดใหญ่ที่มีโครงสร้างสิทธิ์ที่ชัดเจน RBAC สามารถเป็นตัวเลือกที่มีประสิทธิภาพมาก
• ความโปร่งใส: RBAC ให้แผนผังที่ชัดเจนระหว่างบทบาท สิทธิ์ และผู้ใช้ ง่ายต่อการสอบทานและทบทวนนโยบายการควบคุมการเข้าถึง

ข้อเสียของ RBAC#

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

การควบคุมการเข้าถึงตามคุณสมบัติ (ABAC)#

ในช่วงปลายทศวรรษ 2000 เมื่อระบบเริ่มซับซ้อนและมีความยืดหยุ่นมากขึ้น องค์กรจำนวนมากขึ้นเริ่มหันมาใช้การควบคุมการเข้าถึงตามคุณสมบัติ (ABAC) เป็นทางเลือกของ RBAC จุดเด่นสำคัญในการสร้าง ABAC คือการตีพิมพ์ NIST Special Publication 800-162 ในปี 2014

ABAC เป็นโมเดลการควบคุมการเข้าถึงที่ยืดหยุ่นกว่าเมื่อเทียบกับ RBAC มันเป็นโมเดลการอนุญาตที่กำหนดนโยบายการควบคุมการเข้าถึงตามคุณสมบัติของผู้ใช้ ทรัพยากร การกระทำ และสิ่งแวดล้อม มันช่วยให้องค์กรสามารถกำหนดนโยบายการควบคุมการเข้าถึงที่ละเอียดและสามารถปรับเปลี่ยนได้ตามบริบทและเงื่อนไขต่างๆ

องค์ประกอบสำคัญของ ABAC#

• วัตถุประสงค์: วัตถุประสงค์เป็นเอนทิตีที่ขอการเข้าถึงทรัพยากร มันอาจจะเป็นผู้ใช้ อุปกรณ์ แอปพลิเคชัน หรือเอนทิตีอื่นๆ ที่ต้องการเข้าถึงทรัพยากร
• ทรัพยากร: เหมือนกับใน RBAC ทรัพยากรเป็นเอนทิตีที่วัตถุประสงค์สามารถเข้าถึงได้ ทรัพยากรสามารถเป็นไฟล์ ฐานข้อมูล API หรือเอนทิตีระบบอื่น ๆ
• การกระทำ: การกระทำเป็นการดำเนินการเฉพาะที่วัตถุประสงค์สามารถทำบนทรัพยากร มันสามารถเป็นการสร้าง อ่าน อัปเดต ลบ หรือการดำเนินการอื่นๆ ที่ต้องถูกควบคุม
• สิ่งแวดล้อม: สิ่งแวดล้อมเป็นบริบทที่การขอเข้าถึงถูกทำ มันสามารถรวมถึงคุณสมบัติต่างๆ เช่น เวลา สถานที่ เครือข่าย อุปกรณ์ เป็นต้น
• คุณสมบัติ: คุณสมบัติเป็นลักษณะของวัตถุประสงค์ ทรัพยากร การกระทำ หรือสิ่งแวดล้อม คุณสมบัติสามารถเป็นอะไรก็ได้จากบทบาทของผู้ใช้ แผนก สถานที่ ที่อยู่ IP ประเภทอุปกรณ์ เป็นต้น
• นโยบาย: นโยบายเป็นกฎที่กำหนดเงื่อนไขภายใต้ซึ่งการเข้าถึงได้รับหรือถูกปฏิเสธ นโยบายถูกกำหนดไว้ตามคุณสมบัติ

ข้อดีของ ABAC#

• ความยืดหยุ่น: ABAC สามารถตอบสนองต่อนโยบายการควบคุมการเข้าถึงที่ซับซ้อนซึ่งอิงตามหลายคุณสมบัติ มันช่วยให้องค์กรสามารถกำหนดนโยบายที่ละเอียดอ่อนซึ่งสามารถปรับเปลี่ยนได้กับบริบทและเงื่อนไขที่ต่างกัน
• ความเป็นพลวัต: นโยบายของ ABAC สามารถเป็นพลวัตและมีความตระหนักถึงบริบท การตัดสินใจในการควบคุมการเข้าถึงสามารถถูกทำขึ้นตามคุณสมบัติที่เกิดขึ้นจริงเช่น สถานที่ เวลาของวัน ประเภทอุปกรณ์ เป็นต้น
• ความละเอียด: ABAC ให้การควบคุมการเข้าถึงที่ละเอียดอ่อนโดยอนุญาตให้องค์กรสามารถกำหนดนโยบายตามคุณสมบัติหลายประการ ไม่เหมือนกับการกำหนดบทบาทและสิทธิ์ นโยบายที่อิงตามคุณสมบัติสามารถละเอียดอ่อนได้มากกว่า

ข้อเสียของ ABAC#

• ความซับซ้อน: ABAC สามารถมีความซับซ้อนมากขึ้นในการนำเข้าและจัดการเมื่อเทียบกับ RBAC การกำหนดคุณสมบัติและนโยบายสามารถต้องการความพยายามและความชำนาญมากกว่า ไม่เหมือนกับ RBAC ที่บทบาทและสิทธิ์มีโครงสร้างชัดเจน คุณสมบัติสามารถพลวัตมากกว่าและนโยบายก็ด้วย การจัดการคุณสมบัติและนโยบายจำนวนมากในระบบที่ซับซ้อนสามารถเป็นความท้าทาย มักจำเป็นต้องมีเครื่องมือประเมินนโยบายที่ศูนย์กลางเพื่อประเมินนโยบาย
• ประสิทธิภาพ: การประเมินคุณสมบัติสามารถมีผลต่อประสิทธิภาพ โดยเฉพาะในสภาพแวดล้อมที่เกิดขึ้นจริง นโยบายที่อิงตามหลายคุณสมบัติและเงื่อนไขที่เกิดขึ้นจริงสามารถทำให้เวลาในการตัดสินใจของการควบคุมการเข้าถึงช้า

ตารางเปรียบเทียบ#

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

ตัวอย่าง#

สถานการณ์: ระบบของโรงพยาบาลที่ต้องจัดการการเข้าถึงแฟ้มประวัติผู้ป่วยสำหรับบุคลากรที่แตกต่างกัน

• บุคลากร: หมอ พยาบาล ผู้ดูแลระบบ
• ทรัพยากร: แฟ้มประวัติผู้ป่วย
• สิทธิ์: อ่าน เขียน ลบ

กรณีที่ 1#

นโยบายการควบคุมการเข้าถึงค่อนข้างง่าย:

1. หมอสามารถอ่านและเขียนแฟ้มประวัติผู้ป่วยได้
2. พยาบาลสามารถอ่านแฟ้มประวัติผู้ป่วยได้
3. ผู้ดูแลระบบสามารถอ่าน เขียน และลบแฟ้มประวัติผู้ป่วยได้

โมเดล RBAC#

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

การประเมินการควบคุมการเข้าถึงค่อนข้างตรงไปตรงมา:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')

โมเดล ABAC#

ในกรณีนี้ ABAC อาจจะเกินไปแต่มันยังสามารถใช้งานได้เพื่อกำหนดนโยบายที่ละเอียดอ่อนตามคุณสมบัติเช่นแผนก บทบาท เป็นต้น

คุณสมบัติ:

• user.role: doctor, nurse, admin
• resource.name: patient-record
• action: read, write, delete

นโยบาย:

• นโยบาย 1: อนุญาตการเข้าถึงการอ่านตาม user.role และ resource.name
  • subject: ผู้ใช้ที่มีบทบาท doctor, nurse, admin
  • resource: ทรัพยากรที่มีชื่อ patient-record
  • action: read
  • effect: allow
  • rationale: "อนุญาตการเข้าถึงการอ่านแฟ้มประวัติผู้ป่วยสำหรับทุกบทบาท"
• นโยบาย 2: การเข้าถึงการแก้ไขสำหรับหมอและผู้ดูแลระบบ
  • subject: ผู้ใช้ที่มีบทบาท doctor, admin
  • resource: ทรัพยากรที่มีชื่อ patient-record
  • action: write
  • effect: allow
  • rationale: "อนุญาตการเข้าถึงการเขียนแฟ้มประวัติผู้ป่วยสำหรับหมอและผู้ดูแลระบบ"
• นโยบาย 3: การเข้าถึงการลบสำหรับผู้ดูแลระบบ
  • subject: ผู้ใช้ที่มีบทบาท admin
  • resource: ทรัพยากรที่มีชื่อ patient-record
  • action: delete
  • effect: allow
  • rationale: "อนุญาตการเข้าถึงการลบแฟ้มประวัติผู้ป่วยสำหรับผู้ดูแลระบบ"

สำหรับแต่ละคำขออ่าน/เขียน/ลบ เครื่องมือประเมินนโยบายจะประเมินนโยบายที่เกี่ยวข้องทั้งหมดตามคุณสมบัติและทำการตัดสินใจการควบคุมการเข้าถึง

การเปรียบเทียบ#

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

• ในโมเดล RBAC กระบวนการประเมินการควบคุมการเข้าถึงของทรัพยากรแฟ้มประวัติผู้ป่วยยังคงอยู่ง่ายและตรงไปตรงมา ไม่ว่าผู้ใช้จะมีสิทธิ์ read, write, หรือ delete;
• ในทางตรงข้าม ABAC จำเป็นต้องเกี่ยวข้องกับคุณสมัติเพิ่มเติมเช่น department-id และ doctor-id แล้วถ้ามีอุปกรณ์ IoT ที่ต้องการเข้าถึงแฟ้มประวัติผู้ป่วย? มันจะต้องการให้มีคุณสมัติใหม่ device-id นำเข้ามาในกระบวนการประเมินนโยบาย แล้วการมอบสิทธิ์ read ชั่วคราวให้กับหมอฝึกหัดล่ะ?

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

กรณีที่ 2#

ระบบโรงพยาบาลเดียวกัน ตอนนี้เพิ่มบทบาทใหม่ patient และคุณสมบัติใหม่ patient-id

นโยบายการควบคุมการเข้าถึงคือ:

1. หมอสามารถอ่านและเขียนแฟ้มประวัติผู้ป่วยได้
2. พยาบาลสามารถอ่านแฟ้มประวัติผู้ป่วยได้
3. ผู้ดูแลระบบสามารถอ่าน เขียน และลบแฟ้มประวัติผู้ป่วยได้
4. ผู้ป่วยสามารถอ่านแฟ้มประวัติของตนเองได้

โมเดล RBAC#

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

ตอนนี้การประเมินการควบคุมการเข้าถึงมีความซับซ้อนมากขึ้นเล็กน้อย โดยเฉพาะสำหรับการดำเนินการ read ของแฟ้มประวัติผู้ป่วย:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')
• GET /patient-records/:patient-id: user.permission.includes('read-own') && user.id === patient-id || user.permission.includes('read')

โมเดล ABAC#

ตอนนี้ปรับปรุงคุณสมบัติและนโยบายในโมเดล ABAC เพื่อตอบสนองความต้องการใหม่

คุณสมบัติ:

• user.role: doctor, nurse, admin, patient
• user.id: patient-id
• resource.name: patient-record
• resource.patient-id: patient-id
• action: read, write, delete

นโยบาย:

• นโยบาย 1: อนุญาตการเข้าถึงการอ่านทั้งหมดในแฟ้มประวัติผู้ป่วย
  • subject: ผู้ใช้ที่มีบทบาท doctor, nurse, admin
  • resource: ทรัพยากรที่มีชื่อ patient-record
  • action: read
  • effect: allow
  • rationale: "อนุญาตการเข้าถึงการอ่านในแฟ้มประวัติผู้ป่วยสำหรับบุคลากรทั้งหมดและผู้ป่วยเอง"
• นโยบาย 2: อนุญาตการเข้าถึงการเขียนทั้งหมดในแฟ้มประวัติผู้ป่วยสำหรับหมอและผู้ดูแลระบบ
  • subject: ผู้ใช้ที่มีบทบาท doctor, admin
  • resource: ทรัพยากรที่มีชื่อ patient-record
  • action: write
  • effect: allow
  • rationale: "อนุญาตการเข้าถึงการเขียนแฟ้มประวัติผู้ป่วยสำหรับหมอและผู้ดูแลระบบ"
• นโยบาย 3: อนุญาตการเข้าถึงการลบทั้งหมดในแฟ้มประวัติผู้ป่วยสำหรับผู้ดูแลระบบ
  • subject: ผู้ใช้ที่มีบทบาท admin
  • resource: ทรัพยากรที่มีชื่อ patient-record
  • action: delete
  • effect: allow
  • rationale: "อนุญาตการเข้าถึงการลบแฟ้มประวัติผู้ป่วยสำหรับผู้ดูแลระบบ"
• นโยบาย 4: อนุญาตการเข้าถึงการอ่านในแฟ้มประวัติของผู้ป่วยเอง
  • subject: ผู้ใช้ที่มีบทบาท patient
  • resource: ทรัพยากรที่มีชื่อ patient-record
  • action: read
  • condition: user.id === resource.patient-id
  • effect: allow
  • rationale: "อนุญาตการเข้าถึงการอ่านในแฟ้มประวัติของผู้ป่วยเอง"

การเปรียบเทียบ#

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

• ในโมเดล RBAC กระบวนการประเมินการควบคุมการเข้าถึงของทรัพยากรแฟ้มประวัติผู้ป่วยจะต้องมีการตรวจสอบสิทธิ์หลายระดับเพื่อดูว่าผู้ใช้มีการเข้าถึงทรัพยากรหรือไม่ ตัวอย่างเช่น เพื่อดูว่าผู้ป่วยมีการเข้าถึงแฟ้มประวัติของตนเองหรือไม่ ระบบต้องตรวจสอบว่าผู้ใช้มีสิทธิ์ read-own และ user id ตรงกับ patient id หรือไม่
• ในโมเดล ABAC กระบวนการประเมินการควบคุมการเข้าถึงสามารถเป็นไปอย่างตรงไปตรงมากว่า นโยบายสามารถถูกกำหนดตามคุณสมบัติของผู้ใช้ ทรัพยากร และการกระทำได้ ตัวอย่างเช่น เพื่อดูว่าผู้ป่วยมีการเข้าถึงแฟ้มประวัติของตนเองหรือไม่ เครื่องมือประเมินนโยบายสามารถประเมินนโยบายตาม user id และ patient id ได้

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

บทสรุป#

การเลือกใช้ระหว่าง RBAC และ ABAC ขึ้นอยู่กับความต้องการเฉพาะของระบบ RBAC เหมาะสมที่สุดสำหรับระบบที่มีโครงสร้างสิทธิ์ที่ชัดเจนและนโยบายการควบคุมการเข้าถึงที่คงที่ ในทางตรงกันข้าม ABAC เหมาะสมมากกว่าสำหรับระบบที่นโยบายการควบคุมการเข้าถึงต้องเป็นพลวัต มีบริบท และละเอียดอ่อน ในทางปฏิบัติองค์กรอาจเลือกใช้การผสมผสานของทั้งสองโมเดลเพื่อให้ได้นโยบายการควบคุมการเข้าถึงที่ต้องการ