Sécurité

le compte spécifié pour lui
dans cette boîte de dialogue et s’exécute
dans l’OS dans le contexte de sécurité
de ce compte. Quand vous sauvegardez
un périphérique disque, par
exemple, SQL Server vérifie que l’identification
que vous avez utilisée pour
vous connecter à  SQL Server possède
l’autorisation BACKUP DATABASE appropriée.
Toutefois, pour créer l’unité
de fichier de sauvegarde et pour y
écrire, SQL Server doit créer un fichier
sur disque ou dans un network share
et cette opération utilise le contexte de
sécurité du compte de service SQL
Server.

De même, le service SQL Server
Agent exécute les processus dans SQL
Server et dans l’OS ou le réseau sous le contexte de sécurité du compte de service
du SQL Server Agent. Il vaut mieux
faire du compte de service SQL Server
un membre du groupe Administrators
local, bien qu’un compte sans privilèges
administratifs dans la machine
puisse démarrer le service SQL Server.
Sinon, il faudra octroyer explicitement
au compte toutes les autorisations requises
(créer des fichiers base de données,
par exemple). Vous devez aussi
octroyer au compte de service les autorisations
de réseau appropriées (par
exemple, pour créer et écrire dans des
fichiers sur des network shares que
SQL Server utilise comme destinations
de sauvegarde).

Cependant, SQL Server Agent ne
démarrera même pas si vous essayez
de le charger avec un compte de service
ne possédant pas de privilèges administratifs
sur la machine. Et, si SQL
Server Agent mène des activités sur d’autres machines du réseau, comme
des jobs de réplication ou multi serveurs,
vous devriez utiliser un compte
de domaine ayant aussi les autorisations
appropriées sur les autres machines.
Soit un domaine avec trois machines SQL Server dans un environnement multi serveurs dans lequel un serveur maître contrôle les
activités d’automatisation sur des serveurs
cibles. Srv1 joue le rôle de serveur
maître et Srv2 et Srv3 se comportent
comme les serveurs cibles.
Comme les deux côtés (maître et cible)
doivent communiquer entre eux, vous
devez vous assurer que le compte de
service SQL Server Agent sur le serveur
maître a les privilèges appropriés sur le
serveur cible et réciproquement. Le
moyen le plus simple de configurer un
tel environnement consiste à  créer un
compte de domaine (Domain1\SQLService, par exemple) en faire un membre du groupe Administrators local
dans tous les serveurs, et charger
tous les services SQL Server Agent par
l’intermédiaire de ce compte.

Dans la boîte de dialogue Authentication
Mode que présente la figure 5,
vous pouvez choisir de n’autoriser que
des logins authentifiés par Windows
(Windows Authentication Mode) ou
des logins Windows et SQL Server
(Mixed Mode). Vous pouvez aussi indiquer
un mot de passe pour le login
SQL Server sa. L’authentification
Windows-only est le mode de sécurité
par défaut et celui qui est couramment
recommandé. Toutefois, pour des raisons
de sécurité, je vous conseille de
choisir Mixed Mode et de fournir un
mot de passe pour le compte sa, en
changeant le mode d’authentification
en Windows-only après l’installation et
après avoir manipulé quelques autres
éléments de sécurité. Le programme
d’installation crée un login SQL Server
pour sa et en fait un membre du rôle
serveur sysadmin. Si vous choisissez
l’authentification Windows-only
comme mode de sécurité de votre serveur,
le processus d’installation crée le
login sa comme désactivé (parce que
l’authentification de SQL Server est disabled)
et sans mot de passe. Vous
pouvez changer le mot de passe de sa
après l’installation – et je vous le
conseille vivement – mais il est dangereux
de choisir l’authentification
Windows initialement parce que vous
pourriez oublier de changer le mot de
passe ou le laisser vierge, en partant du
principe que sa est désactivé.

Quel que soit le mode choisi, le
programme d’installation crée également
un login authentifié par Windows
pour le groupe BUILTIN\Administrators,
qui est associé au groupe
Administrators de la machine locale. La
création de ce login signifie que tous
les membres du groupe Administrators
local, y compris le groupe domaine
Domain Admins, sont aussi membres
du rôle sysadmin de votre SQL Server.
Il n’est pas toujours judicieux d’accorder des autorisations illimitées
aux administrateurs de réseaux et de
machines, car on introduit des risques.
C’est pourquoi on peut choisir de supprimer
BUILTIN\Administrators du
rôle SQL Server sysadmin. Vous pouvez
aussi supprimer complètement le
login créé automatiquement à  partir
de SQL Server et créer un login avec
l’appartenance sysadmin pour un
groupe dont les membres sont des
DBA (administrateurs de bases de données)
– et pas des administrateurs de
réseaux.

Si vous décidez de suivre l’une de
ces recommandations, il est essentiel
de créer d’abord le login avec l’appartenance
sysadmin pour le groupe
DBA, puis de supprimer le login BUILTINAdministrators. Si le mode d’authentification
de votre serveur est
Windows-only et si vous supprimez
tous les logins qui ont l’appartenance
sysadmin avant de créer le login pour
le DBA, vous risquez de vous retrouver
évincé de SQL Server sans aucun
moyen d’effectuer des tâches administratives
– comme la création de nouveaux
logins. Si vous tombez dans le
piège, vous pouvez néanmoins changer
le mode d’authentification de SQL
Server en Mixed au moyen du registre,
en modifiant la sous-clé de registre
HKEY_LOCAL_MACHINE\SOFTWAREMicrosoft\Microsoft SQL Server\MSSQLServer\Login
Mode. Changez la valeur de sous-clé en
deux, puis redémarrez le service SQL
Server.

Bien qu’il soit commode de
contrôler le mode login de SQL Server
au moyen du registre, cette méthode
présente aussi un inconvénient.
Quiconque a l’autorisation de modifier
cette sous-clé de registre, y compris les
administrateurs de réseaux et de machines,
peut changer le mode d’authentification
de SQL Server. Si vous
installez SQL Server avec Windows
Authentication Mode, sa est désactivé
mais a encore un mot de passe vierge.
Si vous changez ensuite le mode d’authentification
de SQL Server en Mixed (validant ainsi le login sa), n’importe
qui peut se connecter comme sa.
Donc, il faut choisir entre les deux solutions
suivantes : soit changer le mot
de passe sa dès que l’installation est finie,
soit choisir Mixed Mode et fournir
un mot de passe pour sa pendant l’installation.