Des données sous bonne garde avec Kerberos

Si votre application utilise les logins
SQL Server, le client envoie le mot de
passe au serveur en texte clair. (Avec
SQL Server 2000, le mot de passe est
crypté pendant le handshake par défaut.)
Pour protéger le mot de passe
pendant la transmission, il faut utiliser
l’un des trois cryptages suivants :
Multiprotocol Net-Library, SSL (Secure Sockets Layer) ou IPSec (IP Security).
Des trois, seul IPSec peut être géré
pour toute l’entreprise au moyen des
politiques de domaines. Multiprotocol
Net-Library présente deux inconvénients
: les clients peuvent choisir de
ne pas l’utiliser si le serveur prend en
charge toute autre Net-Library, et il ne
fonctionne que vis-à -vis de l’instance
par défaut. Quant à  SSL, le fait qu’il
exige un certificat séparé pour chaque
serveur peut alourdir l’administration
en présence de multiples serveurs.
Pour une comparaison entre IPSec et
Kerberos, voir l’encadré « IPSec face à 
Kerberos ».

A contrario, les logins authentifiés
Windows utilisent les protocoles d’authentification
de Windows, lesquels
cryptent toujours l’information d’identification de l’utilisateur. Le cryptage
du mot de passe empêche quiconque
d’imiter un utilisateur. Le protocole
d’authentification Kerberos
applique des algorithmes de cryptage
plus puissants que le protocole NTLM
(NT LAN Manager) qu’utilise NT. Par
conséquent, quelqu’un qui intercepte
une communication réseau entre le
client et le serveur aura plus de mal à 
voler des mots de passe s’il est
confronté à  Kerberos.

Comme Kerberos contrôle l’identité
du client et du serveur, il est de ce
point de vue supérieur à  d’autres mécanismes
d’authentification. Si l’on
n’utilise pas Win2K, SQL Server peut
valider l’identité de l’utilisateur par un
login NT ou par un login SQL Server,
mais la meilleure façon pour un client
de valider l’identité d’un serveur est de
connaître son adresse réseau. SSL offre
une solution à  ce problème parce que
le certificat du serveur contient son
adresse, mais le certificat n’identifie
que l’ordinateur, pas le service SQL
Server auquel le client essaie d’accéder.
En outre, sans l’autorité de certification
gérée localement de Win2K, il
est long et coûteux d’obtenir des certificats
de la part d’autorités de certification
comme Verisign ou Thawte. C’est
pourquoi de nombreux administrateurs
n’utilisent SSL que sur les serveurs
où le cryptage est obligatoire.
Comme SSL, IPSec identifie l’identité
des deux ordinateurs mais pas le service
SQL Server. L’authentification
Kerberos est la seule à  garantir que le
client communique avec le bon service
SQL Server.

Pour l’accès au serveur Web, l’authentification
Kerberos donne un
moyen d’empêcher une application
Web de communiquer avec d’autres
SQL Server si le serveur Web est infecté
par un virus comme Code Red. Dans
AD (Active Directory), on peut accorder
ou refuser l’accès à  un service particulier,
donc on peut améliorer la sécurité
interne du réseau en permettant
au serveur Web de ne communiquer
qu’avec un SQL Server bien précis.