Forståelse af SQL Server-sikkerhedsfunktionen HAS_Permis_BY

Der er flere tilfælde, hvor vi ønsker at kontrollere tilladelsen på en sikker for en rektor. Inden vi går videre, lad os se, hvad principal, sikkerhedsobjekter og tilladelser er.

Ifølge Microsoft Documentation,

Securables i SQL Server-kontekst er specifikke ressourcer, som SQL Server Database Engine-autorisationssystemet kontrollerer adgangen til. De er opdelt i tre kategorier:Server, Database og Skema. Generelt kan alle SQL Server- eller databaseobjekter være sikrede.
Tilladelser er kontroller, som vi tildeler, giver eller nægter et vist niveau af adgang til en sikker.
Rektor er en enhed, der modtager tilladelse til en sikker. De mest almindelige principper er logins og databasebrugere.

SQL Server har en indbygget sikkerhedsfunktion HAS_Permis_BY_Name som vil hjælpe os med at finde ud af, om en identificeret rektor har specifik tilladelse til en given sikker eller ej. Denne systemfunktion returnerer 1, hvis der tildeles en effektiv tilladelse til den pågældende principal på en given sikkerbar, og den returnerer 0, hvis effektiv tilladelse ikke er tildelt. Du får NULL-værdien, hvis den effektive tilladelse eller sikrede klasse ikke er gyldig.

HAS_Permis_BY_Name systemfunktionen er også meget nyttig til at kontrollere tilladelsen til dit login. Jeg vil vise dig en trin-for-trin-proces for at kontrollere specifik tilladelse til en sikker for min rektor og andre rektorer i denne artikel.

T-SQL-syntaksen for denne systemfunktion er som følger:

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

Tre obligatoriske parametre vil være nødvendige for at udføre denne system-SQL Server-sikkerhedsfunktion.

Indtast navnet på den sikrede som du vil kontrollere tilladelsen om. Hvis en sikker er en server i sig selv, skal du bruge NULL.
Anden parameter er securable_class som er navnet på klassen. Hvis du ikke er sikker på det, kan du bruge en anden systemfunktion sys.fn_builtin_permissions for at få den fulde liste over sikre klasser og deres tilgængelige tilladelser.
Tredje parameter er tilladelsen hvor du skal indtaste den effektive tilladelse, som du vil kontrollere på den angivne sikreable.

Lad mig nu vise dig alle tilgængelige sikre klasser ved at køre systemfunktionen sys.fn_builtin_permissions. Jeg har brugt DISTINCT til at vise rækker pr. sikker klasse.

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

Her kan du få en liste over den sikrede klasse.

Hvis du vil kontrollere alle mulige tilladelser for en sikker klasse, kan du også bruge denne systemfunktion. Kør nedenstående T-SQL-sætning:

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

Vi kan se listen på billedet nedenfor. class_desc er en sikker klasse og tilladelsesnavn er en type tilladelse. Hvis du ikke er sikker på, hvilken klasse der kan sikres, og hvilke tilladelser der skal kontrolleres for eventuelle sikrede, kan du bruge denne systemfunktion.

HAS_Permis_BY_Name USE Cases

Jeg vil vise dig 5 use cases for at kontrollere forskellige tilladelser for mit eget login til SQL Server-instans og for et ekstra login ved navn manvendra .

Tjek tilladelser på server- eller instansniveau
Tjek tilladelser på databaseniveau
Tjek objektniveautilladelser
Tjek logintilladelser
Tjek andre tilladelser som Fuldtekstkatalog, Skema osv.

Lad os starte med den første use case for at kontrollere tilladelser på instansniveau.

BRUG CASE 1:Tjek SQL Server- eller Instance-Level Permission

Denne use case vil vise, hvordan man kontrollerer forskellige tilladelser for en server principal\login. Du kan køre ovenstående T-SQL-sætning ved at bruge systemfunktionen sys.fn_builtin_permissions. Du kan bruge WHERE-sætningen i denne funktion til kun at angive tilladelser på serverniveau. Her vil jeg vise dig tilladelser til mit eget tilsluttede login.

Se servertilstand
Opret serverrolle
Tilslut enhver database

Hvis du leder efter nogen tilladelse på serverniveau, bør du altid sende NULL som et sikkert argument. I dette eksempel vil NULL kunne sikres som dets serverniveau, og ovenstående tilladelsesnavne vil have tilladelsesargument. Kør nedenstående T-SQL-sætning for at kontrollere tilladelser på serverniveau.

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

Outputtet er vist på billedet nedenfor. T-SQL har returneret 1 for alle tilladelser til mit login. Det betyder, at jeg har tilladelser til alle tre operationer. Jeg kan se serverstatus, jeg kan oprette serverrolle, og jeg kan også oprette forbindelse til enhver database på denne server eller instans.

Lad mig vise dig, om et login ved navn 'manvendra' har tilladelser til ovenstående 3 operationer. Vi vil bruge EXECUTE AS LOGIN T-SQL-sætningen til at kontrollere adgangsniveauet. Sørg for, at du har IMPERSONATE tilladelse til det login, som du tjekker tilladelserne for. Kør den samme T-SQL-sætning som ovenfor efter EXECUTE AS LOGIN-sætning.

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

Her kan vi se, at login 'manvendra' ikke har adgang til nogen af disse 3 aktiviteter på serverniveau, da deres output har returneret 0.

BRUG CASE 2:Tjek tilladelser på databaseniveau

Jeg har forklaret, hvordan man kontrollerer forskellige tilladelser for enhver principal på server- eller instansniveau i ovenstående afsnit. Nu vil jeg vise dig, hvordan du kontrollerer forskellige tilladelser for enhver principal på databaseniveau. Se nedenstående erklæring:

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

Du kan se, at der er 82 tilgængelige tilladelser på databaseniveau i nedenstående skærmbillede.

Jeg har valgt nedenstående tilladelser for at kontrollere, om mit login eller et ekstra login 'manvendra' har tilladelse til at udføre disse aktiviteter.

ENHVER
OPRET tabel
OPRET PROCEDURE
INDSÆT
VÆLG

Her vil securable være det databasenavn, som du vil kontrollere tilladelserne på, den sikrede klasse vil være 'Database' og tilladelsen vil være ovenstående tilladelsesnavne. Kør nedenstående T-SQL-sætning for at kontrollere forskellige tilladelser.

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

Outputtet returnerede 1 for hver tilladelse. Det betyder, at jeg har tilladelse til at udføre alle ovenstående aktiviteter i den aktuelle databasekontekst.

Kør nedenstående T-SQL-sætning for at kontrollere de samme tilladelser for login 'manvendra' i den aktuelt valgte databasekontekst.

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

Outputtet viser, at login 'manvendra' har meget begrænsede tilladelser på denne database. Dette login kan kun oprette forbindelse til databasen, og resten af tilladelserne er ikke tilladt.

Her har jeg ændret databasekonteksten og valgt databasen 'AdventureWorksDW2019-TSQL' som et sikkert argument og udført nedenstående sætning for 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]

Det samme login 'manvendra' har tilladelse til at INDSÆTTE og VÆLG operationer på denne database 'AdventureWorks2019-TSQL'

På samme måde kan vi køre ovenstående T-SQL-sætning for at kontrollere tilladelsen til forskellige databaser til vores login. Outputtet viser, at jeg har adgang til alle tilladelser.

Du kan gå videre og kontrollere andre tilladelser på databaseniveau for enhver principal ved at bruge ovenstående system SQL Server-sikkerhedsfunktion.

BRUG CASE 3:Tjek OBJECT-LEVEL-tilladelser

Denne use case illustrerer brugen af tilladelser på objektniveau i en database. Igen kan du køre nedenstående T-SQL-sætning for at liste alle tilgængelige tilladelser for den sikre klasse 'OBJECT'. Jeg har brugt WHERE-sætningen i systemfunktionen sys.fn_builtin_permissions til at vise tilladelseslisten på objektniveau.

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

Her er listen over tilladelser for den sikrede klasse Object.

Nu vil jeg tjekke nedenstående tilladelser på et specifikt objekt for enhver login-konto og se, om den konto har adgang til at udføre nedenstående handlinger.

INDSÆT
VÆLG
SLET
SE DEFINITION

Jeg har brugt et databaseobjekt 'dbo.dimAccount' som sikker, OBJECT som en sikker klasse og ovenstående tilladelser som tilladelsesargument. Kør nedenstående erklæringer for at vise tilladelsesdetaljerne.

--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 jeg er sysadmin i dette tilfælde, returnerer min konto 1 for enhver tilladelse, jeg tjekker på et hvilket som helst niveau. Det betyder, at jeg har fulde tilladelser, og dette kan verificeres ved også at køre nedenstående udsagn.

Kør nedenstående erklæring for at kontrollere tilladelserne for login '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]

Vi kan se login 'manvendra' har adgang til INSERT, SELECT og DELETE tilladelser, men denne konto har ikke tilladelse til at SE DEFINITION af dette objekt i databasen 'AdventureWorksDW2019-TSQL'.

Lad mig anvende DENY-adgang til DELETE-operationen for denne konto 'manvendra' på objektet 'DimAccount' i databasen AdventureWorksDW2019-TSQL. Du kan se dette på billedet nedenfor.

Vi kan se, at outputtet indikerer, at login 'manvendra' kun har adgang til INSERT- og SELECT-sætninger og ikke har tilladelse til DELETE-sætningen.

Tjek forskellige adgangsniveauer for ethvert login på et databaseobjekt ved at bruge ovenstående systemfunktion.

BRUG CASE 4:Tjek logintilladelse

Denne use case hjælper dig med at forstå, hvordan du kontrollerer forskellige tilladelser for logins. Du kan få alle disse slags detaljer ved hjælp af denne system-SQL Server-sikkerhedsfunktion HAS_PERMS_BY_NAME.

Vi kan liste alle tilgængelige tilladelser for et specifikt login ved at køre nedenstående T-SQL-sætning.

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

Nedenfor er listen over tilladelsesnavne for den sikre klasse 'LOGIN'.

Jeg vil kontrollere, om jeg har ALTER- eller VIEW DEFINITION-tilladelse på login sa ved at køre nedenstående T-SQL-sætninger. Jeg har brugt login sa som et sikreligt argument, LOGIN som et sikret klasseargument og ALTER &VIEW DEFINITION som et tilladelsesargument i denne systemfunktion.

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

Som sysadmin vil jeg have disse adgangsniveauer, og outputtet valideres også ved at returnere deres værdi som 1.

Lad os tjekke, om login 'manvendra' har tilladelse til at ÆNDRE eller SE definition af 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')

Outputtet returneres som nul (0), hvilket betyder, at login 'manvendra' ikke har tilladelse til at ÆNDRE eller SE DEFINITION login sa.

Brug denne systemfunktion til at kontrollere og forstå adgangsniveauer for forskellige logins.

BRUG CASE 5:Tjek andre tilladelser

Her vil jeg dække nogle andre sikre klasser såsom SCHEMA og FULLTEXT CATALOG, ENDPOINT, AVAILABILITY GROUP osv.

Lad os først liste alle tilgængelige tilladelser for SCHEMA og FULLTEXT CATALOG sikre klasse ved at køre nedenstående erklæring:

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

Det næste trin er at identificere, hvilken tilladelse vi leder efter for at tjekke for vores rektor. Jeg vil tjekke SLET- og ALTER-tilladelserne for sikker klasse SCHEMA og ALTER- og VIS DEFINITION-tilladelsen på sikker klasse FULLTEXT CATALOG.

Vi er nødt til at videregive deres respektive securables, ligesom jeg har bestået dbo for SCHEMA securable klasse og FTCatalog for securable class FULLTEXT CATALOG i nedenstående erklæring.

Kør nedenstående T-SQL-erklæring for at få tilladelse til dit 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]

Nedenstående output viser, at login 'manvendra' kun har adgang til SCHEMA-sletning, og resten af adgangene er blevet nægtet eller tilbagekaldt.

Konklusion

Jeg har forklaret trin-for-trin-processen for at kontrollere forskellige tilladelser for flere sikre klasser for enhver rektor i denne artikel. Du kan også bruge denne system-SQL Server-sikkerhedsfunktion til at opfylde dine krav til kontrol af tilladelser. Del venligst denne artikel og giv din feedback i kommentarfeltet, så vi kan forbedre os.