Discussion :

[doumbix]

bonjour ,
quel est l'impact de laisser au serveur sqlserveur contrôler par les connexions LocalSystem ou LocalService ou LocalNetwork , car certains de mes amis l'ont laissé être contrôler par un de ses logins ? je veux savoir ce que ça implique quand on le laisse comme ça .
Merci

[WOLO Laurent]

1. Ne jamais utiliser le compte LocalSystem, car il a tous les privilieges sur toutes les ressources d'une machine;
2. Ne jamais utiliser le compte Network Ressource, car il a tous les privilieges sur toutes les ressources d'une machine et peux acceder aux reseaux en utilisant une session null (Sans mot de passe);
   Ne jamais utiliser le compte Local Service, car il a les privileges par defaut d'un utilisateur mais il n'a pas de mot de passe;

Utiliser a leur place un compte personnalise avec un mot de passe fort.

[dbaffaleuf]

Depuis la version SQL Server 2005, l'outil d'installation créé des groupes de démarrage pour les différents services, il en existe un pour SQL Server, un pour l'agent, etc... Idéalement il faut créer un compte sans droit et le placer dans le groupe correspondant. Bien que cette notion de groupes ait presque disparue en SQL 2012, elle reste utilisable en SQL 2005, 2008 et 2008 R2. cf http://msdn.microsoft.com/en-us/libr...ql.105%29.aspx

[doumbix]

très clair

[mikedavem]

Ne jamais utiliser le compte Network Ressource, car il a tous les privilieges sur toutes les ressources d'une machine et peux acceder aux reseaux en utilisant une session null (Sans mot de passe);

Je pense que tu parles du compte prédéfini Local Service Account. De plus ce compte n'a pas accès à toutes les ressources d'une machine. Seul le compte prédéfini Local System Account le possède.

Pour répondre à la question de doumbix je dirais que tout dépend le contexte de ton serveur. Est-ce que celui-ci est dans un domaine ? Doit-il avoir accès à des ressources externes ou non ? Est-ce que le serveur SQL est dédié ? etc ...

Si on suit les bonnes pratiques il est vrai qu'un compte de domaine ou éventuellement un compte local sans privilèges élevés doit être utilisé. Il faut faire attention aux comptes built-in qui sont des comptes "partagés" sur le serveur en local et peuvent être donc utilisés par plusieurs applications en même temps. En d'autres termes, si plusieurs applications utilisent un même compte built-in ils auront potentiellement accès aux mêmes ressources. Ceci devient de moins en moins vrai avec les nouvelles versions de SQL Server où l'on utilise le contexte des SID de service pour protéger les ressources et plus celui correspondant au compte utilisateur utilisé en tant que compte de service.

++

[WOLO Laurent]

Mike,
La plupart de ces comptes utilisent la session null donc potentiellement a risque d'attaque ! Je ne conseillerais jamais quelqu'un a l'utiliser.