গ্রুপ বনাম ভূমিকা (কোন বাস্তব পার্থক্য?)


126

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

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

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

কেন এটিকে একটি গ্রুপ বলুন এবং ভূমিকা নয়? আমি জানি না, আমি কেবল এটি সেভাবে অনুভব করি। আমার কাছে মনে হয় কেবল এটি সত্যিকার অর্থে গুরুত্বপূর্ণ নয়:] তবে আমি এখনও সত্যিকারের পার্থক্যটি জানতে চাই।

এটিকে গ্রুপ বা অন্যভাবে গোলের চেয়ে বরং رول বলা উচিত কেন এমন কোনও পরামর্শ?



উপরে উল্লিখিত ডুপ্লিকেট দেখুন। এর শীর্ষ দুটি সংক্ষিপ্ত উত্তর উভয়ই এখানে যে কোনও একটির চেয়ে ভাল। (+ প্রযুক্তিগতভাবে গোষ্ঠী এবং ভূমিকাগুলি কীভাবে ব্যবহার করা হয় তার একইভাবে কাজ করে)
ফাস্টএল

2
আমি @ ফার্স্টএল এর সাথে একমত নই, আমি এই প্রশ্নের উত্তরগুলি সদৃশটির চেয়ে ভাল পেয়েছি।
অ্যালেক্স অলিভিরা

উত্তর:


148

গুগল আপনার বন্ধু :)

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

http://profsandhu.com/workshop/role-group.pdf

একটি গ্রুপ হ'ল এই গোষ্ঠীটি নির্ধারিত অনুমতির একটি সেট (এবং ব্যবহারকারীদের কাছে ট্রান্সজিটিভলি) নির্ধারিত ব্যবহারকারীদের একটি সংগ্রহ। একটি ভূমিকা হ'ল অনুমতিগুলির সংগ্রহ, এবং কোনও ব্যবহারকারী কার্যকরভাবে সেই অনুমতিগুলি উত্তরাধিকার সূত্রে পান যখন তিনি এই ভূমিকার অধীনে কাজ করেন।

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

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

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

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

আপনি অ্যাপ্লিকেশন বা সিস্টেম-স্তরের ভূমিকার সাথে অনেক স্পষ্টতর পার্থক্য দেখতে পাচ্ছেন - ওএস স্তরে প্রয়োগ করা 'ভূমিকা' (যা সাধারণত দলগুলির সমার্থক শব্দ) এর বিপরীতে - অ্যাপ্লিকেশন বা সিস্টেম-নির্দিষ্ট শব্দার্থ বহন করে (যেমন ওরাকল ভূমিকাগুলির মতো ) বহন করে )

ভূমিকা এবং ভূমিকা-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ মডেলগুলির সীমাবদ্ধতা থাকতে পারে (অবশ্যই যে কোনও কিছুর মতো):

http://www.lhotka.net/weblog/CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx

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

ভূমিকা এবং গোষ্ঠীর মধ্যে সর্বাধিক গুরুত্বপূর্ণ পার্থক্য হ'ল ভূমিকাগুলি সাধারণত একটি বাধ্যতামূলক অ্যাক্সেস কন্ট্রোল (MAC) প্রক্রিয়া প্রয়োগ করে। আপনি নিজেকে (বা অন্যদের) ভূমিকায় অর্পণ করতে পারবেন না। একজন ভূমিকা প্রশাসক বা ভূমিকা প্রকৌশলী তা করে।

এটি ইউনিক্স গ্রুপগুলির মতো পর্যাপ্তরকম যেখানে ব্যবহারকারী / নিজেকে কোনও গোষ্ঠীতে অর্পণ করতে সক্ষম হতে পারে (অবশ্যই সুডোর মাধ্যমে)) যখন সুরক্ষা প্রকৌশল প্রক্রিয়া অনুসারে গোষ্ঠীগুলি বরাদ্দ করা হয় তবে পার্থক্যটি কিছুটা ঝাপসা হয়ে যায়।

আর একটি গুরুত্বপূর্ণ বৈশিষ্ট্য হ'ল সত্য আরবিএসি মডেলগুলি পারস্পরিক একচেটিয়া ভূমিকার ধারণা সরবরাহ করতে পারে। বিপরীতে, পরিচয়-ভিত্তিক গোষ্ঠীগুলি সংযোজনযোগ্য - একটি প্রধানের পরিচয় হ'ল গ্রুপগুলির যোগফল (বা সংমিশ্রণ)।

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

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

আশা করি এটা সাহায্য করবে.

=======================

সাইমন এর ভাল-প্রতিক্রিয়া দেখে আরও কিছু যুক্ত করা। ভূমিকা আপনাকে অনুমতি পরিচালনা করতে সহায়তা করে। গোষ্ঠীগুলি আপনাকে অবজেক্ট এবং বিষয় পরিচালনা করতে সহায়তা করে। তদ্ব্যতীত, কেউ ভূমিকাটিকে 'প্রসঙ্গ' হিসাবে ভাবতে পারে। একটি ভূমিকা 'এক্স' এমন সুরক্ষা প্রসঙ্গ বর্ণনা করতে পারে যা Y Y অ্যাক্সেস (বা অ্যাক্সেস না করে) কীভাবে বিষয়বস্তু Z কে শাসন করে rule

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

এটি আরবিএসি দ্বারা আনুষ্ঠানিকভাবে অভিনীত একটি অভিনব গ্রুপ (এটি খুব কম ব্যবহৃত হলেও), এটি সাধারণত গ্রুপ-সক্ষম সিস্টেমগুলির সাথে উপস্থিত ছিল না।


4
মূলত আপনি যা বলছেন তা হ'ল: আপনি যদি এমন একটি গোষ্ঠীর অনুমতি তালিকা পেয়ে থাকেন যা আপনি ভূমিকাটি দেখছেন এবং যদি আপনি কোনও ভূমিকার তালিকা পান তবে আপনি একটি গোষ্ঠীর দিকে তাকাচ্ছেন।
নাতিম

না। যা ঘটে তা হ'ল অনেকগুলি সিস্টেম গ্রুপ হিসাবে ভূমিকা পালন করে (বা আরও খারাপ, গ্রুপগুলিকে "ভূমিকা" বলে। আমি যদি অনুসরণের জবাব দিয়ে আরও ভালভাবে এটি ব্যাখ্যা করতে পারি তবে আমাকে দেখতে দিন।
luis.espinal

প্রধান পার্থক্যগুলির মধ্যে একটি হ'ল গ্রুপ সদস্যপদটি আপনার অধিবেশন থেকে স্বাধীনভাবে থেকে যায় (আপনার লগিং অধিবেশন someone) কোনও গোষ্ঠীতে আপনার সদস্যতা তখনই পরিবর্তিত হয় যখন কেউ (আপনার বা যথেষ্ট সুযোগ সুবিধাযুক্ত কেউ) এটি পরিবর্তন করে।
luis.espinal

একটি ভূমিকা, "ভূমিকা" হিসাবে বিক্রি হওয়া একটি গোষ্ঠী ধারণা নয়, তবে একটি সত্য ভূমিকা, যখন অধ্যক্ষ একটি অধিবেশন (লগইন সেশন বা অ্যাপ্লিকেশন-নির্দিষ্ট অধিবেশন) শুরু করেন তখন সেই ভূমিকা অধ্যক্ষের সাথে যুক্ত হয় (ওরফে "ভূমিকা সক্রিয় রয়েছে") to যে ভূমিকা অধীনে।
luis.espinal

1
অ্যানালগিকভাবে, আমরা কি বলতে পারি যে দলগুলি গাছের মতো এবং ভূমিকাগুলি ট্যাগের মতো?
টন

26

একটি গোষ্ঠী ব্যবহারকারীদের সংগঠিত করার একটি মাধ্যম, যেখানে ভূমিকা সাধারণত অধিকার সংগঠিত করার একটি মাধ্যম।

এটি বিভিন্ন উপায়ে কার্যকর হতে পারে। উদাহরণস্বরূপ, কোনও ভূমিকার সাথে গোষ্ঠীভুক্ত অনুমতিের একটি সেট গোষ্ঠীর একটি সেট, বা তাদের গোষ্ঠীর স্বতন্ত্রভাবে ব্যবহারকারীদের একটি সেটকে বরাদ্দ করা যেতে পারে।

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

সুতরাং যখন একটি সহজ সিস্টেমের গোষ্ঠী এবং ভূমিকা প্রায়শই ঘনিষ্ঠভাবে সংযুক্ত থাকে, এটি সর্বদা ক্ষেত্রে হয় না।


সুতরাং যদি আমি এটি সঠিকভাবে বুঝতে পারি তবে আপনি ব্যবহারকারীদেরকে ভূমিকার জন্য বরাদ্দ করতে পারবেন না, তবে ব্যবহারকারীদের গোষ্ঠীগুলিতে নির্ধারিত করতে পারেন। এর পরে, আপনি ব্যবহারকারীদের গোষ্ঠীতে ভূমিকা নির্ধারণ করতে পারেন।
ndন্দ্রজ

অ্যান্ড্রেজ অগত্যা নয়। কোনও অ্যাপ্লিকেশন, সিস্টেম বা ওএস ব্যবহারকারীকে কোনও ভূমিকার দায়িত্ব দেওয়ার জন্য একটি প্রক্রিয়া প্রয়োগ করতে পারে (যদিও এটি খুব দ্রুত লোমশ হয়ে উঠতে পারে)।
পার্সোনালগুলি

ধন্যবাদ আপনাকে বলছি, এটি এখন আমার কাছে আরও স্পষ্ট। উপরে বর্ণিত সিস্টেমে Ive কেবল লক্ষ্য করেছেন, ব্যবহারকারীদের আলাদা করার জন্য আরও একটি প্রক্রিয়া রয়েছে। যে কোনও মডিউলে নিযুক্ত প্রতিটি ব্যবহারকারীর একজন ব্যবহারকারী, সুপারভাইজার এবং প্রশাসক হিসাবে তার দক্ষতার দ্বারা আরও আলাদা করা যেতে পারে, যা আমি অনুমান করি যে এটিই হল রোল সিস্টেম:] তাই আবারও আপনাকে ধন্যবাদ উভয়কে! ;)
ওন্দ্রেজ

আমি আপনার ব্যাখ্যাটি পছন্দ করি, তবে কিছু কারণে এখানে কেউ একাধিক গ্রুপের ব্যবহারকারীর সম্ভাবনা সম্পর্কে লেখেননি ... গোষ্ঠীগুলির পক্ষে অন্যান্য গোষ্ঠী এবং ভূমিকাগুলির ক্ষেত্রে যে ভূমিকা পালন করার অনুমতি দেয় এবং এটি কী সম্ভব? সম্পদ সম্পর্কে? সংস্থানগুলিও কি গোষ্ঠীভুক্ত হতে পারে না? সম্পদের ভূমিকা থাকতে পারে না?
inor

19

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

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


আসলে গ্রুপগুলি অ্যাক্সেসের জন্য নির্ধারিত ক্লাসগুলিতে সি # এর মতো একটি পার্থক্য কম্পিউটার ভাষা রয়েছে। ভূমিকাগুলি অ্যাক্সেসের জন্য those ভূমিকার (অনুমতিগুলির সেট হিসাবে), বনাম একটি গোষ্ঠী (ব্যবহারকারীদের সেট হিসাবে) থেকে প্রত্যাশার মতো তাদের আলাদা আলাদা সম্পত্তির নাম এবং বিভিন্ন পদ্ধতি রয়েছে।
পাশুতে

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

18

একটি "গোষ্ঠী" ব্যবহারকারীদের সংগ্রহ। একটি "ভূমিকা" অনুমতিগুলির সংগ্রহ। এর অর্থ হ'ল যখন গ্রুপ আলফায় গ্রুপ বিটা অন্তর্ভুক্ত থাকে , আলফা সমস্ত ব্যবহারকারীকে বিটা থেকে গ্রহণ করে এবং বিটা আলফা থেকে সমস্ত অনুমতি গ্রহণ করে। বিপরীতে, আপনি বলতে পারেন ভূমিকা বিটাতে ভূমিকা আলফা অন্তর্ভুক্ত রয়েছে এবং একই সিদ্ধান্তগুলি প্রযোজ্য হবে।

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

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

কিছু উপমা সাহায্য করতে পারে। সেট তত্ত্বের ক্ষেত্রে ফ্রেমযুক্ত , যখন গ্রুপ আলফা গ্রুপ বিটার একটি উপসেট হয়, তবে অনুমতিগুলি আলফা হ'ল অনুমতি বিটার একটি সুপারসেট। বংশের তুলনায় , দলগুলি যদি বংশধরদের গাছের মতো হয় তবে ভূমিকাগুলি পূর্বপুরুষের গাছের মতো।


আপনার ব্যাখ্যায় হুবহু কভার রয়েছে যে আমরা কেবল গোষ্ঠীগুলিকে ভুমিকা হিসাবে বিবেচনা করতে পারি না (মাইলটার উত্তর অনুসারে)। নিখুঁত উদাহরণ।
ড্রাইজিন

2
প্রকৃতপক্ষে আমরা দলগুলিকে ভূমিকা হিসাবে বিবেচনা করতে পারি ( মাইলতা সেকোভিক যেমন বলেছেন )। উদাহরণস্বরূপ, আমরা প্রতিটি গ্রুপের জন্য কেবল একটি অনন্য ভূমিকা নির্ধারণ করতে পারি (1: 1 সম্পর্ক)। তবে আমরা দলগুলির মধ্যে সম্পর্কের সাথে সম্পর্কিত ভূমিকার মধ্যে সম্পর্ক হিসাবে ব্যাখ্যা করতে পারি না। উদাহরণস্বরূপ, যদি গ্রুপ "গ্রাহক সমর্থন" অন্তর্ভুক্ত গ্রুপ "জ্যেষ্ঠ গ্রাহক সমর্থন" - এর মানে এই নয় যে ভূমিকা "গ্রাহক সমর্থন" অন্তর্ভুক্ত ভূমিকা "জ্যেষ্ঠ গ্রাহক সমর্থন"।
রুভিম

3

দ্রষ্টব্য - নিম্নলিখিত সংস্থাগুলি কেবল তখনই বোধগম্য হয় যদি কেউ কোনও প্রতিষ্ঠানের মধ্যে সুরক্ষা আরোপের চেষ্টা করে - যা তথ্যের অ্যাক্সেসকে সীমাবদ্ধ করার চেষ্টা করে ...

গোষ্ঠীগুলি অভিজ্ঞতাবাদী - তারা "কী" এই প্রশ্নের উত্তর দেয়। তারা সেই "অর্থে" এই অর্থে যে তারা অ্যাক্সেসের বিদ্যমান বাস্তবতা প্রতিফলিত করে। আইটি লোকেরা গোষ্ঠীগুলিকে পছন্দ করে - এগুলি খুব আক্ষরিক এবং সংজ্ঞায়িত করা সহজ। অবশেষে, সমস্ত অ্যাক্সেস নিয়ন্ত্রণ শেষ পর্যন্ত (আমরা সকলেই মিডিয়াম স্কুলে শিখেছি ...) প্রশ্নের উত্তর দিতে "আপনি কোন গ্রুপের?"

ভূমিকাগুলি অবশ্য আরও আদর্শিক - তারা "কী হওয়া উচিত" গাইড করে। ভাল পরিচালক এবং এইচআর "ভূমিকা" পছন্দ করে - তারা উত্তর দেয় না - তারা "কেন?" প্রশ্ন জিজ্ঞাসা করে দুর্ভাগ্যক্রমে, ভূমিকাগুলিও অস্পষ্ট হতে পারে এবং "অস্পষ্টতা" লোকেরা বাদাম চালাতে পারে drive

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

ধরা যাক কোনও চিকিত্সককে রোগীদের আর্থিক রেকর্ডে অ্যাক্সেস (অ্যাক্সেস সহ একটি গোষ্ঠীর সদস্যতা) দেওয়া হয়। এটি সাধারণত কোনও চিকিত্সকের "ভূমিকার" বাইরে থাকে এবং তর্ক করা উচিত । সুতরাং, কারওই (যেভাবেই যোগ্যতা আসুক না কেন) সমস্ত দলে সম্পূর্ণ অ্যাক্সেস থাকা উচিত - এটি ক্ষমতার অপব্যবহারকে আমন্ত্রণ জানায়। এই কারণেই "রোল ইঞ্জিনিয়ারিং" এত গুরুত্বপূর্ণ - এটি ছাড়া আপনার কেবল গ্রুপের অ্যাক্সেস এত ক্যান্ডির মতো হ'ল। লোকেরা অত্যধিক শক্তির ঝুঁকির বিষয়ে কোনও আলোচনা ছাড়াই গোষ্ঠী অ্যাক্সেস সংগ্রহ করবে (এবং কখনও কখনও জঙ্গি)।

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


3

পূর্ববর্তী উত্তরগুলি সমস্ত দুর্দান্ত। যেমনটি বলা হয়েছিল, গ্রুপ বনাম রোলের ধারণাগুলি প্রযুক্তিগতের চেয়ে ধারণাগত। আমরা এই অবস্থান নিয়েছি যে গোষ্ঠীগুলি ব্যবহারকারীদের ব্যবহারের জন্য ব্যবহৃত হয় (কোনও ব্যবহারকারী একাধিক গ্রুপে থাকতে পারে: যেমন জো ম্যানেজার গ্রুপে পাশাপাশি আইটি গ্রুপে [তিনি আইটি-তে একজন পরিচালক)] এবং বিস্তৃত সুযোগসামগ্রী নির্ধারণের জন্য (অর্থাত্ আমাদের ম্যাগ কার্ড কার্ডটি আইটি গ্রুপের সমস্ত ব্যবহারকারীকে সার্ভার রুমে অ্যাক্সেসের অনুমতি দেয়)। ভূমিকা এখন নির্দিষ্ট ব্যবহারকারীদের সুবিধার্থে যুক্ত করার জন্য ব্যবহৃত হয়েছিল (অর্থাত্ আইটি গ্রুপের লোকেরা সার্ভারগুলিতে আরডিপি দিতে পারে তবে ব্যবহারকারীকে বরাদ্দ করতে বা অনুমতি পরিবর্তন করতে পারে না, আইটি গ্রুপের প্রশাসনের ভূমিকাতে থাকা লোকেরা ব্যবহারকারীকে নিয়োগ এবং অনুমতি পরিবর্তন করতে পারে)। ভূমিকা অন্যান্য ভূমিকা থেকেও তৈরি করা যেতে পারে (জো / ব্যবহারকারী / সুবিধাগুলি যুক্ত করতে প্রশাসনের ভূমিকা রাখে এবং সার্ভারে ডিবিএমএসে ডাটাবেস পরিবর্তন করতে ডিবিএর ভূমিকাও রাখে)। ভূমিকাগুলিও খুব সুনির্দিষ্ট হতে পারে যে আমরা পৃথক ব্যবহারকারী ভূমিকা তৈরি করতে পারি (অর্থাত্ জোসরোল) যা ব্যবহারকারীর জন্য খুব নির্দিষ্ট হতে পারে। সুতরাং, পুনর্নির্মাণের জন্য, আমরা ব্যবহারকারীদের পরিচালনা করতে গ্রুপগুলি ব্যবহার করি এবং সুবিধাগুলি পরিচালনার জন্য সাধারণ ভূমিকা ও ভূমিকা নিযুক্ত করি। এটিও संचयी। ব্যবহারকারী যে গোষ্ঠীতে রয়েছেন তার মধ্যে রোলস নির্ধারিত থাকতে পারে (বা উপলভ্য ভূমিকাগুলির একটি তালিকা) যা খুব সাধারণ সুযোগ-সুবিধা দেয় (যেমন আইটি গ্রুপ ব্যবহারকারীদের মধ্যে সার্ভারআরডিপি ভূমিকা রয়েছে যা তাদের সার্ভারগুলিতে লগ ইন করতে দেয়) যাতে ব্যবহারকারীকে বরাদ্দ করা হয়। তারপরে ব্যবহারকারী যে কোনও ভূমিকা অন্তর্ভুক্ত করবেন সেগুলি চূড়ান্তভাবে বলার সাথে শেষ ভূমিকাটির সাথে সংজ্ঞায়িত ক্রমের সাথে যুক্ত করা হবে (ভূমিকাগুলি অনুমোদন দিতে পারে, অস্বীকার করতে বা প্রয়োগ করতে পারে না যাতে প্রতিটি ভূমিকা যেমন প্রয়োগ করা হয় তেমনি এটি কোনও সুবিধার জন্য পূর্ববর্তী সেটিংসকে ওভাররাইড করে বা এটি পরিবর্তন না)। একবার সমস্ত গ্রুপ স্তরের ভূমিকা এবং ব্যবহারকারীর স্তরের ভূমিকা প্রয়োগ হয়ে গেলে,


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

1

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

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


1

গোষ্ঠী এবং ভূমিকার উদ্দেশ্য অ্যাপ্লিকেশনগুলিতে পৃথক হয়, তবে প্রধানত যা আমি বুঝতে পেরেছিলাম তা অনুসরণ হিসাবে, গ্রুপগুলি (ব্যবহারকারীদের সেট) স্থিতিশীল এবং ভূমিকাগুলি (অনুমতিগুলির সেট) নীতিগুলি সহ গতিশীল, উদাহরণস্বরূপ (9 থেকে 6) এ সময় ভিত্তিক গোষ্ঠী বা ব্যবহারকারীর এই ভূমিকা থাকতে পারে তবে তা নয়।


0

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

চিয়ার্স !!!

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.