Partager via

Rôles d’application

  • Article

S’applique à : SQL Server Azure SQL Database Azure 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é. Toute base de données où invité a été désactivé est donc 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 de trace 4616 global en utilisant -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.

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. À 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 procédure stockée sp_unsetapprole 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 les versions ultérieures, le paramètre password est stocké sous la forme d’un hachage unidirectionnel.

Tâche 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