Come implementare la libreria / servizio RBAC scalabile?

Question

Come implementare la libreria / servizio RBAC scalabile?

#1 da (0 voti)

0

Ho bisogno di progettare e implementare una libreria RBAC (controllo di accesso basato sui ruoli) per proteggere le chiamate RPC. Un ruolo è un elenco di verbi (metodi RPC). Uno dovrebbe essere in grado di associare un utente (o un gruppo di utenti) a un ruolo su una risorsa (o un gruppo di risorse). L'architettura deve essere ridimensionata a 10 ^ 8 utenti e 10 ^ 8 risorse.

Ho pensato di avere identificatori univoci int64 per utenti e risorse. Conserverei la gerarchia di gruppo, il binding dei ruoli e gli utenti e le risorse in un database SQL o NoSQL. Quindi userei Apache Spark per appiattire le tuple (utente, ruolo, risorsa) che conserverei in qualche posto in cui interrogherò velocemente, come ElasticSearch.

Sono abbastanza sicuro che questo design si riduca. Tuttavia, non è chiaro come gestirò le modifiche all'appartenenza al gruppo e il ruolo di unbinding.

Qualche suggerimento su come assicurarsi che le modifiche precedenti non lascino delle tuple persistenti (utente, ruolo, risorsa)?

nosql elasticsearch spark rbac

posta Igor Gatis 23.11.2018 - 17:49

fonte

1 risposta

Leggi altre domande sui tag nosql elasticsearch spark rbac

come modellare 2 oggetti che si riferiscono l'un l'altro nel DB Accelera il completamento del codice in QtCreator

score 0 · Answer 1

Un approccio che potreste vedere è che viene tracciata una chiara distinzione tra la fonte (coerente) di verità per tutte le assegnazioni di ruolo e il database (eventualmente consistente) che viene tipicamente interrogato. Quest'ultimo database si comporta più come una cache e le voci sono regolarmente scadute. La scadenza potrebbe essere forzata se un utente, un ruolo o una risorsa cambia, o le voci potrebbero avere un TTL, oppure potresti avere un processo in background che analizza la cache per vedere se è ancora aggiornato. Un tale design implica che i cambiamenti RBAC necessitino di un po 'di tempo prima che entrino in vigore, tipicamente nella scala da minuti a un'ora.

Se la tua fonte di verità è un database denormalizzato (o un database NoSQL) dovrai progettare attentamente il tuo sistema per eliminare le vecchie voci quando cambiano le assegnazioni RBAC. Rispetto ad una cache basata su TTL, questo ha una maggiore possibilità di errori di programmazione e le query necessarie per eliminare i vecchi dati potrebbero essere costose. Tuttavia, le modifiche saranno in grado di propagarsi più rapidamente.