May 3, 2017 at 8:18 am
It is best practice to use a domain account or Managed Service account to run SQL Server Agent. Many administrators choose to make this account a domain admin. However, this comes with significant security risks because it allows anyone with rights to deploy and execute an SSIS package by using SQL Server Agent to elevate his or her permissions and execute potentially damaging T-SQL, command-line, or other code by using that account.
So we should - Create a credential in SQL Server mapped to a domain account with the appropriate privileges to access network resources needed by the SSIS packages. Map this credential to a proxy and select the proxy in the SQL Server Agent job step editor.
----
How does this actually make it more secure?
May 3, 2017 at 8:56 am
Giving Domain Admin to a service account is bad practise.
Generally it should just be a standard blank Domain User account or if you can a managed service account.
Permissions should be kept to a minimum, the installer gives the agent SA rights to the local instance as that's best practise from Microsoft.
From there you then limit what the account can/can't do on the network other servers, keep access to a minimum who can create jobs which exploit the sysadmin rights, generally we would only allow DBA's to create jobs, after the SSIS packages or jobs have been run through Dev/UAT/QA before going to Prod.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply