他の皆さんと同様に、アクセス制御モデルは、特定の機能（すべてではない）に対して staff や admin がアクセスできる範囲を指定する、より細かい粒度の RBAC（ロールベースアクセス制御）レイヤーを追加することで改善されると考えます。
例えば、サイト運営者がより多くの管理者を追加したい場合でも、管理者に付与する RBAC 権限の範囲を狭く設定したいと考えるかもしれません。具体的には、サイト全体のバックアップをダウンロードする権限や、特定のスタッフ行動ログファイルへのアクセス権を付与するか否かを選択できるようにするといった具合です。また、一部のスタッフに管理者や開発者の行動（あるいは「プライベート」と見なされる特定の行動）を閲覧する RBAC 権限を与えないようにしたいと考える場合もあるでしょう。
すべてのサイバーセキュリティの専門家は教育を通じて学び、直接的な経験からも知っています。組織に対する最大の脅威は外部のハッカーや攻撃者ではなく、「不満を持つ内部関係者」であるということです。この基本的な IT セキュリティリスクについては疑いの余地がなく、訓練された経験豊富な IT セキュリティ専門家にとっては確立された知識です。したがって、「管理者を信頼すればよい」「スタッフを信頼しなければならない」という理由だけで内部脅威を軽視することは、IT 専門家にとって技術的な解決策ではありません。何年も忠実に務めてきた最も信頼できるスタッフでさえ、人生の問題に直面した際に「不満を持つスタッフ」へと変化する可能性があります。さらに、最も特権的な権限を持つスタッフほどミスを犯す可能性が高く、一般的に言えば、善意のスタッフや管理者のミスによって発生するダウンタイムの方が、ハッカーによるものよりも多いことは周知の事実です。
以前、Discourse の class Guardian を当サイト用に修正することを検討しましたが、そのクラスをさらに詳しく調査した結果、Discourse の RBAC を強化するために最小限のモンキーパッチコードで済むような「簡単な修正」があるとは明確にはわかりませんでした。本質的に怠け者であり、可能であればシンプルな解決策を好むため、このアイデアは一旦保留にし、他の「報酬の高いクライアント」プロジェクトに進みました。
その後、コードのレベルを一段階下げて、staff や admin の一部の機能を developer に移管することを考えましたが、このアプローチには多くのモンキーパッチが必要となり、当時の私には良いアイデアとは思われませんでした。結局のところ、1 つのモンキーパッチで達成できることを 10 個のパッチで行う必要があるのであれば、明らかに 1 つの方が優れています。
Discore コアの一部をさらに深く調査し、「比較的単純な」プラグインを通じて作成可能な「簡単な」RBAC プラグイン拡張機能があるかどうかを判断する時間や「切実な要件」はまだ持っていません。
正直なところ、私がまだスーパーな Ruby 開発者ではなく、大部分を「Ruby コーダーの志願者」と考えていることが問題だと思っています（笑）。おそらく、シンプルで優れた RBAC プラグインの解決策がどこかに存在するとは確信していますが、個人的にはまだ見つけることができていません。もっと経験豊富な Ruby 開発者であれば、コードをすぐに確認して、どのようにアプローチすべきか分かるでしょう。
私のアイデアは、ロールに基づいて特定の RBAC 権限を制限または付与する新しいブール型のサイト設定を導入し、それらのブール値をプラグイン内のモンキーパッチを通じてコードの適切な部分に追加するというものです。ただし前述の通り、1 つのファイルのみをパッチし、「多数」のファイルをパッチするのではなく、クリーンでシンプルかつ保守が容易な方法を好みます。
時間ができたら、この RBAC 拡張機能についてさらに深く調査する予定です。確かに興味深いテーマですから。