Mae diogelwch yn hollbwysig i weinyddwyr cronfa ddata sy'n ceisio diogelu eu gigabytes o ddata busnes hanfodol o lygaid prysur y tu allan i bobl anawdurdodedig a phobl eraill sy'n ceisio rhagori ar eu hawdurdod. Mae pob system rheoli cronfa ddata berthynas yn darparu rhyw fath o ddulliau diogelwch cynhenid a gynlluniwyd i leihau'r bygythiadau hyn. Maent yn amrywio o'r amddiffyniad cyfrinair syml a gynigir gan Microsoft Access i'r strwythur defnyddiwr / rôl gymhleth a ategir gan gronfeydd data perthynol datblygedig fel Oracle a Microsoft SQL Server. Mae'r erthygl hon yn canolbwyntio ar y mecanweithiau diogelwch sy'n gyffredin i bob cronfeydd data sy'n gweithredu'r Iaith Ymholiad Strwythuredig (neu SQL ). Gyda'n Gilydd, byddwn yn cerdded drwy'r broses o gryfhau rheolaethau mynediad data a sicrhau diogelwch eich data.
Defnyddwyr
Mae cronfeydd data sy'n seiliedig ar y gweinydd oll yn cefnogi cysyniad defnyddiwr sy'n debyg i'r hyn a ddefnyddir mewn systemau gweithredu cyfrifiadurol. Os ydych chi'n gyfarwydd â'r hierarchaeth defnyddiwr / grŵp a geir yn Microsoft Windows NT a Windows 2000, fe welwch fod y grwpiau defnyddiwr / rōl a gefnogir gan SQL Server ac Oracle yn debyg iawn.
Argymhellir yn gryf eich bod chi'n creu cyfrifon unigol o ddefnyddwyr cronfa ddata ar gyfer pob person a fydd yn mynd at eich cronfa ddata. Mae'n dechnegol bosibl i rannu cyfrifon rhwng defnyddwyr neu ddefnyddio un cyfrif defnyddiwr ar gyfer pob math o ddefnyddiwr sydd angen mynediad at eich cronfa ddata, ond rwyf yn rhoi'r gorau i'r ymarfer hwn yn gryf am ddau reswm. Yn gyntaf, bydd yn dileu atebolrwydd unigol-os yw defnyddiwr yn newid eich cronfa ddata (dywedwch wrth roi codi $ 5,000 iddo ei hun), ni fyddwch yn gallu ei olrhain yn ôl i berson penodol trwy ddefnyddio cofnodau archwilio. At hynny, os yw defnyddiwr penodol yn gadael eich sefydliad ac rydych am gael gwared ar ei fynediad o'r gronfa ddata, fe'ch gorfodir i newid y cyfrinair y mae pob defnyddiwr yn dibynnu arno.
Mae'r dulliau ar gyfer creu cyfrifon defnyddwyr yn amrywio o blatfform i lwyfan a bydd yn rhaid ichi ymgynghori â'ch dogfennau DBMS-benodol ar gyfer yr union weithdrefn. Dylai defnyddwyr Microsoft SQL Server ymchwilio i'r defnydd o'r weithdrefn storio sp_adduser. Bydd gweinyddwyr cronfa ddata Oracle yn canfod bod y gorchymyn DEFNYDDIWCH CREATE yn ddefnyddiol. Efallai y byddwch hefyd am ymchwilio i gynlluniau dilysu eraill. Er enghraifft, mae Microsoft SQL Server yn cefnogi'r defnydd o Ddiogelwch Integredig Windows NT. O dan y cynllun hwn, mae defnyddwyr yn cael eu dynodi i'r gronfa ddata gan eu cyfrifon defnyddwyr Windows NT ac nid oes gofyn iddynt nodi ID defnyddiwr a chyfrinair ychwanegol i gael mynediad i'r gronfa ddata. Mae'r ymagwedd hon yn hynod o boblogaidd ymysg gweinyddwyr cronfa ddata oherwydd ei fod yn newid baich rheoli cyfrifon i staff gweinyddol y rhwydwaith ac mae'n darparu rhwyddineb un arwydd ar y defnyddiwr terfynol.
Rolau
Os ydych mewn amgylchedd gyda nifer fechan o ddefnyddwyr, mae'n debyg y byddwch chi'n canfod bod creu cyfrifon defnyddwyr a rhoi caniatâd yn uniongyrchol iddynt yn ddigonol ar gyfer eich anghenion. Fodd bynnag, os oes gennych nifer fawr o ddefnyddwyr, mae'n debyg y bydd baich cynnal a chadw cyfrifon a chaniatâd priodol yn fwy tebygol o gael eich gorchuddio. Er mwyn hwyluso'r baich hwn, mae cronfeydd data perthynol yn cefnogi'r syniad o rolau. Mae rolau cronfa ddata yn gweithredu'n debyg i grwpiau Windows NT. Rhoddir cyfrifon defnyddiwr i rōl (au) a chaniateir caniatâd i'r rôl yn gyffredinol yn hytrach na'r cyfrifon defnyddwyr unigol. Er enghraifft, gallem greu rôl DBA ac yna ychwanegu cyfrifon defnyddwyr ein staff gweinyddol i'r rôl hon. Unwaith y byddwn wedi gwneud hyn, gallwn neilltuo caniatâd penodol i bob gweinyddwr presennol (a'r dyfodol) trwy roi caniatâd i'r rôl yn syml. Unwaith eto, mae'r gweithdrefnau ar gyfer creu rolau yn amrywio o blatfform i lwyfan. Dylai gweinyddwyr MS SQL Server ymchwilio'r weithdrefn storio sp_addrole tra dylai Oracle DBAs ddefnyddio cystrawen CREATE ROLE.
Rhoi Caniatadau
Nawr ein bod wedi ychwanegu defnyddwyr at ein cronfa ddata, mae'n bryd dechrau cryfhau diogelwch trwy ychwanegu caniatâd. Ein cam cyntaf fydd rhoi caniatâd cronfa ddata briodol i'n defnyddwyr. Byddwn yn cyflawni hyn trwy ddefnyddio'r datganiad GRANT SQL.
Dyma chystrawen y datganiad:
GRANT
[AR
I
[GYDA OPSIWN GRANT]
Nawr, gadewch i ni edrych ar y datganiad hwn llinell-wrth-lein. Mae'r llinell gyntaf, caniatād GRANT Defnyddir yr ail linell, AR Yn olaf, mae'r pedwerydd llinell, GYDA OPSIWN GRANT, yn ddewisol. Os yw'r llinell hon wedi'i chynnwys yn y datganiad, caniateir i'r defnyddiwr a effeithir hefyd ganiatáu'r un caniatâd hyn i ddefnyddwyr eraill. Sylwch na ellir nodi'r GYDA OPSIWN GRANT pan roddir y caniatâd i rôl. Edrychwn ar ychydig enghreifftiau. Yn ein senario cyntaf, rydym wedi cyflogi grŵp o 42 o weithredwyr mynediad data yn ddiweddar a fydd yn ychwanegu ac yn cynnal cofnodion cwsmeriaid. Mae angen iddynt allu cael gafael ar wybodaeth yn y tabl Cwsmeriaid, addasu'r wybodaeth hon ac ychwanegu cofnodion newydd i'r tabl. Ni ddylent allu dileu cofnod o'r gronfa ddata yn llwyr. Yn gyntaf, dylem greu cyfrifon defnyddwyr ar gyfer pob gweithredwr ac yna eu hychwanegu i rôl newydd, DataEntry. Nesaf, dylem ddefnyddio'r datganiad SQL canlynol er mwyn rhoi'r caniatâd priodol iddynt: GRANT SELECT, INSERT, DIWEDDARIAD A dyna'r cyfan sydd yno! Nawr, gadewch i ni archwilio achos lle rydyn ni'n gosod caniatâd lefel cronfa ddata. Rydym am ganiatáu i aelodau rôl DBA ychwanegu tablau newydd i'n cronfa ddata. At hynny, rydym am iddynt allu rhoi caniatâd i ddefnyddwyr eraill wneud yr un peth. Dyma ddatganiad SQL: GRANT CREATE TABL Rhowch wybod ein bod wedi cynnwys llinell GYDA OPSIWN GRANT i sicrhau y gall ein DBAs neilltuo'r caniatâd hwn i ddefnyddwyr eraill. Unwaith y byddwn wedi rhoi caniatâd, mae'n aml yn profi ei bod yn angenrheidiol i'w diddymu yn nes ymlaen. Yn ffodus, mae SQL yn rhoi'r gorchymyn REVOKE i ni gael gwared â chaniatâd a roddwyd yn flaenorol. Dyma'r gystrawen: REVOKE [OPSIWN GRANT AR GYFER] Byddwch yn sylwi bod cystrawen y gorchymyn hwn yn debyg i gyfarwyddyd GRANT. Yr unig wahaniaeth yw bod GYDA OPSIWN GRANT wedi'i nodi ar y llinell orchymyn REVOKE yn hytrach nag ar ddiwedd y gorchymyn. Fel enghraifft, gadewch i ni ddychmygu ein bod am ddiddymu caniatâd a ganiatawyd gan Mary i ddileu cofnodion o gronfa ddata'r Cwsmeriaid. Byddwn ni'n defnyddio'r gorchymyn canlynol: Diddymu DIWEDDARAF A dyna'r cyfan sydd yno! Mae yna un mecanwaith ychwanegol a gefnogir gan Microsoft SQL Server sy'n werth nodi - y gorchymyn DENY. Gellir defnyddio'r gorchymyn hwn i wrthod caniatâd i ddefnyddiwr y gallant fel arall gael drwy aelodaeth rôl bresennol neu yn y dyfodol. Dyma'r gystrawen: DENY Gan ddychwelyd i'n enghraifft flaenorol, gadewch i ni ddychmygu bod Mary hefyd yn aelod o rôl y Rheolwyr a oedd hefyd yn cael mynediad i dabl y Cwsmeriaid. Ni fyddai'r datganiad REVOKE blaenorol yn ddigonol i wrthod ei mynediad i'r bwrdd. Byddai'n dileu'r caniatâd a roddwyd iddi trwy ddatganiad GRANT yn targedu ei chyfrif defnyddiwr, ond ni fyddai'n effeithio ar y caniatadau a gafwyd trwy ei haelodaeth yn rôl y Rheolwyr. Fodd bynnag, os byddwn yn defnyddio datganiad DENY bydd yn rhwystro ei hetifeddiaeth y caniatâd. Dyma'r gorchymyn: DYLWCH YN DYLUNIO Yn y bôn, mae'r gorchymyn DENY yn creu "caniatâd negyddol" yn y rheolaethau mynediad cronfa ddata. Os byddwn yn penderfynu yn ddiweddarach i roi caniatâd i Mary gael gwared â rhesi o fwrdd y Cwsmeriaid, ni allwn ddefnyddio gorchymyn GRANT yn unig. Byddai'r gorchymyn hwnnw yn cael ei orchfygu ar unwaith gan y DENY presennol. Yn lle hynny, byddem yn gyntaf yn defnyddio'r gorchymyn REVOKE i gael gwared ar y caniatâd negyddol fel a ganlyn: Diddymu DIWEDDARAF Fe welwch fod y gorchymyn hwn yn union yr un fath â'r un a ddefnyddiwyd i gael gwared â chaniatâd cadarnhaol. Cofiwch fod y DENY a GRANT yn gorchymyn gweithio mewn modd tebyg * mdash; maent yn creu caniatâd (positif neu negyddol) yn y mecanwaith rheoli mynediad cronfa ddata. Mae'r gorchymyn REVOKE yn dileu'r holl ganiatâd positif a negyddol ar gyfer y defnyddiwr penodedig. Unwaith y bydd y gorchymyn hwn wedi'i gyhoeddi, bydd Mary yn gallu dileu rhesi o'r tabl os yw'n aelod o rôl sy'n meddu ar y caniatâd hwnnw. Fel arall, gellid rhoi gorchymyn GRANT i roi caniatâd DELETE yn uniongyrchol i'w chyfrif. Drwy gydol yr erthygl hon, rydych chi wedi dysgu llawer iawn am y mecanweithiau rheoli mynediad a gefnogir gan yr Iaith Gofynion Safonol. Dylai'r cyflwyniad hwn roi man cychwyn da i chi, ond yr wyf yn eich annog i gyfeirio eich dogfennau DBMS i ddysgu'r mesurau diogelwch gwell a gefnogir gan eich system. Fe welwch fod llawer o gronfeydd data yn cefnogi mecanweithiau rheoli mynediad mwy datblygedig, megis rhoi caniatadau ar golofnau penodol. , i bennu'r tabl yr effeithiwyd arno ar gyfer caniatadau lefel bwrdd. Eithrir y llinell hon os ydym yn rhoi caniatâd lefel cronfa ddata. Mae'r trydydd llinell yn pennu'r defnyddiwr neu'r rôl sy'n cael ei ganiatáu.
Enghreifftiau
AR Cwsmeriaid
I DataEntry
I DBA
GYDA OPSIWN GRANT Dileu Caniatâd
AR
O
AR Cwsmeriaid
GAN GAN
AR
I Enghreifftiau
AR Cwsmeriaid
I Mary
AR Cwsmeriaid
GAN GAN