Scénarios de sécurité des applications dans SQL Server (ADO.NET)
Mise à jour : November 2007
Aucune méthode universelle n'existe pour créer une application cliente SQL Server sécurisée. Chaque application est unique au niveau de sa configuration, de son environnement de déploiement et de ses utilisateurs. Une application relativement sécurisée lors de son déploiement initial peut devenir moins sécurisée avec le temps. Il est impossible d'anticiper avec précision sur les menaces qui peuvent survenir dans le futur.
SQL Server, en tant que produit, a évolué version après version pour offrir aujourd'hui les fonctionnalités de sécurité les plus récentes permettant aux développeurs de créer des applications de base de données sécurisées. Toutefois, la sécurité n'est pas toujours acquise ; elle requiert une surveillance et des mises à jour constantes.
Menaces courantes
Les développeurs doivent connaître les menaces de sécurité, les outils disponibles pour les contrer et la manière d'éviter les défaillances de sécurité qu'ils se créent eux-mêmes. La sécurité peut être envisagée comme une chaîne dans laquelle un maillon manquant compromet la solidité de l'ensemble. La liste suivante comprend quelques menaces de sécurité courantes évoquées plus en détail dans les rubriques de cette section.
Injection SQL
L'injection SQL est le processus qui permet à un utilisateur malveillant d'entrer des instructions Transact-SQL au lieu d'une entrée valide. Si l'entrée est transmise directement au serveur sans validation et si l'application exécute accidentellement le code injecté, l'attaque risque d'endommager ou de détruire des données. Vous pouvez déjouer les attaques d'injection SQL Server à l'aide de procédures stockées et de commandes paramétrées, en évitant le code SQL dynamique et en limitant les autorisations de tous les utilisateurs.
Élévation de privilège
Les attaques d'élévation de privilège se produisent lorsqu'un utilisateur s'empare des privilèges d'un compte approuvé, un administrateur ou un propriétaire par exemple. Exécutez toujours le code sous des comptes d'utilisateurs disposant des privilèges minimum et attribuez uniquement les autorisations nécessaires. Évitez l'utilisation des comptes d'administrateur ou de propriétaire pour l'exécution du code. Ainsi, vous limitez l'étendue des dommages qui peuvent se produire si une attaque réussit. Lorsque vous effectuez des tâches qui nécessitent des autorisations supplémentaires, utilisez la signature de procédure ou l'emprunt d'identité pour la durée de la tâche. À partir de SQL Server 2005, vous pouvez signer les procédures stockées à l'aide de certificats ou utiliser l'emprunt d'identité pour affecter des autorisations de manière temporaire.
Détection des attaques et surveillance intelligente
Une attaque de détection peut utiliser des messages d'erreur générés par une application pour rechercher des vulnérabilités dans la sécurité. Implémentez la gestion des erreurs dans tout le code de procédure pour éviter de retourner des informations d'erreurs SQL Server à l'utilisateur final.
Authentification
Une attaque par injection de chaîne de connexion peut se produire lors de l'utilisation de connexions SQL Server si une chaîne de connexion basée sur l'entrée d'utilisateur est construite au moment de l'exécution. Si la vérification de paires de mots clés valides n'est pas effectuée au niveau de la chaîne de connexion, un attaquant peut insérer des caractères supplémentaires et accéder éventuellement à des données sensibles ou à d'autres ressources sur le serveur. Utilisez l'authentification Windows lorsque cela est possible. Si vous devez utiliser des connexions SQL Server, utilisez SqlConnectionStringBuilder pour créer et valider des chaînes de connexion au moment de l'exécution.
Mots de passe
De nombreuses attaques réussissent lorsqu'un intrus a su deviner ou se procurer le mot de passe d'un utilisateur privilégié. Les mots de passe représentent la première ligne de défense contre les intrus, la définition de mots de passe forts est donc un élément essentiel de la sécurité de votre système. À partir de SQL Server 2005, créez et appliquez des stratégies de mot de passe pour l'authentification en mode mixte.
Affectez toujours un mot de passe fort au compte sa, même lorsque vous utilisez l'authentification Windows.
Dans cette section
Gestion des autorisations à l'aide des procédures stockées dans SQL Server (ADO.NET)
Décrit comment utiliser des procédures stockées pour gérer les autorisations et contrôler l'accès aux données. L'utilisation des procédures stockées est un moyen efficace pour pallier de nombreuses menaces concernant la sécurité.Écriture de code SQL dynamique sécurisé dans SQL Server (ADO.NET)
Décrit des techniques permettant d'écrire du code SQL dynamique sécurisé à l'aide de procédures stockées.Signature de procédures stockées dans SQL Server (ADO.NET)
Décrit comment signer une procédure stockée avec un certificat pour permettre aux utilisateurs de disposer des données auxquelles ils n'ont pas un accès direct. Cela permet aux procédures stockées d'effectuer des opérations que l'appelant n'est pas autorisé à effectuer directement.Personnalisation des autorisations avec emprunt d'identité dans SQL Server (ADO.NET)
Décrit la manière d'utiliser la clause EXECUTE AS pour emprunter l'identité d'un autre utilisateur. L'emprunt d'identité transfère le contexte de l'exécution de l'appelant vers l'utilisateur spécifié.Octroi d'autorisations de niveau ligne dans SQL Server (ADO.NET)
Décrit comment implémenter des autorisations au niveau de la ligne pour limiter l'accès aux données.Création de rôles d'application dans SQL Server (ADO.NET)
Décrit les fonctions et les fonctionnalités de rôles d'application.Activation de l'accès aux bases de données croisées dans SQL Server (ADO.NET)
Décrit comment activer l'accès aux bases de données croisées sans risque pour la sécurité.
Voir aussi
Autres ressources
Sécurité de SQL Server (ADO.NET)