Come assegnare i diritti a un amministratore di sistema in un'applicazione?

Question

Come assegnare i diritti a un amministratore di sistema in un'applicazione?

#1 da (3 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (1 voti)

4

Sto progettando un modello di sicurezza per un'applicazione web che limita l'accesso a determinate parti dell'app a seconda dei diritti e delle autorizzazioni dell'utente. Questi diritti e permessi sono raggruppati in ruoli a cui ogni utente può essere assegnato.

Tuttavia, ho bisogno di creare un ruolo di amministratore di sistema che dia ad un utente speciale pieno accesso a tutto. Per affrontarlo, posso affrontarlo in due modi:

Crea un ruolo di amministratore di sistema e dargli ogni singolo permesso / diritto nel sistema (in pratica tutti i diritti sono memorizzati in una tabella DB). Mentre l'applicazione si evolve e diventa più grande, il Anche il ruolo di amministratore deve essere aggiornato in modo che possa accedere a cose nuove.
All'interno dell'applicazione stessa, autorizzo il sistema Ruolo dell'amministratore per aggirare le restrizioni di sicurezza. Quindi essenzialmente controllerà se l'utente ha una certa autorizzazione, o se è a Amministratore di sistema, li lascerà passare.

L'opzione 1 presenta alcuni problemi: potrebbe essere noioso e soggetto a supervisione perché ogni area dell'applicazione ha Crea, Leggi, Aggiorna, Scrivi e molte altre autorizzazioni. Devo includere tutte le possibili combinazioni di aree applicative in permessi in una tabella per consentire al ruolo di avere accesso completo.

L'opzione 2 presenta i propri problemi: il bypass dell'amministratore di sistema è codificato in ogni singola area in cui è necessaria una restrizione. Se il nome del ruolo di amministratore di sistema dovesse cambiare (ad esempio Utente principale), dovrei aggiornare il codice ovunque. Tuttavia, questa opzione significa che non devo preoccuparmi di aggiornare costantemente la tabella dei ruoli in modo che l'amministratore di sistema ottenga l'autorizzazione ad accedere a nuovi elementi.

Sto costruendo un software di classe enterprise, quindi deve essere scalabile a prescindere dall'opzione che scelgo.

Sì, lo so che è molto soggettivo se viene trattato allo stesso modo. Ma credo che ci sia un modello di progettazione di sicurezza di buona pratica in cui un modo è consigliato rispetto all'altro. Ci sono cose che non posso prevedere in questo momento che altri potrebbero aver incontrato. Potrei anche apprezzare alcuni link a pensieri su questo e buon modo per andare avanti.

permissions user-management

posta volume one 03.06.2015 - 19:29

fonte

4 risposte

Leggi altre domande sui tag permissions user-management

È possibile decifrare l'hash con sale conosciuto? Se sì come? Vantaggi di REJECT over DROP su un singolo PC

score 3 · Answer 1

Che ne dici di scartare l'autorizzazione per una singola funzione che prende tutte le decisioni di sicurezza. Le chiamate sarebbero qualcosa come isAccessAllowed(user, FOO_OPERATION, <misc data>) . Quindi il tuo controllo amministratore è un singolo condizionale all'inizio della funzione isAccessAllowed .

L'implementazione di un tale sistema consente anche di modificare i backend di sicurezza senza dover riscrivere l'applicazione. Fa anche un buon lavoro nel separare il codice di sicurezza dal codice dell'applicazione.

score 1 · Answer 2

Penso che entrambe le due opzioni siano un buon modo per andare. Tuttavia, penso che consideri questo problema il lato sbagliato. I due inconvenienti che hai citato per voi due problemi possono essere facilmente superati:

Per la prima opzione: se consideri di assegnare tutti i diritti al ruolo di amministratore di sistema e hai paura delle combinazioni, allora suppongo che tu possa semplicemente eseguire un doppio test con due cicli, ad es. (codice pseudo-mushy all'interno): if($role == "Administrator") { for($i in $rights_array) { $area[$i] = true; }}

So che questo codice è piuttosto ridicolo per il momento, ma spiega molto bene quello che cerco di dire: non è necessario implementare manualmente ogni singola combinazione possibile (area, diritti). Una volta definite le aree e i diritti separatamente nel database, è possibile impostare dinamicamente i valori della combinazione nelle variabili.

Se vuoi davvero memorizzare le tue "combinazioni di diritti" in un database, puoi gestirlo automaticamente allo stesso modo dello pseudo-codice che ho dato in precedenza. Ho già codificato le modifiche alle voci della tabella dinamica al lavoro per gestire il caso in cui l'applicazione si evolve in un livello superiore rispetto al database.

Per la seconda domanda, perché non aggiungere una colonna id nella tabella dei ruoli? Una colonna per l'id e una colonna per il nome. Quindi tutto quello che devi fare è modificare il nome se succede che è veramente necessario. E quando devi controllare il tuo ruolo, devi solo interrogare l'id invece del nome, che consente la modifica del nome senza introdurre incoerenze.

I miei 0,002 centesimi: -)

score 1 · Answer 3

Non puoi avere qualcosa come un trigger nel DB della tabella Role che assicura che le autorizzazioni SysAdmin necessarie vengano aggiunte automaticamente ogni volta che viene aggiunta una voce Crea, Leggi, Aggiorna, Scrivi? Ad esempio la tua Opzione 1, ma con l'automazione per assicurarti di non dover ricordare manualmente di aggiungere le autorizzazioni necessarie. Invece di un trigger, potresti anche avere una procedura fissa che funziona, ad esempio, ogni ora sul DB, assicurandoti che l'utente SysAdmin abbia tutte le autorizzazioni?

score 1 · Answer 4

Quello che di solito faccio nel tuo scenario (forse lo chiameremo opzione 3), è dare al ruolo sysadmin l'accesso SOLO alle parti del sistema che sono specifiche per quel ruolo. Non controllare il ruolo di sysadmin da nessun'altra parte. Quindi, se si desidera che un determinato utente abbia accesso all'intero sistema, fornire a tale persona tutti i ruoli necessari per l'accesso completo. I vantaggi di questo sono: non ci sono aggiornamenti noiosi da fare ogni volta che aggiungi una nuova funzione, non devi controllare più ruoli in più posti e se decidi di dare a qualcuno l'accesso solo alle parti di sysadmin senza resto del sito, puoi.

Ad esempio, supponi di avere 4 diverse sezioni del sito:

Sezione Accountant: crea un ruolo chiamato Accountant che può accedere a questa sezione.
Sezione Executive: crea un ruolo chiamato Executive che può accedere a questa sezione.
Sezione Employee: crea un ruolo chiamato Employee che può accedere a questa sezione.
Sezione Amministrazione del sistema - crea un ruolo chiamato SysAdmin che può accedere a questa sezione.

Ora, a ogni persona vengono assegnati 1-4 ruoli in base alle parti del sito a cui è consentito l'accesso. Nel tuo caso alla persona che agisce come "amministratore di sistema" verrebbero assegnati tutti e 4 i ruoli, in modo che possano accedere a qualsiasi cosa sul sito.

Questo metodo consente il massimo controllo su chi può accedere a quali sezioni e non è necessario modificare alcun codice esistente quando si aggiungono nuovi ruoli o sezioni al sito.