Protezione in .NET Remoting
In generale, le applicazioni che utilizzano .NET Framework Remoting sono caratterizzate da problemi di protezione piu` complessi rispetto alle applicazioni locali.
La protezione di applicazioni distribuite determina un problema di difficile risoluzione senza il ricorso a misure che comportano una riduzione delle prestazioni. Se un'estremita` di una comunicazione e` in attesa di una chiamata, un client non autorizzato a conoscenza dell'endpoint in attesa potrebbe tentare di passare informazioni serializzate in modo che sia possibile deserializzarle e richiamarle nell'altro endpoint. Per garantire con un livello sufficiente di sicurezza che la comunicazione venga eseguita tra due componenti attendibili, e` necessario eseguire l'autenticazione reciproca, nonche´ la crittografia del contenuto. Di conseguenza, e` necessario innanzitutto valutare i requisiti di protezione dell'applicazione .NET Remoting e, successivamente, i requisiti relativi alle prestazioni desiderati. Il livello di autenticazione e di crittografia con cui esporre dati ed endpoint deve essere commisurato al grado di integrita` richiesto dall'applicazione.
L'utilizzo di delegati in .NET Remoting e` esemplificativo. Poiche´ i delegati possono eseguire il wrapping delle informazioni sul tipo dei metodi statici, che non vengono mai eseguiti in modalita` remota, nelle applicazioni server e` sempre necessario dichiarare sempre un tipo delegato personalizzato i cui parametri personalizzati, considerati complessivamente, non devono corrispondere a un metodo statico disponibile per la chiamata nel computer server. E` consigliabile non consentire mai a un client di definire e passare a un'applicazione qualsiasi tipo che il server potrebbe deserializzare.
Prima di procedere nella progettazione di applicazioni distribuite in cui si utilizza l'infrastruttura di .NET Framework Remoting, e` fondamentale stabilire il livello di protezione desiderato e il punto di implementazione. In questa sezione vengono descritti i possibili approcci alla protezione in funzione di determinate scelte di progettazione. Benche´ 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 possibilita` di accedere a risorse e operazioni mediante codice eseguibile, sulla base dei criteri di protezione impostati dell'amministratore del computer. Tuttavia, poiche´ la protezione dall'accesso di codice non permette di elaborare lo stack in una connessione remota, e` necessario che gli sviluppatori di applicazioni remote comprendano con chiarezza che l'esecuzione dell'infrastruttura .NET Remoting sul client o sul server richiede un'attendibilita` completa. Qualsiasi utilizzo non autorizzato di un'applicazione .NET Remoting consente di accedere in modo improprio alle autorizzazioni FullTrust.
Avviso
Non tentare mai di creare un oggetto wrapper remotizzabile per un oggetto AppDomain. Un'operazione di questo tipo, infatti, consentirebbe la pubblicazione in modalita` remota di un riferimento all'oggetto AppDomain specifico e l'esposizione del metodo AppDomain.CreateInstance o di altri metodi in modalita` remota, eliminando ogni protezione dall'accesso di codice per l'oggetto AppDomain specifico. Se eseguono una connessione all'oggetto AppDomain remoto, client non autorizzati potrebbero ottenere l'accesso a tutte le risorse a cui l'oggetto AppDomain specifico puo` accedere. Non e` quindi consigliabile creare un oggetto wrapper remotizzabile per qualsiasi tipo che estenda MarshalByRefObject e che implementi metodi che potrebbero essere utilizzati da client non autorizzati per aggirare il sistema di protezione.
Nota
In generale, diversi tipi di sistema consentono di estendere MarshalByRefObject. Contemporaneamente, tuttavia, questi tipi consentono di eseguire controlli di protezione in fase di esecuzione per impedire che un oggetto del tipo MarshalByRefObject possa essere richiamato in modalita` remota dall'esterno del dominio dell'applicazione. AppDomain e System.Windows.Forms.Form rappresentano due esempi di tali tipi. Contrariamente a quanto si potrebbe presumere, questi tipi speciali non consentono di estendere MarshalByRefObject ne´ di ottenere un riferimento in modalita` remota. Un'ipotesi apparentemente valida potrebbe essere quella di utilizzare un altro tipo remotizzabile per eseguire il wrapping per il riferimento in-process. E` consigliabile non eseguire mai un'operazione di questo tipo poiche´ la protezione dall'accesso di codice verrebbe erroneamente elusa.
Considerazioni sulla protezione nelle applicazioni .NET Remoting
In generale le aree di protezione da valutare in un'applicazione distribuita sono due, in base allo scenario specifico, ovvero la protezione del canale di comunicazione e del messaggio stesso o la protezione dell'applicazione da un utilizzo improprio. In alcuni casi, potrebbe essere necessario valutare entrambi gli aspetti.
In genere, per garantire la protezione del canale di comunicazione, e` necessario crittografare il canale, crittografare il contenuto del messaggio su un lato del flusso e decrittografarlo sull'altro lato o eseguire entrambe le operazioni. Per garantire che il contenuto del messaggio non sia stato alterato, potrebbe essere necessario un controllo dell'integrita`, nonche´ una conferma dell'identita` del client, del server oppure di entrambi.
E` necessario innanzitutto autenticare i client per confermare che dispongano delle autorizzazioni per utilizzare la risorsa. Successivamente, tutte le conversazioni devono essere crittografate per proteggere i dati durante la trasmissione. Queste operazioni sono supportate in modo completo dalle classi HttpChannel e TcpChannel. Tenere presente che, poiche´ e` operativo solo in un computer, il canale IPC non supporta la crittografia ma l'autenticazione Windows.
Alcuni scenari costituiscono un'eccezione rispetto alle due regole descritte in precedenza. La crittografia infatti potrebbe essere eliminata se i requisiti relativi alle prestazioni sono sufficientemente elevati e il valore dei dati sufficientemente basso da ridurre l'importanza dell'osservazione e della manipolazione dei dati stessi. La crittografia puo` essere disattivata anche quando la comunicazione viene eseguita su una rete crittografata, ad esempio una rete protetta mediante IPsec.
E` inoltre possibile proteggere un'applicazione dall'utilizzo non autorizzato mediante la registrazione del comportamento dell'utente per ricostruirne gli schemi di utilizzo.
Avviso
.NET Framework Remoting non consente di eseguire l'autenticazione ne´ la crittografia per impostazione predefinita. E` consigliabile pertanto eseguire tutte le azioni necessarie per verificare l'identita` dei client o dei server prima di interagire con essi in modalita` remota. Poiche´ per eseguire applicazioni .NET Framework Remoting e` necessario disporre di autorizzazioni FullTrust, e` possibile che un client non autorizzato, a cui viene concesso l'accesso al server, esegua codice come se fosse completamente attendibile. E` consigliabile quindi autenticare sempre gli endpoint e crittografare i flussi di comunicazione mediante l'hosting dei tipi remoti in Internet Information Services (IIS) oppure generando una coppia di sink di canale personalizzata. In .NET Framework versione 2.0 non e` piu` necessario creare un sink personalizzato per proteggere una comunicazione, poiche´ le funzionalita` di autenticazione e di crittografia, attivate mediante l'impostazione secure = true per il canale TCP, consentono di ottenere una comunicazione protetta. Il canale TCP consente attualmente di autenticare l'utente che esegue la connessione, di crittografare i dati durante la connessione e di determinare l'identita` e l'indirizzo IP di un client che si connette.
Vedere anche
Riferimenti
RemotingConfiguration
ChannelServices
Context
MethodCall
RemotingServices
Concetti
Autenticazione con il canale HTTP
Altre risorse
Cenni preliminari su .NET Framework Remoting
Protezione basata sui ruoli
Protezione dall'accesso di codice