Quel compte d'utilisateur recommanderiez-vous pour exécuter les services SQL Server Express 2008 dans un environnement de développement?

Question

La configuration de SQL Server Express 2008 vous permet d’affecter un compte utilisateur différent à chaque service.

Pour un environnement de développement, utiliseriez-vous un utilisateur de domaine, un utilisateur local, un serveur NT Authority \ NETWORK SERCVICE, un système NT Authority \ Local ou un autre compte, et pourquoi?

Answer 1

Le système local n'est pas recommandé. Il s'agit d'un compte équivalent à celui d'un administrateur. Cela peut donc conduire à un codage douteux qui tire parti des privilèges d'administrateur qui ne seraient pas autorisés dans un système de production, car des administrateurs / administrateurs de base sensibles à la sécurité n'aime vraiment pas faire fonctionner des services en tant qu'administrateur.

Selon que l’instance de serveur doit ou non accéder à d’autres ressources du domaine, elle doit déterminer le type de compte faible privilège sous lequel elle doit être exécutée.

S'il n'a pas besoin d'accéder à des ressources de domaine (non anonymes), je crée normalement un compte local unique et de faible privilège sous lequel il doit s'exécuter afin d'obtenir l'avantage supplémentaire de ne pas avoir plusieurs services en cours d'exécution dans le système. même contexte d'identité. Sachez que le compte de service local n'est pas pris en charge. les services SQL Server ou SQL Server Agent.

S'il faut accéder à des ressources de domaine non anonymes, vous avez trois options:

1. Exécuter en tant que Service réseau qui est également un compte à privilèges faibles mais un compte qui conserve les informations d'identification réseau de l'ordinateur.
2. Exécuter sous un compte de service local
3. Exécuter sous un compte de domaine personnalisé avec des privilèges locaux faibles. Un des avantages de l’exécution sous le compte développeurs est qu’il est plus facile de joindre des débogueurs à des processus de votre propre identité sans compromettre la sécurité. Le débogage est donc plus facile (les comptes non administrateurs n’ayant pas le privilège de lier par défaut un débogueur à un autre processus d’identité). ). La gestion de ces comptes est un inconvénient lié à l'utilisation d'un autre compte de domaine, d'autant plus que chaque service pour chaque développeur doit idéalement disposer d'identifiants uniques, de sorte que vous ne subissez aucune fuite en cas de départ d'un développeur.

La plupart de mes tâches n'exigent pas que le service accède aux ressources du domaine. Par conséquent, j'ai tendance à utiliser des comptes uniques locaux à faibles privilèges que je gère. J'exécute également exclusivement en tant qu'utilisateur non administrateur (et je l'ai fait sous XP SP2, Server 2003, Vista et Server 2008 sans aucun problème majeur). Ainsi, lorsque j'ai des cas où j'ai besoin du service pour accéder aux ressources du domaine, je ne crains rien à propos de l’utilisation de mes propres identifiants de domaine (en plus de cette façon, je n’ai pas à inquiéter les administrateurs de réseau de la création / maintenance d’un ensemble d’identités de domaine non productives).

Answer 2

Cela dépend.

• Système local - Jamais, c'est trop haut un privilège.
• Service réseau - Peut-être, si vous avez besoin de vous connecter à ressources réseau, mais c'est douteux.
• Service local - probablement le meilleur choix, privilèges limités, ne pas déverrouiller les connexions réseau
• Utilisateur interactif local? Le fait-il vraiment besoin d'avoir des droits de connexion, ou agir en tant qu'utilisateur?
• Utilisateur du domaine? La bonté non, sauf si vous y accédez les lecteurs réseau de l'intérieur; si SQL fonctionne alors un attaquant est amok authentifié sur le domaine.

Answer 3

MS a maintenant un bon article à ce sujet: http://msdn.microsoft.com/en- us / library / ms143504 (v = sql.105) .aspx

Ils indiquent que le service local n'est pas autorisé pour SQL Server Engine. Personnellement, j’utilise Local System uniquement pour éviter des problèmes lors du développement, mais en production, la meilleure pratique consiste à créer un compte de service au niveau du domaine doté des autorisations nécessaires pour effectuer le travail.

Answer 4

Tout ce qu'il veut utiliser par défaut. Changer cela ne fait que demander des ennuis plus tard.