我似乎无法找到这个问题的明确答案。
问题：我使用Octopus Deploy运行可运行数据库迁移脚本的可执行文件。由于八达通“触手”Windows服务以localsystem运行，转换为NT AUTHORITY\System，因此会发生错误。
一种解决方案是更改SQL Server安全设置并向NT AUTHORITY\System用户授予适当的角色，允许以localsystem用户身份运行的进程创建数据库。
进行此更改有哪些安全隐患？它允许任何以localsystem运行的进程在数据库上执行操作，但鉴于我控制安装到服务器上的内容，这是一件坏事吗？
看起来大约在SQL Server 2012上进行了更改，localsystem帐户以前默认为sysadmin但更改了。我看到的一件事是这个更改阻止服务器管理员访问服务器，但我无法看到这是如何可能的，因为你无论如何都无法以localsystem身份登录。
我错过了什么？
参考文献：
https://dba.stackexchange.com/questions/142166/grant-sysadmin-permissions-to-nt-authority-system
答案 0 :(得分：0)
我回答这个问题：
我看到的一件事是此更改阻止了服务器管理员 有权访问服务器，但我无法看到这是如何实现的 无论如何你无法以localsystem身份登录。
本地Windows管理员无论如何都可以访问服务器，以单用户模式启动SQL Server，他可以完全控制它：Connect to SQL Server When System Administrators Are Locked Out
但这需要重新启动服务器。
在没有重新启动的情况下以sysadmin身份访问服务器的另一个选项是使用PsExec（ - s）：您甚至可以通过SSMS以本地系统身份登录。如果此登录是sysadmin，则您可以完全控制服务器
答案 1 :(得分：0)
如果有人能够破坏您的Octopus Deploy实例，则SA角色可以提供足够的访问权限来删除服务器上的每个数据库。
我想创建初始数据库是一个蓝月亮事件。更安全的选择是手动创建数据库并授予NT Authority运行迁移脚本的最少权限。
我们采用了这种方法，并从SA返回到db_owner，再到
的自定义角色[db_datareader]
[db_datawriter]
[db_ddladmin]