Sécuriser l'accès aux données
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 pourrait 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 recommandée pour les bases de données locales 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.
Important
Microsoft vous recommande d’utiliser le flux d’authentification le plus sécurisé disponible. Si vous vous connectez à Azure SQL, les identités managées pour les ressources Azure sont la méthode d'authentification recommandée.
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, consultez les ressources ci-dessous.
| Ressource | Description |
|---|---|
| Protection des informations de connexion | 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. |
| Builders de chaînes de connexion | Décrit comment créer des chaînes de connexion à partir de l'entrée de l'utilisateur au moment de l'exécution. |
| Sécurité pour le moteur de base de données SQL Server et la base de données Azure SQL | Fournit des liens pour vous aider à trouver des informations sur la sécurité et la protection dans le moteur de base de données SQL Server et Azure SQL Database |
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étrées, voir les ressources répertoriées ci-dessous.
| Ressource | Description |
|---|---|
| Paramètres DataAdapter | Décrit comment utiliser des paramètres avec un DataAdapter. |
| Modification des données avec les procédures stockées | Décrit comment spécifier des paramètres et obtenir une valeur de retour. |
| Procédures stockées (moteur de base de données) | Décrit les avantages de l'utilisation de procédures stockées et des différents types de procédures stockées qui existent. |
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, consultez les ressources ci-dessous.
| Ressource | Description |
|---|---|
| Gestion et levée d’exceptions dans .NET | Décrit les formes de base de la gestion des exceptions structurée autour du bloc try/catch/finally. |
| Meilleures pratiques pour les exceptions | Décrit les meilleures pratiques de gestion des exceptions. |
Protéger 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 exigences 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.
Enterprise Services
COM + contient son propre modèle de sécurité qui s’appuie sur les comptes Windows et sur l’emprunt d’identité des processus/threads. 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.
Interopérer avec du code non managé
.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, consultez Interopération avec du code non managé.