Drošība ir sevišķi svarīga datu bāzu administratoriem, kas cenšas aizsargāt savu svarīgo biznesa datu gigabaiti no nevēlamiem ārējiem lietotājiem un iekšējiem lietotājiem, cenšoties pārsniegt viņu pilnvaras. Visas relāciju datu bāzu pārvaldības sistēmas nodrošina zināmu drošības elementu modeli, kas paredzēti šo draudu mazināšanai. Tās svārstās no vienkāršas paroles aizsardzības, ko Microsoft Access piedāvā kompleksai lietotāja / lomu struktūrai, ko atbalsta progresīvas relāciju datu bāzes, piemēram, Oracle un Microsoft SQL Server. Šis raksts ir vērsts uz drošības mehānismiem, kas ir kopīgi visām datubāzēm, kuras īsteno strukturēto vaicājumu valodu (vai SQL ). Kopā mēs centīsimies uzlabot datu piekļuves kontroli un nodrošināt jūsu datu drošību.
Lietotāji
Serveru bāzes datubāzes atbalsta lietotāju koncepciju, kas ir līdzīga tai, ko izmanto datoru operētājsistēmās. Ja esat iepazinies ar lietotāja / grupas hierarhiju, kas atrodama Microsoft Windows NT un Windows 2000, jūs atradīsiet, ka lietotāju / lomu grupējumi, ko atbalsta SQL Server un Oracle, ir ļoti līdzīgi.
Ir ļoti ieteicams izveidot individuālus datu bāzes lietotāju kontus katrai personai, kas piekļūst jūsu datubāzei. Tehniski ir iespējams dalīties kontos starp lietotājiem vai vienkārši izmantot vienu lietotāja kontu katram lietotāja veidam, kuram nepieciešams piekļūt jūsu datubāzei, taču esmu ļoti atturējies no šīs prakses divu iemeslu dēļ. Pirmkārt, tas novērsīs individuālo atbildību - ja lietotājs mainīs jūsu datubāzi (teiksim, dodot sev 5000 USD palielinājumu), jūs nevarēsit to izsekot konkrētai personai, izmantojot revīzijas žurnālus. Turklāt, ja konkrēts lietotājs atstāj jūsu organizāciju un vēlaties noņemt savu piekļuvi no datubāzes, jums būs spiesti mainīt paroli, uz kuru visi lietotāji paļaujas.
Lietotāju kontu izveidošanas metodes atšķiras no platformas uz platformu, un precīzai procedūrai jākonsultējas ar DBMS īpašu dokumentāciju. Microsoft SQL Server lietotājiem ir jāizmeklē sp_adduser glabā procedūras izmantošana. Oracle datu bāzes administratori atradīs CREATE USER komandu noderīgu. Jūs arī varētu vēlēties izpētīt alternatīvās autentifikācijas shēmas. Piemēram, Microsoft SQL Server atbalsta Windows NT integrētās drošības lietošanu. Saskaņā ar šo shēmu lietotājus identificē datu bāzē to Windows NT lietotāju kontos, un tiem nav jāievada papildu lietotāja ID un parole, lai piekļūtu datu bāzei. Šī pieeja ir ārkārtīgi populāra datu bāzes administratoru vidū, jo tas pārveido konta pārvaldības slogu tīkla administrācijas personālam un nodrošina vienkāršu lietotāja pierakstīšanos.
Lomas
Ja atrodaties videi ar nelielu lietotāju skaitu, jūs, iespējams, uzzināsit, ka lietotāju kontu izveide un tieši tiem piešķirtās atļaujas ir pietiekama jūsu vajadzībām. Tomēr, ja jums ir liels lietotāju skaits, jūs, visticamāk, pārsteigsit ar kontu uzturēšanu un pareizām atļaujām. Lai atvieglotu šo slogu, relāciju datu bāzes atbalsta lomu jēdzienu. Datu bāzes lomas darbojas līdzīgi kā Windows NT grupās. Lietotāju konti tiek piešķirti lomai, un pēc tam atļaujas tiek piešķirtas lomai kopumā, nevis atsevišķiem lietotāju kontiem. Piemēram, mēs varētu izveidot DBA lomu un pēc tam pievienot šo administratīvo darbinieku lietotāju kontus šai lomai. Kad tas ir izdarīts, mēs varam piešķirt īpašu atļauju visiem pašreizējiem (un turpmākiem) administratoriem, vienkārši piešķirot atļauju lomai. Atkal lomu veidošanas procedūras atšķiras no platformas uz platformu. MS SQL Server administratoriem būtu jāizmeklē sp_addrole glabā procedūra, bet Oracle DBA izmanto CREATE ROLE sintaksi.
Piešķirt atļaujas
Tagad, kad esam pievienojuši lietotājus mūsu datubāzē, ir pienācis laiks sākt drošības stiprināšanu, pievienojot atļaujas. Mūsu pirmais solis būs nodrošināt mūsu lietotājiem atbilstošas datu bāzes atļaujas. Mēs to izdarīsim, izmantojot SQL GRANT paziņojumu.
Šeit ir izteikuma sintakse:
GRANT
[ON ]
TO
[AR GRANTU IZVĒLEI]
Tagad aplūkosim šo apgalvojumu pa vienam. Pirmā rindiņa, GRANT , ļauj mums norādīt konkrētās tabulas atļaujas, kuras mēs piešķiram. Tie var būt gan galda līmeņa atļaujas (piemēram, SELECT, INSERT, UPDATE un DELETE), vai datubāzes atļaujas (piemēram, CREATE TABLE, ALTER DATABASE un GRANT). Vienā GRANT paziņojumā var piešķirt vairāk nekā vienu atļauju, taču galda līmeņa atļaujas un datubāzes līmeņa atļaujas nedrīkst apvienot vienā paziņojumā.
Otrā rindiņa, ON
, tiek lietota, lai norādītu tabulā norādīto tabulu. Šī rindiņa tiek izlaista, ja mēs piešķiram datubāzes līmeņa atļaujas. Trešajā rindā norādīts lietotājs vai loma, kurai tiek piešķirtas atļaujas.
Visbeidzot, ceturtā rindiņa ar GRANT OPTION ir obligāta. Ja šī rinda ir iekļauta pārskatā, lietotājam, uz kuru ir skāris, ir atļauts piešķirt šīs pašas atļaujas citiem lietotājiem. Ievērojiet, ka AR GRANT OPTION nevar noteikt, kad atļaujas tiek piešķirtas lomai.
Piemēri
Apskatīsim dažus piemērus. Mūsu pirmajā scenārijā mēs nesen pieņēmām 42 datu ievadīšanas operatoru grupu, kas pievienos un uztur klientu uzskaiti. Viņiem ir jābūt iespējai piekļūt informācijai tabulā Klienti, mainīt šo informāciju un pievienot jaunus ierakstus tabulā. Viņiem nevajadzētu pilnībā izdzēst ierakstu no datubāzes. Pirmkārt, mums katram operatoram vajadzētu izveidot lietotāju kontus un pēc tam visus tos pievienot jaunai lomai, DataEntry. Tālāk mums vajadzētu izmantot šādu SQL, lai piešķirtu viņiem atbilstošas atļaujas:
GRANT SELECT, INSERT, UPDATE
ON klientiem
Uz DataEntry
Un tas viss ir tā! Tagad izpētīsim gadījumu, kad mēs piešķiram datubāzes līmeņa atļaujas. Mēs vēlamies ļaut DBA lomas dalībniekiem pievienot mūsu datubāzē jaunas tabulas. Turklāt mēs vēlamies, lai viņi varētu piešķirt citiem lietotājiem atļauju darīt to pašu. Lūk, SQL paziņojums:
GRANT CREATE TABLE
DBA
AR PIEPRASĪJUMA VEIDU
Ņemiet vērā, ka mēs esam iekļāvuši rindu AR GRANT OPTION, lai nodrošinātu, ka mūsu DBA var piešķirt šo atļauju citiem lietotājiem.
Atļaujas noņemšana
Kad mēs esam piešķīruši atļaujas, bieži vien ir nepieciešams atsaukt tos vēlāk. Par laimi, SQL nodrošina mums ar REVOKE komandu, lai noņemtu iepriekš piešķirtās atļaujas. Šeit ir sintakse:
ATCELŠANA [Piešķiršanas iespēja]
ON
NO
Jūs ievērosiet, ka šīs komandas sintakse ir līdzīga GRANT komandas sintaksei. Vienīgā atšķirība ir tā, ka AR GRANT OPTION ir norādīts uz REVOKE komandrindas, nevis komandas beigās. Piemēram, pieņemsim, ka mēs vēlamies atsaukt Marijas iepriekš piešķirto atļauju noņemt ierakstus no klientu datu bāzes. Mēs izmantosim šādu komandu:
REVOKE DELETE
ON klientiem
NO Mary
Un tas viss ir tā! Microsoft SQL Server, kuru vērts pieminēt, ir viens papildu mehānisms - komanda DENY. Šo komandu var izmantot, lai skaidri noraidītu lietotājam piešķirtu atļauju, ko viņi citādi varētu iegūt, izmantojot pašreizējo vai turpmāko lomu. Šeit ir sintakse:
DENY
ON
TO
Piemēri
Atgriežoties pie mūsu iepriekšējā piemēra, ļaujiet iedomāties, ka Marija bija arī Locekļu vadītāja loma, kurai bija arī piekļuve klientu tabulai. Iepriekšējā REVOKE paziņojuma nebūtu pietiekama, lai liegtu viņai piekļuvi galdam. Tas ļaus viņai piešķirt atļauju, izmantojot GRANT paziņojumu, kura mērķauditorija ir viņas lietotāja konts, bet neietekmēs tiesības, kas iegūtas, viņai pievienojoties vadītāju lomai. Tomēr, ja mēs izmantojam DENY paziņojumu, tas bloķēs viņas mantojumu par atļauju. Šeit ir komanda:
DENY DELETE
ON klientiem
Marijai
DENY komanda principā izveido "negatīvu atļauju" datu bāzu piekļuves kontrolē. Ja mēs vēlāk izlemsim atļauju Mary atņemt rindas no tabulas Customers, mēs nevaram vienkārši izmantot GRANT komandu. Šo komandu nekavējoties ignorē pašreizējais DENY. Tā vietā vispirms mēs izmantotu komandu REVOKE, lai noņemtu negatīvo atļauju ierakstu šādi:
REVOKE DELETE
ON klientiem
NO Mary
Jūs ievērosiet, ka šī komanda ir tieši tāpat kā tā, kuru izmanto, lai noņemtu pozitīvu atļauju. Atcerieties, ka DENY un GRANT komandas darbojas gan līdzīgā veidā, gan tie rada atļaujas (pozitīvas vai negatīvas) datu bāzes piekļuves kontroles mehānismā. REVOKE komanda noņem visas pozitīvās un negatīvās tiesības konkrētajam lietotājam. Kad šī komanda būs izsniegta, Marija no tabulas varēs izdzēst rindas, ja viņa ir tādas lomas loceklis, kurai ir šī atļauja. Alternatīvi GRANT komandu var izdot, lai nodrošinātu DELETE atļauju tieši viņas kontā.
Visā šī raksta laikā jūs esat iemācījušies daudz par piekļuves kontroles mehānismiem, kurus atbalsta standarta vaicājumu valoda. Šim ievadam vajadzētu nodrošināt labu sākuma punktu, taču es aicinu jūs atsaukties uz savu DBVS dokumentāciju, lai uzzinātu pastiprinātos drošības pasākumus, ko atbalsta jūsu sistēma. Jūs atradīsiet, ka daudzās datubāzēs tiek atbalstīti uzlaboti piekļuves kontroles mehānismi, piemēram, piešķirt atļaujas konkrētām slejām.