BULK INSERTが危険と見なされるのはなぜですか？
アプリケーションやデータベースプログラマーに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日おきますが、一括操作で実際に制約やトリガーがバイパスされる場合は、問題であることがわかります。
別の可能性は、BULK INSERT操作の実行による影響です。
通常、この種のことは、通常の活動を妨げないように、可能であれば営業時間外に実行されます。一括挿入を行うと、テーブルが数時間ロックされ、他の挿入（および選択、更新、削除）が行われなくなる可能性があります。
または、セキュリティの観点からは、DoS攻撃と非常によく似た結果が生成される可能性があります。
確かに、トランザクションと単純なINSERTステートメントを使用して、これを誤ってまたは故意に行うことができます。ただし、一括挿入プロセス意図したとおりを使用すると、この影響が生じる可能性があります。
一般に、バックアップとその他のスケジュールされたジョブがすべて完了していることを確認する必要があるため、DBAは時間外活動の編成に関与することを期待します。人々がそのような活動を十分に考慮せずにこのようなことをスケジュールすると、バックアップが失敗することがわかります。これは、いくつかの理由で問題になる可能性があります。
これは、以前の回答（ "...disable triggers"）でほのめかされていましたが、説明はありませんwhy無効にすることは、ビジネスの観点から望ましくありません。
多くのビジネスでは、メインテーブルのトリガーは次の目的で使用されます。
整合性制約を検証する（ビジネスロジックがDB制約で通常使用されるよりも複雑な制約）
さらに重要なことは、データを監査すること、具体的には対応する監査テーブルにデータを挿入すること（またはメインテーブルの監査フィールドを更新すること）です。
前者の問題が何であるかは明らかです（アプリケーションは、下流の処理に悪影響を与える不良データを挿入する傾向があります）。後者の場合、トリガーが無効になっていると、監査情報がなく、監査の観点から2つの問題が発生します。
まず、グループとしての監査では、データの変更を監査できなくなるため、内部監査としての主要な機能を実行できなくなります。
第2に、監査記録の欠如は、会社が管理している監査要件の違反である可能性があります（例SAS 70）-これにより、会社は契約違反の責任を負うことになります。
この理由の1つは、アクションのログを明確にすることにあります。すべてのアクションがログファイルの1つのエントリに対応している場合、追加の参照なしで問題の原因となったものを確認することはかなり簡単です。ログファイルに「INSERT FROM external.file」と表示されていて、external.fileがない場合、これ以上何もわかりません。
もちろん、ロギングの動作を変更することもできますが、開始点として、ロギング内であってもすべてのアクションをアトミックにすることはひどい考えではありません。