Konfigurowanie zabezpieczeń dla wysyłania dzienników SQL Server

Artykuł
06/20/2023

W tym artykule opisano sposób konfigurowania zabezpieczeń dla SQL Server wysyłania dzienników i przedstawiono informacje o problemie, który może wystąpić podczas konfigurowania zabezpieczeń dla SQL Server wysyłania dzienników.

Oryginalna wersja produktu: SQL Server
Oryginalny numer KB: 321247

Podsumowanie

Ten artykuł zawiera informacje o sposobie konfigurowania zabezpieczeń na potrzeby wysyłania dzienników. Istnieje kilka problemów, które należy wziąć pod uwagę podczas konfigurowania zabezpieczeń dla SQL Server wysyłania dzienników, które wahają się od konta uruchamiania, aby SQL Server do udostępniania uprawnień do udziału sieciowego, w którym znajdują się kopie zapasowe dziennika transakcji. Te problemy zostały opisane w tym artykule.

Konto domeny

W przypadku umieszczenia SQL Server w domenie firma Microsoft zaleca użycie konta domeny do uruchamiania usług SQL Server. Jeśli zamierzasz skonfigurować SQL Server do uruchamiania jako serwer wirtualny w klastrze systemu Windows, należy użyć konta domeny. Konto domeny zapewnia korzyści z minimalnej konserwacji w przypadku zmiany hasła. Może jednak nie być możliwe uruchomienie programu SQL na koncie domeny, jeśli SQL Server znajduje się na serwerze znajdującym się w grupie roboczej.

Konto sieci lokalnej

Można użyć SQL Server, aby rozpocząć w ramach lokalnie utworzonego konta sieciowego. W sytuacji, gdy dostęp do sieci jest wymagany przez proces SQL Server, tak jest w przypadku skonfigurowania SQL Server do korzystania z wysyłania dzienników, można użyć zabezpieczeń przekazywania sieci. W przypadku zabezpieczeń przekazywania wszystkie maszyny, do których będą uzyskiwane dostęp SQL Server, muszą mieć to samo konto sieciowe z tym samym hasłem i odpowiednimi uprawnieniami skonfigurowane lokalnie. Ponadto, gdy proces SQL Server żąda zasobów z drugiego komputera, tradycyjne zabezpieczenia sieci są pomijane, jeśli to samo konto (w ramach którego jest uruchomiona żądana usługa SQL Server) istnieje z tym samym hasłem. Jeśli konto na drugim komputerze jest skonfigurowane z wystarczającym uprawnieniem do wykonania zadania wymaganego przez wywołanie SQL Server, zadanie zakończy się pomyślnie.

Konto systemu lokalnego

Możesz również skonfigurować SQL Server uruchamiania w ramach konta systemu lokalnego. Modyfikowanie hasła dla konta LocalSystem może spowodować awarię niektórych usług, które mają kluczowe znaczenie dla stabilności systemu. To konto jest lokalne dla komputera, na którym się znajduje, co oznacza, że kontekst zabezpieczeń używany przez usługi SQL Server jest lokalny. Jak określono w sekcji Konto sieci lokalnej, nie można używać zabezpieczeń przekazywania sieci po uruchomieniu SQL Server w ramach konta LocalSystem, ponieważ hasła dla konta LocalSystem na różnych komputerach są różne. Uruchomienie SQL Server na tym koncie, gdy wymagany jest dostęp do zasobów sieciowych, najprawdopodobniej spowoduje niepowodzenie wykonania zadań.

Aby uzyskać informacje o minimalnych wymaganych prawach konta sieciowego do pomyślnego uruchamiania i uruchamiania usług SQL Server i SQL Server Agent, zobacz Konfigurowanie kont usług systemu Windows.

Omówienie modelu zabezpieczeń SQL Server

Aby całkowicie zrozumieć konsekwencje dla bezpieczeństwa, należy zrozumieć model zabezpieczeń zaimplementowany przez firmę Microsoft w SQL Server 2000 r. Podczas tworzenia identyfikatora logowania jest on dodawany syslogins do tabeli w bazie danych MASTER. Dla każdej bazy danych, do których ten nowo dodany identyfikator logowania ma dostęp, jest dodawana do sysusers tabeli w tej bazie danych. Mapowanie między tabelą syslogins a sysusers tabelą znajduje się w polu IDENTYFIKATOR SID.

Jeśli baza danych użytkownika zostanie przeniesiona na inny serwer, wartości identyfikatora SID zostaną przeniesione z poprzedniego serwera. Zabezpieczenia bazy danych są przerywane, gdy nazwy logowania na drugim serwerze nie są tworzone z tymi samymi wartościami identyfikatora SID lub jeśli zabezpieczenia są nieprawidłowo skonfigurowane z powodu niezgodności wartości identyfikatora SID.

Aby uzyskać więcej informacji, zobacz Jak rozwiązać problemy z uprawnieniami podczas przenoszenia bazy danych między serwerami, na których działa SQL Server.

Wymagania dotyczące zabezpieczeń

Udział kopii zapasowych

Skonfiguruj udział sieciowy skonfigurowany do przechowywania kopii zapasowych dziennika transakcji, aby mieć uprawnienia do odczytu/zmiany dla konta, w ramach którego są uruchamiane usługi SQL Server (na serwerze pomocniczym skonfigurowanym do wysyłania dzienników).

Udział sieciowy skonfigurowany do przechowywania kopii zapasowych dziennika transakcji powinien być skonfigurowany tak, aby miał uprawnienia do odczytu/zmiany dla konta, na którym są uruchamiane usługi SQL Server na serwerze pomocniczym skonfigurowanym do wysyłania dzienników. Dostęp do tego udziału uzyskuje zadanie kopiowania na serwerze pomocniczym w celu skopiowania kopii zapasowych dziennika transakcji do folderu lokalnego na odpowiednim serwerze pomocniczym. Zadanie Załaduj następnie ładuje te kopie zapasowe z folderu lokalnego.
Wysyłka dziennika między domenami

Jeśli komputery z systemem SQL Server są umieszczane w środowisku z wieloma domenami, firma Microsoft zaleca skonfigurowanie dwukierunkowych relacji zaufania między wszystkimi domenami, które biorą udział w wysyłaniu dzienników. Jeśli jednak nie możesz ustanowić relacji zaufania między domenami, możesz użyć zabezpieczeń przekazywania sieci do wysyłania dzienników. Zapoznaj się z sekcją tego artykułu, w którym omówiono opcję uruchamiania konta sieciowego systemu lokalnego dla usług związanych z SQL Server.
Wybieranie trybu uwierzytelniania w celu nawiązania połączenia z serwerem monitorowania

Możesz wybrać uwierzytelnianie systemu Windows lub uwierzytelnianie SQL (przez serwery podstawowe i pomocnicze), aby nawiązać połączenie w celu monitorowania serwera i zaktualizowania tabel monitora. Możesz wybrać tę opcję podczas konfigurowania wysyłki dziennika lub po skonfigurowaniu wysyłki dziennika i jest ona funkcjonalna. Domyślnie SQL Server używa uwierzytelniania systemu Windows, jednak jeśli wybierzesz uwierzytelnianie SQL, zostanie utworzony nowy log_shipping_monitor_probe logowania SQL na serwerach podstawowych, pomocniczych i monitora, jeśli nie istnieje. Jeśli w tym celu wybierzesz opcję Uwierzytelnianie SQL, skonfiguruj SQL Server do korzystania z opcji uwierzytelniania SQL i Windows.

Konfiguracja zabezpieczeń na serwerze pomocniczym dla baz danych rezerwowych

Jeśli skonfigurujesz pomocniczą bazę danych w trybie wstrzymania, możesz uzyskać dostęp do tej bazy danych w stanie tylko do odczytu. Przywracanie pomocniczej bazy danych w tym trybie może zapewnić sposób uruchamiania raportów w trybie offline, a tym samym odciążanie części pracy z systemu produkcyjnego. Jednak aby baza danych rezerwowej obsługiwała funkcje tylko do odczytu, może być konieczne zastosowanie tych samych ustawień zabezpieczeń na serwerze pomocniczym. Ponieważ baza danych jest w stanie wstrzymania, nie można nawet wprowadzać żadnych modyfikacji w celu skonfigurowania zabezpieczeń. W takim przypadku należy utworzyć wszystkie SQL Server identyfikatory logowania z tymi samymi wartościami identyfikatora SID na serwerze pomocniczym. Identyfikatory logowania systemu Windows automatycznie zachowują te same identyfikatory SID, ponieważ identyfikator GUID systemu Windows jest unikatowy globalnie, nawet w przypadku korzystania z wielu domen.

Aby uzyskać więcej informacji na temat tworzenia identyfikatorów logowania SQL przy użyciu tego samego identyfikatora SID na różnych serwerach, zobacz Jak udzielić dostępu do identyfikatorów logowania SQL w bazie danych rezerwowej, gdy gość jest wyłączony w SQL Server.

Konfiguracja zabezpieczeń podczas zmiany roli

Procedura zmiany roli dla wysyłania dzienników obejmuje promowanie serwera pomocniczego w celu przejęcia roli podstawowej. Można to zrobić z serwerem podstawowym lub bez serwera podstawowego w trybie online. W ramach zmiany roli są wykonywane maksymalnie cztery procedury składowane. Jedna z tych procedur składowanych , sp_resolve_logins pomaga poprawić wartości identyfikatorów SID dla identyfikatorów logowania, które znajdują się w bazie danych rezerwowej tuż przed udostępnieniem jej do użycia jako podstawowa baza danych.

W ramach tej procedury .bcp składowanej plik syslogins tabeli z poprzedniego serwera podstawowego jest ładowany do tabeli tymczasowej. Każdy identyfikator logowania, który znajduje się w tej tabeli tymczasowej, jest następnie porównywany z tabelą syslogins w bazie danych MASTER serwera pomocniczego i tabelą sysusers pomocniczej bazy danych. Dla każdego identyfikatora logowania w tabeli tymczasowej, który ma nazwę logowania o tej samej nazwie w syslogins tabeli i ten sam identyfikator SID co ten w sysusers tabeli pomocniczej bazy danych, identyfikator SID jest korygowany (w pomocniczej bazie danych) przy użyciu sp_change_users_login , aby dopasować ten, który znajduje się w syslogins tabeli.

Konfiguracja zabezpieczeń korzystająca z tej procedury składowanej wymaga następujących elementów:

Identyfikatory logowania SQL muszą już zostać utworzone na serwerze pomocniczym. W tym celu użyj zadania DTS Transfer Logins (Transfer Logins DTS), które zostało wyjaśnione w temacie SQL Server Books Online: How to set up and perform log shipping role change (Jak skonfigurować i wykonać zmianę roli wysyłki dziennika).
Należy podać .bcp plik syslogins tabeli z serwera podstawowego. Ten plik musi być bieżący, ponieważ nieaktualny plik może spowodować sp_resolve_logins , że nie można naprawić nazw logowania.

Przed faktycznym naprawieniem sp_resolve_logins identyfikatorów logowania w pomocniczej bazie danych należy spełnić następujące trzy warunki:

Nazwa logowania z pliku syslogins tabeli musi być zgodna z .bcp nazwą syslogins w tabeli z serwera podstawowego.
Wartość identyfikatora SID musi być zgodna między plikiem .bcp logowania a tabelą sysusers w pomocniczej bazie danych.
Wartość identyfikatora SID z pomocniczej bazy danych musi być inna niż wartość identyfikatora SID w syslogins tabeli w bazie danych MASTER na serwerze pomocniczym.

Jeśli utworzysz SQL Server identyfikatory logowania zgodnie z opisem w Q303722, nie trzeba uruchamiać tej procedury składowanej, ponieważ wszystkie identyfikatory logowania zostały już przedstawione z tą samą wartością identyfikatora SID w syslogins tabeli (w bazie danych MASTER na serwerze pomocniczym) i sysusers w tabeli (w pomocniczej bazie danych).

Często zadawane pytania

Pytanie: Czy wysyłka dziennika automatycznie propaguje zmiany związane z zabezpieczeniami na serwerze pomocniczym?

Odpowiedź: Tak. Ponieważ wszystkie zmiany w tabelach systemowych są rejestrowane operacje, są one propagowane przez serwer pomocniczy (lub serwery) automatycznie.
Pytanie: Czy możesz mieć dwa identyfikatory logowania na serwerze pomocniczym z tym samym identyfikatorem SID? Potrzebuję tego, ponieważ używam tego samego komputera SQL Server do obsługi wielu baz danych rezerwowych z wielu serwerów.

Odpowiedź: Nie. SQL Server model zabezpieczeń nie zezwala na posiadanie dwóch identyfikatorów logowania z tym samym identyfikatorem SID. Jeśli podczas korzystania z wysyłania dzienników z wieloma serwerami występuje konflikt na identyfikatorze SID, jedynym sposobem naprawienia tego błędu jest usunięcie powodującego konflikt logowania na serwerze podstawowym, a następnie utworzenie go przy użyciu identyfikatora SID, który nie istnieje na serwerze pomocniczym.