วิธีการออกแบบการควบคุมการเข้าถึงตามบทบาท?


15

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

จนถึงตอนนี้ฉันมีหน่วยงานดังต่อไปนี้:

users - ผู้ที่จะใช้ระบบ ที่นี่ฉันมีชื่อผู้ใช้และรหัสผ่าน role - การรวบรวมบทบาทที่ผู้ใช้สามารถมีได้ ทรัพยากรต่างๆ เช่นผู้จัดการผู้ดูแลระบบ ฯลฯ - สิ่งที่ผู้ใช้สามารถจัดการได้ เช่นเดียวกับสัญญาผู้ใช้ร่างสัญญา ฯลฯ การดำเนินการ - สิ่งที่ผู้ใช้สามารถทำกับทรัพยากร ชอบสร้างอ่านอัปเดตหรือลบ

ตอนนี้ความสงสัยของฉันเพิ่มขึ้นที่นี่ในแผนภาพที่ฉันมีความสัมพันธ์เช่นนี้:

การดำเนินงาน (0 .. *) จะดำเนินการเมื่อ ทรัพยากร (0 .. *) ซึ่งจะสร้างตารางที่ผมเรียกว่าสิทธิ์และที่จะจัดเก็บการดำเนินงานและทรัพยากร

ตารางสิทธิ์จะมีลักษณะเช่นนี้ (หนึ่งแถว): ID: 1, การดำเนินการ:สร้าง, ทรัพยากร:สัญญา

ซึ่งหมายถึงการได้รับอนุญาตในการสร้างสัญญา

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

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

ฉันคิดว่าแต่ละแหล่งข้อมูลมีการรวบรวมการดำเนินงานของตนเองที่สามารถดำเนินการกับเขาได้

ฉันสามารถชี้แจงได้หากบางสิ่งไม่เข้าใจ

นี่เป็นวิธีที่ถูกต้องในการติดตั้ง rbac หรือไม่?

แก้ไข

สิ่งที่ฉันหมายความว่าโดยมีสิทธิ์ตารางซึ่งมีการดำเนินงานและทรัพยากรที่ฉันมีสองตารางพิเศษเพราะผมต้องการที่จะเชื่อมโยงทรัพยากรที่มีการดำเนินงาน ฉันสามารถทำทรัพยากรได้เพียงแค่มีสิทธิ์ที่ตารางสิทธิ์จะเก็บสิทธิ์

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

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


2
คุณหมายถึงอะไร "ถูกต้อง" หมายเหตุ: อย่าตอบคำถามซ้ำซากเช่น "แนวปฏิบัติที่ดีที่สุด" ระบุข้อกำหนดเฉพาะของคุณ
Robert Harvey

1
คำจำกัดความของฉันของ "ปกติ" มักเป็น "สิ่งที่ตรงตามข้อกำหนดด้านการใช้งานและไม่ใช้งานของซอฟต์แวร์ของคุณ" โปรดทราบว่า NIST นำเสนอแนวทางโดยละเอียดและแนวทางปฏิบัติที่ดีที่สุดสำหรับการรักษาความปลอดภัยตามบทบาท ดูcsrc.nist.gov/groups/SNS/rbac
Robert Harvey

คุณอาจสนใจที่จะดูว่ามันจะทำอย่างไรในโครงการบัณฑิต
Antarr Byrd

1
คุณควรพิจารณาใช้ห้องสมุดสำหรับสิ่งนี้
RibaldEddie

มีห้องสมุดมากมายที่จะทำ RBAC หรือ ABAC ให้คุณ
David Brossard

คำตอบ:


11

งานออกแบบของคุณใกล้กับฉันมาก เพียงคำแนะนำสองสาม

ผู้ใช้ - ผู้ที่จะใช้ระบบ ที่นี่ฉันมีชื่อผู้ใช้และรหัสผ่าน

ละเอียด

role - การรวบรวมบทบาทที่ผู้ใช้สามารถมีได้ สิ่งต่างๆเช่นผู้จัดการผู้ดูแลระบบ ฯลฯ

ดีเกินไป. แต่คุณจะต้องมีเอนทิตี "UserRoles" / ตารางที่จะบอกคุณว่าผู้ใช้คนใดมีบทบาทใด มีแนวโน้มว่าผู้ใช้ที่กำหนดอาจมีบทบาทอย่างน้อยสองบทบาท

ทรัพยากร - สิ่งที่ผู้ใช้สามารถจัดการได้ เช่นเดียวกับสัญญาผู้ใช้ร่างสัญญาเป็นต้น

อาจเป็นเพียงคำถามของความหมาย ฉันไม่คิดว่าผู้ใช้จัดการทรัพยากรโดยตรง บทบาททำ ดังนั้นมันจะไปผู้ใช้ -> บทบาทของผู้ใช้ -> บทบาท -> การดำเนินงาน -> ทรัพยากร

การดำเนินงาน - สิ่งที่ผู้ใช้สามารถทำกับทรัพยากร ชอบสร้างอ่านอัปเดตหรือลบ

ใช่ยกเว้น "บทบาท" แทนที่จะเป็น "ผู้ใช้"

ตารางสิทธิ์จะมีลักษณะเช่นนี้ (หนึ่งแถว): ID: 1, การดำเนินการ: สร้าง, ทรัพยากร: สัญญา ซึ่งหมายถึงการอนุญาตให้สร้างสัญญา

อืมม มีสองวิธีที่จะไปกับสิ่งนี้ คุณอาจมีตารางสิทธิ์ที่คุณอธิบาย แต่คุณจะต้องมีRolePermissionsตาราง / เอนทิตีเพิ่มเติมที่บอกคุณว่าบทบาทใดมีสิทธิ์ใด แต่ฉันไม่แน่ใจว่าจำเป็น

วิธีที่ง่ายกว่าคือตาราง / เอนทิตีสิทธิ์ที่มีคอลัมน์ / แอ็ตทริบิวต์เหล่านี้: ID บทบาท, ID การดำเนินการ, ResourceID ด้วยวิธีนี้การรวมทรัพยากร Operations x ได้รับการกำหนดให้กับบทบาทโดยตรงแทนที่จะโหลดลงในสิทธิ์ที่กำหนดให้กับบทบาท มันกำจัดหนึ่งเอนทิตี ไม่จำเป็นต้องมีตารางการอนุญาตแบบไม่เชื่อเรื่องพระเจ้าซึ่งแยกจากกันเว้นแต่ว่าคุณต้องการกำหนดสิ่งที่อนุญาตให้รวมกันได้และสิ่งที่ไม่ใช่


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

13

ฉันจะไม่ใช้หรือใช้ RBAC ฉันจะใช้ ABAC แทน ให้ฉันอธิบาย ...

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

ในคำถามของคุณคุณกำหนดรูปแบบข้อมูลเป็นหลัก วัตถุและคุณสมบัติของพวกเขาเช่นผู้ใช้ (ชื่อรหัสผ่านแผนก ... ); วัตถุ (เช่นสัญญา) และอื่น ๆ

แบบจำลองสารสนเทศ

ใน ABAC คุณจะต้องแยกรหัสแอป / ตรรกะทั้งหมดออกจากตรรกะการให้สิทธิ์ที่เก็บไว้เป็นนโยบายโดยใช้แอตทริบิวต์ สิทธิ์จะถูกเก็บไว้ในนโยบาย (ดูตัวอย่างด้านบน) สถาปัตยกรรมการปรับใช้ ABAC มีลักษณะดังต่อไปนี้

สถาปัตยกรรมการควบคุมการเข้าถึงตามคุณสมบัติ

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


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

ไม่นั่นหมายความว่าคุณจะมีบางสิ่ง (LDAP? A table?) ที่เชื่อมโยงผู้ใช้ (Alice) กับบทบาทของเธอ (ผู้จัดการ ... ) จากนั้นคุณจะมีตารางที่จะมีข้อมูลเมตาของเอกสาร (ซึ่งโดยปกติจะเป็นตารางภายในแอปที่คุณกำลังปกป้อง) การอนุญาตเอง (ดูแก้ไขลบ) จะถูกเก็บไว้ในนโยบาย
David Brossard
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.