Rôles d’application

S’applique à :SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

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 sont activés grâce à sp_setapprolequi 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 par le biais des autorisations accordées dans ces bases de données à invité. 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 de trace global 4616 à l’aide de -T4616 ou DBCC TRACEON (4616, -1). Si vous préférez ne pas activer cet indicateur de trace, vous pouvez utiliser une procédure stockée signée par certificat pour autoriser les rôles d’application à afficher l’état du serveur. Pour obtenir un exemple de code, consultez cet exemple de script sur GitHub.

Se connecter 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 en tant qu’utilisateur.

  3. L’application exécute ensuite la sp_setapprole procédure stockée avec un mot de passe connu uniquement 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 assume 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 (9.x), sp_setapprole dispose d’une option qui crée un cookie. Le cookie contient des informations de contexte avant que le rôle d'application soit activé. La sp_unsetapprole procédure stockée utilise ensuite le cookie 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) et sp_unsetapprole (Transaction-SQL).

Important

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 TLS (Transport Layer Security), anciennement 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 (9.x) et versions ultérieures, le mot de passe du paramètre est stocké en tant que hachage unidirectionnel.

Task Type
Créer un rôle d'application. Créer un rôle d’application et CREATE APPLICATION ROLE (Transact-SQL)
Modifier un rôle d'application. ALTER APPLICATION ROLE (Transact-SQL)
Supprimer un rôle d'application. DROP APPLICATION ROLE (Transact-SQL)
Utilisation d'un rôle d'application. sp_setapprole (Transact-SQL)

Voir aussi

Sécurisation de SQL Server