Condividi tramite

Implementazione della sicurezza di SQL Server Agent

  • Articolo

Si applica a: SQL ServerIstanza gestita di SQL di Azure

Importante

In Istanza gestita di SQL di Azure sono attualmente supportate la maggior parte delle funzionalità di SQL Server Agent, ma non tutte. 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 ciascun passaggio di un processo in un contesto di sicurezza in cui sono disponibili solo le autorizzazioni necessarie all'esecuzione di tale passaggio e che viene determinato da un proxy di SQL Server Agent. Per impostare le autorizzazioni per un particolare passaggio di un processo, è necessario creare un proxy che disponga delle autorizzazioni necessarie e quindi assegnare questo proxy al passaggio del processo. È possibile specificare un proxy per più di un passaggio di processo. Per i passaggi che richiedono le medesime autorizzazioni, viene utilizzato lo stesso proxy.

Nella sezione che segue viene spiegato quale ruolo di database concedere agli utenti affinché possano creare o eseguire processi usando SQL Server Agent.

Concessione dell'accesso a SQL Server Agent

Per poter utilizzare SQL Server Agent, l'utente deve essere membro di uno o più dei seguenti ruoli predefiniti di database:

  • SQLAgentUserRole

  • SQLAgentReaderRole

  • SQLAgentOperatorRole

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

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

I membri del ruolo predefinito del server sysadmin sono autorizzati a creare, modificare ed eliminare account proxy. I membri del ruolo sysadmin sono autorizzati a creare passaggi di processo che non specificano un proxy ma che invece vengono eseguiti come account di servizio di SQL Server Agent, vale a dire l'account usato per avviare SQL Server Agent.

Linee guida

Per migliorare la sicurezza dell'implementazione di SQL Server Agent, attenersi alle seguenti indicazioni generali:

  • Creare appositi account utente dedicati per i proxy e utilizzare questi account solo per eseguire passaggi di processo.

  • Concedere le autorizzazioni necessarie solo agli account utente proxy. Concedere solo le autorizzazioni richieste per eseguire i passaggi di processo assegnati a un particolare account proxy.

  • Non eseguire il servizio SQL Server Agent usando un account Microsoft Windows che è membro del gruppo Administrators di Windows.

  • I proxy hanno lo stesso livello di sicurezza dell'archivio credenziali di SQL Server.

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

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

  • SQL Server e SQL Server Agent dispongono dell'accesso reciproco alle proprie risorse. I due servizi condividono un unico spazio di elaborazione e SQL Server Agent è un sysadmin nel servizio SQL Server.

  • Quando un processo TSX (target server) viene integrato con un processo MSX (master server), sysadmins di MSX assume il controllo totale dell'istanza TSX di SQL Server.

  • Il processo ACE è un'estensione e non può richiamare se stesso. Chainer ScenarioEngine.exe, anche noto come Microsoft.SqlServer.Chainer.Setup.exe, o può richiamare un altro ACE. Anche altri processi host possono richiamare ACE.

  • ACE dipende dalle DLL di configurazione seguenti di proprietà di SSDP, perché le API delle DLL vengono richiamate 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

    • Extension: 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.

Nella tabella seguente viene descritto 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 processo SQL Agent Come eseguire il mapping dell'account di accesso
Utente che non è sysadmin Eseguire il mapping dell'utente locale proprietario del processo di SQL Agent all'account di accesso remoto.
sysadmin Eseguire il mapping di tutti gli utenti locali all'account di accesso remoto impostando il parametro @locallogin su NULL.

Nota

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 degli 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

Contenuto correlato