Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La maggior parte del codice dell'applicazione può semplicemente usare l'infrastruttura implementata da .NET. In alcuni casi è necessaria una sicurezza aggiuntiva specifica dell'applicazione, compilata estendendo il sistema di sicurezza o usando nuovi metodi ad hoc.
L'uso delle autorizzazioni applicate da .NET e di altre misure di imposizione nel codice consente di erigere barriere per impedire a codice dannoso di accedere alle informazioni che non si desidera che abbiano o eseseguono altre azioni indesiderate. Inoltre, è necessario trovare un equilibrio tra sicurezza e usabilità in tutti gli scenari previsti usando codice attendibile.
Questa panoramica descrive i diversi modi in cui è possibile progettare il codice per lavorare con il sistema di sicurezza.
Protezione dell'accesso alle risorse
Quando si progetta e si scrive il codice, è necessario proteggere e limitare l'accesso del codice alle risorse, soprattutto quando si usa o richiama codice di origine sconosciuta. Tenere quindi presente le tecniche seguenti per assicurarsi che il codice sia sicuro:
Non usare la Sicurezza per l'Accesso al Codice (CAS).
Non usare codice parzialmente affidabile.
Non usare l'attributo AllowPartiallyTrustedCaller (APTCA).
Non usare .NET Remoting.
Non usare Distributed Component Object Model (DCOM).
Non usare formattatori binari.
La sicurezza dall'accesso di codice e il codice Security-Transparent non sono supportati come limite di sicurezza con codice parzialmente attendibile. Sconsigliamo di caricare ed eseguire codice di origini sconosciute senza aver messo in atto misure di sicurezza alternative. Le misure di sicurezza alternative sono:
Virtualizzazione
AppContainers
Utenti e autorizzazioni del sistema operativo
contenitori Hyper-V
Codice indipendente dalla sicurezza
Il codice indipendente dalla sicurezza non esegue alcuna operazione esplicita con il sistema di sicurezza. Viene eseguito con qualunque autorizzazione ricevuta. Anche se le applicazioni che non rilevano eccezioni di sicurezza associate a operazioni protette ,ad esempio l'uso di file, reti e così via, possono generare un'eccezione non gestita, il codice indipendente dalla sicurezza sfrutta ancora le tecnologie di sicurezza in .NET.
Una libreria indipendente dalla sicurezza presenta caratteristiche speciali che è necessario comprendere. Si supponga che la libreria fornisca elementi API che usano file o chiamano codice non gestito. Se il codice non dispone dell'autorizzazione corrispondente, non verrà eseguito come descritto. Tuttavia, anche se il codice dispone dell'autorizzazione, qualsiasi codice dell'applicazione che lo chiama deve avere la stessa autorizzazione per funzionare. Se il codice chiamante non dispone dell'autorizzazione corretta, viene visualizzato un codice SecurityException come risultato dell'analisi dello stack di sicurezza per l'accesso al codice.
Codice dell'applicazione che non è un componente riutilizzabile
Se il codice fa parte di un'applicazione che non verrà chiamata da altro codice, la sicurezza è semplice e la codifica speciale potrebbe non essere necessaria. Ricorda, tuttavia, che il codice dannoso può chiamare il tuo codice. Anche se la sicurezza dell'accesso al codice potrebbe impedire a codice dannoso di accedere alle risorse, tale codice potrebbe comunque leggere i valori dei campi o delle proprietà che potrebbero contenere informazioni riservate.
Inoltre, se il codice accetta l'input dell'utente da Internet o da altre origini inaffidabili, è necessario prestare attenzione all'input dannoso.
Implementazione del wrapper gestito nel codice nativo
In genere in questo scenario, alcune funzionalità utili vengono implementate nel codice nativo che si vuole rendere disponibile per il codice gestito. I wrapper gestiti sono facili da scrivere usando platform invoke o interoperabilità COM. Tuttavia, se si esegue questa operazione, i chiamanti dei wrapper devono disporre di diritti di codice non gestiti per avere esito positivo. In base ai criteri predefiniti, significa che il codice scaricato da una intranet o Internet non funzionerà con i wrapper.
Anziché concedere diritti di codice non gestiti a tutte le applicazioni che usano questi wrapper, è preferibile concedere questi diritti solo al codice wrapper. Se la funzionalità sottostante non espone risorse e l'implementazione è analogamente sicura, il wrapper deve solo asserire i propri diritti, che consente a qualsiasi codice di chiamarlo. Quando sono coinvolte le risorse, la codifica di sicurezza deve corrispondere al caso del codice della libreria descritto nella sezione successiva. Poiché il wrapper espone potenzialmente i chiamanti a queste risorse, è necessaria un'attenta verifica della sicurezza del codice nativo ed è responsabilità del wrapper.
Codice di libreria che espone risorse protette
L'approccio seguente è il più potente e quindi potenzialmente pericoloso (se eseguito in modo non corretto) per la codifica della sicurezza: la libreria funge da interfaccia per altri codice per accedere a determinate risorse che non sono altrimenti disponibili, proprio come le classi .NET applicano le autorizzazioni per le risorse usate. Ovunque si esponga una risorsa, il codice deve prima richiedere l'autorizzazione appropriata per la risorsa ( ovvero deve eseguire un controllo di sicurezza) e quindi in genere dichiarare i propri diritti per eseguire l'operazione effettiva.
Vedere anche
Collabora con noi su GitHub
L'origine di questo contenuto è disponibile in GitHub, in cui è anche possibile creare ed esaminare i problemi e le richieste pull. Per ulteriori informazioni, vedere la guida per i collaboratori.
