Det finns flera tillfällen när vi vill kontrollera tillståndet för en säkerställbar för en huvudman. Innan vi går vidare, låt oss se vad principal, säkerhetsobjekt och behörigheter är.
Enligt Microsoft Documentation,
- Säkerbart material i SQL Server-sammanhang är specifika resurser som SQL Server Database Engine-auktoriseringssystemet styr åtkomsten till. De är indelade i tre kategorier:Server, Databas och Schema. I allmänhet kan alla SQL Server- eller databasobjekt vara säkerställbara.
- Behörigheter är kontroller som vi tilldelar ger eller nekar viss nivå av åtkomst till en säker.
- Rektor är en enhet som får tillstånd till en säkerställd. De vanligaste principerna är inloggningar och databasanvändare.
SQL Server har en inbyggd säkerhetsfunktion HAS_Permis_BY_Name som kommer att hjälpa oss att ta reda på om en identifierad huvudman har specifik behörighet för ett givet säkerställande eller inte. Den här systemfunktionen returnerar 1 om effektiv behörighet tilldelas den huvudmannen på en given säkerställbar, och den returnerar 0 om effektiv behörighet inte tilldelas. Du kommer att få NULL-värdet om den effektiva behörigheten eller säkra klassen inte är giltig.
Systemfunktionen HAS_Permis_BY_Name är också mycket användbar för att kontrollera behörighet för din inloggning. Jag kommer att visa dig en steg-för-steg-process för att kontrollera specifik behörighet för ett säkerhetsobjekt för min rektor och andra rektorer i den här artikeln.
T-SQL-syntaxen för denna systemfunktion är som följer:
--T-SQL syntax
HAS_PERMS_BY_NAME (securable, securable_class, permission)
Tre obligatoriska parametrar kommer att behövas för att köra den här säkerhetsfunktionen för SQL Server-systemet.
- Ange namnet på den säkrade som du vill kontrollera behörigheten om. Om en säkerbar är en server i sig bör du använda NULL.
- Den andra parametern är securable_class vilket är namnet på klassen. Om du inte är säker på det kan du använda en annan systemfunktion sys.fn_builtin_permissions för att få hela listan över säkra klasser och deras tillgängliga behörigheter.
- Den tredje parametern är behörigheten där du behöver ange den effektiva behörigheten som du vill kontrollera om det angivna säkerhetsobjektet.
Låt mig nu visa dig alla tillgängliga säkra klasser genom att köra systemfunktionen sys.fn_builtin_permissions. Jag har använt DISTINCT för att visa rader per säker klass.
--Display all securable_class
SELECT distinct class_desc FROM sys.fn_builtin_permissions(default)Här kan du få en lista över den säkerställda klassen.
Om du vill kontrollera alla möjliga behörigheter för en säker klass kan du också använda den här systemfunktionen. Kör nedanstående T-SQL-sats:
--Display each permission for all securable class
SELECT class_desc,permission_name FROM sys.fn_builtin_permissions(default);Vi kan se listan i bilden nedan. class_desc är en säker klass och behörighetsnamn är en typ av tillstånd. Om du inte är säker på vilken klass som kan skyddas och vilka behörigheter som ska kontrolleras för eventuella säkerställda kan du använda den här systemfunktionen.
HAS_Permis_BY_Name USE Cases
Jag kommer att visa dig 5 användningsfall för att kontrollera olika behörigheter för min egen inloggning till SQL Server-instansen och för en ytterligare inloggning som heter manvendra .
- Kontrollera behörigheter på server- eller instansnivå
- Kontrollera behörigheter på databasnivå
- Kontrollera behörigheter på objektnivå
- Kontrollera inloggningsbehörigheter
- Kontrollera andra behörigheter som fulltextkatalog, schema etc.
Låt oss börja med det första användningsfallet för att kontrollera behörigheter på instansnivå.
ANVÄND FALL 1:Kontrollera SQL Server eller instansnivåbehörighet
Detta användningsfall kommer att visa hur man kontrollerar olika behörigheter för en serverprincipal\inloggning. Du kan köra ovanstående T-SQL-sats med hjälp av systemfunktionen sys.fn_builtin_permissions. Du kan använda WHERE-satsen i den här funktionen för att bara lista behörigheter på servernivå. Här kommer jag att visa dig behörigheter för min egen anslutna inloggning.
- Visa serverstatus
- Skapa serverroll
- Anslut valfri databas
Om du letar efter någon behörighet på servernivå bör du alltid skicka NULL som ett säkert argument. I det här exemplet kommer NULL att vara säkerställt som servernivå och ovanstående behörighetsnamn kommer att ha behörighetsargument. Kör T-SQL-satsen nedan för att kontrollera behörigheter på servernivå.
--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]Utgången visas i bilden nedan. T-SQL har returnerat 1 för alla behörigheter för min inloggning. Det betyder att jag har behörighet för alla tre operationerna. Jag kan se serverstatus, jag kan skapa serverroll och jag kan också ansluta till vilken databas som helst på den här servern eller instansen.
Låt mig visa dig om en inloggning som heter 'manvendra' har behörigheter för ovanstående 3 operationer. Vi kommer att använda EXECUTE AS LOGIN T-SQL-satsen för att kontrollera åtkomstnivån. Se till att du har IMPERSONATE behörighet för den inloggning som du kontrollerar behörigheterna för. Kör samma T-SQL-sats som ovan efter EXECUTE AS LOGIN-satsen.
--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]Här kan vi se att inloggningen 'manvendra' inte har tillgång till någon av dessa 3 aktiviteter på servernivå eftersom deras utdata har returnerat 0.
ANVÄND FALL 2:Kontrollera behörigheter på databasnivå
Jag har förklarat hur man kontrollerar olika behörigheter för en principal på server- eller instansnivå i avsnittet ovan. Nu kommer jag att visa dig hur du kontrollerar olika behörigheter för alla huvudmän på databasnivå. Se nedanstående uttalande:
--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 att det finns 82 behörigheter tillgängliga på databasnivå i skärmdumpen nedan.
Jag har valt behörigheterna nedan för att kontrollera om min inloggning eller en extra inloggning 'manvendra' har behörighet att utföra dessa aktiviteter.
- NÅGON
- SKAPA tabell
- SKAPA PROCEDUR
- INSERT
- VÄLJ
Här kommer säkerställbar att vara databasnamnet som du vill kontrollera behörigheterna på, den säkerställbara klassen kommer att vara 'Databas' och behörighet kommer att vara ovanstående behörighetsnamn. Kör nedanstående T-SQL-sats för att kontrollera olika behörigheter.
--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]Utdata returnerade 1 för varje behörighet. Det betyder att jag har tillstånd att utföra alla ovanstående aktiviteter i det aktuella databassammanhanget.
Kör T-SQL-satsen nedan för att kontrollera samma behörigheter för inloggning 'manvendra' i den för närvarande valda databaskontexten.
--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]Utdata visar att inloggning 'manvendra' har mycket begränsade behörigheter på denna databas. Denna inloggning kan bara ansluta till databasen och resten av behörigheterna är inte tillåtna.
Här har jag ändrat databaskontexten och valt databasen 'AdventureWorksDW2019-TSQL' som ett säkert argument och kört nedanstående sats för inloggning '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]Samma inloggning 'manvendra' har behörighet att INFOGA och VÄLJA operationer på denna databas 'AdventureWorks2019-TSQL'
På samma sätt kan vi köra ovanstående T-SQL-sats för att kontrollera behörighet för distinkta databaser för vår inloggning. Utdata visar att jag har tillgång till alla behörigheter.
Du kan gå vidare och kontrollera andra behörigheter på databasnivå för alla rektorer genom att använda ovanstående säkerhetsfunktion för systemets SQL Server.
ANVÄND FALL 3:Kontrollera OBJECT-LEVEL behörigheter
Detta användningsfall illustrerar användning av behörigheter på objektnivå i en databas. Återigen kan du köra T-SQL-satsen nedan för att lista alla tillgängliga behörigheter för den säkerställda klassen 'OBJECT'. Jag har använt WHERE-satsen i systemfunktionen sys.fn_builtin_permissions för att visa behörighetslistan på objektnivå.
--Check all object level permissions
SELECT class_desc,permission_name FROM sys.fn_builtin_permissions(default)
WHERE class_desc ='OBJECT'Här är listan över behörigheter för den säkerhetsbara klassen Object.
Nu ska jag kontrollera behörigheterna nedan för ett specifikt objekt för alla inloggningskonton och se om det kontot har åtkomst för att utföra åtgärderna nedan.
- INSERT
- VÄLJ
- RADERA
- VISA DEFINITION
Jag har använt ett databasobjekt 'dbo.dimAccount' som säkerställbart, OBJECT som en säkerställbar klass och ovanstående behörigheter som behörighetsargument. Kör satserna nedan för att visa behörighetsdetaljerna.
--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]
Eftersom jag är systemadministratör i det här fallet, returnerar mitt konto 1 för alla behörigheter som jag kontrollerar på vilken nivå som helst. Det betyder att jag har fullständiga behörigheter, och detta kan verifieras genom att köra nedanstående uttalanden också.
Kör uttalandet nedan för att kontrollera behörigheterna för inloggningen '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 att inloggningen 'manvendra' har tillgång till INSERT-, SELECT- och DELETE-behörigheter men detta konto har inte behörighet att VISA DEFINITION av detta objekt i databasen 'AdventureWorksDW2019-TSQL'.
Låt mig tillämpa NEJ-åtkomsten till DELETE-operationen för detta konto 'manvendra' på objektet 'DimAccount' i databasen AdventureWorksDW2019-TSQL. Du kan se detta i bilden nedan.
Vi kan se att utdata indikerar att inloggning 'manvendra' endast har tillgång till INSERT- och SELECT-satser och inte har behörighet till DELETE-satsen.
Kontrollera olika åtkomstnivåer för alla inloggningar på ett databasobjekt genom att använda ovanstående systemfunktion.
ANVÄND FALL 4:Kontrollera inloggningsbehörighet
Detta användningsfall hjälper dig att förstå hur du kontrollerar olika behörigheter för inloggningar. Du kan få alla dessa typer av detaljer med den här säkerhetsfunktionen HAS_PERMS_BY_NAME för systemets SQL Server.
Vi kan lista alla tillgängliga behörigheter för en specifik inloggning genom att köra nedanstående T-SQL-sats.
--List all available permission for securable class ‘LOGIN’
SELECT class_desc, permission_name FROM sys.fn_builtin_permissions(default)
WHERE class_desc ='LOGIN'Nedan finns listan över behörighetsnamn för den säkerställda klassen 'LOGIN'.
Jag kommer att kontrollera om jag har ALTER- eller VIEW DEFINITION-behörighet vid inloggning sa genom att köra nedanstående T-SQL-satser. Jag har använt login sa som ett säkert argument, LOGIN som ett säkerställbart klassargument och ALTER &VIEW DEFINITION som ett behörighetsargument i den här systemfunktionen.
--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 kommer jag att ha dessa åtkomstnivåer, och utdata valideras också genom att returnera deras värde som 1.
Låt oss kontrollera om inloggningen 'manvendra' har behörighet att ÄNDRA eller VISA definitionen av inloggningen 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')Utdata returneras som noll (0), vilket betyder att inloggning 'manvendra' inte har behörighet att ÄNDRA eller VISA DEFINITION login sa.
Använd denna systemfunktion för att kontrollera och förstå åtkomstnivåer för olika inloggningar.
ANVÄND FALL 5:Kontrollera andra behörigheter
Här kommer jag att täcka några andra säkra klasser som SCHEMA och FULLTEXT CATALOG, ENDPOINT, AVAILABILITY GROUP, etc.
Låt oss först lista ut alla tillgängliga behörigheter för SCHEMA och FULLTEXT CATALOG säkerställd klass genom att köra nedanstående uttalande:
--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'Nästa steg är att identifiera vilken behörighet vi söker för att kontrollera för vår huvudman. Jag ska kontrollera DELETE- och ALTER-behörigheterna för säker klass SCHEMA och ALTER- och VIEW DEFINITION-behörigheterna för säker klass FULLTEXT CATALOG.
Vi måste skicka deras respektive säkerbara objekt som jag har klarat dbo för SCHEMA-säkerhetsklassen och FTCatalog för säkerbar klass FULLTEXT CATALOG i uttalandet nedan.
Kör T-SQL-satsen nedan för att få tillåtelse för din inloggning.
--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]Nedanstående utdata visar att inloggning 'manvendra' endast har åtkomst till SCHEMA-borttagning och resten av åtkomsterna har nekats eller återkallats.
Slutsats
Jag har förklarat steg-för-steg-processen för att kontrollera olika behörigheter för flera säkra klasser för alla rektorer i den här artikeln. Du kan också och använda denna säkerhetsfunktion för systemets SQL Server för att uppfylla dina krav på behörighetskontroll. Dela den här artikeln och ge din feedback i kommentarsektionen så att vi kan förbättra oss.