Autorisations (moteur de base de données)

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'objet sécurisable. Un principal qui dispose de l'autorisation CONTROL peut aussi accorder des autorisations sur l'objet 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 objets 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 objet 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 objets 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 désigne n'importe quel objet sécurisable de type 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 désigne n'importe quel objet sécurisable au niveau de la base de données.

  Confère la capacité de créer, de modifier ou de supprimer 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'objet 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 l'objet sécurisable de type serveur ou Server Securable.

• CREATE <Database Securable>

  Confère au bénéficiaire la capacité de créer l'objet sécurisable de type serveur ou Database Securable.

• CREATE <Schema-contained Securable>

  Confère la capacité de créer l'objet sécurisable contenu dans le schéma. Toutefois, l'autorisation ALTER sur le schéma est requise pour créer l'objet 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 sous forme d'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 objets sécurisables spécifiques

Le tableau ci-dessous répertorie les principales classes d'autorisations et les types d'objets 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.

• 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

Exemples

Les exemples suivants montrent comment récupérer des informations relatives aux autorisations.

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

SELECT * FROM fn_builtin_permissions(default);
GO

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

SELECT * FROM fn_builtin_permissions('assembly');
GO  

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

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

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

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

Voir aussi

Référence

Concepts