Dela via

Implementera SQL Server Agent-säkerhet

  • Artikel

gäller för:SQL ServerAzure SQL Managed Instance

Viktig

På Azure SQL Managed Instancestöds de flesta, men inte alla SQL Server Agent-funktioner för närvarande. Mer information finns i om T-SQL-skillnader mellan Azure SQL Managed Instance och SQL Server.

MED SQL Server Agent kan databasadministratören köra varje jobbsteg i en säkerhetskontext som bara har de behörigheter som krävs för att utföra det jobbsteget, vilket bestäms av en SQL Server Agent-proxy. Om du vill ange behörigheter för ett visst jobbsteg skapar du en proxy som har de behörigheter som krävs och tilldelar sedan proxyn till jobbsteget. En proxy kan anges för fler än ett jobbsteg. För jobbsteg som kräver samma behörigheter använder du samma proxy.

I följande avsnitt beskrivs vilken databasroll du måste bevilja användarna så att de kan skapa eller köra jobb med hjälp av SQL Server Agent.

Bevilja åtkomst till SQL Server-agent

Om du vill använda SQL Server-agenten måste användarna vara medlemmar i en eller flera av följande fasta databasroller:

  • SQLAgentUserRole

  • SQLAgentReaderRole

  • SQLAgentOperatorRole

Dessa roller lagras i databasen msdb. Som standard är ingen användare medlem i dessa databasroller. Medlemskap i dessa roller måste beviljas uttryckligen. Användare som är medlemmar i sysadmin fast serverroll har fullständig åtkomst till SQL Server Agent och behöver inte vara medlem i dessa fasta databasroller för att använda SQL Server Agent. Om en användare inte är medlem i någon av dessa databasroller eller sysadmin- roll är SQL Server Agent-noden inte tillgänglig för dem när de ansluter till SQL Server med hjälp av SQL Server Management Studio.

Medlemmar i dessa databasroller kan visa och köra jobb som de äger och skapa jobbsteg som körs som ett befintligt proxykonto. Mer information om de specifika behörigheter som är associerade med var och en av dessa roller finns i SQL Server Agent Fixed Database Roles.

Medlemmar i sysadmin fast serverroll har behörighet att skapa, ändra och ta bort proxykonton. Medlemmar i sysadmin roll har behörighet att skapa jobbsteg som inte anger en proxy, utan körs istället som SQL Server Agent-tjänstkontot, vilket är det konto som används för att starta SQL Server Agent.

Riktlinjer

Följ dessa riktlinjer för att förbättra säkerheten för implementeringen av SQL Server Agent:

  • Skapa dedikerade användarkonton specifikt för proxyservrar och använd endast dessa proxyanvändarkonton för att köra jobbsteg.

  • Bevilja endast de behörigheter som krävs för proxyanvändarkonton. Bevilja endast de behörigheter som krävs för att köra jobbstegen som har tilldelats till ett visst proxykonto.

  • Kör inte SQL Server Agent-tjänsten under ett Microsoft Windows-konto som är medlem i windows administratörer gruppen.

  • Proxyservrar är bara lika säkra som SQL Server-autentiseringsarkivet.

  • Om användarens skrivåtgärder kan skriva till NT-händelseloggen kan de skapa aviseringar via SQL Server Agent.

  • Ange inte NT-administratörskontot som ett tjänstkonto eller proxykonto.

  • SQL Server och SQL Server Agent har åtkomst till varandras tillgångar. De två tjänsterna delar ett enda processutrymme och SQL Server Agent är en sysadmin på SQL Server-tjänsten.

  • När en TSX (målserver) registrerar sig hos en MSX (huvudserver) får MSX-sysadmins total kontroll över TSX-instansen av SQL Server.

  • ACE är ett tillägg och kan inte anropa sig själv. Chainer ScenarioEngine.exe (kallas även Microsoft.SqlServer.Chainer.Setup.exe) kan anropa ACE. Andra värdprocesser kan också anropa ACE.

  • ACE är beroende av följande konfigurations-DLL:er som ägs av SSDP, eftersom dessa API:er för DLL:er anropas av ACE:

    • SCO- – Microsoft.SqlServer.Configuration.Sco.dll, inklusive nya SCO-valideringar för virtuella konton

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

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

    • Tillägg – Microsoft.SqlServer.Configuration.ConfigExtension.dll

Länkade servrar

I vissa scenarier, till exempel med Azure SQL Managed Instance, för att köra ett SQL Agent-jobb som kör en Transact-SQL -fråga (T-SQL) på en fjärrserver via en länkad server, måste du mappa en lokal inloggning till en inloggning på fjärrservern.

Använd sp_addlinkedsrvlogin för att skapa en mappning mellan en inloggning på den lokala servern till en inloggning på fjärrservern som har nödvändig behörighet för att köra T-SQL-frågan. När SQL Agent-jobbet ansluter till fjärrservern via den länkade servern körs T-SQL-frågan i kontexten för fjärrinloggningen.

I följande tabell beskrivs hur du mappar inloggningen baserat på SQL Agent-jobbägaren i Azure SQL Managed Instance:

SQL Agent-jobbägare Så här kartlägger du inloggningen
Användare som inte är sysadmin Mappa den lokala användaren som äger SQL Agent-jobbet till fjärrinloggningen.
systemadministratör Mappa alla lokala användare till fjärrinloggningen genom att ange parametern @locallogin till NULL.

Obs

Det krävs att du skapar inloggningar på fjärrservern för SQL Agent-jobb när den lokala servern är Azure SQL Managed Instance. Om användarna inte mappas korrekt kan det leda till fel, till exempel följande:

  • 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

Relaterat innehåll