xp_cmdshell：使用する必要がありますか？
xp_cmdshellをストアドプロシージャ内で安全に使用できますか？実際に他にオプションがない状況はありますか？言い換えると、ストアドプロシージャ内での使用は、セキュリティの問題として常にフラグが付けられている必要がありますか（よく知られているソースコードアナライザーのアドバイスに従ってください）。
別の言い方をすると、次の声明（直接引用）に同意しますか？
関数xp_cmdshellは安全に使用できません。使用しないでください。
常にリスクです。常にreviewedである必要があります。適切に軽減にすることができます。
正当な用途があり、必要な場合もありますが、入力には注意してください。
Xp_CmdShellをオフにすることは、腐った肉の上にベールをかぶせるようなものです。それはテーブルに誤った安心感をもたらし、ハエはまだ肉に着くことができます。説明させてください。
誰がxp_CmdShellを使用できますか？そのとおり。 「SA」特権を持つユーザー/アプリログイン、またはプロキシを許可するという恐ろしい間違いを犯したユーザーのみがそれを使用できます。
次の問題。 xp_CmdShellをオフにしている場合、オンに戻すことができるのは誰だけですか？もう一度修正してください！ 「SA」の特権を持つ人々/アプリのみが、それをオンに戻すことができます。
では、xp_CmdShellがセキュリティリスクになる本当の問題は何ですか？答えは、xp_CmdShellはセキュリティリスクではありません。不十分なセキュリティが唯一のセキュリティリスクです。ハッカーまたは悪意のある内部ユーザーが "SA"権限を持つシステムに侵入した場合、彼らは黙想の中でxp_CmdShellをオンにすることができます。ええ、そのアクションはログに記録されますが、それは、セキュリティがそもそも非常に欠けていたことの文書化された証言を提供するだけです。
Xp_CmdShellをオフにしても、ハッカーコードのその部分をオンにして実行する機会を提供する以外、セキュリティには何の影響もありません。
もう一度言います。 xp_CmdShellはセキュリティリスクではありません。悪いセキュリティだけがセキュリティリスクです。セキュリティを修正してから、xp_CmdShellをオンにします。それは素晴らしいツールであり、悪いセキュリティ慣行と神話のためにそれを見逃しています。
「使ってはいけない」というのはかなりいいアドバイスだと思います。これは、「それはalways安全ではない」という明確なカテゴリではなく、xp_cmdshellが危険であり、それを使用することは懸念と慎重な調査の根拠であるという認識です。
また、セキュリティリスクを回避する方法を知っていると思っていても、xp_cmdshellはおそらく使用するのに最適なツールではありません。オッズはより良い解決策があることです（偶然にも偶然にリスクが低くなる解決策です）。
「大きな力には大きな責任が伴います。」そうは言っても、私はxp_cmdshellは、レドモンドからそれを作るために最悪のセキュリティトレインリークの1つです。
Jl01の答え（私が+1したもの）を強調するには...
奇妙なことに、適切にセキュリティ保護された安全なSQL Serverの適切な尺度は、実際にxp_CmdShellを有効にすることです。つまり、システムが十分に安全であれば、xp_CmdShellを有効にして使用するなどの些細な問題について心配する必要はありません。
特にSQL Server 2005以降では、DBA以外のユーザーが、適切にロックダウンされたシステムのストアドプロシージャに対してPUBLIC特権およびEXECUTE特権よりも大きい特権を持つ必要があるという事実は事実上ありません。実際、正しく実装されたPUBLIC特権を持つユーザーは、xp_CmdShellを直接実行することなく、xp_CmdShellへの呼び出しを含むストアドプロシージャを実行できます。
皮肉なことに、MSがコマンドシェルプロキシを作成して、低特権のユーザーがテーブルを見ることができないはずのときにxp_CmdShellを直接実行できるようにしました。
SQL Server環境で使用されているセキュリティの種類は、混合または統合（Windows）ですか？ sysadmin SQL Serverロールには何人いますか？ MSのベストプラクティスでは、統合認証（saログインなし、SQLログインなし）と、sysadmin SQL Serverロールで2つだけが必要です。私は、これらのベストプラクティスに従うことで、危険にさらされることを大幅に軽減するとします。さらに、xp_cmdshell（pre sqlcmdモードおよびpre-Powershell）を使用すると、トランザクションログファイルを、スケジュールされたSQLエージェントジョブ内から数百マイル離れた運用サーバーからDRサーバーにコピーできます。ここには悪はありませんが、1つのポスターが言うように、「状況によって異なります」。