ການຮັກສາຄວາມປອດໄພແມ່ນສໍາຄັນຕໍ່ກັບ ຜູ້ບໍລິຫານຖານຂໍ້ມູນທີ່ ກໍາລັງຊອກຫາເພື່ອປົກປ້ອງຂໍ້ມູນທຸລະກິດທີ່ສໍາຄັນຂອງພວກເຂົາຈາກຕາຢ້ານກົວຂອງຄົນພາຍນອກທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດແລະຜູ້ພາຍໃນພະຍາຍາມທີ່ຈະເກີນອໍານາດຂອງພວກເຂົາ. ລະບົບການຄຸ້ມຄອງຖານຂໍ້ມູນ ທັງຫມົດທີ່ພົວພັນກັບ ການຈັດຕັ້ງ ປະເພດຂອງກົນໄກຄວາມປອດໄພ intrinsic ທີ່ຖືກອອກແບບເພື່ອຫຼຸດຜ່ອນການຂົ່ມຂູ່ເຫລົ່ານີ້. ພວກເຂົາແມ່ນມາຈາກການປ້ອງກັນລະຫັດລັບງ່າຍໆໂດຍ Microsoft Access ກັບໂຄງສ້າງຜູ້ໃຊ້ / ໂຄງສ້າງທີ່ສະຫນັບສະຫນູນໂດຍຖານຂໍ້ມູນການພົວພັນແບບພິເສດເຊັ່ນ Oracle ແລະ Microsoft SQL Server. ບົດຄວາມນີ້ສຸມໃສ່ກົນໄກຄວາມປອດໄພທົ່ວໄປໃນຖານຂໍ້ມູນທັງຫມົດທີ່ປະຕິບັດ ພາສາຄໍາຖາມແບບໂຄງສ້າງ (ຫຼື SQL ). ຮ່ວມກັນ, ພວກເຮົາຈະຍ່າງຜ່ານຂະບວນການສ້າງຄວາມເຂັ້ມແຂງການຄວບຄຸມການເຂົ້າເຖິງຂໍ້ມູນແລະຮັບປະກັນຄວາມປອດໄພຂອງຂໍ້ມູນຂອງທ່ານ.
ຜູ້ໃຊ້
ຖານຂໍ້ມູນເຊີຟເວີທັງຫມົດສະຫນັບສະຫນູນແນວຄວາມຄິດຂອງຜູ້ໃຊ້ຄືກັນກັບທີ່ໃຊ້ໃນລະບົບປະຕິບັດການຄອມພິວເຕີ. ຖ້າທ່ານຄຸ້ນເຄີຍກັບລະບົບຜູ້ໃຊ້ / ກຸ່ມທີ່ພົບເຫັນໃນ Microsoft Windows NT ແລະ Windows 2000, ທ່ານຈະເຫັນວ່າກຸ່ມຜູ້ໃຊ້ / ກຸ່ມທີ່ສະຫນັບສະຫນູນໂດຍ SQL Server ແລະ Oracle ແມ່ນຄ້າຍຄືກັນຫຼາຍ.
ມັນໄດ້ຖືກແນະນໍາໃຫ້ສູງທີ່ທ່ານສ້າງບັນຊີຜູ້ໃຊ້ຖານຂໍ້ມູນແຕ່ລະຄົນສໍາລັບແຕ່ລະບຸກຄົນທີ່ຈະເຂົ້າເຖິງຖານຂໍ້ມູນຂອງທ່ານ. ມັນເປັນໄປໄດ້ທາງວິຊາການທີ່ຈະແບ່ງປັນບັນຊີລະຫວ່າງຜູ້ໃຊ້ຫຼືພຽງແຕ່ໃຊ້ບັນຊີຜູ້ໃຊ້ສໍາລັບແຕ່ລະປະເພດຂອງຜູ້ໃຊ້ທີ່ຈໍາເປັນຕ້ອງເຂົ້າເຖິງຖານຂໍ້ມູນຂອງທ່ານແຕ່ຂ້ອຍບໍ່ຢາກປະຕິເສດການປະຕິບັດນີ້ສໍາລັບສອງເຫດຜົນ. ຫນ້າທໍາອິດ, ມັນຈະລົບລ້າງຄວາມຮັບຜິດຊອບຂອງບຸກຄົນ - ຖ້າຜູ້ໃຊ້ເຮັດການປ່ຽນແປງຖານຂໍ້ມູນຂອງທ່ານ (ໃຫ້ເວົ້າໂດຍການຍົກຕົວເອງ $ 5,000), ທ່ານຈະບໍ່ສາມາດຕິດຕາມກັບບຸກຄົນໃດຫນຶ່ງຜ່ານການນໍາໃຊ້ບັນທຶກການກວດສອບ. ຍິ່ງໄປກວ່ານັ້ນ, ຖ້າຜູ້ໃຊ້ສະເພາະໃດຫນຶ່ງອອກຈາກອົງການຂອງທ່ານແລະທ່ານຕ້ອງການເອົາການເຂົ້າເຖິງຈາກຖານຂໍ້ມູນຂອງທ່ານ, ທ່ານຈະຖືກບັງຄັບໃຫ້ປ່ຽນລະຫັດຜ່ານທີ່ຜູ້ໃຊ້ທຸກຄົນໃຊ້.
ວິທີການສ້າງບັນຊີຜູ້ໃຊ້ແຕກຕ່າງຈາກແພລະຕະຟອມໄປສູ່ເວທີແລະທ່ານຈະຕ້ອງປຶກສາເອກະສານ DBMS ຂອງທ່ານສໍາລັບຂັ້ນຕອນທີ່ແນ່ນອນ. ຜູ້ໃຊ້ Microsoft SQL Server ຄວນສືບສວນການໃຊ້ sp_adduser stored procedure. ຜູ້ຄຸ້ມຄອງຖານຂໍ້ມູນ Oracle ຈະພົບຄໍາສັ່ງ CREATE USER ທີ່ເປັນປະໂຫຍດ. ທ່ານອາດຈະຕ້ອງການສືບສວນໂຄງການກວດສອບທາງເລືອກອີກ. ຕົວຢ່າງເຊັ່ນ Microsoft SQL Server ສະຫນັບສະຫນູນການໃຊ້ Windows NT Integrated Security. ພາຍໃຕ້ໂຄງການນີ້ຜູ້ໃຊ້ຈະຖືກກໍານົດໃຫ້ກັບຖານຂໍ້ມູນໂດຍບັນຊີຜູ້ໃຊ້ Windows NT ແລະບໍ່ຈໍາເປັນຕ້ອງໃສ່ ID ຜູ້ໃຊ້ແລະລະຫັດຜ່ານເພື່ອເຂົ້າເຖິງຖານຂໍ້ມູນ. ວິທີການນີ້ແມ່ນເປັນທີ່ນິຍົມກັນລະຫວ່າງຜູ້ບໍລິຫານຖານຂໍ້ມູນເນື່ອງຈາກວ່າມັນປ່ຽນຄວາມຮັບຜິດຊອບຂອງການຄຸ້ມຄອງບັນຊີກັບພະນັກງານຄຸ້ມຄອງເຄືອຂ່າຍແລະມັນສະຫນອງຄວາມງ່າຍດາຍຂອງການເຂົ້າສູ່ລະບົບດຽວກັບຜູ້ໃຊ້ສຸດທ້າຍ.
ບົດບາດ
ຖ້າທ່ານຢູ່ໃນສະພາບແວດລ້ອມທີ່ມີຈໍານວນຜູ້ໃຊ້ຂະຫນາດນ້ອຍ, ທ່ານອາດຈະພົບວ່າການສ້າງບັນຊີຜູ້ໃຊ້ແລະກໍານົດສິດອະນຸຍາດໂດຍກົງໃຫ້ພວກເຂົາແມ່ນພຽງພໍສໍາລັບຄວາມຕ້ອງການຂອງທ່ານ. ຢ່າງໃດກໍຕາມ, ຖ້າທ່ານມີຈໍານວນຜູ້ໃຊ້ຫຼາຍໆຄົນ, ທ່ານອາດຈະໄດ້ຮັບຜົນກະທົບຈາກຄວາມຮັບຜິດຊອບຂອງການຮັກສາບັນຊີແລະການອະນຸຍາດທີ່ເຫມາະສົມ. ເພື່ອຜ່ອນຜັນພາລະນີ້, ຖານຂໍ້ມູນການພົວພັນສະຫນັບສະຫນູນແນວຄິດຂອງພາລະບົດບາດ. ພາລະບົດບາດຂອງຖານຂໍ້ມູນປະຕິບັດຄ້າຍຄືກັນກັບກຸ່ມ Windows NT. ບັນຊີຜູ້ໃຊ້ຖືກມອບຫມາຍໃຫ້ບົດບາດ (s) ແລະອະນຸຍາດໃຫ້ມີການມອບຫມາຍໃຫ້ບົດບາດທັງຫມົດແທນທີ່ຈະເປັນບັນຊີຜູ້ໃຊ້ສ່ວນບຸກຄົນ. ຕົວຢ່າງ: ພວກເຮົາສາມາດສ້າງພາລະບົດບາດ DBA ແລະຫຼັງຈາກນັ້ນເພີ່ມບັນຊີຜູ້ໃຊ້ຂອງພະນັກງານບໍລິຫານຂອງພວກເຮົາໃຫ້ມີບົດບາດນີ້. ເມື່ອພວກເຮົາເຮັດສິ່ງນີ້, ພວກເຮົາສາມາດກໍາຫນົດການອະນຸຍາດເສພາະໃຫ້ຜູ້ບໍລິຫານທັງຫມົດໃນປະຈຸບັນ (ແລະໃນອະນາຄົດ) ໂດຍການແຕ່ງຕັ້ງການອະນຸຍາດໃຫ້ມີບົດບາດ. ເມື່ອອີກເທື່ອຫນຶ່ງ, ຂັ້ນຕອນການສ້າງພາລະບົດບາດແຕກຕ່າງກັນຈາກເວທີເພື່ອເວທີ. ຜູ້ເບິ່ງແລລະບົບ MS SQL Server ຄວນສືບສວນຂັ້ນຕອນທີ່ເກັບໄວ້ sp_addrole ໃນຂະນະທີ່ Oracle DBA ຄວນໃຊ້ syntax ROLE.
Granting Permissions
ໃນປັດຈຸບັນທີ່ພວກເຮົາໄດ້ເພີ່ມຜູ້ໃຊ້ໃນຖານຂໍ້ມູນຂອງພວກເຮົາ, ມັນແມ່ນເວລາທີ່ຈະເລີ່ມຕົ້ນການສ້າງຄວາມເຂັ້ມແຂງໃຫ້ໂດຍການເພີ່ມການອະນຸຍາດ. ຂັ້ນຕອນທໍາອິດຂອງພວກເຮົາແມ່ນຈະໃຫ້ສິດການໃຊ້ຖານຂໍ້ມູນທີ່ເຫມາະສົມແກ່ຜູ້ໃຊ້ຂອງພວກເຮົາ. ພວກເຮົາຈະເຮັດສໍາເລັດໂດຍຜ່ານການນໍາໃຊ້ຄໍາສັ່ງ SQL GRANT.
ນີ້ແມ່ນຄໍາສັບຂອງຄໍາເວົ້າທີ່ວ່າ:
GRANT ໃນປັດຈຸບັນ, ພວກເຮົາຈະເບິ່ງບົດລາຍງານນີ້ໂດຍກົງ. ເສັ້ນທໍາອິດ, GRANT ເສັ້ນທີສອງ, ON ສຸດທ້າຍ, ເສັ້ນທີສີ່, WITH GRANT OPTION, ແມ່ນທາງເລືອກ. ຖ້າເສັ້ນນີ້ຖືກລວມຢູ່ໃນຄໍາສັ່ງ, ຜູ້ໃຊ້ທີ່ຖືກກະທົບກໍ່ຖືກອະນຸຍາດໃຫ້ອະນຸຍາດໃຫ້ຜູ້ອື່ນໃຊ້. ໃຫ້ສັງເກດວ່າບໍ່ມີການລະບຸອະນຸຍາດໃຫ້ WITH GRANT OPTION ເມື່ອສິດໄດ້ຮັບການມອບຫມາຍໃຫ້ເປັນພາລະບົດບາດ. ໃຫ້ເບິ່ງຕົວຢ່າງສອງສາມຢ່າງ. ໃນສະຖານະການຄັ້ງທໍາອິດຂອງພວກເຮົາ, ພວກເຮົາໄດ້ຈ້າງຄົນກຸ່ມ 42 ຜູ້ເຂົ້າຂໍ້ມູນທີ່ຈະເພີ່ມແລະຮັກສາບັນທຶກຂອງລູກຄ້າ. ພວກເຂົາຕ້ອງການສາມາດເຂົ້າເຖິງຂໍ້ມູນໃນຕາຕະລາງລູກຄ້າ, ແກ້ໄຂຂໍ້ມູນນີ້ແລະເພີ່ມບັນທຶກໃຫມ່ໃນຕາຕະລາງ. ພວກເຂົາເຈົ້າບໍ່ຄວນຈະສາມາດລຶບບັນທຶກຈາກຖານຂໍ້ມູນໄດ້. ຫນ້າທໍາອິດ, ພວກເຮົາຄວນສ້າງບັນຊີຜູ້ໃຊ້ສໍາລັບຜູ້ປະຕິບັດງານແຕ່ລະຄົນແລະຫຼັງຈາກນັ້ນໃຫ້ພວກເຂົາເພີ່ມທັງຫມົດໃນພາລະບົດບາດໃຫມ່, DataEntry. ຕໍ່ໄປ, ພວກເຮົາຄວນໃຊ້ຄໍາສັ່ງ SQL ຕໍ່ໄປນີ້ເພື່ອໃຫ້ພວກເຂົາມີສິດເຫມາະສົມ: GRANT SELECT, INSERT, UPDATE ແລະວ່າທັງຫມົດແມ່ນຢູ່ກັບມັນ! ຕອນນີ້ໃຫ້ກວດເບິ່ງກໍລະນີທີ່ພວກເຮົາກໍາຫນົດການອະນຸຍາດໃນລະດັບຖານຂໍ້ມູນ. ພວກເຮົາຕ້ອງການອະນຸຍາດໃຫ້ສະມາຊິກຂອງບົດບາດຂອງ DBA ເພີ່ມຕາຕະລາງໃຫມ່ໃນຖານຂໍ້ມູນຂອງພວກເຮົາ. ຍິ່ງໄປກວ່ານັ້ນ, ພວກເຮົາຕ້ອງການໃຫ້ພວກເຂົາສາມາດອະນຸຍາດໃຫ້ຜູ້ໃຊ້ອື່ນໆອະນຸຍາດໃຫ້ເຮັດເຊັ່ນດຽວກັນ. ນີ້ແມ່ນຄໍາສັ່ງ SQL: GRANT CREATE TABLE ສັງເກດວ່າພວກເຮົາໄດ້ລວມເອົາຂໍ້ກໍານົດທາງ GRANT OPTION ເພື່ອຮັບປະກັນວ່າ DBA ຂອງພວກເຮົາສາມາດກໍາຫນົດການອະນຸຍາດນີ້ໃຫ້ກັບຜູ້ໃຊ້ອື່ນໆ. ເມື່ອພວກເຮົາໄດ້ຮັບອະນຸຍາດແລ້ວ, ມັນມັກຈະພິຈາລະນາຈໍາເປັນທີ່ຈະຖອນພວກມັນໃນວັນຕໍ່ມາ. ໂຊກດີ, SQL ສະຫນອງໃຫ້ພວກເຮົາກັບຄໍາສັ່ງ REVOKE ເພື່ອເອົາສິດອະນຸຍາດຜ່ານມາ. ນີ້ແມ່ນ syntax: REVOKE [GRANT OPTION FOR] ທ່ານຈະສັງເກດວ່າ syntax ຂອງຄໍາສັ່ງນີ້ແມ່ນຄ້າຍຄືກັບຄໍາສັ່ງຂອງ GRANT. ຄວາມແຕກຕ່າງກັນເທົ່ານັ້ນທີ່ມີ GRANT OPTION ຖືກລະບຸໄວ້ໃນເສັ້ນຄໍາສັ່ງ REVOKE ແທນທີ່ຈະຢູ່ໃນຕອນທ້າຍຂອງຄໍາສັ່ງ. ເປັນຕົວຢ່າງ, ໃຫ້ພວກເຮົາຈິນຕະນາການວ່າພວກເຮົາຕ້ອງການຍົກເລີກການອະນຸຍາດຂອງ Mary ກ່ອນທີ່ຈະລຶບບັນທຶກຈາກຖານຂໍ້ມູນລູກຄ້າ. ພວກເຮົາຕ້ອງໃຊ້ຄໍາສັ່ງຕໍ່ໄປນີ້: REVOKE DELETE ແລະວ່າທັງຫມົດແມ່ນຢູ່ກັບມັນ! ມີກົນໄກເພີ່ມເຕີມຫນຶ່ງທີ່ສະຫນັບສະຫນູນໂດຍ Microsoft SQL Server ທີ່ມີຄວາມຫມາຍ mentioning-DENY ຄໍາສັ່ງ. ຄໍາສັ່ງນີ້ສາມາດຖືກນໍາໃຊ້ຢ່າງຊັດເຈນປະຕິເສດການອະນຸຍາດໃຫ້ຜູ້ໃຊ້ທີ່ພວກເຂົາອາດຈະບໍ່ຜ່ານສະມາຊິກພາລະບົດບາດໃນປະຈຸບັນຫຼືໃນອະນາຄົດ. ນີ້ແມ່ນ syntax: DENY ກັບຄືນໄປບ່ອນຕົວຢ່າງທີ່ຜ່ານມາຂອງພວກເຮົາ, ຈິນຕະນາການວ່ານາງມາລີຍັງເປັນສະມາຊິກຂອງຜູ້ຈັດການທີ່ມີການເຂົ້າເຖິງຕາຕະລາງລູກຄ້າ. ຄໍາສັ່ງ REVOKE ກ່ອນຫນ້ານີ້ຈະບໍ່ພຽງພໍທີ່ຈະປະຕິເສດການເຂົ້າເຖິງຂອງນາງກັບຕາຕະລາງ. ມັນຈະເອົາໃບອະນຸຍາດທີ່ໄດ້ຮັບອະນຸຍາດໃຫ້ເຈົ້າຜ່ານຄໍາຖະແຫຼງທີ່ GRANT ກໍາຫນົດເປົ້າຫມາຍບັນຊີຜູ້ໃຊ້ຂອງເຈົ້າແຕ່ຈະບໍ່ມີຜົນກະທົບຕໍ່ການອະນຸຍາດທີ່ໄດ້ຮັບຈາກສະມາຊິກຂອງເຈົ້າໃນພາລະບົດບາດຜູ້ຈັດການ. ຢ່າງໃດກໍຕາມ, ຖ້າພວກເຮົາໃຊ້ຄໍາເວົ້າ DENY ມັນຈະເຮັດໃຫ້ມໍລະດົກຂອງເຈົ້າອະນຸຍາດ. ນີ້ແມ່ນຄໍາສັ່ງ: DENY DELETE ຄໍາສັ່ງ DENY ໄດ້ສ້າງເປັນ "ການອະນຸຍາດທາງລົບ" ໃນການຄວບຄຸມການເຂົ້າເຖິງຖານຂໍ້ມູນ. ຖ້າຫາກວ່າພວກເຮົາຕໍ່ມາຕັດສິນໃຈອະນຸຍາດໃຫ້ນາງ Maria ເອົາແຖວເກັດທີ່ຢູ່ຈາກຕາຕະລາງລູກຄ້າ, ພວກເຮົາບໍ່ສາມາດໃຊ້ຄໍາສັ່ງ GRANT. ຄໍາສັ່ງດັ່ງກ່າວຈະຖືກລົບລ້າງທັນທີໂດຍ DENY ທີ່ມີຢູ່ແລ້ວ. ແທນທີ່ຈະ, ຄັ້ງທໍາອິດພວກເຮົາຈະໃຊ້ຄໍາສັ່ງ REVOKE ເພື່ອເອົາການອະນຸຍາດທາງລົບອອກເປັນດັ່ງຕໍ່ໄປນີ້: REVOKE DELETE ທ່ານຈະສັງເກດເຫັນວ່າຄໍາສັ່ງນີ້ແມ່ນແທ້ຄືກັບທີ່ໃຊ້ໃນການຖອນການອະນຸຍາດໃນທາງບວກ. ຈົ່ງຈື່ໄວ້ວ່າຄໍາສັ່ງຂອງ DENY ແລະ GRANT ເຮັດວຽກຢູ່ໃນແບບດຽວກັນ * mdash ພວກເຂົາທັງສອງສ້າງສິດ (ທາງບວກຫລືລົບ) ໃນກົນໄກການຄວບຄຸມການເຂົ້າເຖິງຖານຂໍ້ມູນ. ຄໍາສັ່ງ REVOKE ລົບສິດທັງຫມົດໃນທາງບວກແລະລົບສໍາລັບຜູ້ໃຊ້ທີ່ກໍານົດໄວ້. ເມື່ອຄໍາສັ່ງນີ້ໄດ້ຖືກອອກມາ, ນາງ Mary ຈະສາມາດລຶບແຖວເກັດທີ່ຢູ່ໃນຕາຕະລາງຖ້ານາງເປັນສະມາຊິກຂອງບົດບາດທີ່ມີການອະນຸຍາດນັ້ນ. ອີກທາງຫນຶ່ງ, ຄໍາສັ່ງ GRANT ສາມາດອອກໄປໃຫ້ສິດ DELETE ໂດຍກົງກັບບັນຊີຂອງເຈົ້າ. ຕະຫຼອດເວລາຂອງບົດຄວາມນີ້, ທ່ານໄດ້ຮຽນຮູ້ກ່ຽວກັບກົນໄກການຄວບຄຸມການເຂົ້າເຖິງທີ່ສະຫນັບສະຫນູນພາສາຄໍາຖາມແບບມາດຕະຖານ. ແນະນໍານີ້ຄວນໃຫ້ທ່ານມີຈຸດເລີ່ມຕົ້ນທີ່ດີແຕ່ຂ້າພະເຈົ້າຂໍແນະນໍາທ່ານໃຫ້ອ້າງອີງເຖິງເອກະສານ DBMS ຂອງທ່ານເພື່ອຮຽນຮູ້ວິທີການຮັກສາຄວາມປອດໄພທີ່ເພີ່ມຂຶ້ນໂດຍລະບົບຂອງທ່ານ. ທ່ານຈະພົບເຫັນວ່າ ຖານຂໍ້ມູນ ຈໍານວນຫຼາຍສະຫນັບສະຫນູນກົນໄກຄວບຄຸມການເຂົ້າເຖິງແບບພິເສດຫຼາຍ, ເຊັ່ນ: ການອະນຸຍາດໃຫ້ມີສິດໃນຄໍລໍາສະເພາະ.
[ON ]
TO
[WITH OPTION OPTION]
, ຖືກນໍາໃຊ້ເພື່ອກໍານົດຕາຕະລາງທີ່ໄດ້ຮັບຜົນກະທົບສໍາລັບການອະນຸຍາດໃນລະດັບຕາຕະລາງ. ເສັ້ນນີ້ຖືກຍົກເວັ້ນຖ້າພວກເຮົາກໍາລັງອະນຸຍາດໃຫ້ມີລະດັບຖານຂໍ້ມູນ. ເສັ້ນທີສາມກໍານົດຜູ້ໃຊ້ຫຼືບົດບາດທີ່ກໍາລັງຖືກອະນຸຍາດ.
ຕົວຢ່າງ
ON ລູກຄ້າ
TO DataEntry
TO DBA
WITH OPEN OPTION ການຖອນການອະນຸຍາດ
ON
FROM
ON ລູກຄ້າ
ຈາກມາລີ
ON
TO ຕົວຢ່າງ
ON ລູກຄ້າ
TO Mary
ON ລູກຄ້າ
ຈາກມາລີ