Siguria është me rëndësi për administratorët e bazës së të dhënave që kërkojnë të mbrojnë gigabajt e tyre të të dhënave vitale të biznesit nga syri i uritur i të huajve të paautorizuar dhe të brendshëm që përpiqen të tejkalojnë autoritetin e tyre. Të gjitha sistemet relacionale të menaxhimit të bazës së të dhënave ofrojnë disa lloj mekanizmash të brendshëm të sigurisë të dizajnuara për të minimizuar këto kërcënime. Ato variojnë nga mbrojtja e thjeshtë e fjalëkalimeve e ofruar nga Microsoft Access në strukturën komplekse të përdoruesit / rolit të mbështetur nga bazat e të dhënave relacionale të avancuara si Oracle dhe Microsoft SQL Server. Ky artikull fokusohet në mekanizmat e sigurisë të përbashkëta për të gjitha bazat e të dhënave që zbatojnë strukturën e gjuhës së pyetjeve (ose SQL ). Së bashku, do të ecim përmes procesit të forcimit të kontrolleve të qasjes së të dhënave dhe sigurimit të sigurisë së të dhënave tuaja.
përdoruesit
Të gjitha bazat e të dhënave të bazuara në server mbështesin një koncept përdoruesi të ngjashëm me atë të përdorur në sistemet operative të kompjuterit. Nëse jeni të njohur me hierarkinë e përdoruesit / grupit që gjendet në Microsoft Windows NT dhe Windows 2000, do të gjeni se grupimet e përdoruesve / rolit të mbështetur nga SQL Server dhe Oracle janë shumë të ngjashme.
Është shumë e rekomandueshme që të krijoni llogari individuale të përdoruesve të bazës së të dhënave për secilin person i cili do të jetë duke hyrë në bazën tuaj të të dhënave. Është teknikisht e mundur të ndash llogaritë midis përdoruesve ose thjesht të përdorësh një llogari përdoruesi për secilin lloj përdoruesi që ka nevojë për të hyrë në bazën tuaj të të dhënave, por unë e dekurajoj fort këtë praktikë për dy arsye. Së pari, do të eliminojë llogaridhënien individuale - nëse një përdorues bën një ndryshim në bazën tuaj të të dhënave (le të themi duke i dhënë vetes një ngritje prej $ 5,000), nuk do të mund ta gjesh përsëri tek një person i veçantë përmes përdorimit të regjistrave të auditimit. Për më tepër, nëse një përdorues specifik largohet nga organizata juaj dhe ju dëshironi të hiqni qasjen e tij ose saj nga baza e të dhënave, do të detyroheni të ndryshoni fjalëkalimin që mbështeten të gjithë përdoruesit.
Metodat për krijimin e llogarive të përdoruesve ndryshojnë nga platforma në platformë dhe ju do të duhet të konsultoheni me dokumentacionin tuaj specifik DBMS për procedurën e saktë. Përdoruesit e Microsoft SQL Server duhet të hetojnë përdorimin e procedurës së ruajtjes së sp_adduser. Administratorët e bazës së të dhënave Oracle do të gjejnë komandën CREATE USER të dobishme. Ju gjithashtu mund të dëshironi të hetojë skemat alternative të autentifikimit. Për shembull, Microsoft SQL Server mbështet përdorimin e Windows NT Integrated Security. Nën këtë skemë, përdoruesit identifikohen në bazën e të dhënave nga llogaritë e tyre të përdoruesve të Windows NT dhe nuk kërkohet të futin një ID shtesë dhe fjalëkalim shtesë për të hyrë në bazën e të dhënave. Kjo qasje është jashtëzakonisht e popullarizuar në mesin e administratorëve të bazës së të dhënave, sepse ajo ndërron barrën e menaxhimit të llogarisë tek stafi i administratës së rrjetit dhe siguron lehtësinë e një shenje të vetme për përdoruesit përfundimtarë.
rolet
Nëse je në një mjedis me një numër të vogël përdoruesish, ndoshta do të gjesh që krijimi i llogarive të përdoruesve dhe caktimi i lejeve direkt tek ata është i mjaftueshëm për nevojat tuaja. Megjithatë, nëse keni një numër të madh përdoruesish, do të keni më shumë gjasa të jeni të mbingarkuar nga barra e mbajtjes së llogarive dhe lejeve të duhura. Për të lehtësuar këtë barrë, bazat e të dhënave relacionale mbështesin nocionin e roleve. Rolet e bazës së të dhënave funksionojnë në mënyrë të ngjashme me grupet e Windows NT. Llogaritë e përdoruesve janë të caktuara për rolin (rolet) dhe autorizimet pastaj i caktohen rolit në tërësi në vend të llogarive individuale të përdoruesve. Për shembull, mund të krijojmë një rol DBA dhe pastaj t'i shtojmë llogaritë e përdoruesve të stafit tonë administrativ për këtë rol. Sapo ta kemi bërë këtë, ne mund të caktojmë një leje të veçantë për të gjithë administratorët e pranishëm (dhe të ardhshëm) thjesht duke caktuar lejen për rolin. Edhe një herë, procedurat për krijimin e roleve ndryshojnë nga platforma në platformë. Administratorët e MS SQL Server duhet të hetojnë procedurën e ruajtjes së sp_addrole ndërsa DBA të Oracle duhet të përdorin sintaksën CREATE ROLE.
Lejimi i lejeve
Tani që kemi shtuar përdoruesit në bazën tonë të të dhënave, është koha për të filluar forcimin e sigurisë duke shtuar lejet. Hapi ynë i parë do të jetë dhënia e lejeve të përshtatshme të bazës së të dhënave për përdoruesit tanë. Ne do ta arrijmë këtë nëpërmjet përdorimit të deklaratës SQL GRANT.
Ja sintaksa e deklaratës:
GRANT
[ON
TO
[ME OPTION GRANT]
Tani, le të hedhim një vështrim në këtë deklaratë në vijë të rreshtave. Linja e parë, GRANT
Linja e dytë, ON
Së fundi, vija e katërt, ME GRANT OPTION, është fakultative. Nëse kjo linjë përfshihet në deklaratë, përdoruesi i prekur gjithashtu lejohet t'i japë këto leje të njëjta për përdoruesit e tjerë. Vini re që OPTION WITH GRANT nuk mund të specifikohet kur lejet janë caktuar për një rol.
shembuj
Le të shohim disa shembuj. Në skenarin tonë të parë, ne kemi angazhuar kohët e fundit një grup prej 42 operatorëve të hyrjes së të dhënave që do të shtojnë dhe ruajnë të dhënat e konsumatorëve. Ata duhet të jenë në gjendje të marrin informacion në tabelën e Konsumatorëve, të modifikojnë këtë informacion dhe të shtojnë të dhëna të reja në tabelë. Ata nuk duhet të jenë në gjendje të fshijnë tërësisht një rekord nga baza e të dhënave. Së pari, ne duhet të krijojmë llogari përdoruesi për secilin operator dhe pastaj t'i shtojmë të gjithë në një rol të ri, DataEntry. Tjetra, ne duhet të përdorim deklaratën SQL në vijim për t'u dhënë atyre lejet e duhura:
GRANT SELECT, INSERT, UPDATE
PËR Konsumatorët
TË DataEntry
Dhe kjo është e gjitha që ka për të! Tani le të shqyrtojmë një rast ku ne po caktojmë lejet e nivelit të bazës së të dhënave. Ne duam t'i lejojmë anëtarët e rolit të DBA të shtojnë tabela të reja në bazën tonë të të dhënave. Për më tepër, ne duam që ata të jenë në gjendje t'u japin përdoruesve të tjerë leje për të bërë të njëjtën gjë. Ja deklarata SQL:
GRANT CREATE TABLE
PËR DBA
ME ZGJEDHJEN E GRANTIT
Vini re se kemi përfshirë linjën WITH GRANT OPTION për të siguruar që DBA-të tona mund t'i caktojnë këto leje përdoruesve të tjerë.
Heqja e lejeve
Sapo të kemi dhënë leje, shpesh provohet e nevojshme për t'i revokuar ato në një datë të mëvonshme. Për fat të mirë, SQL na siguron me komandën REVOKE për të hequr lejet e dhëna më parë. Ja sintaksa:
REVOKE [GRANT OPTION FOR]
ON
NGA
Do të vëreni se sintakuza e këtij komanda është e ngjashme me atë të komandës GRANT. E vetmja ndryshim është që ME GRANT OPTION është specifikuar në rreshtin e komandës REVOKE dhe jo në fund të komandës. Si shembull, le të imagjinojmë se duam të heqim lejen e dhënë më parë nga Mary për të hequr të dhënat nga baza e të dhënave të Konsumatorëve. Ne do të përdorim komandën e mëposhtme:
SHKARKONI DELETE
PËR Konsumatorët
Nga Maria
Dhe kjo është e gjitha që ka për të! Ka një mekanizëm shtesë të mbështetur nga Microsoft SQL Server që vlen të përmendet - komanda DENY. Ky komandë mund të përdoret për të mohuar në mënyrë eksplicite një leje për një përdorues që ata mund të kenë përndryshe përmes një roli të tanishëm ose të ardhshëm. Ja sintaksa:
DENY Duke iu kthyer shembullit tonë të mëparshëm, le të imagjinojmë se Mary ishte gjithashtu një anëtar i rolit të Menaxherëve që gjithashtu kishte qasje në tryezën e Konsumatorëve. Deklarata e mëparshme REVOKE nuk do të ishte e mjaftueshme për të mohuar qasjen e saj në tryezë. Do të hiqte lejen e dhënë asaj nëpërmjet një deklarate GRANT që synonte llogarinë e saj të përdoruesit, por nuk do të ndikonte në lejet e fituara nëpërmjet anëtarësimit të saj në rolin e Menaxherëve. Megjithatë, nëse përdorim një deklaratë të DENY-it do të bllokojmë trashëgiminë e saj të lejes. Ja komanda: SHKARKONI DENIMIN Komanda DENY në thelb krijon një "leje negative" në kontrollet e qasjes në bazën e të dhënave. Nëse vendosim më vonë të japim lejen e Marisë për të hequr rreshta nga tryeza e Konsumatorëve, nuk mund ta përdorim thjesht komandën GRANT. Ky komandë do të hidhej menjëherë nga DENY ekzistuese. Në vend të kësaj, ne fillimisht do të përdorim komandën REVOKE për të hequr hyrjen negative të lejes si më poshtë: SHKARKONI DELETE Ju do të vini re se ky komandë është saktësisht e njëjtë me atë që përdoret për të hequr një leje pozitive. Mos harroni se DENY dhe GRANT komandojnë të dy punojnë në një mënyrë të ngjashme * mdash; ata të dy krijojnë leje (pozitive ose negative) në mekanizmin e kontrollit të qasjes së bazës së të dhënave. Komanda REVOKE heq të gjitha lejet pozitive dhe negative për përdoruesin e specifikuar. Pasi ky komandë është lëshuar, Maria do të jetë në gjendje të fshijë rreshtat nga tabela nëse ajo është një anëtar i një roli që posedon atë leje. Përndryshe, një urdhër GRANT mund të lëshohet për të dhënë lejen DELETE direkt në llogarinë e saj. Gjatë rrjedhës së këtij artikulli, ju keni mësuar shumë për mekanizmat e kontrollit të qasjes të mbështetura nga gjuha standarde e pyetjeve. Ky hyrje duhet t'ju ofrojë një pikënisje të mirë, por unë ju inkurajoj që t'i referoheni dokumentacionit DBMS tuaj për të mësuar masat e zgjeruara të sigurisë të mbështetura nga sistemi juaj. Do të gjeni se shumë baza të dhënash mbështesin mekanizmat më të avancuar të kontrollit të qasjes, si p.sh. dhënien e lejeve në kolona specifike.
ON
TO shembuj
PËR Konsumatorët
PËR Marinë
PËR Konsumatorët
Nga Maria