Gestion des autorisations à l'aide des procédures stockées dans SQL Server (ADO.NET)
Une méthode pour créer plusieurs lignes de défense autour de votre base de données consiste à implémenter tous les accès aux données à l'aide de procédures stockées ou de fonctions définies par l'utilisateur. Vous révoquez ou refusez toutes les autorisations sur les objets sous-jacents, tels que les tables, et accordez les autorisations EXECUTE sur les procédures stockées De cette manière, vous créez un périmètre de sécurité autour vos objets de données et de base de données.
Avantages des procédures stockées
Les procédures stockées ont les avantages suivants :
Les règles d'entreprise et la logique des données peuvent être encapsulées de telle sorte que les utilisateurs ont accès aux données et aux objets uniquement selon les méthodes définies par les développeurs et les administrateurs de bases de données.
Des procédures stockées paramétrées et chargées de valider toutes les entrées d'utilisateur peuvent servir à contrer les attaques par injection SQL. Si vous utilisez du code SQL dynamique, veillez à paramétrer vos commandes et n'incluez jamais de valeurs de paramètre directement dans une chaîne de requête.
Les modifications des requêtes et des données ad hoc peuvent être interdites. Ainsi, les utilisateurs ne peuvent pas, par inadvertance ou par malveillance, détruire des données ou exécuter des requêtes qui nuisent aux performances sur le serveur ou le réseau.
Les erreurs peuvent être traitées dans le code de procédure sans passer directement dans les applications clientes. Cela empêche le retour de messages d'erreur, ce qui peut contribuer à une attaque de détection. Enregistrez les erreurs et traitez-les sur le serveur.
Les procédures stockées peuvent être écrites une seule fois et sont accessibles par de nombreuses applications.
Les applications clientes n'ont pas besoin de recevoir des informations sur les structures de données sous-jacentes. Le code des procédures stockées peut être modifié sans nécessiter des changements dans les applications clientes à condition que ces changements ne concernent pas les listes de paramètres ou les types de données retournés.
Les procédures stockées peuvent réduire le trafic réseau en associant plusieurs opérations dans un appel de procédure.
Exécution des procédures stockées
Les procédures stockées tirent parti du chaînage des propriétés permettant de fournir l'accès aux données pour ne pas que les utilisateurs aient l'autorisation explicite d'accéder aux objets de base de données. Une chaîne de propriétés existe lorsque les objets qui sont accessibles les uns aux autres de manière séquentielle sont détenus par le même utilisateur. Par exemple, une procédure stockée peut appeler d'autres procédures stockées, ou une procédure stockée peut accéder à plusieurs tables. Si tous les objets dans la chaîne d'exécution ont le même propriétaire, SQL Server se contente de vérifier l'autorisation EXECUTE pour l'appelant, et non les autorisations de l'appelant sur d'autres objets. Par conséquent, il vous suffit d'accorder les autorisations EXECUTE sur les procédures stockées ; vous pouvez révoquer ou refuser toutes les autorisations sur les tables sous-jacentes.
Recommandations
La simple écriture de procédures stockées ne suffit pas à sécuriser votre application de façon adéquate. Vous devez également envisager les défaillances de sécurité potentielles suivantes.
Accordez les autorisations EXECUTE sur les procédures stockées pour les rôles de base de données que vous souhaitez faire accéder aux données.
Révoquez ou refusez toutes les autorisations sur les tables sous-jacentes pour tous les rôles et les utilisateurs de la base de données, y compris le rôle public. Tous les utilisateurs héritent des autorisations de public. Par conséquent, le refus des autorisations à public signifient que seuls les membres et les propriétaires sysadmin ont un accès ; tous les autres utilisateurs ne pourront pas hériter des autorisations issues des appartenances d'autres rôles.
N'ajoutez pas d'utilisateurs ou de rôles aux rôles sysadmin ou db_owner. Les administrateurs système et les propriétaires de bases de données peuvent accéder à tous les objets de base de données.
Désactivez le compte guest. Cela empêche les utilisateurs anonymes de se connecter à la base de données. Le compte invité est désactivé par défaut dans les nouvelles bases de données.
Implémentez la gestion des erreurs et enregistrez les erreurs.
Créez des procédures stockées paramétrées qui valident toutes les entrées d'utilisateur. Traitez toutes les entrées d'utilisateur comme non approuvées.
Évitez d'utiliser le code SQL dynamique, sauf si cela est absolument nécessaire. Utilisez la fonction Transact-SQL QUOTENAME() pour délimiter une valeur de chaîne et échapper à toute occurrence du délimiteur dans la chaîne d'entrée.
Ressources externes
Pour plus d'informations, voir les ressources suivantes.
Ressource |
Description |
---|---|
Procédures stockées et Injection SQL dans la documentation en ligne de SQL Server 2008 |
Ces rubriques expliquent comment créer des procédures stockées et comment fonctionne l'injection SQL. |
Procédures stockées et Injection SQL dans la documentation en ligne de SQL Server 2005 |
Ces rubriques expliquent comment créer des procédures stockées et comment fonctionne l'injection SQL. |
Procédures stockées et Utilisation des chaînes de propriétés dans la documentation en ligne de SQL Server 2000 |
Ces rubriques expliquent comment créer des procédures stockées et comment tirer parti des chaînes de propriétés dans SQL Server 2000. |
Voir aussi
Concepts
Scénarios de sécurité des applications dans SQL Server (ADO.NET)
Écriture de code SQL dynamique sécurisé dans SQL Server (ADO.NET)
Signature de procédures stockées dans SQL Server (ADO.NET)
Personnalisation des autorisations avec emprunt d'identité dans SQL Server (ADO.NET)
Modification de données à l'aide de procédures stockées (ADO.NET)