なぜBULK INSERTは危険と見なされますか？

21

一般にサイバーセキュリティチーム（私が扱った複数の組織）がBULK INSERTアプリケーションやデータベースプログラマーに（TSQLなどの）権利を付与することに対して何の不満があるのかを理解したいと思いますか？最終的な結果は次のようなことを行うアプリケーションと変わらないため、何かを逃さない限り、「ディスクの乱用を埋める」という言い訳は信じられません。

for (long i = 0; i < LONG_MAX; ++i)
    executeSQL("INSERT INTO table VALUES(...)");

これINSERTは、基本的な書き込み権限を持つ人が実行できる一般的なDMLコマンドです。

アプリケーションの利点として、BULK INSERTはるかに効率的で高速であり、プログラマーはSQLの外部でファイルを解析する必要がなくなります。

編集：私はもともと情報セキュリティサイトでこの質問をしました-BULK INSERTを使用することに反対しているのはDBAではなく、「情報保証」（略してIA-サイバーセキュリティの人々）が問題を強要しているからです。この質問をあと1日か2日シチューさせますが、バルク操作が実際に制約またはトリガーをバイパスする場合、問題であることがわかります。

— ジャックLT
ソース

19

おそらく未知のリスクと同じくらい多くの根拠のない恐怖があることを考えると、なぜ彼らが懸念しているのかを作成した人に尋ねることなく、なぜ政策が実施されているのかを本当に言うことは難しいと思います。

しかし、おそらくBULK INSERT/ SqlBulkCopy/ BCP / OPENROWSET(BULK ...)誰かができることと関係があると思います：

無効な制約（CHECK、DEFAULT、とFOREIGN KEY私は信じています）
トリガーを無効にします（監査トリガーが存在する場合、それらをバイパスすることはおそらく望ましくないと見なされます。この特定の問題の詳細については、@ DVKsの回答を参照してください）

さまざまなオプションについては、次のドキュメントで説明しています。

@RDFozzで指摘されているテーブルロックの問題については言及しませんでした。これは、BULK INSERT誰もがTABLOCK / XLOCKをテーブル化したり、に設定したりできるTRANSACTION ISOLATION LEVELからSERIALIZABLEです。

更新

これを絞り込むのに役立つ可能性のある2つの追加情報に出会いました。

トリガーを無効にし、制約を無効にし、設定できるという問題は、（SQL Server 2017以降）、またはサーバーの役割を脅威として見るのに圧倒的な理由でIDENTITY_INSERT ONはないかもしれません。理由は、上記の3つのいずれかを実行するために、ユーザーはそのテーブルまたはテーブルが存在するスキーマに対する権限を持っている必要があるためです。所有権の連鎖はDDLの変更をカバーしません。そのため、ユーザーがを持たない場合、これら3つのことを実行する機能は問題になりません。ADMINISTER BULK OPERATIONSADMINISTER DATABASE BULK OPERATIONSbulkadminALTER TABLEALTER TABLE
何これまで議論されておらず、どのような最終的にはあるかもしれないセキュリティの問題は、両方のことですし、アクセス外部リソース、SQL Serverの外部に。Windowsログイン経由でSQL Serverにアクセスする場合、ファイルシステムアクセスを実行するために、Windowsアカウントが偽装されます（セキュリティコンテキストをを使用して切り替えても）。つまり、読み取り権限が付与されているファイルのみを読み取ることができます。それについて何も悪いことはありません。BULK INSERTOPENROWSET(BULK...EXECUTE AS LOGIN='...'

ただし、 SQL Serverログイン経由でSQL Serverにアクセスする場合、外部アクセスはSQL Serverサービスアカウントのコンテキストで行われます。これは、このアクセス許可を持つユーザーが、他の方法では読み取ることができないファイルや、アクセスできないフォルダー内のファイルを読み取ることができることを意味します。

少なくとも、SQL ServerがSQL Server専用に作成されたアカウントとして実行されるように設定されている場合（推奨される方法）、そのようなユーザーは「SQL Server」アカウントがアクセスできるファイルのみを読み取ることができます。これは限られた問題ですが、SQL Serverログファイルなどのファイルを読み取ることができます（次の例をテストしましたが、動作します）。
```
SELECT tmp.[Col1]
FROM   OPENROWSET(BULK
   N'C:\Program Files\Microsoft SQL Server\MSSQLxx.InstanceName\MSSQL\Log\ERRORLOG.1',
                  SINGLE_NCLOB) tmp([Col1]);
```
ほとんどの人はMSSQL \ Logフォルダーにアクセスできないため、これは既存のセキュリティ制限を回避する方法です。

また、SQL ServerがLocal Systemアカウントとして実行されている場合、問題の範囲が拡大するだけで、このアクセス許可を持つユーザーは広範なシステム関連ファイルを読み取ることができると思われます。

そして、これが、バルクインポートを行う他の方法（BCPおよびSqlBulkCopy-）がbulkadmin許可/役割を必要としない理由である可能性があります。そのような場合、SQL Serverはファイルを読み取ることはなく（またはSQL Serverの外部に到達することもありません）、外部プロセスによって読み取られるファイルからインポートするデータを受信するだけです。

考えられる意味は別として、それは質問で言われました：

アプリケーションの利点として、バルク挿入ははるかに効率的で高速です。

OK

また、SQL以外のファイルを解析する必要性からプログラマを解放します。

おっとネリー。ここで止めましょう。T-SQLは通常、解析に最適な言語の選択肢ではありません。多くの場合、DBにデータを挿入する前に解析を行うのが最善です。これを行う1つの方法は、テーブル値パラメーター（TVP）を使用することです。前述のデータの効率的な一括インポートとともに、事前解析と検証のトピックを扱う別の質問（ここDBA.StackExchange）への私の回答を参照してください。

T-SQL：カスタム解析された数値データ、ルックアップ値を含むCSV-> tableパイプライン

— ソロモン・ラツキー
ソース

レプリケーションが適切に行われている場合、一括挿入に関して追加の考慮事項があります。

— -mustaccio

6

これは、以前の回答（ "... disable triggers "）で示唆されていましたが、ビジネスの観点から無効化が望ましくない理由を説明していません。

多くのビジネスでは、メインテーブルのトリガーは次の目的で使用されます。

整合性制約の検証（DB制約で通常使用されるよりも複雑なビジネスロジックを持つもの）
さらに重要なことは、データを監査することです。具体的には、対応する監査テーブルにデータを挿入します（またはメインテーブルの監査フィールドを更新します）。

前者の問題が何であるかは明らかです（アプリケーションは、ダウンストリーム処理に悪影響を与える不正なデータを挿入する可能性があります）。後者に関しては、トリガーが無効になっている場合、監査情報がないため、監査の観点から2つの問題が発生します。

まず、グループとしての監査ではデータの変更を監査できなくなり、内部監査としての主要な機能を実行できなくなります。
第二に、監査記録の欠如は、企業が管理している監査要件（SAS 70など）に違反している可能性があります。これにより、企業は契約違反の責任を負うことになります。

— DVK
ソース

こんにちは。ここで望ましくないことの説明に異議はありません。詳細を感謝しますが、記録のためだけに、監査トリガーがある場合はトリガーを無効にすることは望ましくないと述べました。確かに、それは詳細な説明ではありませんが、「説明されていない」と言うのは正確ではありません。それはあまりにも単純すぎる、または監査トリガーに関する十分な説明を提供せず、検証について言及していなかったと言う方が良いかもしれません（そして、それについて言及するための+1、および全体的な追加の詳細について）。ちょっとした考え。

— ソロモンラッツキー

@SolomonRutzky-私は、答えが「なぜ説明しないのか」が問題であることを明確に示しました:)ビジネス上の問題を定義できない場合; 技術的な詳細は、多くの場合、特にIAとビジネスベースの議論をしているOPには無関係です。言い換えると、「ああ、監査トリガーが無効になっている可能性がある」と言うと、IAは「tatは私たちにとって何を意味するのか？」と尋ねます。-彼らは通常、DBAや開発者ではありません。

— DVK

OK。最初の文を読んで、「トリガーを無効にすることは望ましくないが、その理由は説明しなかった」と答えただけだと思います。そして、はい、私は一般に問題を適切に定義する必要性についてあなたに同意します、私はOPが監査メカニズムを無効にすることの意味を理解していると仮定しました（常に最良のポリシーではないかもしれません;-)。私が間違っている場合、ありがたいことにあなたはその情報をここに提供しました。そして、その目的のためにこれにリンクするように私の答えを更新しました:)

— ソロモンラッツキー

6

別の可能性は、BULK INSERT操作の実行の影響です。

通常、この種の作業は、通常のアクティビティを妨げないように、可能な場合は営業時間外に実行されます。一括挿入は、テーブルを数時間ロックし、他の挿入（および選択、更新、削除）が行われないようにします。

または、セキュリティの観点から、DoS攻撃と非常によく似た結果を生成できます。

確かに、トランザクションと単純なINSERTステートメントを使用して、偶発的または故意にこれを行うことができます。ただし、意図したとおりに一括挿入プロセスを使用すると、この影響が生じる可能性があります。

一般に、バックアップやその他のスケジュールされたジョブがすべて完了していることを確認する必要があるため、営業時間外のアクティビティの整理にDBAが関与することを期待します。このようなアクティビティを十分に考慮せずにこのようなことをスケジュールすると、バックアップが失敗することがあります。これはいくつかの理由で問題になる可能性があります。

— RDFozz
ソース

2

この理由の1つは、アクションのログを明確にすることです。すべてのアクションがログファイルの1つのエントリに対応している場合、追加の参照なしで問題を引き起こした何かを見るのはかなり簡単です。ログファイルに「INSERT FROM external.file」と書かれていて、external.fileがなければ、それ以上何も言えません。

もちろん、ロギングの動作を変更することもできますが、出発点として、ロギング内であってもすべてのアクションをアトミックにすることはひどい考えではありません。