Les dangers du compte sa

peuvent pas se servir du compte sa
pour se connecter à  SQL Server, mais
avec l’authentification mixte ils le peuvent.
SQL Server ajoute le compte sa
au rôle de serveur fixe sysadmin et personne
ne peut l’enlever. Le compte sa
fournit l’accès à  SQL Server par un niveau
administratif irrévocable.
Toujours lors de l’installation, l’installateur
doit attribuer un compte pour
démarrer, arrêter et suspendre le service
qui contrôle SQL Server. Souvent,
l’installateur choisit le compte Local-
System au lieu d’un compte possédant
un niveau de privilège moindre, parce
que, dans ce dernier cas, si quelqu’un
change accidentellement le mot de
passe du compte, vous risquez de ne
plus pouvoir démarrer le service. En
choisissant le compte LocalSystem,
vous savez que le système démarrera
toujours, quels que soient les changements
de mot de passe ou de permissions.
Toutefois, le compte Local-
System a un accès complet à  toutes les
fonctions de l’OS, y compris la possibilité
d’ajouter des comptes utilisateur,
de redéfinir des mots de passe, et
d’ajouter des utilisateurs à  des groupes.
Dans cette configuration, quand
un utilisateur se connecte à  SQL Server
par l’intermédiaire du compte sa et
qu’il exécute une commande, celle-ci
agit comme si elle provenait de
LocalSystem. Si des pirates pénètrent
dans SQL Server par le biais du compte
sa, ils peuvent utiliser des commandes
dans certaines procédures stockées
pour ajouter un utilisateur au système,
ajouter cet utilisateur au groupe d’administrateurs
local et, en fin de
compte, accéder à  des utilitaires système
dangereux et au registre
Windows.
L’une des failles les plus graves du
compte sa est que si des pirates découvrent
son mot de passe, ils peuvent accéder
à  votre système SQL Server. En
mode d’authentification mixte, SQL
Server n’évince pas les utilisateurs
après un certain nombre de tentatives
de login incorrect. Par conséquent, un
assaillant peut utiliser un outil de cassage
de mots de passe pour découvrir
le mot de passe du compte sa. Et
même avec l’authentification Windows,
il faut quand même munir le
compte sa d’un puissant mot de passe
(c’est-à -dire, d’au moins 12 caractères
de long et mêlant majuscules, minuscules,
chiffres et caractères ALT).
Comme avec l’authentification Windows,
on ne peut pas utiliser le compte
sa pour se connecter à  SQL Server,
beaucoup d’administrateurs qui utilisent
l’authentification Windows ne se
donnent pas la peine de donner un
mot de passe pour sa. Mais si, pour une
raison quelconque, on passe de
Windows à  l’authentification mixte, le
mot de passe du compte sa sera vierge,
avec les conséquences qu’on devine.
Dans le même esprit, les développeurs
ASP et VB (Visual Basic) qui
prennent conscience que l’utilisation
du compte sa pour des connexions
ADO n’est pas judicieuse, ne sont pas à 
l’abri. Au lieu d’utiliser sa, ces développeurs
créent des logins SQL Server et
les configurent avec le niveau de permissions
approprié pour accéder aux
bases de données, aux tables, et à 
d’autres objets. Mais, comme leurs applications
n’utilisent pas le compte sa,
ces développeurs éprouvent une
fausse impression de sécurité et établissent
un mot de passe de compte sa
simple au lieu d’en créer un long et
complexe, comme il se doit. Par conséquent,
même si les développeurs
configurent correctement une application
pour utiliser des comptes à  faible
privilège, SQL Server n’en est pas
moins vulnérable à  une attaque directe
par l’intermédiaire du compte sa.