Come implementare un modello di controllo dell'accesso basato sui ruoli ibrido?

0

Sto scrivendo un'applicazione web-form-frontend aziendale per uso interno. Ha il controllo di accesso diretto (DAC) mascherato da controllo di accesso basato sui ruoli (RBAC).

Per scopi di anonimizzazione, chiamiamo l'unità di informazioni principale memorizzata nella mia applicazione un documento, ei ruoli in azienda sono un capo, un grugnito e un dirigente di livello C. Ci sono anche Externals (ad esempio qualcuno che lavora per un nostro partner commerciale). La linea guida generale è che tutti, tranne gli esterni, dovrebbero essere in grado di leggere tutti i documenti, i dirigenti di livello C possono scrivere tutto, i Boss possono scrivere i documenti appartenenti al proprio dipartimento e Grunt può solo scrivere documenti assegnati personalmente a loro. Abbastanza standard finora.

Ma ciò che gli utenti effettivamente vogliono è che possono fare eccezioni arbitrarie a quanto sopra. Vogliono che a qualsiasi persona nel sistema possa essere concesso l'accesso in scrittura a qualsiasi documento e che a Externals possa essere concesso l'accesso in lettura a qualsiasi documento. (In realtà, è più complicato di così, con più ruoli e una granularità più fine delle autorizzazioni, inclusa la gestione di chi può propagare quale autorizzazione per gli altri, ma la descrizione precedente illustra abbastanza bene il nucleo del problema). Quindi quello che ho sono fondamentalmente permessi a livello personale, e i ruoli sono solo un modo conveniente di avere impostazioni predefinite per le autorizzazioni a livello personale quando un utente o un documento viene aggiunto al sistema, invece di avere qualcuno che riempie un intero riga o colonna in una matrice di controllo degli accessi a mano.

Ora ho già progettato una tabella delle autorizzazioni nel mio database, che ha FK utente, FK del documento e colonne per i diversi tipi di autorizzazioni. Quello che non sono sicuro è ciò che dovrei salvare sul tavolo.

  • Alternativa 1: salvataggio tutte le autorizzazioni in questa tabella (puro DAC) e il livello logico simula un RBAC. Per esempio. quando viene aggiunto un nuovo Boss, una riga per ogni Documento nel sistema viene aggiunta al DB, con le autorizzazioni di Lettura per tutti i documenti e Scrivi per i Documenti del suo dipartimento.
  • Alternativa 2: salvo le deviazioni dalle linee guida sul ruolo. Quindi, quando viene aggiunto un nuovo Boss, non viene scritto nulla nella tabella delle autorizzazioni. Ma quando un dirigente dà a un capo i diritti di scrivere su un documento da un dipartimento diverso, allora viene aggiunta una singola riga per riflettere quell'informazione.

Non sono sicuro di quale alternativa sarebbe meglio. Il primo sembra più vicino all'implementazione dei libri di testo e, se un principio lo ha trasformato in un libro di testo, di solito c'è una buona ragione per usarlo. Ma nel mio caso, danneggia anche il principio DRY - dopo tutto, se l'informazione che un exec di livello C può scrivere su Document X è derivabile dal suo ruolo, scrivere una riga con queste informazioni nel DB è ridondante.

Quali sono i vantaggi e gli svantaggi di ciascun approccio in termini di a) prestazioni dell'applicazione e b) complessità di implementazione? Quali grattacapi posso aspettarmi da ciascuno?

Ricorda che 1) Non ho intenzione di implementare un livello logico completo. L'intera applicazione è praticamente un comodo frontend CRUD per un database, quindi eseguirò query DB per ogni visualizzazione di pagina invece di tenere una raccolta di oggetti Document in memoria. (Conosco i vantaggi di un pattern MVC, ma è stato deciso che sarà eccessivo per questo progetto). 2) Sto programmando questo in ASP .NET 4.5, quindi più mi avvicino ai ruoli, più posso lasciare che il framework faccia il lavoro più pesante per me. 3) Ho pensato di implementare gruppi ortogonali ai ruoli per gestire l'accesso, ma nel mio caso non ha senso.

    
posta Rumi P. 17.01.2013 - 11:45
fonte

2 risposte

2

Autorizzazioni utente

Se disponi di informazioni complete sulle autorizzazioni per ogni voce utente nel tuo database, avresti il vantaggio della semplicità. Vuoi conoscere le autorizzazioni dell'utente X, caricare le autorizzazioni per l'utente X. Il vantaggio è nel lavoro che dovresti fare. È anche vero che userebbe più spazio per il database, ma considero uno svantaggio secondario che non vale la pena menzionare.

Se il tuo cliente era felice di microgestire le autorizzazioni di ogni singolo utente, questo è l'ideale. Tu stesso non devi gestire le autorizzazioni e, allo stesso tempo, permetti il pieno controllo al tuo cliente.

Il problema arriva quando il cliente inizia a lamentarsi di avere troppi utenti da cambiare. La soluzione sensata a questo punto è di dare agli utenti le autorizzazioni di gruppo, ma modificare il modello attuale per consentire ai gruppi è un po 'un incubo. Per non parlare del fatto che l'aggiornamento delle autorizzazioni di un gruppo significa l'aggiornamento in batch di tutti gli utenti con quel gruppo. Diventa rapidamente ingestibile e non esiste un modo semplice per cambiare il modello delle autorizzazioni.

Autorizzazioni di ruolo

Ti consiglierei di usare un sistema basato sui ruoli. Invece di mantenere tutte le autorizzazioni per ogni utente, avere un punto di record utente per un gruppo di autorizzazioni o NULL. Se è NULL, disporre di un gruppo di autorizzazioni predefinito (non cancellabile) che verrà ereditato da un utente se non ne viene specificato nessuno. I client modificano un gruppo di autorizzazioni direttamente (incluso il gruppo di autorizzazioni predefinito) o il gruppo di autorizzazioni a cui un utente punta, ma rimangono entità separate. In questo modo, hanno tutto il controllo individuale che avevano prima, creando gruppi di permessi per singoli utenti, se lo desiderano, ma possono anche creare permessi generali e semplicemente assegnargli degli utenti.

Si potrebbe sostenere che è più lento da caricare, ma se si fa un punto per memorizzare le autorizzazioni, sarà solo lento nel primo caricamento. L'unico vero svantaggio di questo approccio è che è un po 'più complicato da implementare rispetto al primo approccio, ma considerando i grattacapi che avresti cercato di implementare il secondo approccio dopo aver già usato il primo approccio, ne valeva la pena nel mio umile opinione.

    
risposta data 17.01.2013 - 15:18
fonte
2

Non dovresti implementare il tuo modello di autorizzazione ma piuttosto usare quelli esistenti, ad es. un'implementazione RBAC, controllo degli accessi basato sulle attestazioni o controllo degli accessi basato sugli attributi (ABAC).

Per quanto riguarda ABAC, esiste uno standard di autorizzazione che è possibile utilizzare per definire le politiche di autorizzazione. Questo standard è chiamato XACML, l'eXtensible Access Control Markup Language. Puoi leggere su entrambi gli argomenti qui:

XACML definisce un'architettura con la nozione di:

  • un punto di decisione politica (PDP),
  • un punto di applicazione della politica (PEP) e
  • un punto informazioni sulla politica (PIP).

Nel flusso tipico, il PEP protegge i tuoi dati / servizi / API. Il PEP invierà una richiesta di autorizzazione al PDP:

  • L'utente Alice può visualizzare il record n. 123?

Il PDP passerebbe al PIP per recuperare gli attributi mancanti, ad es. il ruolo e l'autorizzazione dell'utente, nonché gli attributi delle risorse, ad es. la sensibilità dei dati, una whitelist o una lista nera ... Sulla base delle nuove informazioni, il PDP può prendere una decisione: Permesso o Nega. L'accesso è consentito o bloccato.

Con XACML non c'è limite alla ricchezza delle politiche di autorizzazione. Lavoro per un'azienda, Axiomatics, che implementa XACML e le nostre soluzioni sono utilizzate nella produzione, nell'assistenza sanitaria, nel settore bancario per garantire l'accesso sicuro ai dati sensibili in modo dinamico (ad esempio, i gestori possono modificare i documenti di loro proprietà).

XACML consente l'autorizzazione esternalizzata gestita centralmente. Abilita anche ciò che mi piace chiamare qualsiasi autorizzazione di profondità, il che significa che puoi applicare XACML a web API, business logic, interfacce utente di presentazione e database.

HTH

    
risposta data 06.05.2014 - 16:27
fonte

Leggi altre domande sui tag