グループとロールの本当の違いは何か、誰か教えてもらえませんか? しばらく前からこのことを理解しようとしていますが、情報を読むほど、これは人々を混乱させるために持ち出されていて、実際の違いはないという印象を受けます。どちらも、お互いの仕事をこなすことができます。私は常に、ユーザーとそのアクセス権を管理するためにグループを使用してきました。
最近、多数のユーザーがいる管理ソフトウェアを見つけました。各ユーザーにはモジュールを割り当てることができます (システム全体がモジュールと呼ばれるいくつかの部分に分割されています。管理モジュール、調査モジュール、注文モジュール、顧客モジュールなど)。さらに、各モジュールには機能のリストがあり、各ユーザーに対して許可または拒否できます。たとえば、ユーザー John Smith はモジュール注文にアクセスしてすべての注文を編集できますが、注文を削除する権限は付与されていません。
同じ能力を持つユーザーが複数いる場合は、グループを使用して管理します。そのようなユーザーを同じグループに集約し、モジュールとその機能へのアクセス権をグループに割り当てます。同じグループ内のすべてのユーザーには同じアクセス権が与えられます。
なぜそれをロールではなくグループと呼ぶのでしょうか? 分かりませんが、そう感じるだけです。単純に、それはあまり重要ではないように思えます:] しかし、私はまだ本当の違いを知りたいです。
これをグループではなくロールと呼ぶべき理由、あるいはその逆の理由について何か提案はありますか?
ベストアンサー1
役割とグループの間の区別は、コンピュータ セキュリティの概念 (単なるリソース管理ではなく) から生じます。Ravi Sandhu 教授は、役割とグループの意味の違いについて独創的な解説を行っています。
http://profsandhu.com/workshop/role-group.pdf
グループとは、グループ (および推移的にユーザー) に割り当てられた特定の権限セットを持つユーザーの集合です。ロールとは権限の集合であり、ユーザーはそのロールで操作するときにそれらの権限を効果的に継承します。
通常、ログインしている間はグループ メンバーシップは維持されます。一方、役割は特定の条件に従ってアクティブ化できます。現在の役割が「医療スタッフ」の場合、特定の患者の医療記録の一部を表示できる可能性があります。ただし、役割が「医師」でもある場合は、「医療スタッフ」の役割のみを持つユーザーが表示できるものを超える追加の医療情報を表示できる可能性があります。
ロールは、時間帯やアクセス場所によってアクティブ化できます。ロールは、属性によって強化/関連付けることもできます。「医師」として活動しているとしても、「主治医」属性または私（「患者」ロールを持つユーザー）との関係がない場合は、私の医療履歴全体を見ることはできません。
グループでもこれらすべてを行うことができますが、繰り返しになりますが、グループは役割やアクティビティではなく、アイデンティティに重点を置く傾向があります。また、先ほど説明したタイプのセキュリティの側面は、前者よりも後者とよりよく一致する傾向があります。
多くの場合、物事を分類する目的（それ以上の目的ではない）では、グループとロールはまったく同じように機能します。ただし、グループは ID に基づいているのに対し、ロールはアクティビティを区別することを目的としています。残念ながら、オペレーティング システムではこの区別があいまいになり、ロールをグループとして扱う傾向があります。
アプリケーションレベルまたはシステムレベルのロールとの区別はより明確です。ロールはアプリケーションまたはシステム固有のセマンティクスを持ちます（Oracle ロール) - OS レベルで実装される「ロール」(通常はグループと同義) とは対照的です。
ロールとロールベースのアクセス制御モデルには制限がある場合があります (もちろん他のものと同様)。
http://www.lhotka.net/weblog/CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx
約 10 年前、ロールベースのアクセス制御よりもはるかに優れた粒度を提供する属性ベースおよび関係ベースのアクセス制御に関する研究をいくつか目にしました。残念ながら、この分野ではここ数年あまり活動が見られません。
ロールとグループの最も重要な違いは、ロールでは通常、強制アクセス制御 (MAC) メカニズムが実装されることです。自分自身 (または他のユーザー) をロールに割り当てることはできません。ロール管理者またはロール エンジニアがそれを行います。
これは、ユーザーが自分自身をグループに割り当てることができる（もちろん sudo 経由）UNIX グループと表面的には似ています。ただし、グループがセキュリティ エンジニアリング プロセスに従って割り当てられる場合、区別は少し曖昧になります。
もう 1 つの重要な特徴は、真の RBAC モデルでは相互に排他的なロールの概念を提供できることです。対照的に、アイデンティティ ベースのグループは加算的であり、プリンシパルのアイデンティティはグループの合計 (または結合) になります。
真の RBAC ベースのセキュリティ モデルのもう 1 つの特徴は、特定のロール用に作成された要素に、通常、そのロールの下で動作していないユーザーが推移的にアクセスできないことです。
一方、任意アクセス制御 (DAC) モデル (Unix のデフォルト モデル) では、グループだけではそのような保証を得ることはできません。ちなみに、これはグループや Unix の制限ではなく、アイデンティティに基づく DAC モデル (および推移的に、アイデンティティ ベースのグループ) の制限です。
それが役に立てば幸い。
=======================
Simon のよくまとまった回答を見て、さらにいくつか追加します。ロールは権限の管理に役立ちます。グループはオブジェクトとサブジェクトの管理に役立ちます。さらに、ロールは「コンテキスト」と考えることもできます。ロール「X」は、サブジェクト Y がオブジェクト Z にアクセスする (またはアクセスしない) 方法を制御するセキュリティ コンテキストを記述できます。
もう 1 つの重要な違い (または理想) は、ロール エンジニアが存在することです。ロール エンジニアとは、アプリケーション、システム、または OS で必要かつ明白なロールやコンテキストを設計する人です。ロール エンジニアは通常 (ただし、必ずしもそうである必要はありません)、ロール管理者 (またはシステム管理者) でもあります。さらに、ロール エンジニアの真の役割 (しゃれではありません) は、管理ではなく、セキュリティ エンジニアリングの領域にあります。
これは、RBAC によって形式化された新しいグループです (めったに使用されませんが)。通常、グループ対応システムには存在しません。