我们正在从 SQL 2000 迁移到 SQL 2005。我们有数百个 DTS 包，开发团队不愿意使用 SSIS 重新开发。
在将这些包迁移到 SSIS 时，我遇到了一个问题——其中许多包是从 Excel 文件中读取的。
鉴于我的生产 Box 是 64 位的，我不得不使用 CmdExec 子系统调用 32 位运行时来执行这些包。
我的问题是：使用 CmdExec 子系统将这些 SSIS 包安排为 SQL 代理作业有哪些安全风险？
谢谢，拉吉
问问题
5542 次
3 回答
1
运行该作业的任何帐户都可能有权从命令行运行命令 - 因此您需要考虑它将如何运行以及该帐户将拥有哪些权限。
例如，如果用户可以创建一个将在您的 sqlagent 上下文中运行的作业，并且您的 sql 代理被过度授权（更改安全性的权利），她可以授予自己提升的权限或损害您的机器。
于 2009-08-04T23:41:30.183 回答
0
SQL 2008 为 DTExec 引入了一个开关，允许您使用 SSIS 的本机 SQL 代理任务以 32 位模式运行包。在作业步骤属性的执行选项卡上，有一个 32 位复选框，当查看命令行视图时，它转换为“/X86”开关。
如果您无法使用 SQL 2005，那么 CMDEXEC 选项是我所知道的唯一一个选项。
于 2010-05-21T17:53:09.930 回答
-1
xp_cmdshell是 SQL Server 中最大的安全风险，因为它允许受损的 SQL Server 机器将攻击提升到主机操作系统本身，并从那里扩展到整个网络。
典型的攻击向量是网站 HTTP 表单 -> SQL 注入 -> xp_cmdshell-> 接管 SQL 主机 -> 接管域。如果xp_cmdshell被关闭，那么攻击者必须找到其他方法来将其攻击从 SQL 提升到主机。
存在其他场景，例如内部用户使用它来提升权限，或将 cmdshell 用于其他目的，例如。窃取数据库。所有这些都是基于xp_cmdshell允许在主机上执行任意命令的事实，并且在某些情况下执行的命令还继承了 SQL Server 服务帐户权限。
如果xp_cmdshell被阻止，攻击者可以使用其他命令和扩展程序，但它们鲜为人知。在每个 SQL 注入备忘单和论坛讨论中都使用xp_cmdshell向量，因此每个人和他们的奶奶都知道。
于 2009-07-19T16:43:55.093 回答