> Tech > Sites Web internes

Sites Web internes

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

Beaucoup d’entreprises créent des sites Web intranet pour partager des informations en interne (dates de vacances, répertoires téléphoniques d’entreprise, par exemple) entre membres d’une même équipe ou comme sites de référence interne pour documenter des stratégies, des tarifs de produits, services, etc. Souvent, ces sites Web sont largement ouverts à

Sites Web internes

tous les utilisateurs, avec peu ou pas de contrôle d’accès. On peut admettre l’accès libre pour des sites Web accessibles uniquement de l’intérieur du LAN.

En revanche, il ne faut pas que de tels sites soient publiés sur Internet sans instaurer un contrôle d’accès, particulièrement si les données sont confidentielles ou sensibles. C’est pour cela que certaines entreprises adoptent un VPN. Les utilisateurs doivent s’authentifier pour établir une connexion VPN, après quoi ils peuvent accéder anonymement aux sites Web internes. Pourtant, là aussi, d’autres solutions existent.

Si les sites Web sont hébergés sur des serveurs Web IIS 6.0 qui sont des serveurs membres dans le même domaine ou la même forêt que les utilisateurs, l’administrateur du serveur Web peut désactiver l’authentification anonyme et demander aux utilisateurs de s’authentifier. Si la méthode d’authentification préférée pour un site Web est Integrated Windows, le site Web peut être publié sur Internet par l’intermédiaire d’un pare-feu.

Si ce dernier est au niveau application (comme ISA Server 2006), vous pouvez configurer des règles d’accès telles que seules certaines parties des répertoires d’un site Web soient accessibles à partir d’Internet, et le trafic HTTP peut être analysé pour y détecter un éventuel trafic Web malveillant. Quand un utilisateur tentera de se connecter au site Web, il devra montrer patte blanche, c’està- dire fournir des références. Je recommande d’utiliser un certificat SSL pour garantir la confidentialité des données échangées entre le site Web et le navigateur de l’utilisateur.

Avec ISA Server, il est possible de mettre fin à la session SSL au niveau du parefeu, puis de déléguer la connexion vers le site Web. Le certificat SSL pour le site Web est installé dans ISA Server, lequel imite le site Web vis-à-vis du navigateur de l’utilisateur. Cette configuration présente un triple avantage : elle permet à ISA Server d’analyser le trafic vers le site Web, elle impose les restrictions d’accès en fonction des chemins, et elle traque tout contenu douteux.

Avec un certificat SSL en place, vous pouvez aussi valider l’authentification Basic vis-à-vis des sites Web. Bien que vous puissiez configurer cette authentification sans certificat SSL, je le déconseille parce que les références des utilisateurs seront transmises en clair entre leur navigateur et le site Web.

L’authentification Basic est utile parce qu’elle permet aux utilisateurs qui ont un client non Windows ou des navigateurs autres que Microsoft Internet Explorer (IE), de se connecter à des sites Web. C’est vrai, l’authentification basique présente aussi un inconvénient : si la connexion SSL se termine au niveau du pare-feu, la connexion entre le pare-feu et le site Web sur le réseau interne n’est pas cryptée et donc un utilisateur malveillant avec un moniteur de réseau (ou un utilisateur interne mal intentionné) pourra capturer des références à moins que le pare-feu ne puisse établir une connexion SSL entre lui-même et le site Web.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

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