Granting [NT AUTHORITY\SYSTEM] sysadmin on SQL server - Compliance/Best Practice

Question

New to security in general. We have a third party service which runs on SQL server host and under Local System. Since it is running under Local System, they have always given sysadmin privilege to [NT AUTHORITY\SYSTEM] on older server.

When a new server was getting build we request if you could use a service account to run the service so that permission can be granted to that specific account instead of a build in account and for whatever reason the application team does not seem to have figured out a way to make it work. Now they are asking if we could go back to giving [NT AUTHORITY\SYSTEM] permission again.

So my options/questions

1. Grant sysadmin to [NT AUTHORITY\SYSTEM]. Probably the worst option, but I am more interested in knowing what the industry standard is about this. Does any compliance like SOX or PCI ban this?
2. Grant more granular permission to [NT AUTHORITY\SYSTEM]. This is what I will try to do first.

So I would like know about what others do in terms of [NT AUTHORITY\SYSTEM] in SQL Server and what SOX, PCI etc compliance best practices are.

Thanks

Answer 1

I assume this is some sort of IT management or monitoring agent, otherwise it shouldn't be running on your SQL Server.

If you don't run any other code as SYSTEM on the server, there's not really a lot of extra risk over and above running 3rd party code with Windows administrative privileges. If the service runs as any local administrator, it can get access to SQL Server.

If possible you should do both of:

1) Grant the service the least privileges is needs to run

2) Provision the login and grant permissions to the per-service SID instead of the service account.

So if the service is has a Name of 'someservice' (not DisplayName), create a login like:

create login [nt service\someservice] from windows

And grant the permissions to that. Then other services running under the same service account won't be able to connect to SQL Server.