Hosting di più applicazioni Web
In questa pagina
Argomenti del modulo
I sistemi operativi Windows Server 2000 e 2003 sono caratterizzati da ambienti di hosting Web scalabili e affidabili. Possono essere impiegati per ospitare in modo sicuro centinaia di siti Web e applicazioni ASP.NET su un unico server Web o Web farm.
Tuttavia, quando si usano applicazioni ASP.NET in scenari di hosting condivisi è necessario isolare le applicazioni una dall'altra e da risorse di sistema condivise quali il file system, il registro e i registri eventi. Senza un adeguato isolamento, un'applicazione sviluppata in modo non corretto o illegale può influire negativamente su altre applicazioni sul server, o accedere a risorse senza autorizzazione. L'isolamento dell'applicazione è particolarmente significativo per i provider di servizi Internet (ISP) che ospitano un gran numero di applicazioni di diverse aziende.
In questo modulo vengono illustrate le tecniche che è possibile utilizzare con Windows 2000 e 2003 per isolare le applicazioni ASP.NET al fine di salvaguardare l'integrità, la riservatezza e l'autenticità dei dati del sito Web ospitato.
Obiettivi
Il modulo consente di:
| • | Capire l'architettura e i componenti principali di ASP.NET in Windows 2000 e 2003. |
| • | Isolare le applicazioni Web utilizzando più identità, pool di applicazioni e la protezione dall'accesso di codice. |
| • | Configurare la rappresentazione dell'account anonimo. |
| • | Configurare la rappresentazione dell'account fisso per accedere a risorse remote o locali se l'autenticazione degli utenti avviene per mezzo dell'autenticazione di Windows integrata o dei certificati. |
| • | Migliorare la protezione dell'autenticazione basata su form. |
| • | Capire come si usano le credenziali quando si accede a dati memorizzati in condivisioni UNC. |
Ambito di applicazione
Le informazioni contenute in questo modulo sono valide per i seguenti prodotti e tecnologie:
| • | Microsoft Windows 2000 Server e Microsoft Windows 2003 Server |
| • | Microsoft .NET Framework 1.1 e ASP.NET 1.1 |
Utilizzo del modulo
In questo modulo viene spiegato come isolare le applicazioni in ambienti di hosting condivisi. Un elemento chiave è la protezione dall'accesso di codice. Utilizzare il modulo corrente insieme alle seguenti risorse:
| • | Leggere il modulo 8 "Protezione dall'accesso di codice". Questo modulo fornisce maggiori informazioni sul funzionamento della protezione dall'accesso di codice e su come utilizzarla per vincolare singoli assembly e limitare l'accesso al file system, al registro, alla rete e ad altre risorse critiche. |
| • | Leggere il modulo 9 "Utilizzo della protezione dall'accesso di codice con ASP.NET". Questo modulo contiene spiegazioni sul funzionamento del criterio di protezione dall'accesso di codice nelle applicazioni ASP.NET; inoltre, contiene considerazioni e implicazioni sulla costruzione di applicazioni con attendibilità parziale. |
| • | Leggere il modulo 16 "Protezione del server Web". In questo modulo vengono illustrate le modalità di protezione del sistema operativo Windows 2000 e di Microsoft .NET Framework. Una piattaforma di base protetta è un requisito indispensabile per la protezione di un'applicazione o di un servizio Web ASP.NET. |
Introduzione
In uno scenario di hosting condiviso, è essenziale fare in modo che un'applicazione non possa avere un impatto negativo sulle operazioni e sulla protezione di altre applicazioni.
Esistono diversi modi per isolare un'applicazione. Le opzioni disponibili variano a seconda della versione di .NET Framework e della versione del sistema operativo del server Web.
| • | Con la versione 1.1 di .NET Framework è possibile utilizzare il modello delle limitazioni delle risorse fornito dalla protezione dall'accesso di codice per creare un livello di isolamento dell'applicazione. L'isolamento dell'applicazione viene raggiunto limitandone l'accesso a diversi tipi di risorse come il file system, il registro, il registro eventi, Active Directory, i database, le risorse di rete e così via. |
| • | Windows Server 2003 consente di isolare i processi attraverso i pool di applicazioni di Internet Information Services 6.0 (IIS 6) che permettono di eseguire più applicazioni in istanze di processi di lavoro IIS separate. L'isolamento del processo non è possibile con Windows 2000 perché tutte le applicazioni Web vengono eseguite in un'unica istanza del processo di lavoro ASP.NET e l'isolamento è fornito dai domini dell'applicazione. |
La tabella 20.1 contiene un riepilogo delle varie opzioni per l'isolamento dell'applicazione disponibili su Windows 2000 e Windows Server 2003.
Tabella 20.1 Funzionalità per l'isolamento dell'applicazione di Windows 2000 e Windows Server 2003
| Funzionalità di isolamento | Windows 2000 | Windows Server 2003 |
Isolamento del processo | No | Sì (pool di applicazioni IIS 6) |
Isolamento dominio applicazione | Sì | Sì |
Identità a più thread | Sì | Sì |
Limitazione delle risorse con protezione dall'accesso di codice | Sì (.NET Framework versione 1.1) | Sì (.NET Framework versione 1.1) |
Windows Server 2003 con la versione 1.1 di .NET Framework è la piattaforma consigliata per l'hosting di più applicazioni ASP.NET perché supporta l'isolamento del processo e fornisce la più ricca gamma di opzioni per l'isolamento dell'applicazione.
Architettura ASP.NET su Windows 2000
Su Windows 2000, in un'unica istanza del processo di lavoro ASP.NET (Aspnet_wp.exe) vengono eseguite più applicazioni Web. Ogni applicazione risiede nel proprio dominio dell'applicazione che fornisce un certo grado di isolamento per il codice gestito. L'architettura Windows 2000/IIS 5 è illustrata nella figura 20.1.
Figura 20.1
Architettura ASP.NET su Windows 2000 con IIS 5
I componenti dell'architettura illustrata nella figura 20.1 sono riassunti nella tabella 20.2.
Tabella 20.2 Componenti dell'architettura Windows 2000 ASP.NET
| Componente | Descrizione |
Inetinfo.exe | Processo principale di IIS. Servizio Windows eseguito sotto l'account SYSTEM locale. |
Aspnet_isapi.dll | I mapping di script IIS associano i tipi di file ASP.NET con questa estensione ISAPI di ASP.NET che viene eseguita all'interno di Inetinfo.exe. Ha il compito di inviare le richieste al processo di lavoro di ASP.NET attraverso un named pipe asincrono. Inoltre, avvia il processo di lavoro e controlla lo stato del sistema. L'estensione ISAPI non contiene codice gestito e non elabora richieste. |
Aspnet_filter.dll | Filtro ISAPI utilizzato esclusivamente per il supporto dello stato sessione senza cookie delle applicazioni ASP.NET. Viene seguito all'interno di Inetinfo.exe. |
Aspnet_wp.exe | Processo di lavoro di ASP.NET. Ospita più applicazioni Web in domini applicazione separati utilizzati per creare l'isolamento. Di solito un'istanza per server, anche se su server a più processori la modalità Web garden consente di supportare più processi identici con un'affinità per un dato processore. Non è possibile separare determinate applicazioni Web in processi diversi. Per fare ciò sono necessari IIS 6 e Windows Server 2003. Aspnet_wp.exe viene eseguito sotto l'account ASPNET locale, ma è possibile utilizzare anche un account personalizzato. |
Aspnet_state.exe | Servizio Windows facoltativo utilizzato per la memorizzazione dello stato sessione delle applicazioni ASP.NET. Può essere eseguito sul server Web o su un computer remoto (obbligatorio per gli scenari Web farm). Viene eseguito sotto l'account ASPNET locale, ma è possibile utilizzare anche un account personalizzato, configurato attraverso lo snap-in Servizi. |
Architettura ASP.NET su Windows Server 2003
Su Windows Server 2003, l'architettura cambia perché IIS 6 consente di utilizzare più processi per ospitare applicazioni Web separate. Questa architettura è illustrata nella figura 20.2.
Nota: IIS 6 supporta una modalità di compatibilità con le versioni precedenti che, a sua volta, supporta il modello di processo di lavoro IIS 5 di ASP.NET.
Figura 20.2
Architettura ASP.NET su Windows Server 2003 con IIS 6
Rispetto all'architettura di ASP.NET sotto Windows 2000, la differenza principale in Windows Server 2003 è costituita dalla possibilità di utilizzare istanze separate del processo di lavoro di IIS (W3wp.exe) per ospitare le applicazioni Web. Per impostazione predefinita, queste istanze vengono eseguite utilizzando l'account NT Authority\NetworkService, che è un account locale con privilegi minimi che funge da account del computer attraverso la rete. Un'applicazione Web eseguita nel contesto dell'account Servizio di rete presenta le credenziali del computer ai server remoti per l'autenticazione.
Configurazione degli ACL per Servizi di rete
La configurazione di un elenco di controllo di accesso (ACL) per l'account Servizi di rete varia a seconda che si tratti di un computer locale o remoto. Per garantire l'accesso all'account Servizi di rete sul computer locale, aggiungere l'account Servizi di rete a un ACL. Per garantire l'accesso all'account Servizi di rete su un computer remoto, aggiungere l'account NomeDominio\NomeComputer$ a un ACL.
Nota: non confondere l'account Servizi di rete con il gruppo incorporato Network, che include utenti autenticati attraverso la rete.
I componenti principali dell'architettura illustrata nella figura 20.2 sono riassunti nella tabella 20.3.
Tabella 20.3 Componenti dell'architettura ASP.NET di Windows Server 2003
| Componente | Descrizione |
Aspnet_isapi.dll | Accoda le richieste perché vengano elaborate dal motore ASP.NET del codice gestito ed esegue il controllo dello stato del sistema. |
Aspnet_filter.dll | Filtro ISAPI utilizzato esclusivamente per il supporto dello stato sessione senza cookie delle applicazioni ASP.NET. Viene eseguito all'interno di W3wp.exe. |
W3wp.exe | Processo di lavoro IIS che contiene il motore di elaborazione ASP.NET del codice gestito. Lo spazio URL può essere arbitrariamente diviso tra diverse istanze W3wp.exe utilizzando pool di applicazioni IIS 6. È supportata anche una modalità Web garden. Le richieste sono instradate verso l'istanza del processo W3wp.exe direttamente da Http.sys che viene eseguito in modalità kernel. Per impostazione predefinita, il processo viene eseguito sotto l'account Servizi di rete ma può essere configurato. |
Aspnet_state.exe | Servizio Windows facoltativo utilizzato per la memorizzazione dello stato sessione delle applicazioni ASP.NET. Può essere eseguito sul server Web o su un computer remoto (obbligatorio per gli scenari Web farm). Viene eseguito sotto l'account Servizi di rete ma può essere configurato utilizzando lo snap-in Servizi. |
Isolamento delle applicazioni in base all'identità
È possibile isolare le applicazioni Web di ASP.NET dal punto di vista dell'identità del sistema operativo controllando l'identità dell'account utilizzato per eseguire ogni applicazione. Se ogni applicazione utilizza un'identità dell'account fisso separata, è possibile autorizzare e controllare ogni applicazione separatamente.
Nota: se si ospita un'applicazione Web di ASP.NET realizzata utilizzando .NET Framework versione 1.0, l'account di processo deve avere le autorizzazioni appropriate alla radice dell'unità del file system corrente. Per ulteriori informazioni, vedere l'articolo della Microsoft Knowledge Base 317955 "FIX: 'Failed to Start Monitoring Directory Changes' Error Message When You Browse to an ASP.NET Page" (in inglese).
Esistono due modi per utilizzare identità fisse separate per ogni applicazione su un server Web condiviso:
| • | Rappresentazione dell'account anonimo |
| • | Rappresentazione dell'identità fissa |
Rappresentazione dell'account anonimo
Con la rappresentazione dell'account anonimo, l'applicazione rappresenta l'account anonimo specificato da IIS e configurato per la directory virtuale dell'applicazione. È possibile utilizzare questo approccio se l'applicazione autentica gli utenti indipendentemente da IIS, ad esempio, utilizzando l'autenticazione basata su form o Microsoft Passport. In questi scenari, è possibile isolare l'applicazione utilizzando un account anonimo fisso. Una volta autenticato il chiamante e controllato i ruoli, il modello server attendibile può essere utilizzato per l'accesso alle risorse in downstream, dove l'account anonimo configurato fornisce l'identità attendibile.
Per supportare questo approccio, le directory virtuali dell'applicazione in IIS devono supportare l'accesso anonimo e per ogni applicazione deve essere configurato un account anonimo separato. L'applicazione deve essere quindi configurata per la rappresentazione. Questo approccio è indicato nella figura 20.3. L'accesso alle risorse locali e remote assume il contesto di protezione dell'account anonimo rappresentato.
Figura 20.3
Più account anonimi utilizzati per ciascuna applicazione
| • | Utilizzo di più account anonimi per l'accesso alle risorse Questa procedura descrive come utilizzare più account anonimi, uno per ciascuna applicazione Web, in modo che l'accesso alle risorse supporti l'autorizzazione e il controllo di singole applicazioni.
|
Rappresentazione dell'identità fissa
Se IIS deve autenticare gli utenti dell'applicazione, ad esempio utilizzando l'autenticazione integrata di Windows o l'autenticazione certificato, è possibile utilizzare un'identità rappresentazione fissa per eseguire l'applicazione di ASP.NET. Questo scenario è illustrato nella figura 20.4.
Figura 20.4
Le applicazioni rappresentano un account fisso e utilizzano tale account per accedere alle risorse
Per rappresentare un account fisso è possibile configurare singole applicazioni di ASP.NET. Questa configurazione offre il vantaggio di poter essere utilizzata con qualsiasi metodo di autenticazione IIS e non richiede l'autenticazione anonima IIS.
| • | Utilizzo di più account di rappresentazione fissi per accedere alle risorse Questa procedura descrive come utilizzare più account di rappresentazione fissi, uno per ciascuna applicazione Web, in modo che l'accesso alle risorse supporti l'autorizzazione e il controllo di singole applicazioni.
|
Nota: su Windows 2000 e .NET Framework versione 1.0, se si rappresenta un'identità fissa utilizzando la configurazione di cui sopra, è necessario garantire il privilegio "Agisci come parte del sistema operativo" all'account di processo ASP.NET usato per eseguire le applicazioni Web. Questo è contrario al principio del privilegio minimo. Per evitare ciò, si consiglia di effettuare l'aggiornamento a .NET Framework versione 1.1.
Isolamento delle applicazioni mediante pool di applicazioni
Se l'applicazione viene eseguita su Windows Server 2003, è possibile utilizzare pool di applicazioni e configurare ogni applicazione perché venga eseguita nel proprio processo di lavoro in modo da fornire isolamento a livello di processo. Per impostazione predefinita, tutte le applicazioni vengono eseguite in un pool di applicazioni predefinito. Con i pool di applicazioni è possibile configurare ogni processo in modo che venga eseguito utilizzando un'identità separata e, di conseguenza, non è necessario usare la rappresentazione.
| • | Per creare isolamento a livello di processo
|
Isolamento delle applicazioni con protezione dall'accesso di codice
Con la versione 1.1 di .NET Framework è possibile configurare le applicazioni in modo che vengano eseguite con livelli di attendibilità parziali, utilizzando l'elemento <trust>. Di seguito viene illustrato come configurare il livello di attendibilità di un'applicazione dal file Machine.config. In questo esempio viene utilizzato il livello di attendibilità medio.
<location path="Web Site Name/appvDir1" allowOverride="false">
<system.web>
<trust level="Medium" originUrl="" />
</system.web>
</location>
Se si configura un'applicazione in modo che venga eseguita con un livello di attendibilità diverso da "Totale", questa avrà autorizzazioni di protezione per l'accesso di codice limitate per accedere a determinati tipi di risorse. In tal modo è possibile vincolare le applicazioni per impedire che interagiscano tra di loro e accedano a risorse a livello di sistema come, ad esempio, aree con restrizioni del file system, il registro, il registro eventi e così via.
Per ulteriori informazioni sui livelli di attendibilità di ASP.NET e sul loro utilizzo per l'isolamento delle applicazioni e per altre considerazioni su progettazione e sviluppo di determinate applicazioni, vedere il modulo 9 "Utilizzo della protezione dall'accesso di codice con ASP.NET".
Nota: se per isolare l'applicazione si utilizza la protezione dall'accesso di codice, è necessario prendere in considerazione anche l'identità del sistema operativo dell'applicazione. Il modello di isolamento consigliato è quello che prevede l'utilizzo della protezione dall'accesso di codice insieme all'isolamento a livello di processo su Windows Server 2003.
Problemi dell'autenticazione basata su form
Se si utilizza l'autenticazione basata su form con la versione 1.0 di .NET Framework, è necessario utilizzare percorsi e nomi dei cookie separati. Altrimenti è possibile che un utente autenticato in un'applicazione esegua una richiesta in un'altra applicazione senza essere reindirizzato alla pagina di accesso relativa. Le regole di autorizzazione URL all'interno della seconda applicazione possono negare l'accesso all'utente, senza fornire l'opportunità di ricevere le credenziali di accesso utilizzando il modulo di accesso.
Per evitare questo problema, utilizzare attributi del nome e del percorso dei cookie univoci sull'elemento <forms> di ogni applicazione; inoltre, utilizzare chiavi computer separate per ogni applicazione.
La versione 1.1 di .NET Framework supporta l'impostazione IsolateApps, come mostrato di seguito.
<machineKey validationKey="AutoGenerate,IsolateApps"
decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>
In tal modo ogni applicazione sul computer utilizza una chiave separata per la crittografia e la convalida del cookie dell'autenticazione basata su form e dello stato di visualizzazione.
Con la versione 1.0 di .NET Framework non è possibile utilizzare IsolateApps ed è necessario creare manualmente gli elementi <machineKey>. Per ulteriori informazioni, consultare i seguenti articoli della Microsoft Knowledge Base:
| • | 313116, "PRB: Forms Authentication Requests Are Not Directed to loginUrl Page" (in inglese). |
| • | 312906, "How To: Create Keys by Using Visual C# .NET for Use in Forms Authentication" (in inglese). |
Host condivisioni UNC
Se si esegue un'applicazione con il suo contenuto su una condivisione UNC (Universal Naming Convention), le credenziali utilizzate per accedere alla condivisione possono essere le credenziali dell'applicazioni o del client autenticato. Queste impostazioni vengono configurate da un amministratore in IIS.
Quando un'applicazione è configurata in questo modo, ASP.NET rappresenta il contesto di protezione del token che riceve da IIS. Non è possibile configurarlo con il tag <identity> a meno che non vengano fornite credenziali esplicite.
Con la versione 1.0 di .NET Framework, utilizzare Mscorcfg.msc per creare un gruppo di codice basato sull'URL e per garantirgli attendibilità totale.
Se si utilizza una directory virtuale che punta a una condivisione remota per ospitare un'applicazione ASP.NET, è possibile ricevere un'eccezione di protezione. Per ulteriori informazioni, vedere l'articolo della Microsoft Knowledge Base 320268 "PRB: "System.Security.SecurityException: Security error" Error Message when the Virtual Directory Points to a Remote Share in ASP.NET" (in inglese).
Riepilogo
Se si ospitano più applicazioni ASP.NET su un unico server Web è necessario considerare come vengono isolate le applicazioni una dall'altra e da risorse di sistema condivise quali il file system, il registro e i registri eventi. Senza un adeguato isolamento, un'applicazione sviluppata in modo non corretto o illegale può influire negativamente su altre applicazioni sul server.
Su Windows Server 2003, utilizzare il modello del processo di lavoro multiplo supportato da IIS 6 per creare l'isolamento del processo del sistema operativo per le applicazioni. Su Windows 2000, non è possibile isolare il processo, sebbene sia possibile configurare più applicazioni in modo che utilizzino account utente anonimi separati. Questa modalità consente di eseguire un controllo separato dell'applicazione e supporta l'autorizzazione indipendente dell'applicazione.
Su entrambe le piattaforme è possibile utilizzare il modello delle limitazioni delle risorse fornito dalla protezione dall'accesso di codice come controllo supplementare per stabilire a quali tipi di risorse possono accedere le applicazioni. Per utilizzare la protezione dall'accesso di codice con le applicazioni ASP.NET è necessaria la versione 1.1 di .NET Framework.
Per ulteriori informazioni su come proteggere le applicazioni ASP.NET, vedere il modulo 19 "Protezione dell'applicazione ASP.NET e dei servizi Web".