Condividi tramite

Modifiche alla sicurezza tra IIS 6.0 e IIS 7 e versioni successive

  • Articolo

di IIS Team

Introduzione

IIS 7 e versioni successive apportano molti nuovi miglioramenti alla sicurezza di IIS 6.0. Questo documento illustra questi miglioramenti relativi all'autenticazione, all'autorizzazione, all'SSL, all'elenco di restrizioni dell'estensione del servizio Web e alle restrizioni IP.

Autenticazione

Per gli sviluppatori di applicazioni di ASP.NET erano presenti, prima di IIS 7, due modelli di autenticazione su cui era necessario programmare. Questi modelli erano le pipeline IIS e ASP.NET. In primo luogo, IIS esamina la richiesta ed esegue le routine di autenticazione e quindi la passa a ASP.NET in modo da poter eseguire un'attività simile.

In IIS 7 e versioni successive sono stati unificati questi due modelli per produrre una nuova pipeline affidabile che fa il meglio che entrambi i modelli meno recenti hanno fatto. IIS supporta ancora tutti i protocolli di autenticazione precedenti, ma ora supporta anche l'autenticazione basata su moduli che può proteggere da tutti i tipi di contenuto e non si basa sugli account di Windows. Oltre a supportare tutte le funzionalità precedenti che si sono apprese e che abbiamo anche migliorato alcune di esse, ad esempio la funzionalità di autenticazione anonima.

Queste modifiche verranno discusse nelle prossime sezioni.

Modifiche all'autenticazione anonima

In IIS 7 e versioni successive, l'autenticazione anonima si comporta in modo simile a quello delle versioni precedenti con una sola modifica, ovvero la possibilità di essere eseguita nel contenuto dell'identità del processo di lavoro. Ogni pool di applicazioni è configurato per l'esecuzione con il contenuto di un account utente e il valore predefinito per questo account è NETWORK edizione Standard RVICE.

È stato molto comune per ASP.NET applicazioni disattivare la rappresentazione ed eseguirla nell'identità del pool di applicazioni usando il codice seguente nei file web.config:

<identity impersonate="false"/>

Esistono diversi scenari in cui le applicazioni devono essere eseguite nel contesto dell'identità del processo:

  • L'identità del processo è un account con privilegi limitati e gli amministratori hanno bloccato i propri sistemi per tale account
  • All'identità del processo è stato concesso l'accesso alla rete e viene usato per accedere alle risorse back-end, ad esempio i database

Come parte della riprogettazione per IIS 7 e versioni successive, è stato necessario rendere questo scenario sicuro e facile da eseguire. Per implementare questo scenario, in IIS è necessario:

  • Installazione e abilitazione del modulo Di autenticazione anonima
  • Impostazione del nome utente anonimo e della password su una stringa vuota

A tale scopo, modificare la configurazione per l'autenticazione anonima in modo che venga visualizzata come segue:

<anonymousAuthentication enabled="true" userName="" defaultLogonDomain="" />

Questa configurazione indicherà a IIS di essere eseguita sempre nel contesto dell'identità del processo di lavoro.

Per impostazione predefinita, l'identità di autenticazione anonima in IIS 7.0 e versioni successive è l'account IUSR. Questo account è un'identità con privilegi limitati con diritti e privilegi minimi. Per altre informazioni sul nuovo account predefinito, vedere l'articolo Informazioni sull'account e il gruppo predefiniti in IIS 7 e versioni successive .

Modifiche di Passport

Il supporto per l'autenticazione Passport legacy è stato integrato in IIS 5/6 e Windows Server 2000 e 2003. Il supporto passport in IIS 5 & 6 è stato esposto come casella di controllo nella scheda Sicurezza directory in Gestione servizi IIS per "Abilita autenticazione Passport". Questa casella di controllo ha fornito a IIS la possibilità di inviare problemi di protocollo Tweener legacy. Oltre a questo, era ancora necessario registrare il sito Web con il portale di provisioning del servizio Passport, ottenere una chiave di crittografia e configurare Passport Manager legacy nel server prima che l'integrazione di IIS fosse funzionale.

In Windows Server 2008 e versioni successive, i file binari e l'integrazione legacy passport con IIS sono stati rimossi.

Il servizio Passport è stato modificato in Windows Live ID. Anche se il nuovo servizio Live ID è certamente cresciuto fuori dal servizio Passport legacy, ci sono modifiche importanti. Una delle principali modifiche è il modo in cui un sito partner si integra con Live ID. È possibile aggiungere l'autenticazione Live ID usando Windows Live ID Web Authentication SDK disponibile pubblicamente. Anche se il servizio Windows Live ID supporta anche la federazione delle identità e ADFS, tale funzionalità è una nuova funzionalità per casi specifici e non è una sostituzione di "Passport".

Autenticazione basata su form

L'autenticazione basata su form fa parte di ASP.NET e consente alle identità di Windows e non Windows di autenticarsi e ottenere un oggetto utente che le applicazioni possono usare in un secondo momento. IIS 7 e versioni successive supportano ora completamente l'autenticazione basata su moduli e possono essere configurati per proteggere l'accesso a tutti i tipi di contenuto.

Come IIS 7 e versioni successive determinano l'identità autenticata

In IIS 7 e versioni successive, le regole di autenticazione vengono elaborate dal motore principale in modo analogo a quello delle versioni precedenti di IIS con solo alcune modifiche secondarie. Per comprendere meglio l'ordine di elaborazione, ecco le regole in base all'ordine in cui IIS le valuta:

  • In primo luogo, IIS determina se un nome utente e una password sono stati configurati nella directory virtuale. Se è stato definito un set di credenziali, queste credenziali verranno usate. Per gli amministratori pre-IIS 7, queste credenziali sono le credenziali UNC
  • Se nella directory virtuale non sono configurate credenziali, IIS userà le credenziali fornite durante l'autenticazione. Queste credenziali possono appartenere all'identità configurata per l'autenticazione anonima o le credenziali fornite dall'utente durante l'handshake di autenticazione quando è abilitato Basic, Digest o autenticazione di Windows
  • Se non è stato stabilito alcun utente autenticato (ad esempio, l'autenticazione basata su form è abilitata) si determinerà se l'identità del processo deve essere usata
  • Se non si dispone di un'identità a questo punto, IIS restituirà un accesso negato

Autorizzazione

Supporto di AzMan

In IIS 6.0 è stato introdotto un nuovo modello di autorizzazione basato sulle regole AZMan. In IIS 7 e versioni successive questa funzionalità è stata deprecata a favore di un nuovo modello molto simile al modello di autorizzazione ASP.NET (vedere l'argomento relativo all'autorizzazione dell'URL di seguito).

Autorizzazione URL

In IIS 7 e versioni successive sono disponibili due soluzioni di autorizzazione. Il primo consiste nell'usare il modello di autorizzazione ASP.NET. Questo metodo richiede la definizione di tutte le regole di autorizzazione nella <configurazione system.web> e richiede zero modifiche per le applicazioni che dispongono già di regole scritte per ASP.NET. Il secondo modello consiste nel passare alla nuova architettura di autorizzazione IIS. Questo modello è molto simile ad ASP. Modello di NET con alcune modifiche secondarie:

  • Le regole non dipendono dall'ordine
  • Le regole di negazione vengono ordinate nella parte superiore dell'elenco
  • Le regole vengono elaborate in modo opposto di ASP.NET, principalmente nell'ordine: nonno, genitore, quindi figlio; ASP.NET le regole dei processi di autorizzazione nell'ordine opposto: figlio, padre, quindi nonno

Per comprendere meglio le differenze tra il modello di autorizzazione ASP.NET e il modello di autorizzazione IIS, si esaminerà innanzitutto una configurazione di autorizzazione ASP.NET:

<authorization>
    <allow users="Vik_Malhotra" />
    <deny roles="administrators" />
    <deny users="*" />
</authorization>

In questo esempio si consente di Vik_Malhotra, ma si negano tutti gli altri. In IIS la configurazione è molto simile:

<authorization>
    <add accessType="allow" users="Vik_Malhotra" />
    <add accessType="deny" roles="administrators" />
    <add accessType="deny" users="*" />
</authorization>

Il motivo della modifica della sintassi era che volevamo assicurarsi che gli sviluppatori di applicazioni sapessero che questi due modelli sono in realtà diversi, ma allo stesso tempo potevano spostare le regole da un'implementazione all'altra con uno sforzo minimo.

SSL

In IIS 6.0 IIS aveva archiviato le informazioni correlate a SSL nella metabase e aveva gestito una parte importante del processo di negoziazione SSL in combinazione con HTTP.SYS. In IIS 7 e versioni successive la maggior parte di questa configurazione è stata spostata in HTTP. Archivio sys.

Per illustrare come ognuna delle impostazioni di configurazione di IIS 6.0 viene eseguita nella configurazione iis 7 e successiva (o HTTP.SYS configurazione), il grafico seguente è stato costruito di seguito.

Configurazione metabase di IIS 6.0 Descrizione della proprietà ARCHITETTURA IIS 7.0 e versioni successive
AccessSSLFlags AccessSSLFlags è una maschera di bit del valore AccessSSL AccessSSL128 AccessSSLNegotiateCert AccessSSSLRequireCert AccessSSSLMapCert 0 indica che non è ssl. Proprietà ancora supportata in IIS 7.0 e versioni successive nella <sezione di accesso>
CertCheckMode Abilitare o disabilitare il controllo CRL (elenco di revoche di certificati). Questo valore verrà ora archiviato in http.sys nell'oggetto PHTTP_edizione Standard RVICE_CONFIG_SSL_PARAM.
RevocationFreshnessTime Se la proprietà RevocationFreshnessTime è impostata su 1 (true), l'elenco di revoche di certificati (CRL) nel client del certificato viene aggiornato dal CRL dal percorso remoto, anche se il CRL memorizzato nella cache nel client del certificato è valido. L'intervallo di timeout predefinito è un giorno, a meno che non si usi l'oggetto RevocationURLRetrievalTimeout per specificare un intervallo di timeout diverso (in minuti). Questo valore verrà ora archiviato in http.sys nell'oggetto PHTTP_edizione Standard RVICE_CONFIG_SSL_PARAM.
SecureBindings La proprietà SecureBindings specifica una stringa utilizzata da IIS per determinare quali endpoint di rete sicuri vengono utilizzati dall'istanza del server. Questa proprietà è ancora supportata in IIS 7.0 e versioni successive <> nella sezione binding per <i siti>. Il protocollo usato deve essere usato da "https".
SSLAlwaysNegoClientCert La proprietà SSLAlwaysNegoClientCert controlla le trattative di connessione client SSL. Se questa proprietà è impostata su true, ogni volta che vengono negoziate le connessioni SSL, il server negozierà immediatamente un certificato client, impedendo una rinegoziazione costosa. L'impostazione di SSLAlwaysNegoClientCert consente anche di eliminare i deadlock di rinegoziazione del certificato client, che possono verificarsi quando un client viene bloccato all'invio di un corpo di richiesta di grandi dimensioni quando viene ricevuta una richiesta di rinegoziazione. Questo valore verrà ora archiviato in http.sys nell'oggetto PHTTP_edizione Standard RVICE_CONFIG_SSL_PARAM.
SSLCertHash La proprietà SSLCertHash viene utilizzata per archiviare l'hash del certificato SSL in uso. Questo valore verrà ora archiviato in http.sys nell'oggetto PHTTP_edizione Standard RVICE_CONFIG_SSL_PARAM.
SslCtlIdentifier La proprietà SslCtlIdentifier contiene un valore univoco che identifica un elenco di attendibilità del certificato specifico (CTL). Deve essere usato con SslCtlStoreName per fare riferimento con precisione a un CTL. Questo valore verrà ora archiviato in http.sys nell'oggetto PHTTP_edizione Standard RVICE_CONFIG_SSL_PARAM.
SslCtlStoreName La proprietà SslCtlStoreName contiene il nome dell'archivio CryptoAPI che contiene elenchi di certificati attendibili (CTL). Deve essere usato con SslCtlIdentifier per fare riferimento con precisione a un CTL. Questo valore verrà ora archiviato in http.sys nell'oggetto PHTTP_edizione Standard RVICE_CONFIG_SSL_PARAM.
SSLStoreName La proprietà SSLStoreName viene utilizzata per archiviare il nome dell'archivio in cui risiede la coppia di chiavi del certificato. Questo valore verrà ora archiviato in http.sys nell'oggetto PHTTP_edizione Standard RVICE_CONFIG_SSL_PARAM.
SslUseDsMapper La proprietà SslUseDsMapper specifica se IIS deve utilizzare il mapper di certificati del servizio directory di Windows o il mapper di certificati IIS. Se SSLUseDSMapper è impostato su false, IIS usa il mapper di certificati IIS. Questo valore verrà ora archiviato in http.sys nell'oggetto PHTTP_edizione Standard RVICE_CONFIG_SSL_PARAM.

Per altre informazioni sull'oggetto HTTP.SYS PHTTP_edizione Standard RVICE_CONFIG_SSL_PARAM, vedere la documentazione seguente.

Tutte queste modifiche vengono gestite in modo trasparente sotto le quinte, in modo che un server Amministrazione istrator non c'è niente di speciale che è necessario fare--IIS farà tutto per l'utente. Se si dispone di applicazioni che accedono alle proprietà IIS 6.0 precedenti ora si trovano in HTTP. L'archivio di configurazione di SYS, l'interfaccia del mapper ABO garantisce che i valori corretti vengano letti/scritti in modo che le applicazioni non avranno esito negativo, ma continueranno a funzionare.

Elenco delle restrizioni dell'estensione del servizio Web

In IIS 7 e versioni successive questa funzionalità è stata leggermente modificata in modo che il nome ora legge "isapiCgiRestrictionList", ma in caso contrario funziona e si comporta come in IIS 6.0.

Il motivo di questa modifica era quello di sottolineare il suo vero utilizzo. In IIS 6.0 questa funzionalità è stata aggiunta per garantire che i file binari ISAPI o CGI non autorizzati non siano stati copiati nei server IIS e quindi possano essere eseguiti. Con la riprogettazione per IIS 7 e versioni successive sono disponibili due modelli supportati:

  • Pipeline ISAPI "classica"
  • Nuova pipeline integrata

Se ci si trova nella pipeline ISAPI "classica", tutto continuerà a funzionare come previsto quando si usa IIS 6.0. Per illustrare questo punto, considerare il funzionamento di ASP.NET durante l'esecuzione in modalità ISAPI. Prima di tutto è necessario aggiungere il percorso completo del aspnet_isapi.dll e impostarlo allowed="true" come illustrato di seguito:

<isapiCgiRestriction>
    <add path="F:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
    allowed="true" groupId="ASP.NET v2.0.50727" description="ASP.NET v2.0.50727" />
</isapiCgiRestriction>

Ora e solo ora questo codice (aspnet_isapi.dll) può essere eseguito. Se la modalità pipeline è stata impostata su integrated and changed allowed="false" il codice ASP.NET verrà comunque eseguito.

Perché? Il motivo è che isapiCgiRestrictionList si applica solo al codice ISAPI e CGI. In modalità integrata, ASP.NET fa ora parte della nuova architettura e di conseguenza non è interessato da isapiCgiRestrictionList. Se non si vuole eseguire ASP.NET codice nella nuova pipeline integrata, è sufficiente rimuovere managedEngine dall'elenco dei moduli.

Restrizioni IP

Le restrizioni IP funzionano esattamente come in passato, tranne che ora supportiamo una nuova proprietà denominata "allowUnlisted". Questa proprietà è stata aggiunta per semplificare la configurazione dei criteri di sicurezza per il sistema a livello globale. Ad esempio, se il criterio richiedeva solo determinati indirizzi IP per essere consentiti, ma rifiutare tutti gli altri che non sono elencati non era molto facile da fare in passato. Analogamente, rifiutare solo un determinato set di indirizzi IP e consentire tutto ciò che non sono elencati può essere eseguito facilmente ora. Come amministratore del server è possibile impostare un criterio globale e quindi bloccare questo valore in modo che non possa essere modificato nel server dagli amministratori dell'applicazione o del sito.

Per illustrare, si consideri un computer di sviluppo a cui si vuole accedere solo gli utenti in locale. La configurazione seguente implementa tale criterio impostando allowUnlisted="false" e quindi consente in modo esplicito solo l'accesso a localhost (127.0.0.1):

<system.webServer>
    <security>
        <ipSecurity allowUnlisted="false">
            <add ipAddress="127.0.0.1" allowed="true" />
        </ipSecurity>
    </security>
</system.webServer>