Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
par l'équipe IIS
Introduction
Les versions 7 et ultérieures d'IIS apportent de nombreuses améliorations en matière de sécurité par rapport à la version 6.0. Le présent document donne un aperçu des améliorations relatives à l'authentification, l'autorisation, le protocole SSL, la liste de restrictions des extensions de services Web et les restrictions d'IP.
Authentification
Avant IIS 7, les développeurs d'applications ASP.NET devaient effectuer la programmation en fonction de deux modèles d'authentification. Ces modèles étaient les pipelines IIS et ASP.NET. IIS examinait d'abord la requête et exécutait ses routines d'authentification, puis transmettait la requête à ASP.NET afin qu'il puisse effectuer une tâche similaire.
Dans IIS 7 et les versions ultérieures, nous avons unifié ces deux modèles de manière à produire un nouveau pipeline robuste reprenant ce que les deux anciens modèles faisaient de mieux. IIS prend toujours en charge tous les anciens protocoles d'authentification, mais également l'authentification par formulaire, qui peut protéger contre tous les types de contenu et ne dépend pas des comptes Windows. Outre la prise en charge de toutes les anciennes fonctions que vous connaissez et appréciez, nous avons également amélioré certaines d'entre elles, notamment la fonction d'authentification anonyme.
Ces changements seront examinés dans les sections suivantes.
Changements apportés à l'authentification anonyme
Dans IIS 7 et les versions ultérieures, l'authentification anonyme se comporte de la même manière que dans les versions précédentes, avec un seul changement : la possibilité de fonctionner sous le contenu de l'identité du processus de travail. Chaque pool d'applications est configuré de manière à fonctionner sous le contenu d'un compte d'utilisateur et la valeur par défaut de ce compte est NETWORKSERVICE.
Il était très courant que les applications ASP.NET désactivent l'usurpation d'identité et s'exécutent sous l'identité du pool d'applications en utilisant le code suivant dans leurs fichiers web.config :
<identity impersonate="false"/>
Dans de nombreux scénarios, les applications devaient s'exécuter dans le contexte de l'identité du processus :
- L'identité du processus est un compte à faible privilège et les administrateurs ont verrouillé leurs systèmes pour ce compte.
- L'identité du processus a été autorisée à accéder au réseau. Elle est utilisée pour accéder à des ressources back end telles que des bases de données.
Dans le cadre de la re-conception d'IIS 7 et des versions ultérieures, nous avons voulu rendre ce scénario sûr et facile à réaliser. Pour mettre en œuvre ce scénario dans IIS, il faut :
- installer et activer le module d'authentification anonyme
- définir le nom d'utilisateur anonyme et le mot de passe comme une chaîne vide.
Pour ce faire, modifiez votre configuration pour l'authentification anonyme de manière à ce qu'elle apparaisse comme suit :
<anonymousAuthentication enabled="true" userName="" defaultLogonDomain="" />
Cette configuration indiquera à IIS de toujours s'exécuter dans le contexte de l'identité du processus travailleur.
Par défaut, l'identité d'authentification anonyme dans IIS 7.0 et les versions ultérieures est le compte IUSR. Ce compte est une identité à faible privilège avec des droits et des privilèges minimaux. Pour en savoir plus sur le nouveau compte intégré, reportez-vous à l'article Comprendre le compte et le groupe intégrés dans IIS 7 et les versions ultérieures.
Modifications apportés à Passport
La prise en charge de l'ancienne authentification Passport a été intégrée dans IIS 5/6 et Windows Server 2000 et 2003. Dans IIS 5 et 6, la prise en charge de Passport se présentait sous forme d'une case à cocher dans l'onglet Sécurité du répertoire du gestionnaire de services IIS pour « Activer l'authentification Passport ». Cette case à cocher permettait à IIS d'envoyer des tests hérités du protocole Tweener. En outre, il fallait encore enregistrer le site Web auprès du portail d'approvisionnement du service de Passport, obtenir une clé de chiffrement et configurer l'ancien gestionnaire de Passport sur le serveur pour que l'intégration de IIS devienne fonctionnelle.
Dans Windows Server 2008 et les versions ultérieures, les anciens binaires Passport et l'intégration avec IIS ont été supprimés.
Le service Passport est maintenant devenu Windows Live ID. Bien que le nouveau service Live ID soit issu de l'ancien service Passport, il y a des changements majeurs. L'un des changements les plus importants concerne la manière dont un site partenaire s'intègre à Live ID. Vous pouvez ajouter l'authentification Live ID en utilisant le SDK d'authentification Web Windows Live ID disponible pour le grand public. Même si le service Windows Live ID prend aussi en charge la fédération d'identité et l'ADFS, cette capacité est une nouvelle fonctionnalité pour des cas spécifiques et ne remplace pas « Passport ».
authentification par formulaires
L'authentification par formulaire fait partie de ASP.NET et permet aux identités Windows et non Windows de s'authentifier et d'obtenir un objet utilisateur que les applications peuvent ensuite utiliser. Les versions 7 et supérieures d'IIS prennent désormais entièrement en charge l'authentification par formulaire et peuvent être configurées pour protéger l'accès à tous les types de contenu.
Méthode utilisée par IIS 7 et les versions ultérieures pour déterminer l'identité authentifiée
Dans IIS 7 et les versions ultérieures, les règles d'authentification sont traitées par le moteur principal de la même manière que dans les versions précédentes d'IIS, à part quelques modifications mineures. Pour mieux comprendre l'ordre de traitement, en fonction de l'ordre dans lequel IIS les évalue :
- Tout d'abord, IIS détermine si un nom d'utilisateur et un mot de passe ont été configurés dans le répertoire virtuel. Si un ensemble d'informations d'identification a été défini, ces informations seront utilisées. Pour les administrateurs antérieurs à IIS 7, ces informations d'identification sont les informations d'identification UNC.
- Si aucun identifiant n'est configuré dans le répertoire virtuel, IIS utilise les identifiants fournis lors de l'authentification. Ces informations peuvent appartenir à l'identité configurée pour l'authentification anonyme ou aux informations d’identification fournies par l'utilisateur au moment de l'établissement d'une liaison par authentification si l'authentification de base Digest ou Windows est activée
- Si aucun utilisateur authentifié n'a été établi (par exemple au cas où l'authentification par formulaire est activée), nous déterminerons si l'identité du processus doit être utilisée
- Si nous n'avons pas d'identité à ce stade, IIS renverra un message indiquant que l’accès est refusé.
Autorisation
Support AzMan
Si nous n'avons pas d'identité à ce stade, IIS 6.0 renverra un message indiquant que l’accès est refusé. Dans IIS 7 et les versions ultérieures, nous avons supprimé cette fonctionnalité en faveur d'un nouveau modèle très similaire au modèle d'autorisation ASP.NET (voir la rubrique relative à l'autorisation d'URL ci-dessous).
Autorisation URL
Dans les versions 7 et ultérieures d'IIS, vous disposez de deux solutions en matière d'autorisation. La première consiste à utiliser le modèle d'autorisation ASP.NET. Cette méthode nécessite de définir toutes vos règles d'autorisation dans la configuration <system.web> et ne requiert aucun changement pour les applications qui ont déjà des règles écrites pour ASP.NET. Le second modèle consiste à passer à la nouvelle architecture d'autorisation IIS. Ce modèle est très semblable au modèle ASP.NET avec quelques changements mineurs :
- Les règles ne dépendent pas de l’ordre.
- Les règles de refus sont triées en haut de la liste.
- Les règles sont traitées à l'inverse d'ASP.NET, principalement dans l'ordre : grand-parent, parent, puis enfant ; l'autorisation ASP.NET traite les règles dans l'ordre inverse : enfant, parent, puis grand-parent
Pour mieux comprendre les différences entre le modèle d'autorisation ASP.NET et le modèle d'autorisation IIS, examinons d'abord une configuration d'autorisation ASP.NET :
<authorization>
<allow users="Vik_Malhotra" />
<deny roles="administrators" />
<deny users="*" />
</authorization>
Dans cet exemple, nous autorisons Vik_Malhotra et nous refusons tous les autres. Dans IIS, la configuration est très semblable :
<authorization>
<add accessType="allow" users="Vik_Malhotra" />
<add accessType="deny" roles="administrators" />
<add accessType="deny" users="*" />
</authorization>
La raison de ce changement de syntaxe est que nous voulions nous assurer que les développeurs d'applications savaient que ces deux modèles sont en fait différents, tout en leur permettant de déplacer les règles d'une implémentation à l'autre avec un minimum d'effort.
SSL
Dans IIS 6.0, IIS a stocké les informations relatives à SSL dans la métabase et a géré une grande partie du processus de négociation SSL en conjonction avec HTTP.SYS. Dans IIS 7 et les versions ultérieures, nous avons déplacé la majeure partie de cette configuration dans le magasin HTTP.SYS.
Le tableau ci-dessous a été élaboré pour illustrer la manière dont chacun des paramètres de configuration d'IIS 6.0 est repris dans la configuration d'IIS 7 et des versions ultérieures (ou dans la configuration de HTTP.SYS).
| Configuration de métabase IIS 6.0 | Description de la propriété | Architecture des versions IIS 7.0 et ultérieures |
|---|---|---|
| AccessSSLFlags | AccessSSLFlags est un masque de bits d’AccessSSL AccessSSL128 AccessSSLNegotiateCert AccessSSLRequireCert AccessSSLMapCert La valeur 0 signifie qu'il n'y a pas de SSL. | Propriété toujours prise en charge dans la configuration de IIS 7.0 et des versions ultérieures de la section d'<accès> |
| CertCheckMode | Activer ou désactiver la vérification de la liste de révocation de certificats (Certificate Revocation List, CRL). | Cette valeur sera désormais stockée dans http.sys dans l'objet PHTTP_SERVICE_CONFIG_SSL_PARAM. |
| RevocationFreshnessTime | Si la propriété RevocationFreshnessTime a la valeur 1 (vrai), la liste de révocation de certificats (CRL) du client de certificat est mise à jour par la CRL provenant de l'emplacement distant, même si la CRL mise en cache sur le client de certificat est valide. L'intervalle de temps par défaut est d'un jour, sauf si vous utilisez RevocationURLRetrievalTimeout pour indiquer un intervalle de temps différent (en minutes). | Cette valeur sera désormais stockée dans http.sys sous l'objet PHTTP_SERVICE_CONFIG_SSL_PARAM. |
| SecureBindings | La propriété SecureBindings spécifie une chaîne utilisée par IIS pour déterminer quels points d'extrémité du réseau sécurisé sont utilisés par l'instance de serveur. | Cette propriété est toujours prise en charge dans la configuration d'IIS 7.0 et ultérieures sous la section de <liaison> pour les <sites>. Le protocole utilisé doit être « https ». |
| SSLAlwaysNegoClientCert | La propriété SSLAlwaysNegoClientCert contrôle les négociations des connexions client SSL. Si cette propriété a la valeur « vrai », à chaque fois que des connexions SSL sont négociées, le serveur négocie immédiatement un certificat client, ce qui évite une renégociation coûteuse. La définition de SSLAlwaysNegoClientCert permet également d'éliminer les blocages de renégociation de certificat client, qui peuvent se produire lorsqu'un client est bloqué sur l'envoi d'un corps de requête volumineux lors de la réception d'une demande de renégociation. | Cette valeur sera désormais stockée dans http.sys sous l'objet PHTTP_SERVICE_CONFIG_SSL_PARAM. |
| SSLCertHash | La propriété SSLCertHash est utilisée pour stocker le code de hachage du certificat SSL utilisé. | Cette valeur sera désormais stockée dans http.sys sous l'objet PHTTP_SERVICE_CONFIG_SSL_PARAM. |
| SslCtlIdentifier | La propriété SslCtlIdentifier contient une valeur unique qui identifie une liste de certificats de confiance (Certificate Trust List, CTL) spécifique. Elle doit être utilisée avec la propriété SslCtlStoreName pour référencer correctement une CTL. | Cette valeur sera désormais stockée dans http.sys sous l'objet PHTTP_SERVICE_CONFIG_SSL_PARAM. |
| SslCtlStoreName | La propriété SslCtlStoreName contient le nom du magasin CryptoAPI qui contient les listes de certificats de confiance (CTL). Elle doit être utilisée avec SslCtlIdentifier pour référencer correctement une CTL. | Cette valeur sera désormais stockée dans http.sys sous l'objet PHTTP_SERVICE_CONFIG_SSL_PARAM. |
| SSLStoreName | La propriété SSLStoreName est utilisée pour stocker le nom du magasin où réside la paire de clés du certificat. | Cette valeur sera désormais stockée dans http.sys sous l'objet PHTTP_SERVICE_CONFIG_SSL_PARAM. |
| SslUseDsMapper | La propriété SslUseDsMapper spécifie si IIS doit utiliser le mappeur de certificats du service d'annuaire Windows ou le mappeur de certificats IIS. Si SSLUseDSMapper a la valeur « false » (faux), IIS utilise le mappeur de certificats IIS. | Cette valeur sera désormais stockée dans http.sys sous l'objet PHTTP_SERVICE_CONFIG_SSL_PARAM. |
Pour plus d'informations sur l'objet HTTP.SYS PHTTP_SERVICE_CONFIG_SSL_PARAM, reportez-vous à la documentation suivante.
Tous ces changements sont gérés de manière transparente sous les descripteurs, de sorte qu'en tant qu'administrateur de serveur, vous n'avez rien de spécial à faire : IIS fera tout pour vous. Si certaines de vos applications accèdent aux anciennes propriétés d'IIS 6.0 qui se trouvent désormais dans le magasin de configuration de HTTP.SYS, notre interface ABO mapper s'assurera que les valeurs correctes sont lues/écrites afin que vos applications continuent à fonctionner sans tomber en panne.
Liste des restrictions d’extension de service Web
Dans IIS 7 et les versions ultérieures, cette fonctionnalité a été légèrement modifiée et son nom est désormais « isapiCgiRestrictionList » ; pour le reste, elle agit et se comporte de la même manière que dans IIS 6.0.
Ce changement a pour but de mettre l'accent sur sa véritable utilisation. Dans IIS 6.0, cette fonctionnalité a été ajoutée pour éviter que des binaires ISAPI ou CGI malveillants puissent être copiés sur vos serveurs IIS et autorisés à s'exécuter. Avec la nouvelle conception pour IIS 7 et plus, deux modèles sont pris en charge :
- le pipeline ISAPI « classique » ;
- le nouveau pipeline intégré.
Si nous sommes dans le pipeline ISAPI « classique », tout continuera à fonctionner comme c’était le cas avec IIS 6.0. Pour illustrer ce point, examinons le fonctionnement d'ASP.NET en mode ISAPI. Il faut tout d'abord ajouter le chemin complet de la dll aspnet_isapi.dll et définir allowed=« vrai » comme indiqué ci-dessous :
<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>
Dès ce moment uniquement, le code (aspnet_isapi.dll) sera autorisé à s'exécuter. Si nous avons changé notre mode de pipeline en mode intégré et modifié allowed=« faux », le code ASP.NET sera toujours exécuté.
Pourquoi ? Cela est dû au fait que l'isapiCgiRestrictionList ne s'applique qu'au code ISAPI et CGI. En mode intégré, ASP.NET fait désormais partie de la nouvelle architecture et n'est donc pas affecté par la isapiCgiRestrictionList. Si vous ne souhaitez pas exécuter le code ASP.NET dans le nouveau pipeline intégré, il suffit de supprimer le managedEngine de la liste des modules.
Restrictions d’IP
Les restrictions IP fonctionnent exactement de la même manière que par le passé, sauf que nous prenons désormais en charge une nouvelle propriété appelée « allowUnlisted ». Cette propriété a été ajoutée pour faciliter la configuration des politiques de sécurité pour votre système à un niveau global. Par exemple, si votre politique exigeait que seules certaines adresses IP soient autorisées et que toutes les autres adresses non répertoriées soient rejetées, cela n’était pas simple à réaliser par le passé. En outre, il est désormais facile de rejeter uniquement un ensemble donné d'adresses IP et d'autoriser toutes celles qui ne figurent pas sur la liste. En tant qu'administrateur de serveur, vous pouvez définir une stratégie globale, puis verrouiller cette valeur afin qu'elle ne puisse pas être modifiée sur votre serveur par les administrateurs d'applications ou de sites.
Pour illustrer ce propos, prenons l'exemple d'une machine de développement à laquelle les utilisateurs ne doivent pouvoir accéder que localement. La configuration suivante met en œuvre cette politique en définissant la valeur allowUnlisted = « faux », puis en n'autorisant explicitement que l'accès à localhost (127.0.0.1) :
<system.webServer>
<security>
<ipSecurity allowUnlisted="false">
<add ipAddress="127.0.0.1" allowed="true" />
</ipSecurity>
</security>
</system.webServer>