Diritti degli utenti in un server web, CRUD è troppo granulare

0

Nel nostro sistema di gestione dei diritti degli utenti seguiamo fondamentalmente "CRUD", dove ad ogni richiesta in entrata l'utente viene controllato contro i suoi diritti, e vede se ha creato, letto l'aggiornamento o distrugge i diritti per i dati a cui desidera accedere.

Questo sistema è stato creato dal mio predecessore, tuttavia sono costantemente in dubbio se questo è il sistema giusto da usare. Diciamo che ho un utente "admin", che è sotto il "rootadmin" - gli amministratori possono modificare gli account ma non il server stesso. Rootadmin potrebbe fare qualsiasi cosa, incluso il ripristino dell'intero server e altre cose divertenti.

Tuttavia, poiché può modificare gli account utente, dispone dell'accesso UPDATE sul "campo ruolo" di un utente e può aggiornare qualsiasi utente a qualsiasi livello, incluso "rootadmin". Quindi sembra semplice CRUD non è sufficiente.

Un altro esempio (per chiarire che questo è un caso che non è univoco per i privilegi rootadmin):

Ai dipendenti viene concesso il diritto di aggiornare lo stato di produzione di "articoli". Tuttavia, ogni dipendente lavora solo in una parte della società: quindi non dovrebbe avere il diritto di aggiornare (o leggere) articoli che si trovano al di fuori della sua linea di produzione.

Esiste un metodo ben noto per gestire i diritti degli utenti, in un sistema generalizzato? O ognuno ha la propria implementazione per ogni applicazione una nuova serie di regole?

La mia unica soluzione fino ad ora è quella di memorizzare "lambda" nel database, dove insieme alla destra c'è una "limitazione". Quindi leggerebbe: "l'utente X ha ragione Y (aggiorna il campo A in B) ma solo se lambda Z è restituito vero.

Tuttavia, ciò renderebbe il database realmente dipendente dalla lingua e memorizzerebbe codice non elaborato sul database. Oppure si dovrebbe scrivere un altro livello per interpretare una sorta di dsl.

    
posta paul23 19.04.2018 - 11:44
fonte

2 risposte

1

Non è chiaro dalla domanda se gli utenti hanno accesso diretto al db o se provengono solo dall'applicazione che sta facendo uso del db. Come già detto da Robert, puoi fare cose nel livello db per controllare le autorizzazioni tramite le viste ecc.

Un'altra opzione, a seconda di dove nel sistema si ha accesso al codice, è più semplice, per te è aggiungere un modello di repository tra l'accesso al database e il resto del codice sopra il livello db. Potresti quindi creare un sistema per generare oggetti di accesso ai dati personalizzati che applichino le autorizzazioni concesse all'utente ovvero: imposta tutti i campi su null / nessuna modifica che l'utente non ha il permesso di modificare / leggere ecc mentre i dati passano tra la vista e il modello.

Il vantaggio di ciò è il tuo permesso / sistema di sicurezza diventa testabile senza la necessità di un database. Puoi prendere in giro tutti i tipi di ruoli strani con permessi diversi e confermare se un utente con quel ruolo ha accesso a fare le cose come previsto senza dover toccare il database.

    
risposta data 19.04.2018 - 21:55
fonte
0

Ovunque tu dica di aver bisogno di lambda, puoi sempre cooptare il database per fare il lavoro per te. Ad esempio, i Project Manager normalmente hanno accesso solo ai progetti che stanno gestendo. Questa è semplicemente una clausola WHERE con due condizioni.

Per sicurezza a livello di colonna, usa meglio Views. Le viste possono essere utilizzate in combinazione con i meccanismi di SQL Server e Oracle per applicare la sicurezza a livello di colonna.

Ulteriori letture
Filtraggio delle colonne di SQL Server utilizzando le autorizzazioni a livello di colonna
colonna di SQL Server livello di sicurezza

    
risposta data 19.04.2018 - 18:21
fonte

Leggi altre domande sui tag