Rozpocznij pracę z uprawnieniami silnika bazy danych

Dotyczy do:SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics System Platform Analitycznych (PDW)Baza danych SQL w Microsoft Fabric

W tym artykule opisano niektóre podstawowe pojęcia dotyczące zabezpieczeń, a następnie opisano typową implementację uprawnień. Uprawnienia w silniku bazy danych są zarządzane na poziomie serwera za pośrednictwem nazw logowania i ról serwera oraz na poziomie bazy danych za pośrednictwem użytkowników bazy danych i ról bazy danych.

Usługa SQL Database i baza danych SQL w usłudze Microsoft Fabric udostępniają te same opcje w każdej bazie danych, ale uprawnienia na poziomie serwera nie są dostępne.

W usłudze SQL Database zapoznaj się z artykułem Samouczek: zabezpieczanie bazy danych w usłudze Azure SQL Database. Zalecane jest uwierzytelnianie za pomocą identyfikatora Entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz Tutorial: Create Microsoft Entra users using Microsoft Entra applications (Samouczek: tworzenie użytkowników entra firmy Microsoft przy użyciu aplikacji Firmy Microsoft Entra).
W bazie danych SQL w usłudze Microsoft Fabric jedyną obsługiwaną metodą uwierzytelniania dla użytkowników bazy danych jest microsoft Entra ID. Role i uprawnienia na poziomie serwera nie są dostępne. Aby uzyskać więcej informacji, zobacz Autoryzacja w bazie danych SQL w usłudze Microsoft Fabric.

Note

Microsoft Entra ID był wcześniej znany jako Azure Active Directory (Azure AD).

Elementy zabezpieczeń

Podmiot zabezpieczeń to tożsamość używana przez program SQL Server, której można przypisać uprawnienia do podejmowania działań. Podmioty zabezpieczeń to zazwyczaj osoby lub grupy osób, ale mogą być innymi jednostkami, które udają ludzi. Podmioty zabezpieczeń można tworzyć i zarządzać nimi przy użyciu przykładów Transact-SQL przedstawionych w tym artykule lub przy użyciu programu SQL Server Management Studio.

Logins

Loginy to konta użytkowników, które służą do logowania do aparatu bazy danych SQL Server. SQL Server i SQL Database obsługują loginy oparte na uwierzytelnianiu Windows oraz loginy oparte na uwierzytelnianiu SQL Server. Aby uzyskać informacje o dwóch typach logowania, zobacz Wybieranie trybu uwierzytelniania.

Stałe role serwera

W programie SQL Server stałe role serwera to zestaw wstępnie skonfigurowanych ról, które zapewniają wygodną grupę uprawnień na poziomie serwera. Loginy można dodawać do ról za pomocą instrukcji ALTER SERVER ROLE ... ADD MEMBER. Aby uzyskać więcej informacji, zapoznaj się z ALTER SERVER ROLE. Usługa SQL Database nie obsługuje stałych ról serwera, ale ma dwie role w master bazie danych (dbmanager i loginmanager), które działają jak role serwera.

Role serwera zdefiniowane przez użytkownika

W programie SQL Server można tworzyć własne role serwera i przypisywać do nich uprawnienia na poziomie serwera. Loginy można dodawać do ról serwera przy użyciu instrukcji ALTER SERVER ROLE ... ADD MEMBER. Aby uzyskać więcej informacji, zapoznaj się z ALTER SERVER ROLE. Usługa SQL Database nie obsługuje ról serwera zdefiniowanych przez użytkownika.

Użytkownicy bazy danych

Aby udzielić dostępu do logowania do bazy danych, należy utworzyć użytkownika bazy danych w tej bazie danych i zamapować użytkownika bazy danych na identyfikator logowania. Nazwa użytkownika bazy danych jest zwykle taka sama jak nazwa logowania zgodnie z konwencją, chociaż nie musi być taka sama. Każdy użytkownik bazy danych jest przypisany do pojedynczego logowania. Identyfikator logowania można przypisać tylko do jednego użytkownika w bazie danych, ale można go przypisać jako użytkownika bazy danych w wielu różnych bazach danych.

Można również utworzyć użytkowników bazy danych, którzy nie mają odpowiedniego identyfikatora logowania. Ci użytkownicy są nazywani użytkownikami zawartej bazy danych. Firma Microsoft zachęca użytkowników zawartej bazy danych, ponieważ ułatwia przenoszenie bazy danych na inny serwer. Podobnie jak podczas logowania, użytkownik zawartej bazy danych może używać uwierzytelniania systemu Windows lub uwierzytelniania programu SQL Server. Aby uzyskać więcej informacji, zobacz Uczyń swoją bazę danych przenośną, korzystając z baz danych z zawartością.

Istnieją 12 typów użytkowników z niewielkimi różnicami w sposobie ich uwierzytelniania i reprezentowanych przez nich osób. Aby wyświetlić listę użytkowników, zobacz TWORZENIE UŻYTKOWNIKA.

Stałe role bazy danych

Stałe role bazy danych to zestaw wstępnie skonfigurowanych ról, które zapewniają wygodną grupę uprawnień na poziomie bazy danych. Użytkowników bazy danych i ról bazy danych zdefiniowanych przez użytkownika można dodawać do stałych ról bazy danych przy użyciu instrukcji ALTER ROLE ... ADD MEMBER . Aby uzyskać więcej informacji, zobacz ALTER ROLE.

Role bazy danych zdefiniowane przez użytkownika

Użytkownicy z CREATE ROLE uprawnieniami mogą tworzyć nowe role bazy danych zdefiniowane przez użytkownika , aby reprezentować grupy użytkowników z typowymi uprawnieniami. Zazwyczaj uprawnienia są przyznawane lub odrzucane dla całej roli, upraszczając zarządzanie uprawnieniami i monitorowanie. Użytkownicy bazy danych mogą być dodawani do ról bazy danych przy użyciu instrukcji ALTER ROLE ... ADD MEMBER . Aby uzyskać więcej informacji, zobacz ALTER ROLE.

Inni główni uczestnicy

Inne podmioty zabezpieczeń, które nie zostały tutaj omówione, obejmują role aplikacji oraz loginy i użytkowników na podstawie certyfikatów lub kluczy asymetrycznych.

Aby zapoznać się z grafiką przedstawiającą relacje między użytkownikami systemu Windows, grupami systemu Windows, identyfikatorami logowania i użytkownikami bazy danych, zobacz Tworzenie użytkownika bazy danych.

Typowy scenariusz

Poniższy przykład reprezentuje typową i zalecaną metodę konfigurowania uprawnień.

W usłudze Windows Active Directory lub Microsoft Entra ID

Utwórz użytkownika dla każdej osoby.
Utwórz grupy systemu Windows reprezentujące jednostki robocze i funkcje robocze.
Dodaj użytkowników systemu Windows do grup systemu Windows.

Jeśli użytkownik będzie łączyć się z wieloma bazami danych

Utwórz identyfikator logowania dla grup systemu Windows. (Jeśli używasz uwierzytelniania SQL Server, pomiń kroki Active Directory i utwórz tutaj loginy uwierzytelniania SQL Server).
W bazie danych użytkowników utwórz użytkownika bazy danych na potrzeby logowania reprezentującego grupy systemu Windows.
W bazie danych użytkownika utwórz co najmniej jedną rolę bazy danych zdefiniowaną przez użytkownika, z których każda reprezentuje podobną funkcję. Na przykład możesz mieć rolę analityka finansowego i rolę analityka sprzedaży.
Dodaj użytkowników bazy danych do co najmniej jednej roli bazy danych zdefiniowanej przez użytkownika.
Udziel uprawnień do ról bazy danych zdefiniowanych przez użytkownika.

Jeśli użytkownik będzie łączyć się tylko z jedną bazą danych

W bazie danych użytkownika utwórz użytkownika zawartej bazy danych dla grupy systemu Windows. (Jeśli używasz uwierzytelniania programu SQL Server, pomiń kroki usługi Active Directory i utwórz tutaj użytkownika zawartej bazy danych przy użyciu uwierzytelniania SQL Server).
W bazie danych użytkownika utwórz co najmniej jedną rolę bazy danych zdefiniowaną przez użytkownika, z których każda reprezentuje podobną funkcję. Na przykład możesz mieć rolę analityka finansowego i rolę analityka sprzedaży.
Dodaj użytkowników bazy danych do co najmniej jednej roli bazy danych zdefiniowanej przez użytkownika.
Udziel uprawnień do ról bazy danych zdefiniowanych przez użytkownika.

Typowym wynikiem jest to, że użytkownik systemu Windows jest członkiem grupy systemu Windows. Grupa systemu Windows ma login w SQL Server albo SQL Database. Login jest mapowany na tożsamość użytkownika w bazie danych użytkowników. Użytkownik jest członkiem roli bazy danych. Teraz musisz dodać uprawnienia do roli.

Przypisz uprawnienia

Większość instrukcji uprawnień ma następujący format:

<authorization> <permission> ON <securable>::<name> TO <principal>;

<authorization> musi być GRANT, REVOKE lub DENY.
Element <permission> ustanawia akcję zezwalającą lub zakazaną. Dokładna liczba uprawnień różni się między programem SQL Server i usługą Azure SQL Database. Aby uzyskać informacje o uprawnieniach, zobacz Uprawnienia (aparat bazy danych) i zapoznaj się z wykresem w dalszej części tego artykułu.
ON <securable>::<name> jest typem zabezpieczanym (serwer, obiekt serwera, baza danych lub obiekt bazy danych) i jego nazwą. Niektóre uprawnienia nie wymagają <securable>::<name> , ponieważ są jednoznaczne lub niewłaściwe w danym kontekście. Na przykład CREATE TABLE uprawnienie nie wymaga klauzuli <securable>::<name> (GRANT CREATE TABLE TO Mary; umożliwia Mary tworzenie tabel).
<principal> jest podmiotem zabezpieczeń (logowaniem, użytkownikiem lub rolą), który otrzymuje lub traci uprawnienia. Udziel uprawnień do ról, jeśli to możliwe.

Poniższa przykładowa instrukcja przyznaje UPDATE uprawnienie w Parts tabeli lub widoku zawartego w schemacie Production do roli o nazwie PartsTeam:

GRANT UPDATE ON OBJECT::Production.Parts TO PartsTeam;

Poniższa przykładowa instrukcja udziela UPDATE uprawnień w schemacie Production i tym samym na dowolnej tabeli lub widoku zawartym w tym schemacie dla roli nazwanej ProductionTeam, jest to bardziej efektywne i opłacalne podejście do przypisywania uprawnień niż na poziomie poszczególnych obiektów.

GRANT UPDATE ON SCHEMA::Production TO ProductionTeam;

Uprawnienia są przyznawane podmiotom zabezpieczeń (logowaniom, użytkownikom i rolom) przy użyciu instrukcji GRANT . Uprawnienia są jawnie odrzucane za pomocą DENY polecenia . Wcześniej przyznane lub odrzucone uprawnienie jest usuwane przy użyciu instrukcji REVOKE . Uprawnienia są skumulowane, a użytkownik otrzymuje wszystkie uprawnienia przyznane użytkownikowi, logowaniu i członkostwu w grupach; jednak każda odmowa uprawnień ma priorytet nad wszystkimi przyznaniami.

Caution

Typowym błędem jest próba usunięcia GRANT obiektu za pomocą polecenia DENY zamiast REVOKE. Może to powodować problemy, gdy użytkownik otrzymuje uprawnienia z wielu źródeł, co może być typowym scenariuszem. W poniższym przykładzie przedstawiono zasadę.

Grupa sprzedaży otrzymuje SELECT uprawnienia do tabeli OrderStatus poprzez instrukcję GRANT SELECT ON OBJECT::OrderStatus TO Sales;. Użytkownik Jae jest członkiem Sales roli. Jae uzyskał SELECT także uprawnienia do OrderStatus tabeli, wykorzystując swoją nazwę użytkownika za pomocą instrukcji GRANT SELECT ON OBJECT::OrderStatus TO Jae;. Zakładamy, że administrator chce usunąć GRANT z roli Sales.

Jeśli administrator prawidłowo wykonuje REVOKE SELECT ON OBJECT::OrderStatus TO Sales;, Jae zachowuje SELECT dostęp do OrderStatus tabeli poprzez swoją indywidualną GRANT instrukcję.
Jeśli administrator niepoprawnie wykonuje DENY SELECT ON OBJECT::OrderStatus TO Sales;, Jae, jako członek roli Sales, ma odmowę uprawnienia SELECT, ponieważ nadpisanie DENY do Sales zastępuje jego poszczególne GRANT.

Note

Uprawnienia można skonfigurować przy użyciu programu Management Studio. Znajdź element zabezpieczalny w Eksploratorze obiektów, kliknij prawym przyciskiem myszy element zabezpieczalny, a następnie wybierz polecenie Właściwości. Wybierz stronę Uprawnienia . Aby uzyskać pomoc dotyczącą korzystania ze strony uprawnień, zobacz Stronę uprawnień lub zabezpieczania.

Hierarchia uprawnień

Uprawnienia mają hierarchię rodzic/dziecko. Oznacza to, że jeśli przyznasz SELECT uprawnienie do bazy danych, to uprawnienie obejmuje SELECT uprawnienia do wszystkich (podrzędnych) schematów w bazie danych. Jeśli udzielasz SELECT uprawnień do schematu, obejmuje to SELECT uprawnienia do wszystkich (podrzędnych) tabel i widoków w schemacie. Uprawnienia są przechodnie: jeśli udzielasz SELECT uprawnień do bazy danych, obejmuje to uprawnienia do wszystkich (podrzędnych) schematów oraz wszystkich (podrzędnych) tabel i widoków.

Uprawnienia mogą również mieć uprawnienia obejmujące. Uprawnienie CONTROL do obiektu zwykle daje wszystkie inne uprawnienia do obiektu.

Ponieważ zarówno hierarchia nadrzędna/podrzędna, jak i hierarchia obejmująca mogą działać na tym samym uprawnieniach, system uprawnień może być skomplikowany. Przykładowo, weźmy tabelę (Region), w schemacie (Customers), w bazie danych (SalesDB).

CONTROLuprawnienie do tabeli Region zawiera wszystkie inne uprawnienia w tabeliRegion, w tym ALTER, , SELECTINSERT, UPDATE, , DELETEi inne uprawnienia.
SELECT w schemacie Customers , który jest właścicielem tabeli Region, zawiera uprawnienia SELECT na tabeli Region.

Tak więc SELECT uprawnienia do Region tabeli można uzyskać za pomocą dowolnego z tych sześciu instrukcji.

GRANT SELECT ON OBJECT::Region TO Jae;

GRANT CONTROL ON OBJECT::Region TO Jae;

GRANT SELECT ON SCHEMA::Customers TO Jae;

GRANT CONTROL ON SCHEMA::Customers TO Jae;

GRANT SELECT ON DATABASE::SalesDB TO Jae;

GRANT CONTROL ON DATABASE::SalesDB TO Jae;

Udzielanie najmniejszego uprawnienia

Pierwsze uprawnienie wymienione wcześniej (GRANT SELECT ON OBJECT::Region TO Jae;) jest najbardziej szczegółowe. To stwierdzenie jest najmniejszym możliwym uprawnieniem, które przyznaje SELECT. Brak uprawnień automatycznie nadawanych do obiektów podrzędnych. Dobrą zasadą jest, aby zawsze udzielać najmniej możliwych uprawnień, ale należy rozważyć przyznanie na wyższych poziomach, aby uprościć system przyznawania.

Jeśli więc Jae potrzebuje uprawnień do całego schematu, przyznaj SELECT raz na poziomie schematu, zamiast udzielać SELECT na poziomie tabeli lub widoku wiele razy. Projekt bazy danych może znacząco wpływać na powodzenie tej strategii. Ta strategia działa najlepiej, gdy baza danych została zaprojektowana tak, aby obiekty wymagające identycznych uprawnień były uwzględniane w jednym schemacie.

Tip

Podczas projektowania bazy danych i jej obiektów należy zaplanować od początku sposób uzyskiwania dostępu do tych obiektów przez aplikacje i użytkowników. Te informacje umożliwiają kontrolowanie dostępu do tabel, widoków, funkcji i procedur składowanych przy użyciu schematów. Schematy umożliwiają łatwiejsze grupowanie typów dostępu.

Diagram uprawnień

Na poniższej ilustracji przedstawiono uprawnienia i ich relacje ze sobą. Niektóre z uprawnień wyższego poziomu (takich jak CONTROL SERVER) są wyświetlane wiele razy. Plakat w artykule jest zbyt mały, aby go przeczytać. Pełnowymiarowy plakat uprawnień silnika baz danych możesz pobrać w formacie PDF.

Zrzut ekranu z PDF uprawnienia silnika bazy danych.

Aby uzyskać grafikę przedstawiającą relacje między jednostkami aparatu bazy danych i obiektami serwera i bazy danych, zobacz Hierarchia uprawnień (aparat bazy danych).

Uprawnienia a stałe role serwera i baz danych

Uprawnienia stałych ról serwera i stałych ról bazy danych są podobne, ale nie dokładnie takie same jak szczegółowe uprawnienia. Na przykład członkowie stałej roli serwera sysadmin mają wszystkie uprawnienia w wystąpieniu programu SQL Server, tak jak loginy z uprawnieniem CONTROL SERVER.

Jednak przyznanie uprawnienia CONTROL SERVER nie czyni logowania członkiem stałej roli serwera sysadmin, a dodanie logowania do stałej roli serwera sysadmin nie udziela mu wyraźnie uprawnienia CONTROL SERVER. Czasami procedura składowana sprawdza uprawnienia, sprawdzając stałą rolę i nie sprawdzając uprawnień szczegółowych.

Na przykład odłączanie bazy danych wymaga członkostwa w db_owner stałej roli bazy danych. Równoważne CONTROL DATABASE uprawnienie nie jest wystarczające. Te dwa systemy działają równolegle, ale rzadko współdziałają ze sobą. Firma Microsoft zaleca korzystanie z nowszego, szczegółowego systemu uprawnień zamiast stałych ról, jeśli jest to możliwe.

Monitorowanie uprawnień

Następujące widoki zwracają informacje o zabezpieczeniach. Aby zapoznać się ze wszystkimi widokami powiązanymi z zabezpieczeniami, zobacz Widoki wykazu zabezpieczeń (Transact-SQL).

View	Description
`sys.server_principals` ¹	Loginy i role serwera zdefiniowane przez użytkownika na serwerze
`sys.database_principals`	Użytkownicy i role zdefiniowane przez użytkownika w bazie danych
`sys.server_permissions` ¹	Uprawnienia przyznane do logowania i zdefiniowanych przez użytkownika stałych ról serwera
`sys.database_permissions`	Uprawnienia przyznane użytkownikom i zdefiniowanym przez użytkownika stałym rolam bazy danych
`sys.database_role_members`	Członkostwo w roli bazy danych
`sys.server_role_members` ¹	Członkostwo w roli serwera

¹ Ten widok nie jest dostępny w usłudze SQL Database.

Examples

Poniższe instrukcje zwracają przydatne informacje o uprawnieniach.

A. Lista uprawnień bazy danych dla każdego użytkownika

Aby zwrócić jawne uprawnienia przyznane lub odrzucone w bazie danych (SQL Server i SQL Database), uruchom następującą instrukcję Transact-SQL w bazie danych.

SELECT perms.state_desc AS State,
       permission_name AS [Permission],
       obj.name AS [on Object],
       dp.name AS [to User Name]
FROM sys.database_permissions AS perms
     INNER JOIN sys.database_principals AS dp
         ON perms.grantee_principal_id = dp.principal_id
     INNER JOIN sys.objects AS obj
         ON perms.major_id = obj.object_id;

B. Lista członków roli serwera

Aby zwrócić członków ról serwera (tylko dla SQL Server), uruchom następujące polecenie.

SELECT roles.principal_id AS RolePrincipalID,
       roles.name AS RolePrincipalName,
       server_role_members.member_principal_id AS MemberPrincipalID,
       members.name AS MemberPrincipalName
FROM sys.server_role_members AS server_role_members
     INNER JOIN sys.server_principals AS roles
         ON server_role_members.role_principal_id = roles.principal_id
     LEFT OUTER JOIN sys.server_principals AS members
         ON server_role_members.member_principal_id = members.principal_id;

C. Lista wszystkich podmiotów bazy danych, które są członkami roli na poziomie bazy danych

Aby zwrócić członków ról baz danych (SQL Server i SQL Database), wykonaj następującą instrukcję w bazie danych.

SELECT dRole.name AS [Database Role Name],
       dp.name AS [Members]
FROM sys.database_role_members AS dRo
     INNER JOIN sys.database_principals AS dp
         ON dRo.member_principal_id = dp.principal_id
     INNER JOIN sys.database_principals AS dRole
         ON dRo.role_principal_id = dRole.principal_id;

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-11-18