Quando leggo ACL e RBAC mi sembra di capirlo facilmente - ci sono nomi utente o ruoli a cui viene dato accesso a una risorsa. Posso anche vedere come ho potuto implementarli.

cioè questa immagine offre una chiara visione di ACL e RBAC per me (come posso andare avanti e progettare tabelle di database basate su sopra): (Immagine per gentile concessione di libri di stampa )

Quello con cui sto lottando è ABAC. Varie immagini che ho trovato finora sono ondulate a mano o eccessivamente complicate, o suggeriscono di utilizzare un'entità esterna di terze parti per l'autorizzazione. O dare strani esempi di attributi che non sono del tutto sicuro su come usare.

Esempio iniziale

Vorrei iniziare con qualcosa nella vita reale. Supponiamo di avere un'azienda con 70-200 persone. E la mia risorsa da proteggere è un sito Web con molte pagine diverse. Desidero consentire a determinate persone l'accesso a determinate risorse.

Ad esempio, desidero che una persona Leslieabbia accesso a una pagina Web chiamata Price Managere le consenta di gestire solo i prezzi per il Travelgruppo di prezzi su quella pagina, ma non sia in grado di gestire i prezzi per il Productgruppo sulla stessa pagina. Come implementerei questo usando ABAC?

Frugando finora, suppongo che potrei assegnare Lesliealcuni attributi (ma quali e quali sono questi attributi?) E quindi avere una tabella di database che li memorizza. Posso quindi progettare un motore che guardi quegli attributi (ma non guardi Lesliecome un "Ruolo" come è fatto in RBAC) e decido da lì se consentire o meno l'accesso alla pagina. Come sarebbe quel motore? È un semplice blocco if / else? Qualcos'altro?

Cosa succede se in seguito Leslie cambia posizione e qualcuno deve cambiare il suo accesso? Come sarà se ha bisogno di spostare Producte revocare l'accesso Travel? Come verrà codificato se ha bisogno di avere completamente revocato l'accesso alla Price Managerpagina e quindi non avere più accesso a nessuno dei due Travel, o Product?

La risorsa nel mio caso, solo per ribadirla, è Price Manager, e un utente può accedere a vari gruppi di prezzi su quella pagina, come Travelprezzi, Productprezzi, ecc.

Quello che sto cercando è una tabella di marcia ragionevolmente completa per chiarire i dettagli e per l'implementazione su dove potrei andare e implementarlo senza indovinare. cioè potrebbe essere completato concettualmente e / o avere un esempio specifico di dove posso visualizzare una struttura di database, ecc.

Bonus: ABAC è un modo adeguato per un'esigenza di autorizzazione relativamente piccola, vale a dire la gestione di 70-200 persone e l'accesso a circa 150-450 attività? Sarà meglio attenersi a ACL / RBAC invece?

Un'implementazione ABAC è più complessa di ACL / RBAC. Alcuni framework ti forniscono persino frammenti di infrastruttura per gestire questi ultimi. Se le persone e le risorse possono essere raggruppate in un numero relativamente piccolo e fisso di ruoli / categorie, probabilmente è meglio attenersi a ACL / RBAC. Se le autorizzazioni differiscono notevolmente da persona a persona, ABAC potrebbe fornire una soluzione migliore e più flessibile.

Se scegli di seguire il percorso ABAC, la prima cosa che devi fare è passare un po 'di tempo a leggere e comprendere lo standard XACML . Gli esempi forniti nel documento usano una sintassi compatibile con XACML e all'inizio sono un po 'difficili da masticare. Immagino che non desideri implementare una soluzione compatibile standard, quindi hai solo bisogno delle idee generali da essa.

concetti

XACML ruota attorno a 4 concetti e ai loro attributi: soggetti , azioni , risorse e ambiente . Ce ne sono alcuni altri, ma questi sono i più importanti. Tutto il resto è costruito su di essi. Se dovessi formulare una frase con questi concetti, potrebbe essere qualcosa del genere: i soggetti eseguono azioni sulle risorse in un determinato ambiente . Applicare questo al tuo scenario si tradurrebbe in qualcosa del tipo:

• Leslie apre la pagina Web del gestore prezzi.
• Leslie crea un prezzo di viaggio utilizzando la pagina Web del gestore prezzi.

Raccolta di attributi

La prima cosa che dobbiamo fare è raccogliere gli attributi rilevanti dei concetti di cui sopra. Idealmente, non dovresti assegnare alcun attributo specifico poiché XACML cerca di essere discreto e fare affidamento solo su ciò che il sistema fornisce naturalmente. E così abbiamo:

Soggetto

Qualsiasi attore, sia esso una persona o un servizio, nel tuo sistema. Il nostro argomento è Leslie. Quali attributi sono richiesti per identificare in modo univoco Leslie? Probabilmente alcuni dei seguenti: first name, last name, e-mail, ssn, company id, position(s).

Azione

Qualsiasi azione eseguita dai soggetti. Possono essere le operazioni CRUD standard o qualcosa di più complesso. Le nostre azioni sono open/viewe create. Gli attributi di queste azioni possono essere diversi in base al framework dell'applicazione Web in uso. Ne parleremo di più quando arriveremo alla risorsa.

Risorsa

Abbastanza esplicativo. Le nostre risorse sono price manager page, travel pricese the newly created price. Potrebbero essercene di più, se proprio lo desideri. Potresti voler nascondere azioni che gli utenti non possono eseguire. Per esempio. la create price buttonpuò essere una risorsa che può essere mostrata / nascosta in base se l'utente dispone delle autorizzazioni per creare i prezzi. Dal momento che l'unico modo per un utente di visualizzare un elenco di prezzi potrebbe essere attraverso questa pagina, probabilmente sarebbe una buona idea imporre l'autorizzazione a questo livello piuttosto che più in basso.

L'accesso alle risorse è il più complicato da implementare, specialmente su quelli che provengono da un database. L'opzione più fine è la sicurezza a livello di riga. Alcuni database hanno un certo grado di supporto per questo. Alcuni implementatori XACML sono arrivati ​​al punto di creare un superset SQL. Questo dipende davvero dalle tue esigenze di autorizzazione, ma l'unica cosa che non vuoi fare è estrarre tutto da un tavolo e quindi decidere cosa mostrare. È possibile raggruppare le risorse in base a set di autorizzazioni, sottrarle dietro un'API e applicare l'autorizzazione agli endpoint API.

Ambiente

Non riesco a definirlo correttamente (anche XACML non ha una definizione corretta) ma diciamo che è la "bolla" in cui tutto ciò accade. Questo comprende: web application, web server, operating system, browser, office. Si potrebbe estrarre gli attributi come: ip address, time of day, user locale, user agent, operating system version. Puoi usarli anche per bloccare l'accesso degli utenti da ambienti non supportati dalla tua applicazione (es. Vecchi browser, vecchi sistemi operativi, computer al di fuori della tua rete, accesso al di fuori dell'orario di lavoro).

Richiesta di autorizzazione

Dopo aver raccolto tutti gli attributi necessari, li raggruppiamo in una richiesta di autorizzazione e li inoltriamo a un'entità che può prendere decisioni di autorizzazione in base ai valori di questi attributi. Nella lingua XACML il luogo in cui si raccolgono questi attributi e si applicano le decisioni prese in seguito viene chiamato punto di applicazione delle politiche (PEP) e il punto di prendere decisioni viene chiamato punto di decisione delle politiche (PDP). Le posizioni da cui vengono ottenuti i valori degli attributi sono denominate punti di informazioni sulle politiche (PIP). PEP, PDP e PIP possono far parte della tua applicazione, possono essere sistemi esterni. Puoi trovare un diagramma di come comunicano tra loro nello standard XACML.

Processo decisionale

Il processo decisionale si basa su regole . Le regole possono essere raggruppate in politiche che possono essere ulteriormente raggruppate in serie di politiche . Ognuno di questi ha un obiettivo . L'obiettivo viene utilizzato per decidere se una delle regole si applica alla richiesta di autorizzazione. Pensalo come un filtro. La destinazione contiene condizioni create utilizzando nomi e valori di attributo. Ad esempio, le regole per la tua applicazione potrebbero essere raggruppate in qualcosa del tipo:

Applicazione Web (set di politiche)
| - target: application-name == "Applicazione Web"
`- Versione 1.0 (set di politiche)
    | - target: application-version == "1.0"
    `- Visualizza gestore prezzi (politica)
        | - target: web-page-name == "price manager" && action-name == "view"
        `- Leslie può visualizzare il gestore prezzi (regola)
            | - target: subject-name == "Leslie"
            `- permesso: consentire

Il PDP corrisponderà a tutto ciò che è impostato sopra con i valori degli attributi nella richiesta di autorizzazione. Cosa succede se non ci sono regole corrispondenti dipende dall'implementazione del tuo PDP. Una volta che il PDP ha preso una decisione ( allow, denyo not-applicable) lo invia indietro al PEP che agisce su di esso da concedere o negare l'accesso alla risorsa. Insieme alla risposta, il PDP può inviare un elenco di obligationse advicesche il PEP deve o deve soddisfare nel processo di applicazione. A seconda di come sono memorizzate le regole (file di testo o database), un amministratore può utilizzare un editor di testo standard o un'applicazione di modifica personalizzata per modificarle a suo piacimento. La revoca dell'accesso di Leslie al gestore dei prezzi riprende semplicemente cambiando l'autorizzazione da allowadeny, a condizione che il PEP faccia il suo lavoro.

Rinforzo

Questo dipende fortemente dal tuo stack tecnologico. Alcuni framework Web hanno punti di applicazione naturali (ad es. ASP.NET MVC ha filtri di attributi). I livelli aziendali potrebbero dover definire tali punti di applicazione. Ho trovato più semplice applicare l'applicazione a livello di servizio (pensa ai microservizi) o a livello di interfaccia utente.

Altri benefici

Un buon effetto collaterale dell'implementazione di questo è che si finisce con una pista di controllo abbastanza ricca che può essere utilizzata per altri scopi.