Riepilogo delle modifiche alla sicurezza dall'accesso di codice
In .NET Framework versione 4 la sicurezza dall'accesso di codice (CAS, Code Access Security) ha subito importanti modifiche al fine di semplificare il sistema di sicurezza. Nelle versioni precedenti di .NET Framework i diritti di un'applicazione gestita venivano determinati dalle regole dei criteri di sicurezza impostate a livello di computer per stabilire le impostazioni di runtime. A partire da .NET Framework 4:
I criteri di sicurezza non sono più validi. Le autorizzazioni vengono ancora utilizzate. È stato eliminato solo il sistema dei criteri.
I diritti di accesso per le applicazioni vengono determinati da due fattori: autorizzazioni (set di concessioni stabilito dal dominio dell'applicazione) e trasparenza. Tutte le applicazioni parzialmente attendibili sono classificate come trasparenti. Le applicazioni trasparenti non devono preoccuparsi della sicurezza. La trasparenza veniva inizialmente utilizzata per Microsoft Silverlight e ora è stata estesa a tutti gli ambienti ospitati.
Alle applicazioni Intranet desktop e locali viene concessa l'attendibilità totale.
.gif "Nota importante") Importante |
|---|
La modifica principale apportata alla sicurezza dall'accesso di codice consiste nell'eliminazione dei criteri di sicurezza.Non è stata eliminata la sicurezza dall'accesso di codice di per sé ma è stato rimosso solo l'utilizzo dei criteri, e di alcune richieste di autorizzazione. |
In questo argomento vengono forniti brevi cenni preliminari sulle modifiche della sicurezza dall'accesso di codice in .NET Framework 4. Per ulteriori informazioni, vedere Modifiche della sicurezza in .NET Framework 4.
Sandboxing e modello di autorizzazione
Nell'elenco seguente viene descritto il modello di attendibilità per le applicazioni desktop e ospitate in .NET Framework 4. Per ulteriori informazioni, vedere Modifiche della sicurezza in .NET Framework 4.
Applicazioni desktop. Come nelle versioni precedenti di .NET Framework alle applicazioni gestite che risiedono sul desktop, a meno che non siano state scaricate dal Web, viene concessa l'attendibilità totale. Anche alle applicazioni che risiedono nelle condivisioni della Intranet locale viene concessa l'attendibilità totale. Non è più possibile utilizzare i criteri per limitare le autorizzazioni per un'applicazione in base alla relativa cartella nel disco rigido locale.
Applicazioni ospitate. Alle applicazioni eseguite in una sandbox, ad esempio le applicazioni basate su Silverlight, viene concesso un set limitato di autorizzazioni che determinano le risorse del computer a cui è possibile accedere, ad esempio i file che è consentito utilizzare. Le sandbox consentono di identificare alcuni assembly all'interno della sandbox come parzialmente attendibili e altri come completamente attendibili. Agli assembly parzialmente attendibili viene concesso un set specifico di autorizzazioni, come determinato dal dominio dell'applicazione (System.AppDomain) che ha creato la sandbox. Parte del codice con attendibilità totale nelle librerie con attendibilità totale può essere chiamato da codice parzialmente attendibile. Il codice attendibile può effettuare le chiamate alle risorse protette del computer. Tuttavia, i tipi e i membri con attendibilità totale accessibili pubblicamente che possono chiamare risorse protette devono essere sottoposti a un controllo di sicurezza. Tali membri vengono classificati come critici per la sicurezza, come descritto nella sezione successiva. Possono essere chiamati da codice (trasparente) parzialmente attendibile e, a loro volta, possono chiamare codice critico.
Trasparenza della sicurezza
La trasparenza della sicurezza separa il codice sensibile per la sicurezza dal codice non sensibile per la sicurezza. È stata introdotta in .NET Framework versione 2.0 per semplificare i controlli di sicurezza annotando il codice che doveva eseguire le azioni sensibili per la sicurezza come critico per la sicurezza. Pertanto il codice che non era critico per la sicurezza, ovvero codice trasparente, non richiedeva un'analisi accurata. Tuttavia, nelle versioni precedenti di .NET Framework, la trasparenza veniva utilizzata solo dal codice Microsoft.
In .NET Framework 4 questo modello è stato esteso e le regole sono state rafforzate per trasformare la trasparenza della sicurezza in un modello di imposizione. In questo modello avanzato il codice considerato sensibile per la sicurezza e che può essere chiamato dalle applicazioni parzialmente attendibili è più facilmente identificabile. In questo modo viene ulteriormente ridotta la superficie di attacco da controllare.
Nella tabella seguente vengono illustrate le categorie di trasparenza e gli attributi associati per l'annotazione del codice.
Categoria di sicurezza |
Attributo |
Descrizione |
|---|---|---|
Trasparente |
Codice che non esegue alcuna operazione intrinsecamente sensibile per la sicurezza. |
|
Critico |
Codice che può eseguire qualsiasi operazione, ma che non può essere chiamato da applicazioni parzialmente attendibili. |
|
Critico per la sicurezza |
Codice che può eseguire qualsiasi operazione e che può essere chiamato da applicazioni parzialmente attendibili. Si tratta del livello di negoziazione sicuro. Lo scopo è quello di eseguire la convalida e i controlli di sicurezza appropriati prima di chiamare il codice critico. |
Il codice trasparente non può eseguire le operazioni riportate di seguito, indipendentemente dalle autorizzazioni concesse:
Contenere codice non verificabile.
Utilizzare platform invoke.
Eseguire operazioni Assert.
Chiamare codice critico.
Derivare da codice critico.
Chiamare codice protetto da LinkDemand, ovvero codice che viene considerato critico.
Se il codice tenta di violare queste regole, vengono generate eccezioni, anche se il codice dispone di attendibilità totale. Per ulteriori informazioni, vedere Modifiche della sicurezza in .NET Framework 4.
Si noti che la sensibilità per la sicurezza viene definita nel Common Language Runtime (CLR) come azioni proibite per il codice trasparente. Il modello di trasparenza non protegge dalle violazioni di sicurezza specifiche di uno scenario come la memorizzazione delle password nei campi.
Funzionamento del modello di sicurezza
Ogni oggetto AppDomain dispone di un set di autorizzazioni associato, definito dall'host in uno scenario ospitato. Il set di autorizzazioni selezionato dispone dell'attendibilità totale per il codice non ospitato.
Il codice parzialmente attendibile è sempre trasparente, pertanto non può eseguire le azioni proibite per il codice trasparente. Vedere trasparenza.
Per impostazione predefinita, il codice ad attendibilità totale è critico, a meno che non sia stato contrassegnato come trasparente. Se un'applicazione desktop è contrassegnata come trasparente, non può chiamare il codice critico, anche se dispone di attendibilità totale.
Le librerie possono essere esposte al codice parzialmente attendibile sia dall'host che da .NET Framework. Tali librerie contengono una combinazione di codice trasparente, critico e critico per la sicurezza.
Il codice critico per la sicurezza deve richiedere autorizzazioni appropriate prima di utilizzare la funzionalità critica. Il metodo File.Open ad esempio richiede FileIOPermission prima di aprire un file.
Il codice critico per la sicurezza deve inoltre eseguire tutti gli altri controlli e la convalida prima e dopo le chiamate a una funzionalità critica. È possibile ad esempio che le eccezioni e i messaggi debbano essere filtrati prima di essere passati al codice parzialmente attendibile.
Il codice critico deve effettuare un'asserzione delle autorizzazioni necessarie quando viene chiamato dal codice parzialmente attendibile, perché il codice critico potrebbe eseguire un'operazione che il codice parzialmente attendibile non è autorizzato a eseguire.