Udostępnij za pośrednictwem

Implementowanie zabezpieczeń agenta programu SQL Server

  • Artykuł

Dotyczy:programu SQL ServerAzure SQL Managed Instance

Ważny

W Azure SQL Managed Instanceobecnie obsługiwana jest większość, ale nie wszystkie funkcje agenta SQL Server. Aby uzyskać szczegółowe informacje, zobacz Różnice języka T-SQL usługi Azure SQL Managed Instance z programu SQL Server.

Agent SQL Server umożliwia administratorowi bazy danych uruchomienie każdego kroku zadania w kontekście zabezpieczeń, mającym jedynie uprawnienia wymagane do wykonania tego kroku, co jest określane przez serwer proxy Agenta SQL Server. Aby ustawić uprawnienia dla określonego kroku zadania, należy utworzyć serwer proxy, który ma wymagane uprawnienia, a następnie przypisać ten serwer proxy do kroku zadania. Pełnomocnika można przypisać do więcej niż jednego kroku zadania. W przypadku kroków zadania, które wymagają takich samych uprawnień, używa się tego samego serwera proxy.

W poniższej sekcji wyjaśniono, jaką rolę bazy danych należy przyznać użytkownikom, aby mogli tworzyć lub wykonywać zadania przy użyciu agenta programu SQL Server.

Udzielanie dostępu do agenta programu SQL Server

Aby można było używać programu SQL Server Agent, użytkownicy muszą należeć do co najmniej jednej z następujących stałych ról bazy danych:

  • SQLAgentUserRole

  • SQLAgentReaderRole

  • SQLAgentOperatorRole

Te role są przechowywane w bazie danych msdb. Domyślnie żaden użytkownik nie jest członkiem tych ról bazy danych. Członkostwo w tych rolach musi być przyznane jawnie. Użytkownicy, którzy są członkami sysadmin stałej roli serwera, mają pełny dostęp do agenta programu SQL Server i nie muszą być członkami tych stałych ról bazy danych do korzystania z programu SQL Server Agent. Jeśli użytkownik nie jest członkiem jednej z tych ról bazy danych lub roli sysadmin, węzeł agenta programu SQL Server nie jest dostępny podczas nawiązywania połączenia z programem SQL Server przy użyciu programu SQL Server Management Studio.

Członkowie tych ról w bazie danych mogą wyświetlać i wykonywać zadania, których są właścicielami, oraz tworzyć kroki zadań, które są uruchamiane jako istniejące konto proxy. Aby uzyskać więcej informacji na temat określonych uprawnień skojarzonych z każdą z tych ról, zobacz stałe role bazy danych agenta programu SQL Server.

Członkowie sysadmin stałej roli serwera mają uprawnienia do tworzenia, modyfikowania i usuwania kont proxy. Członkowie roli sysadmin mają uprawnienia do tworzenia kroków zadań, które nie określają serwera proxy, ale zamiast tego są uruchamiane jako konto usługi agenta programu SQL Server, czyli konto używane do uruchamiania agenta programu SQL Server.

Wytyczne

Postępuj zgodnie z poniższymi wytycznymi, aby zwiększyć bezpieczeństwo implementacji agenta programu SQL Server:

  • Utwórz dedykowane konta użytkowników przeznaczone specjalnie dla serwerów proxy i użyj tylko tych kont użytkowników proxy do wykonywania kroków zadań.

  • Przyznaj tylko niezbędne uprawnienia do kont użytkowników serwera proxy. Przyznaj tylko te uprawnienia wymagane do uruchomienia kroków zadania przypisanych do danego konta serwera proxy.

  • Nie uruchamiaj usługi SQL Server Agent w ramach konta systemu Microsoft Windows, które jest członkiem grupy administratorzy systemu Windows .

  • Serwery proxy są bezpieczne tylko jako magazyn poświadczeń programu SQL Server.

  • Jeśli operacje zapisu użytkownika mogą zapisywać w dzienniku zdarzeń systemu NT, mogą zgłaszać alerty za pomocą agenta SQL Server.

  • Nie należy określać konta administratora NT jako konta usługi lub konta serwera proxy.

  • Program SQL Server i program SQL Server Agent mają dostęp do zasobów siebie. Obie usługi współdzielą jedną przestrzeń procesową, i program SQL Server Agent jest administratorem systemu w usłudze SQL Server.

  • Gdy TSX (serwer docelowy) dołącza do serwera MSX (serwer główny), administratorzy systemu MSX uzyskują całkowitą kontrolę nad instancją serwera SQL TSX.

  • ACE jest rozszerzeniem i nie może wywołać samego siebie. Chainer ScenarioEngine.exe (znana również jako Microsoft.SqlServer.Chainer.Setup.exe) może wywołać ACE. Inne procesy hosta mogą również wywoływać ACE.

  • ACE jest zależny od następujących bibliotek DLL konfiguracji należących do SSDP, ponieważ te interfejsy API z bibliotek DLL są wywoływane przez ACE.

    • SCO – Microsoft.SqlServer.Configuration.Sco.dll, w tym nowe walidacje SCO dla kont wirtualnych

    • Cluster – Microsoft.SqlServer.Configuration.Cluster.dll

    • SFC — Microsoft.SqlServer.Configuration.SqlConfigBase.dll

    • rozszerzenie - Microsoft.SqlServer.Configuration.ConfigExtension.dll

Połączone serwery

W niektórych scenariuszach, takich jak w przypadku usługi Azure SQL Managed Instance, aby uruchomić zadanie agenta SQL, które wykonuje zapytanie Transact-SQL (T-SQL) na serwerze zdalnym za pośrednictwem serwera połączonego, należy zamapować lokalne logowanie do logowania na serwerze zdalnym.

Użyj sp_addlinkedsrvlogin, aby utworzyć mapowanie między logowaniem na serwerze lokalnym do logowania na serwerze zdalnym, który ma uprawnienia niezbędne do wykonania zapytania T-SQL. Gdy zadanie agenta SQL łączy się z serwerem zdalnym za pośrednictwem połączonego serwera, wykonuje zapytanie T-SQL w kontekście zdalnego logowania.

W poniższej tabeli opisano sposób mapowania logowania na podstawie właściciela zadania agenta SQL w usłudze Azure SQL Managed Instance:

Właściciel zadania agenta SQL Jak mapować logowanie
Użytkownik, który nie jest sysadminem Przypisz lokalnego użytkownika , który jest właścicielem zadania agenta SQL, do zdalnego loginu.
administrator systemu Mapuj wszystkich użytkowników lokalnych na zdalne logowanie, ustawiając parametr @locallogin na wartość NULL.

Notatka

Tworzenie identyfikatorów logowania na serwerze zdalnym dla zadań agenta SQL jest wymagane, gdy serwer lokalny jest usługą Azure SQL Managed Instance. Nieprawidłowe mapowanie użytkowników może spowodować błędy, takie jak następujące przykłady:

  • Windows logins are not supported in this version of SQL Server
  • Linked servers cannot be used under impersonation without a mapping for the impersonated login

Powiązana zawartość