Les comptes SQL sont-ils moins sécurisés pour MS SQL Server 2008?

Question

J'ai Microsoft SQL Server 2008 sur lequel nous hébergeons certaines bases de données. Nous utilisons actuellement Windows Integration pour l'authentification.

Nous commençons à avoir besoin de la prise en charge de scripts d'authentification à partir d'ASP.NET et d'autres applications. Ces applications doivent utiliser des "informations d'identification de script" car elles s'exécutent sans qu'un utilisateur ne se connecte. Nous ne souhaitons pas vraiment le faire avec une connexion intégrée comme nous le faisons pour les administrateurs, nous examinons l'authentification SQL. Est-ce que cela réduit notre sécurité?

Answer 1

Oui, c'est le cas.

Utilisez un compte de service NT pouvant être configuré pour s'exécuter uniquement sur certains serveurs. En outre, vous pouvez appliquer tous les droits (tels que la connexion interactive) à l'aide de la stratégie de groupe.

connexions SQL, mais vous pouvez utiliser la stratégie de groupe AD pour les mots de passe, etc, sont intrinsèquement plus précaires

Vous n'avez pas faire ce sysadmin compte sur SQL Server

Edit:

Quelques raisons de l'insécurité au niveau du système et de la solution, pas SQL Server.

1. Le mot de passe doit être en texte clair quelque part (code, app.config, etc.). Pour un compte de service exécutant un pool d'applications IIS, ce n'est pas obligatoire.

2. Aucune restriction sur la machine client que vous utilisez. C'est-à-dire que le compte de service peut être limité à l'application ou au serveur Web.

3. Vous pouvez toujours avoir besoin de droits NFTS ou UNC quelque part: les connexions SQL ne peuvent pas gérer cela.