คุณจัดการความปลอดภัยฐานข้อมูลจากแอปพลิเคชันบนเดสก์ท็อปได้อย่างไร

เป็นเวลาประมาณ 10 ปีที่ฉันได้ทำงานกับแอพพลิเคชั่นไคลเอนต์เดสก์ท็อปภายในพร้อมที่เก็บข้อมูล SQL Server ฉันเริ่มทำโครงการเหล่านี้บ่อยครั้ง - ส่วนใหญ่เป็นงานเทคโอเวอร์

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

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

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

ฉันสนใจที่จะรู้ว่าระบบอื่น ๆ จะแก้ไขปัญหานี้ได้อย่างไร นี่คือตัวเลือกที่ฉันรู้:

1. ใช้กลไกความปลอดภัยของ SQL Server เพื่อรักษาผู้ใช้และรายการบทบาทและทำให้แอปพลิเคชันเดสก์ท็อปเพิ่มและลบผู้ใช้ผ่านการสอบถาม T-SQL
2. แทนที่จะเชื่อมต่อกับฐานข้อมูลโดยตรงให้สร้างบริการบนเว็บบางประเภทที่ทำงานบนเซิร์ฟเวอร์และวางตรรกะการตรวจสอบสิทธิ์ลงในนั้น ทำให้ทุกคำขอทำการตรวจสอบความปลอดภัย

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

ครั้งที่สองดูเหมือนว่าจะเป็นปัญหาด้านประสิทธิภาพที่สำคัญและมีงานพิเศษมากมายรวมถึงคุณไม่สามารถใช้โปรแกรมแมป ORM อย่าง NHibernate ได้อย่างง่ายดาย (ฉันคิดว่า)

ใครบ้างมีประสบการณ์กับสิ่งนี้หรือไม่? ปฏิบัติที่ดีที่สุด?

แก้ไข

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

ฉันกลัวว่าการเพิ่มเลเยอร์บริการบนเว็บน่าจะเป็นทางออกที่ถูกต้องสำหรับปัญหาของคุณ

การแยกไคลเอ็นต์ออกจากการใช้ฐานข้อมูลพื้นฐานอาจช่วยคุณได้ในระยะยาวเช่นกัน

การเพิ่มเลเยอร์บริการเว็บไม่จำเป็นต้องกระทบกับประสิทธิภาพ ...

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

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

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

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

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

เช่นเดียวกับคำตอบของ jmoreno คุณสามารถปฏิเสธการเข้าถึงของผู้ใช้ทุกอย่างนอกเหนือจากการใช้สิทธิ EXECUTE ในขั้นตอนการจัดเก็บจากนั้นใช้ประโยชน์จากการผูกมัดเจ้าของเพื่อให้กระบวนการจัดเก็บดำเนินการตามตารางที่ต้องการ

ดูที่นี่สำหรับรายละเอียดhttps://msdn.microsoft.com/en-us/library/bb669058(v=vs.110).aspx

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

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

วิธีหนึ่งคือการใช้กลุ่มโฆษณาและขั้นตอนการจัดเก็บเพื่อ จำกัด สิ่งที่ผู้ใช้สามารถทำได้ - ตัวอย่างเช่น DB ใบบันทึกเวลาของคุณอาจอนุญาตให้มีการแทรกปรับปรุงและลบชั่วโมงผู้ใช้ แต่ไม่อนุญาตให้อัปเดตชั่วโมงของผู้อื่น ID ของผู้ใช้จะถูกจัดเตรียมโดยเอ็นจิน DB ผู้ใช้จะไม่มีการเข้าถึงโดยตรงไปยังตาราง DB เพียงเพื่อ sp ของที่รันเคียวรีตาม id ล็อกอินของพวกเขา

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

สิ่งที่คุณแบะท่าว่า 'บริการเว็บ' เรียกว่าn ชั้นสถาปัตยกรรม โดยทั่วไปแล้วจะเป็นวิธีไปในกรณีที่มีปัญหาด้านความปลอดภัยหรือการกำหนดค่า (เช่นการกระจายแอปพลิเคชันไปยังสำนักงานหลายแห่ง) ไม่จำเป็นต้องเป็น 'web based' ทำงานกับโปรโตคอลอื่น ๆ มากมาย

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

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

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

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

CREATE VIEW [dbo].[vwSomeTable]
AS
    SELECT SomeTable.*
    FROM SomeTable
        INNER JOIN Employee ON SomeTable.Employee_ID = Employee.Employee_ID
    WHERE Employee.Username = USER_NAME() OR IS_MEMBER('HR_Role')=1

GO

จากนั้นสิ่งที่คุณทำคือให้สิทธิ์ในการอ่าน (และอาจจะเขียน) ในมุมมอง ( vwSomeTable) ให้กับผู้ใช้ทั้งหมดและไม่ให้สิทธิ์ในตาราง ( SomeTable)

คุณสามารถทดสอบสิ่งนี้:

EXECUTE AS USER = 'Some_Regular_Username'
SELECT * FROM vwSomeTable

... ซึ่งควรคืนแถวของพวกเขาเท่านั้น หรือ:

EXECUTE AS USER = 'Some_HR_Username'
SELECT * FROM vwSomeTable

... ซึ่งจะส่งคืนแถวทั้งหมด โปรดทราบว่าคุณจะต้องมีสิทธิ์ดำเนินการ (เลียนแบบ) เพื่อทำการทดสอบนี้

มุมมองสามารถอัปเดตได้ดังนั้นแม้ผู้ใช้ทั่วไปก็สามารถทำได้ตราบใดที่แถวนั้นเชื่อมโยงกับEmployeeแถว:

UPDATE vwSomeTable
SET SomeColumn = 5
WHERE SomeTable_ID = 'TheID'

การใช้การรับรองความถูกต้องตามใบรับรองเป็นวิธี "ที่ถูกต้อง" ในการใช้บัญชี sql ที่ใช้ร่วมกัน เป้าหมายคือกำจัดการใช้รหัสผ่านสำหรับสิ่งนี้

ปรับปรุง:

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

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

การอ้างอิง: http://en.wikipedia.org/wiki/Public-key_infrastructure

การสร้างโซลูชันความปลอดภัยบนเดสก์ท็อปใหม่เราเลือกใช้โซลูชันบริการบนเว็บฉันจะพยายามอธิบายเรื่องร้อง

เรารวบรวมโปรแกรมปฏิบัติการเดสก์ท็อปในสภาพแวดล้อมที่แยกจากนักพัฒนา และคำนวณแฮชจากการปฏิบัติการที่ถูกบันทึกลงในฐานข้อมูล

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

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

DLL จัดการการสื่อสารทั้งหมดจากแอปพลิเคชันเดสก์ท็อปไปยังบริการบนเว็บซึ่งสามารถเข้าถึงได้ด้วยโทเค็นบิลด์ลงใน DLL เท่านั้น

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

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

แก้ไข: คุณสามารถแทนที่แนวคิดแฮชได้โดยใช้ลายเซ็นดิจิทัลและใบรับรอง X.509