possibilités de rebond (via des règles de filtrage), ainsi que des limitations applicatives.
En règle générale, il ne faut jamais offrir une connectivité IP totale à un tiers. Il faut le
cloisonner au strict nécessaire. Un travail soigneux d’architecture doit donc être entrepris
au préalable. D’ailleurs, rien n’empêche de prendre cette précaution pour les connexions
entre deux entités du même groupe.
Il faut signaler que toutes ces solutions nécessitent un équipement spécifique sur chaque
site (routeur, tête de tunnel, etc.), avec une concertation préalable entre les différentes
entités amenées à communiquer.
Publication d’applications sur Internet
Tous les utilisateurs distants ne requièrent pas forcément d’avoir accès à l’intégralité du
SI. D’ailleurs, ils n’ont pour la plupart besoin d’accéder qu’à un ensemble très limité de
ressources. Il s’agit généralement d’utiliser la messagerie, de consulter l’intranet et
d’accéder à quelques applications métier incontournables.
En revanche, l’utilisateur distant est susceptible de se connecter depuis son domicile ou
en déplacement. On ne peut donc pas l’identifier par son adresse IP ou par un routeur
spécifique spécialement configuré pour lui.
Pour répondre à ce besoin, la solution courante consiste à publier sur Internet les
applications nécessaires. Le serveur s’authentifie auprès du client en présentant son
certificat. À son tour, le client s’authentifie auprès du serveur en saisissant son identifiant
puis son mot de passe. La suite des échanges est chiffrée via les protocoles SSL ou TLS.
Pour accéder à des services jugés sensibles, il est possible de renforcer l’authentification
du client, soit en lui imposant un certificat client, soit en utilisant un token (que ce
dernier soit physique ou logique).
La publication de ces applications sur Internet offre une grande flexibilité, mais elle les
expose directement aux attaques. Un soin particulier doit être porté sur leur résistance
aux tentatives de cross site scripting, d’injections SQL et autres attaques courantes. Les
serveurs fournissant le service doivent être installés dans des DMZ. La configuration de
ces équipements doit être soignée.
Tunnel client
Certains utilisateurs distants ne peuvent se contenter d’un accès aussi restreint aux
ressources du SI. C’est le cas des administrateurs qui, par la nature de leur fonction, sont
amenés à accéder à tout le SI.
Dans ce cas, une solution consiste à monter un tunnel entre l’utilisateur distant et le SI.
Bien que transitant via un réseau public, les flux sont encapsulés dans le tunnel. Ainsi,
l’utilisateur dispose d’une adresse publique, qu’il utilise pour accéder à la destination, et
d’une adresse interne au SI, encapsulée dans le tunnel. Il peut donc accéder à tout le
réseau comme s’il était à l’intérieur de l’entreprise, pour peu qu’aucun dispositif de
filtrage explicitement placé à cet effet ne l’en empêche.
Comme pour la solution précédente, le serveur s’authentifie généralement auprès du
client en présentant un certificat. Quant à l’utilisateur distant, il peut s’identifier soit en
En règle générale, il ne faut jamais offrir une connectivité IP totale à un tiers. Il faut le
cloisonner au strict nécessaire. Un travail soigneux d’architecture doit donc être entrepris
au préalable. D’ailleurs, rien n’empêche de prendre cette précaution pour les connexions
entre deux entités du même groupe.
Il faut signaler que toutes ces solutions nécessitent un équipement spécifique sur chaque
site (routeur, tête de tunnel, etc.), avec une concertation préalable entre les différentes
entités amenées à communiquer.
Publication d’applications sur Internet
Tous les utilisateurs distants ne requièrent pas forcément d’avoir accès à l’intégralité du
SI. D’ailleurs, ils n’ont pour la plupart besoin d’accéder qu’à un ensemble très limité de
ressources. Il s’agit généralement d’utiliser la messagerie, de consulter l’intranet et
d’accéder à quelques applications métier incontournables.
En revanche, l’utilisateur distant est susceptible de se connecter depuis son domicile ou
en déplacement. On ne peut donc pas l’identifier par son adresse IP ou par un routeur
spécifique spécialement configuré pour lui.
Pour répondre à ce besoin, la solution courante consiste à publier sur Internet les
applications nécessaires. Le serveur s’authentifie auprès du client en présentant son
certificat. À son tour, le client s’authentifie auprès du serveur en saisissant son identifiant
puis son mot de passe. La suite des échanges est chiffrée via les protocoles SSL ou TLS.
Pour accéder à des services jugés sensibles, il est possible de renforcer l’authentification
du client, soit en lui imposant un certificat client, soit en utilisant un token (que ce
dernier soit physique ou logique).
La publication de ces applications sur Internet offre une grande flexibilité, mais elle les
expose directement aux attaques. Un soin particulier doit être porté sur leur résistance
aux tentatives de cross site scripting, d’injections SQL et autres attaques courantes. Les
serveurs fournissant le service doivent être installés dans des DMZ. La configuration de
ces équipements doit être soignée.
Tunnel client
Certains utilisateurs distants ne peuvent se contenter d’un accès aussi restreint aux
ressources du SI. C’est le cas des administrateurs qui, par la nature de leur fonction, sont
amenés à accéder à tout le SI.
Dans ce cas, une solution consiste à monter un tunnel entre l’utilisateur distant et le SI.
Bien que transitant via un réseau public, les flux sont encapsulés dans le tunnel. Ainsi,
l’utilisateur dispose d’une adresse publique, qu’il utilise pour accéder à la destination, et
d’une adresse interne au SI, encapsulée dans le tunnel. Il peut donc accéder à tout le
réseau comme s’il était à l’intérieur de l’entreprise, pour peu qu’aucun dispositif de
filtrage explicitement placé à cet effet ne l’en empêche.
Comme pour la solution précédente, le serveur s’authentifie généralement auprès du
client en présentant un certificat. Quant à l’utilisateur distant, il peut s’identifier soit en