Sécurité SQL Server de la base de données ASP.NET2.0

Auteur：Eve Cole Date de mise à jour：2009-06-30 16:43:56

Il existe deux options pour le mode sans échec lors de l'installation de SQL Server. La différence entre eux réside dans le logiciel qui effectue le processus d'authentification. L'authentification est le processus de confirmation de l'identité d'un utilisateur qui se connecte à SQL Server. Une fois l'authentification effectuée, SQL Server peut vérifier que l'utilisateur est autorisé à se connecter à une ressource demandée, telle qu'une base de données. Si l'utilisateur est autorisé à se connecter à la base de données, SQL Server autorisera la demande de connexion à réussir, sinon la connexion échouera. Ce processus de vérification de l'autorisation de l'utilisateur est également appelé autorisation.

· L'authentification Windows (également connue sous le nom d'authentification approuvée ou sécurité intégrée) utilise l'identité de l'utilisateur Windows effectuant la demande de connexion pour effectuer l'autorisation d'accès à la base de données. Dans ce cas, la chaîne de connexion n'a pas besoin de fournir un nom d'utilisateur et un mot de passe explicites. ASP.NET s'exécute en tant qu'utilisateur local nommé « ASPNET » (ou « Service réseau » dans IIS 6.0). Ainsi, lors de l'utilisation de l'authentification Windows, SQL vérifiera si cet utilisateur est autorisé à utiliser la base de données. À ce stade, toutes les applications ASP.NET s'exécutent avec ce même utilisateur, le mode sans échec les traite donc de la même manière. Bien qu'il soit possible d'exécuter chaque application dans un processus ASP.NET distinct (un utilisateur distinct exécutant chaque application) ou d'usurper l'identité de l'utilisateur Windows du client navigateur effectuant la demande de connexion, cela dépasse le cadre de ce livre. . Toutefois, l’usurpation d’identité du client constitue l’utilisation la plus courante de l’authentification Windows dans les applications Web.

· L'authentification SQL vérifie les noms d'utilisateur et les mots de passe explicitement fournis par rapport aux utilisateurs configurés dans SQL Server (sans impliquer le système d'exploitation). Dans ce cas, chaque application exécutée dans le processus ASP.NET peut se connecter à la base de données avec un certificat distinct, isolant ainsi raisonnablement les applications (l'application A ne pourra pas se connecter à la base de données si elle ne dispose pas du nom d'utilisateur et du mot de passe de B). . Impossible de se connecter à la base de données de B). Il s’agit du mode d’authentification le plus couramment utilisé pour les applications Web déployées, notamment dans le cas d’un hébergement mutualisé. Un petit inconvénient est qu'il oblige l'application à conserver le mot de passe du compte utilisateur utilisé pour se connecter, et si ce mot de passe est obtenu par un utilisateur malveillant, la sécurité de la base de données sera compromise. Cependant, comme vous le verrez plus loin dans ce livre, ASP.NET fournit un moyen sécurisé de stocker le mot de passe d'authentification SQL dans un format crypté dans le fichier Web.config, réduisant ainsi le risque d'obtention du mot de passe.

· Le mode mixte est une configuration de SQL Server qui permet à la fois l'authentification Windows et l'authentification SQL.

Lors de l'installation de SQL Server ou SSE, vous devez choisir un mode d'authentification. Dans SQL Server, il existe un assistant pour vous aider à choisir lors des étapes de sécurité, tandis que dans SSE, le choix par défaut est l'authentification Windows. Si vous souhaitez installer l'authentification SQL, vous devez la configurer explicitement. Cet article utilise l'authentification Windows.

Si vous avez installé SQL Server ou SSE, vous pouvez afficher le mode d'authentification spécifié en ouvrant RegEdit (bien sûr, vous devez d'abord le sauvegarder), recherchez HKey_Local_Machine/Software/Microsoft/Microsoft SQL Server et recherchez LoginMode. Une sous-clé d'enregistrement avec une valeur de 1 représente l'authentification Windows, tandis qu'une valeur de 2 représente le mode d'authentification mixte.

Le tableau 3-1 résume les différences entre ces modes.

Tableau 3-1

l'authentification SQL Windows ou SQL. Emplacement de la de Windows SQL Server d'installation d'une meilleure sécurité ;

	Authentification	Windows
Nom remplaçable de	Authentification approuvée Sécurité intégrée	Non, mais l'authentification en mode mixte permet l'utilisation de l'authentification
Intranet	liste	des
utilisateurs Internet et des processus d'	authentification	.
L'installation	par défaut	nécessite la spécification de la
chaîne de connexion	Trusted_connection=true ou Integrated Security. =vrai	utilisateur=nom d'utilisateur ; password=mot de passe
Utilisateurs d'applications Web ASP.NET Les utilisateurs	de processus ASP.NET, ASPNET (IIS 5.x) ou Network Service (IIS 6	)
bénéficient	ils	peuvent contrôler les événements SQL de l'utilisateur et le suivi des activités Windows.	être déployé sur la machine hôte sans créer de nouveau compte indépendant du système d'exploitation ; Le site intranet hébergé ne nécessite que des compétences modérées Fournit un moyen plus flexible pour les applications de se connecter à chaque base de données avec des certificats différents.
Inconvénients	Donner un certificat Windows à une application Web peut potentiellement définir une portée d'autorisations trop grande dans le système d'exploitation.	Les mots de passe sont stockés dans l'application Web (ce qui n'est pas le cas). cas dans l'authentification Windows). Confirmez que le mot de passe est enregistré dans le fichier Web.config et qu'il est crypté. Permet des opérations de bas niveau pour les applications Web utilisant des certificats sa. Créez toujours de nouveaux certificats pour les applications Web ASP.NET et accordez uniquement les autorisations requises

Maintenant que nous connaissons la manière sûre d'utiliser SQL, voyons comment le consommateur de données (contrôle DataSource) répondra aux exigences. Tout d'abord, utilisez les données obtenues à partir de VWD et de VWD Web Server (Cassini), principalement lors de la conception et des tests. Deuxièmement, les données doivent être accessibles depuis IIS après le déploiement. Les deux consommateurs de données ont des noms d'utilisateur différents. VWD et VWD Web Server utilisent le nom de la personne connectée à Windows, tandis que le programme IIS utilise le nom ASPNET.

Si SQL Server utilise l'authentification Windows, le contrôle SqlDataSource doit inclure le code suivant dans la chaîne de connexion : Integrated Security=true (ou Trusted_connection=true). Ce paramètre demandera à SQL Server d'authentifier les demandes de données en fonction du compte de connexion Windows du demandeur. Si vous êtes connecté en tant qu'utilisateur qui a installé SSE, son certificat accordera l'accès à SSE. Tout se passera bien avec VWD et VWD Web Server, car les utilisateurs de VW Web Server sont considérés comme des programmeurs connectés à Windows et disposent donc de comptes sur SSE. Cependant, même si l'application fonctionne correctement en dehors de VWD, elle ne fonctionnera pas correctement lorsque le site sera migré vers IIS. IIS s'exécute sous un compte utilisateur nommé ASPNET (ou Service réseau dans IIS6/Windows 2003 Server). Par conséquent, l'administrateur de la machine exécutant IIS doit ajouter l'utilisateur ASP.NET et accorder ses autorisations. Ce processus dépasse le cadre de ce livre, mais est décrit en détail dans de nombreux manuels d'administrateur IIS. En résumé, si SQL Server utilise l'authentification Windows, vous pouvez utiliser VWD et VWD Web Server pour effectuer les exercices de ce livre. Votre page ne peut s'exécuter sur IIS qu'après avoir accordé l'autorisation au compte de processus ASP.NET qui accède à la base de données.

Si SQL Server utilise l'authentification SQL, SQL mènera son propre processus d'authentification. Ce processus ne s'appuiera pas sur la liste des utilisateurs Windows. La chaîne de connexion contient deux paramètres : user=username, password=password. La page peut désormais être utilisée depuis VWD, VWD Web Server ou IIS, car il n'est pas nécessaire de créer un compte utilisateur sous Windows. Cependant, nous devons également utiliser un compte dans SQL Server. Le seul compte par défaut est sa. Avant le déploiement, un autre compte doit être créé dans SQL Server qui est uniquement autorisé à exécuter des pages ASPX. Le fait de ne pas créer un compte alternatif autre que le sa (et un mot de passe pour protéger le sa) laisse le site ouvert à l'une des vulnérabilités de sécurité les plus connues et les plus facilement exploitables. Tout pirate informatique sait se connecter en utilisant userID='sa' avec un mot de passe vide.

Pour les deux modes d'authentification, lors de l'utilisation de la chaîne de connexion décrite précédemment, l'utilisateur se connectera à SQL Server avec le compte initial. Ce compte est sa, ce qui signifie administrateur système. Comme son nom l'indique, il dispose de toutes les autorisations sur tous les objets. Dans la version actuelle de SQL Server, le service ne peut pas être installé avec sa avec un mot de passe NULL. Dans SSE, il doit être installé avec le paramètre SAPWD="MyStrongPassword". Un mot de passe fort signifie ici au moins pas NULL. Il est préférable d'utiliser au moins sept caractères et de veiller à utiliser un mélange de lettres, de chiffres et de symboles. Dans la plupart des cas, en dehors des exercices des étudiants, un compte devra être attribué à chaque base de données et application. Il convient d'éviter de donner à une application l'autorisation d'accéder aux données d'autres applications.