Sicurezza non basata sui ruoli?

Question

Questa è una domanda discutibile perché non sono più in questo progetto, ma continua a infastidirmi. Mi chiedo se qualcuno ha un'idea migliore per riferimento futuro e pratiche di programmazione generale.

L'approccio alla sicurezza da manuale è "sicurezza basata sui ruoli". Ogni schermata, report o altra attività è associata a uno o più ruoli; ogni utente è assegnato a uno o più ruoli; e quindi ogni utente può esercitare gli schermi, ecc. che corrispondono ai suoi ruoli e nient'altro. Destra?

Alcuni anni fa ho guidato un team per lo sviluppo di un sistema per la gestione di manuali tecnici militari. Ogni manuale aveva un "technical content manager", il responsabile della scrittura o della modifica; un "responsabile di magazzino", responsabile della registrazione delle copie e della loro spedizione; e un "manager amministrativo", responsabile del budget, che ha quindi deciso quanto spesso il libro sarebbe stato rivisto, quante copie sarebbero state stampate e così via. Ovviamente ogni libro aveva un gruppo di persone che ordinava copie e leggeva. (Dato che questo era l'esercito, dovevi essere autorizzato a mettere le mani su un libro, le autorizzazioni di sicurezza e tutto il resto.) Normalmente non ci preoccupavamo dei lettori attuali, ma piuttosto delle persone di ciascuna base che gestivano le biblioteche , ma non è davvero rilevante qui.

Quindi ... questi sono ovvi "ruoli", ma un ruolo era legato a un libro particolare. Una persona potrebbe essere il responsabile tecnico dei contenuti per il libro A, il responsabile amministrativo per il libro B e un lettore di 50 altri libri. Quindi non potevamo davvero dire che un utente avesse "un ruolo". Ogni utente aveva ruoli diversi per ogni libro.

Oltre a questo ci sono stati più privilegi a livello di sistema di routine: Abbiamo avuto un paio di amministratori di sistema autorizzato ad aggiornare nulla nel systeem, help desk persone che potevano vedere quasi tutti i dati, ma non si aggiorna, ecc

Ho finito per creare un database come questo. (Per evitare di entrare in alcuni dei nostri strana terminologia cambierò alcuni nomi di campo e di tabella qui, l'idea è la stessa.)

persona (person_id, nome, ecc)

Technical_Manual (manual_id, titolo, admin_manager_person_id, stock_manager_person_id, content_manager_person_id, ecc)

Authorized_Reader (manual_id, person_id, ecc)

utente (user_id, admin_role, ecc)

non ero davvero felice con questo schema, poiché significava che la sicurezza era suddivisa su tre tabelle: la tabella technical_manual, la tabella authorized_reader e la tabella utente. Ma ... c'era un modo più pulito in cui avremmo potuto farlo? Qualche idea migliore?

Answer 1

Il modo in cui ho fatto di recente qualcosa di vagamente simile a questo finisce per assomigliare:

Person (person_id, name, etc) 

Role (role_id, name [admin manager, stock manager, content manager, authorized reader, etc]) 

Technical_Manual (manual_id, title, etc) 

Technical_Manual_Role (manual_id, person_id, role_id) 

Inoltre, nel mio sistema, i ruoli sono fasci di autorizzazione per lo più solo di default, e le autorizzazioni degli utenti per azioni specifiche (Leggi , Modifica, Sposta, Elimina, ecc. Possono essere fatti variare in base alla linea di base per il loro ruolo.

Answer 2

So che questo può sembrare un po 'kludgy, ma si poteva fare qualcosa di simile:

Roles(role_id, etc)

Technical_Manual(manual_id, acceptable_roles, etc) dove acceptable_roles è un elenco delimitato

Poi, nel vostro programma, dividere l'elenco delimitato . Non sto dicendo che questo è il modo migliore, ma funzionerebbe. Anche se, non so se sarebbe il migliore per un'applicazione militare :)

Answer 3

Il problema con l'inserimento forzato di tutti nel modello di "ruoli" sono la logistica/volumi/carico di lavoro per mantenere il set completo delle regole di sicurezza nel caso in cui tali regole siano molto "a grana fine".

Per grana fine, intendo il caso in cui vi sono molti potenziali fattori discriminanti in ogni decisione di autorizzazione e per ogni fattore discriminante (diciamo "importo del credito richiesto dal cliente"), esiste un gamma potenzialmente ampia di "valori" (diciamo, ci sono 25 intervalli distinti di credito-importo-applicato-per).

Dire che ci sono tre fattori discriminanti, ciascuno con un intervallo di sette valori possibili (7 intervalli distinti di importo del credito). Quindi dovresti definire 7 * 7 * 7 = 343 ruoli. Quindi, per ogni singolo utente del sistema, è necessario assegnare il sottoinsieme completo di tutti i ruoli che quell'utente può eseguire. Se un utente è autorizzato a decidere su una richiesta di credito di 50.000.000, allora è molto probabile (ma poi di nuovo, non assolutamente certo!) Che è anche autorizzato a decidere su una domanda di credito di 5.000.000.

Ecco perché nel mio progetto i servizi relativi alla sicurezza sono limitati all'identificazione (userid) e all'autenticazione (usercertificate). Non ci sono disposizioni per l'autorizzazione. Questi devono essere indirizzati attraverso vincoli definiti dall'utente.

Answer 4

È possibile adottare un approccio più basato sulle attestazioni all'autorizzazione.

potrebbero esserci alcune autorizzazioni generali che ciascun utente può o non può avere (cioè l'amministratore) che potrebbe essere direttamente collegato a un ruolo. e useremmo la tua tabella per abbinare un particolare utente a cui le pubblicazioni hanno diritti avanzati e creare rivendicazioni per quelle voci.

così quando viene richiesta l'autorizzazione di un utente, si ottiene una raccolta di attestazioni, alcune di alto livello derivate da ruoli e alcune di pubblicazione specifiche, derivate dalle tabelle.

Answer 5

Commento sulla risposta del Chaos:

Mi viene da pensare che i ruoli "a livello di sistema" potrebbe andare bene lo stesso schema, se manual_id per queste cose potrebbero essere impostati su null o qualche valore magico. Sì, lo so, alcune persone hanno una forte avversione per i null, ma funziona qui. Poi ci sarebbe una sola tabella "roba di sicurezza", ed è tutto pulito.

Ho incontrato un sacco di problemi con i tre campi manager. Abbiamo avuto un numero di domande del tipo "Di quali libri è responsabile Bob?", Che richiedeva una query con un grande OR per andare contro tutti e tre i campi. Il che significava che avevamo bisogno di tre indici. In seguito mi resi conto che sarebbe stato meglio suddividerlo in un tavolo separato. Ma lanciando i lettori autorizzati nello stesso tavolo ... molte cose ripuliscono. Getta anche cose a livello di sistema e ... mi piace. Diventa facile chiedere "Quali diritti ha Mary Jones?" così come "Chi ha i diritti sul manuale dell'avionica F-15?", "Chi sono tutti i nostri gestori di contenuti tecnici?" eccetera.

Answer 6

Volevo solo aggiungere altro dal concetto di prospettiva. Anche se l'RBAC (controllo dell'accesso basato sui ruoli) sembra essere in voga, ci sono molti modelli come DAC, MAC che sono stati disponibili per risolvere il problema del controllo degli accessi per un periodo più lungo (il RBAC è stato effettivamente formalizzato intorno al 1995 mentre altri il modello è in circolazione da molto più tempo e utilizzato dai militari). Il modo in cui hai spiegato i requisiti vedo più modelli in uso

1. RBAC: viene utilizzato in caso di "ruoli di sistema" di cui hai parlato.
2. Controllo dell'accesso basato su criteri/attributi: viene utilizzato per tutti i pezzi relativi al manuale.
3. MAC: viene utilizzato per controllare l'accesso ai manuali alla base, ad esempio ogni manuale e utente ha un livello di sensibilità associato e devono corrispondere in base a criteri specifici per poter accedere.

Questi modelli possono essere espressi utilizzando standard come XACML (e valutati in fase di esecuzione utilizzando le implementazioni del motore di criteri) che possono descrivere la politica. Per esempio nel tuo caso la politica dovrebbe essere qualcosa lungo la linea di

(attributo basa)

Consenti "tutti" a "modifica" "manuale", se userid = manual.technical_content_manager

Consenti " tutti" a "nave" "manuale", se userid = manual.stock_manager

(RBAC)

Consenti "HelpDesk" a "vista" "info manuale", "manuale"

Consenti "Administrator" a "vista", "Modifica", "nave" "manuale"

(MAC)

Consenti "tutti" a "vista" "manuale" se userId.level> = manual.level

sulla base del modello di politica di cui sopra, è chiaro che è necessario tenere traccia user-ruolo mappatura che può essere fatta usando la tabella e recuperato in fase di runtime per alimentare il motore della politica in fase di runtime.