Udostępnij za pomocą

Implementowanie zabezpieczeń agenta programu SQL Server

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 lub ograniczenia zadań agenta SQL w usłudze SQL Managed Instance.

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 msdb bazie danych. 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 Windows Server, mogą zgłaszać alerty za pośrednictwem agenta programu SQL Server.

  • Nie należy określać konta administratora systemu Windows Server 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 w przypadku rejestracji środowiska wieloserwerowego z serwerem MSX (serwer główny) administrator systemu MSX uzyskuje całkowitą kontrolę nad wystąpieniem TSX programu SQL Server.

  • ACE jest rozszerzeniem i nie może wywołać samego siebie. Usługa Chainer ScenarioEngine.exe (znana również jako Microsoft.SqlServer.Chainer.Setup.exe) może wywołać ACE. Również inne procesy hosta mogą 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 weryfikacje sco dla kont wirtualnych

    • Klaster - 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 co to jest usługa 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 na identyfikator 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 administratorem systemu 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.

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ść

  • Last updated on