ผลกระทบด้านความปลอดภัยของการกู้คืนข้อมูลสำรองจากแหล่งที่ไม่รู้จักหรือไม่?

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

คำถามที่ 1 : ความหมายของการกู้คืนข้อมูลสำรองที่อาจเป็นอันตรายได้อย่างไร

คำถามที่ 2 : คุณสามารถปกป้องเซิร์ฟเวอร์ / ข้อมูลในฐานข้อมูลอื่นจากผลกระทบของการกู้คืนข้อมูลสำรองที่อาจเป็นอันตรายได้อย่างไร RESTORE VERIFYONLYดูเหมือนจะเป็นก้าวแรกที่ดี คำตอบที่ดีที่สุดคือ 'กู้คืนฐานข้อมูลใน sandbox VM โดยไม่ต้องเข้าถึงโลกภายนอก' แต่ลองสมมติว่าตัวเลือกนั้นอยู่นอกตาราง ควรทำอะไรในสถานการณ์นี้

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

ไม่มีการตั้งค่าที่สามารถนำไปใช้ภายในฐานข้อมูลเพื่อให้ SQL Server รันโค้ดบางอย่างภายในฐานข้อมูลโดยอัตโนมัติเมื่อทำการกู้คืนไปยังเซิร์ฟเวอร์ ถ้าเป็นเช่นนั้นฉันคาดว่า Microsoft จะปล่อยใบรับรอง Common Criteria สำหรับผลิตภัณฑ์ นั่นคือข้อผิดพลาดที่ดีในการได้รับอนุญาตใน DBMS ให้ฉัน

มีขั้นตอนการป้องกันที่คุณสามารถทำได้

1. ตรวจสอบให้แน่ใจว่าไม่มีใครยกเว้น sysadmin หนึ่งเข้าถึงฐานข้อมูลที่กู้คืน
2. วาง db ในโหมดผู้ใช้เดี่ยวหลังจากการกู้คืนเสร็จสมบูรณ์
3. ตรวจสอบรหัสภายในโพรซีเดอร์และฟังก์ชันที่เก็บไว้ทั้งหมดและทริกเกอร์ภายในฐานข้อมูลนี้
4. ดำเนินการ dbcc checkdb เพื่อให้แน่ใจว่าไม่มีปัญหาด้านความสมบูรณ์
5. ตรวจสอบผู้ใช้ที่เคยเข้าถึงฐานข้อมูลและลบผู้ใช้ทั้งหมด
6. เริ่มอนุญาตการเข้าถึงซึ่ง จำกัด เฉพาะวัตถุที่คุณตรวจสอบมาก

เช่นเดียวกับ Shawn ที่กล่าวว่ารหัสจะไม่ทำงานด้วยตัวเองยกเว้นบางขั้นตอนการจัดเก็บซึ่งดูเหมือนว่า vbalid จะมี exec ของรหัสที่เป็นอันตรายอื่น นี่คือเหตุผลของการตรวจสอบรหัสภายในแต่ละรายการก่อนที่จะวางโหมดผู้ใช้หลายคน

ฉันมาถึงที่นี่ แต่ฉันสามารถนึกถึงสถานการณ์ที่เป็นอันตรายอย่างน้อยหนึ่งสถานการณ์: ถ้าคุณกู้คืนฐานข้อมูลที่มีตารางไฟล์ตอนนี้ไฟล์เหล่านั้นจะอยู่ในเครือข่ายของคุณตามค่าเริ่มต้น (และโดยเฉพาะบน SQL Server ของคุณ) คุณสามารถกู้คืนไวรัสได้

โดยตัวมันเองจะไม่ทำอะไรเลยแน่นอนว่าไวรัสไม่ได้กลายเป็นความรู้สึกฉับพลัน แต่ถ้าผู้ใช้ของคุณลองเข้าถึงไฟล์พวกเขาอาจติดไวรัสได้ (เฮ้ฉันบอกว่าฉันไปถึงแล้ว) ฉันจินตนาการถึงสถานการณ์ที่แฮกเกอร์ข้างนอกต้องการรับมัลแวร์ที่ประตูแล้วเขาก็ส่งอีเมลไปหา Bob ในบัญชีโดยบอกว่า "นี่คือไฟล์: \ sqlserver \ filetableshare \ myvirus.exe "- ณ จุดนี้มันผ่านไฟร์วอลล์ของคุณโดยไม่มีการตรวจจับและตอนนี้เรากำลังลงสู่เครื่องมือป้องกันไวรัสและมัลแวร์ภายในของคุณ

การคืนค่าการยืนยันจะเป็นขั้นตอนแรกที่ดี คำตอบที่ดีที่สุดน่าจะเป็น 'กู้คืนฐานข้อมูลใน sandbox VM ที่ไม่มีการเข้าถึงโลกภายนอก' แต่สมมติว่าตัวเลือกนั้นอยู่นอกตาราง ควรทำอะไรในสถานการณ์นี้

คืนค่าการตรวจสอบยืนยันความถูกต้องของฐานข้อมูลเท่านั้นจะไม่บอกคุณว่าการสำรองข้อมูลรวมถึงรหัสที่เป็นอันตรายหรือไม่ RESTORE VERIFYONLY ไม่ได้พยายามตรวจสอบโครงสร้างของข้อมูลที่มีอยู่ในปริมาณการสำรองข้อมูล ไม่ชอบอย่างมากว่าถ้าการสำรองข้อมูลมาจากภายใน บริษัท ที่คุณทำงานอาจเป็นอันตราย แต่ถ้ามาจากบุคคลที่สามคุณต้องระวังอย่าง Shawn ชี้

เอกสาร Microsoft Online บอกว่า

•เพื่อความปลอดภัยเราขอแนะนำให้คุณไม่แนบหรือกู้คืนฐานข้อมูลจากแหล่งที่ไม่รู้จักหรือไม่น่าเชื่อถือ ฐานข้อมูลดังกล่าวอาจมีรหัสที่เป็นอันตรายที่อาจเรียกใช้รหัส Transact-SQL โดยไม่ได้ตั้งใจหรือทำให้เกิดข้อผิดพลาดโดยการแก้ไข schema หรือโครงสร้างฐานข้อมูลทางกายภาพ ก่อนที่คุณจะใช้ฐานข้อมูลจากแหล่งที่ไม่รู้จักหรือไม่น่าเชื่อถือให้รันDBCC CHECKDBบนฐานข้อมูลบนเซิร์ฟเวอร์ที่ไม่ได้ใช้งานและตรวจสอบรหัสเช่นขั้นตอนการจัดเก็บหรือรหัสที่ผู้ใช้กำหนดอื่น ๆ ในฐานข้อมูล

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

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

มีความเสี่ยงอะไรในการกู้คืนฐานข้อมูลที่ไม่รู้จักจากแหล่งที่ไม่รู้จัก ไม่มี.

มีความเสี่ยงอะไรในการอนุญาตให้แอปพลิเคชันที่ไม่รู้จักเชื่อมต่อโดยใช้บัญชีดูแลระบบเพื่อเชื่อมต่อกับฐานข้อมูลนั้นและเริ่มต้นเรียกใช้รหัส จำนวนมาก! หากบัญชีแอปพลิเคชันมีสิทธิ์ในฐานข้อมูลเท่านั้นและไม่สามารถเข้าถึงระดับเซิร์ฟเวอร์ได้จะไม่มีสิ่งใดที่สามารถทำได้นอกฐานข้อมูล โดยพื้นฐานแล้วสิ่งนี้จะเกิดขึ้นกับการตั้งค่ากรอบความปลอดภัยที่เหมาะสมบนเซิร์ฟเวอร์เพื่อเริ่มต้น

คุณได้ส่งการสำรองฐานข้อมูลและบอกให้คืนค่าไปยังเซิร์ฟเวอร์ (ที่โฮสต์ฐานข้อมูลอื่นอยู่แล้ว) แต่ไม่ได้รับข้อมูลที่เป็นประโยชน์เกี่ยวกับการสำรองข้อมูลที่มีหรือว่าแหล่งข้อมูลนั้นควรเชื่อถือได้หรือไม่

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

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

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

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

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