Quel compte d'utilisateur recommanderiez-vous pour exécuter les services SQL Server Express 2008 dans un environnement de développement?
La configuration de SQL Server Express 2008 vous permet d'attribuer un compte d'utilisateur différent pour chaque service.
Pour un environnement de développement, utiliseriez-vous un utilisateur de domaine, un utilisateur local, NT Authority\NETWORK SERCVICE, NT Authority\Local System ou un autre compte et pourquoi?
Le système local n'est pas recommandé, c'est un compte équivalent à l'administrateur et peut donc conduire à un codage discutable qui tire parti 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 devra accéder à d'autres ressources de domaine ou non, elle devra déterminer le type de compte à faible privilège 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 pour qu'il s'exécute afin d'obtenir l'avantage de sécurité supplémentaire de ne pas avoir plusieurs services en cours d'exécution 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:
- Exécuter en tant que Service résea qui est également un compte à faible privilège mais qui conserve les informations d'identification réseau de l'ordinateur.
- Exécuter sous un compte de service local
- Exécutez sous un compte de domaine personnalisé avec de faibles privilèges locaux. L'un des avantages de l'exécution sous le compte des développeurs est qu'il est plus facile d'attacher des débogueurs à des processus dans votre propre identité sans compromettre la sécurité, donc le débogage est plus facile (car les comptes non-administrateurs n'ont pas le privilège d'attacher un débogueur à un autre processus d'identité par défaut ). Un inconvénient de l'utilisation d'un autre compte de domaine est la surcharge de 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 de domaine, j'ai donc tendance à utiliser des comptes locaux à faible privilège 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 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 à utiliser mes propres informations d'identification de domaine (et de cette façon, je n'ai pas à m'inquiéter des administrateurs réseau pour créer/maintenir un tas d'identités de domaine non produites).
Ça dépend.
- Système local - Jamais, c'est un privilège trop élevé.
- Service réseau - Peut-être, si vous devez vous connecter aux ressources réseau, mais cela est douteux.
- Service local - Probablement le meilleur choix, des privilèges limités, ne déverrouillez pas les connexions réseau
- Utilisateur interactif local? Doit-il vraiment avoir des droits de connexion ou agir en tant qu'utilisateur?
- Utilisateur de domaine? Non, pas à moins que vous n'accédiez à des lecteurs réseau depuis celui-ci; si SQL tourne mal, un attaquant est authentifié par rapport au domaine.
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 le moteur SQL Server. Personnellement, j'utilise le système local juste pour éviter les problèmes pendant le développement, mais en production, la meilleure pratique consiste à créer un compte de service au niveau du domaine avec juste les autorisations dont il a besoin pour faire le travail.