ในด้านความปลอดภัยของระบบคอมพิวเตอร์การควบคุมการเข้าถึงตามบทบาท ( RBAC ) ^{[ 1 ] [ 2 ]}หรือความปลอดภัยตามบทบาท^{[ 3 ]}เป็นแนวทางในการจำกัดการเข้าถึงระบบให้กับผู้ใช้ที่ได้รับอนุญาต และเพื่อนำการควบคุมการเข้าถึงแบบบังคับ (MAC)หรือการควบคุมการเข้าถึงแบบดุลยพินิจ (DAC)มา ใช้

การควบคุมการเข้าถึงตามบทบาท (Role-based access control หรือ RBAC) เป็นกลไกการควบคุมการเข้าถึงที่ไม่ขึ้นกับนโยบาย ซึ่งกำหนดขึ้นโดยอิงจากบทบาทและสิทธิ์ ส่วนประกอบของ RBAC เช่น สิทธิ์ตามบทบาท ความสัมพันธ์ระหว่างผู้ใช้กับบทบาท และความสัมพันธ์ระหว่างบทบาทกับบทบาท ทำให้การกำหนดผู้ใช้เป็นเรื่องง่าย การศึกษาของ NIST แสดงให้เห็นว่า RBAC ตอบสนองความต้องการมากมายขององค์กรเชิงพาณิชย์และภาครัฐ^{[ 4 ]} RBAC สามารถใช้เพื่ออำนวยความสะดวกในการบริหารจัดการความปลอดภัยในองค์กรขนาดใหญ่ที่มีผู้ใช้หลายร้อยคนและสิทธิ์หลายพันรายการ แม้ว่า RBAC จะแตกต่างจากกรอบการควบคุมการเข้าถึง MAC และ DAC แต่ก็สามารถบังคับใช้นโยบายเหล่านี้ได้โดยไม่มีความซับซ้อนใดๆ

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

มีการกำหนดกฎหลัก 3 ข้อสำหรับ RBAC ดังนี้:

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

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

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

ในการกำหนดรูปแบบ RBAC นั้น ข้อกำหนดต่อไปนี้มีประโยชน์:

• S = Subject = บุคคลหรือตัวแทนอัตโนมัติ
• R = บทบาท = หน้าที่การงานหรือชื่อตำแหน่งที่กำหนดระดับอำนาจ
• P = สิทธิ์อนุญาต = การอนุมัติวิธีการเข้าถึงทรัพยากร
• SE = Session = การจับคู่ที่เกี่ยวข้องกับ S, R และ/หรือ P
• SA = การมอบหมายงานตามหัวข้อ
• PA = การมอบสิทธิ์อนุญาต
• RH = ลำดับชั้นบทบาทที่เรียงลำดับบางส่วน (Partially ordered Role Hierarchy) RH สามารถเขียนได้อีกแบบว่า ≥ (สัญลักษณ์: x ≥ y หมายความว่า x ได้รับสิทธิ์จาก y)
  • บุคคลหนึ่งสามารถมีบทบาทได้หลายอย่าง
  • บทบาทหนึ่งอาจมีหลายวิชาได้
  • บทบาทหนึ่งสามารถมีสิทธิ์อนุญาตได้หลายอย่าง
  • สามารถกำหนดสิทธิ์ให้กับหลายบทบาทได้
  • การดำเนินการหนึ่งๆ สามารถกำหนดสิทธิ์ให้กับการดำเนินการหลายๆ อย่างได้
  • สามารถกำหนดสิทธิ์ให้กับการดำเนินการหลายอย่างได้

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

ดังนั้น เมื่อใช้สัญลักษณ์ในทฤษฎีเซต :

• ${\displaystyle PA\subseteq P\times R}$และเป็นความสัมพันธ์แบบอนุญาตหลายต่อหลายในการมอบหมายบทบาท
• ${\displaystyle SA\subseteq S\times R}$และเป็นความสัมพันธ์แบบหลายต่อหลายต่อการกำหนดบทบาท
• ${\displaystyle RH\subseteq R\times R}$

ผู้เข้าร่วมการวิจัยอาจมีหลายช่วงเวลาพร้อมกันในบทบาทที่แตกต่างกัน

มาตรฐาน NIST/ANSI/ INCITS RBAC (2004) รับรอง RBAC สามระดับ: ^{[ 5 ]}

1. RBAC หลัก
2. การควบคุมการเข้าถึงตามบทบาทแบบลำดับชั้น (Hierarchical RBAC) ซึ่งเพิ่มการสนับสนุนการสืบทอดระหว่างบทบาทต่างๆ
3. RBAC ที่มีข้อจำกัด ซึ่งเพิ่มการแบ่งแยกหน้าที่

RBAC เป็นเทคโนโลยีควบคุมการเข้าถึงที่ยืดหยุ่น ซึ่งความยืดหยุ่นนี้ทำให้สามารถใช้งานDAC ^{[ 6 ]}หรือMACได้^{[ 7 ]} DAC ที่มีกลุ่ม (เช่น ที่ใช้งานในระบบไฟล์ POSIX) สามารถจำลอง RBAC ได้^{[ 8 ]} MAC สามารถจำลอง RBAC ได้หากกราฟบทบาทถูกจำกัดไว้ที่ต้นไม้แทนที่จะเป็นชุดที่มีลำดับบางส่วน^{[ 9 ]}

ก่อนการพัฒนา RBAC โมเดล Bell-LaPadula (BLP) ถือเป็นโมเดลเดียวกับ MAC และสิทธิ์การเข้าถึงไฟล์ถือเป็นโมเดลเดียวกับ DAC สิ่งเหล่านี้ถือเป็นโมเดลเดียวที่เป็นที่รู้จักสำหรับการควบคุมการเข้าถึง: หากโมเดลใดไม่ใช่ BLP ก็จะถือว่าเป็นโมเดล DAC และในทางกลับกัน งานวิจัยในช่วงปลายทศวรรษ 1990 แสดงให้เห็นว่า RBAC ไม่จัดอยู่ในหมวดหมู่ใดหมวดหมู่หนึ่ง^{[ 10 ] [ 11 ]}แตกต่างจากการควบคุมการเข้าถึงตามบริบท (CBAC) RBAC ไม่ได้พิจารณาบริบทของข้อความ (เช่น แหล่งที่มาของการเชื่อมต่อ) นอกจากนี้ RBAC ยังถูกวิพากษ์วิจารณ์ว่านำไปสู่การระเบิดของบทบาท^{[ 12 ]}ซึ่งเป็นปัญหาในระบบองค์กรขนาดใหญ่ที่ต้องการการควบคุมการเข้าถึงที่มีความละเอียดสูงกว่าที่ RBAC สามารถให้ได้ เนื่องจากบทบาทต่างๆ ถูกกำหนดให้กับการดำเนินการและประเภทข้อมูลโดยธรรมชาติ เช่นเดียวกับ CBAC ระบบควบคุมการเข้าถึงตามความสัมพันธ์ของเอนทิตีสามารถรักษาความปลอดภัยของอินสแตนซ์ของข้อมูลโดยพิจารณาความสัมพันธ์กับผู้ดำเนินการ^{[ 13 ]}

รายการควบคุมการเข้าถึง (ACL) ถูกใช้ในระบบควบคุมการเข้าถึงแบบเลือกได้ (DAC) แบบดั้งเดิม เพื่อควบคุมข้อมูลระดับต่ำ RBAC แตกต่างจาก ACL ตรงที่ ACL กำหนดสิทธิ์ให้กับการดำเนินการที่เปลี่ยนแปลงความสัมพันธ์โดยตรงระหว่างหลายเอนทิตี (ดู: ACLgด้านล่าง) ตัวอย่างเช่น ACL อาจใช้สำหรับให้หรือปฏิเสธสิทธิ์ในการเขียนไฟล์ระบบเฉพาะ แต่จะไม่กำหนดวิธีการเปลี่ยนแปลงไฟล์นั้น ในระบบที่ใช้ RBAC การดำเนินการอาจเป็นการสร้างบัญชีเครดิตในแอปพลิเคชันทางการเงิน หรือการกรอกข้อมูลในบันทึกการทดสอบระดับน้ำตาลในเลือดในแอปพลิเคชันทางการแพทย์ ดังนั้น บทบาทจึงเป็นลำดับของการดำเนินการภายในกิจกรรมที่ใหญ่กว่า RBAC ได้รับการพิสูจน์แล้วว่าเหมาะสมอย่างยิ่งกับข้อกำหนดการแยกหน้าที่ (SoD) ซึ่งรับประกันว่าต้องมีบุคคลสองคนขึ้นไปเกี่ยวข้องกับการอนุมัติการดำเนินการที่สำคัญ เงื่อนไขที่จำเป็นและเพียงพอสำหรับความปลอดภัยของ SoD ใน RBAC ได้รับการวิเคราะห์แล้ว หลักการพื้นฐานของ SoD คือไม่มีบุคคลใดควรสามารถละเมิดความปลอดภัยได้ผ่านสิทธิ์สองทาง โดยขยายความแล้ว บุคคลใด ๆ ไม่อาจดำรงตำแหน่งที่ใช้อำนาจในการตรวจสอบ ควบคุม หรือทบทวนเหนือตำแหน่งอื่นที่ดำรงอยู่พร้อมกันได้^{[ 14 ] [ 15 ]}

นอกจากนี้ “โมเดล RBAC ขั้นต่ำ” RBACmสามารถเปรียบเทียบกับกลไก ACL, ACLgได้ โดยที่กลุ่มเท่านั้นที่ได้รับอนุญาตให้เป็นรายการใน ACL Barkley (1997) ^{[ 16 ]}แสดงให้เห็นว่าRBACmและACLgเทียบเท่ากัน

เพื่อการแลกเปลี่ยนข้อมูล และเพื่อ "การเปรียบเทียบในระดับสูง" ข้อมูล ACL สามารถแปลงเป็นXACMLได้

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

• ข้อมูลผู้ใช้ เช่น สัญชาติ การอนุมัติ
• ทรัพยากร เช่น การจำแนกประเภท แผนก เจ้าของ
• การกระทำ และ
• บริบท เช่น เวลา สถานที่ ที่อยู่ IP

ABAC เป็นระบบที่ใช้หลักการกำหนดนโยบาย กล่าวคือ ใช้หลักการกำหนดนโยบายแทนการกำหนดสิทธิ์แบบตายตัว เพื่อกำหนดว่าอะไรได้รับอนุญาตหรืออะไรไม่ได้รับอนุญาต

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

ข้อดีของโมเดลนี้คือช่วยให้สามารถกำหนดสิทธิ์ได้อย่างละเอียด ตัวอย่างเช่น ในเครือข่ายสังคมที่ผู้ใช้สามารถแชร์โพสต์กับผู้ใช้เฉพาะกลุ่มได้^{[ 17 ]}

การใช้ RBAC เพื่อจัดการสิทธิ์ของผู้ใช้ (สิทธิ์การใช้งานคอมพิวเตอร์) ภายในระบบหรือแอปพลิเคชันเดียวได้รับการยอมรับอย่างกว้างขวางว่าเป็นแนวปฏิบัติที่ดีที่สุดรายงานปี 2010 ที่จัดทำขึ้นสำหรับNISTโดยResearch Triangle Instituteได้วิเคราะห์มูลค่าทางเศรษฐกิจของ RBAC สำหรับองค์กร และประมาณการผลประโยชน์ต่อพนักงานจากการลดเวลาหยุดทำงานของพนักงาน การจัดสรรทรัพยากรที่มีประสิทธิภาพมากขึ้น และการบริหารนโยบายการควบคุมการเข้าถึงที่มีประสิทธิภาพมากขึ้น^{[ 18 ]}

ในองค์กรที่มีโครงสร้างพื้นฐานด้านไอที ที่หลากหลาย และความต้องการที่ครอบคลุมระบบและแอปพลิเคชันหลายสิบหรือหลายร้อยรายการ การใช้ RBAC เพื่อจัดการบทบาทที่เพียงพอและกำหนดสมาชิกภาพบทบาทที่เหมาะสมจะกลายเป็นเรื่องซับซ้อนอย่างยิ่งหากไม่มีการสร้างบทบาทและการกำหนดสิทธิ์ตามลำดับชั้น^{[ 19 ]}ระบบรุ่นใหม่ขยายโมเดล RBAC ของ NIST รุ่นเก่า^{[ 20 ]}เพื่อแก้ไขข้อจำกัดของ RBAC สำหรับการใช้งานทั่วทั้งองค์กร โมเดล NIST ได้รับการยอมรับเป็นมาตรฐานโดยINCITSในชื่อ ANSI/INCITS 359-2004 นอกจากนี้ยังมีการเผยแพร่การอภิปรายเกี่ยวกับทางเลือกการออกแบบบางประการสำหรับโมเดล NIST ด้วย^{[ 21 ]}

การรบกวนการควบคุมการเข้าถึงตามบทบาทเป็นปัญหาที่ค่อนข้างใหม่ในแอปพลิเคชันด้านความปลอดภัย ซึ่งบัญชีผู้ใช้หลายบัญชีที่มีระดับการเข้าถึงแบบไดนามิกอาจนำไปสู่ความไม่เสถียรของคีย์การเข้ารหัส ทำให้ผู้ใช้ภายนอกสามารถใช้ประโยชน์จากจุดอ่อนเพื่อเข้าถึงโดยไม่ได้รับอนุญาต แอปพลิเคชันการแบ่งปันคีย์ภายในสภาพแวดล้อมเสมือนแบบไดนามิกได้แสดงให้เห็นถึงความสำเร็จในการแก้ไขปัญหานี้^{[ 22 ]}

การควบคุมการเข้าถึงตามบทบาทนั้นถูกกล่าวถึงหรือตีความโดยนัยในกรอบกฎระเบียบหลายฉบับที่กำหนดให้องค์กรต้องจำกัดการเข้าถึงข้อมูลที่ละเอียดอ่อนตามหน้าที่การงาน

กฎ ความปลอดภัย ของพระราชบัญญัติการพกพาและการรับผิดชอบด้านการประกันสุขภาพ (HIPAA) กำหนดให้หน่วยงานที่อยู่ภายใต้การคุ้มครองต้องนำนโยบายและขั้นตอนทางเทคนิคมาใช้เพื่อให้บุคคลหรือโปรแกรมซอฟต์แวร์ที่ได้รับสิทธิ์ในการเข้าถึงข้อมูลสุขภาพที่ได้รับการคุ้มครองทางอิเล็กทรอนิกส์ เท่านั้น (45 CFR 164.312(a)(1)) ^{[ 23 ]}มาตรฐานขั้นต่ำที่จำเป็นของ HIPAA ยังกำหนดให้การเข้าถึงต้องจำกัดเฉพาะข้อมูลสุขภาพที่ได้รับการคุ้มครอง ขั้นต่ำ ที่จำเป็นเพื่อให้บรรลุวัตถุประสงค์ที่ตั้งใจไว้ ซึ่งเป็นหลักการที่สอดคล้องโดยตรงกับการควบคุมการเข้าถึงตามบทบาท^{[ 24 ]}ประกาศร่างกฎระเบียบ (NPRM) เดือนธันวาคม 2024 เพื่อปรับปรุงกฎความปลอดภัยของ HIPAA จะกำหนดให้หน่วยงานที่อยู่ภายใต้การกำกับดูแลต้องนำการเข้าถึง ePHI ตามบทบาทมาใช้ กำหนดให้แจ้งสมาชิกในทีมงานที่เกี่ยวข้องภายใน 24 ชั่วโมงเมื่อมีการเปลี่ยนแปลงสิทธิ์การเข้าถึง และยกเลิกการจำแนกการควบคุมการเข้าถึงว่าเป็นเพียงข้อกำหนดที่ "สามารถระบุที่อยู่ได้" ^{[ 25 ]}

มาตรฐานความปลอดภัยข้อมูลอุตสาหกรรมบัตรชำระเงิน (PCI DSS) กำหนดให้การเข้าถึงส่วนประกอบของระบบและข้อมูลผู้ถือบัตรต้องจำกัดเฉพาะบุคคลที่งานของพวกเขาต้องเข้าถึงข้อมูลดังกล่าว และต้องกำหนดสิทธิ์การเข้าถึงตามการจำแนกประเภทงานและหน้าที่ (ข้อกำหนดที่ 7) ^{[ 26 ]}

• David F. Ferraiolo; D. Richard Kuhn; Ramaswamy Chandramouli (2007). การควบคุมการเข้าถึงตามบทบาท (ฉบับที่ 2). Artech House. ISBN 978-1-59693-113-8.

• คำถามที่พบบ่อยเกี่ยวกับรุ่นและมาตรฐาน RBAC
• การควบคุมการเข้าถึงตามบทบาทที่ NIST
• โปรไฟล์การควบคุมการเข้าถึงตามบทบาทหลักและลำดับชั้นของ XACML