L'utilisation de la sécurité intégrée (SSPI) pour accéder à SQL Server est-elle meilleure pour les applications Web?

Lors du déploiement d'applications Web (.net) dans un environnement de production, est-il préférable d'utiliser la sécurité intégrée ou est-ce même important?

Il me semble que si un pirate informatique brise le serveur Web, cela n'aura pas vraiment d'importance car il peut facilement se faire passer pour la machine.

Pensées?

Je dirais qu'il n'y a que deux raisons valables pour utiliser l'authentification SQL:

1. Vous vous connectez depuis l'extérieur du domaine, donc authentification intégrée.
2. Vous exécutez une référence TPC-C et chaque cycle compte. L'authentification SQL est un tout petit peu plus rapide.

Pour le scénario que vous proposez (l'hôte du serveur Web est complètement compromis), rien ne peut vous protéger. Le pirate peut faire sur le serveur DB au minimum tout ce que le serveur Web peut faire . Et je dirais que la défense en profondeur peut vous apprendre à minimiser la perte dans un tel cas: réduisez les droits DB du compte utilisé par votre serveur Web au strict minimum requis et rien de plus. Assurez-vous ensuite que si l'hôte du serveur Web est compromis, il ne peut pas être utilisé pour élever des privilèges supérieurs au compte du serveur Web (c'est-à-dire qu'il n'y a pas d'autre service sur l'hôte WWW qui utilise des informations d'identification avec des privilèges plus élevés sur la base de données que le compte WWW). Ce sont des principes de sécurité de base et n'ont rien à voir avec le schéma d'authentification utilisé.

Bien que l'authentification SQL par rapport à l'authentification Windows ne donne aucun avantage clair à votre scénario, il y a d'autres problèmes à considérer:

1. Application centralisée des politiques: vous avez un endroit pour configurer vos politiques de mot de passe, y compris la durée de vie et l'expiration du mot de passe, la fermeture de compte, etc.
2. Contrôle de l'emprunt d'identité et de la délégation de confiance. Une fois que l'authentification sql est utilisée dans une chaîne de délégation de confiance, tous les paris sont désactivés car il ne s'agit pas d'une véritable «délégation» et ne sont donc plus soumis aux restrictions imposées par vos stratégies
3. Audit: l'authentification sql n'est même pas vue par votre LSA, donc toute votre infrastructure d'audit est simplement contournée. Vous devez ajouter explicitement les enregistrements que SQL produit sur les événements d'authentification SQL, mais mélange les pommes et les oranges car ces événements ont une source, un fournisseur et un schéma différents dans le journal des événements

Une dernière remarque: le protocole TDS expose le mot de passe d'authentification sql en texte clair sur le trafic, mais cela est généralement atténué en demandant le cryptage SSL du trafic.

Alors pourquoi voyez-vous toujours des hôtes WWW d'authentification sql qui stockent le mot de passe en clair dans web.config? Ce sont les mauvais développeurs / administrateurs, n'en faites pas partie.

msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx

technet.microsoft.com/en-us/library/ms189067.aspx

Si vous n'utilisez pas SSPI, vous codez en dur le nom d'utilisateur et le mot de passe dans les fichiers source.

Si vous codez en dur le nom d'utilisateur et le mot de passe dans les fichiers source, tous vos employés y ont accès.

C'est relativement peu sûr. Un ancien employé mécontent pourrait utiliser les informations de manière malveillante. Un visiteur peut voir le code quelque part sur un écran. Ou le code source pourrait accidentellement sortir dans la nature.

L'avantage de SSPI est que le mot de passe n'est jamais stocké nulle part en clair.

Jusqu'à présent, les autres réponses ont été bonnes, mais je vais en ajouter une autre: la gestion.

Tôt ou tard, vous allez probablement vous retrouver avec plusieurs serveurs SQL. La gestion de l'authentification SQL entre votre application et plusieurs serveurs SQL devient un peu pénible, surtout lorsque vous rencontrez des problèmes de sécurité. Si vous modifiez une fois le mot de passe d'authentification Windows, il change immédiatement sur tous vos serveurs. Si vous devez faire pivoter vos mots de passe d'authentification SQL, c'est plus douloureux - au point que vous ne le ferez probablement pas du tout. C'est un risque pour la sécurité.

Je ne suis pas sûr à 100% ici, mais je pense que le point principal est que l'authentification SQL n'est pas sécurisée, il est donc préférable d'utiliser l'authentification Windows. Selon la configuration de votre application, vous pouvez également stocker les informations d'identification appropriées sous une forme chiffrée sur la machine à l'aide de l'authentification Windows. Je ne pense pas que ce soit vraiment possible avec l'authentification SQL. Vous pouvez l'obscurcir, mais en fin de compte, cela doit être clair.

De plus, ce n'est pas parce qu'un pirate peut accéder à un serveur que le jeu est terminé. Un pirate pourrait prendre le contrôle d'un processus non privilégié mais ne rien faire d'autre sur le serveur. C'est pourquoi il est important de ne pas tout exécuter en tant qu'administrateur ou système, mais plutôt d'utiliser des comptes de service à privilèges minimum.

La meilleure chose à faire est de limiter ce qu'ils peuvent faire si / quand ils pénètrent dans le serveur Web. Cela signifie accorder uniquement les droits SQL requis pour que l'application fonctionne. Il est beaucoup plus facile d'accorder des droits DBO à l'application, mais cela rend la base de données beaucoup plus vulnérable en cas d'attaque réussie contre le serveur Web.

Je vais faire précéder tout cela en disant que je fais l'hypothèse que vous parlez d'un serveur Web interne sur le réseau privé interne.

Commençons par l'emprunt d'identité de la machine. Si l'identité du pool d'applications est Service réseau et qu'il n'y a pas d'emprunt d'identité dans l'application .NET, alors oui, l'application Web se connectera au serveur SQL principal en utilisant le compte d'ordinateur de la machine. Et cela signifierait que vous avez accordé l'accès à ce compte d'ordinateur. Le CRM de Microsoft fonctionne de cette façon.

Cependant, si vous avez spécifié une identité, ce compte d'utilisateur devra avoir accès à SQL Server. Bien que vous ayez raison de dire que si un attaquant a compromis le serveur Web, il a effectivement le même accès que le compte d'identité, la vérité est que l'utilisation d'une connexion SQL Server ne change rien ici. Une fois que j'y ai accès, je peux modifier l'application Web pour faire ce que je veux et ce sera, au maximum, votre sécurité le permet sur le serveur SQL principal.

Maintenant, pourquoi utiliser SSPI. Tout d'abord, vous n'utilisez pas de connexion basée sur SQL Server. Cela signifie qu'Active Directory est la seule source de sécurité. Cela signifie que vous disposez des moyens d'audit normaux pour déterminer l'accès non valide. Deuxièmement, cela signifie qu'à moins que d'autres applications ne l'exigent, vous pouvez laisser votre SQL Server en mode d'authentification Windows uniquement. Cela signifie qu'aucune connexion SQL Server n'est autorisée. Cela signifie que toutes les attaques contre sa sont arrêtées avant même de commencer. Et enfin, cela facilite la récupération. Si vous utilisez une connexion basée sur SQL Server, vous devrez extraire la connexion avec le SID et le mot de passe chiffré. Si vous utilisez un compte d'utilisateur Windows en tant que «compte de service», lorsque vous accédez à un nouveau serveur SQL, en créant la connexion,

La question est qui est "mieux"? Ce qui est difficile à répondre car il dépend du contexte, des valeurs et des priorités de l'interrogateur.

Personnellement, j'aime l'authentification SQL.

• AD est une autre chose pour exécuter et prendre en charge et gérer les comptes de service.
• AD doit être disponible dans votre environnement d'hébergement.
• AD rendrait difficile le passage au cloud ou au cloud hybride.
• AD facilite l'ajout de comptes de service dans des groupes auxquels les administrateurs ne devraient pas appartenir dans une autre partie de votre organisation.
• SSPI ne contourne pas le problème du cryptage de votre chaîne de connexion, car vous devez crypter votre nom d'hôte SQL dans la configuration.
• L'authentification SQL est une configuration de texte simple et juste, facile à déployer.
• La définition des identités du pool d'applications est une autre chose pour automatiser puis masquer le nom d'utilisateur et le mot de passe dans ces scripts d'automatisation pour chaque environnement.
• L'utilisation de deux chaînes de connexion facilite l'utilisation de mots de passe évolutifs afin que vous puissiez mettre à jour le mot de passe sans interruption.

Dernier point: vous codez votre classe de gestionnaire de connexions pour essayer chaque chaîne de connexion, de cette façon, vous pouvez changer le mot de passe sur la première dans la configuration, pousser la modification, et il basculera vers la deuxième connexion, puis vous mettrez à jour le mot de passe sur MSQL et le premier sera à nouveau utilisé. Un dernier changement de configuration est nécessaire pour définir le deuxième mot de passe comme le premier, prêt pour la prochaine fois.

Si les utilisateurs ne manipulent pas directement la base de données (via d'autres outils clients tels que SQL Server Management Studio), je vais généralement simplement créer une connexion SQL unique pour l'application et lui accorder l'accès dont elle a besoin. À ce stade, l'utilisateur est limité dans ce qu'il peut faire comme le permet l'interface de l'application Web.