Аюулгүй байдал нь өгөгдлийн сангийн администраторууд өөрсдийн эрх мэдлээ хэтрүүлэхийг оролдсон зөвшөөрөлгүй гаднын хүмүүс, хараа хяналтгүй хүмүүсээс тэдний бизнесийн чухал өгөгдлүүдийг хамгаалахыг эрмэлздэг. Харилцааны өгөгдлийн сангийн менежментийн системүүд нь эдгээр аюулыг багасгахад чиглэгдсэн зарим төрлийн аюулгүй байдлын механизмтай байдаг. Тэдгээр нь Microsoft Access-ийн санал болгож буй нууц үгийн хамгаалалтын хамгаалалтаас Oracle болон Microsoft SQL Server зэрэг дэвшилтэт өгөгдлийн сангаас дэмждэг нарийн төвөгтэй хэрэглэгч / үүрэг бүтцээс хамаардаг. Энэ өгүүлэлд Structured Query Language (эсвэл SQL ) -ийг хэрэгжүүлдэг бүх өгөгдлийн сантай нийтлэг байдаг аюулгүй байдлын механизмууд дээр анхаарлаа хандуулдаг. Хамтдаа бид өгөгдлийн хандалтын хяналтыг бэхжүүлж, таны өгөгдлийн аюулгүй байдлыг хангах үйл явцыг даван туулах болно.
Хэрэглэгчид
Сервер дээр тулгуурласан мэдээллийн баазууд нь компьютерийн үйлдлийн системд хэрэглэгддэг хэрэглэгчийн концепцийг дэмждэг. Хэрэв та Microsoft Windows NT ба Windows 2000-д хэрэглэгчийн / бүлгийн шатлалыг мэддэг бол SQL Server болон Oracle-ийн дэмжлэгтэй хэрэглэгчийн / үүрэг бүлэг нь маш төстэй байна.
Таны өгөгдлийн санд хандах хүн болгоны мэдээллийн бааз хэрэглэгчийн данс үүсгэхийг маш ихээр зөвлөж байна. Энэ нь хэрэглэгчдийн хооронд данс солилцох, эсвэл хэрэглэгчийн өгөгдлийн санд хандах шаардлагатай хэрэглэгчдийн төрөл бүрийн дансны дугаарыг ашиглах боломжтой юм. Гэхдээ энэ практикийг хоёр шалтгааны улмаас би маш ихээр бууруулдаг. Нэгдүгээрт, энэ нь хувь хүний хариуцлагыг арилгаж өгнө. Хэрэв хэрэглэгч өөрийн мэдээллийн бааздаа өөрчлөлт хийвэл (өөртөө 5000 долларыг өсгөх гэх мэт), хэрэв та аудитын бүртгэлийг ашиглан тодорхой хүн рүү буцааж чадахгүй болно. Цаашилбал, хэрэв тодорхой хэрэглэгч таны байгууллагаас гарах бөгөөд мэдээллийн санд хандах хандалтыг устгахыг хүсвэл та бүх хэрэглэгчдийн найдвартай нууц үгийг солих шаардлагатай болно.
Хэрэглэгчийн данс үүсгэх аргууд нь платформоос платформ хүртэл өөр өөр байдаг бөгөөд та нарийн процедурын хувьд өөрийн DBMS -тэй холбоотой дэлгэрэнгүй баримтыг үзэх хэрэгтэй. Microsoft SQL Server хэрэглэгчид нь sp_adduser хадгалагдсан журмын хэрэглээг судлах хэрэгтэй. Oracle мэдээллийн баазын админууд нь CREATE USER командыг ашиглах болно. Та магадгүй өөр баталгаажуулалтын схемүүдийг шалгахыг хүсч болох юм. Жишээлбэл, Microsoft SQL Server нь Windows NT Integrated Security-ийг ашиглахыг дэмждэг. Энэ схемийн дагуу хэрэглэгчид нь Windows NT хэрэглэгчийн бүртгэлээр өгөгдлийн санд тодорхойлогдсон бөгөөд өгөгдлийн санд хандахын тулд нэмэлт хэрэглэгчийн ID болон нууц үгээ оруулах шаардлагагүй болно. Энэ арга нь өгөгдлийн сангийн администраторуудад маш их түгээмэл байдаг тул энэ нь дансны удирдлагын ачааллыг сүлжээний удирдлагын ажилтнуудад шилжүүлдэг бөгөөд энэ нь эцсийн хэрэглэгч рүү дан ганц нэвтрэх боломжийг олгоно.
Үүрэг
Хэрэв та цөөн тооны хэрэглэгчидтэй орчинд ажиллаж байгаа бол хэрэглэгчийн бүртгэл үүсгэх, тэдэнд зөвшөөрлийг шууд өгөх нь таны хэрэгцээнд хангалттай гэдгийг та олж магадгүй. Гэсэн хэдий ч, хэрэв та олон тооны хэрэглэгчидтэй бол бүртгэл, бүртгэлийг зөв зохистой зөвшөөрлөөр дарамтлах болно. Энэ ачааллыг хөнгөвчлөхийн тулд relational өгөгдлийн сан нь үүрэг хариуцлагын ойлголтыг дэмждэг. Өгөгдлийн сангийн үүрэг Windows NT бүлгүүдэд ижил үүрэг гүйцэтгэдэг. Хэрэглэгчийн бүртгэлүүд нь үүрэг болон зөвшөөрлүүдийг дараа нь хэрэглэгчийн данс гэхээсээ илүүтэйгээр бүхэлд нь үүрэг хариуцдаг. Жишээлбэл, бид DBA-ийн үүрэг үүсгэж, манай захиргааны ажилтнуудын хэрэглэгчийн бүртгэлийг энэ үүрэгт нэмнэ. Үүнийг хийсний дараа бид одоогийн бүх (болон ирээдүйн) администраторуудад тусгай зөвшөөрлийг өгөхдөө тусгай зөвшөөрлийг өгч болно. Дахин хэлэхэд, үүрэг гүйцэтгэх журам нь платформоос платформ хүртэл харилцан адилгүй байдаг. MS SQL Server администраторууд sp_addrole хадгалагдсан процедурыг судалж байх ёстой бөгөөд Oracle DBAs нь CREATE ROLE syntax-ийг ашиглах ёстой.
Зөвшөөрөл олгох
Одоо бид өөрсдийн мэдээллийн баазад хэрэглэгч нэмсэн тул зөвшөөрлийг нэмэх замаар аюулгүй байдлыг бэхжүүлж эхлэх цаг боллоо. Бидний анхны алхам бол хэрэглэгчдэд тохирох мэдээллийн баазыг олгох явдал юм. Бид SQL GRANT мэдэгдлийг ашиглан үүнийг хийж чадна.
Энд өгүүллийн синтакс байна:
GRANT <зөвшөөрөл>
[ON
дээр]
TO-г сонгоорой
[НАЙМДУГААР БҮЛЭГ]
Одоо, энэ мэдэгдлийг мөрдлээр нь харцгаая. Эхний мөрөнд GRANT зөвшөөрөх зөвшөөрөгдсөн тусгай зөвшөөрлийн хүснэгтийг тодорхойлж өгдөг. Эдгээр нь хүснэгтийн түвшний зөвшөөрлүүд (SELECT, INSERT, UPDATE ба DELETE гэх мэт) эсвэл өгөгдлийн сангийн зөвшөөрлүүд байж болно (CREATE TABLE, ALTER DATABASE болон GRANT гэх мэт). Нэг GRANT мэдэгдэлд нэгээс олон зөвшөөрлийг олгож болох боловч хүснэгт түвшний зөвшөөрлүүд болон мэдээллийн баазын түвшний зөвшөөрлүүдийг нэг мэдэгдэлд нэгтгэж болохгүй.
Хоёр дахь мөрөнд
дээр хүснэгтэнд зөвшөөрөгдсөн хүснэгтийг хүснэгтийн түвшний зөвшөөрлүүдийн хувьд зааж өгдөг. Хэрэв бид өгөгдлийн сангийн түвшний зөвшөөрлүүдийг зөвшөөрсөн бол энэ мөрийг орхисон болно. Гурав дахь мөрөнд зөвшөөрөгдсөн хэрэглэгч буюу үүрэг тодорхойлогдоно.
Эцэст нь, дөрөв дэх мөрөнд, НАЙРЛАГА сонгон шалгаруулалт нь заавал байх ёстой. Хэрэв энэ мөр нь мэдэгдэлд орсон бол нөлөөлөлд өртсөн хэрэглэгч бусад хэрэглэгчид эдгээр зөвшөөрлүүдийг олгохыг зөвшөөрдөг. Зөвшөөрөл олгогдох үед үүргийн хуваарилалтыг тодорхойлох боломжгүй.
Жишээ нь
Хэд хэдэн жишээг авч үзье. Бидний эхний хувилбарт бид саяхан мэдээлэл цуглуулах 42 операторчийг захиалагчийн бүртгэлийг нэмж, засварлах болно. Тэд хэрэглэгчийн хүснэгтэд мэдээлэл хандах, энэ мэдээллийг өөрчилж, шинэ мэдээллийг нэмж оруулах хэрэгтэй. Тэд өгөгдлийн сангаас бичлэгийг бүхэлд нь устгах боломжгүй байх ёстой. Нэгдүгээрт, бид оператор бүрийн хэрэглэгчийн бүртгэлийг үүсгэж, бүгдийг нь шинээр үүсгэх DataEntry-д нэмнэ. Дараа нь бид дараах зөвшөөрлийг өгөхийн тулд дараах зөвшөөрлийг өгөх ёстой:
НАЙМДУГААР СУРГУУЛЬ, INSERT, UPDATE
Хэрэглэгчид дээр
DataEntry дээр
Энэ бүхэн тэнд байна! Одоо бид өгөгдлийн сангийн түвшний зөвшөөрлийг өгч буй тохиолдлыг авч үзье. Бид DBA-ийн гишүүд өөрсдийн мэдээллийн санд шинэ хүснэгт нэмэхийг зөвшөөрөхийг хүсч байна. Цаашилбал, бид бусад хэрэглэгчид ижил зүйлийг хийх зөвшөөрөл өгөх боломжтой байхыг хүсч байна. Энд SQL statement:
ГЭРЭЛ ЗУРГИЙН ГАРЧИГ
DBA-д
ГРАНГИЙН СУРГАГААГҮЙ
Бидний DBAs бусад хэрэглэгчдэд энэ зөвшөөрлийг олгож болохыг баталгаажуулахын тулд бид GRANT OPTION шугамыг оруулсан.
Зөвшөөрлийг устгах
Зөвшөөрөл олгосны дараа тэдгээрийг сүүлд нь цуцлах шаардлагатай болдог. Аз болоход, SQL нь бидэнд урьд нь олгогдсон зөвшөөрлийг устгах REVOKE тушаалаар хангадаг. Энд синтакс байна:
REVOKE [НЭМЭЛТ ӨӨРЧЛӨЛТ] <зөвшөөрлүүд>
дээр
FROM
Энэ тушаалын синтакс нь GRANT тушаалынхтай төстэйг та анзаарах болно. Зөвхөн ялгаа нь GRANT OPTION WITH командын төгсгөлд биш харин REVOKE тушаалын мөрөнд тодорхойлогддог. Жишээ нь, Мэригийн хэрэглэгчийн мэдээллийн сангаас бүртгэлийг хасахын тулд өмнө нь зөвшөөрөгдсөн зөвшөөрлийг хүчингүй болгохыг хүсэж байна. Бид дараах тушаалыг ашиглах болно:
БУРУУЛАХГҮЙ
Хэрэглэгчид дээр
Маригаас
Энэ бүхэн тэнд байна! DENY командыг дурдах нь зүйтэй гэж Microsoft SQL Server дэмждэг нэг нэмэлт механизм бий. Энэ командыг одоо хэрэглэгдэж байгаа эсвэл ирээдүйн үүргийн гишүүнчлэлээр дамжуулан өөрөөр хэлбэл хэрэглэгчдэд зөвшөөрлийг нь үгүйсгэх зорилгоор ашиглаж болно. Энд синтакс байна:
DENY <зөвшөөрлүүд>
дээр
Жишээ нь
Өмнөх жишээн дээрээ эргэж харахдаа, Мэри нь Хэрэглэгчийн хүснэгтэд хандаж байсан менежерүүдийн үүрэг гүйцэтгэгчийн гишүүн байсан гэж төсөөлье. Өмнөх REVOKE мэдэгдэл нь түүний ширээн дээр нэвтрэх боломжийг үгүйсгэхгүй. Энэ нь түүний хэрэглэгчийн бүртгэлд хандах GRANT мэдэгдлээр түүнд олгосон зөвшөөрлийг нь хасах болно, гэхдээ түүний менежерүүдийн үүрэг ролийг гишүүдээр дамжуулан олж авсан зөвшөөрлүүдэд нөлөөлөхгүй. Гэсэн хэдий ч, хэрэв бид DENY мэдэгдэл хэрэглэвэл зөвшөөрлийн өвийг нь хааж болно. Энд дараах тушаал байна:
ХУДАЛДАН АВАХ
Хэрэглэгчид дээр
Мариа дээр
DENY тушаал нь мэдээллийн сангийн хандалтын хяналтуудад "сөрөг зөвшөөрөл" үүсгэдэг. Хэрэв бид хожим нь Мэригийн зөвшөөрлийг авахын тулд Мэригийн зөвшөөрлийг өгөхийг зөвшөөрөх юм бол бид GRANT тушаалыг ашиглах боломжгүй. Энэ тушаал нь одоо байгаа DENY-ээс нэн даруй дарагдсан байна. Үүний оронд бид эхлээд REVOKE тушаалыг сөрөг зөвшөөрлүүдийн бүртгэлийг дараах байдлаар арилгана:
БУРУУЛАХГҮЙ
Хэрэглэгчид дээр
Маригаас
Энэ тушаал нь эерэг зөвшөөрлийг устгахад хэрэглэсэнтэй яг ижилхэн болохыг та анзаарах болно. DENY болон GRANT тушаалууд нь хоёулаа ижил төстэй * mdash дээр ажилладаг гэдгийг санаарай; хоюулаа хоёулаа өгөгдлийн сангийн хандалтын хяналтын механизмд зөвшөөрөл (эерэг эсвэл сөрөг) үүсгэдэг гэдгийг санаарай. REVOKE команд нь заасан хэрэглэгчийн хувьд эерэг болон сөрөг зөвшөөрлүүдийг арилгах болно. Энэ тушаалыг гаргасны дараа Мэри тэр зөвшөөрлийг эзэмшсэн үүргийн гишүүн бол хүснэгтээс мөрүүдийг устгаж чадна. Өөрөөр, DELETE-ийн зөвшөөрлийг өөрийн дансанд шууд өгөхийн тулд GRANT команд өгч болно.
Энэ өгүүллийн туршид та Стандарт хайлтын хэлний дэмжлэгтэйгээр хандах хяналтын механизмын талаар сайн мэдэж авсан. Энэ танилцуулга нь танд сайн эхлэлийг өгөх болно. Гэвч танай системээр дэмжигдэх аюулгүй байдлын арга хэмжээг сайжруулахын тулд таны DBMS баримт бичгийг лавлахыг би та бүхнээс хүсч байна. Олон тооны өгөгдлийн сан нь тусгай баганад зөвшөөрлөөр олгодог зэрэг хандалтын хяналтын механизмуудыг илүү их дэмждэг болохыг олж мэднэ.