Come può un soggetto leggere e scrivere solo sui propri oggetti di proprietà?

Question

Come può un soggetto leggere e scrivere solo sui propri oggetti di proprietà?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (-1 voti)

4

Sembra che in RBAC, un Soggetto crei una Sessione con un ruolo / i attivo / i, questi ruoli vengono quindi usati per determinare quali permessi e azioni possono essere presi. Questo sembra andare bene per la maggior parte della nostra organizzazione fino a raggiungere Soggetti con il ruolo del cliente. I clienti dovrebbero essere in grado di leggere solo le cose che possiedono, al contrario di altri ruoli che avrebbero letto / scritto (o qualsiasi altra cosa) su cose dello stesso tipo.

Non sono sicuro del modo migliore per implementarlo utilizzando RBAC. La sessione dovrebbe contenere anche l'oggetto? Alcuni riferimenti suggeriscono no.

Nota: è possibile che io sia troppo purista, ma sto controllando per vedere cosa mi manca. Ho considerato la rotta di PostgreSQL dove un utente è un ruolo, e quindi il ruolo attivo nella sessione è l'utente. Quali sono le opzioni per limitare un ruolo solo a visualizzare le cose non per tipo ma per proprietà?

authorization access-control rbac

posta xenoterracide 13.02.2013 - 05:10

fonte

4 risposte

Leggi altre domande sui tag authorization access-control rbac

La partizione nascosta di Truecrypt ha cancellato i dati originali dell'unità Qual è il modo più semplice per mantenere l'accesso degli utenti remoti a un'app Web

score 1 · Answer 1

Penso che questo possa essere implementato usando le funzionalità. Ogni soggetto ha una serie di coppie (o, r) dove o è l'oggetto e r sono i diritti. Ad esempio se Customer1 può leggere file1 e leggere-scrivere su file2, puoi avere un elenco di capacità come quello:

Customer1 = {(file1, {} lettura), (file2, {leggere, scrivere})}

Se molti clienti hanno gli stessi diritti, è possibile utilizzare i gruppi per limitare lo spazio di archiviazione utilizzato per salvare queste informazioni.

Ma devi essere sicuro che i soggetti non possono modificare l'elenco delle capacità.

score 0 · Answer 2

Bene, quello che puoi fare è definire un contenitore di qualche tipo; assegnare il sottoinsieme dei suoi oggetti diritti pari al livello di accesso / permesso del soggetto. Sembra banale, ma so che funziona. Può essere visualizzato sotto forma di matrice di controllo degli accessi un altro ruolo quando tenta di accedere all'oggetto di un altro livello di fiducia; richiederebbe un errore di autorizzazione.

Vedi questo link

o meglio utilizzare la matrice di controllo degli accessi in google

score 0 · Answer 3

Stai colpendo i limiti di RBAC. Oltre a considerare le funzionalità suggerite da Avraam Mavridis, prendere in considerazione l'utilizzo del controllo degli accessi basato sugli attributi ( ABAC ), che estende le possibilità di RBAC includendo attributi aggiuntivi (metadati) come attributi utente (posizione, autorizzazione, cittadinanza) e metadati delle risorse (classificazione, proprietà ...).

XACML è lo standard OASIS che implementa ABAC. Con XACML, puoi facilmente scrivere una regola di relazione che direbbe:

consente l'accesso a una risorsa solo se e solo se id del richiedente == id proprietario.

Ancora meglio, potresti riscrivere la regola in modo negativo poiché il proprietario potrebbe non essere sufficiente per accedere a una risorsa ma non essere il proprietario è sufficiente per negare l'accesso:

nega l'accesso a una risorsa se id del richiedente! = id proprietario

score -1 · Answer 4

Per coerenza all'interno di un sistema RBAC, tutte le risorse devono contenere informazioni sulla proprietà. L'oggetto Session Sate contiene solitamente informazioni utilizzate per imporre le regole di controllo degli accessi. Le sessioni vengono create (o modificate) in seguito all'autenticazione e alla deautenticazione. Le regole per chi è autorizzato ad autenticarsi e quali risorse hanno accesso sono controllate dal Super User. È logico pensare che tutte le sessioni possano essere modificate dal sistema solo in base alle intenzioni del Super User. Un utente normale non dovrebbe mai essere in grado di modificare lo stato della sessione e modificare la chiave primaria del proprio record utente.

Ora pensiamo a uno scenario. Un dipendente è attualmente connesso al sistema. Sono licenziati dalla direzione. Il Super User rimuove questo account, e il loro stato di sessione deve essere distrutto e i loro privilegi devono essere revocati immediatamente. Il Super User possiede l'oggetto sessione e lo distrugge su richiesta. L'utente non ha alcun controllo al momento del login, se ciò fosse vero potrebbe danneggiare altri dati di proprietà di tale account utente.