Le problème examiné au microscope

des commande) aux ordinateurs,
serveurs, et autres routeurs et
commutateurs. Pour l’iSeries, cela inclut
les clients de ligne de commande
interactive comme Client Access,
l’émulation de terminal 5250 (sous
toutes ses formes – SNA, Telnet et terminaux
5250 de type Web) et l’exécution
de commandes via FTP. Pour des
systèmes Windows, c’est l’environnement
desktop qu’il faut sécuriser. Unix
possède à  la fois des commandes interactives
en formes multiples et l’environnement
desktop X Windows, qui
peuvent être invoqués à  distance sur
n’importe quel chemin TCP/IP. La plupart
des autres unités sont accessibles
et contrôlables via les protocoles standard
Internet, Telnet, SNMP, et HTTP.
Tous doivent être protégés par mot de
passe.

L’accès au niveau des commandes
est critique parce que, dès qu’il est
compromis, un intrus peut accéder à 
une multitude d’outils qui sont autant
d’armes antisécurité. Selon l’importance
des droits exposés, un acteur
malveillant peut endommager d’autres
systèmes de manière presque illimitée.
Par exemple, en accédant à  la racine
d’un système Unix, un assaillant peut
superviser le trafic de tous les autres
utilisateurs de ce système, ainsi que le
trafic de tous les systèmes avec lesquels
le système violé communique.
Lors des réunions (ou des universités
?) de pirates, on voit des tee-shirts
noirs arborant « got root? » (avez-vous
la racine ?) en grosses lettres blanches.
L’importance de l’accès au niveau des
commandes est bien connue.

Après l’accès au niveau des commandes,
le service suivant le plus important
à  sécuriser par l’authentification
est l’accès aux utilisateurs distants. Jadis, il s’agissait d’appeler des services
terminaux, offrant un point d’entrée à 
distance via des lignes téléphoniques
pour les utilisateurs éloignés. Mais
avec l’arrivée des réseaux privés virtuels
(VPN, virtual private networks),
on a aussi des connexions VPN sur
Internet. Une identification d’accès à 
distance ne donne généralement pas à 
un utilisateur l’accès aux systèmes individuels
d’un réseau protégé. En revanche,
elle permet à  un assaillant
d’utiliser votre LAN privé, ce sanctuaire
que vous avez à  grands frais bardé de
pare-feu et de systèmes de détection
d’intrusion.

Après la sécurité au niveau des
commandes et au niveau de l’accès,
vient la sécurité des applications. La
plus répandue d’entre elles est le email
et vous connaissez probablement
le concept d’une ID et mot de passe
e-mail pour consulter la messagerie
électronique. D’autres interfaces d’application
nécessitent aussi l’authentification
: les pages Web intranet et extranet,
les applets de type Java et les
serveurs d’applications interactives
comme Citrix Winframe.

Enfin, on trouve l’authentification
nécessaire entre les composants d’applications
distribuées. Un serveur de
base de données ODBC, par exemple,
doit vérifier que chaque requête provient
d’une application autorisée. Les
serveurs d’applications Web, comme
WebSphere, communiquent souvent entre eux – un autre échange exigeant
l’authentification. Les mots de passe
d’application posent un problème de
sécurité particulier : comment stocker
des mots de passe en toute sécurité
pour empêcher qu’un seul serveur
compromis n’ouvre grand les vannes
vers tout un groupe de serveurs d’applications.

Ce sont là  les bases du paysage de
l’authentification – le champ de bataille
où il faut mener la guerre de la sécurité
de l’information. Vous voilà 
donc prêts à  étudier de possibles solutions.
Sachez quand même qu’il
n’existe pas d’arme absolue. Vous ne
trouverez pas une solution capable de
répondre à  tous les besoins d’authentification
par mot de passe. En revanche,
vous tirerez des enseignements de solutions
partielles susceptibles de réduire
la complexité du problème de
l’authentification.