เมื่ออ่านเกี่ยวกับ ACL และ RBAC ฉันดูเหมือนจะเข้าใจง่าย - มีชื่อผู้ใช้หรือบทบาทที่ได้รับสิทธิ์เข้าถึงเนื้อหา ฉันยังสามารถดูว่าฉันสามารถใช้สิ่งเหล่านี้ได้อย่างไร

เช่นภาพนี้ให้มุมมองที่ชัดเจนของ ACL และ RBAC สำหรับฉัน (ในขณะที่ฉันสามารถไปและออกแบบตารางฐานข้อมูลตามด้านบน): (รูปภาพมารยาทของpressbooks )

สิ่งที่ฉันกำลังดิ้นรนคือเอแบค ภาพต่าง ๆ ที่ฉันพบจนถึงตอนนี้มีลักษณะเป็นคลื่นหรือมีความซับซ้อนมากเกินไปหรือแนะนำให้ใช้บุคคลภายนอกซึ่งเป็นบุคคลที่สามที่ได้รับอนุญาต หรือให้ตัวอย่างคุณสมบัติแปลก ๆ ฉันไม่แน่ใจว่าจะใช้อย่างไร

ตัวอย่างการเริ่มต้น

ขอผมเริ่มด้วยบางสิ่งในชีวิตจริง สมมติว่าฉันมี บริษัท ที่มีพนักงาน 70-200 คน และสินทรัพย์ของฉันเพื่อป้องกันเป็นเว็บไซต์ที่มีหลายหน้า ฉันต้องการอนุญาตให้บางคนเข้าถึงเนื้อหาบางอย่าง

ตัวอย่างเช่นฉันต้องการให้บุคคลLeslieสามารถเข้าถึงหน้าเว็บที่เรียกว่าPrice Managerและอนุญาตให้เธอจัดการราคาสำหรับTravelกลุ่มราคาในหน้านั้นเท่านั้น แต่ไม่สามารถจัดการราคาสำหรับProductกลุ่มในหน้าเดียวกันได้ ฉันจะใช้สิ่งนี้โดยใช้ ABAC ได้อย่างไร

ฉันคิดว่าฉันสามารถกำหนดLeslieคุณลักษณะบางอย่างได้ (แต่มีคุณลักษณะใดบ้างและคุณสมบัติเหล่านี้มีอะไรบ้าง) จากนั้นให้ตารางฐานข้อมูลจัดเก็บข้อมูลเหล่านั้น ฉันสามารถออกแบบเอ็นจิ้นที่ดูที่คุณลักษณะเหล่านั้น (แต่ไม่ได้มองLeslieว่าเป็น "บทบาท" ที่ทำใน RBAC) และตัดสินใจจากที่นั่นว่าจะให้สิทธิ์การเข้าถึงเพจหรือไม่ เครื่องยนต์นั้นมีลักษณะอย่างไร มันง่ายหากบล็อก / อื่น? อื่น ๆ อีก?

จะเกิดอะไรขึ้นหากเลสลี่เปลี่ยนตำแหน่งของเธอในภายหลังและมีคนต้องการเปลี่ยนการเข้าถึงของเธอ สิ่งที่มันจะมีลักษณะเช่นถ้าเธอต้องการที่จะมีการเข้าถึงย้ายจากProductและเพิกถอนTravel? มันจะถูกเข้ารหัสได้อย่างไรหากเธอต้องการที่จะเพิกถอนการเข้าถึงไปยังPrice Managerหน้าทั้งหมดและด้วยเหตุนี้จึงไม่สามารถเข้าถึงได้อีกต่อไปTravelหรือProduct?

เนื้อหาในกรณีของฉันเพียงเพื่อปรับปรุงใหม่คือPrice Managerและผู้ใช้สามารถเข้าถึงกลุ่มราคาต่าง ๆ ในหน้านั้นเช่นการTravelกำหนดProductราคาการกำหนดราคาและอื่น ๆ

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

โบนัส: ABAC เป็นวิธีที่เหมาะสมสำหรับความต้องการการอนุญาตที่ค่อนข้างเล็กเช่นการจัดการ 70-200 คนและการเข้าถึงสินทรัพย์ 150 - 450 รายการหรือไม่ จะดีกว่าไหมถ้าติดกับ ACL / RBAC แทน?

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

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

แนวคิด

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

• เลสลี่เปิดหน้าเว็บผู้จัดการราคา
• Leslie สร้างราคาเดินทางโดยใช้หน้าผู้จัดการราคา

การรวบรวมคุณสมบัติ

สิ่งแรกที่เราต้องทำคือรวบรวมคุณสมบัติที่เกี่ยวข้องของแนวคิดที่กล่าวข้างต้น เป็นการดีที่คุณไม่ควรกำหนดคุณลักษณะเฉพาะใด ๆ เนื่องจาก XACML พยายามไม่สร้างความรำคาญและพึ่งพาเฉพาะสิ่งที่ระบบให้ ดังนั้นเราจึงมี:

เรื่อง

นักแสดงใด ๆ ไม่ว่าจะเป็นบุคคลหรือบริการในระบบของคุณ วิชาของเราคือเลสลี่ คุณลักษณะใดที่จำเป็นต่อการระบุตัวตนของ Leslie? น่าจะเป็นบางส่วนของต่อไปนี้: first name, last name, e-mail, ssn, ,company idposition(s)

หนังบู๊

การกระทำใด ๆ ของอาสาสมัคร สามารถดำเนินการ CRUD มาตรฐานหรือสิ่งที่ซับซ้อนมากขึ้น การกระทำของเราและopen/view createแอ็ตทริบิวต์สำหรับการกระทำเหล่านี้อาจแตกต่างกันไปตามกรอบแอปพลิเคชันเว็บที่คุณใช้ เราจะพูดคุยเกี่ยวกับเรื่องนี้เมื่อเราได้รับทรัพยากร

ทรัพยากร

สวยด้วยตนเองอธิบาย ทรัพยากรของเรามีprice manager page, และtravel prices the newly created priceอาจมีมากกว่านี้หากคุณต้องการจริงๆ คุณอาจต้องการซ่อนการกระทำที่ผู้ใช้ไม่สามารถทำได้ เช่น. the create price buttonสามารถเป็นทรัพยากรที่สามารถแสดง / ซ่อนโดยขึ้นอยู่กับว่าผู้ใช้มีสิทธิ์ในการสร้างราคาหรือไม่ เนื่องจากวิธีเดียวที่ผู้ใช้สามารถดูรายการราคาสามารถผ่านหน้านี้ได้อาจเป็นความคิดที่ดีที่จะบังคับใช้การอนุญาตในระดับนี้แทนที่จะลงไปในกองซ้อน

การเข้าถึงทรัพยากรเป็นสิ่งที่ซับซ้อนที่สุดในการดำเนินการโดยเฉพาะอย่างยิ่งสิ่งที่มาจากฐานข้อมูล ตัวเลือกที่ละเอียดยิ่งขึ้นคือความปลอดภัยระดับแถว ฐานข้อมูลบางตัวมีระดับการสนับสนุนที่แน่นอน ตัวสร้าง XACML บางตัวได้หายไปไกลพอ ๆ กับการสร้าง SQL superset สิ่งนี้ขึ้นอยู่กับความต้องการการอนุญาตของคุณ แต่สิ่งหนึ่งที่คุณไม่ต้องการทำคือการดึงทุกอย่างออกจากโต๊ะแล้วตัดสินใจว่าจะแสดงอะไร คุณสามารถจัดกลุ่มทรัพยากรโดยชุดการอนุญาตวางนามธรรมไว้ด้านหลัง API และบังคับใช้การอนุญาตที่จุดสิ้นสุด API

สิ่งแวดล้อม

ฉันไม่สามารถกำหนดได้อย่างถูกต้อง (XACML ยังไม่มีคำจำกัดความที่เหมาะสม) แต่สมมติว่าเป็น "ฟองสบู่" ที่เกิดขึ้นทั้งหมดนี้ นี้รวมถึง: web application, web server, operating system, ,browser officeคุณสามารถดึงคุณลักษณะที่ชอบ: ip address, time of day, user locale, ,user agent operating system versionคุณสามารถใช้สิ่งเหล่านี้เพื่อบล็อกการเข้าถึงของผู้ใช้จากสภาพแวดล้อมที่แอปพลิเคชันของคุณไม่รองรับ (เช่นเบราว์เซอร์เก่าระบบปฏิบัติการเก่าคอมพิวเตอร์นอกเครือข่ายของคุณเข้าถึงนอกเวลาทำการ)

คำขออนุญาต

เมื่อเรารวบรวมคุณลักษณะที่จำเป็นทั้งหมดแล้วเราจะรวบรวมพวกเขาไว้ในคำขอการให้สิทธิ์และส่งต่อไปยังเอนทิตีที่สามารถทำการตัดสินใจการอนุญาตตามค่าของคุณลักษณะเหล่านี้ ใน XACML lingua สถานที่ที่คุณรวบรวมคุณลักษณะเหล่านี้และบังคับใช้การตัดสินใจที่เกิดขึ้นในตอนนั้นเรียกว่าจุดบังคับใช้นโยบาย (PEP) และจุดตัดสินใจนั้นเรียกว่าจุดตัดสินใจนโยบาย (PDP) ตำแหน่งที่ตั้งที่ได้รับค่าแอตทริบิวต์เรียกว่านโยบายข้อมูลจุด (PIP) PEPs, PDP และ PIP สามารถเป็นส่วนหนึ่งของแอปพลิเคชันของคุณซึ่งอาจเป็นระบบภายนอก คุณสามารถหาไดอะแกรมว่าพวกเขาสื่อสารกันอย่างไรในมาตรฐาน XACML

กระบวนการตัดสินใจ

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

แอปพลิเคชันเว็บ (ชุดนโยบาย)
| - เป้าหมาย: application-name == "เว็บแอปพลิเคชัน"
`- เวอร์ชั่น 1.0 (ชุดนโยบาย)
    | - เป้าหมาย: application-version == "1.0"
    `- ดูผู้จัดการราคา (นโยบาย)
        | - เป้าหมาย: web-page-name == "ผู้จัดการราคา" && action-name == "ดู"
        `- เลสลี่สามารถดูผู้จัดการราคา (กฎ)
            | - เป้าหมาย: subject-name == "Leslie"
            `- การอนุญาต: อนุญาต

PDP จะจับคู่ทุกอย่างในชุดด้านบนกับค่าแอตทริบิวต์ในคำขอการให้สิทธิ์ จะเกิดอะไรขึ้นถ้าไม่มีกฎที่ตรงกับมันขึ้นอยู่กับการใช้งาน PDP ของคุณ เมื่อ PDP ได้ตัดสินใจ ( allow, denyหรือnot-applicable) ก็จะส่งกลับไปยัง PEP ที่ทำหน้าที่กับมันโดยให้หรือปฏิเสธการเข้าถึงทรัพยากร พร้อมกับการตอบสนอง PDP สามารถส่งรายการobligationsและadvicesPEP ต้องหรือควรปฏิบัติตามในกระบวนการบังคับใช้ ขึ้นอยู่กับวิธีการจัดเก็บกฎ (ไฟล์ข้อความหรือฐานข้อมูล) ผู้ดูแลระบบสามารถใช้โปรแกรมแก้ไขข้อความมาตรฐานหรือแอพพลิเคชั่นการแก้ไขที่กำหนดเองเพื่อเปลี่ยนสิ่งเหล่านี้ตามที่เขา / เธอเห็นว่าเหมาะสม การเพิกถอนสิทธิ์การเข้าถึงของ Leslie ต่อผู้จัดการราคาดำเนินต่อเพื่อเปลี่ยนการอนุญาตจากallowเป็นเป็นdenyอนุญาตให้ PEP ทำงานได้

การบังคับใช้

สิ่งนี้ขึ้นอยู่กับกองเทคโนโลยีของคุณเป็นอย่างมาก กรอบงานเว็บบางอันมีจุดบังคับใช้ตามธรรมชาติ (เช่น ASP.NET MVC มีตัวกรองแอตทริบิวต์) เลเยอร์ธุรกิจของคุณอาจต้องกำหนดจุดบังคับใช้ดังกล่าว ฉันพบว่าการบังคับใช้ที่จุดบริการหรือจุดบริการ UI (คิดว่า microservices) ง่ายขึ้น

ผลประโยชน์อื่น ๆ

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