เพราะเหตุใด INSERT BULK จึงถือว่าเป็นอันตราย

ฉันต้องการที่จะเข้าใจว่าทำไมทีมรักษาความปลอดภัยทางไซเบอร์โดยทั่วไป (มากกว่าหนึ่งองค์กรที่ฉันจัดการ) ถูกตั้งค่าให้ตายต่อการให้สิทธิ์BULK INSERT(เช่น TSQL) กับแอปพลิเคชันและโปรแกรมเมอร์ฐานข้อมูล ฉันไม่อยากจะเชื่อข้อแก้ตัว "เติมดิสก์ที่ไม่เหมาะสม" เว้นแต่ฉันจะพลาดบางสิ่งเนื่องจากผลลัพธ์ที่ได้ไม่ต่างจากแอพพลิเคชั่นที่ทำสิ่งต่อไปนี้:

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

และINSERTเป็นคำสั่ง DML ทั่วไปที่ทุกคนที่มีสิทธิ์เขียนขั้นพื้นฐานสามารถดำเนินการได้

เพื่อประโยชน์ของแอปพลิเคชันBULK INSERTมีประสิทธิภาพมากขึ้นเร็วขึ้นและบรรเทาความต้องการโปรแกรมเมอร์ในการแยกวิเคราะห์ไฟล์นอก SQL

แก้ไข: เดิมฉันถามคำถามนี้ในเว็บไซต์ความปลอดภัยของข้อมูลด้วยเหตุผล - ไม่ใช่ DBA ที่ขัดกับการใช้ BULK INSERT มันคือ "การรับรองข้อมูล" (IA สำหรับย่อ - กลุ่มความปลอดภัยทางไซเบอร์) ที่บังคับให้ออก ฉันจะปล่อยให้คำถามนี้ตุ๋นอีกหนึ่งหรือสองวัน แต่ถ้าการดำเนินการเป็นกลุ่มทำผ่านข้อ จำกัด หรือทริกเกอร์แน่นอนฉันจะเห็นว่าเป็นปัญหา

เนื่องจากอาจมีความกลัวที่ไม่มีมูลความจริงมากเท่าที่มีความเสี่ยงที่ไม่รู้จักฉันจะคิดว่าเป็นการยากที่จะพูดว่าทำไมนโยบายถึงเกิดขึ้นโดยไม่ถามใครก็ตามที่สร้างนโยบายขึ้นมาว่าทำไมพวกเขาถึงกังวล

อย่างไรก็ตามฉันเดาว่ามันอาจจะเกี่ยวข้องกับสิ่งที่BULK INSERT/ SqlBulkCopy/ BCP / OPENROWSET(BULK ...)อนุญาตให้คนทำคือ:

1. ปิดการใช้งาน จำกัด ( CHECK, DEFAULTและFOREIGN KEYผมเชื่อว่า)
2. ปิดการใช้งานทริกเกอร์ (หากมีทริกเกอร์การตรวจสอบในสถานที่โดยผ่านพวกเขาอาจจะถือว่าไม่พึงประสงค์สำหรับคำอธิบายเพิ่มเติมเกี่ยวกับปัญหานี้โดยเฉพาะโปรดดู@DVKs ตอบ )

ตัวเลือกต่าง ๆ อธิบายไว้ในเอกสารประกอบต่อไปนี้:

• SqlBulkCopyOptions Enum
• แทรกเป็นกลุ่ม

ผมไม่ได้พูดถึงปัญหาตารางล็อคที่ระบุไว้โดย @RDFozz เนื่องจากว่าเป็นไปไม่ได้เฉพาะเจาะจงBULK INSERT: ตารางสามารถทุกคน TABLOCK / XLOCK หรือตั้งเพื่อTRANSACTION ISOLATION LEVELSERIALIZABLE

UPDATE

ฉันเจอข้อมูลเพิ่มเติมอีกสองชิ้นที่อาจช่วย จำกัด เรื่องนี้:

1. ปัญหาของความสามารถในการทริกเกอร์ปิดการใช้งานปิดการใช้งานข้อ จำกัด และชุดIDENTITY_INSERT ONอาจจะไม่ได้เป็นเหตุผลที่ครอบงำเพื่อดูADMINISTER BULK OPERATIONS, ADMINISTER DATABASE BULK OPERATIONS(เริ่มต้นด้วย SQL Server 2017) หรือbulkadminบทบาทเซิร์ฟเวอร์เป็นภัยคุกคาม เหตุผลก็คือเพื่อที่จะทำสิ่งใด ๆ ในสามสิ่งที่กล่าวถึงนี้ผู้ใช้จำเป็นต้องได้ALTER TABLEรับอนุญาตในตารางนั้นหรือบน Schema ที่มีอยู่ในตารางการผูกมัดการเป็นเจ้าของไม่ครอบคลุมการแก้ไข DDL ดังนั้นหากผู้ใช้ไม่มีALTER TABLEความสามารถในการทำสามสิ่งเหล่านี้จึงไม่ใช่ปัญหา

2. สิ่งที่ยังไม่ได้รับการกล่าวถึงเพื่อให้ห่างไกลและสิ่งที่ท้ายที่สุดอาจจะปัญหาด้านความปลอดภัยคือทั้งสองและการเข้าถึงทรัพยากรภายนอกนอกของ SQL Server เมื่อเข้าถึง SQL Server ผ่านทางเข้าสู่ระบบ Windows บัญชี Windows นั้นจะถูกเลียนแบบ (แม้ว่าคุณจะเปลี่ยนบริบทการรักษาความปลอดภัยโดยใช้) สำหรับการเข้าถึงระบบไฟล์ ซึ่งหมายความว่าคุณสามารถอ่านไฟล์ที่ได้รับอนุญาตให้อ่านเท่านั้น ไม่มีอะไรผิดปกติกับที่BULK INSERTOPENROWSET(BULK...EXECUTE AS LOGIN='...'

   แต่เมื่อเข้าถึง SQL Server ผ่านการเข้าสู่ระบบของเซิร์ฟเวอร์ SQL การเข้าถึงภายนอกจะกระทำในบริบทของบัญชีบริการ 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 จะไม่อ่านไฟล์ (หรือไปถึงนอก SQL Server) เพียงแค่รับข้อมูลที่จะนำเข้าจากไฟล์ที่กำลังอ่านโดยกระบวนการภายนอก

ความหมายที่เป็นไปได้กันก็ถูกกล่าวในคำถาม

เพื่อประโยชน์ของแอปพลิเคชัน BULK INSERT นั้นมีประสิทธิภาพมากกว่ารวดเร็วกว่า ..

ตกลงไป ...

และบรรเทาความต้องการโปรแกรมเมอร์ในการแยกไฟล์นอก SQL

Whoa Nelly หยุดตรงนี้กัน T-SQL ไม่ใช่ทางเลือกภาษาที่ดีที่สุดสำหรับการวิเคราะห์คำ มันเป็นการดีที่สุดที่จะทำการแยกวิเคราะห์ก่อนที่จะแทรกสิ่งต่างๆลงในฐานข้อมูล วิธีหนึ่งในการทำเช่นนี้คือการใช้พารามิเตอร์ที่มีมูลค่าแบบตาราง (TVPs) โปรดดูคำตอบของฉันคำถามอื่น (ที่นี่ใน DBA.StackExchange) ที่เกี่ยวข้องกับหัวข้อของก่อนการแยกและการตรวจสอบพร้อมกับกลุ่มที่มีประสิทธิภาพในการนำเข้าของข้อมูลกล่าวว่า:

T-SQL: CSV-> ไพพ์ไลน์ของตารางที่มีข้อมูลตัวเลขแบบแยกวิเคราะห์ที่กำหนดเองค่าการค้นหา

นี่เป็นการพูดพาดพิงถึงคำตอบก่อนหน้า ("... ปิดการใช้งานทริกเกอร์ ") แต่ไม่ได้อธิบายว่าทำไมการปิดใช้งานจึงไม่เป็นที่ต้องการจากมุมมองทางธุรกิจ

ในธุรกิจจำนวนมากทริกเกอร์ในตารางหลักถูกใช้เพื่อ:

1. ตรวจสอบข้อ จำกัด ด้านความสมบูรณ์ (ผู้ที่มีตรรกะทางธุรกิจซับซ้อนกว่าปกติจะใช้ในข้อ จำกัด ฐานข้อมูล)

2. ที่สำคัญกว่านั้นคือการตรวจสอบข้อมูลโดยเฉพาะเพื่อแทรกข้อมูลลงในตารางการตรวจสอบที่สอดคล้องกัน(หรือปรับปรุงเขตการตรวจสอบในตารางหลัก)

ค่อนข้างชัดเจนว่าปัญหาของอดีตคืออะไร (แอปพลิเคชันของคุณมีแนวโน้มที่จะแทรกข้อมูลที่ไม่ดีซึ่งมีผลเสียต่อการประมวลผลดาวน์สตรีม) ถ้าหากทริกเกอร์ถูกปิดใช้งานคุณไม่มีข้อมูลการตรวจสอบใด ๆ ซึ่งทำให้เกิดปัญหาสองประการจากมุมมองการตรวจสอบ:

• ประการแรกการตรวจสอบในฐานะกลุ่มไม่สามารถตรวจสอบการเปลี่ยนแปลงข้อมูลได้อีกต่อไปดังนั้นจึงไม่สามารถทำหน้าที่หลักในการตรวจสอบภายในได้

• ประการที่สองการขาดบันทึกการตรวจสอบอาจเป็นการละเมิดข้อกำหนดการตรวจสอบที่ บริษัท ถูกควบคุมโดย (เช่น SAS 70) - ซึ่งอาจทำให้ บริษัท ของคุณต้องรับผิดชอบต่อการละเมิดสัญญา

ความเป็นไปได้อีกอย่างก็คือผลกระทบของการใช้BULK INSERTงานการดำเนินการ

โดยปกติสิ่งเหล่านี้จะถูกเรียกใช้นอกเวลาทำการถ้าเป็นไปได้เพื่อไม่ให้รบกวนกิจกรรมปกติ เม็ดมีดจำนวนมากอาจล็อคตารางเป็นเวลาหลายชั่วโมงป้องกันไม่ให้เม็ดมีดอื่นเกิดขึ้น (รวมถึงการเลือกอัปเดตหรือลบ)

หรือจากมุมมองด้านความปลอดภัยก็สามารถสร้างผลลัพธ์ที่คล้ายกันมากกับการโจมตี DoS

เป็นที่ยอมรับว่าใครสามารถทำได้ทั้งโดยบังเอิญหรือโดยเจตนากับการทำธุรกรรมและINSERTข้อความธรรมดา อย่างไรก็ตามการใช้กระบวนการแทรกจำนวนมากตามที่ตั้งใจสามารถทำให้เกิดผลกระทบนี้

โดยทั่วไปฉันคาดหวังว่า DBA จะมีส่วนร่วมในการจัดกิจกรรมนอกเวลาทำงานเนื่องจากพวกเขายังต้องแน่ใจว่าการสำรองข้อมูลและงานอื่น ๆ หากผู้คนต้องกำหนดเวลาสิ่งเหล่านี้โดยไม่พิจารณาอย่างเพียงพอสำหรับกิจกรรมดังกล่าวคุณอาจเห็นการสำรองข้อมูลล้มเหลวซึ่งอาจเป็นปัญหาด้วยเหตุผลหลายประการ

เหตุผลข้อหนึ่งอาจทำให้การบันทึกการกระทำชัดเจน หากทุกการกระทำสอดคล้องกับหนึ่งรายการในล็อกไฟล์มันค่อนข้างง่ายที่จะเห็นสิ่งที่ทำให้เกิดปัญหาโดยไม่มีการอ้างอิงเพิ่มเติม หากไฟล์บันทึกของคุณระบุว่า "INSERT FROM external.file" โดยไม่มี external.file คุณจะไม่สามารถบอกอะไรเพิ่มเติมอีก

แน่นอนคุณสามารถปรับเปลี่ยนวิธีการบันทึก แต่เป็นจุดเริ่มต้นบังคับให้ทุกการกระทำเป็นอะตอมแม้ในการบันทึกไม่ใช่แนวคิดที่แย่