12 sigurnost

Zatitite svoju imovinu

Utroili ste ogromnu koliinu vremena i energije u kreiranje vae baze. Bili biste
razoarani kad bi joj se bilo ta dogodilo. Takoe, morate dati i drugim ljudima pristup vaim podacima, i zabrinuti ste da bi mogli dodavati i aurirati neke podatke pogreno, ili jo gore, mogli bi izbrisati pogrene podatke. Uskoro dete da nauite kako baze i podaci u njima mogu biti sigurniji, i kako moete imati kompletnu kontrolu nad ko moe i ta moe sa vaim podacima.

Problemi korisnika
Pradenje klovnova je uzletjelo tako visoko da gradsko vijede Dataville-a je moralo zaposliti cijeli tim ljudi da trai klovnove i da zapisuje njihove podatke u Clown_tracking bazu. Naalost, tim je prevaren od strane klovna preruenog u svakodnevnu odjedu koji se predstavljao kodnim imenom George. On je stvorio veliki broj problema za bazu, ukljuujudi gubljenje vanih podataka, promjenu podataka, i duplih podataka koji postoje zbog njegovog loeg pravopisa. Ovdje je samo par problema sa bazom pradenja klovnova:

Snuggles, Snugles i Snuggels imaju red u tabeli clown_info. Svi smo sigurni da je to jedan isti klaun zato to kolone spol i opis su mu iste (osim pravopisa). Sa ovakvim istim unosima u tabelu clown_info dobili smo pravi nered sa naim stvarnim podacima. Tabela info_location koristi clown_info ID za Snuggles, Snugles i Snuggels. Tabela activities je takoer puna pravopisnih greaka. Snuggles je juggeler, Snugles je jugeler, a Snuggels je jugalar.

Izbjegavanje greaka u bazi pradenja klovnova

George je dao otkaz prije nego li je neko primijetio da je sabotirao podatke, a na nama je ostalo da ispravljamo njegove greke. Od sada, kada budemo zapoljavali nove radnike, morat demo im dati mogudnost SELECT-ovanja (pregledanja baze) tako da mogu identifikovati klovnove. Ali elimo ih sprijeiti od INSERT-ovanja podataka ili njihovog UPDATE-ovanja, ili bilo ega dok ne budemo imali dovoljno vremena da uradimo opiran rutinski pregled. Takoer, moramo biti veoma oprezni; kada zamolimo nae zaposlenike da DELETE (izbriu) podatke kako bi izbrisali George-ove greke, mogli bi ak izbrisati i dobre podatke pored onih loih. Vrijeme je da zatitimo bazu pradenja klovnova prije nego li klovnovi slini George-u unite je u potpunosti.

Stigle su nove vijesti, mi moemo sprijeiti klaune kao to je George od unitavanja nae baze! SQL nam daje mogudnost da kontroliemo ta nai zaposlenici mogu a ta ne mogu raditi na bazi pradenja klovnova. Ali, prije nego to bilo ta uradimo, svim korisnicima nae baze moramo dati korisniki raun.

Zatiti root korisniki raun

Do sada smo imali samo jednog korisnika u bazi, bez ifre. Bilo ko ko ima dozvolu pristupu naem terminalu i grafikom interfejsu nae baze imao je apsolutnu kontrolu nad bazom. Po zadanom, prvi korisnik root korisnik ima apsolutnu kontrolu nad svim u naoj bazi. Ovo je vano, zato to root korisnik treba da omogudi kreiranje korisnikih rauna za sve ostale korisnike. Mi ne elimo ograniiti ta root korisnik moe uraditi, ali elimo naem root korisniku da dodijelimo ifru. U MySQL-u naredba je jednostavna:

Drugi SZURBP variraju, tako Oracle koristi naredbu:

Ako koristi grafiki interfejs na svojoj bazi, vjerovatno de nadi mnogo laki nain za mijenjanje ifre. Vana taka je da nije vano kako uraditi, ved da definitivno bi trebao uraditi.

Dodavanje novog korisnika

Evo jednog pitanja za vas sa oiglednim odgovorom: ta mislite, kako SQL pohranjuje informacije o svojim korisnicima ? U tabeli, naravno! SQL sauva bazu o sebi. Ona uva korisniki id, username, password i ta je svakom korisniku omogudeno da radi sa baze. Da bismo kreirali novog korisnika, moemo poeti sa username-om i password-om. Nema stvarne SQL naredbe da bismo kreirali korisnika, ali vedina SZURBP-ova bi koristila neto kao ovo:

Mogli bi smo, ali ponekad mi ne znamo tano koji pristup trebamo dodijeliti od samog poetka. Ali jo uvijek moramo odluiti tano emu de na korisnik pristupiti. Uradidemo sve postepeno, prvo demo kreirati korisnika a onda demo mu dodijeliti specifian pristup koji mu je potreban. A onda demo to spojiti prije nego to smo zavrili. Prednost je da znamo kako dodijeliti pristup nezavisno od kreiranja korisnika je da nam daje mogudnost da mijenjamo korisniki raun poslije kako se i naa baza mijenja.

Odlui tano ta korisnici trebaju

Napravili smo korisniki raun za Elsie. Kako sada stoje stvari, ona nema dozvole da uradi bilo ta sa baze. Moramo koristiti GRANT naredbu da bi joj dali dozvolu da ak SELECT-uje podatke iz tabele clown_info. Za razliku od naeg root rauna, koji ima dozvolu da radi sve SQL naredbe u bazi, to novi korisnici koje smo kreirali nemaju. GRANT naredba moe se koristiti da damo specifina prava korisnicima nae baze. Evo ta nam GRANT naredba omoguduje: