I agree with others here that the access control model would be improved with an extra layer of RBAC (roles-based access control) granularity that specifies what staff and admin can access (for certain functions, not all).
For example, a site might want to add more admins; but they prefer to grant smaller set of admin RBAC privileges; for example, grant or not grant the ability to download the entire site backup or to access certain staff action log files. In addition, a site might want to insure that some staff do not have the RBAC permissions to view staff actions of admins or developers, or just certain actions which are considered more “private”.
All cybersecurity experts are taught (and know by direct experience) that the largest threat to any organization is the “disgruntled insider” and not outside hackers or attackers. There is no doubt about this basic IT security risk, and it is well established knowledge for trained or seasoned hands-on IT security professionals. Therefore, dismissing the insider threat with “just trust your admin” or “you must trust your staff” is not a technical solution, for IT professionals. Even the most trustworthy staff, loyal for many years, can start experiencing life problems which can cause them to shift to be a “disgruntled staff member”. In addition, it is the most privileged staff which make the most errors; and we all know that well-intended staff / admin mistakes generally cause more downtime than any hacker, generally speaking.
A while back, I considered altering Discourse class Guardian for our site but after further examination of that class it was not obvious to me there was a “quick fix” which would allow me to write a minimal amount of monkey patch code to enhance the RBAC for Discourse. Being lazy by nature and preferring to create simple solutions whenever possible, I put the idea on the back burner and moved on to other “well paid client” projects.
Subsequently, I considered going a level down in the code and transferring some of the staff and admin functions to developer, but this approach required too many monkey patches, which I thought was not a good idea at the time. After, all if we can accomplish something with one monkey patch versus ten, obviously one patch is better.
I have not yet had the time or a “burning requirement” to look deeper into this part of Discourse core to determine if there is an “easy” RBAC plugin enhancement I can write via a “relatively simple” plugin.
Honestly, I think the problem is that I am not yet a super rubyist and for the most part, consider myself more of a “wannabe” ruby coder, LOL. I am confident there is, more-than-likely, a simple RBAC plugin solution out there, but personally, I have not found it yet and perhaps a much more experienced Ruby person can quickly look at the code and see how to approach this.
My idea would be to have some new boolean site settings which would either limit or grant specific RBAC permissions based on role, and to then add those booleans to the appropriate part of the code via a monkey patch in plugin. However, I as mentioned, I would prefer to patch one file, not “many” so it is clean and simple, easy to maintain.
When I have time, I will look into this RBAC enhancement more deeper since it is interesting, for sure.