Անվտանգությունը առաջնային է տվյալների շտեմարանի ադմինիստրատորներին, որոնք ձգտում են պաշտպանել իրենց կարեւորագույն գործարար տվյալների գիգաբայթները `չարտոնված օտարերկրացիների եւ նրանց ներգրավված անձանց գերազանցող աչքերից: Բոլոր հարաբերական տվյալների բազայի կառավարման համակարգերը ապահովում են մի շարք ներքին անվտանգության մեխանիզմներ, որոնք նախատեսված են այդ սպառնալիքները նվազեցնելու համար: Նրանք ընդգրկում են Microsoft Access- ի կողմից մատուցվող պարզ գաղտնաբառի պաշտպանությունից բարդ Օգտվողի / դեր կառուցվածքը, որը աջակցում է Oracle- ի եւ Microsoft SQL Server- ի առաջադեմ տվյալների բազաներով: Այս հոդվածը կենտրոնանում է անվտանգության բոլոր մեխանիզմներին, որոնք տարածված են բոլոր տվյալների բազաների համար, որոնք իրականացնում են կառուցվածքային հարցման լեզու (կամ 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 եւ գաղտնաբառ մուտքագրել, տվյալների բազա մուտք գործելու համար: Տվյալ մոտեցումը շատ տարածված է տվյալների շտեմարանի ադմինիստրատորների շրջանում, քանի որ այն փոխանցում է հաշվի կառավարման ծանրաբեռնվածությունը ցանցային վարչարարության անձնակազմին եւ ապահովում է վերջնական օգտագործողին մի մուտք գործելու հեշտությունը:
Դերերում
Եթե դուք գտնվում եք փոքր քանակությամբ օգտվողների միջավայրում, դուք հավանաբար գտնում եք, որ օգտվողների հաշիվների ստեղծումը եւ նրանց ուղղակիորեն թույլտվությունները տրամադրելը բավարար է ձեր կարիքների համար: Այնուամենայնիվ, եթե դուք ունեք մեծ թվով օգտվողներ, ապա ամենայն հավանականությամբ, դուք կկարողանաք ճնշվել հաշիվների պահպանման եւ համապատասխան թույլտվությունների բեռով: Այս բեռը թեթեւացնելու համար հարաբերական տվյալների բազաները աջակցում են դերերի հասկացությանը: Տվյալների շտեմարանների դերերը նման են Windows NT խմբերի: Օգտագործողի հաշիվները նշանակվում են դերի (ներ) եւ թույլտվություններ, ապա դերի վրա որպես ամբողջություն, այլ ոչ թե անհատական հաշիվ: Օրինակ, մենք կարողացանք ստեղծել DBA- ի դերակատարություն եւ այնուհետեւ ավելացնել մեր վարչական անձնակազմի հաշիվները այս դերը: Երբ մենք արեցինք դա, մենք կարող ենք հատուկ թույլտվություն ներկայացնել ներկա (եւ ապագա) ադմինիստրատորներին, պարզապես դերի թույլտվությունը տալով: Կրկին ստեղծելով դերերի ստեղծման ընթացակարգերը տարբերվում են պլատֆորմի հարթությունից: MS SQL Server ադմինիստրատորները պետք է ուսումնասիրեն sp_addrole պահված ընթացակարգը, իսկ Oracle DBA- ն պետք է օգտագործի Ստեղծեք ROLE սինթետիկ:
Թույլտվություններ տրամադրելը
Այժմ, երբ մենք օգտվողներին ավելացրեցինք մեր տվյալների բազայում, եկել է ժամանակը, սկսելու թույլտվություն ավելացնելով անվտանգության ամրապնդումը: Մեր առաջին քայլը լինելու է համապատասխան տվյալների բազայի թույլտվությունները մեր օգտվողներին: Մենք դա կատարելու ենք SQL GRANT հայտարարության օգտագործման միջոցով:
Ահա հայտարարության շարադրանքն է.
ԳՐԱՆԹ <թույլտվություններ>
[ON
]
<
[ԳՐԱՆԹԱԿԱՆ ՕՊՏԻԱՅԻ ՀԵՏ]
Այժմ, եկեք դիտենք այս հայտարարությունը տող-by-line: Առաջին տողը, GRANT <թույլտվություններ>, թույլ է տալիս մեզ հստակեցնել տվյալ աղյուսակի թույլտվությունները, որոնք մենք տալիս ենք: Դրանք կարող են լինել կամ աղյուսակի մակարդակի թույլտվություններ (օրինակ SELECT, INSERT, UPDATE եւ DELETE) կամ տվյալների բազայի թույլտվություններ (օրինակ, CREATE TABLE, ALTER DATABASE եւ GRANT): Մեկից ավելի թույլտվություն կարող է տրվել մեկ GRANT հայտարարության մեջ, սակայն աղյուսակի մակարդակի թույլտվությունները եւ տվյալների բազայի մակարդակի թույլտվությունները չեն կարող համակցվել մեկ հայտարարության մեջ:
Երկրորդ տողը, ON
, օգտագործվում է աղյուսակի մակարդակի թույլտվությունների համար տուժած աղյուսակը որոշելու համար: Այս գիծը բացակայում է, եթե մենք տալիս ենք տվյալների բազայի թույլտվություններ: Երրորդ գիծը սահմանում է օգտագործողը կամ դերը, որը տրվում է թույլտվություններ:
Ի վերջո, չորրորդ գիծը, Հատված OPTION- ի հետ, ընտրովի է: Եթե այս տողը ներառված է հայտարարության մեջ, ազդակիր օգտվողին նույնպես թույլատրվում է նույն թույլտվությունները տրամադրել այլ օգտվողներին: Նշենք, որ ՀԱՎԵԼՎԱԾ ՀԱՎԵԼՅԱԼ ԸՆԿԵՐՈՒԹՅՈՒՆԸ չի կարող նշված լինել, երբ թույլտվությունները տրվում են դեր:
Օրինակներ
Եկեք մի քանի օրինակ դիտենք: Մեր առաջին սցենարի ժամանակ մենք վերջերս վարձել ենք տվյալների մուտքագրման 42 օպերատորների մի խումբ, որը կավելացնի հաճախորդների գրառումները: Նրանք պետք է կարողանան տեղեկատվություն ստանալ Հաճախորդների աղյուսակում, փոփոխել այս տեղեկատվությունը եւ ավելացնել նոր գրառումները սեղանին: Նրանք չպետք է ամբողջովին ջնջեն ռեեստրը տվյալների բազայից: Նախ, մենք պետք է ստեղծենք օգտվողների հաշիվներ յուրաքանչյուր օպերատորի համար եւ այնուհետեւ դրանք ավելացնենք նոր դեր, DataEntry: Հաջորդը, մենք պետք է օգտագործենք հետեւյալ SQL հայտարարությունը `համապատասխան թույլտվություններ տրամադրելու համար.
ԳՐԱՆԹ ԸՆՏՐՈՒԹՅՈՒՆ, ՆԵՐԴՐՈՒՄ, ԹՈՂԱՐԿՈՒՄ
Հաճախորդների մասին
ՏՆՏԵՍՏԻՆ
Եվ դա ամենը կա դրա համար: Այժմ ուսումնասիրենք այն դեպքը, երբ մենք տալիս ենք տվյալների բազայի մակարդակի թույլտվություններ: Մենք ցանկանում ենք թույլատրել DBA- ի դերակատարներին նոր աղյուսակներ ավելացնել մեր տվյալների բազայում: Բացի այդ, մենք ուզում ենք, որ նրանք կարողանան այլ օգտվողներին թույլ տալ, որպեսզի նույնը կատարեն: Ահա SQL հայտարարությունը.
ԳՐԱՆԹ ՍՏԵՂԾԵԼ ՏԵՔՍՏ
DBA- ին
ԳՐԱՆՑՎԱԾ ԸՆՏՐՈՒԹՅՈՒՆԻՑ ՀԵՏՈ
Ուշադրություն դարձրեք, որ մենք ընդգրկված ենք ՀԱՎԵԼՅԱԼ ՕՊՏԻվ գծով, ապահովելու համար, որ մեր DBA- ն կարող է այս թույլտվությունը փոխանցել այլ օգտվողներին:
Թույլտվությունների հեռացում
Երբ մենք թույլտվություն ենք տվել, դա հաճախ անհրաժեշտ է ապացուցում, որ հետագայում դրանք վերացնեն: Բարեբախտաբար, SQL- ը մեզ տրամադրում է REVOKE հրաման, նախկինում տրված թույլտվությունները հեռացնելու համար: Ահա սինտացիա:
REVOKE [ԳՐԱՆՑՄԱՆ ՆԿԱՏՄԱՄԲ] <թույլտվություններ>
ON
< - ից
Դուք նկատում եք, որ այս հրամանի տեքստը նման է GRANT- ի հրամանին: Միակ տարբերությունն այն է, որ GRANT OPTION- ի հետ REVOKE հրամանի տողում նշված է ոչ թե հրամանատարության վերջում: Որպես օրինակ, եկեք պատկերացնենք, որ մենք ցանկանում ենք վերացնել Մերիի նախկինում թույլ տրված թույլտվությունը `Հաճախորդների տվյալների բազայից գրառումները հեռացնելու համար: Մենք կօգտագործենք հետեւյալ հրահանգը.
REVOKE DELETE
Հաճախորդների մասին
Մարիամից
Եվ դա ամենը կա դրա համար: Կա մի լրացուցիչ մեխանիզմ, որն աջակցում է Microsoft SQL Server- ին, որը հարկ է նշել `DENY հրամանը: Այս հրամանը կարող է օգտագործվել, որպեսզի հստակորեն ժխտենք օգտագործողին թույլտվություն, որը նրանք կարող են այլ կերպ ներկայացնել ընթացիկ կամ ապագա դերային անդամակցության միջոցով: Ահա սինտացիա:
DENY <թույլտվություններ>
ON
<
Օրինակներ
Վերադառնալով մեր նախորդ օրինակը, եկեք պատկերացնենք, որ Մարիամը նաեւ Մենեջերների դերակատարում էր, որը նույնպես հասանելի էր Հաճախորդների սեղանին: Նախորդ REVOKE- ի հայտարարությունը բավարար չէր ժխտել սեղանին մուտք ունենալը: Այն կվերացնի նրան տրված թույլտվությունը GRANT- ի հայտարարության միջոցով, որը նպատակաուղղված է իր օգտագործողի հաշիվը, սակայն չի ազդի Մենեջերների դերակատարության մեջ ձեռք բերված թույլտվությունների վրա: Այնուամենայնիվ, եթե մենք օգտագործում ենք DENY- ի հայտարարությունը, ապա այն կկիրառի թույլտվության ժառանգությունը: Ահա հրամանը.
ԴԵՆԻ ԴԵԼՏԵ
Հաճախորդների մասին
Մարիամին
DENY հրամանը հիմնականում ստեղծում է «բացասական թույլտվություն» տվյալների բազայի հասանելիության վերահսկում: Եթե մենք ավելի ուշ որոշենք Մերիին թույլ տալ, որ Հաճախորդների սեղանից դուրս տողեր հեռացնենք, մենք չենք կարող պարզապես օգտագործել GRANT հրամանը: Այդ հրամանն անմիջապես կվերացվեր առկա DENY- ի կողմից: Փոխարենը, մենք առաջին հերթին օգտագործում ենք REVOKE հրամանը `բացասական թույլտվության մուտքի հեռացման համար.
REVOKE DELETE
Հաճախորդների մասին
Մարիամից
Դուք նկատում եք, որ այս հրամանը ճիշտ նույնն է, ինչ դրական թույլտվությունը հեռացնելու համար: Հիշեք, որ DENY- ի եւ GRANT- ի հրամանները երկուսն էլ աշխատում են նմանատիպ նորաձեւության մեջ, երկուսն էլ տվյալների բազայի մուտքի վերահսկման մեխանիզմում ստեղծում են թույլտվություններ (դրական կամ բացասական): REVOKE հրամանը հեռացնում է նշված օգտագործողի բոլոր դրական եւ բացասական թույլտվությունները: Երբ այս հրամանագիրը տրվել է, Մարիամը կարող է ջնջել տողերը սեղանից, եթե նա այդ դռանն ունի դերի անդամ: Այլապես, GRANT հրամանը կարող է տրվել, որպեսզի անմիջապես իր հաշիվը դադարեցվի:
Այս հոդվածի ընթացքում դուք սովորել եք լավ գործարք Ստանդարտ Հարցման Լեզվի աջակցությամբ մուտքի վերահսկման մեխանիզմների մասին: Այս ներածումը պետք է ապահովի ձեզ լավ մեկնարկային կետ, բայց ես կոչ եմ անում ձեզ տեղեկացնել ձեր ԴԴԾ փաստաթղթերի մասին `սովորելու ձեր համակարգով ապահովված անվտանգության ուժեղացված միջոցառումների մասին: Դուք կգտնեք, որ բազում տվյալների բազաները աջակցում են ավելի հասանելի մուտքի վերահսկման մեխանիզմներին, ինչպիսիք են հատուկ սյունակներում թույլտվությունները տրամադրելը: