Le modèle de sécurité de SQL Server a évolué au cours des différentes versions. Chaque version de SQL Server a amené son lot de nouveautés en même temps que les versions de Windows sur lequel il repose. Avec la venue de Windows Vista, Seven ou Server 2008 il est apparu la notion de SID pour les services Windows. Depuis SQL Server 2008 il est possible d’utiliser cette fonctionnalité offerte par les nouvelles versions du système d’exploitation. Mais qu’est ce que un SID exactement ? A quoi cela peut bien servir ? Quels sont les avantages ?

Faisons tout d’abord un bon en arrière avec les version 2000 et 2005 de SQL Server. Avec SQL Server 2000 le paramétrage d’un compte de service pour SQL Server donnait lieu à la création d’un login SQL correspondant appartenant au rôle de serveur sysadmin. Les droits nécessaires sont octroyés comme Log On As A Service, Replace a Process-Level Token etc… mais ce n’est pas le cas des ACL des fichiers et dossiers. SQL Server 2005 apporte une réponse ce problème en introduisant des groupes prédéfinis créés lors de l’instance (SQLServer2005MSSQLUser$InstanceName pour le moteur SQL Server par exemple). Ces groupes permettent une administration beaucoup plus simple des comptes de services. Les ACL sont configurées directement pour les groupes concernés. Le compte de service concerné n’est plus qu’à être ajouté en tant que membre du groupe Windows adéquate.

Mais dans les deux cas, c’est le contexte de sécurité du compte ou du groupe Windows qui est utilisé, ce qui ne permet pas une isolation complète des ressources dédiés à une instance SQL Server. En effet imaginez qu’une instance SQL Server utilise un compte de service A et que plusieurs autres applications utilisent ce même compte de service A. Cela signifierait que ces dernières pourraient donc avoir accès aux ressources de notre instance SQL Server. Prenons un 2ème exemple où deux instances SQL Server cohabitent sur le même serveur. Si ces deux instances utilisent le même compte de service cela signifie qu’elles ont accès mutuellement à leurs ressources. Dans un contexte de sécurisation ce n’est pas vraiment ce que l’on veut.

Dans le schéma qui suit les flèches rouges représentent les accès potentiels non désirés. On voit ici que l’utilisation d’un même compte de domaine en tant que compte de service par différentes applications comme SQL Server ou des applications métiers peut vite engendrer des problèmes d’accès aux ressources. Chaque application peut avoir accès aux ressources des autres. Hors tout le monde le sait, beaucoup d’attaques se produisent par le biais des services Windows.

Comment régler ce problème ? Au final, nous voulons que seul le service d’une application ait accès à ses ressources. Nous ne voulons pas utiliser de contexte utilisateur mais un contexte « de service ». C’est ce que propose Microsoft à partir des versions Windows Vista, Seven ou Server 2008. Chaque service possède son propre (et unique) identifiant appelé SID. C’est cet identifiant qui sera directement utilisé pour paramétrer les différentes ACL des ressources concernées. L’avantage est ici est certain : on n’utilise plus l’identifiant du compte utilisateur mais l’identifiant du service pour avoir accès aux ressources. L’utilisation d’un compte utilisateur pour deux instances SQL Server ne posera plus de problème dans ce cas car au final c’est le SID des différents services SQL Server qui seront utilisés pour avoir accès aux ressources nécessaires. Il en va de même pour les services concernant le moteur SQL et l’agent SQL.

Sous SQL Server cela se traduit par l’appariation de deux comptes de connexion (pour une instance par défaut) :

• NT SERVICE\MSSQLSERVER pour le moteur SQL
• NT SERVICE\SQLSERVERAGENT pour l’agent SQL Server

Ces 2 comptes font parti du rôle de serveur sysadmin.

On retrouve notre SID dans les ACL (A noter aussi que l’on peut retrouver le groupe Windows SQLServer2005MSSQLUser créé par SQL Server lors de l’installation. Le SID fait automatiquement parti de ce groupe) :

Pour une instance nommée :

A noter que :

• Il n’existe plus de compte de connexion associé aux groupes Windows du type SQLServerMSSQLUser$… alors que dans la version 2005 ceux-ci étaient présents et faisaient parti du rôle de serveur sysadmin
• Tous les services qui concernent de près ou de loin SQL Server ne peuvent pas utiliser de SID. Par exemple avec SQL Server 2008 et 2008 R2 le service SQL Writer n’utilise pas de SID. Avec SQL Server Denali (CTP3) il semblerait que ceci ne soit plus vrai. On peut facilement le vérifier avec la commande suivante :

       sc qsidtype [servicename]

       La sortie de cette commande peut donner les résultats suivants :

• None (0x0) – the service will not have a per-service SID.  This is the default configuration for a service
• Unrestricted (0x1) – the service has a per-service SID
• Restricted (0x3) – the service has a per-service SID and a write-restricted token.

L’utilisation des SID pour les services SQL permettent une délimitation et une isolation beaucoup plus marquée des ressources propres à chaque instance SQL Server. Encore un grand pas en avant dans le domaine de la sécurité !

David BARBARIN (Mikedavem)
MVP SQL Server