Opis podmiotów zabezpieczeń

• 14 min

Podmioty zabezpieczeń to jednostki, które mogą żądać SQL Server zasobów i do których można (zwykle) udzielić uprawnień. Istnieje kilka zestawów podmiotów zabezpieczeń w SQL Server. Podmioty zabezpieczeń istnieją na poziomie serwera lub na poziomie bazy danych i mogą być osobami fizycznymi lub kolekcjami. Niektóre zestawy mają członkostwo kontrolowane przez administratorów SQL Server, a niektóre mają stałe członkostwo.

Na poziomie bazy danych przyjrzymy się użytkownikom, rolam bazy danych, rolam aplikacji.

Schematy i zabezpieczane

Zanim przyjrzymy się szczegółom podmiotów zabezpieczeń, musimy zrozumieć koncepcje zabezpieczania i schematów. SQL Server i Azure SQL Database mają trzy zakresy zabezpieczania. Zabezpieczane są zasobami w bazie danych, do których system autoryzacji zarządza dostępem. Na przykład tabela jest zabezpieczana. Aby uprościć kontrolę dostępu, SQL Server zawiera zabezpieczenia w zagnieżdżonych hierarchiach nazywanych zakresami. Trzy zabezpieczane zakresy to serwer, baza danych i schemat. Schemat to kolekcja obiektów w bazie danych, która umożliwia grupowanie obiektów w oddzielnych przestrzeniach nazw.

Każdy użytkownik ma schemat domyślny. Jeśli użytkownik próbuje uzyskać dostęp do obiektu bez określenia nazwy schematu, tak jak w: SELECT name FROM customers, zakłada się, że obiekt znajduje się w domyślnym schemacie użytkownika. Jeśli w schemacie domyślnym nie ma takiego obiektu, SQL Server sprawdzi, czy obiekt znajduje się w wstępnie zdefiniowanym schemacie dbo. Jeśli nie ma obiektu określonej nazwy w domyślnym schemacie użytkownika lub w schemacie dbo, użytkownik otrzyma komunikat o błędzie. Najlepszym rozwiązaniem jest zawsze określenie nazwy schematu podczas uzyskiwania dostępu do obiektów, więc poprzednie zaznaczenie będzie wyglądać następująco: SELECT name FROM SalesSchema.customers. Jeśli użytkownik nie otrzymał domyślnego schematu, jego domyślny schemat jest ustawiony na dbo.

Domyślnie, jeśli żaden schemat nie zostanie określony podczas tworzenia obiektu przez użytkownika, SQL Server podejmie próbę utworzenia go w domyślnym schemacie użytkownika. Jeśli użytkownik nie otrzymał uprawnień do tworzenia obiektów w domyślnym schemacie, nie można utworzyć obiektu.

Nazwy logowania i użytkownicy

Niezależnie od używanego trybu uwierzytelniania nazwa logowania używana do uzyskiwania dostępu do bazy danych SQL jest skonfigurowana jako identyfikator logowania w wystąpieniu. Te identyfikatory logowania są konfigurowane na poziomie wystąpienia SQL Server i przechowywane w bazie danych master. Można jednak skonfigurować zawartych użytkowników, którzy są dodawani na poziomie bazy danych. Tych użytkowników można skonfigurować jako użytkowników uwierzytelniania SQL Server, a także użytkowników uwierzytelniania systemu Windows lub użytkowników usługi Azure Active Directory (w zależności od używanej platformy). Aby utworzyć tych użytkowników, baza danych musi być skonfigurowana pod kątem częściowego zawierania, który jest domyślnie skonfigurowany w usłudze Azure SQL Database i opcjonalnie konfigurowalny w SQL Server.

Ci użytkownicy mają dostęp tylko do bazy danych skonfigurowanej przez użytkownika. Dla celów Azure SQL Database jest to najlepsze rozwiązanie do tworzenia użytkowników w zakresie bazy danych użytkowników, a nie w bazie danych master, jak pokazano poniżej.

CREATE USER [dba@contoso.com] FROM EXTERNAL PROVIDER;
GO

Instrukcja CREATE USER jest wykonywana w kontekście bazy danych użytkownika. W powyższym przykładzie użytkownik jest użytkownikiem usługi Azure Active Directory, zgodnie ze składnią FROM EXTERNAL PROVIDER .

Jeśli identyfikatory logowania są tworzone na poziomie wystąpienia w SQL Server, użytkownik powinien zostać utworzony w bazie danych, która mapuje użytkownika na logowanie oparte na serwerze, jak pokazano w poniższym przykładzie.

USE [master]
GO

CREATE LOGIN demo WITH PASSWORD = 'Pa55.w.rd'
GO

USE [WideWorldImporters]
GO

CREATE USER demo FROM LOGIN demo
GO

Identyfikator logowania jest najpierw tworzony w bazie danych master, a następnie w bazie danych WideWorldImporters tworzony jest użytkownik do mapowania na tego użytkownika. Identyfikatory logowania są używane do uzyskiwania dostępu do SQL Server lub bazy danych Azure SQL, ale aby wykonać dowolną pracę w bazie danych, identyfikator logowania musi zostać zamapowany na nazwę użytkownika. Nazwa użytkownika jest używana do całego uwierzytelniania.

Identyfikatory logowania i nazwy użytkownika są najważniejszymi podmiotami zabezpieczeń, o których musisz pamiętać, ale w następnych sekcjach opisano niektóre z innych pojęć i terminów podczas czynienia z autoryzacją.

Role bazy danych

Jak można sobie wyobrazić, zabezpieczenia bazy danych mogą być skomplikowane dla aplikacji z wieloma użytkownikami. Aby ułatwić zarówno administratorom, jak i audytorom, większość aplikacji baz danych korzysta z zabezpieczeń opartych na rolach. Role są skutecznie grupami zabezpieczeń, które współdzielą wspólny zestaw uprawnień. Łączenie uprawnień z rolą umożliwia utworzenie zestawu ról dla danej aplikacji. Niektóre przykłady ról to administratorzy, którzy mieli pełny dostęp do wszystkich baz danych i serwerów, raportowania użytkowników, którzy tylko odczytują bazę danych, oraz konta aplikacji, które miały dostęp do zapisu danych w bazie danych. Role można zdefiniować, gdy aplikacja jest zaprojektowana, a następnie użytkownicy mogą być przypisywani do tych ról, ponieważ potrzebują dostępu do bazy danych. Kontrola dostępu oparta na rolach jest wspólną architekturą w systemach komputerowych i sposobem zarządzania autoryzacją w usłudze Azure Resource Manager.

SQL Server i Azure SQL Database obejmują wbudowane role zdefiniowane przez firmę Microsoft, a także opcję tworzenia ról niestandardowych. Role niestandardowe można tworzyć na poziomie serwera lub bazy danych. Jednak role serwera nie mogą mieć bezpośredniego dostępu do obiektów w bazie danych. Role serwera są dostępne tylko w SQL Server i Azure SQL Managed Instance, a nie w usłudze Azure SQL Database.

W bazie danych można udzielić uprawnień użytkownikom, którzy istnieją w bazie danych. Jeśli wszyscy użytkownicy potrzebują tych samych uprawnień, możesz utworzyć rolę bazy danych w bazie danych i udzielić wymaganych uprawnień do tej roli. Użytkownicy mogą być dodawani jako członkowie roli bazy danych. Członkowie roli bazy danych dziedziczą uprawnienia roli bazy danych.

CREATE USER [DP300User1] WITH PASSWORD = 'Pa55.w.rd'
GO

CREATE USER [DP300User2] WITH PASSWORD = 'Pa55.w.rd'
GO

CREATE ROLE [SalesReader]
GO

ALTER ROLE [SalesReader] ADD MEMBER [DP300User1]
GO

ALTER ROLE [SalesReader] ADD MEMBER [DP300User2]
GO

GRANT SELECT, EXECUTE ON SCHEMA::Sales TO [SalesReader]
GO

W powyższym przykładzie widać, że dwóch użytkowników zostało utworzonych, a następnie utworzono rolę o nazwie SalesReader. Dwóch nowych użytkowników zostanie dodanych do nowo utworzonej roli, a następnie na koniec zostanie udzielona SELECT rola i EXECUTE uprawnienia do schematu Sprzedaż . Każdy użytkownik, który jest w tej roli, może wybrać dowolny obiekt w schemacie Sales i wykonać dowolną procedurę składowaną w schemacie.

Role aplikacji

Role aplikacji można również tworzyć w bazie danych SQL Server lub w bazie danych Azure SQL. W przeciwieństwie do ról bazy danych użytkownicy nie są członkami roli aplikacji. Rola aplikacji jest aktywowana przez użytkownika, podając wstępnie skonfigurowane hasło dla roli aplikacji. Po aktywowaniu roli uprawnienia stosowane do roli aplikacji zostaną zastosowane do użytkownika do momentu dezaktywowania tej roli.

Wbudowane role bazy danych

Microsoft SQL Server zawiera kilka stałych ról bazy danych w każdej bazie danych, dla których uprawnienia są wstępnie zdefiniowane. Użytkownicy mogą być dodawani jako członkowie co najmniej jednej roli. Te role zapewniają członkom wstępnie zdefiniowany zestaw uprawnień. Te role działają tak samo w Azure SQL Database i SQL Server.

Wszyscy użytkownicy w bazie danych są automatycznie członkami public roli. Domyślnie ta rola nie ma uprawnień przyznanych. Uprawnienia można przyznać roli publicznej, ale należy dokładnie rozważyć, czy jest to naprawdę coś, co chcesz zrobić. Przyznanie uprawnień do roli publicznej spowoduje przyznanie tych uprawnień każdemu użytkownikowi, w tym kontu gościa, jeśli konto gościa zostało włączone.

Wbudowane role bazy danych spełniają potrzeby wielu aplikacji; jednak w przypadku aplikacji, które wymagają bardziej szczegółowych zabezpieczeń (na przykład gdy chcesz udzielić dostępu tylko do określonego podzestawu tabel), rola niestandardowa jest często lepszym wyborem.

Azure SQL Baza danych ma dwie role zdefiniowane w bazie danych master serwera Azure SQL.

Naprawiono role serwera

Oprócz ról bazy danych SQL Server i Azure SQL Managed Instance zapewniają kilka stałych ról serwera. Te role przypisują uprawnienia w zakresie całego serwera. Podmioty zabezpieczeń na poziomie serwera, które obejmują identyfikatory logowania SQL Server, konta systemu Windows i grupę systemu Windows, można dodać do stałych ról serwera. Uprawnienia dla stałych ról serwera są wstępnie zdefiniowane i nie można dodać żadnych nowych ról serwera. Stałe role serwera to: