Concordo con gli altri: il modello di controllo degli accessi sarebbe migliorato con un ulteriore livello di granularità RBAC (controllo degli accessi basato sui ruoli) che specifichi cosa possono accedere gli utenti staff e admin (per certe funzioni, non per tutte).
Ad esempio, un sito potrebbe voler aggiungere più amministratori, ma preferisce concedere un insieme più ristretto di privilegi RBAC agli amministratori; ad esempio, concedere o meno la possibilità di scaricare l’intero backup del sito o di accedere a determinati file di log delle azioni dello staff. Inoltre, un sito potrebbe voler garantire che alcuni membri dello staff non abbiano i permessi RBAC per visualizzare le azioni degli amministratori o degli sviluppatori, o solo determinate azioni considerate più “private”.
Tutti gli esperti di cybersecurity vengono istruiti (e lo sanno per esperienza diretta) che la minaccia più grande per qualsiasi organizzazione è l’“insoddisfatto interno” e non gli hacker o gli attaccanti esterni. Non c’è alcun dubbio su questo rischio di base della sicurezza IT, ed è una conoscenza consolidata per i professionisti della sicurezza IT formati o esperti. Pertanto, liquidare la minaccia interna con frasi come “basta fidarsi dell’amministratore” o “devi fidarti dello staff” non è una soluzione tecnica per i professionisti IT. Anche lo staff più affidabile, leale per molti anni, può iniziare ad affrontare problemi personali che potrebbero trasformarlo in un “membro dello staff insoddisfatto”. Inoltre, sono proprio gli staff più privilegiati a commettere la maggior parte degli errori; e sappiamo tutti che, in generale, gli errori benintenzionati di staff o amministratori causano più tempi di inattività di qualsiasi hacker.
Qualche tempo fa, ho considerato di modificare la classe Guardian di Discourse per il nostro sito, ma dopo un’ulteriore analisi di quella classe non mi è risultato ovvio che ci fosse una “soluzione rapida” che mi permettesse di scrivere una quantità minima di codice di monkey patch per migliorare l’RBAC di Discourse. Essendo per natura pigro e preferendo creare soluzioni semplici quando possibile, ho rimandato l’idea e mi sono dedicato ad altri progetti “ben retribuiti per i clienti”.
Successivamente, ho considerato di scendere di un livello nel codice e trasferire alcune delle funzioni staff e admin a developer, ma questo approccio richiedeva troppi monkey patch, cosa che ritenevo non fosse una buona idea al momento. Dopo tutto, se possiamo ottenere qualcosa con un solo monkey patch invece di dieci, è ovvio che un patch è meglio.
Non ho ancora avuto il tempo o un “requisito urgente” per approfondire questa parte del core di Discourse per determinare se esiste un potenziamento “semplice” sotto forma di plugin RBAC che possa scrivere tramite un plugin “relativamente semplice”.
Onestamente, penso che il problema sia che non sono ancora un super rubyista e, per la maggior parte, mi considero più un “aspirante” programmatore Ruby, LOL. Sono sicuro che esista, molto probabilmente, una semplice soluzione di plugin RBAC là fuori, ma personalmente non l’ho ancora trovata e forse una persona Ruby molto più esperta può guardare rapidamente il codice e vedere come affrontare la questione.
La mia idea sarebbe quella di avere alcune nuove impostazioni booleane del sito che limitino o concedano specifici permessi RBAC in base al ruolo, e poi aggiungere questi booleani alla parte appropriata del codice tramite un monkey patch nel plugin. Tuttavia, come ho già detto, preferirei patchare un solo file, non “molti”, in modo che sia pulito, semplice e facile da mantenere.
Quando avrò tempo, approfondirò questo potenziamento RBAC, poiché è sicuramente interessante.