มันเป็นการดีที่จะใช้บัญชีฐานข้อมูลที่แตกต่างกันสำหรับผู้ใช้แอปพลิเคชันแต่ละคนหรือไม่?

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

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

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

ยังมีชื่อสำหรับการตั้งค่าประเภทนี้หรือไม่?

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

หากความปลอดภัยนั้นแน่นคุณมักจะไม่เปิดเผยฐานข้อมูลโดยตรง คุณมีบริการและลูกค้าจะต้องได้รับข้อมูลจากบริการ

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

หากการเข้าสู่ระบบและรหัสผ่านอยู่ในแอปพลิเคชันไคลเอนต์ก็สามารถแฮ็ก หากโดเมนคุณสามารถใช้ความปลอดภัยรวม

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

คุณสามารถมีโหมดผสมที่มีบางขั้นตอนการจัดเก็บที่ใช้โดยผู้ดูแลระบบและคุณต้องการติดตามผู้ดูแลระบบ และคุณสามารถให้สิทธิ์การเข้าถึงแก่ผู้ใช้ที่สร้างรายงานโดยตรงเท่านั้น

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

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

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

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

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

คุณควรเริ่มบังคับใช้ความปลอดภัยในระดับที่ละเอียดที่สุดโดยเร็วที่สุด บทบาทช่วยในเรื่องนี้ - การให้ผู้คนเข้าถึงหลาย ๆ โต๊ะในครั้งเดียวไม่ใช่ฝันร้าย

บัญชีเดียวสำหรับทุกคนเป็นแหล่งที่ดีของคำถามที่นี่และที่อื่น - "บันทึก x ถูกลบแล้วฉันจะรู้ได้อย่างไรว่าใครเป็นคนทำ?" - คำตอบคือคุณไม่สามารถ - ไม่แต่ละบัญชีและการตรวจสอบ

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

คุณต้องมีทริกเกอร์ในระบบของคุณซึ่งบันทึกการทำงานเพื่อให้สามารถติดตามระดับบุคคลที่ดำเนินการ X (ยกเว้นว่าคุณมี RDBMS เช่น Oracle ซึ่งสามารถทำสิ่งนี้ได้โดยอัตโนมัติ)

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

บางทีถ้าคุณให้ RDBMS ของคุณกับเราคุณสามารถขอคำแนะนำที่เฉพาะเจาะจงมากขึ้น / เกี่ยวข้องกับสถานการณ์ของคุณ?

ใช่แล้ว. การเชื่อมต่อกับฐานข้อมูลจากโปรแกรมเป็นผู้ใช้ที่มีประสิทธิภาพเดียวคือการละเมิดที่หลักการของสิทธิน้อย นี่คือสาเหตุหลักของการโจมตี SQL Injection

สิ่งนี้มักจะทำเนื่องจากความไม่รู้เพื่อความเรียบง่ายหรือบางครั้งเพื่อประสิทธิภาพ

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

คุณต้องการเลือกเซิร์ฟเวอร์ db ที่สนับสนุน Row Security, Column Security และการตรวจสอบสิทธิ์ Impersonation / Proxy (ซึ่งรองรับผู้ใช้ db จริง + การรวมการเชื่อมต่อ)

มันจะปลอดภัยกว่าสำหรับแอพพลิเคชั่นที่ใช้ "ปลั๊กอิน" เช่น Wordpress ซึ่งยากที่จะหลีกเลี่ยงการแทรก SQL เนื่องจากผู้เขียนปลั๊กอินที่ไม่มีทักษะ แต่ละปลั๊กอินได้รับการเข้าสู่ระบบ db แทนแอปพลิเคชันโดยรวม