現在、SQL 2000 から SQL 2005 への移行を進めています。数百の DTS パッケージがあり、開発チームは SSIS を使用して再開発することに消極的です。
これらのパッケージを SSIS に移行するとき、問題に直面しました。これらのパッケージの多くは Excel ファイルから読み取られます。
私のプロダクション Box は 64 ビットであるため、これらのパッケージを実行するには、CmdExec サブシステムを使用して 32 ビット ランタイムを呼び出す必要があります。
ここでの私の質問は次のとおりです。CmdExec サブシステムを使用して、これらの SSIS パッケージを SQL エージェント ジョブとしてスケジュールすることに伴うセキュリティ リスクは何ですか?
ありがとう、ラージ
ジョブを実行しているアカウントは、コマンド ラインからコマンドを実行するためのアクセス権を持っている可能性があります。そのため、ジョブをどのように実行するか、およびアカウントが持つ権限について考える必要があります。
たとえば、ユーザーが sqlagent のコンテキストで実行されるジョブを作成でき、SQL エージェントが過剰な特権 (セキュリティを変更する権利) を持っていた場合、ユーザーは自分自身に昇格した特権を付与したり、マシンに損害を与えたりする可能性があります。
SQL 2008 では、SSIS のネイティブ SQL エージェント タスクを使用して 32 ビット モードでパッケージを実行できるようにする DTExec のスイッチが導入されました。ジョブ ステップ プロパティの実行タブには、32 ビット用のチェック ボックスがあります。これは、コマンド ライン ビューを見ると「/X86」スイッチに変換されます。
SQL 2005 の使用に行き詰まっている場合、私が知っている唯一のオプションは CMDEXEC オプションです。
xp_cmdshellこれは、侵害された SQL Server ボックスが攻撃をホスト オペレーティング システム自体に昇格させ、そこからネットワーク全体にまで及ぶ可能性があるため、SQL Server の最大のセキュリティ リスクです。
攻撃の典型的なベクトルは、Web サイトの HTTP フォーム -> SQL インジェクション -> xp_cmdshell-> SQL ホスティング マシンの乗っ取り -> ドメインの乗っ取りです。xp_cmdshellがシャットダウンされた場合、攻撃者は攻撃を SQL からホストに昇格させる他の手段を見つける必要があります。
インサイダー ユーザーがそれを使用して特権を昇格させたり、他の目的で cmdshell を使用したりするなど、他のシナリオが存在します。データベースを盗みます。すべては、ホスト上で任意のコマンドを実行できるという事実に基づいており、xp_cmdshell場合によっては、実行されたコマンドも SQL Server サービス アカウントの権限を継承します。
がブロックされた場合に攻撃者が使用できるコマンドや拡張手順は他にもありますが、xp_cmdshellあまり知られていません。ベクトルの使用xp_cmdshellは、すべての SQL インジェクション チート シートとフォーラム ディスカッションで取り上げられているため、誰もが知っていることです。