ทำไมจึงเป็นการดีที่จะอนุญาตให้ทุกคนใช้การเข้าสู่ระบบ sa

แม้แต่ Microsoft ไม่สนับสนุนการใช้โหมดการรับรองความถูกต้องของ SQL Serverแต่แอปพลิเคชันของเราต้องการ

ฉันได้อ่านว่าเป็นวิธีปฏิบัติที่ดีที่สุดที่จะไม่อนุญาตให้ผู้ใช้ใช้การsaเข้าสู่ระบบโดยตรงแทนการใช้ Windows Authentication และการอนุญาตสิทธิ์ดูแลระบบบัญชี (หรือกลุ่มบัญชี) เหล่านั้น

• นั่นไม่ใช่สิ่งเดียวกัน ข้อดี / ข้อเสียคืออะไร?
• แนวปฏิบัติที่เหมาะสมที่สุดเพิ่มความปลอดภัยของอินสแตนซ์ SQL Server ของฉันได้อย่างไร
• สิ่งนี้ใช้ได้กับอินสแตนซ์การผลิตหรือกับอินสแตนซ์การพัฒนาภายในของเราด้วยหรือไม่

คุณมีคำถามที่แตกต่างกันในที่นี่ดังนั้นฉันจะเคาะออกที:

"ฉันได้อ่านแล้วว่าเป็นวิธีปฏิบัติที่ดีที่สุดที่จะไม่อนุญาตให้ผู้ใช้เข้าสู่ระบบ sa โดยตรงแทนที่จะใช้ Windows Authentication"

คุณกำลังผสมสองสิ่งที่นี่: แนวคิดของ SA และแนวคิดของการรับรองความถูกต้องของ SQL และการรับรองความถูกต้องของ Windows

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

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

"... และอนุญาตให้ใช้สิทธิ์ดูแลระบบบัญชีเหล่านั้น (หรือกลุ่มบัญชี)"

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

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

"วิธีปฏิบัติที่ดีที่สุดเพิ่มความปลอดภัยของอินสแตนซ์ SQL Server ของฉันได้อย่างไร"

คุณต้องการทำสองสิ่ง:

1. หยุดคนไม่ให้เซิร์ฟเวอร์แตก
2. เมื่อพวกเขาทำลายเซิร์ฟเวอร์ให้สามารถระบุได้อย่างแม่นยำว่าใครเป็นคนทำ

คนแรกทำได้สำเร็จด้วยหลักการของสิทธิพิเศษอย่างน้อยที่สุด: มอบสิทธิ์ที่พวกเขาต้องการเท่านั้นและไม่มีอะไรเพิ่มเติม

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

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

"สิ่งนี้ใช้ได้เฉพาะกับอินสแตนซ์ของการผลิตหรือกับอินสแตนซ์การพัฒนาภายในของเราด้วย"

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

ที่จริงแล้วถ้าคุณอ่าน whitepaper นี้: SQL Server การแยกหน้าที่ Whitepaper

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

ฉันปิดการใช้งานและเปลี่ยนชื่อบัญชี "sa" เช่นเดียวกับที่คุณทำกับบัญชีผู้ดูแลระบบภายในระบบปฏิบัติการ เพื่อใช้ในกรณีฉุกเฉินเท่านั้น

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

หากคุณอยู่ภายใต้การควบคุมหรือมาตรฐานภายนอก (SOX, PCI ฯลฯ ) คุณก็ควร

• จะล้มเหลวในการตรวจสอบ
• ล้มเหลวในการตรวจสอบ PCI รายเดือนของคุณ

นักพัฒนาควรมี db_owner บนเครือข่าย SQL Server เพื่อการพัฒนาเท่านั้น

หากเซิร์ฟเวอร์ SQL ของคุณทั้งหมดอยู่ในเครือข่ายที่มีบิลด์มาตรฐาน (เช่นบัญชีบริการเดียวกัน) ดังนั้นในหนึ่งสิทธิให้พวกเขาทั้งหมด

หากบัญชีบริการเป็นผู้ดูแลท้องถิ่นผู้พัฒนาของคุณก็สามารถควบคุมเซิร์ฟเวอร์ได้เช่นกัน

ไม่มีอัพไซด์

sa = ดูแลระบบ

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

การให้สิทธิ์การดูแลระบบบัญชี windows จะทำในสิ่งเดียวกัน

รายการดำเนินต่อไป แต่สิ่งนี้ควรให้เหตุผลที่ดีบางประการแก่คุณที่ไม่เคยมีมาก่อนให้ผู้ใช้ที่ไม่ใช่ผู้ดูแลระบบใช้

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

วิธีปฏิบัติที่ดีที่สุดคือการใช้รหัสผ่านที่คาดเดายากและลืมมันไป

ตอนนี้ฉันมีสองตัวเลือกในใจว่าทำไมไม่มีบัญชี SA ที่อ่อนแอ หากคุณมีรหัสผ่านที่อ่อนแอ / ว่างเปล่าสำหรับ SA หนึ่งคนชั่วร้าย (แปลว่าเป็น 'เพื่อนร่วมงานที่เป็นมิตร') สามารถ:

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

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

ฉันจะไม่ชี้ให้เห็นข้อเท็จจริงที่ชัดเจนว่ามันสามารถดร็อปฐานข้อมูลล็อกอิน ... ฯลฯ

• นั่นไม่ใช่สิ่งเดียวกัน ข้อดี / ข้อเสียคืออะไร?

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

• แนวปฏิบัติที่เหมาะสมที่สุดเพิ่มความปลอดภัยของอินสแตนซ์ SQL Server ของฉันได้อย่างไร

• เช่นเดียวกับทุกแนวปฏิบัติที่ดีที่สุดในโลกนี้ทำงานของมันลดความเป็นไปได้ที่จะเกิดข้อเสีย (เช่น: แนวปฏิบัติที่ดีที่สุดในการทำกิจกรรมทางกายจะลดโอกาสที่คุณจะเป็นเหมือนฉัน .. มันฝรั่งทอด) ที่อาจเกิดขึ้นได้

• สิ่งนี้ใช้ได้กับอินสแตนซ์การผลิตหรือกับอินสแตนซ์การพัฒนาภายในของเราด้วยหรือไม่

• สมมติว่าฉันแนะนำให้ใช้แนวทางปฏิบัติด้านความปลอดภัยที่ดีที่สุด (ทดสอบและแก้ไขตามความต้องการของสภาพแวดล้อมของคุณ) อย่างน้อยในการผลิต แต่ถ้าในการพัฒนาคุณยังใช้ข้อมูลการผลิต (ละเอียดอ่อน .. ฯลฯ ) กว่าเป็นตัวบ่งชี้ที่ชัดเจนว่าคุณต้องเปลี่ยนแนวทางการพัฒนาของคุณด้วย

ตอบคำถามสุดท้ายของคุณเราใช้บัญชี SA ในฐานข้อมูลการพัฒนาทั้งหมดของเรา (ด้วยรหัสผ่าน "sa" ที่นั่น!)

อย่างไรก็ตามสิ่งสำคัญคือต้องทราบว่าเราไม่ได้จัดเก็บข้อมูลและเราไม่ได้สร้างข้อมูล ฐานข้อมูลของเราใช้สำหรับที่เก็บข้อมูลสำหรับแอปพลิเคชัน C / C ++ เท่านั้น ฐานข้อมูลการพัฒนาเหล่านี้มีข้อมูลการทดสอบอย่างครบถ้วนและมีการสร้าง, ปล่อย, แก้ไข, และอื่น ๆ \

นอกจากนี้ยังสำคัญเท่ากับฐานข้อมูลการพัฒนาทั้งหมดที่ติดตั้งบนเครื่องพัฒนา (อย่างน้อยหนึ่งสำเนาต่อนักพัฒนาซอฟต์แวร์อย่างน้อยที่สุด!) ดังนั้นหากใครบางคนทำให้การติดตั้งทั้งหมดยุ่งเหยิงพวกเขาก็ทำตัวเองให้วุ่นวาย

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

สำหรับกลุ่มนักพัฒนาซอฟต์แวร์ที่มีสำเนาฐานข้อมูลของตนเองซึ่งมีข้อมูลการทดสอบล้วนๆฉันยังไม่พบข้อโต้แย้งที่มั่นคงในการรักษาบัญชี SA ที่แข็งแกร่ง

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

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