不明なソースからバックアップを復元することによるセキュリティへの影響？
シナリオ：データベースバックアップを渡され、それをサーバー（既に他のデータベースをホストしている）に復元するように指示されましたが、バックアップに含まれる内容や、ソースを信頼する必要があるかどうかに関する有用な情報は提供されません。
質問1：悪意のある可能性のあるバックアップを復元することの潜在的な影響は何ですか？
質問2：悪意のある可能性のあるバックアップの復元の影響からサーバー/他のデータベースのデータを保護するために何ができますか？ RESTORE VERIFYONLYは、良い最初のステップのようです。最終的な答えは、おそらく「サンドボックスにデータベースを復元するVM外部の世界へのアクセスなしで）」ですが、オプションがテーブルから外れていると仮定しましょう。この状況で他に何をすべきですか？
データベースには、悪意のあるコードが含まれている可能性があり、「sa」ログインのパスワードを変更したり、すべてのデータベースを削除したりする手順が考えられます。ただし、問題が発生していることを確認できる唯一の方法は、個人がデータベースを復元し、そのデータベース内のコードを手動で実行することです。自動化された方法では実行されません。
データベースをサーバーに復元すると、SQL Serverがデータベース内の一部のコードを自動的に実行するようにデータベース内に適用できる設定はありません。もしそうなら、マイクロソフトが製品のCommon Criteria認定を失うことを期待します。これは、DBMSで許容されている大きなバグです。
あなたが行うことができるいくつかの防止手順があります。
- 復元されたデータベースにアクセスできるのは、1人のシステム管理者だけであることを確認してください。
- 復元が完了したら、データベースをシングルユーザーモードにします。
- このデータベース内のすべてのストアドプロシージャと関数およびトリガー内のコードを確認してください。
- Dbcc checkdbを実行して、整合性の問題がないことを確認します。
- データベースにアクセスしていたユーザーを確認し、すべて削除します。
- あなたがチェックした特定のオブジェクトに非常に制限されたアクセスを許可し始めます。
Shawnが言ったように、vbalidと思われるいくつかのストアドプロシージャが別の悪意のあるコードのexecを持たない限り、コードはそれ自体では実行されません。これが、マルチユーザーモードにする前に、それぞれの内部のコードをチェックする理由です。
私はここに到達していますが、少なくとも1つの危険なシナリオを考えることができます： filetable を持つデータベースを復元すると、これらのファイルはデフォルトで（特にSQLに）ネットワーク上にありますサーバ）。ウイルスを復元できます。
もちろん、それだけでは何も起こりません-ウイルスが突然知覚的になることはありません-しかし、ユーザーがファイルにアクセスしようとすると、ウイルスに感染する可能性があります。 （ねえ、私は近づいていたと言った。）私は、外部のハッカーがマルウェアをドアに入れようとするシナリオを想定しています。 myvirus.exe "-その時点で、ファイアウォールを検出されずに通過し、内部のウイルス対策ツールとマルウェア対策ツールが使用されます。
質問は主にマルウェアを含むバックアップに焦点を当てていますが、復元操作自体から不要で潜在的に悪意のある動作を取得することも可能です。
破損したバックアップファイルを復元しようとすると、SQL Serverがクラッシュし、SQL Serverがバックアップファイルの最後を超えて読み取ってクラッシュする可能性があることを誤って見つけました。どのバージョンが影響を受けやすいか、または問題を再現するために何が必要か正確にはわかりません。数年前にこの問題に遭遇したとき、私はいくつかの限られた詳細 ここ を文書化しました。
VERIFYONLYを復元することは、良い最初のステップのようです。最終的な答えは、おそらく「サンドボックスにデータベースを復元するVM外部の世界へのアクセスなしで）」ですが、オプションがテーブルから外れていると仮定しましょう。この状況で他に何をすべきですか？
Restore verifyonly データベースの整合性を検証します。バックアップに悪意のあるコードが含まれているかどうかは通知されません。RESTOREVERIFYONLYは、バックアップボリュームに含まれるデータの構造の検証を試みません。バックアップが社内の社内から行われる場合は悪意がある可能性が非常に低いですが、サードパーティからのバックアップの場合はShawnが指摘したように注意する必要があります。
Microsoft Onlineのドキュメントによると
•セキュリティ上の理由から、不明または信頼できないソースからデータベースをアタッチまたは復元しないことをお勧めします。このようなデータベースには、意図しないTransact-SQLコードを実行したり、スキーマや物理的なデータベース構造を変更してエラーを引き起こしたりする悪意のあるコードが含まれている可能性があります。不明または信頼できないソースからのデータベースを使用する前に、非運用サーバー上のデータベースで DBCC CHECKDB を実行し、データベース内のストアドプロシージャや他のユーザー定義コードなどのコードも調べます。
不明なソースから不明なデータベースを復元すると、どのようなリスクがありますか？なし。
不明なアプリケーションがsysadminアカウントを使用してそのデータベースに接続し、コードの実行を開始できるようにするには、どのようなリスクがありますか？たくさん！アプリケーションアカウントがデータベース内でのみ権限を持ち、サーバーレベルのアクセス権を持たない場合、データベースの外部で実際に実行できることは何もありません。これは基本的に、最初にサーバー上で適切なセキュリティフレームワークをセットアップすることになります。
データベースのバックアップを受け取り、それをサーバー（既に他のデータベースをホストしている）に復元するように指示されましたが、バックアップに含まれる内容や、ソースを信頼する必要があるかどうかに関する有用な情報は提供されません。
いいね。あなたは、彼らが結果に対して完全な責任を負うことをこれを行うようにあなたに言っている誰からでも、署名された書面による声明を要求します。彼らがそれを望まない場合は、バックアップファイル（可能な場合）を調べた後、サンドボックスにインストールをテストし、すべてのテーブルや手順などを徹底的に調べてください。生産システム。それでも、バックアップを信頼したことがなく、直接の注文の下でのみこれを行っていることを（上司と上司に）明らかにする必要があります。
そのような声明に署名しない場合は、何かをする前に上司に警告してください。専門家として、あなたのシステムを可能な限り保護するのはあなたの義務です。あなたは解雇されるかもしれませんが、あなたは頭を高く保ち、あなたが正しいことをしたことを知ることができます。
ここで提案されているいくつかの遠大なものを除いて、言うには多くの危険はありません。言及したように、データベースのバックアップ自体に自動実行機能を含めることは困難です。何らかの外部トリガーメカニズムが必要です。
ライセンスに問題がある場合は、古いラップトップ/デスクトップとデータベースソフトウェア（SQLExpress）の評価版を入手してください。マシンにバックアップファイルをコピーし、ネットワーク/ワイヤレスを取り外し、復元を実行します。その後、掘り始めます。ものを隠すことができる場所はたくさんあるので、必要なすべての時間を取ってください。それらのほとんどは、このスレッドの他の投稿ですでにカバーされています。
DBAの整合性と運用環境の健全性は、上司からの注文よりも重要です。