グループと役割（本当の違いはありますか？）

グループと役割の本当の違いは何ですか？私はしばらくの間これを理解しようと努めてきましたが、私が読んだ情報が多ければ多いほど、これは人々を混乱させるためだけに育てられ、本当の違いはないという感覚がますます得られます。どちらも相手の仕事をすることができます。私は常にグループを使用してユーザーとそのアクセス権を管理してきました。

最近、私は管理ソフトウェアに出くわしました。そこではたくさんのユーザーがいます。各ユーザーはモジュールを割り当てることができます（システム全体は、モジュールと呼ばれるいくつかの部分（管理モジュール、調査モジュール、注文モジュール、顧客モジュール）に分割されます）。その上に、各モジュールには機能のリストがあり、ユーザーごとに許可または拒否できます。したがって、ユーザーJohn SmithがモジュールOrdersにアクセスでき、任意の注文を編集できるが、それらのいずれかを削除する権限を与えていないとしましょう。

同じコンピテンシーを持つユーザーがもっといる場合は、グループを使用して管理します。そのようなユーザーを同じグループに集約し、モジュールへのアクセス権とその機能をグループに割り当てます。同じグループ内のすべてのユーザーは、同じアクセス権を持ちます。

役割ではなくグループと呼ぶのはなぜですか？わからない、ただそのように感じます。どうやらそれは本当に重要ではないように思えます：]しかし、私はまだ本当の違いを知りたいです。

これがグループまたはその逆ではなく役割と呼ばれるべきである理由はありますか？

Googleはあなたの友達です:)

とにかく、役割とグループの間の分割は、（単にリソース管理とは対照的に）コンピュータセキュリティの概念に由来します。Ravi Sandhu教授は、役割とグループの間のセマンティックな違いを精力的にカバーしています。

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

グループは、グループ（およびユーザーに推移的に）に割り当てられた特定の権限セットを持つユーザーのコレクションです。ロールは権限のコレクションであり、ユーザーはそのロールの下で行動するときにそれらの権限を効果的に継承します。

通常、グループメンバーシップはログイン中も残ります。一方、ロールは特定の条件に従ってアクティブ化できます。現在の役割が「医療スタッフ」の場合、特定の患者の医療記録の一部を表示できる可能性があります。ただし、あなたの役割が「医師」でもある場合、「医療スタッフ」の役割だけを持つ人が見ることができるものを超えて、追加の医療情報を見ることができる場合があります。

役割は、時刻、アクセス場所によってアクティブ化できます。ロールは、属性に拡張/関連付けることもできます。あなたは「医師」として活動しているかもしれませんが、「主治医」の属性または私（「患者」の役割を持つユーザー）との関係がない場合、私の病歴全体を見ることができません。

グループですべてを行うことができますが、グループは役割や活動ではなくアイデンティティに焦点を合わせる傾向があります。また、ここで説明したセキュリティの種類は、前者よりも後者によく合う傾向があります。

多くの場合、物事を一緒に分類する（それ以外は何もしない）場合、グループとロールはまったく同じように機能します。ただし、グループはアイデンティティに基づいていますが、役割はアクティビティを区別することを目的としています。残念ながら、オペレーティングシステムは区別を曖昧にする傾向があり、役割をグループとして扱います。

OSレベルで実装された「ロール」（通常はグループと同義）とは対照的に、アプリケーションまたはシステムレベルのロール-アプリケーションまたはシステム固有のセマンティクス（Oracleロールなど）との明確な違いがわかります。

役割と役割ベースのアクセス制御モデルには制限がある場合があります（もちろん何でも同様です）。

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

約10年前に、ロールベースのアクセス制御よりもはるかに優れた粒度を提供する属性ベースおよび関係ベースのアクセス制御に関するいくつかの研究を見ました。残念ながら、私は何年もその分野であまり活動していません。

ロールとグループの最も重要な違いは、ロールは通常、強制アクセス制御（MAC）メカニズムを実装することです。自分（または他の人）をロールに割り当てることはできません。役割管理者または役割エンジニアがそれを行います。

これは、表面的にはUNIXグループに似ており、ユーザーは（もちろんsudoを介して）グループに自分自身を割り当てることができます（可能性があります）。ただし、セキュリティエンジニアリングプロセスに従ってグループが割り当てられている場合、違いは少しあいまいになります。

別の重要な特性は、真のRBACモデルが相互に排他的な役割の概念を提供できることです。対照的に、アイデンティティベースのグループは付加的です-プリンシパルのアイデンティティはグループの合計（または結合）です。

真のRBACベースのセキュリティモデルのもう1つの特徴は、特定の役割に対して作成された要素は、通常、その役割のもとで行動しない人から推移的にアクセスできないことです。

一方、随意アクセス制御（DAC）モデル（UNIXのデフォルトモデル）では、グループだけではそのような保証はありません。ところで、これはグループやUnixの制限ではなく、IDに基づく（そしてIDベースのグループでは推移的に）DACモデルの制限です。

それが役に立てば幸い。

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

Simonの適切な応答を確認した後、さらに追加します。役割は、権限の管理に役立ちます。グループは、オブジェクトとサブジェクトの管理に役立ちます。さらに、役割を「コンテキスト」と考えることもできます。ロール「X」は、サブジェクトYがオブジェクトZにアクセスする（またはアクセスしない）方法を制御するセキュリティコンテキストを記述できます。

もう1つの重要な違い（または理想）は、アプリケーション、システム、またはOSで必要かつ/または明白であるロールエンジニア、ロール、コンテキストをエンジニアする人がいることです。ロールエンジニアは通常、ロール管理者（またはsysadmin）でもあります（そうである必要はありません）。さらに、ロールエンジニアの本当の役割（しゃれた意図はありません）は、管理ではなくセキュリティエンジニアリングの領域にあります。

これは、RBACによって形式化された新しいグループであり（ほとんど使用されない場合でも）、通常、グループ対応システムには存在しません。

グループはユーザーを整理する手段ですが、役割は通常、権限を整理する手段です。

これはいくつかの点で役立ちます。たとえば、ロールにグループ化された権限のセットを、グループのセットに割り当てることも、グループに関係なくユーザーのセットに割り当てることもできます。

たとえば、CMSには、投稿の読み取り、投稿の作成、投稿の編集などのいくつかの権限がある場合があります。編集者の役割は読み取りと編集はできるが、作成はできない（理由がわからない！）。投稿は作成や読み取りなどができる場合があります。マネージャーのグループには編集者の役割があり、マネージャーのグループに属していないITのユーザーにも編集者の役割がある場合があります。グループはしません。

したがって、単純なシステムでは、グループと役割が密接に連携していることがよくありますが、これは常に当てはまるとは限りません。

役割とグループの間には意味的な違いがありますが（他の回答で前述したように）、技術的には役割とグループは同じように見えます。アクセス許可をユーザーとグループに直接割り当てることを妨げるものはありません（これは、アクセス制御の微調整と見なすことができます）。同様に、ユーザーにロールが割り当てられている場合、ユーザーがグループのメンバーになるときと同じ意味で、ユーザーはロールメンバーと見なすことができます。

したがって、ロールとグループの間に実質的な違いがなくなる可能性があります。どちらも、ユーザーおよび/または権限をグループ化するために検討できます。したがって、違いはセマンティックのみです。—パーミッションのグループ化に意味的に使用されている場合、それはロールです。—意味的にユーザーのグループ化に使用される場合、それはグループになります。技術的には違いはありません。

「グループ」はユーザーの集合です。「ロール」は、権限のコレクションです。つまり、グループalphaにグループbetaが含まれている場合、alphaはすべてのユーザーをbetaから受け取り、betaはすべての権限をalphaから受け取ります。逆に、役割ベータには役割アルファが含まれ、同じ結論が当てはまると言えます。

具体的な例は、物事をより明確になります。「カスタマーサポート」と「シニアカスタマーサポート」を検討してください。これらのコレクションをグループと考えると、カスタマーサポートユーザーがシニアカスタマーサポートユーザーを「含む」ことは明らかです。ただし、それらを役割として見ると、シニアカスタマーサポートの権限にカスタマーサポート権限が「含まれている」ことは明らかです。

理論的には、単純に1つのコレクションタイプを持つことができます。ただし、「コレクションアルファにはコレクションベータが含まれている」と言えばあいまいです。その場合、アルファ版のユーザーがベータ版（ロールなど）であるか、ベータ版のユーザーがアルファ版（グループなど）であるかはわかりません。「includes」などの用語とツリービューなどの視覚要素を明確にするために、ほとんどのrbacシステムでは、問題のコレクションが「グループ」か「ロール」かを少なくとも議論のために指定する必要があります。

いくつかの類推が役立つかもしれません。集合論の観点から組み立てると、グループアルファがグループベータのサブセットである場合、権限アルファは権限ベータのスーパーセットです。系図と比較すると、グループが子孫のツリーのようなものである場合、役割は祖先のツリーのようなものです。

注-次のとりとめのない話は、組織内にセキュリティを課そうとしている場合にのみ意味があります。つまり、情報へのアクセスを制限しようとしています...

グループは経験的です-彼らは「何」の質問に答えます。それらは、アクセスの既存の現実を反映するという意味で「is」です。ITの人々はグループを愛しています-グループは非常に文字通りで定義が簡単です。最終的には、すべてのアクセス制御が最終的に（私たちがすべて中学校で学んだように）、「どのグループに属していますか？」という質問への回答に移ります。

ただし、役割はより規範的です。役割は「あるべき姿」を導きます。良い経営者や人事愛「役割」 -彼らは答えません-彼らは尋ねるの質問「なぜ？」残念ながら、役割もあいまいであり、その「あいまいさ」は人々を不快にさせる可能性があります。

場合は、上記の医療の例を使用するには、役割「プライマリケア医」のは、より多くの権利（複数のグループにすなわちアクセス）を持つ役割「は、X線技師」のを人（管理者やHR）が決まっているため、これはなぜそれを発生する必要がありました。その意味で、彼らは組織の「集合知」です。

医師が患者の財務記録へのアクセス権（アクセス権を持つグループへのメンバーシップ）を与えられているとしましょう。これは通常、医師の「役割」の範囲外であり、議論する必要があります。したがって、誰が（どのように資格があっても）すべてのグループへの完全なアクセス権を持つべきではありません-それは権力への虐待を招きます。これが、「ロールエンジニアリング」が非常に重要である理由です。これがないと、たくさんのキャンディのようにグループアクセスが渡されます。人々は、あまりにも多くの力の危険性について議論することなく、グループアクセスを収集します（時には大群）。

結論として、明確に定義された役割の知恵は、暴走するグループアクセスの危険を緩和するのに役立ちます。組織内の誰もが特定のグループへのアクセスを主張できます。しかし、そのアクセスが提供されると、めったに中止されることはありません。ロールエンジニアリング（明確に定義されたグループの説明や権限のあるグループアクセスマネージャなどのベストプラクティスと共に）は、組織内の利益相反を制限し、意思決定を分散化し、セキュリティ管理をより合理的にするのに役立ちます。

以前の答えはすべて素晴らしいです。すでに述べたように、グループと役割の概念は、技術的というより概念的です。私たちは、グループはユーザーの包含（つまり、ユーザーは複数のグループに属することができます。つまり、ジョーはマネージャーグループとITグループ[彼はITのマネージャーです]に属しています）と広範な特権の割り当てに使用されるというスタンスをとっています（つまり、当社のマグカードシステムでは、ITグループのすべてのユーザーがサーバールームにアクセスできます）。ロールを使用して特定のユーザーに特権を追加しました（つまり、ITグループのユーザーはサーバーにRDPを実行できますが、ユーザーの割り当てや権限の変更はできません。管理者ロールを持つITグループのユーザーはユーザーの割り当てや権限の変更ができます）。ロールは、他のロールで構成することもできます（Joeは、ユーザー/特権を追加するためのAdminロールと、サーバー上のDBMSへのデータベース変更を行うためのDBAロールを持っています）。個々のユーザーロール（つまり、JoesRole）をユーザーに固有なものにすることができるので、ロールも非常に固有なものにすることができます。要約すると、グループを使用してユーザーを管理し、一般的な役割と役割を割り当てて特権を管理します。これも累積的です。ユーザーが所属するグループには、非常に一般的な特権を与える役割（または使用可能な役割のリスト）が割り当てられている場合があります（つまり、ITグループユーザーは、サーバーにログオンできるようにするServerRDPの役割を持っています）。次に、ユーザーが属するすべてのロールは、最後のロールを持つ最後のロールで定義された順序で追加されます（ロールは特権を許可、拒否、または適用しないため、各ロールが適用されると、以前の特権の設定を上書きしますまたは変更しないでください）。すべてのグループレベルの役割とユーザーレベルの役割が適用されたら、

ユーザーは、システムで果たす責任に基づいてロールに割り当てられます。たとえば、Sales Managerの役割を持つユーザーは、製品に追加の割引を提供するなどの特定のアクションを実行できます。

グループは、セキュリティの管理を容易にするために、システム内のユーザーまたはロールを「グループ化」するために使用されます。たとえば、「リーダーシップグループ」という名前のグループには、マネージャー、ディレクター、アーキテクトの役割、およびこれらの役割の範囲外の個々のユーザーのメンバーを含めることができます。これで、このグループに特定の特権を割り当てることができるはずです。

グループとロールの目的はアプリケーションによって異なりますが、主に私が理解していることは次のとおりです。グループ（ユーザーのセット）は静的ですが、ロール（アクセス権のセット）は、たとえば（9から6）までの時間に基づいて、ポリシーとともに動的ですグループまたはユーザーはこの役割を持つことができますが、そうではありません。

グループに役割を割り当てることができます。ユーザーをグループに割り当てたり、任意の役割ユーザーの個々のユーザーに役割を割り当てたりすることができます。意味。Jean Doeは、SharePointからレポートを印刷できるReportWritterの役割を持つSalesDeptartmentのグループに所属できますが、SalesDepartmentグループでは、他のユーザーがReportWritterの役割を持たない場合があります。-つまり、役割は割り当てられたグループに対する特別な特権です。これでどんなシーンにもなることを願っています。

乾杯！！！