Complesso Righty System: ACL, RBAC e altro ancora?

Question

Attualmente stiamo sviluppando un software per la gestione dei progetti. E abbiamo difficoltà a decidere l'approccio corretto per implementare la sicurezza. Abbiamo esaminato sia ACL che RBAC e siamo già abbastanza sicuri che abbiamo bisogno di almeno una combinazione di entrambi per motivi specifici. Ma ci sono un paio di problemi che non hanno una bella soluzione in entrambi i mondi. Mi spiego:

Diciamo di avere le seguenti entità:

1. utenti, con ruoli diversi, vale a dire
   • Project Lead
   • Worker
   • Admin
2. Progetti
3. utenti assegnati
4. Compiti nel progetto

Ora la seguente regola deve essere espresso: Un utente con il ruolo Worker è solo permesso di visualizzare Attività , che sono legati a un progetto a cui è assegnato.

Il risultato è che un utente è consentito solo per vedere alcuni Compiti in tutta la lista.

Vorremmo utilizzare RBAC per dare ruoli il permesso di leggere in realtà Attività. Ma la condizione non viene applicata in quanto vi sono entità specifiche coinvolte. ACL potrebbe essere utilizzato, ma temiamo l'incubo di mantenere l'ACL voci consitent ai requisiti (Utenti può cambiare, Ruoli può cambiare, nuovi Compiti può essere introdotta una avrebbe dovuto ottenere le voci corrette, che è altrettanto complesso).

Naturalmente ci potrebbero essere domande specifiche durante la visualizzazione di un progetto specifico (WHERE project_id = 123), ma questo non aiuta per una "Veduta di tutti i miei attuali Tasks", dove praticamente ogni attività può essere considerato per la visualizzazione, ma la ACL dovrebbe essere controllato per ogni singolo ingresso.

E come faccio a garantire cose come "Ottieni i primi 25 compiti che l'utente corrente è autorizzato a vedere" senza caricare tutte le attività dal DB e quindi filtrare in base all'ACL, ovvero la gestione dell'impaginazione.

Answer 1

Bene, io uso Yii framework con il suo bel livello RBAC. Non ho molta familiarità con gli ACL, né ho avuto bisogno di esserlo, ultimamente.

In termini di termini RBAC Yii, la chiave della soluzione è l'utilizzo di "regole aziendali". I Bizrules sono piccoli frammenti di codice che sono allegati a un "permesso" o un "ruolo" (un 'elemento auth' nei termini di Yii). Questo codice viene eseguito dinamicamente quando è necessario determinare l'accesso a un determinato "permesso" (diciamo, ma potrebbe anche essere associato a un "ruolo") e riceve l'elemento in questione (attività nel tuo esempio) e determinare l'effettivo accesso all'attività specifica o meno. Ecco un esempio più dettagliato:

• dicono è necessario disporre delle seguenti autorizzazioni:
  • Modifica compito (che dovrebbe essere consentito a tutti coloro che con l' 'amministratore di compiti' di ruolo)
  • Modifica propri compiti (che dovrebbe essere consentito alla persona che ha inviato questa attività).
• Ora, nella sezione del codice 'modifica attività', è necessario prima controllare l'autorizzazione 'modifica attività'. se ok, consenti.
• se non è stato consentito, verificare anche 'Modifica attività propria' (utilizzando il costrutto else-if). Ora sull'ultimo permesso menzionato dovrebbe essere allegato un bizrule (= codice php) che accetta un oggetto 'compito' e confronta il suo 'id creatore' con l''id utente attualmente selezionato'. Se uguale, restituisce true, il che significa che l'accesso dovrebbe essere concesso.

In poche parole. Se ti interessa di più, vedi this section della guida ufficiale. Ci sono anche un sacco di altre risorse, se necessario.

Answer 2

È necessario guardare oltre ACL e RBAC e considerare il controllo degli accessi basato sugli attributi (ABAC - vedere la guida NIST here). Gartner chiama questo spazio "gestione di autorizzazione esternalizzata".

Con ABAC, puoi facilmente esprimere qualsiasi regola che tenga conto non solo di chi è l'utente, ma anche di ciò che l'utente vuole fare, dove, quando, perché e come. Utilizzando gli attributi per definire l'autorizzazione, è possibile utilizzare XACML per implementare le politiche. XACML è uno standard OASIS (proprio come SAML).

Con XACML, ottieni un'API in cui puoi porre domande ad esempio Alice può visualizzare questo record? Ma nel tuo caso, non è sufficiente perché vuoi filtrare i record dal database. E, come descrivi, vuoi che la query sia giusta fin dall'inizio piuttosto che andare avanti e indietro nel database finché non hai il numero giusto di record autorizzati. È qui che XACML diventa particolarmente interessante perché neutro dal punto di vista tecnologico. Puoi applicare XACML a Java, C# e altre lingue, ad es. Python ma applica anche XACML a diversi livelli (database di presentazione, API e ...). XACML può essere interrogato in modo query inversa per la produzione di un'istruzione SQL che è possibile utilizzare per interrogare il database back-end per i registri:

• record che può osservare Alice?
• Alice può visualizzare i record in California che produce "SELECT * FROM record in cui posizione = 'CA'"

HTH