> Data > Des données sous bonne garde avec Kerberos

Des données sous bonne garde avec Kerberos

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Morris Lewis - Mis en ligne le 25/03/03
Toutes les opérations de sécurité de SQL Server s'appuient sur un double processus : authentification et autorisation. Si le serveur n'a pas toute confiance en l'identité de l'utilisateur et n'est donc pas certain des permissions de celui-ci, toutes les tentatives de contrôle d'accès aux données échoueront. Pendant longtemps, Microsoft a préféré les logins authentifiés de Windows NT à  leurs homologues de SQL Server parce que Windows vérifie plus efficacement l'identité de l'utilisateur, bien au-delà  de la simple comparaison d'un couple compte/mot de passe. Kerberos est le protocole d'authentification par défaut de Windows 2000. Il améliore le protocole d'authentification de NT de plusieurs manières et identifie à  la fois le client et le serveur. Voyons brièvement le principe de fonctionnement de Kerberos et comment il peut protéger les données de vos serveurs SQL Server 2000. Bien entendu, il faut exécuter SQL Server 2000 sur Win2K pour utiliser Kerberos. Je reviendrai plus loin plus en détail sur les exigences en la matière.

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.

Téléchargez cette ressource

SD-WAN de confiance : guide de mise en œuvre

SD-WAN de confiance : guide de mise en œuvre

Ce livre blanc décrit les différents aspects indispensables pour la mise en place d’une approche SD-WAN sécurisée et de confiance. Ce document s’adresse aux consultants et responsables sécurité des systèmes d’information pour bien comprendre les enjeux du Trusted SD-WAN à l’heure de la transformation numérique des entreprises.

Data - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT