Condividi tramite


Implementare la sicurezza di SQL Server Agent

Si applica a:SQL ServerIstanza gestita di Azure SQL

Importante

In Azure SQL Managed Instance, sono attualmente supportate la maggior parte, ma non tutte, le funzionalità di SQL Server Agent. Per informazioni dettagliate, vedere differenze T-SQL tra Istanza gestita di SQL di Azure e SQL Server.

SQL Server Agent consente all'amministratore del database di eseguire ogni passaggio del processo in un contesto di sicurezza che dispone solo delle autorizzazioni necessarie per eseguire tale passaggio di processo, determinato da un proxy di SQL Server Agent. Per impostare le autorizzazioni per un passaggio di processo specifico, creare un proxy con le autorizzazioni necessarie e quindi assegnare tale proxy al passaggio del processo. È possibile specificare un proxy per più passaggi del processo. Per i passaggi del processo che richiedono le stesse autorizzazioni, usare lo stesso proxy.

La sezione seguente illustra il ruolo del database che è necessario concedere agli utenti in modo che possano creare o eseguire processi usando SQL Server Agent.

Concessione dell'accesso a SQL Server Agent

Per usare SQL Server Agent, gli utenti devono essere membri di uno o più dei ruoli predefiniti del database seguenti:

  • SQLAgentUserRole

  • SQLAgentReaderRole

  • SQLAgentOperatorRole

Questi ruoli vengono archiviati nel database msdb . Per impostazione predefinita, nessun utente è membro di questi ruoli del database. L'appartenenza a questi ruoli deve essere concessa in modo esplicito. Gli utenti membri del ruolo predefinito del server sysadmin hanno accesso completo a SQL Server Agent e non devono essere membri di questi ruoli predefiniti del database per usare SQL Server Agent. Se un utente non è membro di uno di questi ruoli del database o del ruolo sysadmin , il nodo SQL Server Agent non è disponibile quando si connette a SQL Server tramite SQL Server Management Studio.

I membri di questi ruoli del database possono visualizzare ed eseguire processi di cui sono proprietari e creare passaggi di processo eseguiti come account proxy esistente. Per altre informazioni sulle autorizzazioni specifiche associate a ognuno di questi ruoli, vedere Ruoli predefiniti del database di SQL Server Agent.

I membri del ruolo predefinito del server sysadmin hanno l'autorizzazione per creare, modificare ed eliminare account proxy. I membri del ruolo sysadmin dispongono dell'autorizzazione per creare passaggi di processo che non specificano un proxy, ma vengono eseguiti come account del servizio SQL Server Agent, ovvero l'account usato per avviare SQL Server Agent.

Istruzioni

Seguire queste linee guida per migliorare la sicurezza dell'implementazione di SQL Server Agent:

  • Creare account utente dedicati specificamente per i proxy e usare solo questi account utente proxy per eseguire i passaggi del processo.

  • Concedere solo le autorizzazioni necessarie agli account utente proxy. Concedere solo le autorizzazioni necessarie per eseguire i passaggi del processo assegnati a un determinato account proxy.

  • Non eseguire il servizio SQL Server Agent con un account Di Microsoft Windows membro del gruppo Amministratori di Windows.

  • I proxy sono sicuri solo come l'archivio credenziali di SQL Server.

  • Se le operazioni di scrittura degli utenti possono scrivere nel registro eventi NT, possono generare avvisi tramite SQL Server Agent.

  • Non specificare l'account amministratore NT come account del servizio o un account proxy.

  • SQL Server e SQL Server Agent hanno accesso agli asset dell'altro. I due servizi condividono uno spazio di processo singolo e SQL Server Agent è un sysadmin nel servizio SQL Server.

  • Quando un TSX (server di destinazione) si integra con un MSX (server master), gli amministratori di sistema MSX ottengono il controllo totale sull'istanza TSX di SQL Server.

  • ACE è un'estensione e non può richiamare se stessa. Chainer ScenarioEngine.exe (noto anche come Microsoft.SqlServer.Chainer.Setup.exe) può richiamare ACE. Anche altri processi host possono richiamare ACE.

  • ACE dipende dalle DLL di configurazione seguenti di proprietà di SSDP, perché tali API delle DLL vengono chiamate da ACE:

    • SCO - Microsoft.SqlServer.Configuration.Sco.dll, incluse le nuove convalide SCO per gli account virtuali

    • Cluster - Microsoft.SqlServer.Configuration.Cluster.dll

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

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

Server collegati

In alcuni scenari, ad esempio con Istanza gestita di SQL di Azure, per eseguire un processo di SQL Agent che esegue una query Transact-SQL (T-SQL) in un server remoto tramite un server collegato, è necessario eseguire il mapping di un account di accesso locale a un account di accesso nel server remoto.

Usare sp_addlinkedsrvlogin per creare un mapping tra un account di accesso nel server locale e un account di accesso nel server remoto con l'autorizzazione necessaria per eseguire la query T-SQL. Quando il processo di SQL Agent si connette al server remoto tramite il server collegato, esegue la query T-SQL nel contesto dell'account di accesso remoto.

La tabella seguente descrive come eseguire il mapping dell'account di accesso in base al proprietario del processo di SQL Agent in Istanza gestita di SQL di Azure:

Proprietario dell'attività di SQL Agent Come mappare il login
Utente che non è sysadmin Associare l'utente locale proprietario del processo di SQL Agent all'account remoto.
sysadmin Eseguire il mapping di tutti gli utenti locali all'account di accesso remoto impostando il @locallogin parametro su NULL.

Annotazioni

La creazione di account di accesso nel server remoto per i processi di SQL Agent è necessaria quando il server locale è Istanza gestita di SQL di Azure. Se non si esegue correttamente il mapping degli utenti, possono verificarsi errori come gli esempi seguenti:

  • 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