Я согласен с другими участниками здесь, что модель контроля доступа была бы улучшена за счёт добавления дополнительного уровня детализации RBAC (управление доступом на основе ролей), который определял бы, к чему могут обращаться пользователи с ролями staff и admin (для определённых функций, а не для всех).
Например, сайт может захотеть добавить больше администраторов, но при этом предпочесть предоставить им более ограниченный набор привилегий RBAC; например, разрешить или запретить возможность скачивания полной резервной копии сайта или доступа к определённым файлам журналов действий сотрудников. Кроме того, сайт может захотеть гарантировать, что некоторые сотрудники не имеют прав RBAC для просмотра действий администраторов или разработчиков, или же только тех действий, которые считаются более «частными».
Всем специалистам по кибербезопасности преподают (и они знают из личного опыта), что наибольшую угрозу для любой организации представляет «недовольный инсайдер», а не внешние хакеры или злоумышленники. В этом базовом риске информационной безопасности нет никаких сомнений, и это хорошо установленный факт для подготовленных или опытных специалистов по ИБ. Поэтому отмахиваться от угрозы со стороны инсайдеров фразами «просто доверяйте администратору» или «вы должны доверять своим сотрудникам» — это не техническое решение для ИТ-специалистов. Даже самый надёжный сотрудник, работающий многие годы, может начать сталкиваться с жизненными проблемами, которые заставят его превратиться в «недовольного сотрудника». Кроме того, именно наиболее привилегированные сотрудники чаще всего совершают ошибки; и мы все хорошо знаем, что ошибки доброжелательных сотрудников или администраторов, как правило, приводят к простоям чаще, чем любые действия хакеров.
Некоторое время назад я рассматривал возможность изменения класса Guardian в Discourse для нашего сайта, но после дальнейшего изучения этого класса мне не стало очевидно, что существует «быстрое решение», позволившее бы мне написать минимальное количество кода патча (monkey patch) для улучшения RBAC в Discourse. Будучи по натуре ленивым и предпочитая создавать простые решения, когда это возможно, я отложил эту идею на потом и переключился на другие проекты для «хорошо оплачиваемых клиентов».
Позже я подумал о том, чтобы спуститься на уровень ниже в коде и перенести некоторые функции staff и admin в developer, но этот подход требовал слишком большого количества патчей (monkey patches), что, как мне показалось, не было хорошей идеей в тот момент. В конце концов, если мы можем достичь чего-то с помощью одного патча вместо десяти, очевидно, что один патч лучше.
У меня пока не нашлось времени или «острой необходимости» глубже изучить эту часть ядра Discourse, чтобы определить, существует ли «простое» расширение RBAC в виде плагина, которое я мог бы написать через «относительно простой» плагин.
Честно говоря, я думаю, что проблема в том, что я ещё не супер-рубист и в основном считаю себя скорее «wannabe»-кодером на Ruby, LOL. Я уверен, что скорее всего, существует простое решение в виде плагина для RBAC, но лично я его пока не нашёл, и, возможно, более опытный специалист по Ruby сможет быстро посмотреть на код и понять, как подойти к этой задаче.
Моя идея заключалась бы в добавлении новых булевых настроек сайта, которые бы ограничивали или предоставляли конкретные права RBAC в зависимости от роли, а затем добавлении этих булевых значений в соответствующую часть кода через патч (monkey patch) в плагине. Однако, как я уже упоминал, я предпочёл бы патчить один файл, а не «многие», чтобы это было чисто, просто и легко поддерживалось.
Когда у меня появится время, я займусь этим улучшением RBAC более глубоко, так как это, безусловно, интересно.