Freigeben über

Implementieren der SQL Server-Agent-Sicherheit

  • Artikel

Gilt für:SQL Serverazure SQL Managed Instance

Wichtig

In azure SQL Managed Instancewerden die meisten, aber nicht alle SQL Server-Agent-Features derzeit unterstützt. Weitere Informationen finden Sie unter T-SQL-Unterschiede zwischen Azure SQL Managed Instance und SQL Server.

Der SQL Server-Agent ermöglicht es dem Datenbankadministrator, jeden Auftragsschritt in einem Sicherheitskontext auszuführen, der nur über die erforderlichen Berechtigungen zum Ausführen dieses Auftragsschritts verfügt, der von einem SQL Server-Agent-Proxy bestimmt wird. Um die Berechtigungen für einen bestimmten Auftragsschritt festzulegen, erstellen Sie einen Proxy, der über die erforderlichen Berechtigungen verfügt, und weisen diesen Proxy dann dem Auftragsschritt zu. Für mehrere Auftragsschritte kann ein Proxy angegeben werden. Für Auftragsschritte, die dieselben Berechtigungen erfordern, verwenden Sie denselben Proxy.

Im folgenden Abschnitt wird erläutert, welche Datenbankrolle Sie Benutzern erteilen müssen, damit sie Aufträge mithilfe des SQL Server-Agents erstellen oder ausführen können.

Gewähren des Zugriffs auf den SQL Server-Agent

Um DEN SQL Server-Agent zu verwenden, müssen Benutzer Mitglied einer oder mehrerer der folgenden festen Datenbankrollen sein:

  • SQLAgentUserRole-

  • SQLAgentReaderRole-

  • SQLAgentOperatorRole

Diese Rollen werden in der msdb--Datenbank gespeichert. Standardmäßig ist kein Benutzer Mitglied dieser Datenbankrollen. Die Mitgliedschaft in diesen Rollen muss explizit gewährt werden. Benutzer, die Mitglieder des sysadmin festen Serverrolle sind, haben vollzugriff auf DEN SQL Server-Agent und müssen kein Mitglied dieser festen Datenbankrollen sein, um SQL Server-Agent zu verwenden. Wenn ein Benutzer kein Mitglied einer dieser Datenbankrollen oder der sysadmin- Rolle ist, ist der SQL Server-Agent-Knoten nicht verfügbar, wenn er eine Verbindung mit SQL Server mithilfe von SQL Server Management Studio herstellt.

Mitglieder dieser Datenbankrollen können Aufträge anzeigen und ausführen, die sie besitzen, und Auftragsschritte erstellen, die als vorhandenes Proxykonto ausgeführt werden. Weitere Informationen zu den spezifischen Berechtigungen, die jeder dieser Rollen zugeordnet sind, finden Sie unter SQL Server Agent Fixed Database Roles.

Mitglieder des sysadmin festen Serverrolle verfügen über die Berechtigung zum Erstellen, Ändern und Löschen von Proxykonten. Mitglieder der sysadmin Rolle verfügen über die Berechtigung, Aufgabenschritte zu erstellen, die keinen Proxy angeben. Stattdessen werden sie als SQL Server-Agents-Dienstkonto ausgeführt, das zum Starten des SQL Server-Agents verwendet wird.

Leitlinien

Befolgen Sie die folgenden Richtlinien, um die Sicherheit Ihrer SQL Server-Agent-Implementierung zu verbessern:

  • Erstellen Sie dedizierte Benutzerkonten speziell für Proxys, und verwenden Sie diese Proxybenutzerkonten nur für die Ausführung von Auftragsschritten.

  • Erteilen Sie nur den erforderlichen Berechtigungen für Proxybenutzerkonten. Erteilen Sie nur diese Berechtigungen, die zum Ausführen der Auftragsschritte erforderlich sind, die einem bestimmten Proxykonto zugewiesen sind.

  • Führen Sie den SQL Server-Agent-Dienst nicht unter einem Microsoft Windows-Konto aus, das Mitglied der Windows -Administratorgruppe ist.

  • Proxys sind nur so sicher wie der SQL Server-Anmeldeinformationsspeicher.

  • Wenn Benutzerschreibvorgänge in das NT-Ereignisprotokoll schreiben können, können sie Warnungen über den SQL Server-Agent auslösen.

  • Geben Sie das NT-Administratorkonto nicht als Dienstkonto oder Proxykonto an.

  • SQL Server- und SQL Server-Agent haben Zugriff auf die Ressourcen der anderen. Die beiden Dienste teilen einen einzelnen Prozessraum, und der SQL Server-Agent ist ein Sysadmin für den SQL Server-Dienst.

  • Wenn ein TSX (Zielserver) sich bei einem MSX (Masterserver) registriert, erhalten die MSX-Sysadmins die vollständige Kontrolle über die TSX-Instanz von SQL Server.

  • ACE ist eine Erweiterung und kann sich nicht selbst aufrufen. Chainer-ScenarioEngine.exe (auch bekannt als Microsoft.SqlServer.Chainer.Setup.exe) kann ACE aufrufen. Andere Hostprozesse können auch ACE aufrufen.

  • ACE hängt von den folgenden Konfigurations-DLLs im Besitz von SSDP ab, da diese APIs von DLLs von ACE aufgerufen werden:

    • SCO - Microsoft.SqlServer.Configuration.Sco.dll, einschließlich neuer SCO-Validierungen für virtuelle Konten

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

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

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

Verknüpfte Server

In einigen Szenarien, z. B. mit von Azure SQL Managed Instance, um einen SQL-Agent-Auftrag auszuführen, der eine Transact-SQL-Abfrage (T-SQL) auf einem Remoteserver über einen verknüpften Server ausführt, müssen Sie eine lokale Anmeldung einer Anmeldung auf dem Remoteserver zuordnen.

Verwenden Sie sp_addlinkedsrvlogin, um eine Zuordnung zwischen einer Anmeldung auf dem lokalen Server zu einer Anmeldung auf dem Remoteserver zu erstellen, die über die erforderliche Berechtigung zum Ausführen der T-SQL-Abfrage verfügt. Wenn der SQL-Agent-Auftrag eine Verbindung mit dem Remoteserver über den verknüpften Server herstellt, wird die T-SQL-Abfrage im Kontext der Remoteanmeldung ausgeführt.

Die folgende Tabelle beschreibt, wie die Anmeldung basierend auf dem Besitzer des SQL-Agenten-Jobs in einer Azure SQL Managed Instance abgebildet werden kann.

SQL-Agent-Auftragsbesitzer Wie man die Anmeldung abbildet
Benutzer, der nicht Systemadministrator ist Ordnen Sie den lokalen Benutzer , dem der SQL-Agent-Job gehört, der Remoteanmeldung zu.
Systemadministrator Ordnen Sie alle lokalen Benutzer dem Remote-Login zu, indem Sie den Parameter @locallogin auf NULLfestlegen.

Anmerkung

Das Erstellen von Anmeldungen auf dem Remoteserver für SQL-Agent-Aufträge ist erforderlich, wenn der lokale Server azure SQL Managed Instance ist. Fehler beim ordnungsgemäßen Zuordnen von Benutzern können zu Fehlern wie den folgenden Beispielen führen:

  • 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

Verwandte Inhalte