Accès à des données sécurisées (ADO.NET)
Pour écrire un code ADO.NET sécurisé, vous devez comprendre les mécanismes de sécurité disponibles dans la base de données ou le magasin de données sous-jacent. Vous devez également prendre en compte les implications relatives à la sécurité des autres fonctionnalités ou composants que votre application peut contenir.
Authentification et autorisations
Lorsque vous vous connectez à Microsoft SQL Server, vous pour utiliser l'authentification Windows, également appelée sécurité intégrée, qui utilise l'identité de l'utilisateur Windows actif au lieu de transmettre un ID d'utilisateur et un mot de passe. L'utilisation de l'authentification Windows est hautement recommandée car elle permet de ne pas exposer les informations d'identification de l'utilisateur dans la chaîne de connexion. Si vous ne pouvez pas utiliser l'authentification Windows pour vous connecter à SQL Server, envisagez de créer des chaînes de connexion au moment de l'exécution, en utilisant SqlConnectionStringBuilder.
Les informations d'identification utilisées pour l'authentification doivent être traitées différemment en fonction du type d'application. Par exemple, dans une application Windows Forms, il se peut que l'utilisateur soit invité à fournir des informations d'authentification ou que les informations d'identification Windows de l'utilisateur soient utilisées. Toutefois, il est fréquent qu'une application Web accède à des données à l'aide d'informations d'identification fournies par l'application elle-même plutôt que par l'utilisateur.
Une fois les utilisateurs authentifiés, la portée de leurs actions dépend des autorisations qui leur ont été accordées. Suivez toujours le principe des privilèges minimum et accordez uniquement les autorisations qui sont absolument nécessaires.
Pour plus d'informations, voir les ressources répertoriées ci-dessous.
Ressource |
Description |
|---|---|
Décrit les techniques et meilleures pratiques de sécurité permettant de protéger les informations de connexion, telles que l'utilisation d'une configuration protégée pour chiffrer les chaînes de connexion. |
|
Fournit des recommandations pour l'accès aux données et l'exécution d'opérations de base de données. |
|
Décrit comment créer des chaînes de connexion à partir de l'entrée de l'utilisateur au moment de l'exécution. |
|
Décrit l'architecture de sécurité de SQL Server. |
Commandes paramétrées et injection de code SQL
L'utilisation des commandes paramétrées aide à se protéger des attaques par injection de code SQL, dans lesquelles un attaquant « injecte » une commande dans une instruction SQL qui compromet la sécurité sur le serveur. Les commandes paramétrées protègent contre une attaque par injection de code SQL en garantissant que les valeurs reçues à partir d'une source externe sont passées en tant que valeurs uniquement et non pas comme partie intégrante de l'instruction Transact-SQL. Par conséquent, les commandes Transact-SQL insérées dans une valeur ne sont pas exécutées au niveau de la source de données. Au lieu de cela, les valeurs sont évaluées uniquement comme valeurs de paramètre. Outre les avantages relatifs à la sécurité, les commandes paramétrées fournissent une méthode pratique d'organisation des valeurs passées avec une instruction Transact-SQL ou à une procédure stockée.
Pour plus d'informations sur l'utilisation des commandes paramétrables, voir les ressources répertoriées ci-dessous.
Ressource |
Description |
|---|---|
Décrit comment utiliser des paramètres avec un DataAdapter. |
|
Modification de données à l'aide de procédures stockées (ADO.NET) |
Décrit comment spécifier des paramètres et obtenir une valeur de retour. |
Gestion des autorisations à l'aide des procédures stockées dans SQL Server (ADO.NET) |
Décrit comment utiliser des procédures stockées SQL Server pour encapsuler l'accès aux données. |
Attaques de script
Une attaque de script est une autre forme d'injection qui utilise des caractères nuisibles insérés dans une page Web. Le navigateur ne valide pas les caractères insérés et les traitera dans le cadre de la page.
Pour plus d'informations, voir les ressources répertoriées ci-dessous.
Ressource |
Description |
|---|---|
Décrit comment se protéger contre des attaques de script et d'instructions SQL. |
Détection des attaques
Les attaquants utilisent souvent des informations incluses dans une exception, telles que le nom de votre serveur, base de données ou table pour organiser une attaque sur votre système. Étant donné que les exceptions peuvent contenir des informations spécifiques relatives à votre application ou à votre source de données, vous pouvez mieux protéger celles-ci en exposant au client seulement les informations indispensables.
Pour plus d'informations, voir les ressources répertoriées ci-dessous.
Ressource |
Description |
|---|---|
Décrit les formes de base de la gestion des exceptions structurée autour du bloc try/catch/finally. |
|
Décrit les meilleures pratiques de gestion des exceptions. |
Protection des sources de données Microsoft Access et Excel
Microsoft Access et Microsoft Excel peuvent faire office de magasin de données pour une application ADO.NET quand les conditions de sécurité sont minimales ou inexistantes. Leurs fonctionnalités de sécurité sont efficaces pour la dissuasion, mais ne comptez pas sur elles pour faire plus que décourager des utilisateurs non informés de s'impliquer. Les fichiers de données physiques pour Access et Excel existent sur le système de fichiers et doivent être accessibles à tous les utilisateurs. Cela les rend vulnérables à des attaques susceptibles d'entraîner un vol ou une perte de données car les fichiers peuvent être aisément copiés ou altérés. Lorsqu'une sécurité fiable est requise, utilisez une base de données SQL Server ou une base de données basée sur un autre serveur dans laquelle les fichiers de données physiques ne sont pas lisibles à partir du système de fichiers.
Pour plus d'informations sur la protection des données Access et Excel, voir les ressources répertoriées ci-dessous.
Ressource |
Description |
|---|---|
Décrit des techniques de sécurité pour Access 2007, telles que le chiffrement des fichiers, l'administration des mots de passe, la conversion des bases de données vers les nouveaux formats ACCDB et ACCDE, ainsi que l'utilisation d'autres options de sécurité. |
|
Vue d'ensemble de la sécurité et de la protection dans Excel |
Décrit comment contrôler qui peut accéder à vos données Excel 2007 et les modifier. |
Protéger une base de données et ses objets avec la sécurité au niveau utilisateur (MDB) |
S'applique à Access 2003. Fournit des instructions pour l'implémentation d'une sécurité au niveau utilisateur pour protéger les données dans Access 2003. |
Description du rôle des fichiers d'informations de groupe de travail dans la sécurité Access |
Explique le rôle et la relation du fichier d'informations de groupe de travail dans la sécurité Access 2003. |
Version téléchargeable du FAQ sur la sécurité de Microsoft Access. |
|
Résoudre les problèmes liés à la sécurité et à la protection |
Présente des solutions aux problèmes courants de sécurité dans Excel 2003. |
Enterprise Services
COM + contient son propre modèle de sécurité qui s'appuie sur les comptes Windows NT et l'emprunt d'identité de processus/thread. L'espace de noms System.EnterpriseServices fournit des wrappers qui permettent aux applications .NET d'intégrer du code managé avec des services de sécurité COM+ à l'aide de la classe ServicedComponent.
Pour plus d'informations, voir les ressources répertoriées ci-dessous.
Ressource |
Description |
|---|---|
Explique comment intégrer du code managé à des services de sécurité COM+. |
|
Explique comment utiliser les classes de l'espace de noms EnterpriseServices pour créer des composants de service. |
Interopérabilité avec du code non managé
Le .NET Framework permet l'interaction avec du code non managé, y compris des composants COM, des services COM+, des bibliothèques de types externes et de nombreux services de système d'exploitation. Travailler avec du code non managé implique de sortir du périmètre de sécurité pour le code managé. Votre code, ainsi que tout code qui l'appelle, doit disposer de l'autorisation de code non managé (SecurityPermission avec l'indicateur UnmanagedCode spécifié). Du code non managé peut introduire des vulnérabilités involontaires dans votre application. Par conséquent, vous devez éviter d'interagir avec du code non managé à moins que ce soit absolument nécessaire.
Pour plus d'informations, voir les ressources répertoriées ci-dessous.
Ressource |
Description |
|---|---|
Contient des rubriques qui décrivent comment exposer les composants COM au .NET Framework et comment exposer les composants .NET Framework à COM. |
|
Contient des sujets avancés tels que les assemblys PIA (Primary Interop Assembly), les threads et le marshaling personnalisé. |
Voir aussi
Concepts
Recommendations for Data Access Strategies
Protection des informations de connexion (ADO.NET)
Générateurs de chaînes de connexion (ADO.NET)