ใช้ความปลอดภัยรวม (SSPI) สำหรับการเข้าถึง SQL Server ที่ดีกว่าสำหรับเว็บแอปพลิเคชันหรือไม่

เมื่อปรับใช้เว็บแอปพลิเคชัน (.net) กับสภาพแวดล้อมการผลิตจะดีกว่าหรือไม่ที่จะใช้การรักษาความปลอดภัยแบบบูรณาการ

ดูเหมือนว่าสำหรับฉันหากแฮกเกอร์ทำลายเว็บเซิร์ฟเวอร์มันจะไม่สำคัญเพราะพวกเขาสามารถเลียนแบบเครื่องได้อย่างง่ายดาย

คิด?

ฉันว่ามีเหตุผลที่ถูกต้องเพียงสองเหตุผลในการใช้ SQL auth:

1. คุณกำลังเชื่อมต่อจากนอกโดเมนจึงต้องมีการตรวจสอบสิทธิ์
2. คุณกำลังรันเกณฑ์มาตรฐาน TPC-C และทุกรอบจะนับ SQL auth เร็วขึ้นเล็กน้อย

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

ในขณะที่ sql auth เทียบกับ windows auth ให้ประโยชน์ไม่ชัดเจนในสถานการณ์ของคุณมีปัญหาอื่น ๆ ที่ต้องพิจารณา:

1. การบังคับใช้นโยบายแบบรวมศูนย์: คุณมีที่เดียวสำหรับตั้งค่านโยบายรหัสผ่านของคุณรวมถึงอายุการใช้งานรหัสผ่านและการหมดอายุการยกเลิกบัญชีเป็นต้น
2. ควบคุมการแอบอ้างบุคคลอื่นและมอบหมายความไว้วางใจ เมื่อ sql auth ถูกใช้ในห่วงโซ่การมอบหมายความน่าเชื่อถือการเดิมพันทั้งหมดจะปิดเนื่องจากไม่ได้เป็น 'การมอบหมาย' จริงและดังนั้นจึงไม่อยู่ภายใต้ข้อ จำกัด ที่นโยบายของคุณกำหนดไว้
3. การตรวจสอบ: sql auth ไม่เห็นแม้แต่กับ LSA ของคุณดังนั้นโครงสร้างการตรวจสอบทั้งหมดของคุณจะถูกข้าม คุณต้องเพิ่มระเบียน SQL อย่างชัดเจนเกี่ยวกับกิจกรรมการตรวจสอบ sql แต่กำลังผสมแอปเปิ้ลและส้มเนื่องจากเหตุการณ์เหล่านั้นมีแหล่งที่มาผู้ให้บริการและสคีมาที่แตกต่างกันในบันทึกเหตุการณ์

หมายเหตุสุดท้ายหนึ่ง: โปรโตคอล TDS จะเปิดเผยรหัสผ่าน sql auth ในข้อความที่ชัดเจนเกี่ยวกับการรับส่งข้อมูล แต่โดยปกติแล้วจะลดลงโดยการร้องขอการเข้ารหัส SSL ของการรับส่งข้อมูล

เหตุใดคุณจึงเห็นว่าโฮสต์ WWW ยังคง sql auth ที่เก็บรหัสผ่านไว้อย่างชัดเจนใน web.config เหล่านี้จะไม่ดีนักพัฒนา / ผู้ดูแลระบบไม่ได้เป็นหนึ่งในพวกเขา

msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx

technet.microsoft.com/en-us/library/ms189067.aspx

หากคุณไม่ได้ใช้ SSPI คุณจะต้องเข้ารหัสชื่อผู้ใช้และรหัสผ่านลงในไฟล์ต้นฉบับ

หากคุณเข้ารหัสชื่อผู้ใช้และรหัสผ่านลงในไฟล์ต้นฉบับพนักงานของคุณทุกคนสามารถเข้าถึงได้

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

ข้อได้เปรียบของ SSPI คือรหัสผ่านจะไม่ถูกเก็บไว้ในที่ใด ๆ

คำตอบอื่น ๆ นั้นดี แต่ฉันจะกล่าวอีกเรื่องหนึ่ง: การจัดการ

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

ฉันไม่แน่ใจ 100% ที่นี่ แต่ฉันคิดว่าประเด็นหลักคือการรับรองความถูกต้องของ SQL ไม่ปลอดภัยดังนั้นจะเป็นการดีกว่าถ้าใช้ Windows auth คุณสามารถจัดเก็บข้อมูลประจำตัวที่เหมาะสมในรูปแบบที่เข้ารหัสบนเครื่องโดยใช้ Windows auth ทั้งนี้ขึ้นอยู่กับการตั้งค่าแอพของคุณ ฉันไม่คิดว่ามันเป็นไปได้จริง ๆ กับ SQL auth คุณสามารถทำให้งงงวย แต่ในที่สุดมันจะต้องชัดเจน

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

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

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

เริ่มจากการเลียนแบบเครื่อง ถ้ารหัสประจำตัวกลุ่มแอพลิเคชันคือบริการเครือข่ายและไม่มีการเลียนแบบในแอปพลิเคชัน. NET แล้วใช่เว็บแอปพลิเคชันจะเชื่อมต่อกับ SQL Server ส่วนหลังโดยใช้บัญชีคอมพิวเตอร์ของเครื่อง และนั่นหมายความว่าคุณได้ให้สิทธิ์การเข้าถึงบัญชีเครื่องดังกล่าว CRM ของ Microsoft ทำงานในลักษณะนี้

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

ทีนี้ทำไมถึงใช้ SSPI ก่อนอื่นคุณไม่ได้ใช้การเข้าสู่ระบบโดยใช้ SQL Server นั่นหมายความว่า Active Directory เป็นแหล่งความปลอดภัยเพียงอย่างเดียว นั่นหมายความว่าคุณมีการตรวจสอบปกติหมายถึงการตรวจสอบการเข้าถึงที่ไม่ถูกต้อง อย่างที่สองก็หมายความว่าหากไม่มีแอพอื่น ๆ ที่จำเป็นต้องใช้คุณสามารถปล่อยให้ SQL Server ของคุณอยู่ในโหมดการตรวจสอบ Windows เท่านั้น นั่นหมายความว่าไม่อนุญาตให้ล็อกอิน SQL Server นั่นหมายความว่าการโจมตี Sa จะหยุดลงก่อนที่จะเริ่ม และในที่สุดมันทำให้การกู้คืนง่ายขึ้น หากคุณใช้การเข้าสู่ระบบโดยใช้ SQL Server คุณจะต้องแตกการเข้าสู่ระบบด้วย SID และรหัสผ่านที่เข้ารหัส หากคุณใช้บัญชีผู้ใช้ที่ใช้ Windows เป็น "บัญชีบริการ" เมื่อคุณไปที่ SQL Server ใหม่ด้วยการสร้างการเข้าสู่ระบบ

คำถามคือ "ดีกว่า" คืออะไร? ซึ่งเป็นการยากที่จะตอบเนื่องจากขึ้นอยู่กับบริบทค่านิยมและลำดับความสำคัญของผู้ถาม

ส่วนตัวผมชอบ SQL auth

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

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

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