การรักษาความปลอดภัย SQL Server ของฐานข้อมูล ASP.NET2.0

ผู้เขียน：Eve Cole เวลาอัปเดต：2009-06-30 16:43:56

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

· Windows Authentication (หรือที่เรียกว่า Trusted Authentication หรือ Integrated Security) ใช้ข้อมูลประจำตัวของผู้ใช้ Windows ที่ส่งคำขอเชื่อมต่อเพื่อดำเนินการอนุญาตฐานข้อมูล ในกรณีนี้ สตริงการเชื่อมต่อไม่จำเป็นต้องระบุชื่อผู้ใช้และรหัสผ่านที่ชัดเจน ASP.NET ทำงานเป็นผู้ใช้ภายในเครื่องชื่อ "ASPNET" (หรือ "บริการเครือข่าย" ใน IIS 6.0) ดังนั้นเมื่อใช้ Windows Authentication SQL จะตรวจสอบว่าผู้ใช้รายนี้มีสิทธิ์ใช้ฐานข้อมูลหรือไม่ ณ จุดนี้ แอปพลิเคชัน ASP.NET ทั้งหมดกำลังทำงานกับผู้ใช้รายเดียวกัน ดังนั้นเซฟโหมดจึงปฏิบัติต่อแอปพลิเคชันเหล่านั้นอย่างเท่าเทียมกัน แม้ว่าจะเป็นไปได้ที่จะเรียกใช้แต่ละแอปพลิเคชันในกระบวนการ ASP.NET ที่แยกจากกัน (ผู้ใช้แยกต่างหากที่เรียกใช้แต่ละแอปพลิเคชัน) หรือเลียนแบบข้อมูลประจำตัวผู้ใช้ Windows ของไคลเอนต์เบราว์เซอร์ที่ทำการร้องขอการเชื่อมต่อ แต่สิ่งเหล่านี้อยู่นอกเหนือขอบเขตของหนังสือเล่มนี้ . อย่างไรก็ตาม การเลียนแบบไคลเอ็นต์คือการใช้ Windows Authentication ที่พบบ่อยที่สุดในเว็บแอปพลิเคชัน

· การตรวจสอบความถูกต้องของ SQL จะตรวจสอบชื่อผู้ใช้และรหัสผ่านที่ให้มาอย่างชัดเจนกับผู้ใช้ที่กำหนดค่าภายใน SQL Server (โดยไม่เกี่ยวข้องกับระบบปฏิบัติการ) ในกรณีนี้ แต่ละแอปพลิเคชันที่ทำงานในกระบวนการ ASP.NET สามารถเชื่อมต่อกับฐานข้อมูลด้วยใบรับรองแยกต่างหาก ดังนั้นจึงเป็นการแยกแอปพลิเคชันอย่างสมเหตุสมผล (แอปพลิเคชัน A จะไม่สามารถเชื่อมต่อกับฐานข้อมูลได้หากไม่มีชื่อผู้ใช้และรหัสผ่านของ B) ไม่สามารถเชื่อมต่อกับฐานข้อมูลของ B) นี่เป็นโหมดการตรวจสอบสิทธิ์ทั่วไปที่ใช้สำหรับเว็บแอปพลิเคชันที่ใช้งาน โดยเฉพาะอย่างยิ่งในกรณีของโฮสติ้งที่ใช้ร่วมกัน ข้อเสียเล็กน้อยคือแอปพลิเคชันต้องเก็บรหัสผ่านของบัญชีผู้ใช้ที่ใช้ในการเชื่อมต่อ และหากผู้ใช้ที่เป็นอันตรายได้รับรหัสผ่านนี้ ความปลอดภัยของฐานข้อมูลก็จะถูกบุกรุก อย่างไรก็ตาม ดังที่คุณจะเห็นในภายหลังในหนังสือเล่มนี้ ASP.NET มอบวิธีที่ปลอดภัยในการจัดเก็บรหัสผ่านการรับรองความถูกต้องของ SQL ในรูปแบบที่เข้ารหัสในไฟล์ Web.config ซึ่งจะช่วยลดความเสี่ยงในการได้รับรหัสผ่าน

· โหมดผสมคือการกำหนดค่าของ SQL Server ที่อนุญาตทั้ง Windows Authentication และ SQL Authentication

เมื่อติดตั้ง SQL Server หรือ SSE คุณต้องเลือกโหมดการรับรองความถูกต้อง ใน SQL Server จะมีตัวช่วยสร้างเพื่อช่วยคุณเลือกในระหว่างขั้นตอนการรักษาความปลอดภัย ในขณะที่อยู่ใน SSE ตัวเลือกเริ่มต้นคือการรับรองความถูกต้องของ Windows หากคุณต้องการติดตั้ง SQL Authentication คุณต้องกำหนดค่าอย่างชัดเจน บทความนี้ใช้การรับรองความถูกต้องของ Windows

หากคุณได้ติดตั้ง SQL Server หรือ SSE คุณสามารถดูโหมดการตรวจสอบสิทธิ์ที่ระบุได้โดยเปิด RegEdit (แน่นอนว่าคุณต้องสำรองข้อมูลก่อน) ค้นหา HKey_Local_Machine/Software/Microsoft/Microsoft SQL Server และค้นหา LoginMode คีย์ย่อยของการลงทะเบียนที่มีค่า 1 แสดงถึง Windows Authentication ในขณะที่ค่า 2 แสดงถึงโหมด Mixed Authentication

ตาราง 3-1 สรุปความแตกต่างระหว่างโหมดเหล่านี้

ตารางที่ 3-1

ของ

	การรับรองความถูกต้องของ Windows	การรับรองความถูกต้องของ SQL
ชื่อที่เปลี่ยนได้	การรับรองความถูกต้องที่เชื่อถือได้ การรักษาความปลอดภัยแบบรวม	ไม่ แต่การรับรองความถูกต้องของโหมดผสมอนุญาตให้ใช้การรับรองความถูกต้องของ Windows หรือ SQL ได้
สภาพแวดล้อมทั่วไป	ราย	ชื่อ
ผู้ใช้อินเทอร์เน็ตและกระบวนการตรวจสอบความ	ถูก	ต้อง
ของ	Windows
SQL	Server	SSE
=ผู้ใช้จริง	=ชื่อผู้ใช้; รหัสผ่าน=รหัสผ่าน
ผู้ใช้แอปพลิเคชันเว็บ	ASP.NET, ASPNET (IIS 5.x) หรือบริการเครือข่าย (IIS 6)	ผู้ใช้ SQL
มีข้อดี	ของการรักษาความปลอดภัยที่ดีกว่า สามารถควบคุมเหตุการณ์ SQL ของผู้ใช้และการติดตามกิจกรรมของ Windows	ได้ ปรับใช้บนเครื่องโฮสต์โดยไม่ต้องสร้างบัญชีใหม่โดยไม่ขึ้นกับระบบปฏิบัติการ ไซต์อินทราเน็ตที่โฮสต์ต้องใช้ทักษะปานกลางเท่านั้น ให้วิธีที่ยืดหยุ่นมากขึ้นสำหรับแอปพลิเคชันในการเชื่อมต่อกับแต่ละฐานข้อมูลด้วยใบรับรองที่แตกต่างกัน
ข้อเสีย	การให้ใบรับรอง Windows แก่แอปพลิเคชันเว็บมีศักยภาพในการกำหนดขอบเขตการอนุญาตในระบบปฏิบัติการที่มีขนาดใหญ่เกินไป	รหัสผ่านจะถูกเก็บไว้ในแอปพลิเคชันเว็บ (ซึ่งไม่ใช่ กรณีในการรับรองความถูกต้องของ Windows) ยืนยันว่ารหัสผ่านถูกบันทึกไว้ในไฟล์ Web.config และมีการเข้ารหัส อนุญาตการดำเนินการระดับต่ำสำหรับเว็บแอปพลิเคชันที่ใช้ใบรับรอง SA สร้างใบรับรองใหม่สำหรับแอปพลิเคชันเว็บ ASP.NET เสมอ และให้สิทธิ์ที่จำเป็นเท่านั้น

ตอนนี้เราทราบวิธีที่ปลอดภัยในการใช้ SQL แล้ว ลองพิจารณาว่าผู้ใช้ข้อมูล (การควบคุมแหล่งข้อมูล) จะตอบสนองความต้องการอย่างไร ขั้นแรก ให้ใช้ข้อมูลที่ได้รับจาก VWD และ VWD Web Server (Cassini) ส่วนใหญ่ในระหว่างการออกแบบและการทดสอบ ประการที่สอง ควรเข้าถึงข้อมูลจาก IIS หลังจากการปรับใช้ ผู้ใช้ข้อมูลทั้งสองมีชื่อผู้ใช้ที่แตกต่างกัน VWD และ VWD Web Server ใช้ชื่อของบุคคลที่เข้าสู่ระบบ Windows ในขณะที่โปรแกรม IIS ใช้ชื่อ ASPNET

ถ้า SQL Server ใช้การรับรองความถูกต้องของ Windows ตัวควบคุม SqlDataSource จำเป็นต้องรวมรหัสต่อไปนี้ในสตริงการเชื่อมต่อ: Integrated Security=true (หรือ Trusted_connection=true) พารามิเตอร์นี้จะสั่งให้ SQL Server ตรวจสอบคำขอข้อมูลตามบัญชีเข้าสู่ระบบ Windows ของผู้ร้องขอ หากคุณเข้าสู่ระบบในฐานะผู้ใช้ที่ติดตั้ง SSE ใบรับรองของพวกเขาจะให้สิทธิ์การเข้าถึง SSE ทุกอย่างจะดำเนินไปอย่างราบรื่นโดยใช้ VWD และ VWD Web Server เนื่องจากผู้ใช้ VW Web Server ถือเป็นโปรแกรมเมอร์ที่ลงชื่อเข้าใช้ Windows และจึงมีบัญชีใน SSE อย่างไรก็ตาม แม้ว่าแอปพลิเคชันจะทำงานได้ดีภายนอก VWD แต่ก็จะไม่ทำงานอย่างถูกต้องเมื่อย้ายไซต์ไปยัง IIS IIS ทำงานภายใต้บัญชีผู้ใช้ชื่อ ASPNET (หรือ Network Service ใน IIS6/Windows 2003 Server) ดังนั้น ผู้ดูแลระบบของเครื่องที่ใช้ IIS จะต้องเพิ่มผู้ใช้ ASP.NET และให้สิทธิ์แก่ผู้ใช้ กระบวนการนี้อยู่นอกเหนือขอบเขตของหนังสือเล่มนี้ แต่มีอธิบายรายละเอียดไว้ในคู่มือผู้ดูแลระบบ IIS หลายฉบับ โดยสรุป หาก SQL Server ใช้การรับรองความถูกต้องของ Windows คุณสามารถใช้ VWD และ VWD Web Server เพื่อทำแบบฝึกหัดในหนังสือเล่มนี้ได้ เพจของคุณสามารถทำงานบน IIS ได้หลังจากให้สิทธิ์แก่บัญชีกระบวนการ ASP.NET ที่เข้าถึงฐานข้อมูลแล้วเท่านั้น

หาก SQL Server ใช้การรับรองความถูกต้องของ SQL SQL จะดำเนินการกระบวนการตรวจสอบความถูกต้องของตนเอง กระบวนการนี้จะไม่ขึ้นอยู่กับรายชื่อผู้ใช้ Windows สตริงการเชื่อมต่อประกอบด้วยพารามิเตอร์สองตัว: ผู้ใช้=ชื่อผู้ใช้ รหัสผ่าน=รหัสผ่าน ขณะนี้เพจนี้สามารถใช้งานได้จาก VWD, VWD Web Server หรือ IIS เนื่องจากไม่จำเป็นต้องสร้างบัญชีผู้ใช้ใน Windows อย่างไรก็ตาม เราจำเป็นต้องใช้บัญชีใน SQL Server ด้วย บัญชีเริ่มต้นเพียงบัญชีเดียวคือ sa ก่อนที่จะปรับใช้ ควรสร้างบัญชีอื่นใน SQL Server ที่มีสิทธิ์ในการเรียกใช้เพจ ASPX เท่านั้น ความล้มเหลวในการสร้างบัญชีอื่นนอกเหนือจาก sa (และรหัสผ่านเพื่อป้องกัน sa) จะทำให้ไซต์เปิดต่อหนึ่งในช่องโหว่ด้านความปลอดภัยที่เป็นที่รู้จักและหาประโยชน์ได้ง่ายที่สุด แฮกเกอร์ทุกคนรู้ว่าต้องเข้าสู่ระบบโดยใช้ userID='sa' ด้วยรหัสผ่านที่ว่างเปล่า

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