Estoy de acuerdo con otros aquí en que el modelo de control de acceso mejoraría con una capa adicional de granularidad RBAC (control de acceso basado en roles) que especifique qué pueden acceder staff y admin (para ciertas funciones, no para todas).
Por ejemplo, un sitio podría querer agregar más administradores; pero prefieren otorgar un conjunto más pequeño de privilegios RBAC de administrador; por ejemplo, otorgar o no otorgar la capacidad de descargar la copia de seguridad completa del sitio o acceder a ciertos archivos de registro de acciones del personal. Además, un sitio podría querer asegurarse de que algunos miembros del personal no tengan los permisos RBAC para ver las acciones del personal de administradores o desarrolladores, o solo ciertas acciones que se consideran más “privadas”.
A todos los expertos en ciberseguridad se les enseña (y lo saben por experiencia directa) que la mayor amenaza para cualquier organización es el “insatisfecho interno” y no los hackers o atacantes externos. No hay duda sobre este riesgo básico de seguridad de TI, y es conocimiento bien establecido para profesionales de seguridad de TI capacitados o con experiencia práctica. Por lo tanto, descartar la amenaza interna con “solo confía en tu administrador” o “debes confiar en tu personal” no es una solución técnica para los profesionales de TI. Incluso el personal más confiable, leal durante muchos años, puede comenzar a experimentar problemas de vida que pueden hacer que se conviertan en un “miembro del personal insatisfecho”. Además, es el personal más privilegiado el que comete más errores; y todos sabemos que, en general, los errores bien intencionados del personal/administrador causan más tiempo de inactividad que cualquier hacker.
Hace un tiempo, consideré modificar la clase Guardian de Discourse para nuestro sitio, pero tras examinar más a fondo esa clase, no me resultó obvio que existiera una “solución rápida” que me permitiera escribir una cantidad mínima de código de parche de mono para mejorar el RBAC de Discourse. Siendo perezoso por naturaleza y prefiriendo crear soluciones simples siempre que sea posible, dejé la idea en espera y pasé a otros proyectos de “clientes bien pagados”.
Posteriormente, consideré bajar un nivel en el código y transferir algunas de las funciones de staff y admin a developer, pero este enfoque requería demasiados parches de mono, lo que pensé que no era una buena idea en ese momento. Después de todo, si podemos lograr algo con un parche de mono en lugar de diez, obviamente un parche es mejor.
Aún no he tenido el tiempo ni una “necesidad urgente” para profundizar en esta parte del núcleo de Discourse y determinar si existe una mejora de plugin RBAC “fácil” que pueda escribir mediante un plugin “relativamente simple”.
Honestamente, creo que el problema es que aún no soy un super rubyista y, en su mayoría, me considero más un “aspirante” a programador en Ruby, LOL. Estoy seguro de que, muy probablemente, existe una solución simple de plugin RBAC por ahí, pero personalmente aún no la he encontrado y quizás una persona de Ruby mucho más experimentada pueda mirar rápidamente el código y ver cómo abordar esto.
Mi idea sería tener algunas nuevas configuraciones de sitio booleanas que limiten o otorguen permisos RBAC específicos según el rol, y luego agregar esos booleanos a la parte adecuada del código mediante un parche de mono en un plugin. Sin embargo, como mencioné, preferiría parchear un solo archivo, no “muchos”, para que sea limpio y simple, fácil de mantener.
Cuando tenga tiempo, investigaré más a fondo esta mejora de RBAC, ya que es interesante, sin duda.