Freigeben über

Implementieren der SQL Server-Agent-Sicherheit

  • Artikel

Gilt für: SQL Server Azure SQL Managed Instance

Wichtig

In Azure SQL Managed Instance werden derzeit die meisten, aber nicht alle, SQL Server-Agent-Features unterstützt. Details dazu finden Sie unter T-SQL-Unterschiede zwischen Azure SQL Managed Instance und SQL Server.

SQL Server-Agent ermöglicht es dem Datenbankadministrator, jeden Auftragsschritt in einem Sicherheitskontext auszuführen, dem lediglich die Berechtigungen erteilt wurden, die zum Durchführen dieses Auftragsschritts erforderlich sind, wie von einem SQL Server-Agent-Proxy festgelegt. Um Berechtigungen für einen bestimmten Auftragsschritt festzulegen, erstellen Sie einen Proxy mit den erforderlichen Berechtigungen und weisen dann diesen Proxy dem Auftragsschritt zu. Ein Proxy kann für mehrere Auftragsschritte angegeben werden. Für Auftragsschritte, für die dieselben Berechtigungen erforderlich sind, 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.

Erteilen des Zugriffs auf den SQL Server-Agent

Um den SQL Server-Agent zu verwenden, müssen die Benutzer Mitglied mindestens einer 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 erteilt werden. Benutzer, die Mitglieder der festen Serverrolle sysadmin sind, haben vollen Zugriff auf den SQL Server-Agent und müssen nicht Mitglied dieser festen Datenbankrollen sein, um den SQL Server-Agent verwenden zu können. Wenn ein Benutzer kein Mitglied einer dieser Datenbankrollen oder der sysadmin-Rolle ist, steht ihm der SQL Server-Agent-Knoten nicht zur Verfügung, wenn er mithilfe von SQL Server Management Studio eine Verbindung mit SQL Server herstellt.

Die Mitglieder dieser Datenbankrollen können Aufträge anzeigen und ausführen, deren Besitzer sie sind, und Auftragsschritte erstellen, die als bereits vorhandenes Proxykonto ausgeführt werden. Weitere Informationen zu den einzelnen Berechtigungen, die jeder dieser festen Rollen zugeordnet sind, finden Sie unter Feste Datenbankrollen des SQL Server-Agents.

Die Mitglieder der festen Serverrolle sysadmin haben die Berechtigung zum Erstellen, Ändern und Löschen von Proxykonten. Die Mitglieder der sysadmin -Rolle haben die Berechtigung zum Erstellen von Auftragsschritten, die keinen Proxy angeben, sondern stattdessen als das SQL Server-Agent-Dienstkonto ausgeführt werden, bei dem es sich um das Konto handelt, das zum Starten des SQL Server-Agents verwendet wird.

Richtlinien

Befolgen Sie diese 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 zum Ausführen von Auftragsschritten.

  • Erteilen Sie die erforderlichen Berechtigungen lediglich den Proxybenutzerkonten. Erteilen Sie nur die 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-Gruppe Administratoren ist.

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

  • 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-Adminkonto nicht als Dienst- oder Proxykonto an.

  • SQL Server und der SQL Server-Agent können gegenseitig auf ihre Ressourcen zugreifen. Die beiden Dienste verwenden einen einzelnen Prozessraum, und der SQL Server-Agent fungiert mit der Rolle "sysadmin" auf dem SQL Server-Dienst.

  • Wenn für ein TSX (Zielserver) ein MSX (Masterserver) eingetragen wird, erhält die MSX-Rolle „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 als bekannt als Microsoft.SqlServer.Chainer.Setup.exe) kann ACE aufrufen. Andere Hostprozesse können auch ACE aufrufen.

  • ACE hängt von den folgenden Konfigurations-DLL-Elementen ab, die sich im Besitz von SSDP befinden, da diese DLL-APIs von ACE aufgerufen werden:

    • SCO: Microsoft.SqlServer.Configuration.Sco.dll, einschließlich neuer SCO-Überprüfungen 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 Azure SQL Managed Instance, müssen Sie einen SQL-Agent-Auftrag ausführen, der eine Transact-SQL -Abfrage (T-SQL) auf einem Remoteserver über einen verknüpften Server ausführt, 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 über den Verbindungsserver eine Verbindung mit dem Remoteserver herstellt, wird die T-SQL-Abfrage im Kontext der entfernten Anmeldung ausgeführt.

In der folgenden Tabelle wird beschrieben, wie Sie die Anmeldung basierend auf dem SQL-Agent-Auftragsbesitzer in Azure SQL Managed Instance zuordnen:

SQL-Agent-Auftragsbesitzer So ordnen Sie die Anmeldung zu
Benutzer, der nicht sysadmin ist Ordnen Sie den lokalen Benutzer , der den SQL-Agent-Auftrag besitzt, der Remote-Anmeldung zu.
sysadmin Ordnen Sie alle lokalen Benutzer der Remote-Anmeldung zu, indem Sie den @locallogin Parameter auf NULL stellen.

Hinweis

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

Zugehöriger Inhalt