คำแนะนำใด ๆ ในการลดเอกสิทธิ์ของฉันในการผลิต แต่ไม่ทำให้งานของฉันยากเกินไป

ใช้ SQL Server 2005 และ 2008 บน Windows 2008 R2

เรากำลังจะได้รับการลดสิทธิพิเศษในการผลิตสำหรับนักพัฒนา - และฉันต้องการที่จะทำเช่นเดียวกันสำหรับตัวเองเป็นที่ DBAจำกัด สิทธิในการผลิตและการยกระดับเมื่อจำเป็น

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

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

ขณะนี้เรามีกลุ่ม windows สำหรับ DBA ที่มีสิทธิ์ในเซิร์ฟเวอร์และฐานข้อมูลทั้งหมดของเรา

ฉันยังสนใจที่จะลดสิทธิ์การเข้าสู่ระบบ OS / ระยะไกล - แต่ฉันกังวลมากที่สุดเกี่ยวกับสิทธิ์ DB

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

ขอบคุณสำหรับคำแนะนำและแบ่งปันประสบการณ์ของคุณ!

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

การเรียงลำดับของสิทธิที่ UserIDs ทำงานภายใต้สิทธิเพียง แต่พวกเขาจริงๆควรจะมีอยู่db_datareader, db_datawriterและชัดเจนGRANT EXECUTE ON x TO y(สำหรับแต่ละ proc การจัดเก็บและการใช้ฟังก์ชั่นที่กำหนดไว้xสำหรับหมายเลขผู้ใช้y)

หากคุณต้องการใช้งานร่องรอยในการผลิตคุณมีปัญหาบางอย่างและต้องใช้ Great Wall of Text ™เพื่ออธิบายทุกอย่าง คำแนะนำแรกของฉันคือการมีสภาพแวดล้อม QA ที่ถูกล็อคเช่นเดียวกับการผลิตและหากจำเป็นต้องเรียกใช้ร่องรอยให้เรียกคืนการสำรองข้อมูลของ prod db เป็น QA และเรียกใช้การติดตามที่นั่น อีกครั้งถ้าคุณมีข้อกำหนดSOX, HIPAAหรือPCI-DSSคุณควรทำให้ข้อมูลที่ถูกสุขอนามัยดีขึ้นก่อนที่จะกู้คืนไปยัง QA

ขณะนี้เรามีกลุ่ม windows สำหรับ DBA ที่มีสิทธิ์ในเซิร์ฟเวอร์และฐานข้อมูลทั้งหมดของเรา

ให้พวกเขาเข้าสู่ระบบและดูสิทธิ์ข้อมูล; อย่างไรก็ตามเพื่อปฏิบัติหน้าที่ DBAly ให้ใช้การเข้าสู่ระบบแยกต่างหากด้วยสิทธิ์ที่ยกระดับ ฉันรู้ว่าลูกค้าด้านการเงินรายหนึ่งที่ทำสิ่งนี้ - การเข้าสู่ระบบโดยใช้การรับรองความถูกต้องของ windows ปกตินั้นถูก จำกัด ในความเสียหายที่พวกเขาอาจทำโดยไม่ได้ตั้งใจ กู้คืนและรัน DML ที่จำเป็นต้องใช้ในการรันด้วยการล็อกอินการพิสูจน์ตัวตน SQL แยกต่างหาก

หน่วยงานรัฐบาลหนึ่งที่ฉันทำงานด้วยใช้การเข้าสู่ระบบแยกกัน 2 รายการสำหรับแต่ละเซิร์ฟเวอร์ / ผู้ดูแลระบบ db ดังนั้นหากTangurenaเข้าสู่ระบบโดเมนของฉัน (เข้าสู่ระบบนี้จะมีUserสิทธิ์ปกติ) จากนั้นTangurenaAdminจะAdministratorเข้าสู่ระบบแยกต่างหากของฉัน คุณประสบปัญหาหากคุณใช้บัญชีผู้ดูแลระบบของคุณตลอดเวลา แต่จากนั้นจะไม่มีสิทธิ์ในสิ่งอื่น ๆ (เช่นไม่มีอีเมลโอ้คุณบอกว่ามันเป็นสิ่งที่ไม่ดี ... )

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

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

ฉันเดาว่าเราจะต้องใช้สิทธิ์ระดับสูงในการเรียกใช้ร่องรอยเป็น sa

ไม่คุณต้องได้รับอนุญาตจาก ALTER TRACE เท่านั้น:
http://msdn.microsoft.com/en-us/library/ms187611.aspx

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

ฉันจะบอกวิธีการภายในของเรา:

• แอปพลิเคชันทั้งหมดใช้ผู้ใช้โดเมนเดียวที่ได้รับสิทธิ์ที่จำเป็นในฐานข้อมูล (โดยปกติคือบทบาทฐานข้อมูล db_owner)

• สำหรับข้อมูลที่อ่านเป็นครั้งคราวเราใช้การเข้าสู่ระบบ SQL สำหรับผู้ใช้นั้นเรากำหนดบทบาทฐานข้อมูล - db_datareader นี่คือที่ซึ่งจะสิ้นสุดการเข้าถึงสำหรับนักพัฒนาในคลัสเตอร์ฐานข้อมูลหลัก สำหรับแนวคิดอื่น ๆ ที่พวกเขามีพวกเขาจะใช้ฐานข้อมูลเซิร์ฟเวอร์รายงานซึ่งเป็นสำเนา (ทำโดยใช้ Log Shipping) ของฐานข้อมูลเซิร์ฟเวอร์หลักที่ทำในเวลาเที่ยงคืน เพื่อที่จะไม่ฆ่าเซิร์ฟเวอร์การรายงานด้วยคิวรีนักฆ่าเฉพาะกิจเราใช้การจัดสรรกลุ่มทรัพยากรสำหรับหน่วยความจำและซีพียู

• สำหรับทีม DBA เรามีกลุ่มโดเมนที่มีสิทธิ์ทั้งหมดในเครื่องและเซิร์ฟเวอร์ (ผู้ดูแลระบบในเครื่อง windows และดูแลระบบบนเซิร์ฟเวอร์ sql)

• สำหรับการติดตั้งเรามีผู้ใช้ SQL ที่เป็น db_owner บนฐานข้อมูลที่เราใช้เมื่อเรียกใช้การปรับปรุง - เราใช้ทริกเกอร์ DDL เพื่อตรวจสอบการเปลี่ยนแปลงสคีมาและเราควรดูว่ามีการเปลี่ยนแปลงใดบ้างในระหว่างการติดตั้ง

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

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

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

ในการควบคุมที่ละเอียดยิ่งขึ้น SQL 2005 + schemaสามารถทำได้ด้วย ตรวจสอบลิงค์นี้บนสคีมาเพื่อรับรายละเอียดเพิ่มเติม