Enkripcija baza podataka

Izvor: SIS Wiki
Skoči na: orijentacija, traži

Sadržaj

Uvod

Danas ima mnoštvo raznovrsnih podataka koji se čuvaju i obrađuju na računalima ili se pak prenose komunikacijskim putevima te oni zahtjevaju efikasnu zaštitu. Razlog tome je činjenica kako uništenje podataka, njihovo neovlašteno modificiranje, dolazak u ruke neovlaštenim osobama ili organizacijama može često imati vrlo teške posljedice. Ovaj je problem posebno izražen kod nekih organizacija kao što su bankarske, pravosudne, vojne, medicinske i druge. Kako su tokom vremena računala, mreže, računalni resursi itd. postali dostupni širem krugu korisnika, proširila su se područja primjene, ali samim time su se otvorili mnogi problemi vezani za zaštitu. Pod time se zapravo misli kako je olakšan pristup podacima te je povećana mogućnost njihovog narušavanja. Na žalost, također postoji sve izraženiji interes da se narušavanjem ili krađom podataka pribavi sebi korist ili drugom pričini šteta. Kako bi se podaci zaštitili danas se koristi enkripcija. Enkripcija baze podataka odnosi se na korištenje tehnika enkripcije podataka u kriptiranu bazu podataka, kako bi ona bila nečitljiva onima koji ne posjeduju ključ.

Na tu je temu izrađena aplikacija. Svi članovi tima su sudjelovali u izradi aplikacije te je ona objavljena na GitHubu

Također, na temu enkripcije baza podataka izrađen je plakat na kojem je ukratko objašnjeno o čemu je zapravo riječ. Plakat je izradila Iva Horvat.

Plakat-iva.jpg

--Iva Horvat 16:26, 20. sječnja 2013. (NED)

Ključni koncepti

Baza podataka

Bazom podataka zovemo skup uređenih podataka na nekom mediju odnosno mogli bismo reći kako je to organizirana zbirka podataka. Jedna od mogućih definicija baze podataka glasi da je to skup međusobno ovisnih podataka, pohranjenih bez redudancije(poklapanja) koji služe jednoj ili više aplikacija na optimalan način, gdje su podaci neovisni o programima kojima se obrađuju i gdje postoji kontroliran pristup podacima (Martin, 1977.). Ako govorimo o digitalnom obliku zapisa podataka, baza podataka nema svrhu bez svog sustava za upravljanjem bazom podataka (SUBP). On omogućuje pohranjivanje, mijenjanje, čitanje i brisanje podataka, uz ostale funkcionalnosti ovisne o razini implementacije SUBP-a. U najširoj praksi, pa tako i ovdje, koristimo relacijski model podatka.

Ovisno o vrsti i namjeni podataka u bazi podataka, kao i načinima korištenja podataka, razlikujemo baze:

Baze podataka danas se zaista koriste u mnogim aplikacijam, a može se čak reći da se protežu na stvarno čitav opseg programske podrške. Baze podataka su poželjna metoda spremanja velikih multikorisničkih aplikacija gdje je potrebna koordinacija između mnogih korisnika.

--Iva Horvat 17:08, 20. sječnja 2013. (NED)

Enkripcija

Enkripcija je šifriranje podataka/poruka koja omogućava korištenje istih samo autoriziranim stranama. Enkripcija nam omogućava zaštitu podataka izmjenama samih informacija, tako da originalni sadržaj može vidjeti samo osoba koja posjeduje ključ za dekripciju. Na taj način osigurava se i sigurna razmjena informacija. Sustav za enkripciju treba podržavati mogućnost centraliziranog upravljanja korisnicima i ključevima i mogućnost jednostavnog dijeljenja ključeva. Suvremene mogućnosti komunikacije predstavljaju velik problem kad je u pitanju mogućnost neovlaštenog širenja povjerljivih informacija. Internet, mobilni uređaji, prenosivi uređaji za pohranu podataka koriste se u svakodnevnom poslovanju, pa tvrtke trebaju početi voditi računa o tome koje osjetljive podatke posjeduju, gdje se oni nalaze i tko im smije pristupiti, te kako spriječiti “curenje informacija”. Prva poznata metoda šifriranja datira iz vremena rimskog vojskovođe Julije Cezara, po kojem je i dobila ime, a sastoji se u jednostavnoj supstituciji latiničnih slova poruke pomicanjem za određeni broj mjesta u abecedi. U orginalnoj verziji, pomakom za tri mjesta unazad, šifra FDHVDU otkriva ime vlasnika Caesar.

Slika 1 Kako funkcionira enkripcija



U našem slučaju, mi kriptiramo sadržaj koji putuje prema spremniku baze, ili kriptiramo sadržaj koji je već u spremniku. Razine enkripcije baze podataka razlučiti ćemo u nastavku.

--Iva Horvat 17:31, 20. sječnja 2013. (NED)

Ključevi

Ključevi predstavljaju frazu koja određuje vrijednost funkcije nekog algoritma nad sadržajem. U kriptografskom smislu, ključ je metafora za mehanizam koji nam dopušta rukovanje osiguranim objektima. Najčešći oblici su simetrični i asimetrični ključevi:

Slika 2 Simetrični ključ


Slika 3 Asimetrični ključ



Metoda kriptiranja sa simetričnim ključevima je donedavno bila jedina poznata metoda. Prednost je u svakom slučaju njena jednostavnost i brzina. Za proces kriptiranja potrebno je znati algoritam kriptiranja i jedan tajni ključ koji dijele sve strane koje komunciraju. Razlika između simetričnih i asimetričnih algoritama je u tome što simetrični algoritmi koriste isti ključ za kriptiranje i dekriptiranje dok asimetrični algoritmi koriste različite ključeve za kriptiranje i dekriptiranje. Informacije kriptirane javnim ključem mogu se dekriptirati samo privatnim ključem odnosno to može samo osoba koja je vlasnik tajnog asimetričnog ključa. Ključ dekriptiranja ne može se izvestiiz ključa kriptiranja.

Slika 4 Primjer asimetričnog ključa


--Iva Horvat 17:48, 20. sječnja 2013. (NED)

Klijent-poslužitelj paradigma

U klijent-poslužiitelj paradigmi, poslužitelja smatramo sustavom koji posjeduje resurse, dok klijenta smatramo stranom koja pristupa i koristi resurse. Može se reći kako poslužitelj nudi uslugu koju traži klijent. U našim primjerima, poslužitelja smatramo bazom podataka, a korisnike baze klijentima. To je uobičajena paradigma mnogih “tradicionalnih” aplikacija, kao npr.Web browser i Web server.

Unatoč brojnim varijacijama klijent-poslužitelj interakcija najčešće ima sljedeće značajke.

Klijent:

S druge strane poslužitelj ima karakteristike:

Informacije mogu teći u oba smjera no komunikaciju uvijek inicira klijent.

--Iva Horvat 18:28, 20. sječnja 2013. (NED)

Algoritam

Algoritam je konačan slijed koraka koji se obavljaju uzastopno i daju izlaznu vrijednost(simplicirano).

Algoritmi imaju slijedeća svojstva:

Algoritam staje nakon konačno mnogo koraka, za svaku instancu problema kojeg rješava. Nije teško napisati niz naredbi koji bi se izvodio beskonaćno, ali takve programe ne smatramo opisima algoritama. Svaki korak od kojeg se sastoji algoritam je precizno i jednoznačno određen. U praksi možemo imati jednostavnije ili kompliciranije korake, no bitno je da ih čovjek ili stroj koji izvodi algoritam može izvršavati točno i bez dvosmislenosti.


--Iva Horvat 18:41, 20. sječnja 2013. (NED)

Sigurnost baza podataka

Sigurnost baze uključuje tri glavna svojstva:

Kako bi povjerljivost podataka bila očuvana, važno je definirati kontrolu pristupa (access control) na sustavu za kontrolu baze podataka (eng. database management system). Način provedbe kontrole pristupa ovisi o modelu podataka (npr. relacijski, XML), a načini na koje autorizacije mogu biti dodjeljene i upravljanje su Discretionary access control (DAC), Role Based Access Control (RBAC) ili Mandatory Access Control (MAC). Međutim, svaki od tih modela mogu se zaobići na nekoliko načina. Na primjer, napadač može infiltrirati sustav i pokušati doći do podataka tzv. footprintingom.

Neke baze podataka su ugrožene zbog činjenice da je njihovo čuvanje predano vanjskim uslugama odnosno Database Service Providerima (DSP). Tada vlasnici podataka daju svoje povjerenje tvrtci, a pokazalo se da zaposlenici tih tvrtki nisu uvijek profesionalni. Također administrator baze može zloporabiti ovlaštenja kako bi ugrozio ili špijunirao bazu podataka. Kako bi spriječili napadača, često se koriste kriptografske tehnike i princip prema kojemu bi on morao prelaziti više prepreka da bi ugrozio bazu. Smisao enkripcije je taj da iako napadač uspije proći kroz firewall i zaobići kontrolu pristupa, svejedno trebaju ključ da bi dekriptirali podatke. Za neke statične podatke, enkripcija je dobra zaštita, ali kod razvijanja strategije enkripcije dinamične baze podataka, moramo uzeti u obzir nekoliko faktora. Na primjer, gdje bismo trebali provesti enkripciju (storage layer, na samoj bazi ili odmah u aplikaciji). Koliko podataka bi podrazumijevalo adekvatnu sigurnost? Koji algoritam treba koristiti? Tko ima pristup ključevima? Kako ne usporiti rad baze zbog enkripcije?

--Iva Horvat 18:55, 20. sječnja 2013. (NED)

Razine enkripcije

Enkripcija na razini spremnika

Enkripcija na razini spremnika (Slika 1) podrazumijeva kriptiranje statičnih podataka u slučaju da napadač ukrade medij na kojem su podaci spremljeni. Dobro je koristiti ovu razinu enkripcije zbog transparentnosti tj. Ne dozvoljava promjene postojećih aplikacija. S druge pak strane ne mogu se implementirati korisničke privilegije (korištenje različitih ključeva za različite korisnike). Često se pribjegava selektivnom kriptiranju, odnosno kriptiranju samo određenih dijelova baze. To predstavlja problem jer je kriptiranje ograničeno na granularnost podataka, a također je riskanto jer se treba pobrinuti da ne postoji nekriptirana replika povjerljivih podataka negdje u bazi (npr. log files, temporary files itd).

Podaci u koje baza podataka skladišti podatke, su osnovna točka napada. Ovaj rizik je povećan, zbog toga što se podaci baza podataka neprestano repliciraju na položaje za oporavke od katastrofa i prave se rezervne kopije (eng. backup) na prenosive medije koji se kasnije mogu ostaviti bez nadzora. Bilo koji administrator sistema ili napadač koji ostvari pristup sistemu, može ukrasti podatke iz ovih datoteka. Jedan osnovni napad na datoteke baza podataka je otvoriti ih sa nekim editorom i potražiti potrebne informacije. Složeniji napad je korištenje alata da se pretraže binarni podaci i istraži datoteka te da se odredi njezina struktura i format.

Enkripcija na razini spremnika, štiti osjetljive podatke od svih napadača koji nemaju ključ za kriptiranje. Prednosti ove vrste enkripcije su: štiti podatke od napada sa razine operacijskog sustava i smanjuje rizik od fizičkih napada, relativno je jednostavna implementacija, kratko vrijeme primjene, lako se održava. Nedostatci su: ne može spriječiti napade na razini baze podataka kakvi su SQL injection i napadi DBA, podaci su u formi otvorenog teksta na razini između sustava za upravljanje bazama podataka i aplikacije, ne mogu se kriptirati pojedinačni dijelovi datoteka već samo cijela datoteka. Enkripcija na razini spremnika nema selektivnog pristupa – jednom kada se pristup ostvari svi podaci su izloženi osim ako nisu prethodno enkriptirani na razini aplikacije ili baze podataka.


--Nives Horvatić 17:19, 20. siječnja 2013. (NED)

Enkripcija na razini baze podataka

Enkripcija na razini baze podataka(Slika 1) omogućava dinamičnije kriptiranje podataka tj. kriptiranje podataka tokom ulaska i izlaska iz baze. Ova razina omogućava korisničke privilegije, a enkripcija ne ovisi o granuralnosti podataka. Ovisno o dizajnu i razini integracije enkripcije, ova enkripcija omogućava promjene na postojećim aplikacijama. Ovaj način enkripcije također ne dozvoljava korištenje indeksa na kriptiranim podacima. Za obje strategije vrijedi da se dekripcija odvija za vrijeme dok poslužitelj radi. To znači da ključ mora biti spremljen među kriptiranim podacima, što omogućava administratoru ili napadaču koji se predstavlja kao administrator mogu doći do ključa (npr. špijuniranjem memorije napadač može vidjeti ključ u plain textu).

Enkripcija na razini baze podataka omogućava da se osiguraju podaci dok se oni upisuju, odnosno čitaju iz baze podataka. Ostvaruje se pozivanjem funkcija, uskladištenih procedura (eng. stored procedure) i okidača (eng. trigger) baze podataka, koje obično razvija „treća strana“ (Protegrity, nCipher, Application Security, i dr.) ili se može ostvariti korištenjem enkripcijskih sposobnosti koje se nalaze u sistemima za upravljanje bazama podataka (SUBP) koje nude njihovi prodavači (Oracle, MS SQL Server 2005, i dr.). Zajedničko za prodavače „treće strane“ i „native“ prodavače SUBP je:

•Oba rješenja fokusiraju se na enkripciju i dekripciju na nivou baze podataka.

•Oba rješenja se oslanjaju na autentifikaciju i kontrolu pristupa SUBP da bi čuvali i povlačili kriptirane podatke (iako neki prodavači „treće strane“ nude dodatne sposobnosti autentifikacije i kontrole pristupa).

•Oba rješenja nude čuvanje ključeva u bazi podataka ili u nekoj datoteci, dok neki prodavači „treće strane“ nude sposobnost čuvanja ključeva na nekom hardverskom sigurnosnom modulu npr. HSM (eng. Hardware Security Modul).

•Ni jedno rješenje ne nudi enkripciju na razini sloga već samo na razini kolone ili cijele tabele.


Utjecaj enkripcije na performanse prikazan je na sljedećem primjeru:

Primjer: Tabela sadrži informacije o kupcima u sljedećim kolonama: IDKupca, ImeKupca, AdresaKupca i BrojKreditneKartice. Ona sadrži podatke od milijun kupaca, tj. ima milijun slogova. Nad tabelom se može izvršiti više načina enkripcije sa prednostima i posljedicama po performanse za svaku implementaciju, i to:

1)Enkripcija svih kolona u tabeli. Ako je potrebno izvršiti select nad kolonom IDKupca za određenu vrijednost IDKupca, onda će se morati izvršiti dešifriranje kolone IDKupca za svih milijun slogova(veliko opterećenje performanse). Kada se vrši insert u tabelu, opterećenje je minimalno, međutim ako se vrši update na koloni IDKupca, za određenu vrijednost IDKupca, potrebno je ponovo izvršiti dešifriranje za svaki pojedinačni slog.

2)Enkripcija tri kolone u tabeli. U ovom slučaju nije enkriptirana kolona IDKupca. Kada se vrši select nad kolonom IDKupca za određenu vrijednost IDKupca, ne zahtjeva se obavljanje dešifriranja sve dok se traženi slog ne poklopi sa odabranim kriterijem. Vrijeme koje je potrebno za obavljanje operacije select je minimalno, ali će dešifriranje pronađenog sloga doprinijeti relativno malom opterećenju performansi. Ukoliko se umjesto pretraživanja po koloni IDKupca odabere pretraživanje po koloni ImeKupca, onda će se morati obaviti dešifrovanje svih milion slogova za kolonu ImeKupca dok se ne pronađe odgovarajući slog, što će za posljedicu imati spor upit. Isto će se dogoditi i kod operacija update i delete. Ukoliko se odabere select nad kolonama IDKupca i ImeKupca, za odgovarajuću vrijednost IDKupca, pretraživanje će biti neznatno brže zato što će se dešifriranje izvršiti u koloni ImeKupca samo za slog koji odgovara traženoj vrijednosti IDKupca. Naravno, ukoliko se odabere prvo pretraživanje na osnovu vrijednosti ImeKupca prije IDKupca, rezultat će biti potpuno drugačiji, pošto će se prvo morati izvršiti dešifriranje podataka u koloni ImeKupca, a onda pronaći tražena vrijednost.

3)Enkripcija samo kolone BrojKreditneKartice. Mogućnosti da upit može značajno da uspori rad baze podataka smanjuju se ukoliko se kriptira samo broj kreditne kartice. Značajni udar na performanse će biti samo ako se odluči da se pretražuje po koloni BrojKreditneKartice. Ovo će se dogoditi samo ako se traži određeni broj kreditne kartice bez osiguravanja bilo kojeg drugog kriterija pretrage.

Enkripcija na razini baze podataka transparentna je u odnosu na aplikacijsku razinu, što znači da eliminira zahtjeve za izmjenu na razinu modela aplikacije i ukazuje na povećan trend ugradnje poslovne logike unutar sistema za upravljanje bazama podataka korištenjem uskladištenih procedura i okidača. Pošto se enkripcija/dekripcija događa unutar baze podataka, ovo rješenje ne zahtjeva poznavanje karakteristika aplikacija koje pristupaju kriptiranim podacima. Nedostatak ovog pristupa je da su podaci u formi otvorenog teksta između aplikacije i baze podataka te stoga uzrokuje opterećenje performansi. Prednosti ovog pristupa su: transparentnost u odnosu na aplikaciju, malo vrijeme primjene, podaci su kriptirani na disku ili mediju za backup podataka, a troškovi održavanja su minimalni.

--Nives Horvatić 17:19, 20. siječnja 2013. (NED)

Enkripcija na razini aplikacije

Enkripcija na razini aplikacije (Slika 1) premješta proces enkripcije i dekripcije u aplikaciju koja stvara podatke. Enkripcija se odvija u aplikaciji pa su ti podaci poslani i spremljeni kriptirani i primaju se nazad u aplikaciju gdje se dekriptiraju. Ova vrsta enkripcije ima prednost da ključevi nisu spremljeni s kriptiranim podacima, tj. Nikad ne napuštaju aplikaciju. Naravno, aplikacije se moraju prilagoditi ovom rješenju. S druge strane, ovisno o granularnosti enkripcije, aplikacija često mora dohvatiti više podataka nego što je dozvoljeno korisniku, što ostavlja prostor za napadača u bazu. Ovakva strategija zaštite onemogućava neke naprednije funkcionalnosti baze, kao ugrađene procedure ili triggere. Što se tiče granularnosti, aplikacijska razina je najfleksibilnija jer se može odabrati granularnost i ključevi ovisno o logici aplikacije. Enkripcija na razini aplikacije može zahtjevati ispravak postojećih aplikacija ako u njih nisu ugrađene enkripcijske/dekripcijske sposobnosti ili kupovinu aplikacija koje posjeduju sposobnosti enkripcije/dekripcije. Zahtjev ispravaka postojećih aplikacija je nepraktičan uslijed ograničenih IT resursa, nedostatka pristupa izvornom kodu ili nedostatka poznavanja starog koda. Prepravljanje aplikacija je također skupo, rizično i unosi faktor kašnjenja implementacije. Ako su podaci kriptirani na razini aplikacije, onda sve aplikacije koje pristupaju kriptiranim podacima moraju biti promijenjene da podrže model enkripcije/dekripcije. Znači da je tijekom faze planiranja primjene enkripcije, potrebno odrediti koje aplikacije imaju potrebu pristupa kriptiranim podacima, zatim je potrebno osigurati resurse da se modificira cjelokupni skup aplikacija od kojih se zahtjeva da pruže sposobnost enkripcije na razini aplikacije. Ako se uepješno primjeni, enkripcija na razini aplikacije štiti podatke od: napada na storage, krađe storage media i napada od zlonamjernih administratora baza podataka. Ovaj pristup je potpuno transparentan u odnosu na baze podataka, a to znači da nije potrebno ništa raditi na razini baze podataka osim osigurati da su veličine polja sposobne da prime šifriran podatak. No, ovaj pristup ima i nedostatke kao što je mogućnost korištenja tih podataka samo kroz aplikaciju, a to znači da se ne mogu koristiti SQL editori ili neki alati administratora baza podataka. Međutim, ovo može biti i prednost, pošto se sprječava npr. napad od strane zlonamjernih administratora. Nedostatak enkripcije na razini aplikacije također je, pošto se dekripcija obavlja na strani klijenta, to što hakeri koji kompromitiraju klijentske aplikacije imaju pristup dešifriranim podacima. Da bi se spriječio ovaj nedostatak potrebna je primjena snažne autentifikacije na aplikacijskoj razini.


Slika 1 – Tri različite razine enkripcije: a) na razini sloja spremnika, b) na razini baze, c) na razini razini aplikacije


--Nives Horvatić 17:19, 20. siječnja 2013. (NED)

Algoritmi kriptiranja i načini djelovanja

Neovisno o strategiji enkripcije, sigurnost podataka ovisi i o enkripcijskom algoritmu, veličini ključa i njegovom zaštitom. Čak i korištenjem naprednih algoritama kao AES, šifrirani tekst bi mogao pokazivati plain text informacije ako je odabran neprikladan način kriptiranja. Na primjer, ako je algoritam implementiran u electronic codebook mode (ECB), identični plain text blokovi su kriptirani u identične šifrirane blokove, otkrivajući ponavljajuće uzorke. U kontekstu baze, ponavljajući uzorci su česti jer mnogi podaci imaju istu vrijednost stupca, što znači da treba pažljivo odabrati način enkripcije. Posebno treba promotriti specifičnosti baze kako bismo odabrali prikladan algoritam i način djelovanja: ponavljajući uzorci, ažuriranja, velik volumen kriptiranih podataka. Također bi zaštita trebala biti dovoljno jaka jer neki podaci mogu biti važeći dulje vrijeme. Korištenje najboljih algoritama i načina djelovanja bi trebala biti praksa.

--Nives Horvatić 17:19, 20. siječnja 2013. (NED)

Sažetak

Kriptografski sažetak (engl. hash) je poput otiska prsta nekog podataka. Hash algoritam smanjuje vrlo velik podatak u malu jedinstvenu vrijednost. Iz sažetka je nemoguće izračunati original, nemoguće je pronaći poruku koja daje isti sažetak ko zadana poruka te je nemoguće pronaći dvije poruke koje daju isti sažetak. Hash u modernim kripto sustavima poboljšava učinkovitost digitalnih potpisa. Hash algoritam se još koristi za zaštitu lozinke, za točan uvid u stvaranje i modifikacije poruke, te jamči integritet podataka. Poznati hash algoritmi su SHA- 256, SHA-384, i SHA-512. Stariji SHA-1 i MD5 algoritmi su trenutačno u široj upotrebi, ali kod oba algoritma uočene su greške te bi trebali biti povučeni iz upotrebe. Nama je najzanimljivije korištenje sažetka za zaštitu lozinki.

--Violeta Jalšić 17:54, 20. sječnja 2013. (NED)

Sažetak lozinki u MySQL-u

MySQL je razvila Oracle Corporation te je jedan od najpoznatijih DBMS-a. Koristi se na svakom kontinentu – čak i na Antarktici. Koriste ga pojedinci, programeri te poznate kompanije kao što su Yahoo!, Alcatel-Lucent, Google, Nokia i YouTube. Njegove najveće prednosti su visoke performanse, brzina, pouzdanost i jednostavnost korištenja. U tablici user baze podataka mysql su pohranjeni svi korisnički računi s kojih se može spojiti na bazu podataka. Kada se korisnik prijavi u sustav, njegov identitet određuje „host“ s kojeg se spojio, te njegovo korisničko ime. MySQL upotrebljava oba podatka jer se smatra da ne postoji razlog da se pretpostavi da jedno korisničko ime pripada jednoj osobi na svim „hostovima“. Sintaksa za korisničke račune je 'korisnicko_ime'@'ime_hosta'. Ako se korisnički račun nekog korisnika sastoji samo od korisničkog imena, sintaksa je 'korisnicko_ime'@'%'. Postoje i korisnički računi kod kojih je korisničko ime prazno. Oni predstavljaju anonimnog korisnika, a za njegovo specificiranje koristi se @'ime_hosta'.

U početnim postavkama je administratorova lozinka prazna:
mysql> SELECT User, Host, Password FROM mysql.user;
MySQL tablica1.png

Ako bi takva i ostala, neovlašteni korisnici bi lako mogli dobiti pristup njegovom korisničkom računu. Zbog toga je jedan od najvažnijih koraka u osiguravanju sigurnosti MySQL-a postavljanje administratorove lozinke. Iz prvih riječi rečenice Svaka 4-a godina je prestupna i ima 366 dana.može se dobiti lozinka s4gji3d koju je vrlo teško pogoditi ćemo u tu lozinku promijeniti administratorovu lozinku. Vidljivo je da administrator vezu može uspostaviti tako da kao „host' upiše localhost, IP adresu 127.0.0.1 ili IPv6 adresu ::1. Za MySQL korisnički računi 'root'@'localhost' i 'root'@'127.0.0.1' nisu jednaki, te im je moguće dodjeliti različite lozinke i privilegije što često zbunjuje korisnike i rezultira neuspješnim prijavama.

Kako bi se to spriječilo, potrebno je dodijeliti lozinku svakom korisničkom računu administratora koji je naveden u tablici user:
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('s4gji3d');
mysql> SET PASSWORD FOR 'root'@'127.0.0.1' = PASSWORD('s4gji3d');
mysql> SET PASSWORD FOR 'root'@'::1' = PASSWORD('s4gji3d');

Moguće je provjeriti kako sada izgleda tablica s korisničkim računima:
mysql> SELECT User, Host, Password FROM mysql.user;
MySQL tablica2.png


Vidljivo je da lozinka nije zapisana u čitljivom obliku, već kao „hash“ vrijednost izračunata iz nje. Funkcija za izračunavanje „hash“ vrijednosti je PASSWORD(). MySQL koristi lozinke u dvije faze kod klijentsko-serverske komunikacije:

U MySQL-u je mehanizam za kriptiranje lozinke ažuriran u verziji MySQL 4.1. Verzije prije MySQL 4.1 „hash“ vrijednosti lozinke su bile duge 16 bajta, dok su danas duge 41 bajt. Novija verzija kriptiranja pruža bolju zaštitu lozinkama te je sigurna čak i ako se TCP/IP paketi prisluškuju ili ako je mysql baza podataka zarobljena.

Primjer starije verzije je:
mysql> SELECT PASSWORD('mypass');
MySQL tablica3.png

Primjer novije verzije je:
mysql> SELECT PASSWORD('mypass');
MySQL tablica4.png

Razlika između verzija je očita. Novija verzija lozinki je duža te uvijek počinje sa znakom „*“.
Ako se želi promijeniti neka lozinka koristeći noviju verziju, može se koristiti:
SET PASSWORD FOR 'korisnik'@'host' = PASSWORD('mypass');

A ako se želi promijeniti lozinka, ali da se kreira starija i kraća verzija:
SET PASSWORD FOR 'korisnik'@'host' = OLD_PASSWORD('mypass');

Ne smije se zaboraviti koristiti funkcija za kriptiranje kod promjene lozinke koristeći SET PASSWORD, INSERT, ili UPDATE. Primjerice, sljedeći kod dodjeljuje lozinku, ali pošto ju ne kriptira, korisnik se kasnije neće moći spojiti:
SET PASSWORD FOR 'korisnik'@'host' = 'mypass';

Kod upotrebe CREATE USER ili GRANT nije potrebno koristiti ove funkcije jer one automatski koriste funkciju PASSWORD() za kriptiranje.

--Violeta Jalšić 17:34, 20. sječnja 2013. (NED)


Upravljanje ključevima

Upravljanje ključevima se odnosi na način kako su kriptografski ključevi generirani i upravljani kroz svoj život. Zbog toga što je kriptografija bazirana na ključevima koji kriptiraju podatke, baza je sigurna koliko je siguran ključ koji ih kriptira. To pokazuje važnost lokacije pohrane ključa i ograničavanje pristupa ključevima. Za enkripciju na razini baze, jednostavno rješenje je spremanje ključa u tablicu ili datoteku s ograničenim pristupom, koji su kriptirani master key - em. S druge strane, svi korisnici s administratorskim pristupom imaju pristup tim ključevima i podacima, bez da budu otkriveni. Kako bi riješili taj problem, koristi se hardware security module (HSM) za spremanje ključeva. Drugo rješenje je premještanje sigurnosnih zadataka na neki drugi software pokrenut na (fizički) drugom serveru, tzv. security server.

--Violeta Jalšić 13:27, 20. sječnja 2013. (NED)

Hardware security module(HSM)

HSM je vrsta kriptoprocesora. Kriptoprocesor je sklopovlje namijenjeno obavljanju 'ugrađenih' kriptografskih operacija nad sadržajem koji koristi. Namijenjen je ubrzavanjem nekih kriptoprocesa, ali poglavito za sigurnost važnih ključeva/master keya kojim se dolazi do ostalih ključeva. Najčešće dolaze u obliku plug-in kartica ili eksternih TCP/IP sigurnosnih uređaja, a koriste asimetrične ključeve. Važna osobina je tamper protection (zaštite od neovlaštenog/nepredviđenog korištenja), koja je jedna od ciljeva HSM-a uopće. Razlikujemo HSM sa klijentske strane i sa strane poslužitelja:

Slika 2 – Hsm na a) poslužiteljskoj strani, i b) klijentskoj


Za razliku od Slike 1, na Slici 2.a vidimo HSM kao dio poslužitelja zadužen za kriptiranje sadržaja koji DBMS engine prosljeđuje sloju spremnika, dok na Slici 2.b HSM djeluje kao „filter“ sadržaja koji aplikacija prosljeđuje poslužitelju, tj. DBM sustavu koji će se pobrinuti za pospremanje sadržaja. HSM na strani poslužitelja nudi iste prednosti kao enkripcija na razini poslužitelja, sa prednosti zaštite ključeva, jer HSM ima spomenuti tamper protection. HSM na strani klijenta je posvećen samo jednom korisniku, te predstavlja slanje kriptiranog sadržaja bazi koja mora rukovati tim sadržajem.

--Violeta Jalšić 13:27, 20. sječnja 2013. (NED)  

Security server

Dok svi postojeći komercijalni proizvodi koriste klasične algoritme za kriptiranje, neke nove, specifične sheme su se počele pojavljivati, posebno u bazi podataka kao usluga paradigmi. U ovom obliku zaštite, provideri servisa baza podataka nude svojim korisnicima mehanizme za izradu, pohranu i pristup svojim bazama na njihovim hostovima. U ovom obliku zaštite, poslužitelj baze podataka može upravljati kriptiranim podacima bez pristupa enkripcijskom ključu (slično kao zaštita na razini aplikacije).

Rješenje zaštite sadržaja preko udaljenog poslužitelja:

Slika 3 – Sigurnosni poslužitelj


U ovom slučaju postoji sigurnosni modul koji je u komunikaciji sa poslužiteljem. Sigurnosni poslužitelj upravlja korisnicima, dopuštenjima i ključevima enkripcije, koju DBMS obavlja. Prednost je što je potrebna suradnja između administratora oba poslužitelja da bi se povjerljivost podataka ugrozila. Komunikacija dvaju poslužitelja je dodatno osigurana sigurnosnim protokolima(SSL, Ipsec, SHTTP...) Korištenjem security servera i HSM-a povećava sigurnost baze, ali ju ne zaštićuje u potpunosti. Enkripcijski ključevi kao i podaci svejedno se pojavljuju na memoriji baze i mogu biti meta napadača.

--Violeta Jalšić 13:27, 20. sječnja 2013. (NED)

Primjena i budućnost

Većina proizvođača DBMS-a ugrađuje enkripcijske tehnike koje omogućavaju developerima aplikacija da uključe dodatne mjere sigurnosti selektivnom enkripcijom. Neka rješenja native enkripcije:

• enkripcijski paketi (Oracle8i/9i)

• funkcije koje mogu biti ugrađene u SQL naredbe (IBM DB2)

• ekstenzije SQL-a (Sybase, SQL Server 2005)

Enkripcija se može obaviti na razini stupca, ali može uključiti mijenjanje sheme baze da bi se prilagodila binarnim podacima koju su rezultat procesa enkripcije.

--Jelena Hajdinjak 16:26, 20. sječnja 2013. (NED)

Transparent data encryption

Ovaj oblik zaštite sličan je zaštiti na razini spremnika. Podaci su kriptirani real-time tj. neposredno po spremanju podataka. Cijela baza je kriptirana pomoću Database encryption keya (DEK) koji je osiguran drugim načinima, moguće HSM-om ili pomoću Walleta kod Oraclea 10g/11g. TDE zato omogućuje lakšu nadogradnju sigurnosti jer kriptira cijelu bazu i nije potrebno mijenjati postojeće tipve podataka, sheme, procedure i redoslijed postojećih procesa.

--Jelena Hajdinjak 16:26, 20. sječnja 2013. (NED)

IBM Database encryption expert in DB2

IBM-ovo rješenje je udaljeni sigurnosni poslužitelj i DB2 „Agent“ na poslužitelju sa bazom:

DB2.png

Sigurnosni poslužitelj djeluje kao središte administriranja ključeva, police sigurnosti podataka i dnevnika transakcija, a Agent služi kao dodatni sigurnosni sloj kriptiranja sadržaja.

--Jelena Hajdinjak 16:26, 20. sječnja 2013. (NED)

Rješenje RSA grupe

RSA.png

SecureID tokeni su tehnologija autentikacije kao i tokeni koje koristimo za internet bankarstvo.Rješenje ima dvije vrste udaljena sigurnosna poslužitelja: jedan za autentiakciju, drugi za enkripciju sadržaja. BSAFE omogućuje developerima biranje vrste algoritama enkripcije, a Keon služi kao dnevnik transakcija i „očvršćivanje“ zaštite.

--Jelena Hajdinjak 16:26, 20. sječnja 2013. (NED)

Oracle

Oracle Database popularni je sustav za upravljanje relacijskim bazama podataka, oblikovan na način da podržava raspodijeljeni rad (engl. grid computing). Sigurnosni podaci koji su primijećeni kod Oracle sustava za upravljanje bazom podataka odnose se na potencijalno prepisivanje spremnika enkripcijom određenih PL/SQL procedura, DoS ranjivost TNS Listener modula, mogućnost ubacivanja proizvoljnih PL/SQL naredbi te mogućnost stjecanja viših korisničkih ovlasti uzrokovanu propustom implementacije tzv. okidaca (engl. trigger).

Prvi se otkriveni nedostatak odnosi na mogućnost enkripcije programskog koda određenih PL/SQL naredbi, čime je moguće izazvati prepisivanje spremnika te na taj način doći do mogućnosti izvođenja proizvoljnog programskog koda u sigurnosnom okviru "Oracle" korisnika.

Drugi se nedostatak odnosi na mogućnost stjecanja povećanih korisničkih ovlasti ubacivanjem određenih PL/SQL naredbi. Prilikom izvođenja PL/SQL procedure, sigurnosne su ovlasti predefinirane osim u slučaju korištenja AUTHID CURRENT USER ključne riječi. U slučaju da se koriste predefinirane sigurnosne ovlasti, napadaču se otvara mogućnost iskorištavanja navedenog nedostatka, što je uočeno kod sljedećih procedura:

Vlasnik Procedura

SYS DBMS_EXPORT_EXTENSION

WKSYS WK_ACL.GET_ACL

WKSYS WK_ACL.STORE_ACL

WKSYS WK_ADM.COMPLETE_ACL_SNAPSHOT

WKSYS WK_ACL.DELETE_ACLS_WITH_STATEMENT

CTXSYS DRILOAD.VALIDATE_STMT


Treći se otkriveni nedostatak odnosi na mogućnost stjecanja povećanih korisničkih ovlasti iskorištavanjem propusta u implementaciji tzv. okidača (engl. trigger). Okidači su namijenjeni očuvanju integriteta baze podataka tako da prilikom modificiranja tablica poduzimaju određene akcije.

Sva tri navedena nedostatka primjećena su kod Oracle sustava inačica 10g i 9i.

Posljednji se nedostatak odnosi na DoS ranjivost TNS Listener modula, koju je moguće iskoristiti slanjem malformiranog service_register_NSGR zahtjeva. Budući da se 182. oktet zahtjeva koristi za određivanje pomaka (engl. offset) pokazivača, slanjem zahtjeva koji umjesto uobičajene vrijednosti 5 sadrži neku drugu vrijednost (primjerice 0xCC), napadač izaziva pristup proizvoljnim dijelovima memorije te na taj način uzrokuje rušenje modula. Navedeni nedostatak primjećen je isključivo kod Oracle sustava inačice 10g.

Oracle je objavio sigurnosnu zakrpu #68 koja u potpunosti uklanja navedene nedostatke.

--Jelena Hajdinjak 16:26, 20. sječnja 2013. (NED)


Privacy homomorphic encryption (PH)

PH enkripcija je oblik enkripcije koja dozvoljava specifični tip operacija koje se izvode nad kriptiranim sadržajem, a rezultat nakon dekripcije je izvorni tekst sa istim obavljenim operacijama koje su izvedene nad kriptiranim sadržajem. Ovaj oblik enkripcije je nesiguran jer je moguće transformirati šifrirani tekst u drugi šifrirani tekst koji se dekriptira u plaintext, odnosno ako je zadana enkripcija m, moguće je generirati drugi šifrirani tekst koji se dekriptira u f(m) za poznatu funkciju f, bez poznavanja enkripcije m. Primjer Imamo tekst koji želimo zaštititi „broj korisnika 000034“ i napravimo enkripciju koja nam daje „adkemfkejtigkej382751“. Sada možemo uvećati broj u kriptiranom sadržaju za 10, gdje ćemo dobiti „adkemfkejtigkej382761“. Ako nakon dekripcije ovog modificiranog sadržaja broj bude „broj korisnika 000044“, znamo da se radi o homomorfnoj enkripciji.

--Jelena Hajdinjak 16:26, 20. sječnja 2013. (NED)

Ostali mogući problemi

Kriptiranje podataka garantira povjerljivost podataka, ali ne osigurava njihov integritet. Podaci mogu biti modificirani ili izmijenjeni. Ako je poslužitelj baze napadnut, potrebno je provjeriti točnost i cjelovitost rezultata upita. Kriptografske tehnike i kriptografske hash funkcije su važan dio za gradnju testova integriteta baze. Korištenje postojećih tehnika kriptiranja povećava veličinu baze podataka i usporava njen rad. Ugroženost baze podataka dolazi i od socijalnog inžinjeringa koji potencijalno zaobilazi veliku većinu sigurnosnih prepreka/zaštita koji se ne mogu tehnološki spriječiti

--Jelena Hajdinjak 16:26, 20. sječnja 2013. (NED)

Praktični dio

Svi članovi tima su sudjelovali u izradi aplikacije te je ona objavljena na GitHubu. Aplikacija je zamišljena kao što je prikazano na sljedećoj slici.

Dijagram aplikacije enkripcija BP.png

Potrebno je kreirati tri foldera: SecureServer, SUBP i Tablespace001. SecureServer glumi udaljenog posluzitelja koji drži podatke za autentikaciju (tamo sadržaj nije kriptiran). Unutar njega je potrebno kreirati datoteku "korisnici.txt" unutar koje se nalaze korisnička imena i lozinke svih korisnika. Unutar SUBP se nalazi kod naše aplikacije. Tablespace001 je naziv za rezervirano područje na nekom disku(baza podataka).

--Violeta Jalšić 15:54, 20. sječnja 2013. (NED)

Kod aplikacije

Kod se sastoji od nekoliko funkcija te funkcije main iz koje se one pozivaju. U nastavku će svaka funkcija biti ukratko opisana.

Funkcija enkripcija služi za enkripciju. A enkripciju predstavlja Cezarova šifra s pomakom 1.

Enkripcija cezarova sifra.png






Funkcija dekripcija služi za dekripciju te se dekriptira Cezarovom šifrom s pomakom 1.

Dekripcija cezarova sifra.png





Funkcija autentifikacija pretražuje datoteku "korisnici.txt" te ispituje postoji li korisnik s unešenim korisničkim imenom i lozinkom. Ukoliko postoji vraća 1, inače vraća 0.

Autentifikacija enkripcija BP.png















































Funkcija lok_kor pokazuje na lokacija korisničkog sadržaja u spremniku. Funkcija vraća 0 kada nema korisničkog sadržaja u spremniku. Inače vraća pokazivač na mjesto gdje počinje tekst korisnika.

Lokacija korisnickog sadrzaja.png









































Funkcija duljina nam govori duljinu cijelog spremnika. EOF (END OF FILE) označava kraj datoteke.

Duljina spremnika.png














Funkcija citanje čita sa spremnika sadržaj logiranog korisnika.

Citanje iz spremnika.png















Funkcija unos služi za unos sadržaja na mjesto koje posjeduje logirani korisnik u spremniku.

Unos u spremnik.png








































Na kraju se nalazi main unutar kojeg se nalazi izbornik te se pozivaju funkcije.

Main enkripcija BP.png













































--Violeta Jalšić 13:56, 20. sječnja 2013. (NED)

Izgled aplikacije

Kod pokretanja aplikacije unosimo korisnika i njegovu lozinku.

Korisnici i njihove lozinke su redom:

iva - loz1

violeta - loz2

jelena - loz3

nives - loz4


Unos korisnika i lozinke


Kod nepostojećih korisnika javlja se poruka o greški (korisnici nisu spremljeni u bazi, stoga se ne mogu prijaviti)


Poruka o nepostojećem korisniku


Nakon uspješnog logiranja imamo tri opcije:

1. Čitanje teksta

2. Unos teksta

3. Izlaz


Odabiremo unos teksta koji se nakon unošenja sprema u datoteku spremnik.txt (enkripcija u spremnik je cezarova šifra +1) Unosimo neki tekst; npr. "programiranje" i on se sprema u spremnik.txt (kasnije dok otvorimo spremnik.txt zbog enkripcije napisano je "qsphsbnjsbokf")


Unos teksta



Kod čitanja teksta ispisuje se ono što je uneseno u spremnik.txt (dekripcija prema ekranu,tj. ispisu je cezarova šifra -1)


Čitanje teksta


--Nives Horvatić 20:04, 20. siječnja 2013. (NED)

Literatura

Svi dostupni u prosinac 2012. i siječanj 2013.

Dobavljeno iz "https://security.foi.hr/wiki/index.php/Enkripcija_baza_podataka"
Osobni alati
Imenski prostori
Inačice
Radnje
Orijentacija
Traka s alatima