อะไรคือสิทธิพิเศษที่สมเหตุสมผลในการให้สิทธิ์ผู้ใช้ทั่วไป? [ปิด]

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

1. root
2. developer
3. application

rootเป็นการอธิบายตนเอง สำหรับdeveloperผู้ใช้นี้จะต้องสามารถเข้าถึงฐานข้อมูลใด ๆ ได้อย่างง่ายดายทำการปรับเปลี่ยนเป็นต้นสำหรับผู้เริ่มฉันตั้งค่าผู้ใช้นี้เป็นชุดสิทธิ์นี้:

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

applicationมีชุดที่ จำกัด ยิ่งขึ้น ควร จำกัด ให้จัดการฐานข้อมูลเฉพาะเท่านั้น

ฉันไม่แน่ใจว่าจะให้สิทธิ์ชุดใดเป็นพิเศษ สิทธิพิเศษชุดใดที่เหมาะสมสำหรับนักพัฒนาและแอปพลิเคชันและเพราะเหตุใด

ผู้ใช้ทั่วไปควรมี:

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

สี่ครั้งแรกที่เห็นได้ชัดสวย - แม้ว่าคุณอาจตั้งค่า "อ่านเท่านั้น" SELECTผู้ใช้ที่มีเพียง

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

EXECUTEขึ้นอยู่กับประเภทของระบบ คุณมีกิจวัตรที่เก็บไว้หรือไม่? คุณต้องการให้ผู้ใช้ของคุณเข้าถึงพวกเขาหรือไม่? ให้แน่ใจว่าคุณยังรู้เกี่ยวกับSECURITY=DEFINER/INVOKERคำจำกัดความสำหรับกิจวัตรที่เก็บไว้

ในกรณีใด ๆ ให้แน่ใจว่าจะใช้ทั้งหมดข้างต้นในschema ที่เฉพาะเจาะจง หลีกเลี่ยงการใช้:

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

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

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

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

แอปพลิเคชั่นควรมีสิ่งที่ต้องการและไม่มาก (โดยทั่วไปนี่คือ "select / insert / update บนตารางทั้งหมด" และ "exec ในทุกโพรซีเดอร์" สำหรับระบบขนาดใหญ่ที่คุณอาจมีผู้ใช้แอปพลิเคชันแยกต่างหากสำหรับงานที่แตกต่างกัน อินสแตนซ์ที่แอปพลิเคชันหนึ่งรับผิดชอบในการป้อนข้อมูลเซ็นเซอร์และอีกแอปหนึ่งสำหรับการสร้างรายงาน) คุณควรแยกสิทธิ์ของพวกเขาเพื่อให้มีสิทธิ์น้อยที่สุด (ผู้ใช้รายงานอาจไม่ต้องการและเขียนสิทธิ์) ตรวจสอบให้แน่ใจว่าคุณทำซ้ำ สภาพแวดล้อมหากคุณมีพวกเขา: ฉันเห็นรหัสล้มเมื่อเลื่อนระดับเป็น Live ที่ทำงานในการทดสอบเพราะทุกอย่างในสภาพแวดล้อมการทดสอบกำลังเข้าถึงฐานข้อมูลเป็นsa(MSSQL เทียบเท่ากับroot)โดยทั่วไปแล้วผู้ใช้แอปพลิเคชันไม่ควรมีสิทธิ์ที่อนุญาตให้แก้ไขสคีมาของคุณ (CREATE,, DROP... ) - มีข้อยกเว้นสำหรับสิ่งนี้ แต่พวกมันอยู่ห่างกันไม่มากนัก

rootrootคือดี ในการผลิตนี่คือ DBA ของคุณเท่านั้นและไม่ควรใช้ - สำหรับการบำรุงรักษาระบบ (อัปเกรดเป็นการออกแบบฐานข้อมูล) และการตรวจสอบ สำหรับระบบขนาดใหญ่โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมที่มีการควบคุมที่คุณต้องควบคุมบุคคลอย่างใกล้ชิดเพื่อความรับผิดชอบคุณอาจไม่อนุญาตให้rootผู้ใช้คนเดียวเลยและลองแยกสิทธิพิเศษออกเป็นม้วนเล็ก ๆ (ฉันไม่แน่ใจว่าคุณจะไปได้ไกลแค่ไหน ด้วยสิ่งนี้ใน mysql แต่คุณสามารถปรับให้เหมาะสมใน MSSQL, Oracle และอื่น ๆ )

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

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