Progettazione di un'autorizzazione
Un'autorizzazione rappresenta la possibilità di accedere a una risorsa protetta o di eseguire un'operazione protetta. Quando si implementa una classe di autorizzazioni personalizzata, sono numerose le decisioni di progettazione di alto rilievo che è necessario assumere. Uno dei primi passi consiste nel determinare con esattezza la risorsa per la cui sicurezza si progetta l’autorizzazione personalizzata.
Sarà quindi necessario individuare eventuali problemi relativi alla sovrapposizione di autorizzazioni. Benché si desideri evitare che due autorizzazioni proteggano la stessa risorsa, in alcune situazioni non sarà evidentemente possibile. È ad esempio possibile che nell'autorizzazione per l'accesso a codice non gestito siano incluse altre autorizzazioni, poiché il codice al quale è stata concessa l'autorizzazione per l'accesso al codice non gestito è in grado di eseguire quasi ogni tipo di operazione attraverso un'API non gestita. Quando invece l'autorizzazione per l'accesso a codice non gestito non viene concessa, è comunque necessario concedere le autorizzazioni per l'accesso ad altre risorse specifiche. È quindi consigliabile che l'autorizzazione per l'accesso a codice non gestito sia separata dalle altre autorizzazioni.
Non è sempre possibile stabilire se una sovrapposizione delle autorizzazioni sia gestibile, ma risulta utile individuare l'autorizzazione che consente un accesso più specifico rispetto all'altra e che quindi verrà in genere concessa più facilmente rispetto all'altra. In molti di questi casi, la concessione dei diritti di accesso è un'operazione piuttosto facile e l'attività degli amministratori risulta semplificata.
Una volta individuata la risorsa che è necessario proteggere dall'autorizzazione personalizzata e risolti gli eventuali problemi relativi alla sovrapposizione di autorizzazioni, sarà necessario definire il livello di accuratezza del controllo di accesso. Quest'ultima decisione influenza il modo in cui si progettano le variabili che rappresentano lo stato dell'autorizzazione e consente di determinare se gli amministratori possono configurare l'accesso alla risorsa protetta. Tale decisione influirà inoltre sulle prestazioni, sulla facilità di utilizzo e su altri fattori.
Per esaminare alcuni di questi problemi di progettazione, si prendano in considerazione alcune possibili scelte di progettazione per la classe FileIOPermission fornita da .NET Framework. Ogni scelta di progettazione influenza le variabili che rappresentano lo stato dell'autorizzazione.
Un singolo bit che significa "utilizza tutti i file" o "non utilizzare alcun file" a seconda del valore che assume.
Due bit che significano "leggi tutti i file" e "scrivi tutti i file" o il contrario a seconda dei valori che assumono.
26 bit che significano "utilizza tutti i file contenuti nell'unità specificata".
Una matrice di stringhe in cui sono elencati tutti i file a cui è consentito accedere.
Naturalmente sarà necessario effettuare alcuni compromessi. L'autorizzazione a bit singolo, ad esempio, è molto semplice, veloce e facile da comprendere, ma impone agli amministratori una scelta radicale e, quindi, a volte scomoda. Le altre scelte che specificano una rappresentazione più complessa dello stato di autorizzazione potrebbero rallentare in qualche misura le prestazioni. Sarà quindi necessario considerare questi compromessi e assicurarsi di non creare più autorizzazioni per proteggere la stessa risorsa. In generale, è consigliabile progettare l'autorizzazione in modo che il relativo stato sia tanto complesso quanto necessario, senza influire eccessivamente sulle prestazioni.
Per quanto sia possibile effettuare altre scelte di progettazione, la maggior parte delle autorizzazioni risponde a uno dei seguenti schemi standard di progettazione o una combinazione di tali schemi:
Autorizzazioni booleane. Il tipo più semplice di oggetto autorizzazione contiene uno o più bit, ognuno dei quali equivale ad "autorizzazione a X". L'autorizzazione può essere o meno concessa. Un esempio di questo tipo di autorizzazione è la classe SecurityPermission, il cui stato contiene variabili booleane che rappresentano il diritto di eseguire varie operazioni, quale l'autorizzazione a chiamare codice non gestito, ognuna delle quali può essere o meno concessa.
Livelli di autorizzazioni. Questa forma più dettagliata di autorizzazione dispone di variabili che rappresentano ogni tipo di accesso come un numero compreso tra zero (nessun accesso) e un numero superiore (accesso senza alcuna restrizione), con alcuni livelli intermedi. È possibile, ad esempio, utilizzare la classe UIPermission per esprimere vari livelli di autorizzazione all'utilizzo delle finestre, da nessuna autorizzazione di interfaccia utente ad autorizzazione illimitata di interfaccia utente, con alcuni livelli intermedi.
Autorizzazioni di elenchi di oggetti. Questo tipo di autorizzazione fornisce una specificazione molto dettagliata delle operazioni consentite o non consentite. La classe FileIOPermission è un esempio efficace di questo tipo di autorizzazione poiché il relativo stato è rappresentato da elenchi di file ai quali sono consentiti certi tipi di accesso. Le autorizzazioni con elenchi sono particolarmente utili per proteggere risorse che contengono un numero elevato di oggetti denominati.
In generale, è consigliabile ridurre le dipendenze esterne della classe di autorizzazioni personalizzata, poiché ogni volta che tale classe verrà richiesta dal sistema di sicurezza, sarà necessario caricare ciascun assembly da cui l'autorizzazione dipende. Se possibile, è necessario che l'autorizzazione personalizzata e ogni classe di attributi ad essa associata vengano posizionate in un singolo assembly distinto, per evitare che vengano inutilmente caricati altri assembly.
Vedere anche
Concetti
Creazione di autorizzazioni personalizzate di accesso al codice