Udostępnij za pośrednictwem

Konfiguracja zabezpieczeń usługi Azure SQL Database i zarządzanie nimi pod kątem przywracania lub trybu failover obszaru geograficznego

  • Artykuł

Dotyczy: Azure SQL Database

W tym artykule opisano wymagania uwierzytelniania dotyczące konfigurowania i kontrolowania aktywnej replikacji geograficznej i grup trybu failover. Zawiera on również kroki wymagane do skonfigurowania dostępu użytkownika do pomocniczej bazy danych. Na koniec opisano również sposób włączania dostępu do odzyskanej bazy danych po użyciu przywracania geograficznego. Aby uzyskać więcej informacji na temat opcji odzyskiwania, zobacz Omówienie ciągłości działania.

Odzyskiwanie po awarii z zawartymi użytkownikami

W przeciwieństwie do tradycyjnych użytkowników, które muszą być mapowane na logowania w master bazie danych, zawarty użytkownik jest zarządzany całkowicie przez samą bazę danych. Ma to dwie korzyści. W scenariuszu odzyskiwania po awarii użytkownicy mogą nadal łączyć się z nową podstawową bazą danych lub bazą danych odzyskaną przy użyciu przywracania geograficznego bez dodatkowej konfiguracji, ponieważ baza danych zarządza użytkownikami. Istnieje również potencjalne korzyści ze skalowalności i wydajności z tej konfiguracji z perspektywy logowania. Aby uzyskać więcej informacji, zobacz artykuł Contained Database Users - Making Your Database Portable (Użytkownicy zawartej bazy danych — tworzenie przenośnej bazy danych).

Głównym kompromisem jest to, że zarządzanie procesem odzyskiwania po awarii na dużą skalę jest trudniejsze. Jeśli masz wiele baz danych korzystających z tego samego identyfikatora logowania, utrzymywanie poświadczeń przy użyciu zawartych użytkowników w wielu bazach danych może negować zalety zawartych użytkowników. Na przykład zasady rotacji haseł wymagają spójnego wprowadzania zmian w wielu bazach danych, a nie zmiany hasła logowania raz w master bazie danych. Z tego powodu, jeśli masz wiele baz danych, które używają tej samej nazwy użytkownika i hasła, nie zaleca się używania zawartych użytkowników.

Jak skonfigurować identyfikatory logowania i użytkowników

Jeśli używasz identyfikatorów logowania i użytkowników (a nie zawartych użytkowników), musisz wykonać dodatkowe kroki, aby upewnić się, że te same identyfikatory logowania istnieją w master bazie danych. W poniższych sekcjach opisano kroki i dodatkowe zagadnienia.

Uwaga

Do zarządzania bazami danych można również użyć identyfikatorów logowania utworzonych na podstawie identyfikatora Entra firmy Microsoft (wcześniej usługi Azure Active Directory). Aby uzyskać więcej informacji, zobacz Identyfikatory logowania i użytkownicy usługi Azure SQL.

Konfigurowanie dostępu użytkownika do pomocniczej lub odzyskanej bazy danych

Aby pomocnicza baza danych mogła być używana jako pomocnicza baza danych tylko do odczytu, oraz aby zapewnić odpowiedni dostęp do nowej podstawowej bazy danych lub bazy danych odzyskanej przy użyciu przywracania geograficznego, master baza danych serwera docelowego musi mieć odpowiednią konfigurację zabezpieczeń przed odzyskiwaniem.

Konkretne uprawnienia dla każdego kroku opisano w dalszej części tego tematu.

Przygotowanie dostępu użytkownika do pomocniczej replikacji geograficznej należy wykonać w ramach konfigurowania replikacji geograficznej. Przygotowanie dostępu użytkownika do przywróconych geograficznie baz danych powinno być wykonywane w dowolnym momencie, gdy oryginalny serwer jest w trybie online (np. w ramach testowania odzyskiwania po awarii).

Uwaga

Jeśli przełączysz się w tryb failover lub przywracanie geograficzne na serwer, który nie ma prawidłowo skonfigurowanych logowań, dostęp do niego będzie ograniczony do konta administratora serwera.

Konfigurowanie identyfikatorów logowania na serwerze docelowym obejmuje trzy kroki opisane poniżej:

1. Określanie identyfikatorów logowania z dostępem do podstawowej bazy danych

Pierwszym krokiem procesu jest ustalenie, które identyfikatory logowania muszą zostać zduplikowane na serwerze docelowym. Jest to realizowane za pomocą pary instrukcji SELECT, jednej w logicznej master bazie danych na serwerze źródłowym i jednej w podstawowej bazie danych.

Tylko administrator serwera lub członek roli serwera LoginManager może określić identyfikatory logowania na serwerze źródłowym za pomocą następującej instrukcji SELECT.

SELECT [name], [sid]
FROM [sys].[sql_logins]
WHERE [type_desc] = 'SQL_Login'

Tylko członek roli bazy danych db_owner, użytkownik dbo lub administrator serwera, może określić wszystkie podmioty zabezpieczeń użytkowników bazy danych w podstawowej bazie danych.

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

2. Znajdź identyfikator SID dla identyfikatorów logowania zidentyfikowanych w kroku 1

Porównując dane wyjściowe zapytań z poprzedniej sekcji i pasując do identyfikatorów SID, można mapować identyfikator logowania serwera do użytkownika bazy danych. Identyfikatory logowania, które mają użytkownika bazy danych z pasującym identyfikatorem SID, mają dostęp użytkownika do tej bazy danych jako podmiotu zabezpieczeń użytkownika bazy danych.

Poniższe zapytanie może służyć do wyświetlenia wszystkich podmiotów zabezpieczeń użytkownika i ich identyfikatorów SID w bazie danych. To zapytanie może uruchomić tylko członek roli bazy danych db_owner lub administratora serwera.

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

Uwaga

Użytkownicy systemu i INFORMATION_SCHEMA mają identyfikatory SID o wartości NULL, a identyfikator SID gościa jest 0x00. Identyfikator SID dbo może zaczynać się od 0x01060000000001648000000000048454, jeśli twórca bazy danych był administratorem serwera zamiast członkiem DbManager.

3. Tworzenie identyfikatorów logowania na serwerze docelowym

Ostatnim krokiem jest przejście do serwera docelowego (lub serwerów docelowych) i wygenerowanie identyfikatorów logowania przy użyciu odpowiednich identyfikatorów SID. Podstawowa składnia jest następująca.

CREATE LOGIN [<login name>]
WITH PASSWORD = '<login password>',
SID = 0x1234 /*replace 0x1234 with the desired login SID*/

Na serwerze docelowym nie należy tworzyć nowego identyfikatora logowania przy użyciu identyfikatora SID administratora serwera ze źródła. Zamiast tego wprowadź nazwę główną bazy danych administratora serwera docelowego w bazie danych, na przykład db_owner lub użytkownika.

Uwaga

Jeśli chcesz udzielić użytkownikowi dostępu do pomocniczej, ale nie podstawowej, możesz to zrobić, zmieniając identyfikator logowania użytkownika na serwerze podstawowym przy użyciu następującej składni.

ALTER LOGIN [<login name>] DISABLE

Funkcja DISABLE nie zmienia hasła, więc zawsze można ją włączyć w razie potrzeby.

Następne kroki