不明なソースからバックアップを復元することのセキュリティへの影響

シナリオ：データベースのバックアップを渡され、サーバー（他のデータベースを既にホストしている）に復元するように指示されましたが、バックアップの内容やソースを信頼する必要があるかどうかに関する有用な情報は提供されません。

質問1：悪意のある可能性のあるバックアップの復元の潜在的な影響は何ですか？

質問2：悪意のある可能性のあるバックアップの復元の影響から、サーバー/他のデータベースのデータを保護するために何ができますか？RESTORE VERIFYONLY良い最初のステップのようです。最終的な答えは、おそらく「外の世界へのアクセスのないサンドボックスVMにデータベースを復元する」でしょうが、そのオプションはテーブルから外れていると仮定しましょう。この状況で他に何をすべきですか？

データベースには、悪意のあるコードが含まれている場合があります。これは、「sa」ログインのパスワードを変更するか、すべてのデータベースを削除する手順です。ただし、問題の原因を特定できる唯一の方法は、個人がデータベースを復元し、そのデータベース内のコードを手動で実行することです。自動化された方法では実行されません。

データベースをサーバーに復元するときに、SQL Serverがデータベース内の一部のコードを自動的に実行するようにデータベース内に適用できる設定はありません。もしそうなら、マイクロソフトが製品のCommon Criteria認定を失うことになると思います。DBMSで許可されているのは、これは大きなバグです。

あなたができるいくつかの予防手順があります。

1. 1人のシステム管理者のみが復元されたデータベースにアクセスできることを確認してください。
2. 復元が完了したら、データベースをシングルユーザーモードにします。
3. このデータベース内のすべてのストアドプロシージャおよび関数とトリガー内のコードを確認します。
4. dbcc checkdbを実行して、整合性の問題がないことを確認します。
5. データベースにアクセスしていたユーザーを確認し、それらをすべて削除します。
6. あなたがチェックした特定のオブジェクトに非常に制限されたアクセスの許可を開始します。

Shawnが言ったように、vbalidのようなストアドプロシージャに別の悪意のあるコードの実行権限がない限り、コードは単独では実行されません。これが、マルチユーザーモードにする前に、それぞれのコードをチェックする理由です。

私はここに到達していますが、少なくとも1つの危険なシナリオを考えることができます：filetableを持つデータベースを復元する場合、それらのファイルはデフォルトでネットワーク上にあります（具体的には、SQL Server上）。ウイルスを復元できます。

もちろん、それ自体は何もしません-ウイルスが突然知覚することはありません-しかし、ユーザーがファイルにアクセスしようとすると、感染する可能性があります。（ねえ、私は到達していると言いました。）私は、外部のハッカーがマルウェアをドアに入れたがっているシナリオを想像し、彼は会計でボブに「ここにファイルがある：\ sqlserver \ filetableshare \ myvirus.exe」-その時点で、検出されずにファイアウォールを通過し、内部のウイルス対策およびマルウェア対策ツールになりました。

復元を確認するのは良い最初のステップのようです。究極の答えは、おそらく「外の世界へのアクセスのないサンドボックスVMにデータベースを復元する」でしょうが、そのオプションはテーブルから外れていると仮定しましょう。この状況で他に何をすべきですか？

復元verifyonlyは、バックアップに悪意のあるコードが含まれているかどうかはわかりませんが、RESTORE VERIFYONLYはバックアップボリュームに含まれるデータの構造を検証しません。バックアップが企業内から行われた場合、悪意がある可能性は非常に低いですが、サードパーティからのものである場合は、Shawnが指摘したように注意する必要があります。

Microsoft Onlineのドキュメントによると

セキュリティ上の理由から、未知または信頼できないソースからデータベースをアタッチまたは復元しないことをお勧めします。このようなデータベースには、意図しないTransact-SQLコードを実行したり、スキーマまたは物理データベース構造を変更してエラーを引き起こす可能性のある悪意のあるコードが含まれている可能性があります。不明または信頼できないソースのデータベースを使用する前に、非実稼働サーバー上のデータベースでDBCC CHECKDBを実行し、データベース内のストアドプロシージャやその他のユーザー定義コードなどのコードも調べます。

質問は主にマルウェアを含むバックアップに焦点を当てていますが、復元操作自体から望ましくない、潜在的に悪意のある動作を取得することも可能です。

過去に誤って、破損したバックアップファイルを復元しようとするとSQL Serverがクラッシュし、SQL Serverがバックアップファイルの終わりを超えて読み取りを試み、クラッシュする可能性があることを発見しました。どのバージョンが影響を受けやすいのか、問題を再現するために何が必要なのかはわかりません。数年前にこの問題に遭遇したとき、私はここでいくつかの詳細を文書化しました。

未知のソースから未知のデータベースを復元することにはどのようなリスクがありますか？なし。

sysadminアカウントを使用して不明なアプリケーションを接続し、そのデータベースに接続してコードの実行を開始すると、どのようなリスクがありますか？たくさん！アプリケーションアカウントにデータベース内の権限のみがあり、サーバーレベルのアクセス権がない場合、データベースの外部で実際に実行できることは何もありません。これは基本的に、サーバーに適切なセキュリティフレームワークをセットアップすることから始まります。

データベースのバックアップを渡され、サーバー（既に他のデータベースをホストしている）に復元するように指示されますが、バックアップに含まれるものやソースを信頼する必要があるかどうかに関する有用な情報は提供されません。

いいね あなたは、結果に対して全責任を負うことをこれを行うようにあなたに言っている人に、署名された書面による声明を要求します。そうしたくない場合は、バックアップファイルを調べた後（可能な場合）、サンドボックスでインストールをテストし、すべてのテーブル、手順などを徹底的に調べてください。実動システム。それでも、（上司と上司に）バックアップを決して信用しておらず、これを直接の命令でのみ行っていることを明確にする必要があります。

そのような声明に署名しない場合は、何かを行う前に上司に警告してください。専門家として、あなたのシステムを可能な限り保護することはあなたの義務です。あなたは解雇されるかもしれませんが、頭を高く保ち、あなたが正しいことをしたことを知ることができます。

ここで提案されているいくつかの広範囲に及ぶものを除いて、言うごとに多くの危険はありません。既に述べたように、データベースのバックアップ自体に自動実行機能を組み込むことは困難です。何らかの外部トリガー機構が必要です。

ライセンスが問題になる場合は、古いラップトップ/デスクトップとデータベースソフトウェア（SQLExpress）の評価版を入手してください。マシンにバックアップファイルをコピーし、ネットワーク/ワイヤレスのプラグを抜き、復元を行います。その後、掘り始めます。物を隠す場所はたくさんあるので、必要なすべての時間をかけてください。それらのほとんどは、このスレッドの他の投稿ですでにカバーされています。

DBAの整合性と運用環境の健全性は、上司からの注文よりも重要です。