Sekureco estas plej grava al datumbazaj administrantoj, kiuj serĉas protekti siajn gigabajtojn de esencaj komercaj datumoj de la okuloj de ne rajtigitaj eksterlandanoj kaj insuloj provantaj superi sian aŭtoritaton. Ĉiuj rilataj datumbazaj sistemoj provizas iun tipon de sekurecaj mekanismoj desegnitaj por minimumigi ĉi tiujn minacojn. Ili iras de la simpla protekta pasvorto proponita de Microsoft Access al la kompleksa uzanto / rolo-strukturo subtenata de progresintaj rilataj datumbazoj kiel Oracle kaj Microsoft SQL Server. Ĉi tiu artikolo temas pri la sekurecaj mekanismoj komuna al ĉiuj datumbazoj kiuj aplikas la Strukturitan Query-Lingvo (aŭ SQL ). Kune, ni trairos la procezon de plifortigo de datumoj alireblaj kontroloj kaj certiganta la sekurecon de viaj datumoj.
Uzantoj
Servilaj datumbazoj ĉiuj subtenas uzantan koncepton simila al tiu uzata en komputilaj operaciumoj. Se vi estas konata kun la uzanto / grupa hierarkio trovita en Microsoft Windows NT kaj Windows 2000, vi trovos, ke la uzantoj / roloj-grupoj subtenataj de SQL-Servilo kaj Orakolo estas tre similaj.
Estas tre rekomendinda, ke vi kreu individuajn datumbazajn kontojn por ĉiu persono, kiu aliĝos al via datumbazo. Estas teknike ebla dividi kontojn inter uzantoj aŭ simple uzi unu uzanton-koncernon por ĉiu tipo de uzanto, kiu devas aliri vian datumbazon, sed mi forte malkuraĝigas ĉi tiun praktikon pro du kialoj. Unue, ĝi forigos individuan respondecon-se uzanto ŝanĝas vian datumbazon (ni diru, donante al si $ 5,000 USD), vi ne povos reteni ĝin al specifa persono per la uzado de registritaj registroj. Krome, se specifa uzanto forlasas vian organizon kaj vi volas forigi sian aliron de la datumbazo, vi devos ŝanĝi la pasvorton, kiun ĉiuj uzantoj fidas.
La metodoj por krei uzantajn kontojn varias de platformo al platformo kaj vi devos konsulti vian DBMS-specifa dokumentado por la ĝusta proceduro. Uzantoj de Microsoft SQL-Servilo devus esplori la uzon de la sp_adduser-stokita procedo. Administrantoj de datumbazoj de Orakolo trovos la utilajn KREU-USER-komandojn. Vi ankaŭ eble volas esplori alternativajn aŭtentikajn planojn. Ekzemple, Microsoft SQL-Servilo subtenas la uzon de Windows NT Integrated Security. Sub ĉi tiu skemo, uzantoj estas identigitaj al la datumbazo de siaj uzantoj de Windows NT kaj ne estas necesaj por eniri aldonan uzanton-ID kaj pasvorton por aliri la datumbazon. Ĉi tiu aliro estas ekstreme populara inter datumbazaj administrantoj, ĉar ĝi ŝanĝas la ŝarĝon de kontenta administrado al la administracia administrantaro kaj ĝi havigas la facilecon de sola signo al la fina uzanto.
Roloj
Se vi estas en medio kun malgranda nombro da uzantoj, vi verŝajne trovos, ke krei uzantajn kontojn kaj atribui permesojn rekte al ili sufiĉas por viaj bezonoj. Tamen, se vi havas multajn uzantojn, vi verŝajne estos superfortita de la ŝarĝo de konservado de kontoj kaj konvena permesoj. Por faciligi ĉi tiun ŝarĝon, rilataj datumbazoj subtenas la nocion de roloj. Funkciaj roloj funkcias simile al Windows NT-grupoj. Uzaj kontoj estas atribuataj al rolo (j) kaj permesoj tiam estas atribuitaj al la rolo en aro pli ol la individuaj uzantoj. Ekzemple, ni povus krei DBA-rolon kaj poste aldoni la uzantokontojn de nia administracia personaro al ĉi tiu rolo. Fojo ni faris ĉi tion, ni povas atribui specifan permeson al ĉiuj prezencantoj (kaj estontaj) administrantoj simple donante la permeson al la rolo. Denove, la proceduroj por krei listojn varias de platformo al platformo. La administrantoj de MS-SQL-serviloj devus esplori la sp_addrole-konservitan proceduron dum Oracle DBAs devus uzi la sintakson de CREATE ROLE.
Donante Permesojn
Nun, ke ni aldonis uzantojn al nia datumbazo, estas tempo komenci plifortigi sekurecon aldonante permesojn. Nia unua paŝo estos donaci konvenajn datumajn permesojn al niaj uzantoj. Ni plenumos tion per la uzo de la SQL-GRANT-aserto.
Jen la sintakso de la deklaro:
GRANT
[ON ]
TO
[KUN GRAN OPTION]
Nun, ni rigardu ĉi tiun deklaron line-by-line. La unua linio, GRANT permesas al ni specifi la specifajn tablajn permesojn, kiujn ni donas. Ĉi tiuj povas esti aŭ tablo-nivelaj permesoj (kiel SELECT, INSERT, UPDATE and DELETE) aŭ datumbazoj-permesoj (kiel ekzemple KREU TABLE, ALTER-DATABASE kaj GRANT). Pli ol unu permesilo povas esti donita en ununura GRANT-aserto, sed tablo-nivelaj permesoj kaj datumbazo-nivelaj permesoj ne povas esti kombinitaj en sola deklaro.
La dua linio, ON
, estas uzata por specifi la tuŝitan tablon por tabloj-nivelaj permesoj. Ĉi tiu linio preterlasas, se ni donas datumbazajn permesojn. La tria linio specifas la uzanton aŭ rolon, kiu estas donita permesojn.
Fine, la kvara linio, KUN GRANDA OPCIO, estas laŭvola. Se ĉi tiu linio estas inkluzivita en la deklaro, la uzanto trafita ankaŭ rajtas doni ĉi tiujn samajn permesojn al aliaj uzantoj. Rimarku, ke la KUNA GRANTO-OPPIO ne povas esti specifita kiam la permesoj estas atribuitaj al rolo.
Ekzemploj
Ni rigardu kelkajn ekzemplojn. En nia unua sceno, ni lastatempe kontraktis grupon de 42 datumaj enigrantaj operatoroj, kiuj aldonos kaj konservos klientajn rekordojn. Ili bezonas povi aliri informon en la Tablo de Klientoj, modifi ĉi tiun informon kaj aldoni novajn rekordojn al la tablo. Ili ne devus tute forigi registron de la datumbazo. Unue, ni devus krei uzantokontojn por ĉiu operatoro kaj poste aldoni ilin ĉiujn al nova rolo, DataEntry. Poste ni devas uzi la jenan SQL-komunikaĵon por doni al ili la taŭgajn permesojn:
GRANTULEKTO, INSERT, UPDATE
ON Klientoj
TO DatumojEntri
Kaj ĉio estas al ĝi! Nun ni ekzamenu kazon, kie ni atribuas datumbazon-nivelajn permesojn. Ni volas permesi al membroj de la DBA-rolon aldoni novajn tabulojn al nia datumbazo. Krome ni volas, ke ili povu permesi al aliaj uzantoj permeson fari la saman. Jen la deklaro de SQL:
GRANT KREU TABLEO
TO DBA
KUN GRAN OPPONO
Rimarku, ke ni inkluzivis la KUN GRANDA OPCION-linio por certigi, ke niaj DBAoj povas atribui ĉi tiun permeson al aliaj uzantoj.
Forigi Permesojn
Unufoje ni koncedis permesojn, ĝi ofte pruvas necese revoki ilin en posta dato. Feliĉe, SQL provizas al ni la REVOKE-komandon forigi antaŭajn permesojn. Jen la sintakso:
REVOKE [GRANT-OZONO]
ON
FROM
Vi rimarkos, ke la sintakso de ĉi tiu komando estas simila al tiu de la GRANT-komando. La sola diferenco estas, ke KUN GRANTO-OPCIO estas precizigita en la komandlinio REVOKE prefere ol ĉe la fino de la komando. Kiel ekzemplo, ni imagu, ke ni volas revoki la antaŭe permesitan permeson por forigi registrojn de la datumbazo de la Klientoj. Ni uzus la sekvan komandon:
REVOKE DELETE
ON Klientoj
De Maria
Kaj ĉio estas al ĝi! Ekzistas unu kroma mekanismo subtenata de Microsoft SQL-Servilo, kiu valoras mencii-la DEN-komandon. Ĉi tiu komando povas esti uzata por eksplicite nei permeson al uzanto, kiun ili alie povus havi per nuna aŭ estonta papero-membreco. Jen la sintakso:
DENY
ON
TO
Ekzemploj
Revenante al nia antaŭa ekzemplo, ni imagu, ke Maria ankaŭ estis membro de la rolo de Administrantoj, kiu ankaŭ havis aliron al la Tablo de Klientoj. La antaŭa REVOKE-deklaro ne sufiĉus por nei ŝian aliron al la tablo. Ĝi forigus la permeson donita al ŝi per GRANT-aserto celanta sian uzantokonton, sed ne influus la permesojn akiritajn per sia membreco en la rolo de Administrantoj. Tamen, se ni uzas DENY-deklaron, ĝi blokos sian heredaĵon de la permeso. Jen la komando:
Ĵus malplenigi
ON Klientoj
TO Maria
La DENY-komando esence kreas "negativan permeson" en la datumbazoj al la kontroloj de aliro. Se ni poste decidas doni al Maria permeson forigi vicojn de la Tablo de Klientoj, ni ne povas simple uzi la GRANT-komandon. Tiu komando estus tuj malpermesita de la ekzistanta DENY. Anstataŭe, ni unue uzos la REVOKE-komandon forigi la negativan eniron kiel sekvas:
REVOKE DELETE
ON Klientoj
De Maria
Vi rimarkos, ke ĉi tiu komando estas ĝuste la sama, kiel oni uzis por forigi pozitivan permeson. Memoru, ke la DENY kaj GRANT-komandoj ambaŭ funkcias simile, sed ambaŭ kreas permesojn (pozitivajn aŭ negativajn) en la datumbaza kontrolo-mekanismo. La komando REVOKE forigas ĉiujn pozitivajn kaj negativajn permesojn por la specifita uzanto. Post kiam ĉi tiu komando estas elsendita, Maria povos forigi vicojn de la tablo se ŝi estas membro de rolo, kiu havas tiun permeson. Alternative, GRANT-komando povus esti elsendita por provizi la DELETE-permeson rekte al ŝia konto.
Laŭlonge de ĉi tiu artikolo, vi lernis bonan interkonsenton pri la alira kontrolo-mekanismoj subtenataj de la Norma Lingvo-Lingvo. Ĉi tiu enkonduko devus doni al vi bonan komencpunkton, sed mi instigas vin referencigi vian DBMS-dokumentadon por lerni la plibonigitajn sekurecajn mezurojn apogitajn de via sistemo. Vi trovos, ke multaj datumbazoj subtenas pli altnivelajn kontrolprogramajn mekanismojn, kiel doni permesojn pri specifaj kolumnoj.