> Tech > Sites Web internes (2)

Sites Web internes (2)

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

En configurant un site Web pour qu’il demande l’authentification, on s’expose au problème suivant : les utilisateurs se voient sans cesse demander leurs références. Quand le site Web est configuré de manière à utiliser l’authentification Windows Integrated et si les utilisateurs se servent de IE, il est possible de configurer

Sites Web internes (2)

IE de manière à envoyer les références de l’utilisateur avec chaque connexion HTTP.

Par défaut, cette configuration est en vigueur pour les sites situés dans la zone intranet locale, comme on le voit dans la figure 3, page XX. Ajoutez simplement l’URL public de chaque site Web publié, à la zone intranet locale des utilisateurs dans IE. Malgré les apparences, ce scénario ne présente aucun risque: comme avec l’authentification Windows Integrated, les hashes NTLM sont utilisés et des références en texte clair ne sont pas échangées entre le navigateur et le site Web.

Si vous craignez qu’un hash NTLM envoyé sur le réseau lors d’une tentative de connexion HTTP risque d’être utilisé pour obtenir le mot de passe d’un utilisateur, vous pouvez employer SSL pour empêcher l’interception du hash NTLM. Si la connexion SSL n’est pas terminée au niveau du parefeu mais plutôt sur le site Web lui-même, vous pouvez configurer le site Web de manière à demander aux utilisateurs de s’authentifier à l’aide d’un certificat client (TLS). Dans ce cas, un utilisateur doit avoir un certificat X.509v3 émis par une CA (Certification Authority) approuvée par le site Web.

Ce certificat peut servir à l’authentification client. Si vous n’avez pas une PKI (Public Key Infrastructure) capable de délivrer des certificats aux utilisateurs, je vous conseille de jeter un coup d’oeil aux propres Certificate Services de Microsoft qui accompagnent Windows 2003 et Win2K. L’utilisation de SSL avec TLS présente plusieurs avantages. Le premier est que les utilisateurs n’ont pas besoin d’entrer leurs références : ils utilisent à la place un certificat. Deuxièmement, la plupart des navigateurs sur presque toutes les plates-formes client supportent SSL avec TLS.

Troisièmement, les certificats peuvent être utilisés pour s’authentifier en utilisant SSL/TLS avec des serveurs Web autres que IIS 6.0 (comme Apache). Quatrièmement, il est possible d’associer les certificats émis par des CA tierces à des comptes utilisateur, ce qui vous dispense d’établir et de maintenir une PKI. Enfin, un certificat sur une carte intelligente ou un jeton (par exemple un Rainbow iKey) peut être utilisé, ce qui permet aux utilisateurs de travailler sur n’importe quelle machine sans devoir entrer des références susceptibles d’être enregistrées par un keylogger ou autre spyware. (Pour utiliser une carte intelligente, la machine devrait avoir un lecteur de carte intelligente. Tandis qu’un jeton du genre iKey serait simplement enfiché dans un port USB libre.)

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010