Version imprimable
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
- Ne jamais utiliser le compte LocalSystem, car il a tous les privilieges sur toutes les ressources d'une machine;
- 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.
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
très clair :merci:
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.Citation:
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);
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.
++
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.
Le probleme n'est pas tant la session null mais les privileges que possedent un compte. La preuve si on regarde avec SQL Server 2012 et le support des comptes manages et des comptes virtuels pour lesquels les mots de passe ne sont plus necessaires. Ces comptes sont de simple comptes locaux ou de domaine sans privilege particulier.Citation:
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.
De plus les comptes utilisateurs utilises pour les services SQL n'ont plus de privilege particulier sur l'instance SQL Server concernee avec les nouvelles versions. On a vraiment un confinement de plus en plus strict au niveau des ressources avec l'arrivee des nouvelles versions de SQL Server.
++