Rôles d'applications

Un rôle d'application est un principal de base de données qui permet à une application de s'exécuter avec ses propres autorisations de type utilisateur. Vous pouvez utiliser les rôles d'application pour permettre l'accès à des données spécifiques aux utilisateurs qui se connectent via une application spécifique. À la différence des rôles de base de données, les rôles d'application ne contiennent pas de membres et sont inactifs par défaut. Les rôles d'application fonctionnent avec les deux modes d'authentification. Les rôles d'application sont activés grâce à sp_setapprole qui nécessite un mot de passe. Les rôles d'application étant un principal au niveau des bases de données, ils peuvent uniquement accéder à d'autres bases de données via les autorisations accordées dans ces bases de données à invité. Par conséquent, toute base de données où invité a été désactivé est inaccessible aux rôles d'application des autres bases de données.

Dans SQL Server, les rôles d'application ne peuvent pas accéder à des métadonnées au niveau serveur, car ils ne sont pas associés à un principal au niveau serveur Pour désactiver cette restriction et permettre ainsi aux rôles d'application d'accéder aux métadonnées de niveau serveur, définissez l'indicateur global 4616. Pour plus d'informations, consultez Indicateurs de trace (Transact-SQL) et DBCC TRACEON (Transact-SQL).

Connexion avec un rôle d'application

Les étapes suivantes composent le processus par lequel un rôle d'application fait basculer les contextes de sécurité :

1. Un utilisateur exécute une application cliente.

2. L'application cliente se connecte à une instance de SQL Server sous le nom de cet utilisateur.

3. L'application exécute ensuite la procédure stockée sp_setapprole avec un mot de passe uniquement connu pour l'application.

4. Si le nom et le mot de passe du rôle d'application sont valides, le rôle d'application est activé.

5. À ce stade, la connexion perd les autorisations de l'utilisateur et adopte les autorisations du rôle d'application.

Les autorisations acquises via le rôle d'application restent effectives pendant la durée de la connexion.

Dans les versions précédentes de SQL Server, lorsqu'un utilisateur a démarré un rôle d'application, il peut récupérer son contexte de sécurité initial uniquement en se déconnectant de SQL Server et en s'y reconnectant. À partir de SQL Server 2005, sp_setapprole a une option qui crée un cookie. Le cookie contient des informations de contexte avant que le rôle d'application soit activé. Le cookie peut être utilisé par sp_unsetapprole pour rétablir la session à son contexte d'origine. Pour obtenir des informations sur cette nouvelle option et un exemple, consultez sp_setapprole (Transact-SQL).

Remarque relative à la sécurité

L'option encrypt d'ODBC n'est pas prise en charge par SqlClient. Lorsque vous transmettez des informations confidentielles sur un réseau, utilisez le protocole SSL (Secure Sockets Layer) ou IPsec pour chiffrer le canal. Si vous devez conserver des informations d'identification dans l'application cliente, chiffrez-les à l'aide des fonctions API de chiffrement. Dans SQL Server 2005 et les versions ultérieures, le paramètre password est stocké sous la forme d'un hachage unidirectionnel.

Tâches associées

Voir aussi

Concepts

Sécurisation de SQL Server