Autorisations (moteur de base de données)

Chaque élément sécurisable SQL Server a des autorisations associées qui peuvent être accordées à un principal. Cette rubrique fournit les informations suivantes :

• Conventions de noms d'autorisations

• Autorisations relatives à des éléments sécurisables spécifiques

• Autorisations SQL Server

• Algorithme de vérification des autorisations

• Exemples

Conventions de noms d'autorisations

La section ci-après décrit les conventions générales qui sont suivies pour affecter des noms aux autorisations.

• CONTROL

  Confère des fonctionnalités de type propriété au bénéficiaire de l'autorisation. Le bénéficiaire dispose effectivement de toutes les autorisations définies sur l'élément sécurisable. Un principal qui dispose de l'autorisation CONTROL peut aussi accorder des autorisations sur l'élément sécurisable. Le modèle de sécurité de SQL Server étant hiérarchique, l'autorisation CONTROL sur une portée particulière étend implicitement CONTROL à tous les éléments sécurisables inclus dans cette portée. Par exemple, CONTROL sur une base de données implique toutes les autorisations sur la base de données, toutes les autorisations sur tous les assemblys de la base de données, toutes les autorisations sur tous les schémas de la base de données et toutes les autorisations sur les objets de tous les schémas de la base de données.

• ALTER

  Confère la capacité de modifier les propriétés, excepté l'appartenance, d'un élément sécurisable particulier. Lorsque ALTER est accordé sur une portée, ALTER octroie également la capacité de modifier, de créer ou de supprimer tous les éléments sécurisables contenus dans cette portée. Par exemple, l'autorisation ALTER sur un schéma inclut la capacité de créer, de modifier et de supprimer les objets du schéma.

• ALTER ANY <Server Securable>, où Server Securable peut être n'importe quel élément sécurisable du serveur.

  Confère la capacité de créer, de modifier ou de supprimer des instances individuelles de Server Securable. Par exemple, ALTER ANY LOGIN confère la capacité de créer, de modifier ou de supprimer n'importe quelle connexion dans l'instance.

• ALTER ANY <Database Securable>, où Database Securable peut être n'importe quel élément sécurisable au niveau de la base de données.

  Confère la capacité de créer, de modifier ou de supprimer (à l'aide des instructions CREATE, ALTER ou DROP) des instances individuelles de Database Securable. Par exemple, ALTER ANY SCHEMA confère la capacité de créer, de modifier ou de supprimer n'importe quel schéma dans la base de données.

• TAKE OWNERSHIP

  Permet au bénéficiaire d'obtenir la propriété de l'élément sécurisable sur lequel cette autorisation est accordée.

• IMPERSONATE <Login>

  Permet au bénéficiaire d'emprunter l'identité impliquée dans la connexion.

• IMPERSONATE <User>

  Permet au bénéficiaire d'emprunter l'identité de l'utilisateur.

• CREATE <Server Securable>

  Confère au bénéficiaire la capacité de créer Server Securable.

• CREATE <Database Securable>

  Confère au bénéficiaire la capacité de créer Database Securable.

• CREATE <Schema-contained Securable>

  Confère la capacité de créer l'élément sécurisable contenu dans le schéma. Toutefois, l'autorisation ALTER sur le schéma est requise pour créer l'élément sécurisable dans un schéma particulier.

• VIEW DEFINITION

  Permet au bénéficiaire d'accéder aux métadonnées.

• REFERENCES

  L'autorisation REFERENCES sur une table est obligatoire pour pouvoir créer une contrainte FOREIGN KEY qui référence cette table.

  L'autorisation REFERENCES est obligatoire sur un objet pour pouvoir créer une FONCTION ou une VUE avec la clause WITH SCHEMABINDING qui référence cet objet.

Graphique des autorisations SQL Server

Pour obtenir un graphique de la taille d'une affiche de toutes les autorisations du Moteur de base de données au format PDF, consultez https://go.microsoft.com/fwlink/?LinkId=229142.

Autorisations applicables à des éléments sécurisables spécifiques

Le tableau ci-dessous répertorie les principales classes d'autorisations et les types d'éléments sécurisables auxquels elles peuvent s'appliquer.

Autorisations SQL Server

Le tableau ci-dessous fournit la liste complète des autorisations SQL Server.

Synthèse sur l'algorithme de vérification des autorisations

La vérification des autorisations peut être complexe. L'algorithme de vérification des autorisations englobe les membres de groupes qui se chevauchent et le chaînage des propriétés, l'autorisation explicite et implicite, et peut être affecté par les autorisations sur les classes sécurisables qui contiennent l'entité sécurisable. Le processus général de l'algorithme consiste à collecter toutes les autorisations pertinentes. Si aucun blocage DENY n'est rencontré, l'algorithme recherche une instruction GRANT fournissant un accès suffisant. L'algorithme contient trois éléments essentiels : le contexte de sécurité, l'espace d'autorisation et l'autorisation requise.

[!REMARQUE]

Vous ne pouvez pas accorder, refuser ou révoquer des autorisations à sa, dbo, le propriétaire de l'entité (entity owner), information_schema, sys ou à vous-même.

• Contexte de sécurité

  Il s'agit du groupe de principaux qui apporte les autorisations à la vérification d'accès. Ces autorisations sont liées à la connexion ou à l'utilisateur actif, à moins que le contexte de sécurité n'ait été modifié au profit d'une autre connexion ou d'un autre utilisateur par le biais de l'instruction EXECUTE AS. Le contexte de sécurité se compose des principaux suivants :

  • la connexion ;

  • l'utilisateur ;

  • les appartenances aux rôles ;

  • les appartenances aux groupes Windows ;

  • si la signature de module est utilisée, toute connexion ou compte d'utilisateur du certificat utilisé pour signer le module actuellement exécuté par l'utilisateur, ainsi que les appartenances aux rôles associées de ce principal.

• Espace d'autorisation

  Correspond à l'entité sécurisable et aux classes sécurisables qui contiennent l'élément sécurisable. Par exemple, une table (entité sécurisable) est contenue par la classe sécurisable de schéma et par la classe sécurisable de base de données. L'accès peut être affecté par des autorisations de niveau table, schéma, base de données et serveur. Pour plus d'informations, consultez Hiérarchie des autorisations (moteur de base de données).

• Autorisation requise

  Correspond au type d'autorisation requise. Il peut s'agir, par exemple, d'une autorisation INSERT, UPDATE, DELETE, SELECT, EXECUTE, ALTER, CONTROL, etc.

  L'accès peut nécessiter plusieurs autorisations, comme l'illustrent les exemples suivants :

  • Une procédure stockée peut nécessiter une autorisation EXECUTE sur la procédure stockée et une autorisation INSERT sur plusieurs tables référencées par la procédure stockée.

  • Une vue de gestion dynamique peut nécessiter à la fois une autorisation VIEW SERVER STATE et une autorisation SELECT sur la vue.

Étapes générales de l'algorithme

Au moment de déterminer si l'accès à un élément sécurisable doit être autorisé, l'algorithme peut suivre différentes étapes en fonction des principaux et des éléments sécurisables concernés. Cependant, l'algorithme exécute les étapes générales suivantes :

1. Contournement de la procédure de vérification des autorisations si la connexion est membre du rôle serveur fixe sysadmin ou si l'utilisateur est l'utilisateur dbo dans la base de données active.

2. Autorisation de l'accès si le chaînage des propriétés est applicable et si la vérification de l'accès sur l'objet plus tôt dans la chaîne a passé avec succès le contrôle de sécurité.

3. Agrégation des identités de niveau serveur, base de données et du module signé qui sont associées à l'appelant pour créer le contexte de sécurité.

4. Pour ce contexte de sécurité, collecte de toutes les autorisations accordées ou refusées pour l'espace d'autorisation. L'autorisation peut être explicitement déclarée comme une autorisation GRANT, GRANT WITH GRANT ou DENY ; les autorisations peuvent également correspondre à une autorisation implicite ou couvrante GRANT ou DENY. Par exemple, l'autorisation CONTROL sur un schéma implique une autorisation CONTROL sur une table. Et une autorisation CONTROL sur une table implique une autorisation SELECT. Par conséquent, si l'autorisation CONTROL a été accordée sur le schéma, l'autorisation SELECT l'est également sur la table. Si l'autorisation CONTROL a été refusée sur la table, l'autorisation SELECT l'est tout autant sur la table.

   [!REMARQUE]

   Une instruction GRANT associée à une autorisation au niveau colonne se substitue à une instruction DENY au niveau objet.

5. Identification de l'autorisation requise.

6. Échec de la vérification des autorisations si l'autorisation requise est directement ou implicitement refusée à l'une des identités dans le contexte de sécurité pour les objets contenus dans l'espace d'autorisation.

7. Succès de la vérification des autorisations si l'autorisation requise n'a pas été refusée et si l'autorisation requise contient une autorisation GRANT ou GRANT WITH GRANT directement ou implicitement accordée à l'une des identités dans le contexte de sécurité pour un objet contenu dans l'espace d'autorisation.

Exemples

Les exemples de cette section montrent comment récupérer des informations relatives aux autorisations.

A.Retour de la liste complète des autorisations accordables

L'instruction suivante retourne toutes les autorisations du moteur de base de données à l'aide de la fonction fn_builtin_permissions . Pour plus d'informations, consultez sys.fn_builtin_permissions (Transact-SQL).

SELECT * FROM fn_builtin_permissions(default);
GO

B.Retour des autorisations sur une classe d'objets particulière

L'exemple suivant utilise la fonction fn_builtin_permissions pour consulter toutes les autorisations disponibles pour une catégorie d'élément sécurisable donnée. L'exemple retourne les autorisations sur les assemblys.

SELECT * FROM fn_builtin_permissions('assembly');
GO  

C.Retour des autorisations accordées au principal en cours d'exécution sur un objet

L'exemple suivant utilise la fonction fn_my_permissions pour retourner la liste des autorisations effectives détenues par le principal appelant sur un élément sécurisable spécifié. L'exemple retourne les autorisations sur un objet nommé Orders55. Pour plus d'informations, consultez sys.fn_my_permissions (Transact-SQL).

SELECT * FROM fn_my_permissions('Orders55', 'object');
GO

D.Retour des autorisations applicables à un objet spécifié

L'exemple suivant retourne les autorisations applicables à un objet nommé Yttrium. Notez que la fonction intégrée OBJECT_ID est utilisée pour récupérer l'identificateur de l'objet Yttrium.

SELECT * FROM sys.database_permissions 
    WHERE major_id = OBJECT_ID('Yttrium');
GO

Voir aussi

Référence

sys.database_permissions (Transact-SQL)

Concepts

Hiérarchie des autorisations (moteur de base de données)