Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Comprendre la fonction de sécurité SQL Server HAS_Permis_BY_Name et ses cas d'utilisation

Il existe plusieurs cas où nous voulons vérifier l'autorisation sur un élément sécurisable pour un principal. Avant de continuer, voyons ce que sont le principal, les éléments sécurisables et les autorisations.

Selon la documentation Microsoft,

  1. Sécurisables dans le contexte SQL Server sont des ressources spécifiques auxquelles le système d'autorisation du moteur de base de données SQL Server contrôle l'accès. Ils sont divisés en trois catégories :Serveur, Base de données et Schéma. En général, tous les objets SQL Server ou de base de données peuvent être sécurisables.
  2. Autorisations sont des contrôles à l'aide desquels nous accordons ou refusons un certain niveau d'accès à un élément sécurisable.
  3. Directeur est une entité qui reçoit l'autorisation d'accéder à un élément sécurisable. Les principaux les plus courants sont les connexions et les utilisateurs de la base de données.

SQL Server a une fonction de sécurité intégrée HAS_Permis_BY_Name cela nous aidera à savoir si un principal identifié a ou non une autorisation spécifique sur un élément sécurisable donné. Cette fonction système renvoie 1 si l'autorisation effective est attribuée à ce principal sur un élément sécurisable donné, et elle renvoie 0 si l'autorisation effective n'est pas attribuée. Vous obtiendrez la valeur NULL si l'autorisation effective ou la classe sécurisable n'est pas valide.

La fonction système HAS_Permis_BY_Name est également très utile pour vérifier l'autorisation de votre connexion. Je vais vous montrer un processus étape par étape pour vérifier une autorisation spécifique sur un élément sécurisable pour mon principal et d'autres principaux dans cet article.

La syntaxe T-SQL de cette fonction système est la suivante :

--T-SQL syntax
HAS_PERMS_BY_NAME (securable, securable_class, permission)

Trois paramètres obligatoires seront nécessaires pour exécuter cette fonction de sécurité du système SQL Server.

  • Entrez le nom du sécurisable dont vous voulez vérifier l'autorisation. Si un élément sécurisable est lui-même un serveur, vous devez utiliser NULL.
  • Le deuxième paramètre est securable_class qui est le nom de la classe. Si vous n'êtes pas sûr, vous pouvez utiliser une autre fonction système sys.fn_builtin_permissions pour obtenir la liste complète des classes sécurisables et leurs autorisations disponibles.
  • Le troisième paramètre est la autorisation où vous devez saisir l'autorisation effective que vous souhaitez vérifier sur l'élément sécurisable spécifié.

Maintenant, laissez-moi vous montrer toutes les classes sécurisables disponibles en exécutant la fonction système sys.fn_builtin_permissions. J'ai utilisé DISTINCT pour afficher les lignes par classe sécurisable.

--Display all securable_class
SELECT distinct class_desc FROM sys.fn_builtin_permissions(default)

Ici, vous pouvez obtenir une liste de la classe sécurisable.

Si vous souhaitez vérifier toutes les autorisations possibles pour une classe sécurisable, vous pouvez également utiliser cette fonction système. Exécutez l'instruction T-SQL ci-dessous :

--Display each permission for all securable class
SELECT class_desc,permission_name FROM sys.fn_builtin_permissions(default);

Nous pouvons voir la liste dans l'image ci-dessous. Le class_desc est une classe sécurisable et permission_name est un type d'autorisation. Si vous n'êtes pas sûr de la classe sécurisable et des autorisations à vérifier pour tout sécurisable, vous pouvez utiliser cette fonction système.

HAS_Permis_BY_Name Cas d'UTILISATION

Je vais vous montrer 5 cas d'utilisation de vérification de diverses autorisations pour ma propre connexion à l'instance SQL Server et pour une connexion supplémentaire nommée manvendra .

  1. Vérifier les autorisations au niveau du serveur ou de l'instance
  2. Vérifier les autorisations au niveau de la base de données
  3. Vérifier les autorisations au niveau de l'objet
  4. Vérifier les autorisations de connexion
  5. Vérifiez les autres autorisations telles que le catalogue de texte intégral, le schéma, etc.

Commençons par le premier cas d'utilisation pour vérifier les autorisations au niveau de l'instance.

CAS D'UTILISATION 1 :Vérifier l'autorisation au niveau de SQL Server ou de l'instance

Ce cas d'utilisation montrera comment vérifier diverses autorisations pour un principal de serveur\login. Vous pouvez exécuter l'instruction T-SQL ci-dessus à l'aide de la fonction système sys.fn_builtin_permissions. Vous pouvez utiliser la clause WHERE dans cette fonction pour répertorier uniquement les autorisations au niveau du serveur. Ici, je vais vous montrer les autorisations pour ma propre connexion connectée.

  • Afficher l'état du serveur
  • Créer un rôle de serveur
  • Connectez n'importe quelle base de données

Si vous recherchez une autorisation au niveau du serveur, vous devez toujours passer NULL comme argument sécurisable. Dans cet exemple, NULL sera sécurisable en tant que niveau de serveur et les noms d'autorisation ci-dessus auront un argument d'autorisation. Exécutez l'instruction T-SQL ci-dessous pour vérifier les autorisations au niveau du serveur.

--Display server level permission for your own login using which you have established the database connection
SELECT HAS_PERMS_BY_NAME(null, null, 'VIEW SERVER STATE') AS [VIEW SERVER STATE],
	HAS_PERMS_BY_NAME(null, null, 'CREATE SERVER ROLE') AS [CREATE SERVER ROLE],
	HAS_PERMS_BY_NAME(null, null, 'CONNECT ANY DATABASE') AS [CONNECT ANY DATABASE]

La sortie est illustrée dans l'image ci-dessous. T-SQL a renvoyé 1 pour toutes les autorisations pour ma connexion. Cela signifie que j'ai des autorisations pour les trois opérations. Je peux voir l'état du serveur, je peux créer un rôle de serveur et je peux également me connecter à n'importe quelle base de données sur ce serveur ou cette instance.

Laissez-moi vous montrer si une connexion nommée "manvendra" a des autorisations pour les 3 opérations ci-dessus. Nous utiliserons l'instruction EXECUTE AS LOGIN T-SQL pour vérifier le niveau d'accès. Assurez-vous que vous disposez de l'autorisation IMPERSONATE sur la connexion pour laquelle vous vérifiez les autorisations. Exécutez la même instruction T-SQL que ci-dessus après l'instruction EXECUTE AS LOGIN.

--Display server level permission for another login ‘manvendra’
EXECUTE AS LOGIN = ‘manvendra’
GO
SELECT HAS_PERMS_BY_NAME(null, null, 'VIEW SERVER STATE') AS [VIEW SERVER STATE],
	HAS_PERMS_BY_NAME(null, null, 'CREATE SERVER ROLE') AS [CREATE SERVER ROLE],
	HAS_PERMS_BY_NAME(null, null, 'CONNECT ANY DATABASE') AS [CONNECT ANY DATABASE]

Ici, nous pouvons voir que la connexion 'manvendra' n'a accès à aucune de ces 3 activités au niveau du serveur car leur sortie a renvoyé 0.

CAS D'UTILISATION 2 :Vérifier les autorisations au niveau de la base de données

J'ai expliqué comment vérifier diverses autorisations pour tout principal au niveau du serveur ou de l'instance dans la section ci-dessus. Maintenant, je vais vous montrer comment vérifier diverses autorisations pour n'importe quel principal au niveau de la base de données. Voir la déclaration ci-dessous :

--Display each permission for securable class ‘DATABASE’
SELECT class_desc,permission_name FROM sys.fn_builtin_permissions(default)
WHERE class_desc = ‘DATABASE’

Vous pouvez voir qu'il y a 82 autorisations disponibles au niveau de la base de données dans la capture d'écran ci-dessous.

J'ai choisi les autorisations ci-dessous pour vérifier si mon identifiant ou un identifiant supplémentaire "manvendra" est autorisé à effectuer ces activités.

  • TOUT
  • CRÉER un tableau
  • CRÉER UNE PROCÉDURE
  • INSÉRER
  • SÉLECTIONNER

Ici, sécurisable sera le nom de la base de données sur laquelle vous souhaitez vérifier les autorisations, la classe sécurisable sera "Base de données" et l'autorisation sera les noms d'autorisation ci-dessus. Exécutez l'instruction T-SQL ci-dessous pour vérifier diverses autorisations.

--Display few specific permissions for your own connected login on a DATABASE
SELECT HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'ANY') AS [DB Access],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'CREATE TABLE') AS [CREATE TABLE],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'CREATE PROCEDURE') AS [CREATE PROCEDURE],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'INSERT') AS [INSERT Access],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'SELECT') AS [SELECT Access]

La sortie a renvoyé 1 pour chaque autorisation. Cela signifie que j'ai la permission d'effectuer toutes les activités ci-dessus dans le contexte actuel de la base de données.

Exécutez l'instruction T-SQL ci-dessous pour vérifier les mêmes autorisations pour la connexion "manvendra" dans le contexte de base de données actuellement sélectionné.

--Display few specific permissions for login ‘manvendra’ on current database
EXECUTE AS LOGIN ='manvendra'
GO
SELECT HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'ANY') AS [DB Access],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'CREATE TABLE') AS [CREATE TABLE],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'CREATE PROCEDURE') AS [CREATE PROCEDURE],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'INSERT') AS [INSERT Access],
HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'SELECT') AS [SELECT Access]

La sortie montre que la connexion 'manvendra' a des autorisations très limitées sur cette base de données. Cette connexion ne peut se connecter qu'à la base de données et les autres autorisations ne sont pas autorisées.

Ici, j'ai changé le contexte de la base de données et choisi la base de données "AdventureWorksDW2019-TSQL" comme argument sécurisable et exécuté l'instruction ci-dessous pour la connexion "manvendra".

--Display few specific permissions for login ‘manvendra’ on database ‘AdventureWorksDW2019-TSQL’
EXECUTE AS LOGIN ='manvendra'
GO
SELECT HAS_PERMS_BY_NAME('AdventureWorksDW2019-TSQL', 'DATABASE', 'ANY') AS [DB Access],
HAS_PERMS_BY_NAME('AdventureWorksDW2019-TSQL', 'DATABASE', 'CREATE TABLE') AS [CREATE TABLE],
HAS_PERMS_BY_NAME('AdventureWorksDW2019-TSQL', 'DATABASE', 'CREATE PROCEDURE') AS [CREATE PROCEDURE],
HAS_PERMS_BY_NAME('AdventureWorksDW2019-TSQL', 'DATABASE', 'INSERT') AS [INSERT Access],
HAS_PERMS_BY_NAME('AdventureWorksDW2019-TSQL', 'DATABASE', 'SELECT') AS [SELECT Access]

Le même identifiant "manvendra" est autorisé à effectuer des opérations INSERT et SELECT sur cette base de données "AdventureWorks2019-TSQL"

De même, nous pouvons exécuter l'instruction T-SQL ci-dessus pour vérifier l'autorisation de bases de données distinctes pour notre connexion. La sortie montre que j'ai accès à toutes les autorisations.

Vous pouvez continuer et vérifier d'autres autorisations au niveau de la base de données pour n'importe quel principal en utilisant la fonction de sécurité système SQL Server ci-dessus.

CAS D'UTILISATION 3 :Vérifier les autorisations au niveau de l'objet

Ce cas d'utilisation illustre l'utilisation des autorisations au niveau de l'objet dans une base de données. Encore une fois, vous pouvez exécuter l'instruction T-SQL ci-dessous pour répertorier toutes les autorisations disponibles pour la classe sécurisable 'OBJECT'. J'ai utilisé la clause WHERE dans la fonction système sys.fn_builtin_permissions pour afficher la liste des autorisations au niveau de l'objet.

--Check all object level permissions
SELECT class_desc,permission_name FROM sys.fn_builtin_permissions(default)
WHERE class_desc ='OBJECT'

Voici la liste des permissions pour la classe sécurisable Object.

Maintenant, je vais vérifier les autorisations ci-dessous sur un objet spécifique pour n'importe quel compte de connexion et voir si ce compte a accès pour effectuer les opérations ci-dessous.

  • INSÉRER
  • SÉLECTIONNER
  • SUPPRIMER
  • AFFICHER LA DÉFINITION

J'ai utilisé un objet de base de données 'dbo.dimAccount' comme sécurisable, OBJECT comme classe sécurisable et les autorisations ci-dessus comme argument d'autorisation. Exécutez les instructions ci-dessous pour afficher les détails de l'autorisation.

--Check some specific object level permissions for your own login
SELECT HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'INSERT') AS [Insert Permission],
HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'SELECT') AS [Select Permission],
HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'DELETE') AS [DELETE Permission],
HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'VIEW DEFINITION') AS [VIEW DEFINITION Access]

Comme je suis un administrateur système sur cette instance, mon compte renvoie 1 pour toute autorisation que je vérifie à n'importe quel niveau. Cela signifie que j'ai toutes les autorisations, et cela peut être vérifié en exécutant également les instructions ci-dessous.

Exécutez l'instruction ci-dessous pour vérifier les autorisations pour la connexion "manvendra".

--Check some specific object level permissions for another login ‘manvendra’
EXECUTE AS USER ='manvendra'
GO
USE [AdventureWorksDW2019-TSQL]
GO
SELECT HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'INSERT') AS [Insert Permission],
HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'SELECT') AS [Select Permission],
HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'DELETE') AS [DELETE Permission],
HAS_PERMS_BY_NAME('[dbo].[DimAccount]', 'OBJECT', 'VIEW DEFINITION') AS [VIEW DEFINITION Access]

Nous pouvons voir que la connexion "manvendra" a accès aux autorisations INSERT, SELECT et DELETE, mais ce compte n'a pas l'autorisation de VOIR LA DÉFINITION de cet objet dans la base de données "AdventureWorksDW2019-TSQL".

Permettez-moi d'appliquer l'accès DENY à l'opération DELETE pour ce compte 'manvendra' sur l'objet 'DimAccount' dans la base de données AdventureWorksDW2019-TSQL. Vous pouvez le voir dans l'image ci-dessous.

Nous pouvons voir que la sortie indique que la connexion 'manvendra' n'a accès qu'aux instructions INSERT et SELECT et n'a pas l'autorisation d'accéder à l'instruction DELETE.

Vérifiez différents niveaux d'accès pour toute connexion sur n'importe quel objet de base de données en utilisant la fonction système ci-dessus.

CAS D'UTILISATION 4 :Vérifier l'autorisation de connexion

Ce cas d'utilisation vous aidera à comprendre comment vérifier diverses autorisations pour les connexions. Vous pouvez obtenir tous ces types de détails en utilisant cette fonction de sécurité système SQL Server HAS_PERMS_BY_NAME.

Nous pouvons répertorier toutes les autorisations disponibles pour une connexion spécifique en exécutant l'instruction T-SQL ci-dessous.

--List all available permission for securable class ‘LOGIN’
SELECT class_desc, permission_name FROM sys.fn_builtin_permissions(default)
WHERE class_desc ='LOGIN'

Vous trouverez ci-dessous la liste des noms d'autorisation pour la classe sécurisable "LOGIN".

Je vais vérifier si j'ai l'autorisation ALTER ou VIEW DEFINITION lors de la connexion sa en exécutant les instructions T-SQL ci-dessous. J'ai utilisé login sa comme argument sécurisable, LOGIN comme argument de classe sécurisable et ALTER &VIEW DEFINITION comme argument d'autorisation dans cette fonction système.

--Check ALTER & VIEW DEFINITION permission on securable sa
SELECT HAS_PERMS_BY_NAME('sa', 'LOGIN', 'ALTER'),
HAS_PERMS_BY_NAME('sa', 'LOGIN', 'VIEW DEFINITION')

En tant qu'administrateur système, j'aurai ces niveaux d'accès, et la sortie est également validée en renvoyant leur valeur à 1.

Vérifions si le login 'manvendra' est autorisé à ALTER ou VIEW définition du login sa.

--Check ALTER & VIEW DEFINITION permission on securable sa for principal ‘manvendra’
EXECUTE AS USER ='manvendra'
GO

SELECT HAS_PERMS_BY_NAME('sa', 'LOGIN', 'ALTER'),
HAS_PERMS_BY_NAME('sa', 'LOGIN', 'VIEW DEFINITION')

La sortie renvoyée est zéro (0), ce qui signifie que la connexion "manvendra" n'a pas l'autorisation de ALTER ou VIEW DEFINITION login sa.

Utilisez cette fonction système pour vérifier et comprendre les niveaux d'accès pour différentes connexions.

CAS D'UTILISATION 5 :vérifier les autres autorisations

Ici, je couvrirai d'autres classes sécurisables comme SCHEMA et FULLTEXT CATALOG, ENDPOINT, AVAILABILITY GROUP, etc.

Commençons par répertorier toutes les autorisations disponibles pour les classes sécurisables SCHEMA et FULLTEXT CATALOG en exécutant l'instruction ci-dessous :

--List all available permission for securable class ‘SCHEMA’ & ‘FTCatalog’. FTCatalog is full text catalog.
SELECT class_desc, permission_name FROM sys.fn_builtin_permissions(default)
WHERE class_desc='SCHEMA' OR
class_desc= 'FULLTEXT CATALOG'

L'étape suivante consiste à identifier l'autorisation que nous recherchons pour vérifier notre principal. Je vais vérifier les autorisations DELETE et ALTER pour la classe sécurisable SCHEMA et les autorisations ALTER et VIEW DEFINITION sur la classe sécurisable FULLTEXT CATALOG.

Nous devons transmettre leurs sécurisables respectifs comme j'ai passé dbo pour la classe sécurisable SCHEMA et FTCatalog pour la classe sécurisable FULLTEXT CATALOG dans l'instruction ci-dessous.

Exécutez l'instruction T-SQL ci-dessous pour obtenir l'autorisation de vous connecter.

--List below permissions for securable class ‘SCHEMA’ & ‘FTCatalog’. 
SELECT HAS_PERMS_BY_NAME('dbo', 'SCHEMA', 'DELETE') AS [Schema Deletion Access],
HAS_PERMS_BY_NAME('dbo', 'SCHEMA', 'ALTER') AS [Schema Alter Access],
HAS_PERMS_BY_NAME('[FTCatalog]', 'FULLTEXT CATALOG', 'ALTER') AS [FTC Alter Access],
HAS_PERMS_BY_NAME('[FTCatalog]', 'FULLTEXT CATALOG', 'VIEW DEFINITION') AS [VIEW DEFINITION]

La sortie ci-dessous montre que la connexion 'manvendra' n'a accès qu'à la suppression de SCHEMA et que les autres accès ont été refusés ou révoqués.

Conclusion

J'ai expliqué le processus étape par étape pour vérifier diverses autorisations pour plusieurs classes sécurisables pour n'importe quel principal dans cet article. Vous pouvez également utiliser cette fonction de sécurité du système SQL Server pour répondre à vos exigences de vérification des autorisations. Veuillez partager cet article et donner votre avis dans la section des commentaires afin que nous puissions nous améliorer.