sql >> Database >  >> RDS >> Sqlserver

Inzicht in SQL Server-beveiligingsfunctie HAS_Permis_BY_Name en zijn gebruiksgevallen

Er zijn meerdere gevallen waarin we de toestemming op een beveiligbaar voor een principal willen controleren. Laten we, voordat we verder gaan, eens kijken wat de hoofdsom, beveiligingen en machtigingen zijn.

Volgens Microsoft-documentatie,

  1. Beveiligingen in SQL Server-context zijn specifieke bronnen waartoe het SQL Server Database Engine-autorisatiesysteem de toegang beheert. Ze zijn onderverdeeld in drie categorieën:Server, Database en Schema. Over het algemeen kunnen alle SQL Server- of databaseobjecten beveiligbaar zijn.
  2. Machtigingen zijn controles waarmee we een bepaald niveau van toegang toewijzen of weigeren aan een beveiligbare.
  3. Principaal is een entiteit die toestemming krijgt voor een beveiligbare. De meest voorkomende principes zijn logins en databasegebruikers.

SQL Server heeft een ingebouwde beveiligingsfunctie HAS_Permis_BY_Name dat zal ons helpen te achterhalen of een geïdentificeerde principal specifieke toestemming heeft voor een bepaalde beveiligbare waarde of niet. Deze systeemfunctie retourneert 1 als effectieve machtiging is toegewezen aan die principal op een bepaalde beveiligbare, en retourneert 0 als effectieve machtiging niet is toegewezen. U krijgt de NULL-waarde als de effectieve machtiging of beveiligbare klasse niet geldig is.

De systeemfunctie HAS_Permis_BY_Name is ook erg handig bij het controleren van de toestemming voor uw login. Ik zal je in dit artikel een stapsgewijs proces laten zien om specifieke toestemming voor een beveiligbaar voor mijn opdrachtgever en andere opdrachtgevers te controleren.

De T-SQL-syntaxis van deze systeemfunctie is als volgt:

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

Er zijn drie verplichte parameters nodig om deze SQL Server-beveiligingsfunctie van het systeem uit te voeren.

  • Voer de naam in van de beveiligde waarvan u de toestemming wilt controleren. Als een beveiligbaar bestand zelf een server is, moet u NULL gebruiken.
  • Tweede parameter is securable_class dat is de naam van de klas. Als u het niet zeker weet, kunt u een andere systeemfunctie sys.fn_builtin_permissions gebruiken om de volledige lijst met beveiligbare klassen en hun beschikbare machtigingen te krijgen.
  • Derde parameter is de toestemming waar u de effectieve toestemming moet invoeren waarover u de gespecificeerde beveiligbare wilt controleren.

Laat me je nu alle beschikbare beveiligbare klassen laten zien door de systeemfunctie sys.fn_builtin_permissions uit te voeren. Ik heb DISTINCT gebruikt om rijen per beveiligde klasse weer te geven.

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

Hier kunt u een lijst krijgen van de beveiligbare klasse.

Als u alle mogelijke machtigingen voor een beveiligbare klasse wilt controleren, kunt u ook deze systeemfunctie gebruiken. Voer de onderstaande T-SQL-instructie uit:

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

We kunnen de lijst in de onderstaande afbeelding zien. De class_desc is een beveiligbare klasse en permission_name is een soort toestemming. Als u niet zeker bent van de beveiligbare klasse en machtigingen die moeten worden gecontroleerd voor een beveiligbaar bestand, kunt u deze systeemfunctie gebruiken.

HAS_Permis_BY_Name USE-cases

Ik zal u 5 voorbeelden laten zien van het controleren van verschillende machtigingen voor mijn eigen aanmelding bij SQL Server-instantie en voor een extra aanmelding met de naam manvendra .

  1. Machtigingen op server- of instantieniveau controleren
  2. Toestemmingen op databaseniveau controleren
  3. Toestemmingen op objectniveau controleren
  4. Controleer inlogrechten
  5. Controleer andere machtigingen zoals volledige tekstcatalogus, schema enz.

Laten we beginnen met de eerste use case om machtigingen op instantieniveau te controleren.

GEBRUIK 1:Controleer SQL Server of machtiging op instantieniveau

Deze use case laat zien hoe u verschillende machtigingen voor een server-principal\login kunt controleren. U kunt de bovenstaande T-SQL-instructie uitvoeren met behulp van de systeemfunctie sys.fn_builtin_permissions. U kunt de WHERE-component in deze functie gebruiken om alleen machtigingen op serverniveau weer te geven. Hier laat ik je de rechten zien voor mijn eigen verbonden login.

  • Serverstatus bekijken
  • Serverrol maken
  • Verbind elke database

Als u op zoek bent naar toestemming op serverniveau, moet u altijd NULL doorgeven als een veilig argument. In dit voorbeeld is NULL beveiligbaar als serverniveau en hebben de bovenstaande machtigingsnamen een machtigingsargument. Voer de onderstaande T-SQL-instructie uit om de machtigingen op serverniveau te controleren.

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

De uitvoer wordt weergegeven in de onderstaande afbeelding. T-SQL heeft 1 geretourneerd voor alle machtigingen voor mijn login. Het betekent dat ik machtigingen heb voor alle drie de bewerkingen. Ik kan de serverstatus bekijken, ik kan een serverrol maken en ik kan ook verbinding maken met elke database op deze server of instantie.

Ik zal u laten zien of een login met de naam 'manvendra' rechten heeft voor de bovenstaande 3 bewerkingen. We zullen het EXECUTE AS LOGIN T-SQL-statement gebruiken om het toegangsniveau te controleren. Zorg ervoor dat u IMPERSONATE-machtiging hebt voor die login waarvoor u de machtigingen controleert. Voer dezelfde T-SQL-instructie uit als hierboven na de instructie 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]

Hier kunnen we zien dat de login 'manvendra' geen toegang heeft tot een van deze 3 activiteiten op serverniveau omdat hun output 0 is geretourneerd.

GEBRUIK 2:Controleer machtigingen op databaseniveau

In de bovenstaande sectie heb ik uitgelegd hoe u verschillende machtigingen voor elke principal op server- of instantieniveau kunt controleren. Nu zal ik u laten zien hoe u verschillende machtigingen voor elke principal op databaseniveau kunt controleren. Zie de onderstaande verklaring:

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

U kunt zien dat er 82 machtigingen beschikbaar zijn op databaseniveau in de onderstaande schermafbeelding.

Ik heb de onderstaande machtigingen gekozen om te controleren of mijn login of een extra login 'manvendra' toestemming heeft om deze activiteiten uit te voeren.

  • ELKE
  • TABEL MAKEN
  • PROCEDURE MAKEN
  • INSERT
  • SELECTEER

Hier is beveiligbaar de databasenaam waarop u de machtigingen wilt controleren, de beveiligbare klasse is 'Database' en de machtiging zijn de bovenstaande machtigingsnamen. Voer de onderstaande T-SQL-instructie uit om verschillende machtigingen te controleren.

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

De uitvoer heeft 1 geretourneerd voor elke machtiging. Het betekent dat ik toestemming heb om alle bovenstaande activiteiten uit te voeren in de huidige databasecontext.

Voer de onderstaande T-SQL-instructie uit om dezelfde machtigingen voor login 'manvendra' in de momenteel geselecteerde databasecontext te controleren.

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

De output laat zien dat login 'manvendra' zeer beperkte rechten heeft op deze database. Deze login kan alleen verbinding maken met de database en de rest van de rechten zijn niet toegestaan.

Hier heb ik de databasecontext gewijzigd en database 'AdventureWorksDW2019-TSQL' gekozen als een veilig argument en de onderstaande instructie uitgevoerd voor login '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]

Dezelfde login 'manvendra' heeft toestemming voor INSERT en SELECT operaties op deze database 'AdventureWorks2019-TSQL'

Op dezelfde manier kunnen we de bovenstaande T-SQL-instructie uitvoeren om de toestemming voor verschillende databases voor onze login te controleren. De output laat zien dat ik toegang heb tot alle rechten.

U kunt doorgaan en andere machtigingen op databaseniveau voor elke principal controleren door de bovenstaande SQL Server-beveiligingsfunctie van het systeem te gebruiken.

GEBRUIK 3:Machtigingen op OBJECTNIVEAU controleren

Deze use case illustreert het gebruik van machtigingen op objectniveau binnen een database. Nogmaals, u kunt de onderstaande T-SQL-instructie uitvoeren om alle beschikbare machtigingen voor de beveiligbare klasse 'OBJECT' weer te geven. Ik heb de WHERE-component in de systeemfunctie sys.fn_builtin_permissions gebruikt om de lijst met machtigingen op objectniveau weer te geven.

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

Hier is de lijst met machtigingen voor de beveiligbare klasse Object.

Nu ga ik de onderstaande machtigingen voor een specifiek object voor elk inlogaccount controleren en kijken of dat account toegang heeft om de onderstaande bewerkingen uit te voeren.

  • INSERT
  • SELECTEER
  • VERWIJDEREN
  • DEFINITIE BEKIJKEN

Ik heb een database-object 'dbo.dimAccount' gebruikt als beveiligbaar, OBJECT als een beveiligbare klasse en de bovenstaande machtigingen als toestemmingsargument. Voer de onderstaande instructies uit om de toestemmingsdetails weer te geven.

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

Aangezien ik een systeembeheerder ben in dit geval, retourneert mijn account 1 voor elke toestemming die ik op elk niveau controleer. Het betekent dat ik volledige rechten heb en dit kan worden geverifieerd door ook de onderstaande instructies uit te voeren.

Voer de onderstaande instructie uit om de machtigingen voor de login 'manvendra' te controleren.

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

We kunnen zien dat de login 'manvendra' toegang heeft tot de machtigingen INSERT, SELECT en DELETE, maar dit account heeft geen toestemming om DEFINITIE VAN dit object in de database 'AdventureWorksDW2019-TSQL' TE BEKIJKEN.

Laat me de DENY-toegang tot DELETE-bewerking toepassen voor dit account 'manvendra' op object 'DimAccount' in database AdventureWorksDW2019-TSQL. Je kunt dit zien in de onderstaande afbeelding.

We kunnen zien dat de uitvoer aangeeft dat login 'manvendra' alleen toegang heeft tot INSERT- en SELECT-statements en geen toestemming heeft voor het DELETE-statement.

Controleer verschillende toegangsniveaus voor elke login op een database-object met behulp van de bovenstaande systeemfunctie.

GEBRUIK CASE 4:Controleer aanmeldingstoestemming

Deze use-case helpt u te begrijpen hoe u verschillende machtigingen voor aanmeldingen kunt controleren. U kunt al dit soort details krijgen met behulp van deze systeem-SQL Server-beveiligingsfunctie HAS_PERMS_BY_NAME.

We kunnen een lijst maken van alle machtigingen die beschikbaar zijn voor een specifieke login door de onderstaande T-SQL-instructie uit te voeren.

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

Hieronder vindt u de lijst met machtigingsnamen voor de beveiligbare klasse 'LOGIN'.

Ik zal controleren of ik ALTER of VIEW DEFINITION toestemming heb bij inloggen sa door de onderstaande T-SQL-statements uit te voeren. Ik heb login sa gebruikt als een beveiligbaar argument, LOGIN als een beveiligbaar klassenargument en ALTER &VIEW DEFINITION als een toestemmingsargument in deze systeemfunctie.

--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 systeembeheerder heb ik deze toegangsniveaus en de uitvoer wordt ook gevalideerd door hun waarde als 1 terug te geven.

Laten we eens kijken of de login 'manvendra' toestemming heeft om de definitie van de login sa te WIJZIGEN of BEKIJKEN.

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

De uitvoer geretourneerd als nul (0), wat betekent dat login 'manvendra' geen toestemming heeft om DEFINITIE login sa te wijzigen of BEKIJKEN.

Gebruik deze systeemfunctie om toegangsniveaus voor verschillende logins te controleren en te begrijpen.

GEBRUIK CASE 5:Controleer andere machtigingen

Hier zal ik enkele andere beveiligbare klassen behandelen, zoals SCHEMA en FULLTEXT CATALOGUS, ENDPOINT, BESCHIKBAARHEIDSGROEP, enz.

Laten we eerst een lijst maken van alle machtigingen die beschikbaar zijn voor de beveiligbare klasse SCHEMA en FULLTEXT CATALOG door de onderstaande instructie uit te voeren:

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

De volgende stap is om te bepalen welke toestemming we zoeken om te controleren voor onze opdrachtgever. Ik ga de machtigingen DELETE en ALTER controleren voor de beveiligbare klasse SCHEMA en de machtigingen ALTER en DEFINITIE BEKIJKEN voor de FULLTEXT CATALOGUS van de beveiligbare klasse.

We moeten hun respectieve securables doorgeven zoals ik dbo heb doorgegeven voor de beveiligbare klasse SCHEMA en FTCatalog voor de beveiligbare klasse FULLTEXT CATALOG in de onderstaande verklaring.

Voer de onderstaande T-SQL-instructie uit om toestemming te krijgen voor uw login.

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

De onderstaande uitvoer laat zien dat login 'manvendra' alleen toegang heeft tot SCHEMA-verwijdering en dat de rest van de toegangen is geweigerd of ingetrokken.

Conclusie

Ik heb het stapsgewijze proces uitgelegd om verschillende machtigingen voor meerdere beveiligbare klassen voor elke principal in dit artikel te controleren. U kunt deze SQL Server-beveiligingsfunctie van het systeem ook gebruiken om aan uw vereisten voor toestemmingscontrole te voldoen. Deel dit artikel en geef uw feedback in de commentaarsectie zodat we kunnen verbeteren.


  1. OF Operator Kortsluiting in SQL Server

  2. De prijs van niet zuiveren

  3. CONSTRAINT om waarden uit een op afstand gerelateerde tabel te controleren (via join etc.)

  4. Tijd aftrekken formaat resultaat