> Data > Meilleures pratiques pour l’authentification mixte

Meilleures pratiques pour l’authentification mixte

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

par Kalen Delaney - Mis en ligne le 10/11/2004 - Publié en Décembre 2003

Comment renforcer la sécurité de SQL Server

Les administrateurs de bases de données (DBA) et les développeurs d'applications doivent prendre les décisions de sécurité qui protègent le mieux leurs systèmes. S'il est vrai que le risque zéro n'existe pas, les DBA et les développeurs qui utilisent SQL Server peuvent améliorer la sécurité par une bonne compréhension des ramifications du mode d'authentification qu'ils adoptent...SQL Server 2000 et 7.0 fournissent deux modes d'authentification : l'authentification SQL Server et Windows (aussi appelée authentification mixte) et l'authentification intégrée à  Windows. L'authentification mixte permet aux applications de se connecter à  SQL Server à  l'aide des comptes et des mots de passe stockés dans les tables SQL Server ou dans un domaine ou une machine locale Windows. L'authentification mixte est simple d'emploi mais elle n'a pas de possibilité de filtrage de rejet de comptes et elle peut exposer vos systèmes à  une attaque menée par le biais du compte SA, vulnérable et souvent mal géré, de SQL Server. L'authentification Windows, qui exige d'utiliser un compte Windows pour tout ce qui touche à  la connectivité base de données, fournit un mécanisme de filtrage (et donc de refus éventuel) de compte et élimine les risques de sécurité liés au compte SA. Elle offre aussi des moyens supplémentaires de journalisation au moyen des journaux Windows Security Event Viewer. Mais l'authentification Windows est plus complexe et il n'est pas toujours facile de convaincre un développeur d'applications de l'adopter.
L'authentification Windows est de loin la plus sûre et il faut donc l'appliquer dans la mesure du possible. Il arrive cependant que le type de gestion ou d'application impose l'authentification mixte. Deux exemples : certaines applications tierce partie ne reconnaissent que l'authentification mixte et certains langages de programmation, comme Java, ne prennent pas en charge l'authentification Windows pour des connexions SQL Server. Parfois aussi les concepteurs architectes de l'application peuvent estimer que l'authentification mixte représente le chemin de développement le plus rapide et le plus simple. Parfois encore, il faudra travailler avec des applications existantes qui utilisent l'authentification mixte, jusqu'à  ce qu'on ait le temps ou le personnel permettant de les réécrire pour l'authentification Windows. Quelle qu'en soit la raison, si vous devez utiliser l'authentification mixte, vous devez connaître les failles de vos systèmes SQL Server et savoir vous en protéger.

Avant d’examiner les faiblesses de l’authentification
mixte et comment y pallier,
voyons rapidement pourquoi développeurs
et DBA pourraient choisir à 
tort l’authentification mixte ou répugner
à  utiliser l’authentification Windows.
En réalité, beaucoup de développeurs
d’applications et de DBA SQL
Server qui pratiquent l’utilisation mixte
ne connaissent pas ses dangers. Ils
choisissent généralement l’authentification
mixte pour deux raisons.
Premièrement, la plupart des exemples
qu’ils trouvent sur Internet ou
dans les livres montrent des chaînes de
connexion SQL Server qui utilisent des
comptes SQL Server et n’expliquent
pas comment utiliser l’authentification
Windows pour se connecter à  SQL
Server.
Deuxièmement, la plupart des
DBA et développeurs pensent qu’il est
plus rapide d’écrire des applications
avec authentification mixte et que le
code ainsi obtenu sera plus facile à  déboguer.
L’authentification Windows
peut ajouter une couche de complexité
à  l’application. Comme ce
mode d’authentification demande
d’utiliser un compte Windows pour
toute la connectivité base de données,
les développeurs ASP (Active Server
Pages), par exemple, pourraient être
obligés d’utiliser COM+ pour accéder
à  SQL Server au lieu d’incorporer directement
l’information de connexion
dans le code ASP. Avec l’authentification
mixte, les développeurs codent un
nom d’utilisateur et un mot de passe
dans une chaîne de connexion dans la
page ASP. Avec cette méthode de stockage,
les développeurs connaissent
toujours le compte par l’intermédiaire
duquel un utilisateur se connecte à 
SQL Server. En revanche, quand les développeurs
utilisent l’authentification
Windows sur une simple page ASP, le
compte par le biais duquel un utilisateur
se connecte à  la page ASP est aussi
le compte qui connecte à  SQL Server.
Le plus souvent, le compte que l’utilisateur
emploie pour se connecter au serveur Web qui héberge la page ASP,
est le compte d’accès anonyme Microsoft
IIS (IUSR_machinename). La plupart
des DBA ne veulent pas permettre
à  ce compte anonyme d’accéder à  SQL
Server – et ils ont raison. Mais cette
restriction oblige le développeur à 
fournir l’une des deux méthodes de
connexion suivantes aux utilisateurs.
Le développeur peut demander aux
utilisateurs de se connecter au serveur
Web qui héberge la page Web en utilisant
l’authentification IIS ou un formulaire
Web sur la page ASP. Ou bien, le
développeur peut créer un fichier
COM+ .dll et utiliser les propriétés du
package COM+ pour savoir quel
compte la page ASP appelle pour se
connecter à  SQL Server. On voit bien
que l’authentification Windows semble
plus ardue.
En outre, les développeurs d’applications
Web utilisent souvent l’authentification
mixte parce qu’elle permet
d’utiliser facilement ADO pour se
connecter aux bases de données SQL
Server. Et comme ADO anime les applications
Web pilotées par base de
données et basées sur ASP, les développeurs
Web pourraient légitimement
penser que l’authentification mixte est
le meilleur choix.
S’il est vrai que l’authentification
Windows est plus difficile à  mettre en
oeuvre, les développeurs qui prennent
le temps de bien la comprendre peuvent
éliminer les failles de sécurité potentielles
inhérentes à  l’authentification
mixte. D’ailleurs, les développeurs
doivent souvent réécrire des applications
ASP précisément à  cause des lacunes
de sécurité de l’authentification
mixte. Il faut choisir : soit écrire des applications
rapidement et simplement
pour être obligé de les réécrire plus
tard ; soit prendre le temps d’écrire
d’emblée des applications plus sûres.
Voyons maintenant les problèmes associés
à  l’authentification mixte et au
compte sa et comment s’en protéger.

Téléchargez gratuitement cette ressource

Comment sécuriser la Digital Workplace ?

Comment sécuriser la Digital Workplace ?

Avec le recours généralisé au télétravail, les entreprises ont ouvert davantage leur SI. En dépit des précautions prises, elles ont mécaniquement élargi leur surface d’exposition aux risques. Découvrez 5 axes à ne pas négliger dans ce Top 5 Sécurité du Télétravail.

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