Turvalisus on ülioluline andmebaasi haldajatele, kes püüavad oma elutähtsate äriandmete gigabaiti kaitsta lubamatute kõrvaliste isikute ja siseringite eest, kes püüavad oma volitusi ületada. Kõik relatsioonandmebaasis juhtimissüsteemid pakuvad mingeid sisemisi turbemehhanisme, mis on kavandatud nende ohtude minimeerimiseks. Need ulatuvad lihtsast paroolikaitsest, mida pakub Microsoft Access keeruka kasutaja / rollistruktuuri, mida toetavad arenenud relatsioonandmebaasid, nagu Oracle ja Microsoft SQL Server. Käesolev artikkel keskendub turvamehhanismidele, mis on ühised kõigile andmebaasidele, mis rakendavad struktureeritud päringu keelt (või SQL ). Üheskoos läbime andmete juurdepääsu kontrollimise ja andmete turvalisuse tagamise protsessi.
Kasutajad
Kõik serveripõhised andmebaasid toetavad kasutajakontseptsiooni, mis sarnaneb arvutite operatsioonisüsteemides kasutatava mõistega. Kui olete tutvunud Microsoft Windows NT-i ja Windows 2000-ga leitud kasutaja / grupi hierarhiaga, leiad, et SQL Serveri ja Oracle'i poolt toetatavad kasutaja / rollirühmitused on väga sarnased.
On äärmiselt soovitatav, et loote üksikute andmebaasi kasutajate kontod iga inimese jaoks, kes pääsevad teie andmebaasi. Tehniliselt on võimalik kontod jagada kasutajate vahel või lihtsalt kasutada ühte kasutajakontot iga tüüpi kasutaja jaoks, kellel on juurdepääs teie andmebaasile, kuid ma pean tungivalt seda tava kaheks põhjuseks. Esiteks kõrvaldab see individuaalse aruandekohustuse - kui kasutaja muudab teie andmebaasi (ütleme näiteks, andes endale 5 000 dollarit tõusma), siis ei saa te auditilogide kasutamisel seda jälgida konkreetsele isikule. Lisaks sellele, kui konkreetne kasutaja lahkub teie organisatsioonist ja soovite oma juurdepääsu andmebaasist eemaldada, peate sind muutma parooli, millele kõik kasutajad tuginevad.
Kasutajakontode loomise meetodid erinevad platvormilt erinevate platvormide vahel ning peate täpset protseduuri kasutades oma DBMS-iga täpset dokumentatsiooni. Microsoft SQL Serveri kasutajad peaksid uurima sp_adduser salvestatud protseduuri kasutamist. Oracle'i andmebaasi administraatorid leiavad CREATE USERi käsu kasuliku. Samuti võite soovida uurida alternatiivseid autentimisskeeme. Näiteks Microsoft SQL Server toetab Windows NT integreeritud turbe kasutamist. Selle skeemi kohaselt tuvastavad kasutajad oma Windows NT kasutajakontod andmebaasi ja nad ei pea andmebaasi pääsemiseks sisestama täiendavat kasutajatunnust ja parooli. Selline lähenemine on andmebaasiside administraatorite hulgas üsna populaarne, kuna see muudab kontohalduse koormuse võrguhaldustöötajatele ja see lihtsustab lõppkasutajale ühekordse sisselogimist.
Rollid
Kui olete väikese arvu kasutajatega keskkonnas, siis tõenäoliselt leiate, et kasutajakontode loomine ja õiguste määramine neile otse on teie vajadustele piisav. Kuid kui teil on suur hulk kasutajaid, kipub tõenäoliselt kontode ja nõuetekohaste õiguste säilitamise koormus. Selle koormuse leevendamiseks toetavad relatsioonandmebaasid rollide mõistet. Andmebaasiülesanded toimivad sarnaselt Windows NT-i rühmadena. Kasutajakontod määratakse rollile ja seejärel määratakse õigused kogu rollile, mitte üksikutele kasutajakontodele. Näiteks võime luua DBA rolli ja seejärel lisada oma halduspersonali kasutajakontod selle rolli juurde. Kui oleme seda teinud, saame anda konkreetse loa kõigile olemasolevatele (ja tulevastele) administraatoritele, lihtsalt loovutades rolli. Veel kord on rollide loomise protseduurid platvormilt erinevad. MS SQL Serveri administraatorid peaksid uurima sp_addrole salvestatud protseduuri, samas kui Oracle'i DBA-d peaksid kasutama CREATE ROLE-i süntaksi.
Lubade andmine
Nüüd, kui oleme lisanud oma andmebaasi kasutajad, on aeg alustada turvalisuse suurendamist, lisades lubasid. Meie esimene samm on anda meie kasutajatele asjakohased andmebaasi õigused. Me teeme seda SQL GRANTi avalduse abil.
Siin on avalduse süntaks:
GRANT <õigused>
[ON ]
TO
[VÕISTLUSVÕIMALUSEGA]
Nüüd vaatame selle avalduse rida-realt. Esimene rida, GRANT võimaldab meil täpsustada konkreetseid lubasid, mida me andsime. Need võivad olla kas tabeli tasemed (nt SELECT, INSERT, UPDATE ja DELETE) või andmebaasi õigused (näiteks CREATE TABLE, ALTER DATABASE ja GRANT). Ühel GRANTi avaldusel võib anda rohkem kui ühe loa, kuid tabelis olevad õigused ja andmebaasi tasemed ei pruugi olla ühises avalduses ühendatud.
Teine rida, ON
, kasutatakse tabelis olevate lubatud õiguste tabelis oleva tabeli määramiseks. See rida jäetakse välja, kui anname andmebaasi tasemel õigusi. Kolmas rida määrab kasutaja või rolli, millele antakse õigusi.
Lõpuks on neljas rida, WITH GRANT OPTION, valikuline. Kui see rida avalduses sisaldub, võib mõjutatud kasutaja lubada ka teistele kasutajatele samu õigusi. Pange tähele, et loendiga WITH GRANT OPTION ei saa määrata, kui õigused on määratud rollile.
Näited
Vaatame mõningaid näiteid. Meie esimeses stsenaariumis oleme hiljuti tööle võtnud 42 andmete sisestamise operaatorit, kes lisavad ja säilitavad klientide andmeid. Neil peab olema võimalus pääseda klientide tabelis olevale teabele, seda teavet muuta ja tabeleid lisada uusi andmeid. Nad ei tohiks olla võimelised andmebaasi kirje täielikult kustutama. Esiteks peaksime looma kasutajakontosid iga operaatori jaoks ja seejärel lisama need kõik uuele rollile, DataEntry. Järgmiseks peame kasutama järgmisi SQL-i avaldusi, et neile anda vastavad õigused:
GRANT SELECT, INSERT, UPDATE
Kliendid ON
Andmebaasi juurde
Ja see on kõik selleks! Nüüd uurime juhtumit, kus me loome andmebaasi taseme õigused. Soovime lubada DBA rolli liikmetel meie andmebaasi uute tabelite lisamiseks. Lisaks tahame, et nad saaksid lubada teistel kasutajatel samu ülesandeid teha. Siin on SQL avaldus:
TOETAMISE TABEL
TO DBA
TOETUSE VÕIMALIK
Pange tähele, et oleme lisanud rida WITH GRANT OPTION, et tagada, et meie DBA-d saavad seda luba teistele kasutajatele määrata.
Õiguste eemaldamine
Kui oleme loa andnud, on sageli vaja neid hiljem tühistada. Õnneks annab SQL meile varasemate lubade eemaldamiseks käsku REVOKE. Siin on süntaks:
LÕPETAMINE [VÕISTLUSVÕIMALUS] <õigused>
ON
FROM
Märkate, et selle käsu süntaks on sarnane GRANTi käsuga. Ainus erinevus on see, et GRANTIMISE OPTION on määratud pigem REVOKE käsureale kui käsu lõpus. Näiteks võime kujutada, et tahame tühistada Maarja eelnevalt antud luba eemaldada Kliendi andmebaasist pärinevad andmed. Me kasutasime järgmist käsku:
Tühistama kustutama
Kliendid ON
Maarjast
Ja see on kõik selleks! Microsoft SQL Server toetab üht täiendavat mehhanismi, mida tasub mainida - käsk DENY. Seda käsku saab selgesõnaliselt keelata kasutajale antud luba, mida nad võivad muul viisil olla praeguse või tulevase rolli kuulumisega. Siin on süntaks:
DENY
ON
TO
Näited
Olles oma eelmise näitena tagasi pöördunud, nägem kujutlusvõimalusega, et ka Maarja oli juhtide rolli liige, kellel oli ka juurdepääs klientide tabelile. Eelmisele REVOKE avaldusele ei piisa, kui keeldute tema juurdepääsu tabelile. See eemaldaks talle tema kontot sihitud GRANTi avalduse kaudu antud loa, kuid see ei mõjuta juhtide rolli kaudu tema liikmeks antud õigusi. Kuid kui me kasutame DENY avaldust, blokeerime selle loa pärimise pärand. Siin on käsk:
Kustuta kustutada
Kliendid ON
Maarjale
DENY käsk loob sisuliselt andmebaasi juurdepääsu kontrollides negatiivse loa. Kui me hiljem otsustaksime Mary-l lubada klientide tabelist ridu eemaldada, ei saa me lihtsalt GRANTi käsku kasutada. Olemasolev DENY kaotab selle käsu kohe üle. Selle asemel kasutame negatiivse loa sissektsiooni eemaldamiseks kõigepealt käsku REVOKE:
Tühistama kustutama
Kliendid ON
Maarjast
Märkate, et see käsk on täpselt sama, mis positiivse loa eemaldamiseks. Pidage meeles, et DENY ja GRANT käsklused mõlemad töötavad sarnasel viisil *, mis mõlemad loovad andmebaasi juurdepääsu kontrollmehhanismis õigused (positiivsed või negatiivsed). Käsk REVOKE eemaldab kõik positiivsed ja negatiivsed õigused määratud kasutaja jaoks. Kui see käsk on välja antud, saab Mary kustutada tabelis olevaid ridu, kui ta on sellise loo omanik. Alternatiivina võidakse välja anda GRANTi käsk DELETE-loa andmiseks otse tema kontole.
Selle artikli jooksul olete õppinud standardse päringuliigi poolt toetatud juurdepääsu kontrollimehhanisme. See sissejuhatus peaks andma teile hea lähtepunkti, kuid ma soovitaksin teie DBMS-i dokumentatsiooni viidata teie süsteemis toetatud tõhustatud turvameetmete tundmaõppimiseks. Leiad, et paljud andmebaasid toetavad täpsemaid juurdepääsu kontrollimehhanisme, näiteks teatud veergude lubade andmist.