Should NT AUTHORITY\System be granted the sysadmin role? - sql-server

Question

I cannot seem to find a definitive answer to this question.
The problem: I am using Octopus Deploy to run an executable that will run my database migration scripts. An error occurs as the Octopus "Tentacle" Windows service runs as localsystem which translates to NT AUTHORITY\System.
One solution is to change the SQL server security settings and grant an appropriate role to the NT AUTHORITY\System user which allows a process running as the localsystem user to create the database.
What are the security implications of making this change? It would allow any process running as localsystem to perform operations on the database but is this a bad thing given that I control what gets installed onto the server?
It would appear there was a change made circa SQL Server 2012 where by the localsystem account was previously by default a sysadmin but that got changed. One thing I saw was that this change prevents server administrators having access to the server but I can't see how this is possible given that you cannot log in as localsystem anyway.
What am I missing?
References:
https://support.microsoft.com/en-us/help/932881/how-to-make-unwanted-access-to-sql-server-2005-by-an-operating-system
https://dba.stackexchange.com/questions/142166/grant-sysadmin-permissions-to-nt-authority-system
https://serverfault.com/questions/130958/implications-and-benefits-of-removing-nt-authority-system-from-sysadmin-role

Answer 1

I answer to this one:
One thing I saw was that this change prevents server administrators
having access to the server but I can't see how this is possible given
that you cannot log in as localsystem anyway.
Local Windows administrator can access the server anyway, launching SQL Server in single user mode he will have a full control over it: Connect to SQL Server When System Administrators Are Locked Out
But this requires the server to be restarted.
Another option to access server as sysadmin without any restart is to use PsExec (-s) : you can log in as localsystem even through SSMS. And if this login is a sysadmin, you have a full control over the server

Answer 2

If someone is able to compromise your instance of Octopus Deploy the SA role provides enough access to drop every database on your server.
I imagine creating the initial database is a blue moon event. A safer option is to manually create the database and grant NT Authority the least amount of privileges to run your migration scripts.
We took this approach and worked back from SA, to db_owner, to a custom role with
[db_datareader]
[db_datawriter]
[db_ddladmin]

Answer 3

The NT AUTHORITY\SYSTEM account used to be sysadmin by default but not anymore because it's considered a "shared" account. It's not that it's a huge security issue, but when the time comes to point a finger at someone when something goes wrong, it's impossible to do so because using SYSTEM allows actions to be perfomed "anonymously". That's why SYSTEM is no longer recommended to be sysadmin.
"Any user with enough access to the server can execute a task that
will be run as NT AUTHORITY\SYSTEM either using task scheduler or
other tools. At this point, NT AUTHORITY\SYSTEM essentially becomes a
shared account because the operating system and SQL Server are unable
to determine who created the process. Prior to SQL Server 2012, NT
AUTHORITY\SYSTEM was a member of the sysadmin role by default. This
allowed jobs/tasks to be executed in SQL Server without the approval
or knowledge of the DBA because it looked like operating system
activity." (https://www.stigviewer.com/stig/ms_sql_server_2016_instance/2018-03-09/finding/V-79129)