ভূমিকা ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ কীভাবে ডিজাইন করবেন?


15

ব্যবহারকারীরা আমার সিস্টেমে কী করতে পারে বা করতে পারে না তা সীমাবদ্ধ করতে আমি ভূমিকা ঘাঁটি অ্যাক্সেস নিয়ন্ত্রণের মডেলটি অনুসরণ করার চেষ্টা করছি।

এখনও পর্যন্ত আমি নিম্নলিখিত সত্তা আছে:

ব্যবহারকারী - সিস্টেমটি ব্যবহার করবে এমন লোক। এখানে আমার ব্যবহারকারীর নাম এবং পাসওয়ার্ড রয়েছে। ভূমিকা - ব্যবহারকারীদের যে ভূমিকা থাকতে পারে তা সংগ্রহ। ম্যানেজার, অ্যাডমিন ইত্যাদির মতো স্টাফস - সংস্থানগুলি যেগুলি ব্যবহারকারীরা হেরফের করতে পারেন। চুক্তি, ব্যবহারকারী, চুক্তি খসড়া ইত্যাদির মতো কাজগুলি - ব্যবহারকারী যেগুলি সংস্থানগুলি করতে পারে তা। তৈরি করা, পড়া, আপডেট করা বা মুছতে পছন্দ করে।

এখন, আমার সন্দেহটি এখানে ডায়াগ্রামে উঠে এসেছে যেখানে আমার এইরকম একটি সম্পর্ক রয়েছে:

অপারেশনস (0 .. *) রিসোর্সের (0 .. *) উপর চালিত হয় যা একটি টেবিল তৈরি করে যার জন্য আমি অনুমতি বলেছি এবং এটি অপারেশন এবং সংস্থান সংরক্ষণ করবে

অনুমতিগুলির সারণীটি এর মতো দেখতে পাবেন (এর এক সারি): আইডি: 1, অপারেশন: তৈরি, সংস্থান: চুক্তি।

কোনটি মানে অনুমতি থেকে তৈরি একটি চুক্তি

আমি এটি এইভাবে করেছি কারণ আমার মনে হয় কিছু সংস্থার সমস্ত ধরণের অপারেশন নাও থাকতে পারে। উদাহরণস্বরূপ, চুক্তিগুলি নিবন্ধকরণের জন্য , ব্যবহারকারীরা ফাইলগুলি আপলোড করতে পারেন , তবে সরবরাহকারী নিবন্ধকরণের জন্য এই অপারেশনটি উপলভ্য নয় ।

সুতরাং এখন যখন প্রশাসক কোনও ভূমিকার অনুমতি দিচ্ছেন , তখন তার সিস্টেমে নিবন্ধিত প্রতিটি ক্রিয়াকলাপের সংস্থানগুলির তালিকা থাকবে না।

আমি মনে করি প্রতিটি সংস্থার নিজস্ব ক্রিয়াকলাপ রয়েছে যা তার উপর কার্যকর করা যেতে পারে।

কিছু বুঝতে না পারলে আমি স্পষ্ট করে বলতে পারি।

এটি কি ব্যর্থতা কার্যকর করার সঠিক উপায়?

সম্পাদনা

আমি যা বলতে চাইছি তা হল কোনও অনুমতি টেবিল রয়েছে যারটিতে অপারেশন এবং সংস্থান রয়েছে , আমার কাছে দুটি আরও টেবিল রয়েছে কারণ আমি অপারেশনগুলির সাথে সংস্থানগুলি সংযুক্ত করতে চাই । আমিও ঠিক কাজ করতে পারে সম্পদ আছে অনুমতি যেখানে অনুমতি টেবিল অনুমতি সংরক্ষণ করবে।

তবে তারপরে কী ঘটেছিল তা হ'ল কিছু অনুমতি যা কিছু সংস্থানগুলির জন্য এমনকি অস্তিত্বও উপস্থিত না থাকায় এডমিন যখন তাদের বরাদ্দ করা হত।

সুতরাং আমি একটি ডাটাবেস ডিজাইন দৃষ্টিকোণ থেকে জানতে চাই যে এই টেবিলের অনুমতিটিতে যার একটি কলাম অপারেশন রয়েছে এবং অন্য সংস্থানটি সঠিক? এটি যদি এভাবেই থাকে তবে কি আমি সমস্যার মধ্যে পড়ে যাব?


2
"সঠিক" বলতে কী বোঝ? দ্রষ্টব্য: "সেরা অনুশীলন" এর মতো টোটোলজির সাথে উত্তর দিবেন না। আপনার নির্দিষ্ট প্রয়োজনীয়তা বর্ণনা করুন।
রবার্ট হার্ভে

1
আমার "সংশোধন" এর সংজ্ঞাটি সাধারণত "এটি যা আপনার সফ্টওয়্যারটির কার্যকরী এবং অ-কার্যকরী প্রয়োজনীয়তা সবচেয়ে কার্যকরভাবে পূরণ করে।" মনে রাখবেন যে এনআইএসটি ভূমিকা-ভিত্তিক সুরক্ষার জন্য বিশদ গাইডলাইন এবং সেরা-অনুশীলন সরবরাহ করে। Csrc.nist.gov/groups/SNS/rbac
রবার্ট হার্ভে

পন্ডিত প্রকল্পে এটি কীভাবে হয় তা দেখার জন্য আপনি আগ্রহী হতে পারেন ।
এন্টার বাইার্ড

1
আপনি এই জন্য একটি গ্রন্থাগার ব্যবহার বিবেচনা করা উচিত।
রিবল্ড এডি

প্রচুর গ্রন্থাগার রয়েছে যা আপনার জন্য আরবিএসি বা এবাক করবে
ডেভিড

উত্তর:


11

আপনার নকশা আমার কাছাকাছি মনে হয়। মাত্র একটি দম্পতি পরামর্শ।

ব্যবহারকারী - সিস্টেমটি ব্যবহার করবে এমন লোক। এখানে আমার ব্যবহারকারীর নাম এবং পাসওয়ার্ড রয়েছে।

জরিমানা

ভূমিকা - ব্যবহারকারীদের যে ভূমিকা থাকতে পারে তা সংগ্রহ। ম্যানেজার, অ্যাডমিন ইত্যাদির মতো স্টাফ

খুব ভাল। তবে আপনার একটি "ইউজাররোলস" সত্তা / টেবিলেরও প্রয়োজন হবে যা আপনাকে জানাবে যে কোন ব্যবহারকারীর কোন ভূমিকা রয়েছে। সম্ভবত কোনও প্রদত্ত ব্যবহারকারীর দুটি বা ততোধিক ভূমিকা থাকতে পারে।

সংস্থানসমূহ - যে জিনিসগুলি ব্যবহারকারীরা হেরফের করতে পারে। চুক্তি, ব্যবহারকারী, চুক্তি খসড়া ইত্যাদির মতো

শব্দার্থবিজ্ঞানের একটি প্রশ্ন হতে পারে। আমি মনে করি না যে ব্যবহারকারীরা সরাসরি সংস্থানগুলি ব্যবহার করে; ভূমিকা আছে। সুতরাং এটি ব্যবহারকারী -> ব্যবহারকারী ভূমিকা -> ভূমিকা -> অপারেশন -> সংস্থানতে যায়

ক্রিয়াকলাপ - ব্যবহারকারী যেগুলি সংস্থানগুলি দিয়ে করতে পারে। তৈরি করা, পড়া, আপডেট করা বা মুছতে পছন্দ করে।

হ্যাঁ, "ব্যবহারকারী" এর পরিবর্তে "ভূমিকা" বাদে

অনুমতিগুলির সারণীটি এর মতো দেখতে পাবেন (এর এক সারি): আইডি: 1, অপারেশন: তৈরি, সংস্থান: চুক্তি। যার অর্থ চুক্তি তৈরির অনুমতি।

হুম। এটির সাথে যাওয়ার দুটি উপায় আছে। আপনি বর্ণিত অনুমতি সারণী থাকতে পারে, তবে আপনার অতিরিক্ত RolePermissionsটেবিল / সত্তাও প্রয়োজন যা আপনাকে জানায় যে কোন ভূমিকাটিতে কোন অনুমতি রয়েছে। তবে আমি নিশ্চিত নই যে এটি প্রয়োজনীয়।

এটি করার সহজতর উপায় হ'ল এই কলামগুলি / বৈশিষ্ট্যগুলির সাথে অনুমতি সারণী / সত্তা: ভূমিকা আইডি, অপারেশন আইডি, রিসোর্সআইডি। এইভাবে, অপারেশন এক্স রিসোর্স সংমিশ্রণগুলি কোনও ভূমিকার জন্য নির্ধারিত অনুমতিতে লোড না করে সরাসরি কোনও ভূমিকার জন্য বরাদ্দ করা হয়। এটি একটি সত্তা নির্মূল করে। কোনও পৃথক রোল-অজোনস্টিক অনুমতি টেবিলের সত্যই দরকার নেই, যদি না আপনি পূর্বনির্ধারিত করতে চান তবে কোন অনুমতি সংমিশ্রণ অনুমোদিত এবং কোনটি অনুমোদিত নয়।


প্রথমত, আমি "ব্যবহারকারী" সংশোধনের পরিবর্তে "ভূমিকা" এর সাথে সম্পূর্ণ একমত। আমি এটাই বোঝাতে চেয়েছিলাম এখন, জিনিসটি হ'ল আমি সংস্থানগুলি অপারেশনের সাথেও যুক্ত করতে চাই। উদাহরণস্বরূপ: একটি চুক্তি সংস্থার আপলোড_ফাইলের মতো একটি অপারেশন রয়েছে। সুতরাং আমি যা চাই না তা হ'ল আপলোড_ফায়াল অপারেশনটি অন্য কোনও সংস্থায় উপস্থিত হওয়ার জন্য যেখানে অ্যাডমিন যখন কোনও ভূমিকার জন্য অনুমতি বরাদ্দ করে থাকে তখন সরবরাহকারীদের (অন্য সংস্থান) এর মতো একটি আপলোড_ফায়াল অপারেশন নেই।
imran.razak

13

আমি আরবিএসি ব্যবহার বা প্রয়োগ করব না। পরিবর্তে আমি ABAC ব্যবহার করব। আমাকে বিস্তারিত বলতে দাও...

  • আরবিএসি বা ভূমিকা-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ ব্যবহারকারী পরিচালনা এবং ভূমিকা কার্যনির্বাহী সম্পর্কে। আরবিএসি-তে, আপনি বলতে পারেন যে অ্যালিস একজন পরিচালক। আপনি সেই সাথে স্থির অনুমতিগুলি সংজ্ঞায়িত করতে পারেন। উদাহরণস্বরূপ, একজন পরিচালক loansণ অনুমোদন করতে পারেন। সুতরাং অনুমতি হিসাবে লোন অনুমোদনের জন্য অ্যালিসের ম্যানেজারের সাথে একটি লিঙ্ক রয়েছে। প্রচুর সিস্টেম রয়েছে যা আপনাকে এটি করতে দেয় যাতে আপনার নিজের টেবিলগুলি প্রয়োগ করার প্রয়োজন হয় না। এমনকি আরবিএসি-র সীমিত সেটগুলির জন্যও এলডিএপি সমর্থন করে। আপনার ভূমিকা ও অনুমতিগুলির তুলনামূলকভাবে ছোট সেট থাকা পর্যন্ত এটি ঠিক আছে। তবে আপনি যদি আপনার ক্ষেত্রে যেমন নির্দিষ্ট অনুমতি গ্রহণ করতে চান তবে কী হবে? দেখুন, মুছুন, ,োকান? আপনি যদি সম্পর্কের বিষয়টি আমলে নিতে চান?
  • ABAC বা অ্যাট্রিবিউট-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ নীতি চালিত, সূক্ষ্ম দানযুক্ত অনুমোদনের বিষয়ে। এবাকের সাহায্যে আপনি আরবিএসি সংজ্ঞায়িত ভূমিকাগুলি ব্যবহার করতে পারেন এবং নীতিগুলি লিখতে পারেন যেমন
    • পরিচালকরা তাদের বিভাগে নথি দেখতে পারেন
    • কর্মচারীরা নিজের দস্তাবেজগুলি সম্পাদনা করতে পারবেন

আপনার প্রশ্নে, আপনি প্রয়োজনীয়ভাবে তথ্য মডেলটি সংজ্ঞায়িত করেছেন। আপনার অবজেক্টস এবং তাদের বৈশিষ্ট্যগুলি যেমন একটি ব্যবহারকারী (নাম, পাসওয়ার্ড, বিভাগ ...); একটি অবজেক্ট (যেমন একটি চুক্তি) এবং আরও অনেক কিছু।

তথ্য মডেল

অ্যাব্যাক-এ, আপনি অত্যাধিকতা যুক্তি থেকে আপনার অ্যাপ কোড / লজিককে সম্পূর্ণরূপে ডিকুয়াল করবেন যা বৈশিষ্ট্যগুলি ব্যবহার করে নীতি হিসাবে সংরক্ষণ করা হয়। অনুমতিগুলি নিজেই নীতিতে সংরক্ষণ করা হয় (উপরের উদাহরণ দেখুন)। ABAC স্থাপনার আর্কিটেকচারটি নীচের মত দেখাচ্ছে

অ্যাট্রিবিউট ভিত্তিক অ্যাক্সেস কন্ট্রোল আর্কিটেকচার

মুল বক্তব্যটি হ'ল আপনি যদি কোন এএবিএসি পন্থা অবলম্বন করেন তবে আপনি এব্যাকের জন্য নীতি লেখেন (হয় এক্সএএমসিএমএল বা আলফায় - এর জন্য প্রচুর সরঞ্জাম রয়েছে) এবং আপনার আর কখনও কাস্টম-কোড বা কাস্টম-প্রয়োগকারী আরবিএসি বা অ্যাক্সেস নিয়ন্ত্রণের দরকার নেই।


1
আপনার নীতিগুলির উদাহরণে এটি বলেছে যে পরিচালকরা তাদের বিভাগে নথি দেখতে পারেন। এর অর্থ কি এই যে সিস্টেমটিতে ইতিমধ্যে পূর্বনির্ধারিত অনুমতি, ভূমিকা এবং সংস্থানগুলির ধরণ থাকবে?
imran.razak

না। এর অর্থ হল আপনার কাছে এমন কিছু (এলডিএপি? একটি টেবিল?) থাকবে যা কোনও ব্যবহারকারীকে (অ্যালিস) তার ভূমিকার সাথে পরিচালনা করে (পরিচালক ...)? তারপরে আপনার একটি টেবিল থাকবে যাতে নথির মেটাডেটা থাকবে (এটি সাধারণত আপনি যে অ্যাপ্লিকেশনটি সুরক্ষিত করছেন তার মধ্যে একটি টেবিল)। অনুমতি নিজেই (দেখুন, সম্পাদনা করুন, মুছুন) নীতিতে সংরক্ষণ করা হয়।
ডেভিড
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.