Concordo com os outros aqui de que o modelo de controle de acesso seria melhorado com uma camada extra de granularidade de RBAC (controle de acesso baseado em funções) que especifique o que staff e admin podem acessar (para certas funções, não todas).
Por exemplo, um site pode querer adicionar mais administradores; mas preferem conceder um conjunto menor de privilégios de RBAC para administradores; por exemplo, conceder ou não conceder a capacidade de fazer o download do backup completo do site ou acessar certos arquivos de log de ações da equipe. Além disso, um site pode querer garantir que alguns membros da equipe não tenham permissões de RBAC para visualizar as ações da equipe de administradores ou desenvolvedores, ou apenas certas ações que são consideradas mais “privadas”.
Todos os especialistas em cibersegurança são ensinados (e sabem pela experiência direta) que a maior ameaça a qualquer organização é o “insatisfeito interno” e não hackers ou atacantes externos. Não há dúvida sobre esse risco básico de segurança de TI, e é um conhecimento bem estabelecido para profissionais de segurança de TI treinados ou experientes. Portanto, descartar a ameaça interna com “apenas confie no seu administrador” ou “você deve confiar na sua equipe” não é uma solução técnica para profissionais de TI. Mesmo a equipe mais confiável, leal por muitos anos, pode começar a enfrentar problemas de vida que podem fazê-los se tornar um “membro da equipe insatisfeito”. Além disso, são os membros da equipe com mais privilégios que cometem mais erros; e todos sabemos que, em geral, erros bem-intencionados de equipe/administrador geralmente causam mais tempo de inatividade do que qualquer hacker.
Há algum tempo, considerei alterar a class Guardian do Discourse para o nosso site, mas após uma análise mais detalhada dessa classe, não foi óbvio para mim que havia uma “solução rápida” que me permitiria escrever uma quantidade mínima de código de monkey patch para melhorar o RBAC do Discourse. Sendo preguiçoso por natureza e preferindo criar soluções simples sempre que possível, deixei a ideia de lado e segui para outros projetos de “clientes bem remunerados”.
Subsequentemente, considerei descer um nível no código e transferir algumas das funções de staff e admin para developer, mas essa abordagem exigia muitos monkey patches, o que eu achei que não era uma boa ideia na época. Afinal, se podemos realizar algo com um monkey patch em vez de dez, obviamente um patch é melhor.
Ainda não tive tempo ou uma “necessidade urgente” para investigar mais profundamente essa parte do núcleo do Discourse e determinar se há uma melhoria de plugin de RBAC “fácil” que eu possa escrever por meio de um plugin “relativamente simples”.
Honestamente, acho que o problema é que ainda não sou um super rubyista e, na maior parte, me considero mais um “aspirante” a programador Ruby, LOL. Tenho certeza de que, muito provavelmente, existe uma solução simples de plugin de RBAC por aí, mas pessoalmente, ainda não a encontrei e talvez uma pessoa Ruby muito mais experiente possa olhar rapidamente para o código e ver como abordar isso.
Minha ideia seria ter algumas novas configurações de site booleanas que limitariam ou concederiam permissões específicas de RBAC com base na função e, em seguida, adicionar esses booleanos à parte apropriada do código por meio de um monkey patch no plugin. No entanto, como mencionei, prefiro corrigir um arquivo, não “muitos”, para que seja limpo e simples, fácil de manter.
Quando tiver tempo, investigarei mais essa melhoria de RBAC, pois é interessante, com certeza.