SQL-де пайдаланушылар мен рөлдер үшін қатынасты басқару

Қауіпсіздік - өздерінің гигабайттарын өмірлік маңызды деректерді қорғауға ұмтылатын әкімшіліктерге рұқсат етілмеген бөтен тұлғалардан және өз өкілеттіктерін асыруға тырысатын инсайдерлердің қуанышты көздерінен басымдылық. Реляциялық дерекқорды басқару жүйелері осы қауіптерді барынша азайтуға арналған қандай да бір ішкі қауіпсіздік механизмдерін ұсынады. Олар Oracle және Microsoft SQL Server сияқты алдыңғы қатарлы дерекқорлар қолдайтын күрделі пайдаланушы / рөл құрылымына Microsoft Access ұсынатын қарапайым құпия сөзбен қорғауды қамтиды. Бұл мақалада Structured Query Language (немесе SQL ) бағдарламасын іске асыратын барлық дерекқорларға арналған қауіпсіздік механизмдері қарастырылады. Бірлесе отырып, деректерге қол жеткізуді басқаруды күшейту және деректеріңіздің қауіпсіздігін қамтамасыз ету процесі арқылы жүреміз.

Пайдаланушылар

Серверге негізделген дерекқорлар компьютерлік амалдық жүйелерде пайдаланылатын пайдаланушы ұғымын қолдайды. Егер Microsoft Windows NT және Windows 2000 жүйесінде табылған пайдаланушы / топ иерархиясымен таныс болсаңыз, SQL Server және Oracle қолдау көрсететін пайдаланушы / рөл топтары өте ұқсас.

Дерекқорыңызға кіруге болатын әрбір адамға жеке дерекқордың пайдаланушы тіркелгілерін жасау ұсынылады. Пайдаланушылар арасында шоттарды бөлісудің техникалық мүмкіндігі бар немесе сіздің дерекқорыңызға кіруі қажет әр пайдаланушы түрі үшін бір пайдаланушының тіркелуін ғана қолдануға болады, бірақ мен бұл екі себеп бойынша қатты бас тартамын. Біріншіден, ол жеке есеп берушілікті жояды - егер пайдаланушы дерекқорыңызға өзгеріс енгізсе ($ 5000 көтеру арқылы айтып берсеңіз), оны аудит журналдарын пайдалану арқылы белгілі бір адамға қайтадан қадағалай алмайсыз. Сонымен қатар, белгілі бір пайдаланушы сіздің ұйымнан шығып кетсе және оның дерекқордан кіру рұқсатын жойғыңыз келсе, барлық пайдаланушыларға арналған парольді өзгертуге мәжбүр болады.

Пайдаланушы тіркелгілерін жасау әдістері платформаға платформаға қарай өзгереді және дәл рәсімге арналған ДББЖ-ға қатысты құжаттамамен кеңесу керек. Microsoft SQL Server пайдаланушылары sp_adduser сақталған процедурасын пайдалануды зерттеуі керек. Oracle дерекқорының әкімшілері CREATE USER пәрменін пайдалы деп табады. Балама аутентификация схемаларын зерттеуді де қаласаңыз болады. Мысалы, Microsoft SQL Server Windows NT Integrated Security пайдалануды қолдайды. Осы схема бойынша пайдаланушылар Windows NT пайдаланушы тіркелгілері арқылы дерекқорға сәйкестендіріледі және дерекқорға қатынасу үшін қосымша пайдаланушы идентификаторы мен құпия сөзін енгізу талап етілмейді. Бұл тәсіл дерекқор әкімшілері арасында өте танымал, себебі ол есепшотты басқару жүктемесін желі әкімшілігі қызметкерлеріне аударады және соңғы пайдаланушыға бір рет кіру мүмкіндігін береді.

Рөлдері

Егер сіз аздаған пайдаланушылар саны бар ортада болсаңыз, пайдаланушы тіркелгілерін жасау және оларға тікелей рұқсаттарды тағайындау сіздердің қажеттіліктеріңіз үшін жеткілікті екенін анықтаңыз. Дегенмен, сізде көптеген пайдаланушылар болса, шоттарды жүргізу және тиісті рұқсаттардың ауыртпалығы сізді еңсеруі мүмкін. Бұл жүктемені жеңілдету үшін реляциялық дерекқорлар рөлдердің ұғымын қолдайды. Дерекқор рөлдері Windows NT топтарына ұқсас. Пайдаланушы тіркелгілері рөлге тағайындалады және рұқсаттар жеке пайдаланушы тіркелгілерінен гөрі тұтастай рөлге тағайындалады. Мысалы, DBA рөлін жасай аламыз, содан кейін әкімшілік қызметкерлердің осы тіркелгіге арналған пайдаланушы тіркелгілерін қосамыз. Біз мұны жасағаннан кейін, рөлге рұқсат беру арқылы қазіргі (және болашақ) барлық әкімшілерге арнайы рұқсат беруді ұсынамыз. Тағы да, рөлдерді құру процедуралары платформадан платформаға байланысты. MS SQL Server әкімшілері sp_addrole сақталатын процедураны зерттеуі керек, ал Oracle DBA-лері CREATE ROLE синтаксисін пайдалану керек.

Рұқсаттарды беру

Енді біздің деректер базасына пайдаланушылар қосқандықтан, рұқсаттарды қосу арқылы қауіпсіздікті күшейтуге бастау керек. Біздің бірінші қадам пайдаланушыларға тиісті дерекқор рұқсатын беру болып табылады. Біз мұны SQL GRANT үзіндісін пайдалану арқылы орындаймыз.

Өтініштің синтаксисі:

GRANT <рұқсаттар>
[ON

]
TO <пайдаланушы / рөл>
[ГРАНТ опциясымен]

Енді осы мәлімдемені сызықпен қарастырайық. Бірінші жол, GRANT <рұқсаттар> бізге берілген нақты кесте рұқсаттарын көрсетуге мүмкіндік береді. Бұл кесте деңгейінің рұқсаттары (мысалы, SELECT, INSERT, UPDATE және DELETE) немесе дерекқор рұқсаттары (CREATE TABLE, ALTER DATABASE және GRANT сияқты) болуы мүмкін. Бірден артық рұқсат бір GRANT мәлімдемесінде берілуі мүмкін, бірақ кесте деңгейіндегі рұқсаттар мен дерекқор деңгейіндегі рұқсаттарды бірыңғай нұсқада біріктіру мүмкін емес.

Екінші жол, ON

, кесте деңгейіндегі рұқсаттарға қатысты кестені көрсету үшін пайдаланылады. Дерекқор деңгейіндегі рұқсаттар берілсе, бұл жол жоқ. Үшінші жолда рұқсаттар берілген пайдаланушы немесе рөл анықталады.

Соңында, төртінші жол, ГРАНТ ОПЦИЯСЫМЕН, міндетті емес. Егер бұл жол өтінішке қосылса, зардап шеккен пайдаланушыға сол басқа рұқсаттарды басқа пайдаланушыларға беруге рұқсат етіледі. Рұқсат рөлге тағайындалғанда, ГРАНТ ОПЦИЯСЫНЫҢ анықталуы мүмкін емес екенін ескеріңіз.

Мысалдар

Бірнеше мысал қарастырайық. Біздің бірінші сценарийімізде біз жақын арада клиенттердің жазбаларын қосып, ұстап тұратын 42 деректерді енгізу операторларының тобын жалдадық. Олар Тұтынушылар кестесіндегі ақпаратты ашуға, осы ақпаратты өзгертуге және кестеге жаңа жазбаларды қосуға тиіс болуы керек. Олар дерекқордан жазбаны толығымен жоя алмауы керек. Біріншіден, әрбір операторға арналған пайдаланушы тіркелгілерін жасау керек, содан кейін оларды барлық жаңа рөлге қосыңыз, DataEntry. Одан кейін, оларға тиісті рұқсаттарды беру үшін келесі SQL нұсқауын қолданған жөн:

GRANT SELECT, INSERT, UPDATE таңдаңыз
ON Клиенттер
TO DataEntry

Мұның бәрі бар! Енді дерекқор деңгейіндегі рұқсаттарды тағайындау жағдайын қарастырайық. Біз DBA рөлінің мүшелеріне дерекқорға жаңа кестелерді қосуды рұқсат етеміз. Сонымен қатар, біз басқа пайдаланушыларға бірдей рұқсат беру мүмкіндігіне ие болғымыз келеді. Міне SQL нұсқауы:

ГРАНТТЫҚ КЕСТЕ
TO DBA
GRANT OPTION арқылы

Біздің DBA-лер бұл рұқсатты басқа пайдаланушыларға бере алатындығына көз жеткізу үшін GRANT OPTION сызығымен бірге енгізілгенімізге назар аударыңыз.

Рұқсаттарды жою

Рұқсаттарды бергеннен кейін, оларды кейінірек алып тастау қажет. Бақытымызға қарай, SQL бізге бұрын берілген рұқсаттарды жоюға REVOKE пәрменін береді. Міне синтаксис:

REVOKE [GRANT OPTION FOR] үшін <рұқсаттар>
ON <үстел>
<Пайдаланушы / рөл> тармағынан

Бұл пәрменнің синтаксисі GRANT пәрменіне ұқсас екенін байқайсыз. Жалғыз айырмашылығы, GRANT OPTION командасымен командалардың соңында емес, REVOKE пәрмен жолында көрсетіледі. Мысал ретінде, Клиенттер дерекқорынан жазбаларды жоюға Мәриямға бұрын берілген рұқсатты қайтарып алуды қалаймыз деп елестетіп көрейік. Мына пәрменді пайдаланамыз:

REVOKE DELETE
ON Клиенттер
МЕРИЙДЕН

Мұның бәрі бар! Microsoft SQL Server қолдау көрсететін тағы бір қосымша механизм бар - бұл DENY командасы. Бұл пәрменді пайдаланушыға ағымдағы немесе келешектегі рольдік мүшелікте бола алатын рұқсатынан бас тартуға болады. Міне синтаксис:

DENY <рұқсаттар>
ON <үстел>
TO <пайдаланушы / рөл

Мысалдар

Алдыңғы мысалға оралсақ, Мария да Тұтынушылар кестесіне қол жеткізе алатын Менеджерлер рөлінің мүшесі болғанын елестетіп көрейік. Алдыңғы REVOKE мәлімдемесі кестеге қатынаудан бас тартуға жеткіліксіз еді. Ол өзінің қолданушы есебіне бағытталған ГРАНТ үзіндісі арқылы оған берілген рұқсатты алып тастайды, бірақ оның Менеджерлер рөлінде мүшелігі арқылы алынған рұқсаттарға әсер етпейді. Дегенмен, егер біз DENY мәлімдемесін қолданатын болсақ, ол оның мұрагерін бұғаттайды. Мынау:

DENY DELETE
ON Клиенттер
Мэриге

DENY командасы деректер базасына кіру рұқсаттарында «теріс рұқсатты» жасайды. Егер кейінірек Мэриге Клиенттер кестесінен жолдарды алып тастауға рұқсат берсеңіз, біз тек GRANT командасын пайдалана алмаймыз. Бұл команда бар DENY бірден жойылады. Оның орнына алдымен теріс рұқсат жазбасын келесідей жою үшін REVOKE пәрменін қолданамыз:

REVOKE DELETE
ON Клиенттер
МЕРИЙДЕН

Бұл пәрменнің оң рұқсатты алып тастау үшін қолданылатын бірдей екенін байқайсыз. DENY және GRANT командаларының екеуі ұқсас түрде жұмыс істейтінін есте сақтаңыз, олар дерекқорға қатынасты басқару механизмінде рұқсаттарды (оң немесе теріс) жасайды. REVOKE пәрмені көрсетілген пайдаланушы үшін барлық оң және теріс рұқсаттарды жояды. Бұл команда шығарылғаннан кейін, Мария бұл рұқсаты бар рөлге кіретін болса, кестеден жолдарды өшіре алады. Немесе DELETE рұқсатын тікелей шотына беру үшін GRANT командасы шығарылуы мүмкін.

Осы мақаланың барысында стандартты тілдесу тілін қолдайтын қатынауды басқару механизмдері туралы жақсы мәлімет алдыңыз. Бұл кіріспе сізге жақсы басталу нүктесін беруі керек, бірақ мен жүйеңіздің қолдауымен күшейтілген қауіпсіздік шараларын үйрену үшін ДББЖ құжаттамасына сілтеме жасауды ұсынамын. Көптеген дерекқорлар белгілі бір бағандарға рұқсаттар беру сияқты жетілдірілген қатынасты басқару тетіктерін қолдайды.