Protezione

In generale, le applicazioni in cui si utilizza .NET Remoting presentano problemi di protezione più complessi rispetto alle applicazioni locali.

La protezione delle applicazioni distribuite pone un problema che è difficile da superare senza ricorrere a misure che comporterebbero una riduzione delle prestazioni. Se un'estremità della comunicazione è in attesa di una chiamata, un client non autorizzato che sia a conoscenza dell'endpoint in attesa potrà tentare di passare informazioni serializzate sperando che all'altra estremità esse vengano deserializzate e richiamate in qualche modo. Solo l'autenticazione reciproca e la crittografia del contenuto possono garantire che la comunicazione avvenga tra componenti dotati di un elevato livello di attendibilità. Di conseguenza, nella progettazione dell'applicazione remota è necessario valutare innanzitutto le specifiche esigenze di protezione e poi i requisiti relativi alle prestazioni. L'esposizione dei dati e degli endpoint senza le misure di protezione indicate deve essere commisurata all'integrità dei dati richiesta per l'applicazione e all'investimento che i dati rappresentano.

Il problema è ben esemplificato dal caso dei delegati remoti. Poiché i delegati possono fungere da wrapper per le informazioni sul tipo dei metodi static, i quali non verranno mai eseguiti in modalità remota, nelle applicazioni server deve essere sempre dichiarato un tipo di delegato personalizzato i cui parametri personalizzati, considerati nell'insieme, non corrisponderanno mai a un metodo static disponibile per la chiamata sul computer server. Non si deve mai consentire che un client definisca e passi all'applicazione tipi che il server potrebbe deserializzare, intenzionalmente o non intenzionalmente.

Nella progettazione di applicazioni protette e distribuite in cui si utilizza l'infrastruttura di .NET Remoting è importante stabilire con precisione quale livello di protezione si desidera e in quale posizione. In questa sezione vengono descritti i possibili approcci alla protezione in funzione di determinate scelte di progettazione. Benché non vengano analizzati tutti gli scenari, tali argomenti rappresentano un buon punto di partenza per prendere le decisioni opportune.

Protezione dall'accesso di codice

La protezione dall'accesso di codice consente di controllare la possibilità di accedere a risorse e operazioni mediante codice eseguibile, sulla base dei criteri di protezione impostati dell'amministratore del computer. Tuttavia, poiché la protezione dall'accesso di codice non permette di elaborare lo stack in una connessione remota, è necessario che gli sviluppatori di applicazioni remote comprendano con chiarezza che l'esecuzione dell'infrastruttura remota sul client o sul server richiede un'attendibilità completa.

Attenzione   Non si deve mai tentare di creare un wrapper remotizzabile per un oggetto AppDomain. Una simile operazione, infatti, consentirebbe la pubblicazione remota di un riferimento a tale oggetto e, di conseguenza, l'esposizione remota del metodo AppDomain.CreateInstance o di altri metodi, eliminando di fatto ogni protezione dall'accesso di codice per l'oggetto AppDomain. Connettendosi all'oggetto AppDomain remoto, client non autorizzati potrebbero ottenere accesso a tutte le risorse accessibili dallo stesso AppDomain. Le stesse considerazioni valgono per qualsiasi tipo che estenda MarshalByRefObject e implementi metodi che potrebbero essere utilizzati da client non autorizzati per evitare il sistema di protezione.

Più in generale, diversi tipi di sistema consentono di estendere MarshalByRefObject, ma consentono di effettuare controlli di protezione in fase di esecuzione per impedire che oggetti di questo tipo possano essere effettivamente richiamati in modalità remota dall'esterno del dominio applicazione. AppDomain e System.Windows.Forms.Form ne sono due esempi. Contrariamente a quanto si potrebbe presumere, con i tipi speciali in questione non è possibile estendere MarshalByRefObject e ottenere un riferimento in modalità remota. Un'ipotesi apparentemente valida potrebbe essere quella di utilizzare un altro tipo remotizzabile come wrapper per il riferimento in-process, ma così facendo si eluderebbe non intenzionalmente la protezione dall'accesso al codice e pertanto l'operazione è assolutamente sconsigliata.

Generazione di un'applicazione di comunicazione remota protetta

In generale, sono due le aree di protezione da valutare in un'applicazione distribuita, a seconda dello scenario: la protezione del canale di comunicazione e del messaggio stesso o la protezione dell'applicazione da un utilizzo improprio o, in certa misura, entrambe le opzioni.

In genere, la protezione del canale di comunicazione significava crittografare il contenuto del messaggio su un lato del flusso e decrittografarlo su un altro, crittografare il canale stesso o eseguire entrambe le operazioni. Poteva essere richiesto un controllo dell'integrità del contenuto del messaggio, per garantire che non fosse stato alterato, nonché una conferma dell'identità del client, del server oppure di entrambi.

È possibile proteggere l'applicazione dall'utilizzo non autorizzato verificando che l'utente disponga dell'autorizzazione all'uso dell'applicazione oppure registrando il comportamento dell'utente per ricostruire in seguito i criteri di utilizzo.

Progettazione della protezione nella comunicazione remota

È necessario rispondere a due domande principali per progettare un'applicazione protetta e facile da generare:

• Quali canali sono disponibili?
• Qual è il modello di autenticazione e di autorizzazione dell'utente per il server?

Se è possibile scegliere tra l'utilizzo di un oggetto HttpChannel e di un oggetto TcpChannel, è consigliabile preferire HttpChannel e inserire gli oggetti remoti in Internet Information Services (IIS), indipendentemente dai modelli di autenticazione e di autorizzazione dell'utente. L'hosting IIS offre il supporto per la protezione a livello di connessione con Secure Sockets Layer (SSL) e l'autenticazione tramite l'autenticazione Windows integrata (nota in precedenza come autenticazione NTLM) o Kerberos.

TcpChannel, in quanto implementazione del protocollo TCP (Transmission Control Protocol), non offre il supporto predefinito per alcuni efficienti standard di autenticazione assicurati dallo standard HTTP. In un ambiente protetto, ossia dotato di una protezione a livello di connessione come IPSec, è possibile utilizzare TcpChannel a velocità elevata, ma questa opzione non è consigliabile in Internet o in una rete Intranet non protetta.

Attenzione   .NET Remoting non consente di effettuare l'autenticazione né la crittografia per impostazione predefinita. Si consiglia dunque di eseguire tutte le azioni necessarie per verificare l'identità dei client o dei server prima di interagire con essi in modalità remota. Poiché l'esecuzione delle applicazioni .NET Remoting richiede autorizzazioni FullTrust, qualora a un client non autorizzato venisse concesso l'accesso al server, il client potrebbe eseguire codice come se fosse completamente attendibile. È necessario autenticare sempre gli endpoint e crittografare i flussi di comunicazione mediante l'hosting dei tipi remoti in IIS oppure generando a questo scopo una coppia di sink di canale personalizzata.

Il modello di autenticazione e autorizzazione dell'utente per il server può variare notevolmente, ma l'hosting degli oggetti remoti in IIS supporta le soluzioni più complesse. Sono sufficienti poche righe di codice e si ottiene il supporto predefinito sul server per individuare l'oggetto WindowsPrincipal o GenericPrincipal del client, una scelta appropriata quando occorre rappresentare il client per eseguire alcune funzioni per conto dell'utente. Per informazioni dettagliate, vedere Rappresentazione e ripristino.

Gli oggetti GenericPrincipal rappresentano qualsiasi schema di autorizzazione dell'utente indipendente dai domini Windows e, di conseguenza, possono essere estesi per l'utilizzo con database utente e per interagire con altre piattaforme.

Vedere anche

Cenni preliminari su .NET Remoting | Protezione Web di HttpChannel | Protezione basata sui ruoli in applicazioni gestite | Protezione dall'accesso di codice | RemotingConfiguration | ChannelServices | Context | MethodCall | RemotingServices