Share via

Progettazione efficace dei ruoli

  • Articolo

In molti scenari, la sicurezza basata sui ruoli è un meccanismo molto efficace, ma esistono situazioni in cui è meno efficace. Quando si decide dove e come applicare la sicurezza basata sui ruoli a una determinata applicazione, è necessario prendere in considerazione diversi fattori.

Caratteristiche utente e dati e idoneità dei ruoli

I ruoli funzionano molto bene per caratterizzare gruppi di utenti e, su tale base, filtrare le azioni che tali utenti possono eseguire. Spesso, questa operazione viene eseguita in pratica creando ruoli che riflettono il posto di un utente all'interno di un'organizzazione, ad esempio i ruoli "Manager" e "Tellers", "Amministrazione istrators" e "Reader", "Project One Employees" e "Project Two Employees". In questi casi, in cui i dati a cui si accede sono piuttosto generici rispetto agli utenti, i ruoli possono essere usati in modo efficiente per applicare regole business come le seguenti:

  • "I manager possono trasferire qualsiasi quantità di denaro. I teller possono trasferire solo fino a $10.000."

  • "Amministrazione istrator può cambiare qualcosa. Tutti gli altri possono solo leggere."

  • "I dipendenti di Project One possono accedere a un determinato database. Nessun altro può."

Gli utenti possono naturalmente rientrare in più ruoli, a seconda del modo in cui i ruoli modellano la struttura organizzativa di un'azienda.

Tuttavia, i ruoli non funzionano molto bene quando una decisione di accesso alla sicurezza dipende dalle caratteristiche di una particolare parte di dati. Ad esempio, sarebbe difficile usare i ruoli per riflettere relazioni complesse tra i dati utente, ad esempio le seguenti:

  • "Un particolare responsabile può accedere ai dati del personale solo per i suoi report".

  • "Joe Consumer può cercare il suo saldo del conto."

In questi casi, il controllo di sicurezza deve spesso essere eseguito nel database stesso, in cui è più facile prendere in considerazione le caratteristiche innate dei dati a cui si accede. Ciò significa che è necessario usare la rappresentazione per passare l'identità client al database e consentire al database di convalidare la richiesta. Ciò può influire sulle prestazioni e può influire sulla progettazione dell'applicazione, ad esempio il pool di connessioni potrebbe non funzionare quando una connessione viene aperta con un'identità utente specifica. Per una descrizione dei problemi coinvolti, vedere Sicurezza delle applicazioni multilivello e Rappresentazione client e delega.

Complessità e scalabilità di criteri di autorizzazione basati sui ruoli

Indipendentemente dai criteri di sicurezza applicati, l'implementazione dell'applicazione verrà applicata solo dagli amministratori di sistema che distribuiscono l'applicazione. Se gli amministratori commettono errori nell'assegnazione degli utenti ai ruoli corretti in base ai criteri di sicurezza, i criteri non funzioneranno come previsto. È molto probabile che si verifichino problemi nelle circostanze seguenti:

  • Sono stati creati criteri molto complessi basati sui ruoli, con molti ruoli e utenti che esestituiscono numerosi ruoli.
  • I ruoli vengono creati con criteri ambigui per chi deve appartenere.
  • Sono presenti molti utenti nel sito in cui è installata l'applicazione e gli utenti si spostano spesso all'interno dell'organizzazione, cambiando in relazione ai ruoli creati.
  • Nel sito in cui è installata l'applicazione sono molti amministratori, con la divisione delle responsabilità, in modo che un amministratore abbia familiarità con i requisiti di sicurezza dell'applicazione è potenzialmente poco familiare con i gruppi di utenti di grandi dimensioni che devono usarla. Questo è un problema particolare quando gli utenti si spostano all'interno dell'organizzazione, tali informazioni devono essere comunicate correttamente.

Inoltre, man mano che aumenta il numero di ruoli assegnati a un'applicazione, la quantità di tempo che COM+ deve dedicare alla ricerca dell'appartenenza del chiamante in tali ruoli, con una probabile riduzione delle prestazioni.

Per gestire la complessità e attenuare questi problemi, è possibile usare le linee guida seguenti:

  • Scegliere nomi di ruolo auto-descrittivi. Rendere più ovvio possibile quali utenti devono appartenere a quali ruoli.
  • Rendere i criteri basati sui ruoli il più semplice possibile (e non più semplice). Scegliere il minor numero possibile di ruoli, mantenendo al contempo criteri efficaci.
  • Documentare chiaramente i criteri basati sui ruoli che si creano per gli amministratori, indipendentemente dal fatto che l'appartenenza ai ruoli sia ovvia (per l'utente). In particolare, usare il campo di descrizione disponibile per ogni ruolo per descrivere la finalità del ruolo. Se in genere non si può descrivere chi deve appartenere al ruolo in un paio di frasi, è probabilmente troppo complicato.
  • È consigliabile che gli amministratori dell'applicazione popolano i ruoli con gruppi di utenti anziché con singoli utenti. Si tratta di una soluzione molto più scalabile. Semplifica la riassegnazione o la rimozione degli utenti man mano che si spostano all'interno dell'organizzazione e isola gli amministratori da una certa quantità di supervisione e problemi nella comunicazione.

Limiti di sicurezza

Informazioni sul contesto delle chiamate di sicurezza

Security Context, proprietà

Uso dei ruoli per l'autorizzazione client