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

Le système Local n'est pas recommandé, il s'agit d'un compte équivalent administrateur et peut donc conduire à un codage douteux qui profite des privilèges d'administrateur qui ne seraient pas autorisés dans un système de production car les administrateurs/DBA soucieux de la sécurité n'aiment vraiment pas exécuter les services en tant qu'administrateur.

Selon que l'instance de serveur doit accéder à d'autres ressources de domaine ou non, elle doit déterminer le type de Compte à privilèges bas sous lequel elle doit s'exécuter.

S'il n'a pas besoin d'accéder à des ressources de domaine (non anonymes), je crée normalement un compte local à faible privilège unique pour qu'il s'exécute afin de bénéficier de l'avantage de sécurité supplémentaire de ne pas avoir plusieurs services s'exécutant dans le même contexte d'identité. sachez que le compte de Service Local n'est pas pris en charge pour les services SQL Server ou SQL Server Agent.

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

1. exécuter comme Service réseau qui est également un compte à faible privilège, mais qui conserve les informations d'identification du réseau des ordinateurs.
2. exécuter sous un compte de Service Local
3. S'exécute sous un compte de domaine personnalisé avec de faibles privilèges locaux. L'un des avantages de l'exécution sous le compte developers est qu'il est plus facile d'attacher des débogueurs à des processus dans votre propre identité sans compromettre la sécurité, de sorte que le débogage est plus facile (puisque les comptes non administrateurs n'ont pas le privilège d'attacher un débogueur à un autre processus d'identités par défaut). Un inconvénient à l'utilisation d'un autre compte de domaine est la surcharge de la gestion de ces comptes, d'autant plus que chaque service pour chaque développeur devrait idéalement avoir des informations d'identification uniques afin que vous n'ayez aucune fuite si un développeur devait partir.

La Plupart de ce que j'ai tendance à faire ne nécessite pas que le service accède aux ressources du domaine, donc j'ai tendance à utiliser des comptes locaux à faible privilège uniques que je gère. J'ai également exécuter exclusivement en tant qu'utilisateur non administrateur (et je l'ai fait sous XP SP2, Server 2003, Vista et Server 2008 sans problèmes majeurs) donc quand j'ai des cas où j'ai besoin du service pour accéder aux ressources du domaine, je n'ai aucun souci d'utiliser mes propres identifiants de domaine (de plus, je n'ai pas à inquiéter les administrateurs du réseau de créer / maintenir un tas d'identités de domaine non-production).