การควบคุมการเข้าถึงสำหรับผู้ใช้และบทบาทใน SQL

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

ผู้ใช้

ฐานข้อมูลเซิร์ฟเวอร์ที่ใช้สนับสนุนแนวคิดของผู้ใช้แบบเดียวกับที่ใช้ในระบบปฏิบัติการคอมพิวเตอร์ ถ้าคุณคุ้นเคยกับลำดับชั้นของผู้ใช้ / กลุ่มที่พบใน Microsoft Windows NT และ Windows 2000 คุณจะพบว่ากลุ่มผู้ใช้ / บทบาทที่ SQL Server และ Oracle สนับสนุนมีลักษณะคล้ายกันมาก

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

วิธีการสร้างบัญชีผู้ใช้แตกต่างกันไปในแต่ละแพลตฟอร์มและคุณจะต้องปรึกษาเอกสารเฉพาะของ DBMS สำหรับขั้นตอนที่แน่นอน ผู้ใช้ Microsoft SQL Server ควรตรวจสอบการใช้กระบวนงานที่เก็บไว้ sp_adduser ผู้ดูแลระบบฐานข้อมูล Oracle จะหาคำสั่ง CREATE USER ที่เป็นประโยชน์ นอกจากนี้คุณอาจต้องการตรวจสอบแผนการรับรองความถูกต้องอื่น ๆ ตัวอย่างเช่น Microsoft SQL Server สนับสนุนการใช้ Windows NT Integrated Security ภายใต้โครงการนี้ผู้ใช้จะถูกระบุไปยังฐานข้อมูลโดยบัญชีผู้ใช้ Windows NT และไม่จำเป็นต้องป้อน ID ผู้ใช้และรหัสผ่านเพื่อเข้าถึงฐานข้อมูล วิธีนี้เป็นที่นิยมอย่างมากในหมู่ผู้ดูแลระบบฐานข้อมูลเนื่องจากจะช่วยลดภาระในการจัดการบัญชีให้กับเจ้าหน้าที่บริหารเครือข่ายและช่วยให้ผู้ใช้ปลายทางสามารถลงชื่อเข้าใช้ได้ง่ายขึ้น

บทบาท

หากคุณอยู่ในสภาพแวดล้อมกับผู้ใช้จำนวนน้อยคุณอาจพบว่าการสร้างบัญชีผู้ใช้และการกำหนดสิทธิ์ให้ตรงกับความต้องการเหล่านั้นเพียงพอสำหรับความต้องการของคุณ อย่างไรก็ตามหากคุณมีผู้ใช้จำนวนมากคุณอาจจะจมกับภาระในการรักษาบัญชีและสิทธิ์ที่เหมาะสม เพื่อลดภาระนี้ฐานข้อมูลเชิงสัมพันธ์สนับสนุนแนวคิดเรื่องบทบาท บทบาทของฐานข้อมูลทำหน้าที่เสมือนกลุ่ม Windows NT บัญชีผู้ใช้ถูกกำหนดให้กับบทบาทและสิทธิ์จะถูกกำหนดให้กับบทบาทโดยรวมมากกว่าบัญชีผู้ใช้แต่ละราย ตัวอย่างเช่นเราสามารถสร้างบทบาท DBA และเพิ่มบัญชีผู้ใช้ของเจ้าหน้าที่ผู้ดูแลระบบของเราเพื่อทำหน้าที่นี้ได้ เมื่อเราทำเช่นนี้แล้วเราสามารถมอบหมายสิทธิ์เฉพาะสำหรับผู้ดูแลระบบในปัจจุบัน (และอนาคต) โดยการมอบหมายสิทธิ์ในบทบาทนี้ ขั้นตอนการสร้างบทบาทแตกต่างกันไปในแต่ละแพลตฟอร์ม ผู้ดูแลระบบ MS SQL Server ควรตรวจสอบกระบวนงานที่เก็บไว้ sp_addrole ในขณะที่ Oracle DBA ควรใช้ไวยากรณ์ CREATE ROLE

การให้สิทธิ์

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

นี่คือไวยากรณ์ของคำสั่ง:

ให้สิทธิ์ <สิทธิ์>
[ON

]
TO
[WITH GRANT OPTION]

ตอนนี้ลองมาดูคำชี้แจงนี้ทีละบรรทัด บรรทัดแรก GRANT อนุญาตให้เราระบุสิทธิ์ของตารางที่เฉพาะเจาะจงที่เราอนุญาต เหล่านี้อาจเป็นสิทธิ์ระดับตาราง (เช่น SELECT, INSERT, UPDATE และ DELETE) หรือสิทธิ์ของฐานข้อมูล (เช่น CREATE TABLE, ALTER DATABASE และ GRANT) คุณสามารถได้รับสิทธิ์มากกว่าหนึ่งคำในงบ GRANT เดียว แต่สิทธิ์ในระดับตารางและสิทธิ์ระดับฐานข้อมูลอาจไม่สามารถรวมกันในคำสั่งเดียวได้

บรรทัดที่สอง ON

ใช้เพื่อระบุตารางที่ได้รับผลกระทบสำหรับสิทธิ์ระดับตาราง บรรทัดนี้ถูกละเว้นถ้าเราให้สิทธิ์ในระดับฐานข้อมูล บรรทัดที่สามระบุผู้ใช้หรือบทบาทที่ได้รับอนุญาต

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

ตัวอย่าง

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

GRANT SELECT, INSERT, UPDATE
ON ลูกค้า
TO DataEntry

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

GRANT CREATE TABLE
TO DBA
ด้วยตัวเลือก GRANT

โปรดสังเกตว่าเราได้รวมบรรทัด WITH GRANT OPTION เพื่อให้มั่นใจว่า DBA สามารถมอบหมายสิทธิ์นี้ให้กับผู้ใช้รายอื่นได้

กำลังลบสิทธิ์

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

REVOKE [GRANT OPTION FOR]
ON


FROM

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

ถอนการรับส่ง
ON ลูกค้า
จากแมรี่

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

ปฏิเสธ <สิทธิ์>
ON


TO <ผู้ใช้ / บทบาท

ตัวอย่าง

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

DENY DELETE
ON ลูกค้า
ถึงแมรี่

คำสั่ง DENY จะสร้าง "สิทธิ์เชิงลบ" ในการควบคุมการเข้าถึงฐานข้อมูล ถ้าภายหลังเราตัดสินใจที่จะให้ Mary อนุญาตลบแถวออกจากตาราง Customer เราไม่สามารถใช้คำสั่ง GRANT ได้ คำสั่งนั้นจะถูกแทนที่โดย DENY ที่มีอยู่โดยทันที แต่ก่อนอื่นเราจะใช้คำสั่ง REVOKE เพื่อลบรายการอนุญาตลบดังต่อไปนี้:

ถอนการรับส่ง
ON ลูกค้า
จากแมรี่

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

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