Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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 des rôles d’application pour activer l’accès à des données spécifiques aux seuls utilisateurs qui se connectent via une application particulière. Contrairement aux rôles de base de données, les rôles d’application ne contiennent aucun membre et ne sont pas inactifs par défaut. Les rôles d’application fonctionnent avec les deux modes d’authentification. Les rôles d’application sont activés à l’aide de sp_setapprole, ce qui nécessite un mot de passe. Étant donné que les rôles d’application sont un principal au niveau de la base de données, ils peuvent accéder à d’autres bases de données uniquement par le biais d’autorisations accordées dans ces bases de données à guest. Par conséquent, toute base de données dans laquelle l’invité a été désactivé est inaccessible aux rôles d’application dans d’autres bases de données.
Dans SQL Server, les rôles d’application ne peuvent pas accéder aux métadonnées au niveau du serveur, car ils ne sont pas associés à un principal au niveau du serveur. Pour désactiver cette restriction et autoriser ainsi les rôles d’application à accéder aux métadonnées au niveau du 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 constituent le processus par lequel un rôle d’application change les contextes de sécurité :
Un utilisateur exécute une application cliente.
L’application cliente se connecte à une instance de SQL Server en tant qu’utilisateur.
L’application exécute ensuite la procédure stockée sp_setapprole avec un mot de passe connu uniquement pour l’application.
Si le nom et le mot de passe du rôle d’application sont valides, le rôle d’application est activé.
À ce stade, la connexion perd les autorisations de l’utilisateur et suppose 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 antérieures de SQL Server, la seule façon pour un utilisateur de réacquire son contexte de sécurité d’origine après le démarrage d’un rôle d’application consiste à se déconnecter et à se reconnecter à SQL Server. À compter de SQL Server 2005, sp_setapprole a une option qui crée un cookie. Le cookie contient des informations de contexte avant l’activation du rôle d’application. Le cookie peut être utilisé par sp_unsetapprole pour rétablir la session dans son contexte d’origine. Pour plus d’informations sur cette nouvelle option et un exemple, consultez sp_setapprole (Transact-SQL).
Important
L’option de chiffrement ODBC n’est pas prise en charge par SqlClient. Lorsque vous transmettez des informations confidentielles sur un réseau, utilisez SSL (Secure Sockets Layer) ou IPsec pour chiffrer le canal. Si vous devez conserver les informations d’identification dans l’application cliente, chiffrez les informations d’identification à l’aide des fonctions d’API de chiffrement. Dans SQL Server 2005 et versions ultérieures, le mot de passe du paramètre est stocké en tant que hachage unidirectionnel.
Tâches associées
| Créez un rôle d’application. | Créer un rôle d’application et CREATE APPLICATION ROLE (Transact-SQL) |
| Modifiez un rôle d’application. | ALTER APPLICATION ROLE (Transact-SQL) |
| Supprimez un rôle d’application. | SUPPRIMER RÔLE D'APPLICATION (Transact-SQL) |
| Utilisation d’un rôle d’application. | sp_setapprole (Transact-SQL) |