グループとロール（本当の違いは？）
グループと役割の本当の違いは何ですか？私はこれをしばらく理解しようとしてきましたが、私が読んでいる情報が多ければ多いほど、これは人々を混乱させるためだけにもたらされ、本当の違いはないという感覚が得られます。どちらも相手の仕事をすることができます。私は常にグループを使用してユーザーとそのアクセス権を管理してきました。
最近、多くのユーザーがいる管理ソフトウェアに出会いました。各ユーザーはモジュールを割り当てることができます（システム全体は、モジュールと呼ばれるいくつかの部分に分割されます。すなわち、管理モジュール、調査モジュール、注文モジュール、顧客モジュールです）。さらに、各モジュールには機能のリストがあり、各ユーザーに対して許可または拒否することができます。たとえば、ユーザー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）メカニズムを実装することです。自分（または他の人）を役割に割り当てることはできません。ロール管理者またはロールエンジニアがそれを行います。
これは、ユーザーが（もちろんSudoを介して）グループに自分自身を割り当てることができる/できるUNIXグループに表面的に似ています。ただし、セキュリティエンジニアリングプロセスに従ってグループを割り当てると、区別が少し曖昧になります。
別の重要な特徴は、真のRBACモデルが相互に排他的な役割の概念を提供できることです。対照的に、IDベースのグループは加算的です。プリンシパルのIDは、グループの合計（または接続詞）です。
真のRBACベースのセキュリティモデルのもう1つの特徴は、特定のロール用に作成された要素は、通常、そのロールの下で行動しない人が一時的にアクセスできないことです。
一方、随意アクセス制御（DAC）モデル（Unixのデフォルトモデル）では、グループだけではそのタイプの保証を得ることはできません。ところで、これはグループやUnixの制限ではなく、IDに基づく（そして一時的にIDベースのグループの）DACモデルの制限です。
それが役に立てば幸い。
=======================
サイモンの好評の応答を見た後、さらに追加します。ロールは、権限の管理に役立ちます。グループは、オブジェクトとサブジェクトの管理に役立ちます。さらに、役割を「コンテキスト」と考えることもできます。ロール「X」は、サブジェクトYがオブジェクトZにアクセスする（またはアクセスしない）方法を規定するセキュリティコンテキストを記述できます。
もう1つの重要な違い（または理想）は、アプリケーション、システム、またはOSに必要な、および/または明らかなロール、コンテキストを設計するロールエンジニアがいることです。ロールエンジニアは通常、ロール管理者（またはシステム管理者）でもあります（そうである必要はありません）。さらに、ロールエンジニアの真の役割（しゃれは意図されていません）は、管理ではなくセキュリティエンジニアリングの領域にあります。
これは、RBACによって公式化された新しいグループであり（たとえめったに使用されない場合でも）、通常はグループ対応システムには存在していません。
グループはユーザーを整理する手段ですが、通常、ロールは権利を整理する手段です。
これはいくつかの方法で役立ちます。たとえば、ロールにグループ化されたアクセス許可のセットは、グループのセット、またはグループとは無関係のユーザーのセットに割り当てることができます。
たとえば、CMSには、投稿の読み取り、投稿の作成、投稿の編集などの権限があります。編集者の役割は、読み取りと編集はできるが、作成はできない可能性があります（理由はわかりません！）。投稿は作成や閲覧などができる場合があります。マネージャーのグループには編集者の役割があり、マネージャーのグループに属さないITのユーザーには、他のユーザーが編集者の役割もありますグループはしません。
そのため、単純なシステムではグループとロールが密接に連携している場合が多くありますが、常にそうであるとは限りません。
ロールとグループの間にはセマンティックな違いがありますが（他の回答で前述）、技術的にはロールとグループは同じようです。ユーザーとグループにアクセス許可を直接割り当てることを妨げるものは何もありません（これはアクセス制御の微調整と見なすことができます）。同様に、ユーザーにロールが割り当てられている場合、ユーザーがグループのメンバーになるときと同じ意味で、ロールはロールメンバーと見なすことができます。
そのため、ロールとグループの間に実際の違いはありません。両方とも、ユーザーおよび/または権限をグループ化するために考慮することができます。したがって、違いはセマンティックのみです。—パーミッションのグループ化にセマンティックに使用される場合、ロールになります。 —ユーザーのグループ化に意味的に使用される場合、それはグループです。技術的には、違いはありません。
「グループ」はユーザーの集まりです。 「ロール」は、権限のコレクションです。つまり、グループアルファにグループベータが含まれる場合の場合、アルファはベータからすべてのユーザーを受け取り、ベータはアルファからすべての権限を受け取ります。逆に、ロールベータにはロールアルファが含まれると言うこともでき、同じ結論が当てはまります。
具体的な例は、物事をより明確にします。 「カスタマーサポート」と「シニアカスタマーサポート」を検討してください。これらのコレクションをグループと考えると、カスタマーサポートユーザーがシニアカスタマーサポートユーザーを「含む」ことは明らかです。ただし、それらをロールと見なすと、シニアカスタマーサポート権限がカスタマーサポート権限を「含む」ことは明らかです。
理論的には、単純に1つのコレクションタイプを持つことができます。ただし、「コレクションアルファにはコレクションベータが含まれる」と言うと曖昧になります。その場合、アルファ版のユーザーがベータ版（ロールなど）なのか、ベータ版のユーザーがアルファ版（グループなど）なのかわかりません。 「含む」などの用語やツリービューなどの視覚要素を明確にするために、ほとんどのrbacシステムでは、少なくとも議論のために、問題のコレクションが「グループ」か「ロール」かを指定する必要があります。
いくつかのanalogiesが役立つ場合があります。 集合論の観点から見れば、グループアルファがグループベータのサブセットである場合、権限アルファは権限ベータのスーパーセットです。 系図と比較すると、グループが子孫のツリーのようなものである場合、ロールは祖先のツリーのようなものです。
前の答えはすべて素晴らしいです。述べたように、グループとロールの概念は技術的というより概念的です。グループはユーザーを含むために使用されるというスタンスを取りました（ユーザーは複数のグループに属することができます。つまり、JoeはITグループ[彼はITマネージャー]だけでなくManagersグループにも属します）。 （つまり、当社のmagカードシステムでは、ITグループ内のすべてのユーザーがサーバールームにアクセスできます）。役割を使用して、特定のユーザーに特権を追加するようになりました（つまり、ITグループ内のユーザーはサーバーにRDPできますが、ユーザーの割り当てや権限の変更はできません。管理者ロールを持つITグループのユーザーはユーザーの割り当てと権限の変更ができます）。ロールは他のロールで構成することもできます（Joeにはユーザー/特権を追加するAdminロールがあり、サーバー上のDBMSにデータベース変更を行うDBAロールもあります）。ユーザーに非常に限定的な個々のユーザーロール（JoesRole）を作成できるという点で、ロールも非常に限定的です。要約すると、グループを使用してユーザーを管理し、一般的なロールとロールを割り当てて特権を管理します。これも累積的です。ユーザーが属しているグループには、非常に一般的な権限を与えるロール（または使用可能なロールのリスト）が割り当てられている場合があります（つまり、ITグループユーザーは、サーバーにログオンできるようにするServerRDPロールを持っています）。次に、ユーザーが属するロールは、最終決定権を持つ最後のロールで定義された順序で追加されます（ロールは特権を許可、拒否、または適用しないため、各ロールが適用されるたびに特権の以前の設定をオーバーライドしますまたは変更しないでください）。すべてのグループレベルのロールとユーザーレベルのロールが適用されると、システム全体でアクセスと機能を判断するために使用できるユーザー用の個別のセキュリティモデルが作成されます。
注-次のとりとめは、組織内でセキュリティを課そうとしている場合にのみ意味があります-つまり、情報へのアクセスを制限しようとしています...
グループは経験的であり、「何」の質問に答えます。それらは、アクセスの既存の現実を反映しているという意味で「あり」です。 ITの人々はグループを愛しています-彼らは非常に文字通りで定義しやすいです。最終的に、すべてのアクセス制御は最終的に（私たち全員が中学校で学んだように...）「あなたはどのグループに属しますか？」という質問に答えます。
ただし、ロールはより規範的です-それらは「あるべき」ものを導きます。良いマネージャーと人事は「役割」が大好きです-彼らは答えません-彼らは質問「なぜ？」の質問残念なことに、役割はあいまいである場合があり、その「あいまいさ」が人々の心を動かします（IT）。
上記の医療例を使用するには、「プライマリケア医」のroleが「X線技師のroleよりも多くの権利（つまり、より多くのグループへのアクセス）を持っている場合」 「これは、人々（マネージャーと人事）が理由を決定する必要があるためです。その意味で、彼らは組織の「集合的な知恵」です。
医師に患者の財務記録へのアクセス権（アクセス権を持つグループのメンバーシップ）が与えられたとします。これは通常、医師の「役割」の範囲外であり、はず議論されています。だから、誰も（どんなに資格があっても）すべてのグループにフルアクセスするべきではありません-それは権力への虐待を招きます。これが、「ロールエンジニアリング」が非常に重要である理由です-それなしでは、グループアクセスが非常に多くのキャンディーのように配られます。人々は、あまりにも多くの権力の危険性について議論することなく、グループへのアクセスを収集します（時には大群になります）。
最後に、明確に定義された役割の知恵は、暴走したグループアクセスの危険性を緩和するのに役立ちます。組織内のだれでも、特定のグループへのアクセスについて議論できます。しかし、いったんそのアクセスが提供されると、めったにgivenめられません。ロールエンジニアリング（明確に定義されたグループの説明や権限のあるグループアクセスマネージャーなどのベストプラクティスと共に）は、組織内の利益相反を制限し、意思決定を分散化し、セキュリティ管理をより合理的にするのに役立ちます。
ユーザーは、システムで果たす役割に基づいてロールに割り当てられます。たとえば、ロールSales Managerのユーザーは、製品に追加の割引を提供するなど、特定のアクションを実行できます。
グループは、システム内のユーザーまたはロールを「グループ化」して、セキュリティを簡単に管理するために使用されます。たとえば、「Leadership Group」という名前のグループには、ロールマネージャー、ディレクター、アーキテクト、およびこれらのロールからも外れている個々のユーザーのメンバーを含めることができます。これで、このグループに特定の特権を割り当てることができるはずです。
グループとロールの目的はアプリケーションによって異なりますが、主に理解しているのは次のとおりです。グループ（ユーザーのセット）は静的であり、ロール（アクセス権のセット）はポリシーで動的です、たとえば（9から6）までの時間に基づいてグループまたはユーザーはこの役割を持つことができますが、そうではありません。
グループにロールを割り当てることができます。ユーザーをグループに割り当てたり、任意の役割ユーザーの個々のユーザーに役割を割り当てたりできます。意味。 Jean Doeは、SharePointからレポートを印刷できるReportWritter以外のロールを持つSalesDeptartmentのグループに所属できますが、SalesDepartmentグループでは、ReportWritterのロールを持たない人もいます。 -言い換えると、ロールは割り当てられたグループに対する特別な特権です。これがどんなシーンにもなることを願っています。
乾杯！！！