I.2.12.2. Proxy et les Reverse Proxy
Les Proxy permettent d'une part, de relayer le trafic entre
Internet et un réseau protégé et d'autre part, ils
effectuent un enregistrement intermédiaire de données à
des points définis d'Internet. La meilleure utilisation de cette
technique est apparue avec les serveurs Web. Avec sa technique de cache, un
Proxy permet de recevoir les pages Web plus rapidement car celles-ci sont
directement activées depuis un Proxy proche de l'émetteur de la
requête HTTP.
Le Reverse Proxy est un mécanisme de contrôle
d'accès récemment apparu. Si le Proxy est un mécanisme de
filtrage des connexions sortantes d'une entreprise, le Reverse Proxy est le
mécanisme inverse qui permet de filtrer toutes les connexions des
utilisateurs vers un ensemble d'applications. Un serveur Reverse Proxy permet
la réalisation des VPNs au niveau applicatif tout en se basant sur un
protocole de sécurité comme SSL/TLS ou SSH. La figure I.3
illustre l'Architecture des Proxy et des reverse Proxy.
Fig. I.3. Architecture des Proxy et des reverse Proxy
Actuellement les protocoles de sécurité sont
plus adaptés à ces deux mécanismes largement
déployés dans les réseaux des entreprises. Nous pouvons
citer dans ce domaine l'utilisation conjointe du protocole IPSec avec les
Firewalls et l'utilisation du protocole SSL/TLS avec les Reverse Proxy. Ils
permettent ainsi de fournir des mécanismes plus robustes pour
l'authentification et le contrôle d'accès des
utilisateurs externes avant de pouvoir accéder au
réseau interne de l'entreprise. I.2.13. Gestion des
«délégations» entre acteurs
Les points d'accès jouent le rôle d'un point
d'authentification pour les utilisateurs qui se connectent au réseau
interne des entreprises. Les solutions de sécurité telles que
SSL/TLS et SSH essaient de s'adapter a ce type de connexion en
présentant les entités intermédiaires comme des
entités de confiance et en faisant un double tunnel de
sécurité pour assurer une sécurité de bout en bout
des données. Cependant, la problématique d'une telle approche
vient du fait que dans des scénarios où une application finale A
souhaite déléguer le rôle d'authentification a une autre
entité B. Cette dernière doit présenter un certificat de
délégation d'un rôle d'authentification émis par
l'application A ou par une infrastructure de gestion des privilèges.
Pour cela, nous proposons l'utilisation d'un mécanisme de
délégation des droits basé sur les infrastructures de
gestion des privilèges et les certificats d'attribut. Par
délégation, nous entendons dire l'autorisation donnée par
une entité finale A (normalement le serveur destinataire) à une
entité intermédiaire B pour pouvoir exercer un mécanisme
d'authentification et de contrôle d'accès a sa place.
Un tel mécanisme permet d'offrir a l'utilisateur une
preuve de l'identité et des rôles associés a
l'entité intermédiaire B. Notons ainsi que, dans le cas ou les
passerelles sont éloignées des serveurs origines (cas de
distribution de contenu dans Internet), la délégation du
rôle d'authentification aux différentes passerelles peut jouer un
rôle important pour la minimisation des bandes passantes vers le serveur
Web d'application. La vérification formelle des protocoles de
sécurité Au cours des dernières années,
différents protocoles cryptographiques ont été mis en
oeuvre pour répondre aux exigences demandées, mais la
difficulté de la conception de ces protocoles vient du fait que les
messages échangés peuvent être écoutés par
une tierce personne, interceptés ou modifiés. Afin d'assurer que
ces protocoles soient protégés contre des attaques pareilles, un
nouveau domaine de sécurité est apparu. C'est la
modélisation et la vérification des protocoles
cryptographiques.
L'extensibilité du protocole, un protocole est dit
extensible s'il permet de fournir des nouveaux services sans avoir à
changer sa structure de conception. Le grand intérêt de cette
option a poussé les nouveaux successeurs des protocoles de
sécurité (comme TLS Extensions) et des protocoles
d'échange des clés (comme IKEv2) a ajouter des échanges ou
des messages génériques dans leur phase d'initialisation. Ces
messages permettent à ces protocoles de négocier durant leurs
phases d'initialisation, des nouveaux services tels que l'URL des certificats
et les HMAC tronqués. Ces messages sont dans la plupart des cas,
déclenchés du coté de l'émetteur qui propose la
négociation d'un ou de plusieurs services optionnels. Ceci permet de
garder une interopérabilité entre les entités qui
supportent ces services et celles qui ne les supportent pas. La Figure I.4
illustre l'Exemple de délégation entre un serveur d'application
et une passerelle.
Fig. I.4. Exemple de délégation entre un
serveur d'application et une passerelle I.3.
CONCLUSION
Dans ce chapitre, nous avons défini les principales
exigences qu'un protocole de sécurité doit assurer. Ces exigences
sont nécessaires pour de nombreuses applications telles que le commerce
électronique, l'accès distant a une machine ou a certaines
parties d'un site contenant des informations confidentielles. En se basant sur
ces exigences, nous allons comparer dans le chapitre suivant, les trois
principales solutions de sécurité suivantes : IPSec, SSH et
SSL/TLS.
| 
