มีความปลอดภัยมากกว่าหรือไม่ในการใช้ฐานข้อมูลที่ 3 เพื่อเชื่อมต่อสองฐานข้อมูลโดยใช้การล็อกอินเดียวกัน

เรามีการตั้งค่าต่อไปนี้:

• ฐานข้อมูลการผลิตหลายรายการที่มีข้อมูลส่วนตัวซึ่งใช้โดยซอฟต์แวร์เดสก์ท็อป
• ฐานข้อมูลเว็บสำหรับเว็บไซต์สาธารณะที่ต้องการข้อมูลบางส่วนจากฐานข้อมูลส่วนตัว
• ฐานข้อมูลกลางที่มีมุมมองไม่กี่และขั้นตอนการจัดเก็บที่ดึงข้อมูลจากฐานข้อมูลส่วนตัว

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

บัญชีผู้ใช้มีการเข้าถึงแบบเต็มไปยังฐานข้อมูลบนเว็บและฐานข้อมูลตัวกลาง แต่สามารถเข้าถึงมุมมองเฉพาะและขั้นตอนการจัดเก็บของฐานข้อมูลส่วนตัวและเฉพาะ

นี่ปลอดภัยกว่าการทำให้ฐานข้อมูลสาธารณะเชื่อมต่อโดยตรงกับฐานข้อมูลส่วนตัวหรือไม่?

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

มีสิ่งหนึ่งที่กระโดดออกจากที่นี่:

กระบวนการทั้งหมดใช้ชุดข้อมูลรับรองการเข้าสู่ระบบชุดเดียวกัน

ปัญหา

สมมุติว่า userX (ไม่ว่าจะเป็น meatsack บางตัวที่ใช้ Excel หรือ IIS AppPool Identity) สามารถเห็นบางมุมมองและโค้ด ไม่สำคัญว่ามุมมองและรหัสเหล่านี้อยู่ในฐานข้อมูลใดเนื่องจาก userX ตั้งค่าในฐานข้อมูล 3 ตัว

อย่างไรก็ตามคุณสูญเสียการผูกมัดแบบนี้

สมมติว่าโทรWebDB.dbo.SomeProc PrivateDB.dbo.SomeTableUserX ต้องการสิทธิ์ใช้งานทั้งสองวัตถุ ถ้านี่คือการOneDB.WebGUI.SomeProcใช้งานOneDB.dbo.SomeTableแล้วเท่านั้นOneDB.WebGUI.SomeProcสิทธิ์ที่ต้องการ สิทธิ์ในวัตถุที่อ้างอิงกับเจ้าของคนเดียวกันจะไม่ถูกตรวจสอบ

หมายเหตุ: ฉันไม่ได้มองลึกเกินไปที่ฐานข้อมูลข้ามผูกมัดเป็นเจ้าของ ฉันเพียงรู้ธรรมดาเก่า"เจ้าของผูกมัด"ดี

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

ฐานข้อมูล "ส่วนตัว" อื่น ๆ อาจรวมกันได้ แต่นั่นจะเป็นปัญหาแยกต่างหาก ดูลิงค์ด้านล่างสำหรับการสนทนาแบบเต็ม "ฐานข้อมูลหนึ่งหรือหลาย"

วิธีการแก้?

หากฐานข้อมูลเพิ่มเติมเป็นคอนเทนเนอร์รหัสเท่านั้นดังนั้นสกีมาเป็นแนวคิดที่ดีกว่า

ดูเหมือนว่าคุณใช้ "ฐานข้อมูล" ซึ่งคุณควรใช้ "Schema" (ในความหมายของ SQL Server ไม่ใช่ความรู้สึกของ MySQL) ฉันมี WebGUI schema, Helper หรือ Common schema (เพื่อแทนที่ฐานข้อมูลระดับกลาง) และ schema ของเดสก์ท็อป วิธีนี้คุณแยกการอนุญาตตามไคลเอ็นต์และมีฐานข้อมูลเดียว

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับสกีมาดูคำถามเหล่านี้:

• การออกแบบ Schema - แนวทางปฏิบัติที่ดีที่สุด
• ใช้งานเกิน / ใช้งาน schema อย่างถูกต้อง?

ในที่สุดก็ไม่มีเหตุผลที่จะมีฐานข้อมูลแยกกันโดยยึดตาม "ความสมบูรณ์ของธุรกรรมไม่จำเป็นต้องใช้" ดูคำถามนี้เพื่ออธิบายสิ่งนี้: เกณฑ์การตัดสินใจว่าเมื่อใดควรใช้ schema ที่ไม่ใช่ dbo เทียบกับฐานข้อมูลใหม่

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

ถ้าไม่ฉันไม่คิดว่ามันจะเพิ่มอะไรนอกจากความซับซ้อน

แก้ไข:

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

ในกรณีแรก WTF? ตัดออก มันไม่มีค่าอะไรนอกจากมีคนต้องการตรวจสอบมันเพื่อเข้าถึงโปรไฟล์ของ PrivateDB อย่างเกียจคร้าน (และทำให้นักพัฒนา WebApp ทำงานหนักขึ้น) SQL Profiler สามารถกรองโดยใช้ DB_ID ...

ในกรณีที่สองฉันคงคำตอบก่อนหน้าของฉัน

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

การมีตัวกลางหมายความว่าผู้บุกรุกจะต้องขุดรหัสของคุณรู้ว่ามีอยู่ของ IntermDB - และมันต้องขุดรหัสของคุณเพื่อที่จะรู้ว่ามี PrivateDB อยู่

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

นอกจากนี้คุณยังได้รับข้อดีอื่น ๆ : เนื่องจากรหัสทั้งหมดจะต้องผ่าน IntermDB เพื่อเข้าถึงข้อมูลใน PrivateDB จะไม่มีนักพัฒนาใดที่ถูกล่อลวงให้ลองข้ามมัน - และความพยายามนั้นสามารถถูกพบเห็นได้ง่ายบน SQL Server Profiler เป็น DB_ID ของคำขอข้อมูล PrivateDb จะเป็น WebAppDb