Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

Verständnis der SQL Server-Sicherheitsfunktion HAS_Permis_BY_Name und ihrer Anwendungsfälle

Es gibt mehrere Fälle, in denen wir die Berechtigung für ein sicherungsfähiges Element für einen Prinzipal überprüfen möchten. Bevor wir fortfahren, sehen wir uns an, was Prinzipal, sicherungsfähige Elemente und Berechtigungen sind.

Laut Microsoft-Dokumentation

  1. Sicherheiten im SQL Server-Kontext sind bestimmte Ressourcen, auf die das Autorisierungssystem der SQL Server-Datenbank-Engine den Zugriff steuert. Sie sind in drei Kategorien unterteilt:Server, Datenbank und Schema. Im Allgemeinen können alle SQL Server- oder Datenbankobjekte sicherungsfähig sein.
  2. Berechtigungen sind Steuerelemente, mit denen wir einem Sicherungsobjekt eine bestimmte Zugriffsebene gewähren oder verweigern.
  3. Geschäftsführer ist eine Entität, die die Berechtigung für ein Sicherungsobjekt erhält. Die häufigsten Prinzipale sind Logins und Datenbankbenutzer.

SQL Server hat eine eingebaute Sicherheitsfunktion HAS_Permis_BY_Name das hilft uns herauszufinden, ob ein identifizierter Prinzipal eine bestimmte Berechtigung für ein bestimmtes sicherungsfähiges Objekt hat oder nicht. Diese Systemfunktion gibt 1 zurück, wenn diesem Prinzipal eine gültige Berechtigung für ein bestimmtes sicherungsfähiges Element zugewiesen ist, und sie gibt 0 zurück, wenn keine gültige Berechtigung zugewiesen ist. Sie erhalten den NULL-Wert, wenn die effektive Berechtigung oder die sicherungsfähige Klasse nicht gültig ist.

Die Systemfunktion HAS_Permis_BY_Name ist auch sehr nützlich, um die Berechtigung für Ihr Login zu überprüfen. In diesem Artikel zeige ich Ihnen Schritt für Schritt, wie Sie bestimmte Berechtigungen für ein sicherungsfähiges Element für meinen Prinzipal und andere Prinzipale überprüfen können.

Die T-SQL-Syntax dieser Systemfunktion lautet wie folgt:

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

Drei obligatorische Parameter werden benötigt, um diese System-SQL-Server-Sicherheitsfunktion auszuführen.

  • Geben Sie den Namen der sicherungsfähigen ein für die Sie die Berechtigung überprüfen möchten. Wenn ein sicherungsfähiges Element selbst ein Server ist, sollten Sie NULL verwenden.
  • Zweiter Parameter ist securable_class das ist der Name der Klasse. Wenn Sie sich nicht sicher sind, können Sie eine andere Systemfunktion sys.fn_builtin_permissions verwenden, um die vollständige Liste der sicherungsfähigen Klassen und ihrer verfügbaren Berechtigungen abzurufen.
  • Dritter Parameter ist die Berechtigung wo Sie die gültige Berechtigung eingeben müssen, die Sie für das angegebene sicherungsfähige Element überprüfen möchten.

Lassen Sie mich Ihnen nun alle verfügbaren sicherungsfähigen Klassen zeigen, indem ich die Systemfunktion sys.fn_builtin_permissions ausführe. Ich habe DISTINCT verwendet, um Zeilen pro sicherungsfähiger Klasse anzuzeigen.

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

Hier erhalten Sie eine Liste der sicherungsfähigen Klasse.

Wenn Sie alle möglichen Berechtigungen für eine beliebige sicherungsfähige Klasse prüfen möchten, können Sie auch diese Systemfunktion verwenden. Führen Sie die folgende T-SQL-Anweisung aus:

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

Wir können die Liste im folgenden Bild sehen. Die class_desc ist eine sicherungsfähige Klasse und permission_name ist eine Art Erlaubnis. Wenn Sie sich bezüglich der sicherungsfähigen Klasse und der Berechtigungen, die für sicherungsfähige Elemente geprüft werden sollen, nicht sicher sind, können Sie diese Systemfunktion verwenden.

HAS_Permis_BY_Name USE Cases

Ich zeige Ihnen 5 Anwendungsfälle zum Überprüfen verschiedener Berechtigungen für meine eigene Anmeldung bei der SQL Server-Instanz und für eine zusätzliche Anmeldung namens manvendra .

  1. Überprüfen Sie die Berechtigungen auf Server- oder Instanzebene
  2. Berechtigungen auf Datenbankebene prüfen
  3. Berechtigungen auf Objektebene prüfen
  4. Überprüfen Sie die Anmeldeberechtigungen
  5. Überprüfen Sie andere Berechtigungen wie Volltextkatalog, Schema usw.

Beginnen wir mit dem ersten Anwendungsfall zum Überprüfen von Berechtigungen auf Instanzebene.

USE CASE 1:Überprüfen Sie die Berechtigung auf SQL Server- oder Instanzebene

Dieser Anwendungsfall zeigt, wie verschiedene Berechtigungen für einen Server-Principal\-Login überprüft werden. Sie können die obige T-SQL-Anweisung mit der Systemfunktion sys.fn_builtin_permissions ausführen. Sie können die WHERE-Klausel in dieser Funktion verwenden, um nur Berechtigungen auf Serverebene aufzulisten. Hier zeige ich Ihnen Berechtigungen für mein eigenes verbundenes Login.

  • Serverstatus anzeigen
  • Serverrolle erstellen
  • Beliebige Datenbank verbinden

Wenn Sie nach einer Berechtigung auf Serverebene suchen, sollten Sie immer NULL als sicherungsfähiges Argument übergeben. In diesem Beispiel ist NULL als Serverebene sicherbar, und die obigen Berechtigungsnamen haben ein Berechtigungsargument. Führen Sie die folgende T-SQL-Anweisung aus, um die Berechtigungen auf Serverebene zu überprüfen.

--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]

Die Ausgabe ist im folgenden Bild dargestellt. T-SQL hat 1 für alle Berechtigungen für meine Anmeldung zurückgegeben. Das bedeutet, dass ich Berechtigungen für alle drei Vorgänge habe. Ich kann den Serverstatus anzeigen, ich kann eine Serverrolle erstellen und ich kann auch eine Verbindung zu jeder Datenbank auf diesem Server oder dieser Instanz herstellen.

Lassen Sie mich Ihnen zeigen, ob ein Login namens „manvendra“ Berechtigungen für die oben genannten 3 Operationen hat. Wir werden die T-SQL-Anweisung EXECUTE AS LOGIN verwenden, um die Zugriffsebene zu überprüfen. Stellen Sie sicher, dass Sie die IMPERSONATE-Berechtigung für die Anmeldung haben, für die Sie die Berechtigungen überprüfen. Führen Sie dieselbe T-SQL-Anweisung wie oben nach der EXECUTE AS LOGIN-Anweisung aus.

--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]

Hier können wir sehen, dass das Login „manvendra“ keinen Zugriff auf eine dieser 3 Aktivitäten auf Serverebene hat, da ihre Ausgabe 0 zurückgegeben hat.

USE CASE 2:Berechtigungen auf Datenbankebene prüfen

Ich habe im obigen Abschnitt erklärt, wie Sie verschiedene Berechtigungen für einen Prinzipal auf Server- oder Instanzebene überprüfen können. Jetzt zeige ich Ihnen, wie Sie verschiedene Berechtigungen für jeden Prinzipal auf Datenbankebene überprüfen. Siehe folgende Anweisung:

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

Im folgenden Screenshot sehen Sie, dass auf Datenbankebene 82 Berechtigungen verfügbar sind.

Ich habe die folgenden Berechtigungen ausgewählt, um zu prüfen, ob mein Login oder ein zusätzliches Login „manvendra“ berechtigt ist, diese Aktivitäten durchzuführen.

  • JEDES
  • Tabelle erstellen
  • VERFAHREN ERSTELLEN
  • EINFÜGEN
  • AUSWÄHLEN

Hier ist sicherungsfähig der Datenbankname, für den Sie die Berechtigungen überprüfen möchten, die sicherungsfähige Klasse ist „Datenbank“ und die Berechtigung sind die oben genannten Berechtigungsnamen. Führen Sie die folgende T-SQL-Anweisung aus, um verschiedene Berechtigungen zu überprüfen.

--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]

Die Ausgabe gab 1 für jede Berechtigung zurück. Das bedeutet, dass ich berechtigt bin, alle oben genannten Aktivitäten im aktuellen Datenbankkontext auszuführen.

Führen Sie die folgende T-SQL-Anweisung aus, um die gleichen Berechtigungen für die Anmeldung „manvendra“ im aktuell ausgewählten Datenbankkontext zu überprüfen.

--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]

Die Ausgabe zeigt, dass das Login „manvendra“ sehr eingeschränkte Berechtigungen für diese Datenbank hat. Dieser Login kann sich nur mit der Datenbank verbinden und die restlichen Berechtigungen sind nicht erlaubt.

Hier habe ich den Datenbankkontext geändert und die Datenbank „AdventureWorksDW2019-TSQL“ als sicherbares Argument ausgewählt und die folgende Anweisung für die Anmeldung „manvendra“ ausgeführt.

--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]

Dasselbe Login „manvendra“ hat die Berechtigung für INSERT- und SELECT-Operationen auf dieser Datenbank „AdventureWorks2019-TSQL“

In ähnlicher Weise können wir die obige T-SQL-Anweisung ausführen, um die Berechtigung für unterschiedliche Datenbanken für unsere Anmeldung zu überprüfen. Die Ausgabe zeigt, dass ich Zugriff auf alle Berechtigungen habe.

Sie können fortfahren und andere Berechtigungen auf Datenbankebene für jeden Prinzipal überprüfen, indem Sie die oben genannte SQL Server-Sicherheitsfunktion des Systems verwenden.

USE CASE 3:Berechtigungen auf OBJEKTEBENE prüfen

Dieser Anwendungsfall veranschaulicht die Verwendung von Berechtigungen auf Objektebene innerhalb einer Datenbank. Auch hier können Sie die folgende T-SQL-Anweisung ausführen, um alle verfügbaren Berechtigungen für die sicherungsfähige Klasse „OBJECT“ aufzulisten. Ich habe die WHERE-Klausel in der Systemfunktion sys.fn_builtin_permissions verwendet, um die Berechtigungsliste auf Objektebene anzuzeigen.

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

Hier ist die Liste der Berechtigungen für die sicherungsfähige Klasse Object.

Jetzt werde ich die folgenden Berechtigungen für ein bestimmtes Objekt für ein beliebiges Anmeldekonto überprüfen und sehen, ob dieses Konto Zugriff hat, um die folgenden Vorgänge auszuführen.

  • EINFÜGEN
  • AUSWÄHLEN
  • LÖSCHEN
  • DEFINITION ANZEIGEN

Ich habe ein Datenbankobjekt „dbo.dimAccount“ als sicherungsfähig, OBJECT als sicherungsfähige Klasse und die obigen Berechtigungen als Berechtigungsargument verwendet. Führen Sie die folgenden Anweisungen aus, um die Berechtigungsdetails anzuzeigen.

--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]

Da ich in dieser Instanz ein Systemadministrator bin, gibt mein Konto 1 für jede Berechtigung zurück, die ich auf jeder Ebene überprüfe. Das bedeutet, dass ich alle Berechtigungen habe, und dies kann auch überprüft werden, indem Sie die folgenden Anweisungen ausführen.

Führen Sie die folgende Anweisung aus, um die Berechtigungen für das Login „manvendra“ zu überprüfen.

--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]

Wir können sehen, dass das Login „manvendra“ Zugriff auf die Berechtigungen INSERT, SELECT und DELETE hat, aber dieses Konto hat keine Berechtigung, die DEFINITION dieses Objekts in der Datenbank „AdventureWorksDW2019-TSQL“ zu sehen.

Lassen Sie mich den DENY-Zugriff auf den DELETE-Vorgang für dieses Konto „manvendra“ auf das Objekt „DimAccount“ in der Datenbank AdventureWorksDW2019-TSQL anwenden. Sie können dies im folgenden Bild sehen.

Wir können sehen, dass die Ausgabe anzeigt, dass Login „manvendra“ nur Zugriff auf INSERT- und SELECT-Anweisungen hat und keine Berechtigung für die DELETE-Anweisung hat.

Überprüfen Sie verschiedene Zugriffsebenen für jedes Login auf ein beliebiges Datenbankobjekt, indem Sie die obige Systemfunktion verwenden.

USE CASE 4:Anmeldeberechtigung prüfen

Dieser Anwendungsfall hilft Ihnen zu verstehen, wie Sie verschiedene Berechtigungen für Anmeldungen überprüfen können. Sie können all diese Arten von Details mit dieser System-SQL-Server-Sicherheitsfunktion HAS_PERMS_BY_NAME abrufen.

Wir können alle für eine bestimmte Anmeldung verfügbaren Berechtigungen auflisten, indem wir die folgende T-SQL-Anweisung ausführen.

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

Nachfolgend finden Sie die Liste der Berechtigungsnamen für die sicherungsfähige Klasse „LOGIN“.

Ich werde prüfen, ob ich die ALTER- oder VIEW DEFINITION-Berechtigung für Login sa habe, indem ich die folgenden T-SQL-Anweisungen ausführe. Ich habe login sa als sicherungsfähiges Argument, LOGIN als sicherungsfähiges Klassenargument und ALTER &VIEW DEFINITION als Berechtigungsargument in dieser Systemfunktion verwendet.

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

Als Systemadministrator habe ich diese Zugriffsebenen, und die Ausgabe wird auch validiert, indem ihr Wert als 1 zurückgegeben wird.

Lassen Sie uns prüfen, ob das Login „manvendra“ die Berechtigung hat, die Definition des Logins sa zu ändern oder anzuzeigen.

--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')

Die Ausgabe wurde als Null (0) zurückgegeben, was bedeutet, dass Login „manvendra“ keine Berechtigung zum ALTER oder VIEW DEFINITION login sa hat.

Verwenden Sie diese Systemfunktion, um Zugriffsebenen für verschiedene Anmeldungen zu überprüfen und zu verstehen.

USE CASE 5:Andere Berechtigungen prüfen

Hier werde ich einige andere sicherungsfähige Klassen behandeln, wie SCHEMA und FULLTEXT CATALOG, ENDPOINT, AVAILABILITY GROUP usw.

Lassen Sie uns zunächst alle Berechtigungen auflisten, die für die sicherungsfähigen Klassen SCHEMA und FULLTEXT CATALOG verfügbar sind, indem Sie die folgende Anweisung ausführen:

--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'

Der nächste Schritt besteht darin, zu ermitteln, welche Berechtigung wir suchen, um nach unserem Prinzipal zu suchen. Ich werde die DELETE- und ALTER-Berechtigungen für die sicherungsfähige Klasse SCHEMA und die ALTER- und VIEW DEFINITION-Berechtigung für die sicherungsfähige Klasse FULLTEXT CATALOG überprüfen.

Wir müssen ihre jeweiligen sicherungsfähigen Elemente übergeben, so wie ich in der folgenden Anweisung dbo für die sicherungsfähige SCHEMA-Klasse und FTCatalog für die sicherungsfähige Klasse FULLTEXT CATALOG übergeben habe.

Führen Sie die folgende T-SQL-Anweisung aus, um die Berechtigung für Ihre Anmeldung zu erhalten.

--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]

Die folgende Ausgabe zeigt, dass die Anmeldung „manvendra“ nur Zugriff auf die SCHEMA-Löschung hat und die restlichen Zugriffe verweigert oder widerrufen wurden.

Schlussfolgerung

Ich habe den schrittweisen Prozess zum Überprüfen verschiedener Berechtigungen für mehrere sicherungsfähige Klassen für jeden Prinzipal in diesem Artikel erläutert. Sie können diese SQL Server-Systemsicherheitsfunktion auch verwenden, um Ihre Anforderungen an die Berechtigungsprüfung zu erfüllen. Bitte teilen Sie diesen Artikel und geben Sie Ihr Feedback im Kommentarbereich ab, damit wir uns verbessern können.