Controllo degli accessi basato sui ruoli + Permessi basati sulla proprietà dei dati

Questa è un'ottima domanda ed è stata identificata come uno dei problemi con RBAC. C'è stata una linea di ricerca sui ruoli parametrizzati (il pdf può essere trovato online) e più recentemente è emersa l'idea del controllo dell'accesso basato sulla relazione (vedi il lavoro di P. Fong et al, per esempio questo ). Non sono sicuro di quanto è stato implementato.

Potresti configurare un moderno prodotto Multi-Level Security (MLS) per risolvere il problema. Questi sistemi sono progettati per la protezione dei dati di livello militare su infrastrutture condivise. In genere, i sistemi utilizzano il controllo dell'accesso basato sui ruoli (RBAC), il controllo dell'accesso discrezionale (DAC) e il controllo dell'accesso obbligatorio (MAC) basato sulle etichette di sicurezza.

Le etichette di sicurezza indirizzano il tuo elemento mancante. In un sistema MLS tutti gli oggetti hanno un'etichetta per includere sia dati che processi. Le etichette forniscono lo schema per rivolgersi al medico e alla situazione specifica del gruppo.

Ecco una configurazione di esempio. Il set di etichette principali (noto come codifiche di sistema) include uno schema di etichetta che include gruppi individuali per tutti i gruppi di medici in questione. L'applicazione utilizzata da tutti i medici potrebbe essere limitata dal controllo RBAC che hai menzionato. Ogni medico avrebbe anche la propria etichetta di sicurezza unica nel proprio profilo account e quindi sarebbe solo in grado di accedere ai dati definiti da tale etichetta.

La configurazione iniziale è pesante, ma nel tuo caso hai a disposizione moltissime altre funzionalità come il controllo della stampa di documenti su quale stampante (i limiti hardware sono pensati come i limiti del gruppo medico).

La pagina di Wikipedia per MLS fornisce i fornitori (quando non è in blackout SOPA). Il prodotto Oracle Extensions Trusted ha alcuni buoni esempi di casi di utilizzo commerciale online sulla falsariga della tua domanda.

Esiste un modello simile utilizzato da Exchange 2010; dove il modello di accesso è limitato usando la proprietà "Ambito" che si applica al livello Binding. In questa implementazione, Scope è la "relazione" tra l'utente autenticato e l'unità organizzativa in cui si trova il "paziente".

Exchange 2010 ha un modello di delega in cui gruppi di winrm I cmdlet di PowerShell sono raggruppati in modo essenziale in ruoli e i ruoli assegnati a un utente.

( Fonte immagine )

Questo è un ottimo & modello flessibile considerando come sfruttare tutti i vantaggi di PowerShell, utilizzando al contempo le tecnologie di basso livello (WCF, SOAP ecc.) e non richiedendo software aggiuntivo sul lato client.

( Fonte immagine )

Si tratta di una progettazione di applicazioni molto moderna, e sto cercando di imitarla da sola. Ho una domanda simile su StackOverflow qui

Mi rendo conto che questa domanda ha quasi 4 anni. Le risposte, in particolare quella data da userxxxxx, sono grandiose.

Da allora, un nuovo paradigma del controllo degli accessi è maturato e affronta le carenze dell'RBAC. Si chiama controllo degli accessi basato sugli attributi (ABAC) e consente di esprimere relazioni utilizzando questi attributi all'interno delle politiche. Il linguaggio della politica è basato su uno standard chiamato XACML (eXtensible Access Control Markup Language).

Se rivisitiamo lo scenario dell'OP

Bob is a doctor and has the role with the privilege 'view, patient details'

Bob is a member of group 'A'.

Bob can view all patient details for patients assigned to group 'A'

Il modo in cui questo sarebbe stato riscritto in ABAC è:

A user with the role == doctor can do the action == view on an object of type == patient details if the patient's assigned group is in the list of the doctor's groups.

Usando ALFA come notazione, ottieni

namespace healthcare{
    policyset viewMedicalRecords{
        target clause actionId == "view" and object.nature == "patient details"
        apply firstApplicable       
        policy doctors{
            target clause user.role=="doctor"
            apply firstApplicable
            rule allowSameGroup{
                permit
                condition patient.group == doctor.group
            }
        }       
    }
}

Puoi leggere di più su ABAC sul sito web del NIST (National Institute of Science & Tech). Sono quelli che hanno anche definito RBAC.