એસક્યુએલમાં વપરાશકર્તાઓ અને ભૂમિકાઓ માટે વપરાશ નિયંત્રણ

અનધિકૃત બહારના લોકોની અંદરની વ્યક્તિઓ અને તેમના અધિકારીઓ કરતાં વધી જવાનો પ્રયાસ કરી રહેલી આંખોમાંથી મહત્વપૂર્ણ વ્યવસાય ડેટાના તેમના ગીગાબાઇટ્સને સુરક્ષિત રાખવા માટે ડેટાબેઝ એડમિનિસ્ટ્રેટર્સની સુરક્ષા સૌથી વધુ છે. તમામ રીલેશ્નલ ડેટાબેસ મેનેજમેન્ટ સિસ્ટમ આ પ્રકારની ધમકીઓને ઘટાડવા માટે રચાયેલ આંતરિક સિક્યોરિટી મિકેનિઝમ્સ પૂરી પાડે છે. તે ઓરેકલ અને માઈક્રોસોફ્ટ SQL સર્વર જેવા અદ્યતન રીલેશ્નલ ડેટાબેઝ દ્વારા સપોર્ટેડ જટિલ વપરાશકર્તા / રોલ માળખું માટે માઈક્રોસોફ્ટ એક્સેસ દ્વારા આપવામાં આવતી સરળ પાસવર્ડ પ્રોટેક્શનની શ્રેણી છે. આ લેખ સ્ટ્રક્ચર્ડ ક્વેરી લેંગ્વેજ (અથવા એસક્યુએલ ) ને અમલમાં મૂકાયેલા તમામ ડેટાબેસેસ માટે સામાન્ય સુરક્ષા મિકેનિઝમ્સ પર ધ્યાન કેન્દ્રિત કરે છે. એકસાથે, અમે ડેટા એક્સેસ નિયંત્રણોને મજબૂત બનાવવાની અને તમારા ડેટાની સલામતીને સુનિશ્ચિત કરવાની પ્રક્રિયામાંથી પસાર થઈશું.

વપરાશકર્તાઓ

સર્વર-આધારિત ડેટાબેઝો બધા કમ્પ્યુટર ઓપરેટિંગ સિસ્ટમ્સમાં વપરાતા જેવો જ વપરાશકર્તા વિચારધારાને સપોર્ટ કરે છે. જો તમે માઇક્રોસોફ્ટ વિન્ડોઝ એનટી અને વિન્ડોઝ 2000 માં મળેલી યુઝર / ગ્રુપ પદાનુક્રમથી પરિચિત છો, તો તમને મળશે કે SQL સર્વર અને ઓરેકલ દ્વારા સપોર્ટેડ યુઝર / રોલ ગ્રૂપ ખૂબ સમાન છે.

એ ખૂબ આગ્રહણીય છે કે તમે દરેક વ્યક્તિ માટે વ્યક્તિગત ડેટાબેઝ વપરાશકર્તા એકાઉન્ટ બનાવો કે જે તમારા ડેટાબેસને ઍક્સેસ કરશે. તે વપરાશકર્તાઓ માટેના ખાતાઓને શેર કરવા માટે તકનિકી રીતે શક્ય છે અથવા દરેક વપરાશકર્તાના વપરાશકર્તા માટે ફક્ત એક વપરાશકર્તા એકાઉન્ટનો ઉપયોગ કરો જે તમારા ડેટાબેસને ઍક્સેસ કરવાની જરૂર છે, પરંતુ હું આ પ્રથાને બે કારણોથી નિરુત્સાહ કરું છું. પ્રથમ, તે વ્યક્તિગત જવાબદારીને દૂર કરશે- જો કોઈ વપરાશકર્તા તમારા ડેટાબેસમાં પરિવર્તન કરે છે (ચાલો પોતાને 5,000 ડોલર એકત્ર કરીને કહીએ), તો તમે કોઈ વિશિષ્ટ વ્યક્તિને ઑડિટ લોગ્સના ઉપયોગથી પાછા શોધી શકશો નહીં. વળી, જો કોઈ ચોક્કસ વપરાશકર્તા તમારી સંસ્થાને છોડે છે અને તમે ડેટાબેઝમાંથી તેના અથવા તેણીની એક્સેસને દૂર કરવા માંગતા હો, તો તમને પાસવર્ડ બદલવાની ફરજ પડશે જે બધા વપરાશકર્તાઓ પર આધાર રાખે છે.

વપરાશકર્તા એકાઉન્ટ્સ બનાવવા માટેની પદ્ધતિઓ પ્લેટફોર્મ પરથી પ્લેટફોર્મ સુધી બદલાય છે અને તમારે ચોક્કસ પ્રક્રિયા માટે તમારા ડીબીએમએસ-વિશિષ્ટ દસ્તાવેજીકરણનો સંપર્ક કરવો પડશે. માઇક્રોસોફ્ટ SQL સર્વર વપરાશકર્તાઓએ sp_adduser સંગ્રહિત કાર્યપ્રણાલીના ઉપયોગની તપાસ કરવી જોઈએ. ઓરેકલ ડેટાબેઝ સંચાલકો CREATE USER કમાન્ડને ઉપયોગી બનાવશે. તમે પણ વૈકલ્પિક પ્રમાણીકરણ યોજનાઓ તપાસ કરી શકો છો ઉદાહરણ તરીકે, માઇક્રોસોફ્ટ SQL સર્વર વિન્ડોઝ એનટી ઈન્ટિગ્રેટેડ સિક્યોરિટીના ઉપયોગને ટેકો આપે છે. આ યોજના હેઠળ, વપરાશકર્તાઓને તેમના Windows NT વપરાશકર્તા ખાતા દ્વારા ડેટાબેઝ તરીકે ઓળખવામાં આવે છે અને ડેટાબેસને ઍક્સેસ કરવા માટે વધારાની વપરાશકર્તા ID અને પાસવર્ડ દાખલ કરવાની આવશ્યકતા નથી. આ અભિગમ ડેટાબેઝ એડમિનિસ્ટ્રેટર્સમાં અત્યંત લોકપ્રિય છે કારણ કે તે નેટવર્ક સંચાલન કર્મચારીઓને એકાઉન્ટ મેનેજમેન્ટના ભારણને બદલે છે અને તે અંતિમ વપરાશકર્તાને સિંગલ સાઇન-ઑનની સરળતા પૂરી પાડે છે.

ભૂમિકાઓ

જો તમે નાના વપરાશકર્તાઓ સાથે પર્યાવરણમાં છો, તો તમે કદાચ શોધી શકશો કે વપરાશકર્તા ખાતું બનાવવું અને તેમને સીધા જ પરવાનગીઓ આપવી તમારી જરૂરિયાતો માટે પૂરતી છે. જો કે, જો તમારી પાસે મોટી સંખ્યામાં વપરાશકર્તાઓ હોય, તો તમે મોટે ભાગે એકાઉન્ટ્સ જાળવવા અને યોગ્ય પરવાનગીઓના ભારથી ભરાઈ જાઓ છો. આ ભારણને સરળ બનાવવા માટે, રીલેશ્નલ ડેટાબેઝ ભૂમિકાઓની કલ્પનાને સમર્થન આપે છે. ડેટાબેઝની ભૂમિકાઓ Windows NT જૂથોની જેમ કાર્ય કરે છે. વપરાશકર્તા એકાઉન્ટ્સ ભૂમિકા (ઓ) ને સોંપવામાં આવે છે અને પરવાનગીઓ પછી વ્યક્તિગત વપરાશકર્તા એકાઉન્ટ્સની જગ્યાએ સંપૂર્ણ ભૂમિકાને સોંપવામાં આવે છે. ઉદાહરણ તરીકે, અમે એક ડીબીએ ભૂમિકા બનાવી શકીએ છીએ અને પછી આ ભૂમિકા માટે અમારા વહીવટી સ્ટાફના વપરાશકર્તા એકાઉન્ટ્સને ઉમેરી શકીએ છીએ. એકવાર અમે આ કરી લીધું છે, અમે ભૂમિકાને પરવાનગી સોંપણી દ્વારા ફક્ત બધા હાજર (અને ભવિષ્યના) સંચાલકોને ચોક્કસ પરવાનગી આપી શકીએ છીએ. એકવાર ફરી, ભૂમિકાઓ બનાવવા માટેની કાર્યવાહી પ્લેટફોર્મથી પ્લેટફોર્મ સુધી બદલાય છે. એમએસ એસક્યુએલ સર્વર સંચાલકોએ sp_addrol સંગ્રહિત કાર્યપદ્ધતિની તપાસ કરવી જોઈએ જ્યારે ઓરેકલ DBAs ને રોલે વાક્યરચના બનાવવી જોઈએ.

મંજૂરી આપો

હવે અમે વપરાશકર્તાઓને અમારા ડેટાબેસમાં ઉમેર્યા છે, પરવાનગીઓ ઉમેરીને સુરક્ષાને મજબૂત કરવાનું શરૂ કરવાનો સમય છે અમારું પ્રથમ પગલું અમારા વપરાશકર્તાઓને યોગ્ય ડેટાબેઝ પરવાનગીઓ આપવાનું રહેશે. અમે SQL GRANT નિવેદનના ઉપયોગ દ્વારા આ પૂર્ણ કરીશું.

અહીં સ્ટેટમેન્ટનું વાક્યરચના છે:

GRANT <પરવાનગીઓ>
[ON

]
TO
[GRANT OPTION સાથે]

હવે, ચાલો આ સ્ટેટમેન્ટ રેખા-બાય લાઇન પર એક નજર કરીએ. પ્રથમ રેખા, GRANT <પરવાનગીઓ>, અમને મંજૂરી આપેલ ચોક્કસ ટેબલ પરવાનગીઓનો ઉલ્લેખ કરવાની મંજૂરી આપે છે. આ કાં તો ટેબલ-લેવલ પરવાનગીઓ (જેમ કે SELECT, INSERT, UPDATE અને DELETE) અથવા ડેટાબેઝ પરવાનગીઓ (જેમ કે કૉપિ ટેબલ, એલટ ડેટાબેઝ અને GRANT) હોઈ શકે છે. એક કરતાં વધુ પરવાનગી એક જ GRANT નિવેદનમાં આપી શકાય છે, પરંતુ કોષ્ટક-સ્તરના પરવાનગીઓ અને ડેટાબેસ-સ્તર પરવાનગીઓ એક નિવેદનમાં સંયોજિત થઈ શકશે નહીં.

બીજી લાઇન, ON

, ટેબલ-સ્તર પરવાનગીઓ માટે પ્રભાવિત કોષ્ટકને ઉલ્લેખિત કરવા માટે વપરાય છે. જો અમે ડેટાબેસ-સ્તર પરવાનગીઓ આપીએ તો આ રેખા અવગણવામાં આવે છે. ત્રીજા વાક્ય વપરાશકર્તા અથવા ભૂમિકાને મંજૂરી આપે છે કે જે પરવાનગીઓ આપવામાં આવી છે.

છેલ્લે, ચોથો રેખા, GRANT OPTION સાથે, વૈકલ્પિક છે. જો આ વાક્ય વિધાનમાં શામેલ છે, તો અસરગ્રસ્ત વપરાશકર્તાને અન્ય વપરાશકર્તાઓને આ જ પરવાનગીઓ આપવાની પરવાનગી પણ છે. નોંધ કરો કે જેની સાથે પરવાનગીઓ ભૂમિકાને સોંપવામાં આવી છે ત્યારે સાથે GRANT વિકલ્પ સ્પષ્ટ કરી શકાશે નહીં.

ઉદાહરણો

ચાલો આપણે થોડા ઉદાહરણો જોઈએ. અમારા પ્રથમ દૃશ્યમાં, અમે તાજેતરમાં 42 ડેટા એન્ટ્રી ઑપરેટર્સનો એક જૂથ રાખ્યો છે જે ગ્રાહક રેકોર્ડ્સનો ઉમેરો અને જાળવશે. તેઓ ગ્રાહકોના કોષ્ટકમાં માહિતીને ઍક્સેસ કરવા, આ માહિતીને સંશોધિત કરવા અને કોષ્ટકમાં નવા વિક્રમો ઉમેરવા માટે સમર્થ હોવા જરૂરી છે. તેઓ ડેટાબેઝમાંથી સંપૂર્ણપણે રેકોર્ડ કાઢી શકતા નથી. પ્રથમ, અમારે દરેક ઓપરેટર માટે વપરાશકર્તા ખાતું બનાવવું જોઈએ અને તે પછી તેમને નવી ભૂમિકા, ડેટાએન્ટ્રીમાં ઉમેરો. આગળ, અમે તેમને યોગ્ય પરવાનગીઓ આપવા માટે નીચેના SQL સ્ટેટમેન્ટનો ઉપયોગ કરવો જોઈએ:

પસંદ કરો, દાખલ કરો, અપડેટ કરો
ગ્રાહકો પર
ડેટાએન્ટ્રી માટે

અને તે બધા ત્યાં છે! હવે ચાલો કેસની તપાસ કરીએ જ્યાં આપણે ડેટાબેઝ-સ્તરની પરવાનગીઓ આપી રહ્યા છીએ. અમે અમારા ડેટાબેઝમાં નવા કોષ્ટકોને ઉમેરવા માટે DBA રોલના સભ્યોને પરવાનગી આપીએ છીએ વળી, અમે ઇચ્છતા હોઈએ છીએ કે તે અન્ય વપરાશકર્તાઓને આવું કરવા માટે પરવાનગી આપે. અહીં SQL સ્ટેટમેન્ટ છે:

ટેબલ બનાવો
DBA ને
GRANT OPTION સાથે

નોંધ લો કે અમે આ સાથે GRANT OPTION રેખાનો સમાવેશ કર્યો છે જેથી કરીને ખાતરી થઈ શકે કે અમારા DBAs અન્ય વપરાશકર્તાઓને આ પરવાનગી આપી શકે છે.

પરવાનગીઓ દૂર કરી રહ્યા છીએ

એકવાર અમે પરવાનગીઓ મંજૂર કરી દીધા પછી, તે ઘણી વખત પછીની તારીખે તેમને રદ કરવા માટે જરૂરી પુરવાર કરે છે સદભાગ્યે, એસક્યુએલ અમને અગાઉ મંજૂર પરવાનગીઓ દૂર કરવા માટે REVOKE આદેશ સાથે પૂરી પાડે છે. અહીં વાક્યરચના છે:

REVOKE [પરવાનગીઓ માટે મંજૂરી આપો] <પરવાનગીઓ>
ON


થી

તમે નોંધ લો કે આ આદેશનું વાક્યરચના GRANT કમાન્ડની સમાન છે. માત્ર એટલો જ તફાવત એ છે કે GRANT OPTION સાથે આદેશની અંતમાં REVOKE કમાન્ડ રેખા પર સ્પષ્ટ કરેલ છે. ઉદાહરણ તરીકે, ચાલો કલ્પના કરીએ કે અમે મેરીની ગ્રાહક ડેટાબેઝમાંથી રેકોર્ડ્સને દૂર કરવા માટે અગાઉ મંજૂર કરેલી પરવાનગીને રદબાતલ કરવા માગીએ છીએ. અમે નીચેના આદેશનો ઉપયોગ કરીશું:

REVOKE DELETE
ગ્રાહકો પર
મેરીથી

અને તે બધા ત્યાં છે! માઈક્રોસોફ્ટ SQL સર્વર દ્વારા આધારભૂત એક વધારાના પદ્ધતિ છે જે ઉલ્લેખનીય છે- ડેની આદેશ. આ આદેશનો ઉપયોગ કોઈ વપરાશકર્તાની સ્પષ્ટ પરવાનગી આપવા માટે થઈ શકે છે કે જે કદાચ વર્તમાન અથવા ભાવિ ભૂમિકા સભ્યપદ દ્વારા હોય. અહીં વાક્યરચના છે:

ડીએનઆઇ <પરવાનગી>
ON


TO

ઉદાહરણો

અમારા અગાઉના ઉદાહરણ પર પાછા આવો, ચાલો કલ્પના કરીએ કે મેરી પણ મેનેજરની ભૂમિકાના સભ્ય હતા, જેની પાસે ગ્રાહક કોષ્ટકની ઍક્સેસ પણ હતી. પાછલા REVOKE નિવેદન ટેબલ પરની તેની ઍક્સેસને નકારવા માટે પૂરતું નથી. તે તેના વપરાશકર્તા એકાઉન્ટને લક્ષિત કરતી GRANT નિવેદન દ્વારા મંજૂર કરેલી પરવાનગીને દૂર કરશે, પરંતુ મેનેજર્સની ભૂમિકામાં તેણીની સભ્યપદ દ્વારા પ્રાપ્ત પરવાનગીઓને અસર કરશે નહીં. જો કે, જો અમે ડેની સ્ટેટમેન્ટનો ઉપયોગ કરીએ છીએ તો તે પરવાનગીની તેના વારસાને અવરોધિત કરશે. અહીં આદેશ છે:

ડેની કાઢી નાખો
ગ્રાહકો પર
મેરી માટે

ડેની આદેશ અનિવાર્યપણે ડેટાબેઝ ઍક્સેસ નિયંત્રણોમાં "નકારાત્મક પરવાનગી" બનાવે છે જો અમે પછીથી મેરીને ગ્રાહક કોષ્ટકમાંથી પંક્તિઓ દૂર કરવાની પરવાનગી આપવાનો નિર્ણય કર્યો, તો અમે ફક્ત GRANT કમાન્ડનો ઉપયોગ કરી શકતા નથી. તે આદેશ તાત્કાલિક ડેની દ્વારા ઓવરરાઇડ કરવામાં આવશે. તેના બદલે, અમે નીચે પ્રમાણે નકારાત્મક પરવાનગી એન્ટ્રી દૂર કરવા માટે REVOKE આદેશનો ઉપયોગ કરીશું:

REVOKE DELETE
ગ્રાહકો પર
મેરીથી

તમે જોશો કે આ આદેશ બરાબર એ જ છે કે જે સકારાત્મક પરવાનગીને દૂર કરવા માટે વપરાય છે. યાદ રાખો કે DENY અને GRANT બંને સમાન ફેશનમાં કામ કરે છે * mdash; તેઓ બન્ને ડેટાબેઝ એક્સેસ કંટ્રોલ મેકેનિઝમમાં પરવાનગીઓ (હકારાત્મક કે નકારાત્મક) બનાવે છે. REVOKE આદેશ ચોક્કસ વપરાશકર્તા માટે બધા હકારાત્મક અને નકારાત્મક પરવાનગીઓ દૂર કરે છે. એકવાર આ આદેશ જારી થઈ જાય તે પછી, મેરી તે ટેબલમાંથી પંક્તિઓ કાઢી શકે છે, જો તે તે ભૂમિકા ધરાવતી સભ્ય છે જે તે પરવાનગી ધરાવે છે. વૈકલ્પિક રૂપે, ડિલિટની પરવાનગી સીધી તેના ખાતામાં આપવા માટે GRANT કમાન્ડ જારી કરી શકાય છે.

આ લેખ દરમિયાન, સ્ટાન્ડર્ડ ક્વેરી લેંગ્વેજ દ્વારા સમર્થિત એક્સેસ કન્ટ્રોલ મિકેનિઝમ્સ વિશે તમે એક સારો સોદો શીખ્યા છો. આ રજૂઆતથી તમને એક સારા પ્રારંભિક બિંદુ મળી શકે છે, પરંતુ હું તમને તમારી સિસ્ટમ દ્વારા સપોર્ટેડ ઉન્નત સલામતી પગલાં જાણવા માટે તમારા ડીબીએમએસ દસ્તાવેજને સંદર્ભ આપવા પ્રોત્સાહિત કરું છું. તમે શોધી શકશો કે ઘણા ડેટાબેઝ વધુ એડવાન્સ્ડ એક્સેસ કંટ્રોલ મિકેનિઝમને સપોર્ટ કરે છે, જેમ કે ચોક્કસ કૉલમ્સ પર પરવાનગીઓ આપવી.