Zrozumienie funkcji zabezpieczeń programu SQL Server HAS_Permis_BY_Name i jej przypadków użycia

Istnieje wiele przypadków, w których chcemy sprawdzić uprawnienia do zabezpieczanego dla zleceniodawcy. Zanim przejdziemy dalej, zobaczmy, jakie są podmioty, zabezpieczenia i uprawnienia.

Zgodnie z dokumentacją Microsoft,

1. Zabezpieczone w kontekście SQL Server są to określone zasoby, do których dostęp kontroluje system autoryzacji SQL Server Database Engine. Są one podzielone na trzy kategorie:Serwer, Baza danych i Schemat. Ogólnie rzecz biorąc, każdy obiekt SQL Server lub obiekt bazy danych może być zabezpieczony.
2. Uprawnienia to kontrolki, za pomocą których przypisujemy lub odmawiamy określonego poziomu dostępu do zabezpieczanego.
3. Zleceniodawca jest podmiotem, który otrzymuje pozwolenie na zabezpieczenie. Najczęstszymi podmiotami są loginy i użytkownicy bazy danych.

SQL Server ma wbudowaną funkcję bezpieczeństwa HAS_Permis_BY_Name które pomogą nam ustalić, czy zidentyfikowany zleceniodawca ma określone uprawnienia na dany zabezpieczany, czy nie. Ta funkcja systemowa zwraca 1, jeśli skuteczne uprawnienie jest przydzielone temu podmiotowi głównemu na danym zabezpieczanym, i zwraca 0, jeśli skuteczne uprawnienie nie jest przypisane. Otrzymasz wartość NULL, jeśli efektywne uprawnienie lub klasa zabezpieczana nie jest ważna.

Funkcja systemowa HAS_Permis_BY_Name jest również bardzo przydatna podczas sprawdzania uprawnień do logowania. W tym artykule pokażę Ci krok po kroku proces sprawdzania konkretnych uprawnień dotyczących zabezpieczenia dla mojego zleceniodawcy i innych zleceniodawców.

Składnia T-SQL tej funkcji systemowej jest następująca:

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

Do wykonania tej funkcji bezpieczeństwa systemu SQL Server potrzebne będą trzy obowiązkowe parametry.

• Wpisz nazwę zabezpieczonego o którym chcesz sprawdzić uprawnienia. Jeśli zabezpieczeniem jest sam serwer, powinieneś użyć wartości NULL.
• Drugi parametr to securable_class czyli nazwa klasy. Jeśli nie jesteś tego pewien, możesz użyć innej funkcji systemowej sys.fn_builtin_permissions, aby uzyskać pełną listę zabezpieczanych klas i ich dostępnych uprawnień.
• Trzeci parametr to uprawnienie gdzie musisz wprowadzić skuteczne uprawnienie, które chcesz sprawdzić na określonym zabezpieczonym.

Teraz pozwólcie, że pokażę wam wszystkie dostępne klasy, które można zabezpieczyć, uruchamiając funkcję systemową sys.fn_builtin_permissions. Użyłem DISTINCT do wyświetlenia wierszy na zabezpieczaną klasę.

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

Tutaj możesz uzyskać listę zabezpieczanych klas.

Jeśli chcesz sprawdzić wszystkie możliwe uprawnienia dla dowolnej zabezpieczanej klasy, możesz również użyć tej funkcji systemowej. Uruchom poniższą instrukcję T-SQL:

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

Listę możemy zobaczyć na poniższym obrazku. class_desc jest bezpieczną klasą i permission_name to rodzaj pozwolenia. Jeśli nie masz pewności co do zabezpieczanej klasy i uprawnień, które należy sprawdzić pod kątem zabezpieczania, możesz użyć tej funkcji systemowej.

HAS_Permis_BY_Name Przypadki użycia

Pokażę Ci 5 przypadków użycia sprawdzania różnych uprawnień dla własnego logowania do instancji SQL Server oraz dla dodatkowego loginu o nazwie manvendra .

1. Sprawdź uprawnienia na poziomie serwera lub instancji
2. Sprawdź uprawnienia na poziomie bazy danych
3. Sprawdź uprawnienia na poziomie obiektu
4. Sprawdź uprawnienia logowania
5. Sprawdź inne uprawnienia, takie jak katalog pełnego tekstu, schemat itp.

Zacznijmy od pierwszego przypadku użycia, aby sprawdzić uprawnienia na poziomie instancji.

PRZYPADEK UŻYCIA 1:Sprawdź SQL Server lub uprawnienia na poziomie instancji

Ten przypadek użycia pokaże, jak sprawdzić różne uprawnienia dla nazwy głównej serwera. Powyższą instrukcję T-SQL można uruchomić za pomocą funkcji systemowej sys.fn_builtin_permissions. Możesz użyć klauzuli WHERE w tej funkcji, aby wyświetlić tylko uprawnienia na poziomie serwera. Tutaj pokażę Ci uprawnienia do mojego własnego połączonego loginu.

• Wyświetl stan serwera
• Utwórz rolę serwera
• Połącz dowolną bazę danych

Jeśli szukasz uprawnień na poziomie serwera, zawsze powinieneś przekazać NULL jako bezpieczny argument. W tym przykładzie NULL będzie zabezpieczony jako jego poziom serwera, a powyższe nazwy uprawnień będą miały argument uprawnienia. Uruchom poniższą instrukcję T-SQL, aby sprawdzić uprawnienia na poziomie serwera.

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

Dane wyjściowe pokazano na poniższym obrazku. T-SQL zwrócił 1 dla wszystkich uprawnień do mojego logowania. Oznacza to, że mam uprawnienia do wszystkich trzech operacji. Mogę zobaczyć stan serwera, mogę stworzyć rolę serwera, a także mogę połączyć się z dowolną bazą danych na tym serwerze lub instancji.

Pokażę ci, czy login o nazwie „manvendra” ma uprawnienia do powyższych 3 operacji. Użyjemy instrukcji EXECUTE AS LOGIN T-SQL, aby sprawdzić poziom dostępu. Upewnij się, że masz uprawnienia IMPERSONATE do tego loginu, dla którego sprawdzasz uprawnienia. Uruchom tę samą instrukcję T-SQL, jak powyżej, po instrukcji 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]

Tutaj widzimy, że login „manvendra” nie ma dostępu do żadnej z tych 3 aktywności na poziomie serwera, ponieważ ich dane wyjściowe zwróciły 0.

PRZYPADEK UŻYCIA 2:Sprawdź uprawnienia na poziomie bazy danych

W powyższej sekcji wyjaśniłem, jak sprawdzić różne uprawnienia dla dowolnego zleceniodawcy na poziomie serwera lub instancji. Teraz pokażę, jak sprawdzić różne uprawnienia dla dowolnego zleceniodawcy na poziomie bazy danych. Zobacz poniższe oświadczenie:

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

Na poniższym zrzucie ekranu możesz zobaczyć 82 uprawnienia dostępne na poziomie bazy danych.

Wybrałem poniższe uprawnienia, aby sprawdzić, czy mój login lub dodatkowy login „manvendra” ma uprawnienia do wykonywania tych czynności.

• DOWOLNE
• UTWÓRZ stół
• UTWÓRZ PROCEDURĘ
• WSTAW
• WYBIERZ

Tutaj zabezpieczana będzie nazwa bazy danych, dla której chcesz sprawdzić uprawnienia, zabezpieczaną klasą będzie „Baza danych”, a uprawnienie będą powyższymi nazwami uprawnień. Uruchom poniższą instrukcję T-SQL, aby sprawdzić różne uprawnienia.

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

Dane wyjściowe zwróciły 1 dla każdego uprawnienia. Oznacza to, że mam uprawnienia do wykonywania wszystkich powyższych czynności w bieżącym kontekście bazy danych.

Uruchom poniższą instrukcję T-SQL, aby sprawdzić te same uprawnienia do logowania „manvendra” w aktualnie wybranym kontekście bazy danych.

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

Dane wyjściowe pokazują, że login „manvendra” ma bardzo ograniczone uprawnienia w tej bazie danych. Ten login może łączyć się tylko z bazą danych, a pozostałe uprawnienia są niedozwolone.

Tutaj zmieniłem kontekst bazy danych i wybrałem bazę danych „AdventureWorksDW2019-TSQL” jako bezpieczny argument i wykonałem poniższą instrukcję logowania „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]

Ten sam login „manvendra” ma uprawnienia do operacji INSERT i SELECT na tej bazie danych „AdventureWorks2019-TSQL”

Podobnie możemy uruchomić powyższą instrukcję T-SQL, aby sprawdzić uprawnienia do różnych baz danych dla naszego logowania. Wynik pokazuje, że mam dostęp do wszystkich uprawnień.

Możesz sprawdzić inne uprawnienia na poziomie bazy danych dla dowolnego podmiotu, korzystając z powyższej funkcji bezpieczeństwa systemu SQL Server.

PRZYPADEK UŻYCIA 3:Sprawdź uprawnienia na POZIOMIE OBIEKTU

Ten przypadek użycia ilustruje użycie uprawnień na poziomie obiektu w bazie danych. Ponownie, możesz uruchomić poniższą instrukcję T-SQL, aby wyświetlić wszystkie dostępne uprawnienia dla zabezpieczanej klasy „OBJECT”. Użyłem klauzuli WHERE w funkcji systemowej sys.fn_builtin_permissions, aby wyświetlić listę uprawnień na poziomie obiektu.

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

Oto lista uprawnień dla zabezpieczanej klasy Object.

Teraz sprawdzę poniższe uprawnienia do określonego obiektu dla dowolnego konta logowania i zobaczę, czy to konto ma dostęp do wykonywania poniższych operacji.

• WSTAW
• WYBIERZ
• USUŃ
• WIDOK DEFINICJI

Użyłem obiektu bazy danych „dbo.dimAccount” jako zabezpieczanej, OBJECT jako zabezpieczanej klasy i powyższych uprawnień jako argumentu uprawnień. Uruchom poniższe instrukcje, aby wyświetlić szczegóły uprawnień.

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

Ponieważ jestem administratorem w tej instancji, moje konto zwraca 1 dla każdego uprawnienia, które sprawdzam na dowolnym poziomie. Oznacza to, że mam pełne uprawnienia i można to również zweryfikować, uruchamiając poniższe instrukcje.

Uruchom poniższe oświadczenie, aby sprawdzić uprawnienia do logowania „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]

Widzimy, że login „manvendra” ma dostęp do uprawnień INSERT, SELECT i DELETE, ale to konto nie ma uprawnień do WYŚWIETLANIA DEFINICJI tego obiektu w bazie danych „AdventureWorksDW2019-TSQL”.

Pozwólcie, że zastosuję dostęp DENY do operacji DELETE dla tego konta „manvendra” na obiekcie „DimAccount” w bazie danych AdventureWorksDW2019-TSQL. Możesz to zobaczyć na poniższym obrazku.

Widzimy, że dane wyjściowe wskazują, że login „manvendra” ma dostęp tylko do instrukcji INSERT i SELECT i nie ma uprawnień do instrukcji DELETE.

Sprawdź różne poziomy dostępu dla dowolnego logowania do dowolnego obiektu bazy danych, korzystając z powyższej funkcji systemowej.

PRZYPADEK UŻYCIA 4:Sprawdź uprawnienia do logowania

Ten przypadek użycia pomoże Ci zrozumieć, jak sprawdzić różne uprawnienia do logowania. Możesz uzyskać wszystkie tego rodzaju informacje, korzystając z tej systemowej funkcji bezpieczeństwa SQL Server HAS_PERMS_BY_NAME.

Możemy wyświetlić listę wszystkich uprawnień dostępnych dla konkretnego loginu, uruchamiając poniższą instrukcję T-SQL.

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

Poniżej znajduje się lista nazw uprawnień dla zabezpieczanej klasy „LOGIN”.

Sprawdzę, czy mam uprawnienie ALTER lub VIEW DEFINITION do logowania sa, uruchamiając poniższe instrukcje T-SQL. Użyłem login sa jako zabezpieczanego argumentu, LOGIN jako zabezpieczanego argumentu klasy i ALTER &VIEW DEFINITION jako argumentu uprawnień w tej funkcji systemowej.

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

Jako administrator będę miał te poziomy dostępu, a dane wyjściowe są również sprawdzane przez zwrócenie ich wartości jako 1.

Sprawdźmy, czy login „manvendra” ma uprawnienia do ZMIANY lub WYŚWIETLANIA definicji logowania 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')

Dane wyjściowe zwrócone jako zero (0), co oznacza, że ​​logowanie „manvendra” nie ma uprawnień do ZMIANY lub WYŚWIETLANIA DEFINICJI login sa.

Użyj tej funkcji systemowej, aby sprawdzić i zrozumieć poziomy dostępu dla różnych loginów.

PRZYPADEK UŻYCIA 5:Sprawdź inne uprawnienia

Tutaj omówię kilka innych bezpiecznych klas, takich jak SCHEMA i KATALOG PEŁNOTEKSTOWY, PUNKT KOŃCOWY, GRUPA DOSTĘPNOŚCI itp.

Najpierw wypiszmy wszystkie uprawnienia dostępne dla zabezpieczanej klasy SCHEMA i FULLTEXT CATALOG, uruchamiając poniższą instrukcję:

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

Następnym krokiem jest określenie, jakich uprawnień szukamy, aby sprawdzić naszego zleceniodawcę. Zamierzam sprawdzić uprawnienia DELETE i ALTER dla zabezpieczanej klasy SCHEMA oraz uprawnienia ALTER i VIEW DEFINITION dla zabezpieczanej klasy FULLTEXT CATALOG.

Musimy przekazać ich odpowiednie zabezpieczenia, tak jak przekazałem dbo dla klasy zabezpieczanej SCHEMA i FTCatalog dla klasy zabezpieczanej FULLTEXT CATALOG w poniższym oświadczeniu.

Uruchom poniższą instrukcję T-SQL, aby uzyskać pozwolenie na logowanie.

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

Poniższe dane wyjściowe pokazują, że login „manvendra” ma dostęp tylko do usuwania SCHEMATU, a pozostałe dostępy zostały odrzucone lub unieważnione.

Wniosek

W tym artykule wyjaśniłem krok po kroku proces sprawdzania różnych uprawnień dla wielu zabezpieczanych klas dla dowolnego zleceniodawcy. Możesz również użyć tej funkcji bezpieczeństwa systemu SQL Server, aby spełnić wymagania dotyczące sprawdzania uprawnień. Udostępnij ten artykuł i podziel się swoją opinią w sekcji komentarzy, abyśmy mogli ulepszyć.