SQL Server : Quels comptes de service choisir ?

SQL Server : Quels comptes de service choisir ?

SQL Server est un moteur de base de données fonctionnant en tant que services, c’est-à-dire que vous avez juste à démarrer le serveur pour que l’application démarre. Nul besoin de se connecter au serveur, ni de démarrer un quelconque programme.
 Par contre, ce service, comme tout autre service nécessite un utilisateur pour s’exécuter. Le choix de cet utilisateur est loin d’être anodin, un mauvais choix peut potentiellement être une brèche de sécurité dans l’entreprise, ou vous faire arracher les cheveux de la tête lors de la mise en place de réplications, ou autre système nécessitant de communiquer entre les serveurs.
 En tout vous avez 5 choix pour chacun des services de SQL Server :

• LocalSystem
• LocalService (Windows 2003 et +)
• NetworkService (Windows 2003 et +)
• Compte Utilisateur Local
• Compte Utilisateur du Domaine

 Les autres choix sont volontairement exclus, mais je vous en cite 2 qui sont à proscrire coûte que coûte :

• Invité local ou du domaine
  • Tout simplement déconseillé car ce compte a son profil local recréé à chacune se ses connexion et dispose de droits très limités (à la limite il est fortement bridé et particulièrement depuis Windows 2003) et peu poser des problèmes avec un service. D’une manière générale ou ne donnera jamais moins de privilèges que celui d’utilisateur à un service.
• Administrateur du domaine
  • Dans ce cas, c’est au contraire que les droits accordés sont beaucoup trop élevés. D’une part SQL Server ne nécessite en aucuns cas des privilèges administrateurs sur une machine, mais encore moins sur un domaine. Utiliser ce type de compte de service est une faille de sécurité majeure, toute personne étant sysadmin (login sa entre autres) bénéficie indirectement de ce type de droits et de l’accès total au domaine de l’entreprise.

 Les comptes utilisables et leurs particularités :

• Compte LocalSystem

 Ce compte est un compte prédéfini (BUILTIN) qui existe sous toutes les versions de Windows NT (NT x, 2000, 2003, XP, Vista et 2008).
 C’est en général l’option par défaut dans beaucoup d’installation de SQL Server. SQL Server dispose de permission « administrateur » local de la machine avec ce compte et même un peu plus étant donné que ce compte dispose de quelques privilèges systèmes supplémentaires que n’ont pas les administrateurs.
Ses droits sont locaux uniquement, ce compte n’a pas de réel contexte utilisateur en cas de connexion à une machine distante, c’est une demande d’ouverture de session (null) qui  faites sur celle-ci (qui est en général refusée).
 C’est un assez mauvais choix car il procure des droits très importants à SQL Server et potentiellement à des personnes malveillantes connectées sur ce même serveur de base de données (possibilités entre autres de redémarrer Windows, etc.). SQL Server n’a pas besoin de privilèges aussi élevé, on préfèrera l’une des autres options plus « sécurisé ».

• Compte LocalService (nouveauté Windows 2003)

Ce compte est un compte prédéfini (BUILTIN) qui existe sous toutes les versions de Windows à partir de 2003 / XP (2003, XP, Vista et 2008).
 Ses droits sont ceux d’un utilisateur simple local. Les privilèges dont il dispose sont locaux uniquement, en cas de tentative de connexion à une machine distante, c’est une demande d’ouverture de session (null) qui  faites sur celle-ci (qui est en général refusée).
 A savoir que ses droits sont restreints volontairement en vue de l’utilisation comme compte de service, ce qui en fait un choix meilleur que LocalSystem. Cependant il cumule les droits de tous les services qui l’utilisent : Si SQL server et IIS s’en servent comme compte de service il aura accès à la fois aux répertoires de SQL Server et à ceux de IIS.

C’est un assez bon compromis en termes de sécurité, même si les droits dont il dispose sont très fonctions de l’utilisation de celui-ci avec d’autres services. Suivant le rôle de votre serveur vous aurez un compte LocalService avec des privilèges plus ou moins élevés, ce qui n’en fait pas un choix parfait.

• Compte NetworkService (nouveauté Windows 2003)

Ce compte est un compte prédéfini (BUILTIN) qui existe sous toutes les versions de Windows à partir de 2003 / XP (2003, XP, Vista et 2008).

Identique au précédent, sauf que les accès réseau sont possibles. Si une tentative de connexion à un autre serveur est faite, ce serveur verra une tentative de connexion du compte de la machine. Exemple : SRVSQL fait une connexion vers SRVWEB, SRVWEB verra une tentative de connexion de \\SRVSQL, qu’il doit autoriser pour qu’elle réussisse.
 Ce type de compte de service permet au serveur de se reconnaître entre eux sans pour autant nécessiter un domaine. Une DMZ est l’endroit idéal où utiliser ce type de compte.

Les limitations restent les même que pour LocalService, les droits de ce type de compte étant fonction de son utilisation pour d’autres services. Il faut considérer qu’il n’a pas d’équivalent, dans le cas de serveurs non connectés à un domaine sont choix peut s’avérer judicieux.

• Compte Utilisateur Local Windows

 Ce compte est à créer manuellement, sa création est possible sous toutes versions de Windows.

Ce compte ne dispose que des privilèges « utilisateur » local. En cas de tentative de connexion à une machine distante, c’est une demande d’ouverture de session (null) qui  faites sur celle-ci (qui est en général refusée).

Les privilèges accordés à ce compte sont uniquement ceux que vous lui accordez (et que l’installation de SQL Server lui accorde). Il faudra lui donner un mot de passe complexe et interdire son expiration si vous souhaitez éviter tout problème.

Ce choix est généralement le meilleur en termes de sécurité pour SQL Server il est équivalent à LocalService, mais ne souffre pas du principal problème de ce dernier : les droits de ce comptes ne sont partagés que par les services où vous l’utilisé, et rien ne vous interdit d’un créer un par service. Cependant si vous avez besoin de réaliser des accès distant à d’autres serveurs ce choix n’est pas intéressant.

C’est le choix parfait pour le service SQL Server (moteur relationel), celui-ci n’ayant pas besoin de se connecter à d’autres machines.

• Compte Utilisateur du Domaine Windows

 Ce compte est à créer manuellement, sa création est possible sous toutes versions de Windows à condition que votre serveur soit joint à un domaine.

Ce compte ne dispose que des privilèges « utilisateur » sur le domaine. En cas de tentative de connexion à une machine distante, c’est le compte de service qui réalise cette connexion, à vous de donner les privilèges nécessaire à cette connexion sur la machine distante (exemple : accordez les droits en écriture sur le partage \\SRVFILES\SAV à DOMAINE\compte_sql_server pour permettre la sauvegarde à distance sur ce partage).

Les privilèges accordés à ce compte sont uniquement ceux que vous lui accordez (et que l’installation de SQL Server lui accorde). Il faudra lui donner un mot de passe complexe et interdire son expiration si vous souhaitez éviter tout problème.

Option la plus courante lorsque vous êtes relié à un domaine, permet plus de facilité au niveau de la gestion des droits entre les serveurs. Nécessite pas contre que SQL Server soit joint à un domaine pour en profiter totalement.

C’est un très bon choix pour l’Agent SQL, ce service ayant très souvent besoin de se connecter à d’autres postes au d’autres serveurs de base de données.

Quels choix faire ?
 Une petite synthèse des options intéressantes par situation.
 Machine autonome sur le réseau :

• Compte Utilisateur local Windows
• Compte LocalService

 Machine sur DMZ nécessitant la connexion à d’autres serveurs

• Compte NetworkService

 Machine sur domaine nécessitant la connexion à d’autres serveurs

• Compte Utilisateur du Domaine

 Bon choix…

sorting listitems in dropdown ASP.NET

ListItemCollection items = new ListItemCollection();
        items.Add( new ListItem("Item 2", "Item 2"));
        items.Add(new ListItem("Item 1", "Item 2"));
        items.Add(new ListItem("Item 3", "Item 2"));
        SortListItems(items, false);  

// true or false based on descending or ascending
        ddlworkshops.DataSource = items ;
        ddlworkshops.DataBind(); 

   public void SortListItems(ListItemCollection items, bool Descending)
    {
        List<ListItem> list = new List();
        foreach (ListItem i in items)
        { list.Add(i);
        }
        if (Descending)
        {   list.Sort(delegate(ListItem x, ListItem y) {  

            return y.Text.CompareTo(x.Text); });
        }
        else
        {   list.Sort(delegate(ListItem x, ListItem y) { 

            return x.Text.CompareTo(y.Text); });
        }
        items.Clear();
        items.AddRange(list.ToArray());
    }