भूमिका आधारित अभिगम नियंत्रण कैसे डिजाइन करें?


15

मैं अपने सिस्टम में उपयोगकर्ता क्या कर सकता हूं या क्या नहीं कर सकता हूं, इसे प्रतिबंधित करने के लिए रोल बेस एक्सेस कंट्रोल मॉडल का पालन करने की कोशिश कर रहा हूं।

अब तक मेरे पास निम्नलिखित इकाइयाँ हैं:

उपयोगकर्ता - जो लोग सिस्टम का उपयोग करेंगे। यहां मेरे पास उपयोगकर्ता नाम और पासवर्ड हैं। भूमिकाएँ - उन भूमिकाओं का संग्रह जो उपयोगकर्ता कर सकते हैं। प्रबंधक, व्यवस्थापक, आदि संसाधनों की तरह - चीजें जो उपयोगकर्ता हेरफेर कर सकते हैं। जैसे कॉन्ट्रैक्ट, उपयोगकर्ता, कॉन्ट्रैक्ट ड्राफ्ट, आदि ऑपरेशंस - वे चीजें जो उपयोगकर्ता संसाधनों के साथ कर सकते हैं। जैसे क्रिएट, रीड, अपडेट या डिलीट।

अब, मेरा संदेह यहाँ आरेख में उभरता है जहाँ मेरा इस तरह से संबंध है:

संचालन (0 .. *) संसाधनों पर निष्पादित किए जाते हैं (0 .. *) जो एक तालिका उत्पन्न करता है जिसे मैं अनुमति देता हूं और जो ऑपरेशन और संसाधन को संग्रहीत करेगा ।

अनुमतियाँ तालिका इस तरह दिखाई देगी (इसकी एक पंक्ति): ID: 1, संचालन: निर्माण, संसाधन: अनुबंध।

जो एक का मतलब है की अनुमति के लिए बनाने के लिए एक अनुबंध

मैंने इसे इस तरह से किया है क्योंकि मुझे लगता है कि कुछ संसाधनों में सभी प्रकार के ऑपरेशन नहीं हो सकते हैं। उदाहरण के लिए, अनुबंध दर्ज करने के लिए , उपयोगकर्ता फाइलें अपलोड कर सकते हैं , लेकिन प्रदाता के पंजीकरण के लिए यह ऑपरेशन उपलब्ध नहीं है ।

तो अब जब व्यवस्थापक दे दिया जाएगा अनुमतियाँ एक करने के लिए भूमिका है, वह हर एक प्रणाली में पंजीकृत संचालन के साथ संसाधनों की सूची नहीं होगा।

मुझे लगता है कि प्रत्येक संसाधन के संचालन का अपना संग्रह है जिसे उस पर निष्पादित किया जा सकता है।

अगर कुछ समझ में नहीं आ रहा है तो मैं स्पष्ट कर सकता हूं।

क्या यह rbac को लागू करने का सही तरीका है?

संपादित करें

मेरा मतलब है कि एक अनुमति तालिका है जिसमें ऑपरेशन और संसाधन हैं , मेरे पास दो अतिरिक्त टेबल हैं क्योंकि मैं संसाधनों को संचालन के साथ जोड़ना चाहता हूं । मैं भी कर सकता था बस संसाधनों की अनुमति है जहां अनुमति तालिका अनुमतियों को संग्रहीत करेगी।

लेकिन फिर क्या हुआ होगा कि कुछ अनुमतियाँ जो कुछ संसाधनों के लिए भी मौजूद नहीं हैं, तब प्रकट होगी जब व्यवस्थापक उन्हें असाइन करेगा।

इसलिए मैं एक डेटाबेस डिजाइन बिंदु से जानना चाहता हूं कि क्या यह तालिका अनुमति जिसमें एक कॉलम ऑपरेशन है और दूसरा संसाधन सही है? अगर मैं इस तरह रहता हूं तो क्या मैं समस्याओं में चला जाऊंगा?


2
"सही" से आपका क्या तात्पर्य है? नोट: "सर्वश्रेष्ठ अभ्यास" जैसी एक तनातनी के साथ उत्तर न दें। अपनी विशिष्ट आवश्यकताओं को बताएं।
रॉबर्ट हार्वे

1
"सही" की मेरी परिभाषा आमतौर पर "वह है जो सबसे प्रभावी रूप से आपके सॉफ़्टवेयर की कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं को पूरा करती है।" ध्यान दें कि NIST भूमिका-आधारित सुरक्षा के लिए विस्तृत दिशानिर्देश और सर्वोत्तम अभ्यास प्रदान करता है। देखें csrc.nist.gov/groups/SNS/rbac
रॉबर्ट हार्वे

आपको यह देखने में रुचि हो सकती है कि यह पंडित परियोजना में कैसे किया गया है ।
एंटीअर बर्ड

1
आपको इसके लिए पुस्तकालय का उपयोग करने पर विचार करना चाहिए।
रिबेल्डैडी

वहाँ बहुत सारे पुस्तकालय हैं जो आपके लिए आरबीएसी या एबीएसी करेंगे
डेविड ब्रॉसार्ड

जवाबों:


11

आपका डिज़ाइन मुझे बहुत करीब लगता है। बस एक दो सुझाव।

उपयोगकर्ता - जो लोग सिस्टम का उपयोग करेंगे। यहां मेरे पास उपयोगकर्ता नाम और पासवर्ड हैं।

ठीक

भूमिकाएँ - उन भूमिकाओं का संग्रह जो उपयोगकर्ता कर सकते हैं। प्रबंधक, व्यवस्थापक इत्यादि जैसे सामान।

ठीक हूँ। लेकिन आपको एक "UserRoles" इकाई / तालिका की भी आवश्यकता होगी जो आपको बताएगी कि कौन सी उपयोगकर्ता की भूमिकाएँ हैं। यह संभावना है कि किसी दिए गए उपयोगकर्ता की दो या दो से अधिक भूमिकाएँ हो सकती हैं।

संसाधन - ऐसी चीजें जो उपयोगकर्ता हेरफेर कर सकते हैं। जैसे अनुबंध, उपयोगकर्ता, अनुबंध ड्राफ्ट आदि।

सिर्फ शब्दार्थ का सवाल हो सकता है। मुझे नहीं लगता कि उपयोगकर्ता सीधे संसाधनों में हेरफेर करते हैं; भूमिकाएँ करते हैं। इस प्रकार यह उपयोगकर्ता -> उपयोगकर्ता भूमिका -> भूमिका -> संचालन -> संसाधन चला जाता है

संचालन - चीजें जो उपयोगकर्ता संसाधनों के साथ कर सकते हैं। जैसे क्रिएट, रीड, अपडेट या डिलीट।

हां, "उपयोगकर्ता" के बजाय "भूमिका" को छोड़कर

अनुमतियाँ तालिका इस तरह दिखाई देगी (इसकी एक पंक्ति): ID: 1, संचालन: निर्माण, संसाधन: अनुबंध। जिसका अर्थ है एक अनुबंध बनाने की अनुमति।

हममम। इसके साथ जाने के दो तरीके हैं। आपके पास वर्णित अनुमतियाँ तालिका हो सकती हैं, लेकिन आपको एक अतिरिक्त RolePermissionsतालिका / इकाई की भी आवश्यकता होगी जो आपको बताए कि किस भूमिका की अनुमति है। लेकिन मुझे यकीन नहीं है कि यह आवश्यक है।

इसे करने का एक सरल तरीका इन कॉलम / विशेषताओं के साथ एक अनुमति तालिका / इकाई है: रोल आईडी, ऑपरेशन आईडी, रिसोर्सआईडी। इस तरह, संचालन x संसाधन संयोजन को एक भूमिका के लिए सीधे असाइन किया जाता है, बजाय एक भूमिका में सौंपे अनुमति के रूप में। यह एक इकाई को समाप्त करता है। वास्तव में एक अलग भूमिका-अज्ञेय अनुमति तालिका की आवश्यकता नहीं है, जब तक कि आप पूर्वनिर्धारित करने की इच्छा नहीं रखते हैं कि कौन से अनुमतियों के संयोजन की अनुमति है और कौन से नहीं हैं।


सबसे पहले, मैं "उपयोगकर्ता" सुधार के बजाय "भूमिका" से पूरी तरह सहमत हूं। यही मेरा भी मतलब था। अब, बात यह है कि मैं संसाधनों को संचालन के साथ जोड़ना चाहता हूं। उदाहरण के लिए: एक अनुबंध संसाधन में upload_file जैसा एक ऑपरेशन है। इसलिए जो मैं नहीं चाहता, वह है कि अपलोड_फाइल ऑपरेशन दूसरे संसाधन में भी दिखाई देता है, जिसमें प्रदाताओं (एक अन्य संसाधन) की तरह अपलोड_फाइल ऑपरेशन नहीं होता है जब व्यवस्थापक एक भूमिका के लिए अनुमति दे रहा होता है।
imran.razak

13

मैं RBAC का उपयोग या कार्यान्वयन नहीं करता। इसके बजाय मैं एबीएसी का उपयोग करूंगा। मुझे समझाने दो...

  • RBAC या भूमिका-आधारित अभिगम नियंत्रण उपयोगकर्ता प्रबंधन और भूमिका असाइनमेंट के बारे में है। RBAC में, आप कहते हैं कि ऐलिस एक प्रबंधक है। आप उस के साथ-साथ स्थैतिक अनुमतियों को परिभाषित कर सकते हैं। उदाहरण के लिए, एक प्रबंधक ऋण को मंजूरी दे सकता है। तो एक अनुमति के रूप में एलिस से प्रबंधक तक एक कड़ी है। बहुत सारे सिस्टम हैं जो आपको ऐसा करने देंगे ताकि आपको अपनी खुद की टेबल को लागू करने की आवश्यकता न पड़े। यहां तक ​​कि एलडीएपी के पास आरबीएसी के सीमित सेट का समर्थन है। यह ठीक है जब तक आपके पास भूमिकाओं और अनुमतियों का एक छोटा सा सेट है। लेकिन क्या होगा यदि आप विशिष्ट अनुमतियों को ध्यान में रखना चाहते हैं जैसा कि आपका मामला है? देखें, हटाएं, डालें? यदि आप रिश्तों को ध्यान में रखना चाहते हैं तो क्या होगा?
  • ABAC या विशेषता-आधारित अभिगम नियंत्रण नीति-चालित, बारीक-बारीक प्राधिकरण के बारे में है। ABAC के साथ आप RBAC में परिभाषित भूमिकाओं का उपयोग कर सकते हैं और उदाहरण के लिए नीतियां लिख सकते हैं
    • प्रबंधक अपने विभाग में दस्तावेज़ देख सकते हैं
    • कर्मचारी अपने स्वयं के दस्तावेजों को संपादित कर सकते हैं

आपके प्रश्न में, आपने सूचना मॉडल को अनिवार्य रूप से परिभाषित किया है। आपकी वस्तुओं और उनकी विशेषताओं जैसे एक उपयोगकर्ता (नाम, पासवर्ड, विभाग ...); एक वस्तु (जैसे एक अनुबंध) और इसी तरह।

सूचना मॉडल

ABAC में, आप इसीलिए पूरी तरह से प्राधिकरण तर्क से अपने ऐप कोड / तर्क को पूरी तरह से अलग कर देंगे, जिसे तब विशेषताओं का उपयोग करके नीतियों के रूप में संग्रहीत किया जाता है। अनुमतियाँ स्वयं नीति में संग्रहीत हैं (ऊपर उदाहरण देखें)। ABAC परिनियोजन आर्किटेक्चर निम्नलिखित की तरह दिखता है

आधारित अभिगम नियंत्रण वास्तुकला

मुद्दा यह है कि यदि आप एक ABAC दृष्टिकोण लेते हैं, तो आप ABAC के लिए नीतियां लिखते हैं (या तो XACML या ALFA में - इसके लिए बहुत सारे उपकरण हैं) और आपको कभी भी कस्टम-कोड या कस्टम-कार्यान्वयन RBAC या फिर एक्सेस कंट्रोल नहीं करना है।


1
आपकी नीतियों के उदाहरण में, यह कहता है कि प्रबंधक अपने विभाग में दस्तावेज़ देख सकते हैं। क्या इसका मतलब है कि सिस्टम में पहले से ही पूर्वनिर्धारित अनुमतियां, भूमिकाएं और संसाधन प्रकार होंगे?
imran.razak

नहीं। इसका मतलब है कि आपके पास कुछ होगा (LDAP? एक तालिका?) जो एक उपयोगकर्ता (ऐलिस) को उसकी भूमिकाओं (प्रबंधक ...) से जोड़ता है। फिर आपके पास एक तालिका होगी जिसमें दस्तावेज़ मेटाडेटा होगा (जो कि आमतौर पर आपके द्वारा संरक्षित ऐप के भीतर एक तालिका है)। अनुमति स्वयं (देखें, संपादित करें, हटाएं) नीति में संग्रहीत है।
डेविड ब्रॉसार्ड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.