我正在进行的一个项目的 SQL 开发人员询问是否可以在生产数据库上启用 xp_cmdshell，因为使用 xp_cmdshell 导出 CSV 文件比编写 SSIS 包执行相同操作更容易。
启用 xp_cmdshell 听起来像是一场安全噩梦，而且绝对不应该这样做。
针对此问题有哪些建议/最佳做法？
答案1
我不会这么做。特别是如果你打算作为开发者合作伙伴从微软获得任何品牌。我们的产品已通过微软认证，他们的应用程序检查工具将检查 xp_cmdshell 是否已启用。
答案2
只要您已正确清理了代码进入 SQL Server 的任何区域，并且没有人拥有他们不需要的任何权限，您的风险就应该很小。当然仍然存在风险，因此我只会在必要时或将极大地改善当前流程时才启用它。如果编写 SSIS 包不是太麻烦，您最好不要使用 xp_cmdshell。
答案3
关闭 xp_CmdShell 有点像给腐烂的肉蒙上一层面纱。它给餐桌带来了一种虚假的安全感，苍蝇仍然能吃到肉。请允许我解释一下。
谁可以使用 xp_CmdShell？没错。只有拥有“SA”权限的人员/应用程序登录或您犯下授予代理权这一可怕错误的人才能使用它。
下一个问题。如果您关闭了 xp_CmdShell，那么只有谁可以将其重新打开？又正确了！只有拥有“SA”权限的人/应用程序才能将其重新打开。
那么，xp_CmdShell 存在安全风险的真正原因是什么？答案是 xp_CmdShell 不存在安全风险。安全性差是唯一的安全风险。如果黑客或恶意内部用户以“SA”权限进入系统，那么他们可以在短时间内打开 xp_CmdShell。是的，该操作会被记录下来，但这只能提供书面证据，证明安全性从一开始就严重不足。
打开 xp_CmdShell 对安全性没有任何作用，只是为黑客代码的那部分提供了重新运行的机会。
我再说一遍。xp_CmdShell 不是安全风险。只有糟糕的安全措施才是安全风险。修复您的安全措施，然后启用 xp_CmdShell。这是一个很棒的工具，而您却因为糟糕的安全措施和误解而错过了它。
答案4
我建议不要启用此功能，但如果它成为业务关键问题并对您造成影响，我会设置流程，以便您仅在需要导入的短暂时间内启用 xp_cmdshell。可以使用 sp_configure 编写脚本，并在作业步骤或 T-SQL 过程中打开和关闭。