Autorisations (moteur de base de données)

S’applique à :SQL ServerBase de données Azure SQLAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)Point de terminaison d’analyse SQL dans Microsoft FabricEntrepôt dans Microsoft FabricBase de données SQL dans Microsoft Fabric

Chaque élément sécurisable de SQL Server dispose d’autorisations associées qui peuvent être accordées à un principal. Les autorisations dans le moteur de base de données sont gérées au niveau du serveur pour les connexions et les rôles de serveur, et au niveau de la base de données pour les utilisateurs de base de données et les rôles de base de données. Le modèle pour Azure SQL Database a le même système pour les autorisations de base de données, mais les autorisations de niveau serveur ne sont pas disponibles. Cet article comporte la liste complète des autorisations. Pour obtenir une implémentation classique des autorisations, consultez Prise en main des autorisations du moteur de base de données.

Le nombre total d’autorisations pour SQL Server 2022 (16.x) est de 292. Azure SQL Database expose 292 autorisations. La plupart des autorisations s’appliquent à toutes les plateformes, mais ce n’est pas le cas pour certaines d’entre elles. Par exemple,la plupart des autorisations au niveau du serveur ne peuvent pas être accordées sur Azure SQL Database et seules quelques autorisations sont pertinentes sur Azure SQL Database. De nouvelles autorisations sont introduites progressivement avec de nouvelles versions. SQL Server 2019 (15.x) expose 248 autorisations. SQL Server 2017 (14.x) a exposé 238 autorisations. SQL Server 2016 (13.x) a exposé 230 autorisations. SQL Server 2014 (12.x) a exposé 219 autorisations. SQL Server 2012 (11.x) a exposé 214 autorisations. SQL Server 2008 R2 (10.50.x) a exposé 195 autorisations. L’article sys.fn_builtin_permissions spécifie les permissions nouvelles dans les versions récentes.

Dans la base de données SQL de Microsoft Fabric, seuls les utilisateurs et rôles au niveau de la base de données sont pris en charge. Les connexions au niveau du serveur, les rôles et le sa compte ne sont pas disponibles. Dans la base de données SQL de Microsoft Fabric, Microsoft Entra ID pour les utilisateurs de base de données est la seule méthode d’authentification prise en charge. Pour en savoir plus, consultez Autorisation dans la base de données SQL de Microsoft Fabric.

Une fois que vous avez compris les autorisations requises, vous pouvez appliquer des autorisations au niveau du serveur aux comptes de connexion ou aux rôles de serveur, et des autorisations au niveau de la base de données aux utilisateurs ou aux rôles de base de données, à l’aide des instructions GRANT, REVOKE et DENY. Par exemple :

GRANT SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;
REVOKE SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;

Pour obtenir des conseils sur la planification d’un système d’autorisations, consultez Prise en main des autorisations du 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.

• CONTRÔLE

  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 étendue particulière inclut implicitement CONTROL sur tous les éléments sécurisables inclus dans cette étendue. 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 <Élément sécurisable du serveur>, où Élément sécurisable du serveur peut être tout élément sécurisable du serveur.

  Confère la capacité de créer, de modifier ou de supprimer des instances individuelles de l’ Élément sécurisable du serveur. Par exemple, ALTER ANY LOGIN confère la possibilité de créer, modifier ou supprimer une connexion dans l’instance.

• ALTER ANY <Élément sécurisable de base de données>, où Élément sécurisable de base de données peut être tout élément 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 l’ Élément sécurisable de base de données. Par exemple, ALTER ANY SCHEMA confère la possibilité de créer, de modifier ou de supprimer un schéma dans la base de données.

• PRENDRE POSSESSION

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

• IMPERSONATE <Connexion>

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

• IMPERSONATE <Utilisateur>

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

• CREATE <Élément sécurisable du serveur>

  Confère au bénéficiaire la capacité de créer l’ Élément sécurisable du serveur.

• CREATE <Élément sécurisable de base de données>

  Confère au bénéficiaire la capacité de créer l’ Élément sécurisable de base de données.

• CREATE <Élément sécurisable contenu dans le schéma>

  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 DÉFINITION

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

• RÉFÉRENCES

  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 nécessaire sur un objet pour créer un FUNCTION ou un VIEW avec la clause WITH SCHEMABINDING référençant cet objet.

Graphique des autorisations SQL Server

L’image suivante illustre les autorisations et leurs relations. Certaines des autorisations de niveau supérieur (telles que CONTROL SERVER) figurent plusieurs fois. Dans cet article, l’affiche est trop petite pour être lue correctement. Vous pouvez télécharger le poster des autorisations de moteur de base de données en taille réelle au format PDF.

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

Le tableau suivant 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 suivant fournit la liste complète des autorisations SQL Server. Les autorisations Azure SQL Database sont uniquement disponibles pour les éléments sécurisables de base pris en charge. Les autorisations au niveau du serveur ne peuvent pas être accordées dans Azure SQL Database ; toutefois, dans certains cas, les autorisations de base de données sont disponibles à la place.

Nouvelles autorisations granulaires ajoutées à SQL Server 2022

Les autorisations suivantes sont ajoutées à SQL Server 2022 :

• 10 nouvelles autorisations ont été ajoutées pour autoriser l’accès aux métadonnées système.

• 18 nouvelles autorisations ont été ajoutées pour les événements étendus.

• 9 nouvelles autorisations ont été ajoutées en ce qui concerne les objets liés à la sécurité.

• 4 autorisations ont été ajoutées pour le registre.

• 3 autorisations de base de données supplémentaires.

Pour en savoir plus, consultez Nouvelles autorisations granulaires pour SQL Server 2022 et Azure SQL permettant d’améliorer l’adhésion à PoLP.

Accès aux autorisations de métadonnées système

Niveau du serveur :

• VIEW TOUTE DÉFINITION DE SÉCURITÉ
• VIEW TOUTE DÉFINITION DE PERFORMANCES
• VIEW ÉTAT DE SÉCURITÉ DU SERVEUR
• VIEW ÉTAT DES PERFORMANCES DU SERVEUR
• VIEW TOUTE DÉFINITION SÉCURISÉE PAR CHIFFREMENT

Niveau de la base de données :

• VIEW DATABASE ÉTAT DE SÉCURITÉ
• VIEW DATABASE ÉTAT DES PERFORMANCES
• VIEW DÉFINITION DE SÉCURITÉ
• VIEW DÉFINITION DES PERFORMANCES
• VIEW DÉFINITION SÉCURISÉE PAR CHIFFREMENT

Autorisations d’événements étendus

Niveau du serveur :

• CREATE ANY EVENT SESSION
• DÉPRÉCIER TOUT EVENT SESSION
• MODIFIER TOUT EVENT SESSION OPTION
• MODIFIER TOUT EVENT SESSION ÉVÉNEMENT D'AJOUT
• ALTER ANY EVENT SESSION DROP EVENT
• ACTIVER TOUT EVENT SESSION ACTIVER
• MODIFIER TOUT EVENT SESSION DÉSACTIVER
• MODIFIER TOUTE EVENT SESSION CIBLE D'AJOUT
• ALTER ANY EVENT SESSION DROP TARGET

Toutes ces autorisations se trouvent sous la même autorisation parente : ALTER ANY EVENT SESSION

Niveau de la base de données :

• CRÉER TOUT DATABASEEVENT SESSION
• DÉPRÉCIER TOUT DATABASEEVENT SESSION
• MODIFIER TOUT DATABASEEVENT SESSION OPTION
• MODIFIER TOUT DATABASEEVENT SESSION ÉVÉNEMENT D'AJOUT
• MODIFIER TOUT DATABASEEVENT SESSION ÉVÉNEMENT DE DÉPRÉCIATION
• ACTIVER TOUT DATABASEEVENT SESSION ACTIVER
• MODIFIER TOUT DATABASEEVENT SESSION DÉSACTIVER
• MODIFIER TOUTE DATABASEEVENT SESSION CIBLE D'AJOUT
• ALTER ANY DATABASEEVENT SESSION DROP TARGET

Toutes ces autorisations se trouvent sous la même autorisation parente : ALTER ANY DATABASEEVENT SESSION

Autorisations d’objet relatives à la sécurité

• CONTRÔLE (CREDENTIAL)
• CREATE LOGIN
• CREATE USER
• RÉFÉRENCES (CREDENTIAL)
• DÉMASQUER (OBJET)
• DÉMASQUER (SCHEMA)
• VIEW TOUT JOURNAL D'ERREUR
• VIEW AUDIT DE SÉCURITÉ DU SERVEUR
• VIEW DATABASE AUDIT DE SÉCURITÉ

Autorisations de registre

• MODIFIER LE REGISTRE
• ALTER LEDGER CONFIGURATION
• ACTIVER LE REGISTRE
• VIEW CONTENU DU GRAND LIVRE

Autres autorisations de base de données

• MODIFIER TOUTE TÂCHE EXTERNE
• MODIFIER TOUT FLUX EXTERNE
• EXÉCUTER N’IMPORTE QUEL ÉLÉMENT EXTERNE ENDPOINT

Résumé de 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 trouvé, l’algorithme recherche un GRANT qui fournit 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. Il s’agit d’autorisations liées à la connexion ou à l’utilisateur actuel, sauf si le contexte de sécurité a été modifié en une autre connexion ou un autre utilisateur à l’aide 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 en savoir plus, consultez Hiérarchie des autorisations (moteur de base de données).

• Autorisation obligatoire

  Correspond au type d’autorisation requise. Par exemple, INSERT, UPDATE, DELETE, SELECT, EXECUTE, ALTER, CONTROL, et ainsi de suite.

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

  • Une procédure stockée peut nécessiter à la fois l’autorisation EXECUTE sur la procédure stockée elle-même et l’autorisation INSERT sur plusieurs tables auxquelles la procédure stockée fait référence.

  • Une vue de gestion dynamique peut nécessiter à la fois les autorisations VIEW SERVER STATE et 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 indiquée en tant que GRANT, GRANT WITH GRANTou DENY; ou les autorisations peuvent être implicites ou couvrant l’autorisation 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 GRANT autorisation au niveau de la colonne remplace un DENY au niveau de l’objet. Pour plus d’informations, consultez DENY Autorisations d’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. La vérification des autorisations est validée si la permission requise n’a pas été refusée et que la permission requise contient une permission GRANT ou une permission GRANT AVEC GRANT, directement ou implicitement, pour l’une quelconque des identités du contexte de sécurité pour tout objet de l’espace d’autorisation.

Considérations spéciales relatives aux autorisations au niveau des colonnes

Les autorisations au niveau des colonnes sont accordées avec la syntaxe <table_name>(<column _name>). Par exemple :

GRANT SELECT ON OBJECT::Customer(CustomerName) TO UserJoe;

Un DENY sur la table est remplacé par un GRANT sur une colonne. Toutefois, si vous appliquez ensuite DENY à la table, la colonne GRANT sera supprimée.

Exemples

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

A. Renvoyer la liste complète des autorisations accordables

L’instruction suivante renvoie toutes les autorisations de moteur de base de données à l’aide de la fonction fn_builtin_permissions. Pour plus d’informations, consultez sys.fn_builtin_permissions.

SELECT * FROM fn_builtin_permissions(default);
GO

B. Renvoyer les 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

Chapitre C. Renvoyer les 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.

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

D. Renvoyer les autorisations applicables à un objet spécifié

L'exemple suivant retourne les autorisations applicables à un objet nommé Yttrium. La fonction intégrée OBJECT_ID permet de récupérer l’ID de l’objet Yttrium.

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

Contenu associé

• Hiérarchie des autorisations (moteur de base de données)
• sys.database_permissions (Transact-SQL)