Autentifikacija, autorizacija i bilježenje

Izvor: SIS Wiki

Skoči na: orijentacija, traži

Uvod

U poslovnom okruženju 21. stoljeća, podrška poslovnih sustava informatičkom tehnologijom postala je neizostavna nota tržišne konkurentnosti. Budući da se uvođenjem IS-a u poduzeće svaki poslovni događaj bilježi u nekakvom spremištu podataka (najčešće je riječ o bazi podataka), podaci koji opisuju aktivnosti promatranog subjekta imaju realnu (stvarnu) vrijednost te ih je nužno zaštiti od neovlaštenog pristupa.

Definiranje sigurnosne politike u okviru izgradnje IS-a prema važećim standardima i normama nemoguće je bez slojevite zaštite podataka na nekoliko razina, a tu svakako spada ograničavanje pristupa određenim sadržajima prilikom same prijave u informacijski sustav (programska razine zaštite). Pravo pristupa prvenstveno zavisi o stupnju organizacijske odgovornosti korisnika sustava - u tom kontekstu pojavljuju se tri neizostavna procesa utvrđivanja digitalnog identita onoga koji će djelovati u sustavskom okruženju: autentifikacija, autorizacija i bilježenje aktivnosti.

Prije nego li se može uopće detaljnije govoriti o spomenutim procesima, treba razumijeti pojam digitalnog identiteta. Kao u realnom sustavu gdje primjerice policijski službenik uz pomoć osobne iskaznice može utvrdititi identitet pojedinca u okviru strukture kao što je država, tako i administrator (onaj koji upravlja resursima informacijskog sustava) mora biti sposoban prepoznati korisnika da bi mu mogao dodijeliti određena, organizacijskom strukturom definirana prava.

Utvrđivanje identiteta može se provesti na nekoliko načina. Ono se obično definira u okviru sigurnosne politike poduzeća, ovisno o uvjetima u kojima se posluje. Tu dolazimo do pojma autentifikacije gdje korisnik pokušava dokaziti sustavu tko je on zapravo. Potvrdu identiteta korisnika moguće je realizirati na temelju onoga što pojedina osoba zna (osobni faktor), onoga što posjeduje (tehnički faktor) i onoga što osoba jest (ljudski faktor). Budući da su statične lozinke danas izuzetno ranjive, u sustavima koji zahtjevaju višu razinu sigurnosti, obično se primjenjuje dvofaktorska, a ponekad i trofaktorska zaštita. Banke recimo često primjenjuju dvofaktorsku zaštitu, i to kroz formu jednokratnih lozinki. Nakon što korisnik prođe proces autentifikacije, slijedi postupak autorizacije, tj. dodjeljivanje sigurnosnom politikom definiranih prava pojedinom tipu korisnika.

U konačnici, sukladno iso normama i drugim standardima, aktivnost korisnika je nužno pratiti, tj. bilježiti kako bi se u slučaju incidentne situacije mogla utvrditi organizacijska odgovornost, a potom i pravna. I u tom segmentu postoji više načina kako to izvesti što znači kako projektant informacijskog sustava ima relativno širok raspon opcija s kojima će povezati spomenute procese i definirati korisnika sustava..

--Ante Malenica 21:47, 10. lipnja 2013. (CEST)

Autentifikacija

Autentifikacijske metode

Proces autentifikacije najjednostavnije je opisati na sljedeći način - utvrđivanje korisničkog identiteta. Iako se odgovarajuća zaštita podataka može realizirati već na fizičkoj razini (ograničavanje pristupa prostoru gdje se nalaze računala s osjetljivim sadržajem), autentifikacija je ipak danas neizostavni proces pri korištenju sustavskih resursa, posebice u segmentu distribuiranih informacijskih sustava ili pri korištenju web aplikacija (elektronička pošta, virtualne trgovine, uredske aplikacije i sl.).

Kao što je već navedeno na početku, postoji nekoliko tipova autentifikacije, ovisno o kombinaciji faktora koji se koriste. Dok je jednofaktorska autentifikacija najčešće u domeni unošenja podataka koje korisnik pamti (korisničko ime i lozinka), dvofaktorski i trofaktorski sustavi kombiniraju tehnički (npr. token za generiranje jednokratnih lozinkI) i ljudski element (utvrđivanje bioloških značajka osobe putem biometrijskih uređaja), kako bi se realizirali sigurniji autentifikacijski sustavi.

Izuzev visoke razine sigurnosti, važno je realizirati i druge zahtjeve poput primjerice financijske isplativosti. Primjerice, biometrijsku provjeru nema smisla uvoditi za pristup podacima kao što je elektronička pošta - riječ je o tehnički kompleksnom i financijski izuzetno skupom sustavu s kojim se obično nastoje zaštiti strogo povjerljivi i materijalno iznimno vrijedni podaci. S druge strane, u današnjim distribuiranim informacijskim sustavima korisnici često su prisiljeni za različite dijelove sustava pamtiti podatke o višestrukim korisničkim računima pa tu primjerice kao veoma praktično rješenje pokazala se prijava na jednom mjestu (eng. Single Sign-On). No prije nego li se detaljnije pozabavimo tim sustavom, pogledajmo neke standarne metode autentifikacije korisnika one programske razine zaštite podataka.

Izvor informacija: [32]

--Ante Malenica 21:52, 10. lipnja 2013. (CEST)

Lozinke

Najčešći način utvrđivanja identiteta korisnika danas je korištenje korisničkog imena i pripadajuće lozinke koji se definiraju prilikom registracije na sustav ili se dobiju jednokratno od administratora. Identifikator, tj. korisničko ime najčešće je nekakva fraza ili inicijal koji ima nekakvo značenje samom korisniku.

Statična lozinka, nasumični niz alfanumerika i specijalnih znakova, najčešće se sprema u kriptiranom obliku kako bi se zaštitila komunikacija između klijenta i servera. Unatoč tome, lozinke imaju svoje slabosti - one “slabe strukture” (jednostavne za pogoditi) mogu se probiti “brute force” pristupom, dok korisnici često rade grešku da ih ostave zapisane na vidljivim mjestima ili ih se zbog neznanja i nepažnje domognu zlonamjerne osobe putem prisluškivanja komunikacijskog kanala (uz pomoć malicioznog koda).

Izuzev već spomenutog problema lake provaljivosti, lozinke koje se temelje na osobnim informacijama imaju nekoliko problema:

1. Ograničen broj informacija;
2. Većinu osobnih informacija nije moguće mijenjati;
3. Ako je osobne informacije moguće mijenjati, svaku je promjenu potrebno zapamtiti;
4. Vrijednost osobnih informacija kao autentifikacijskog faktora opada s obzirom na broj organizacija koje ih posjeduju;
5. Napadač može lako otkriti osobne informacije jednostavnim istraživanjem ili korištenjem napada pogađanjem pojmova.

Budući da lozinke kao jednofaktorski model autentifikacije često nisu dovoljno siguran način za utvrđivanje identiteta korisnika sustava, često se primjenjuju dvofaktorske metode koje kombiniraju osobni i tehnički ili ljudski faktor. Primjer takvog oblika utvrđivanja identiteta korisnika su jednokratne lozinke.

Izvor informacija: [33] [34]

--Ante Malenica 22:02, 10. lipnja 2013. (CEST)

Jednokratne lozinke

U domeni dvofaktorske autentifikacije, jednokratne lozinke za razliku od statičnih su drugačije prilikom svake prijave u sustav. Osnovna ideja je pružiti dodatnu razinu zaštite jer ako napadač uspije doći do lozinke korisnika sustava, ona će biti neupotrebljiva budući da se nasumični niz znakova može iskoristiti prilikom samo jedne prijave. Jednokratne lozinke dakle pružaju zaštitu od phishing i pharming napada te štete koja se može desiti otkrivanjem povjerljivih informacija koje posjeduje pojedini korisnik sustava. Riječ je o obliku “jake autentifikacije” koja se najčešće koristi za zaštitu bankovnih transakcija, u mrežnim sustavima vojske i policije, odnosno za zaštitu strogo povjerljivih informacija.

Postoji nekoliko metoda generiranja jednokratnih lozinka:

1. Matematički algoritmi
2. Vremenska sinkronizacija
3. Transakcijski autentifikacijski brojevi
4. Jednokratne lozinke primljene putem SMS-a
5. “Challenge-based” generiranje

Matematički algoritmi

Služe za generiranje jednokratnih lozinki iz korisničke statične lozinke. Koriste se hash funkcije koje onemogućuju dobivanje izvorne (statičke) lozinke iz one jednokratne, odnosno napadač nije u mogućnosti obrnutim postupkom doći do statičkog niza znakova na temelju kojeg bi sam mogao generirati nove jednokratne lozinke. Raspršna (hash) funkcija je ona koja na temelju unesenih vrijednosti generira niz znakova točno određene duljine, tj. “raspršnu vrijednost”. Promjene bilo kakvog karaktera u unesenim podacima također mijenjaju raspršnu vrijednost. Vrijednosti koje se šifiriraju nazivaju se porukama, a raspršne vrijednosti rezultatima poruke.

Slika 1: Način funkcioniranja kriptografske raspršne funkcije [1]

Vremenska sinkronizacija

Obično se veže za uređaje poput tokena (tehnički faktor) koji služe za generiranje jednokratnih lozinki. U sklopu uređaja nalazi se poseban vremenski sklop koji kroz sikronizaciju s glavnim poslužiteljem generira jednokratnu lozinku na temelju vremena. Za razliku od drugih sustava, kod vremenske sinkronizacije često nije potrebna korisnička statička lozinka. U svrhu vremenske sinkronizacije moguće je koristiti i smartphone uređaje.

Slika 2: Generiranje jednokratnih lozinki tehnikom vremenske sikronizacije [2]

Transakcijski autentifikacijski brojevi

Riječ je o brojevima koji se također opisuju pojmom jednokratnih lozinki. Izdaje ih banka u svrhu realizacije financijskih transakcija, a njihovo izdavanje ostvaruje se na sljedeći način:

1. Banka generira određeni broj transakcijskih autentifikacijskih brojeva za pojedinog korisnika. Najčešće korisnik ima dovoljno transakcijskih autentifikacijskih brojeva za vremenski period od šest mjeseci do godine dana.

2. Korisnik pri preuzimanju liste lozinki u banci mora dokazati svoj identitet nekim osobnim dokumentom.

3. Korisnik od banke prima također i korisničko ime i statističku lozinku koju koristi za prijavu na traženu uslugu.

4. Kako bi koristio uslugu, korisnik se mora prijaviti putem preglednika i upisati dobiveno korisničko ime i statičku lozinku. Napadač mora saznati korisničko ime i lozinku, ali neće moći nanijeti štetu jer je za obavljanje financijskih transakcija potreban transakcijski autentifikacijski broj s liste koju je izdala banka.

5. Da bi korisnik izvršio transakciju, potrebno je upisati transakcijski autentifikacijski kod. Poslužitelj potom provjerava da li se taj broj nalazi na listi pridijeljenom tom korisniku i da li je taj broj već korišten. Ako se broj ne nalazi na listi ili ako je već korišten za neku prethodnu transakciju, poslužitelj neće izvršiti traženu akciju. (npr. isplatu novčanih sredstava).

6. Ukoliko je transakcija uspješno provedena, uneseni transakcijski autentifikacijski broj je izbrisan s korisnikove liste na poslužitelju i nije ga moguće više koristiti.

7. Ako je u pitanje dovedena sigurnost liste transakcijskih autentifikacijskih brojeva, korisnik može prijaviti banci da poništi staru listu i izda novu s novim transakcijskim autentifikacijskim brojevima.

Jednokratne lozinke primljene putem SMS-a

Postoje sustavi u koje se korisnik može prijaviti putem jednokratnih lozinki koje se šalju na mobilni uređaj. Riječ je danas o sve raširenijoj metodi prijave budući da je ona iznimno jednostavna za krajnjeg korisnika - izuzev podržanog mobilnog uređaja, sve što korisnik usluge najčešće treba je nekakav klijentski software. U tom softwareu najčešće leži i mana cijele te ideje - većina aplikacija za ovaj način generiranja jednokratnih lozinki bazira se na programskom jeziku Java čime je napadaču omogućeno iskorištavanje sigurnosnih propusta u samim aplikacijama.

“Challenge-based” generiranje jednokratnih lozinki

Kod ovog tipa generiranja jednokratnih lozinki upotrebljava se numerička vrijednost (challenge, tj. upit) koju korisnik dobiva od poslužitelja kako bi pomoću uređaja (najčešće tokena) ili programa generirao jednokratnu lozinku. Riječ je o tehnici generiranja koja se zasniva na vremenskoj sikronizaciji.

Challenge-based autentifikacija ima sljedeći tijek zbivanja:

1. Korisnik šalje poslužitelju zahtjev za prijavu
2. Na temelju poslanog zahtjeva za prijavu, poslužitelj šalje korisniku upit (eng. challenge)
3. Korisnik upit mora unijeti u token kako bi uređaj prikazao odgovor na upit (eng. response)
4. Korisnik očitava odgovor na uput prikazan na ekranu tokena
5. Korisnik unosi odgovor na upit u sučelje za autentifikaciju kako bi mu poslužitelj odobrio pristup
6. Poslužitelj također generira odgovor na upit. Ako su oba odgovora na upit (onaj na zaslonu tokena i na poslužitelju) jednaka, poslužitelj odobrava pristup korisniku.

Budući da je sustav zasnovan na vremenskoj sikronizaciji, čak ako se desi da poslužitelj pošalje korisniku u više navrata identičan upit, odgovor (response) na njega će biti drugačiji zbog dva različita vremenska odsječka. Ovaj način generiranja jednokratnih lozinki ima dvije razine zaštite - uređaj generira jednokratne lozinke na temelju vremenskog trenutka i upita poslužitelja. Zbog dodatne razine sigurnosti, često se primjenjuje u online bankarstvu pri izvršavanju transakcija financijskih sredstava.

Slika 3: Generiranje jednokratnih lozinki "challenge-based" tehnikom [3]

Prednosti i nedostaci jednokratnih lozinka

Bez obzira što iz one teoretske perspektive jednokratne lozinke pružaju mnoge pogodnosti, jednako take imaju i svoje mane koje ovisno o tipu usluge za koje se primjenjuju, mogu biti većeg ili manjeg značaja. U nastavku slijedi lista nekih prednosti i mana sustava jednokratnih lozinka.

PREDNOSTI:

1. Sustavi za generiranje jednokratnih lozinka su jednostavni i većina ih ne zahtjeva ugradnju bilo kakvih programa

2. Sustave za generiranje jednokratnih lozinki je jednostavno koristiti jer su vrlo slični sustavima za obične lozinke

3. Uređaji za generiranje jednokratnih lozinki koji koriste vremensku sikronizaciju (tokeni) te sustavi koji rade na principu upita/odgovora se mogu koristiti na više usklađenih računala. Prednost toga je što se korisnik može spojiti putem bilo kojeg računala u sustavu te je moguće spajanje više korisnika na pojedinu uslugu istovremeno

4. Upotrebom uređaja za generiranje jednokratnih lozinki i ispisanih lista jednokratnih lozinki, korisnik neće osjetiti posljedice u slučaju krađe lozinke budući da se ona može upotrijebiti samo jednom. Jedino je problematično ako napadač sazna (otuđi) lozinku prije nego li je korisnik uspio upotrijebiti.

5. Zbog efekta jednokratnog korištenja lozinke, omoguće je zaštita od napada zavaravanjem ili od napada presretanjem.

NEDOSTACI:

1. Kako bi se koristio sustav jednokratnih lozinki, korisniku i ponuđaču usluge potrebni su specijalni uređaji i programi. Proizvođač takvih rješenja mora imati zaštićene statične lozinke kako ih se napadač ne bi mogao dočepati.

2. Pri upotrebi tehnike vremenske sikronizacije, moguće je da napadač otuđi lozinku i upotrijebi je u kraćem vremenskom intervalu (20-30 sekundi) pri korištenju na više usklađenih računala. Ovaj problem moguće je riješiti zaštitom odgovarajuće veze.

3. Većina uređaja za generiranje jednokratnih lozinki ne pruža jednaku razinu zaštite budući da napadač može otkriti korisnikovu statičku lozinku i to pri korištenju uređaja koji rade na temelju vremenske sikronizacije ili upita poslužitelja kod koji se ne koristi statička lozinka.

4. Sustavi za generiranje jednokratnih lozinki koji iste drže unaprijed definiranoj tablici su vrlo osjetljivi na napade budući da napadač koji je u mogućnosti dobiti pristup tablici može bez problema “provaliti” bilo kakvu korištenu lozinku za prijavu u sustav.

Izvori informacija: [35] [36]

--Ante Malenica 22:02, 10. lipnja 2013. (CEST)

SSO sustavi

U brojnim poduzećima gdje se odvija mnogo poslovnih procesa koji koriste podatke iz nekoliko autorizacijskih razina, potrebno je mnogo aplikacija koje su ih sposobne obrađivati, s time da svaka od njih ima speficične funkcionalnosti koje ne trebaju biti dostupne svim zaposlenicima. Iz toga se povlači logičan zaključak kako aplikacije koje vrše obradu nad podacima trebaju sustav autentifikacije (i autorizacije) kako bi se mogla definirati prava korisnika, no problematično je što u IS-ovima postoji golem broj aplikacija gdje bi pamćenje autentifikacijskih podataka za zaposlenika koji radi s više aplikacija bilo problematično, čime bi se ujedno povećao i sigurnosni rizik (npr. zapisivanje autentifikacijskih podataka na vidljivo mjesto).

U tu svrhu osmišljeni su sustavi jednostruke prijave čija filozofija rada se može realizirati na dva načina: putem dupliciranja korisničkih imena i lozinki koji se stavljaju u bazu podataka za svaku aplikaciju ili se može tijekom prijave korisnika podatke proslijediti svim aplikacijama koje zaposlenik ima pravo koristiti na temelju svoje uloge u poduzeću.

Bez obzira koji sustav se primijenio, obično se Single-Sign On module izdvaja kao zasebna cjelina, od kuda zapravo i dolazi termin “prijava na jednom mjestu”, kako se obično referencira SSO. Zahtjevi koji se postavljaju pred ovakav sustav prijave, izuzev temeljne ideje da se omogući jednokratna prijava korisnika, uključuju i sljedeće stvari:

1. središnje upravljanje korisničkim podacima i analiza istih
2. automatizirano prebacivanje aplikacija bez prekidanja usluge
3. uspostavljanje središnjeg sustava podataka o reviziji i vremensko praćenje ponašanja korisnika
4. središnji pregled na sustavima i uslugama te pripravljanje odgovarajućih specifičnih dojava o kvaru
5. autentifikacija specifična za aplikacije i uloge

U sustavima koji koriste veći broj aplikacija, administratori su zaduženi za očuvanje integriteta podataka i sigurnosti. Obično je riječ o distribuiranim sustavima koji su nastali povezivanjem funkcionalno neovisnih komponenata koje obuhvaćaju individualne platforme s pridruženim operacijskim sustavima i aplikacijama. Komponente djeluju kao neovisne domene što znači da se korisnik svakoj od njih mora predstaviti (autentificirati) kako bi mogao raditi na njoj. O čemu se točno radi, može se vidjeti na sljedećoj slici:

Slika 4: Upravljanje s više korisničkih računa [4]

Kao što je ilustrirano, korisnik komunicira s primarnom domenom s kojom uspostavlja sesiju. U njoj se vrši prijava na sustav uz predočenje autentifikacijskih podataka što je obično korisničko ime i lozinka. Nakon što se prijavi, korisnik poziva usluge na drugim (sekundarnim) domenama.

Kako bi mogao koristiti funkcije aplikacija na drugim domenama, potrebna je autentifikacija uz podataka koji su upotrebljivi na sekundarnoj domeni. Nju obično predstavlja ljuska operacijskog sustava ili aplikacije. Ono što se traži je neovisno pristupanje svakoj domeni i mogućnost višestrukog pristupa, a to opet traži koordinaciju funkcija za prijavu svih domena. Ideja između ostalog je i smanjiti troškove koji uključuju vrijeme potrebno za prijavljavanje pojedinim domenama, količinu podataka koje je potrebno upamtiti te vrijeme potrebno administratoru za dodjeljivanje dozvola te održavanje sustava. Usluga koja sve to omogućuje je upravo Single-Sing On.

Sustav koji je dio primarnog SSO-a ima zadatak prikupljati korisničke podatke potrebne za autentificiranje korisnika na svaku od sekundarnih domena na koje bi korisnik mogao eventualno zatražiti pravo pristupa. Podaci se mogu iskoristiti na više načina:

1. izravno, korisnički podaci se prosljeđuju sekundarnoj domeni
2. neizravno, korisnički podaci su u funkciji dohvaćanja drugih podataka iz baze koji se zatim koriste pri prijavi na sekundarnu domenu
3. trenutno uspostavljanje sesije sa sekundarnom domenom tijekom prijave na primarnu domenu
4. podaci su samo privremeno spremljeni i korišteni na sekundarnoj domeni tijekom zahtjevanja usluge.

Slika 5: Jednostruka prijava [5]

Sveukupno gledajući, SSO sustav upravljanja pruža jedinstveno korisničko sučelje kroz koje se može koordinirano i sinkronizirano upravljati sa svim dijelovima domena. Kako bi to bilo ostvarivo, nužno je da sekundarna domena može “vjerovati” primarnoj domeni u kontekstu provjere identiteta i zaštite autentifikacijskih podataka te u kontekstu zaštite prijenosa podataka između primarne i sekundarne domene.

U kontekstu Weba, uvođenje SSO-a ima drugačiju svrhu - dok je u poduzećima ideja smanjiti troškove i povećati razinu sigurnosti, na webu sve je usmjereno prema korisnicima usluga. Mnoge komericijalne stranice koje primjenjuju ovaj sustav žele korisniku omogućiti što ugodniji boravak u svojem okruženju sa što manje potrebnih “loginova”. Jedan od najboljih primjera je Google koji je odlučio sve svoje usluge povezati putem ovakvog SSO sustava - prijava na Gmail ujedno znači mogućnost pristupa društvenoj mreži Google+, podacima na cloudu (Google Drive) ili kalendaru (Google Calendar).

Naravno, SSO nije jedina opcija u želji pojednostanjivanja procesa autentitifkacije u sustavima s više domena - postoji model sinkronizacije lozinki gdje korisnik može koristiti jednu lozinku na svim sustavima, a ona se prenosi z pomoć poslužiteljskih agenata. Oni kada utvrde da je promijenjena lozinka, automatski prosljeđuju informaciju drugim sustavima - riječ je o transparentnom procesu za koji korisnik mora biti svjestan da u slučaju komprimiranja lozinke, svi su sustavi u opasnosti. Ipak, ovo nije SSO koncept budući da se proces autentitifikacije stalno mora ponavljati pri prijavi na različite aplikacije.

Drugo rješenje je sustav automatizirane prijave kod kojeg su svi autentifikacijski podaci spremljeni na autentifikacijskom poslužitelju. Korisnik se prijavljuje na poslužitelj uz pomoć klijentske aplikacije, koji zatim daje korisniku listu svih resursa koje može koristiti.Ovaj sustav je pomak u odnosu na sinkronizirane lozinke budući da se može za svaku aplikaciju koristiti drugačija lozinka koja je spremljena na autentifikacijskom poslužitelju.

Nešto naprednija rješenja omogućuju prijavu i autorizaciju korisnika uz pomoć tokena (hrv. oznaka). Prilikom autentifikacije, stvara se jedinstvena oznaka koja se može iskoristiti samo jednom i koja korisniku dodjeljuje resurs sustava za koji je autoriziran. Jedan od najpoznatijih takvih sustava je Kerberos, razvijen na američkom MIT-u. Većina SSO rješenja bazirana je upravo na Kerberosu.

Izvori informacija: [37] [38]

--Ante Malenica 22:29, 10. lipnja 2013. (CEST)

Kriptografija javnog ključa

Pojam kriptografije javnog ključa odnosi se na kriptografski sustav temeljen na dva različita ključa, ukoliko jednim ključem kriptiramo poruku, drugim ćemo je moći dekriptirati. Par ključeva dijelimo na javni(public) i tajni(private) ključ koji su dodijeljeni nekom korisniku. Javni ključ je javno objavljen i uz njega je vezan identitet korisnika koji posjeduje odgovarajući tajni ključ.

Ovu ideju možemo si jednostavno predočiti na primjeru poštanskog sandučića. Poštanski sandučić glasi na Peru Perića, koji za podizanje pošte iz sandučića koristi odgovarajući ključ. Marija Peri šalje pismo i naslovljava ga kao primatelja pisma, pismo stiže u sandučić i samo ga Pero može podići pomoću svojeg ključa. U primjeru Marija koristi Perino ime, prezime i adresu kao javni ključ pomoću kojeg je sigurna da će primatelj pisma biti baš Pero. Dok Pero ključ poštanskog sandučića koristi kao tajni ključ, kojim jedino može podići Marijino pismo iz svog sandučića.

Slika 6: Kriptografija javnog ključa [6]

Kriptografija javnog ključa koristi asimetrične algoritme za generiranje ključeva, koji su osnovani na matematičkim odnosima za koje se pretpostavlja da nemaju jednostavno rješenje. Sigurnost ove kriptografije leži u činjenici kako je gotovo nemoguće doći do tajnog ključa na osnovu poznavanja javnog ključa.

Glavne primjene kriptografije javnog ključa:

Enkripcija poruke - Koristi se za postizanje tajnosti. Poruka kriptirana javnim ključem može se dekriptirati samo odgovarajućim tajnim ključem, za čijeg se imaoca pretpostavlja da je vlasnik identiteta vezanog u taj par ključeva.

Digitalni potpis - Poruka se kriptira tajnim ključem pošiljatelja te se može dekriptirati njegovim javnim ključem kako bi se provjerila autentičnost poruke i postigla neporecivost.

S obzirom na to da si ne možemo međusobno vjerovati na riječ, koristimo infrastrukturu javnog ključa(eng. Public key infrastructure), koja je sustav za stvaranje, spremanje i distribuciju digitalnih certifikata. Unutar PKI nalaze se službe za ovjeravanje(eng. Certificate authorities) putem kojih se jamči da je određeni identitet vezan uz određeni javni ključ.

Neke od pouzdanijih tehnika generiranja asimetričnih ključeva:

 • Diffie-Hellman key exchange
 • DSS	
 • ElGamal
 • Paillier cryptosystem
 • RSA
 • Cramer-Shoup cryptosystem 
 • YAK

Neki od protokola koji koriste algoritme asimetričnih ključeva:

 • PGP-a
 • GPG-a
 • Internet Key Exchange
 • ZRT
 • SSL
 • SILC
 • SSH
 • Bitcoin

Izvor informacija: [39][40][41]

--Vanja Buterin 22:25, 10. lipnja 2013. (CEST)

Dokazi “bez znanja”

Dokazi "bez znanja" spadaju pod kategoriju interaktivnih dokaza, protokola gdje jedna strana, dokazivatelj, dokazuje istinitost određene činjenice drugoj strani, provjeravatelju. Uobičajeni oblik interaktivnih dokaza su izazov-odgovor protokoli, u kojima strane razmjenjuju poruke i nakraju protokola provjeravatelj prihvati ili odbaci dokaz. Ideja dokaza “bez znanja”(zero-knowledge proof) je dokazivanje istinotsti neke tvrdnje od strane dokazivatelja strani provjeravatelja, ali na način da se ne otkriju dodatne informacije u procesu razmjene koje objema stranama nisu od prije poznate.

Na području kriptografije i računalne sigurnosti, ovi dokazi koriste se za identifikaciju i autentikaciju, gdje su provjere najčešće vezane uz identitet dokazivatelja.

Ovi dokazi imaju slijedeće karakteristike:

Cjelovitost(eng. Completeness) - Provjeravatelj uvijek prihvaća dokaz ukoliko je tvrdnja istinita.

Ispravnost(eng. Soundness) - Provjeravatelj uvijek odbacuje dokaz ukoliko tvrdnja nije istinita.

"bez znanja"(eng. zero-knowledge) - Provjeravatelj od dokazivatelja ne dobiva nikakve informacije, koje već ne posjeduje ili do kojih može doći sam. Na taj način dokazatelj može dokazati poznavanje neke tajne informacije bez iznošenja, a provjeravatelj kasnije nemože dokazati istu činjenicu nekom drugom.

Za primjer ćemo pogledati Ali Babinu pećinu:

Slika 7: Ali Babina pećina [7][8]

Vratimo se Mariji i Peri, Marija želi Peri dokazati kako poznaje tajne riječi koje otvaraju tajna vrata između R i S, no ne želi mu ih otkriti. Kako bi mu dokazala poznavanje tajnih riječi, Marija odlazi na poziciju R ili na poziciju S dok Pero čeka na poziciji P. Pero prelazi na poziciju Q i dovikne Mariji iz kojeg tunela želi da izađe. Ako Marija poznaje tajne riječi za otvaranje vrata, nije joj problem ispuniti Perin zahtjev. No, ukoliko Marija ne poznaje tajne riječi, vjerojatnost da će izaći iz traženog tunela iznosi 50%. Pero može ponoviti ovaj izazov koliko god puta želi, dok se ne uvjeri da Marija stvarno poznaje tajne riječi, koje bez obzira na broj ponavljanja, Pero nikada neće saznati.

Glavni nedostatak dokaza "bez znanja" je da se provjeravatelj može lažno predstaviti i jednostavno proslijediti poruke dokazivatelja pravom provjeravatelju i preuzeti njegov identitet. Ovaj problem rješava se ograničenjenjem vremenskog perioda koji je dopušten za slanje odgovora, u kojem je malo vjerojatno da će potencijalni napadač stići iskoristiti preuzete odgovore u svoju korist.

Feige-Fiat-Shamir protokol

Uriel Feige, Amos Fiat i Adi Shamir poznati su po svojoj identifikacijskoj shemi baziranoj na dokazu "bez znanja", koja je ujedni i najbolji dokaz "bez znanja". Ovaj protokol koristi par javnog i privatnog ključa. S obzirom da je za njegovo izvođenje potrebno svega nekoliko modularnih operacija, izvodi se vrlo brzo prigodan je za implementaciju uz slabe mikroprocesore ugrađene u pametne kartice. FFS je isključivo identifikacijski protokol i može poslužiti u svrhu procedura prijave klijenta. Nije ga moguće koristiti za kriptiranje podataka, jer koristi samo operacije množenja.

Slika 8: Slika koraka zbog matematičkih zapisa. [9]

Iako su u pravilu interaktivni, dokazi "bez znanja" mogu biti izvedeni i jednostrano, kada samo dokazivatelj šalje poruke provjeravatelju. "U takvoj izvedbi klijent šalje poruke poslužitelju, ali ne i obratno. Ova metoda koristi jednosmjernu funkciju sažetka gdje se potvrđeni odgovori temelje na izlaznoj vrijednosti te funkcije. Broj potrebnih dokaza je veći od prethodnog slučaja (64 i više)." - Ivan Medenjak

Izvor informacija: [42][43][44]

--Vanja Buterin 22:32, 10. lipnja 2013. (CEST)

Digitalni potpis

Digitalni potpis je način šifriranja kojime dokazujemo autorstvo nad elektroničkim dokumentom. Možemo reći i da je on digitalna inačica vlastitog potpisa, ali nije skenirani vlastoručni potpis. Digitalni potpis je zakonski valjan jednako kao i vlastoručni potpis. Njegova svrha je zaštita autorskih prava i dokazivanje pravog autora nekog dokumenta. Digitalni potpis je bitan za autentičnost, ali se njime osigurava i integritet dokumenta( što znači da se provjerava je li došlo do kakve promjene u poruci pri slanju od pošiljatelja do primatelja) i neporecivost( što znači da pošiljatelj ne može negirati sudjelovanje u slanju poruke).

Kako nastaje digitalni potpis?

Digitalni potpis je kriptografska metoda koja se najčešće sastoji od tri algoritma. Prvi je algoritam kojim se generira privatni ključ. Privatni ključ je ključ kojime se podaci kriptiraju prije slanja računalnom mrežom. Ovaj algoritam funkcionira na način da koristi skup formula te nasumično odabire znakove tako da u ključu nema ponavljanja istih te ga je na taj način gotovo nemoguće replicirati. Nakon što je generiran privatni ključ, algoritam generira i javni ključ koji se koristi za provjeru privatnog ključa. Sljedeći algoritam je algoritam za potpisivanje. Ovaj algoritam koristi privatni ključ i poruku koju želimo poslati da bi generirao digitalni potpis. On generira sažetak( engl. hash) originalne poruke koju želimo poslati te ga kriptira privatnim ključem. Zadnji algoritam je algoritam za provjeru valjanosti potpisa. Nakon što smo primili poruku, uz pomoć javnog ključa i potpisa algoritam potvrđuje valjanost potpisa te je li poruka autentična.

Slika 9: Stvaranje i provjera digitalnog potpisa [10]

Porukom se nazivaju podaci koji se obilježavaju digitalnim potpisom. Originalna poruka se provodi kroz algoritam sažimanja( engl. Secure Hash Algorithm. Zatim se pokreće algoritam za digitalni potpis (engl. Digital Signature Algorithm) i njime kriptiramo sažetak privatnim ključem te tako nastajee digitalni potpis. taj potpis prilažemo originalnoj poruci. Uz pomoć Secure Hash Algoritma i algoritma za digitalni potpis vršimo i provjeru provjeru digitalnog potpisa, ali uz pomoć javnog ključa.

Politika upravljanja digitalnim potpisom

Politika upravljanja digitalnim potpisom se može definirati kao imenovani skup pravila koja navode primjenjivost digitalnog potpisa unutar određene zajednice, te za određeni skup primjena u uobičajenim sigurnosnim zahtjevima. Ona je skup pravila o upravljanju i korištenju certifikata s javnim ključevima. Politika upravljanja digitalnim potpisom se definira na razini neke organizacije, tvrtke, agencija i odjela. Pri definiranju politike je potrebno konzultirati sve strane koje sudjeluju u njenoj provedbi jer je politika od izuzetne važnosti za stvaranje povjerenja među korisnicima. Za politiku upravljanja digitalnim potpisom su bitne norme sigurnosti i infrastruktura javnih ključeva. Neke od normi su:

ISO(eng. International Organization for Standardization) norma 9798 definira identifikaciju sudionika na računalnoj mreži, tehnike digitalnog potpisa, kriptografske algoritme.

NIST definira algoritme za kriptiranje dokumenta, a to su DES (eng. Data Encription Standard) i DSA (eng. Digital Signature Algorithm).

ANSI (American National Standards Institute) definira norme upravljanje ključevima i kriptografiju javnog ključa.

Pri definiranju politike upravljanja digitalnim potpisom nam trebaju i protokoli za prijenost podataka, a najpoznatiji su SSL( engl. Secure Socket Layer)- koji osigurava privatnost komunikacije, identitet sudionika u komunikaciji te jamči pouzdan prijenost podataka. Sljedeći protokol je S/ MIME( engl. Secure Multipurpose Internet MAil Extension) koji se koristi kod prijenosa elektroničke pošte, te protokol SET( engl. Secure Electronic Transaction) koji je bitan pri bankarskim transakcijama kao što je autorizacija plaćanja, te sadrži protokole za naručivanje robe i usluga.

Izvor informacija: [45][46][47]

--Sara Gračan 15:03, 12. lipnja 2013. (CEST)

Autentifikacijski protokoli

SSL/TLS

SSL spada u sigurnosne protokole, a koriste ga aplikacije klijent-poslužitelj arhitekture za osiguranje privatnosti i nepromjenjenosti komunikacije. Izvorno ga je razvio Netscape(TM), a javno je objavljen tek u inačici 2.0 početkom 1995.godine i nastavlja razvoj do inačice 3.0 izdane 1996.godine, kada je konačno zadovoljio sigurnosne zahtjeve i ušao u svakodnevnu uporabu. Inačicu 3.0 razvili su Netscapeovi inženjeri Phil Karlton i Alan Freier u suradnji sa Paulom Kocherom. Na temelju SSL-a 1999.godine razvio se TLS(Transport Layer Securtiy) koji je danas izdan u inačici 1.2 koja je zadnji puta ažurirana u ožujku 2011,kada je iz protokola u potpunosti uklonjena podrška za SSL 2.0.

Koraci uspostave SSL/TLS protokola

S obzirom na to da protokoli mogu raditi sa ili bez SSLa/TLSa, klijent mora specifirati želi li uspostaviti SSL/TLS vezu ili ne, što može na dva načina. Jedna mogućnost je korištenje različitog porta za SSL vezu, a druga je da klijent poslužitelju da zahtjev za promjenu veze u SSL pomoću specifičog mehanizma( primjer STARTTTLS za email i news protokole).

Kada se klijent i poslužitelj odluče koristiti SSL, vezu dogovaraju putem procedura rukovanja(eng. Handshake). Tijekom rukovanja, dogovaraju se oko različitih parametara kojima će postići sigurnost veze:

1. Klijent poslužitelju šalje informacije o svojoj inačici SSLa, postavke za kriptiranje, podatke specifične za sesiju i ostale informacije koje su potrebne poslužitelju kako bi komunicirao s klijentom pomoću SSLa.

2. Poslužitelj klijentu šalje informacije o svojoj inačici SSLa, postavke za kriptiranje, podatke specifične za sesiju i ostale informacije koje su potrebne klijentu kako bi komunicirao s poslužiteljem pomoću SSLa. Uz to poslužitelj još šalje svoj certifikat i ako klijent zatraži resurs poslužitelja koji zahtijeva klijentovu autentifikaciju, poslužitelj traži klijentov certifikat.

3. Klijent autentficira poslužitelja pomoću dobivenih informacija. Ako autentifikacija servera nije moguća, klijent se upozorava na problem i informira da nije moguće uspostaviti kriptiranu i autentificiranu vezu. Ako je poslužitelj uspješno autentificiran, klijent ide na slijedeći korak.

4. Koristeći podatke generirane u dosadašnjem rukovanju klijent, uz suradnju poslužitelja, kreira pre-master tajnu za sesiju, kriptira je poslužiteljevim javnim ključem i šalje je poslužitelju.

5. Poslužitelj autentificira klijenta ukoliko je zatražio njegovu autentifikaciju, ako je autentifikacija klijenta uspješna poslužitelj dekriptira pre-master tajnu svojim tajnim ključem i prolazi kroz određenu proceduru, kroz koju prolazi i klijent počevši od iste pre-master tajne, kojom generira master tajnu. 6. Pomoću master tajne, klijent i poslužitelj generiraju simetrične ključeve sesije, kojima će kriptirati i dekriptirati razmjenjivane informacije tijekom SSL sesije, te provjeravati integritet same sesije.

7. Klijent porukom obavještava poslužitelja kako će buduće poruke biti kriptirane ključem sesije, nakon čega šalje drugu poruku, ovaj put kriptiranu, kojom poručuje kako je klijentov dio rukovanja gotov.

8. Poslužitelj porukom obavještava klijenta kako će buduće buduće poruke biti kriptirane ključem sesije, nakon čega šalje drugu poruku, ovaj put kriptiranu, kojom poručuje kako je poslužiteljev dio rukovanja gotov.

SSL rukovanje je završilo i počinje sesija, veza je sada sigurna do prekida ili zatvaranja veze. Klijent i poslužitelj koriste ključ sesije za kritpiranje i dekriptiranje podataka koje razmjenjuju i za provjeru integriteta sesije. Obje strane mogu zbog unutarnjih ili vanjskih poticaja u bilo koje vrijeme ponoviti dogovor veze, kada se ovi koraci ponavljaju. Ukoliko neki korak ne uspije, rukovanje se prekida i veza se ne uspostavlja.

Izvor informacija: [48]

--Vanja Buterin 22:32, 10. lipnja 2013. (CEST)

IP SEC

IP SEC ili IP security je skupina protokola čija je namjena zaštita komunikacije preko interneta. IP SEC ima dvije osnovne zadaće, a to su tuneliranje paketa i transportni način rada. Kod tuneliranja se nekoliko računala skriva iza jednog čvora te na taj način postaje nevidljiva ostatku mreže. S obzirom da je ostatku mreže nevidljiva, postaje zaštićena od napada. Transportni način rada je takav da postoje dva krajnja računala u mreži između kojih se paketi šalju. Sigurnosne provjere vrši računalo koje prima paket. S obzirom da IP protokol nije pružao elemente zaštite, na IP SEC-u ostaje kriptiranje podataka koji se prenose( engl. payload), provjeta integriteta podataka, autentificiranje čvorova kroz koje paket prolazi te zaštita od neovlaštenog odgovora za vrijeme aktivne sjednice( tzv. Anti- Replay opcija)

Slika 10: Sustav baziran na IP SEC protokolu [11]

Obrada ulaznih i izlaznih paketa

Pri obradi ulaznih paketa, IP SEC paket koji računalo prima prolazi kroz filtere koji su definirani u Security Association bazi. Nakon što ulazni paket prođe kroz SAD, oni se dekriptiraju te se provjerava njihova autentičnost. Nakon provjere autentičnosti, podaci se šalju u Security Policy Dabase filter, a tu se ili prihvaćaju ili odbijaju što ovisi o tome odgovaraju li paketi sigurnosnim politikama.

Slika 11: Prikaz ulaznih podataka [12]

Ukoliko želimo poslati paket na javnu računalnu mrežu, taj paket prvo mora proći kroz SPD- OUT filter. u tom filteru se provjerava koji paketi se smiju poslati na javnu mreži, a provjerava se putem predefiniranih pravila. Ukoliko se provjerom zaključi da paket smije na javnu mrežu, bira se odgovarajući SA algoritam za zaštitu podataka. Zadnji korak se vrši u Security Association bazi gdje se postavlja autentifikacija paketa te se paket enkriptira ukoliko je to potrebno.

Slika 12: Prikaz izlaznih podataka [13]

Izvor informacija: [49][50]

--Sara Gračan 15:04, 12. lipnja 2013. (CEST)

Sigurnosna ljuska

Sigurnosna ljuska ili SSH( engl. Secure Shell) protokol je protokol koji pruža sigurne udaljene prijave i ostale sigurne mrežne servise preko nesigurne mreže. Ovaj protokol uvodi zaštitu tajnosti podataka, za razliku od sličnih protokola kod kojih se podaci kroz mrežu šalju u nekriptiranom obliku, te ih se može presresti, pročitati ili mijenjati. Sigurnosna ljuska se temelji na modelu klijent/ poslužitelj. Na unaprijed zadanom mrežnom priključku( TCP priključak 22) poslužitelj prima zahtjeve, a klijent šalje zahtjeve po potrebi.

Slika 13: Shema SSH modela klijent/poslužitelj [14]

Koristeći troslojnu arhitekturu možemo opisati uspostavu i samu komunikaciju unutar SSH protokola. Arhitekturu čine transportni sloj, autentifikacijski sloj i spojni sloj.

Slika 14: Prikaz slojeva u SSH [15]

Transportni sloj osigurava enkripciju, zaštitu integriteta i autentifikaciju poslužitelja, a tu je omogućeno i sažimanje podataka kako bi prijenos istih bio što jednostavniji i brži. Kod ovog sloja se određuju i metode kojima će biti razmijenjeni ključevi, određuju se algoritmi koji će se koristiti i funkcije sažimanja poruke( hash). Za transportni sloj se može koristiti arhitektura koja osigurava i jamči pozdan prijenos podataka na nižim slojevima mrežne arhitekture, ali se najčešće nadograđuje na TCP/ IP mrežu.

Nakon uspostavljene komunikacije na transportnom sloju, komunikacija se uspostavlja na autentifikacijskom sloju. Na ovom sloju se provjerava identitet klijenta na poslužitelju, a ta provjera se može obaviti uz pomoć više metoda. Jedan od načina je putem lozinki- kriptirana lozinka se šalje SSH kanalom. Public key Infrastructure su metode koje se temelje na digitalnim potpisima i kriptografskim algoritmima.

Autentifikacijski sloj ostvaruje SSH komunikacijski kanal, a preko tog kanala se može provesti spojni sloj. Za spojni sloj je karakteristično da se tu ostvaruju udaljene prijave korisnika, izvođenje naredbi, prosljeđivanje veza te se sve veze povezuju u jedan kriptirani kanal, a sva komunikacija se odvija putem kanala.

Izvor informacija:[51][52]

--Sara Gračan 15:04, 12. lipnja 2013. (CEST)

Kerberos

Ovaj autentifikacijski protokol razvijen je 1978. godine na MiT-u (op.a. skraćenica za Massachusetts Institute of Technology), za potporu fizički nesigurnih mreža. Razvijen je s idejom da mrežnim aplikacijama omogući siguran način identifikacije. Naziv je dobio prema psu “Kerberu”, biću iz antičke mitologije koji je kao troglava zvijer čuva ulaz u svijet mrtvih. Za svoju realizaciju koristi dvije osnovne komponente:

ulaznica - u službi autentifikacije korisnika i osiguravanje podataka autentifikator - potvrđuje se da je korisnik isti onaj kojemu je ulaznica inicijalno dodijeljena

Proces prijave započinje klijent, tj. principal kako se on označava u Kerberos terminologiji. On pokreće razmjenu poruka između tri strane kako bi kontaktirana strana (poslužitelj) utvrdila identitet klijenta. Nakon prijave korisnika u sustav, isti se spaja na Kerberos poslužitelj od kojeg dobiva sjednički ključ. Sjednički ključ u upotrebi je između korisnika i poslužitelja za dodjelu ulaznica (engl. „Ticket Granting Server“ – TGS). Sjednički ključ kriptira se ključem temeljenim na korisnikovoj lozinci. Ukoliko korisnika daje pravu lozinku sustav je u mogućnosti dekriptirati sjednički ključ.

Potvrda s kojom poslužitelj dokazuje identitet klijenta ima oblik ulaznice - identifira klijenta i autentifikatora gdje potonji validira ulaznicu i spriječi ponovnu uporabu stare ulaznice od strane napadača. Ulaznica je samo valjana u odgovarajućem perioud zvanom lifetime. Kad razdoblje valjanosti istekne, ulaznica postaje nevaljana. Ako se žele daljnje usluge, potrebno je zatražiti novu ulaznicu, s time da se valjana ulaznica može koristiti proizvoljan broj pta, sve dok joj ne istekne valjanost.

Osnovni problem Kerberosa je brz rast opsega - poslužitelj mora biti u mogućnosti spremiti tajne ključeve za svakog korisnika i svakog poslužitelja za dodjelu ulaznica čime brzo postaje kompleksan za implementaciju među organizacijama. Danas se uglavnom koristi u protokolima aplikacijskog sloja (npr. telnet ili FTP), u svrhu osiguranja sigurnosti korisnika i računala. Nešto manje je upotrebi kao implicintni autentifikacijski sustav toka podataka ili kao RPC mehanizam. Također je korišten i u nižim slojevima za sigurnost među čvorovima, u protokolima poput IP-a, UDP-a ili TCP-a, no takve implementacije su vrlo rijetke.

Izvori informacija: [53] [54]

--Ante Malenica 22:35, 10. lipnja 2013. (CEST)

Autorizacija

Postupak autorizacije

Autorizacija je proces kojim se korisniku nakon autentifikacije dodjeluju prava definirana sigurnosnom politikom poduzeća, može se svesti na šest jednostavnih koraka:

Slika 15: Postupak autorizacije [16]

1. Zahtjev autentitificiranog klijenta za pristupom pojedinom resursu prosljeđuje se upraviteljskom serveru gdje se on presreće od strane procesa zaduženog za provođenje sigurnosnih mehanizama. Na primjer, upravitelj resursima može biti WebSEAL za hipertekst protokol, HTTPS pristup ili neka druga aplikacija.

2. Nakon što je zahtjev zadržan u resource manageru, proces zadužen za provođenje sigurnosnih mehanizama pomoću autorizacijskog API-a poziva autorizacijsku uslugu za donešenje autorizacijske odlike.

3. Autorizacijska usluga pomoću posebnog algoritma provodi autorizacijsku provjeru na resursu.

4. Odluka da se prihvati ili odbije zahtjev klijenta je u obliku preporuke vraćena resurs menadžeru putem procesa za provođenje sigurnosnog mehanizma.

5. Ako je zahtjev klijenta u konačnici odobren, upravitelj resursima propušta zahtjev aplikaciji odgovornoj za pristup traženom resursu.

6. Klijent u konačnici prima rezultate tražene operacije.

Izvor informacija :[55]

--Vanja Buterin 23:37, 11. lipnja 2013. (CEST)

Liste kontrole pristupa

Strogo definicijski gledano, liste kontrole pristupa možemo označiti kao “uređeni skup podataka o ovlastima i pravima pristupa svih subjekata (korisnika ili programa) na računalnom sustavu.” Budući da se u kontekstu autorizacije bavimo dodjeljivanjem prava nad resursima sustava korisnicima koje smo autentificirali, spomenuti skup podataka nije ništa drugo nego li utvrđivanje što pojedini korisnik smije ili ne smije raditi nad objektima sustava. Njih možemo pobliže definirati kao datoteke ili direktorije datoteka, a svaki korisnik ovisno o datim ovlastima može nad njima imati ovlasti čitanja, pisanja ili izvođenja.

Liste kontrole pristupa (op.a. u nastavku teksta koristit ćemo englesku skraćenicu ACL za Access Control List) obično se koriste u organizacijskim strukturama koje imaju centraliziranu sigurnosnu politiku s velikim brojem korisnika kao što su sveučilišta i istraživački laboratoriji, gdje je u fokusu zaštita orijentirana na podatke u okruženju u kojem korisnici sami upravljaju računalnom sigurnošću (Unix i Linux OS-ovi).

U ACL-u svaki element liste definira subjekt te operacije za koje on ima prava nad određenim objektom. Primjerice, unos u AC listu “IIvan, read” daje Ivanu pravo da samo čita određenu datoteku. Ideja je da se prije izvođenja operacije nad objektom koju traži određeni subjekt, prvo provjeri ima li na listi taj subjekt dodijeljeno pravo prema traženoj operaciji.

Kod računalnih mreža, opet strogo definicijski gledano, ACL predstavlja “skupinu pravila koja određuju portove ili pozadinske aplikacije (eng. deamon) koje su raspoložive na uređaju mrežnog sloja OSI modela, a uz listu korisnika ili mreža kojima je dozvoljeno korištenje usluge”. U prijevodu, mrežni poslužitelji i usmjerivači mogu u sebi sadržavati ACL-ove koji se mogu podesiti da vrše kontrolu dolaznog i odlaznog podaktovnog prometa. Definicijski to je slično pojmu vatrozida, no u izvođenju ideje filtriranja prometa jasno je kako su prisutne određene razlike.

Zanimljivo je cijelu ideju promotriti u kontekstu operacijskih sustava koji su danas dio naše svakodnevnice. Unix/Linux sustavi svoje kontrole pristupa datotekama baziraju na dodjeljivanju atributa rwx (logično, r je početno slovo oznake čitanja, w dozvole pisanja, a x dozvole izvođenja) za skupine “vlasnik” (eng. owner), “grupa” (eng. group) i “ostali korisnici” (eng. others). Dakle atributi su ti koji označaju što korisnik (ne) smije raditi s pojedinim datotekama. Na operacijskim sustavima Windows taj je problem riješen pomoću atributa “take ownership”, “change permissions” i “delete” - ideja je isto, samo što je na ovaj način moguća nešto fleksibilnija delegacija prava pristupa.

Izvori informacija: [56] [57]

--Ante Malenica 22:39, 10. lipnja 2013. (CEST)

Diskrecijska kontrola pristupa

Kako se još skraćeno naziva DAC (eng. Discretional model), riječ je o kontroli pristupa koja se najčešće koristi na osobnim i umreženim računalima. DAC je realiziran kao dorađen ACL - razlikovni element je mogućnost dodjele subjektima jedinstven tip pristupa, odnosno ovlasti. U prijevodu, jedan korisnik primjerice može samo čitati i pisati u neku datoteku, dok drugi ima isključivo ovlasti čitanja te iste datoteke. Politiku pristupa definira vlasnik datoteke (najčešće korisnik koji je je kreirao) koji može jednoznačno odrediti tko točno ima pravo pristupiti objektu nad kojim on ima ovlasti. Postoje dva važna koncepta:

1. vlasništvo datoteka i podataka - svaki objekt u sustavu ima svog vlasnika. U većini DAC sustava pretpostavljeni vlasnik objekta je onaj subjekt (korisnik ili proces) koji ga je stvorio.
2. prava pristupa i ovlasti - vlasnik objekta ih može dodijeliti ostalim subjektima na računalu za taj objekt.

Treba još istaknuti kako DAC za razliku od nediskrecijskog pristupa, subjekta ne ograničava u mogućnosti kopiranja podataka - ako on ima ovlasti čitanja, može ih kopirati ako želi. Ovo je važno iz raloga što subjekt ima mogućnost kopirati podatke u datoteku čiji je vlasnik što zapravo omogućuje dodijelu prava pristupa korisnicima kojima je pristup izvornoj datoteci bio onemogućen. Doduše, na ovaj način se narušava integritet podataka, što recimo nije slučaj u obveznoj kontroli pristupa podacima koja onemogućuje kopiranja podataka na spomenuti način. DAC modeli su obično temeljeni na strukturi vlasnik-objekt, matrica pristupa te na centraliziranom, decentraliziranom i raspodijeljenom pristupu. Primjer DAC-a u realizaciji matrice pristupa možemo vidjeti na slici ispod:

Slika 16: Matrica pristupa [17]

Izvor informacija: [58] [59]

--Ante Malenica 22:42, 10. lipnja 2013. (CEST)

Obavezna kontrola pristupa

U odnosu na DAC, mandatorni model je korak naprijed u realizaciji sustava autorizacije. Radi se o obliku kontrole pristupa kod kojeg “operacijski sustav ograničava mogućnost subjekta u pristupanju i/ili obavljanju neke akcije nad objektima.” Ograničenje se ostvaruje pomoću tzv. klasifikacija - sigurnosnih oznaka koje kada se dodijele subjektima označaju tko od njih može pristupiti određenim objektima. U praksi, riječ je o centraliziranom sustavu gdje mehanizam nadzora prema objektima nameće operacijski sustav i/ili modul za sigurnost jezgre OS-a. Jednostavnije rečeno, korisnik (subjekt) kada želi napraviti određenu operaciju na objektom, testira se prema nekolicini autorizacijskih pravila, u okviru sigurnosne politike koja iz “iz vrha” definirala je li pojedina operacija dozvoljena ili nije. Dakle, sigurnosna politika se provodi centralizirano gdje vlasnik sustava nameće tu politiku, dok je administrator sustava implementira.

Očigledno, naspram DAC-a glavni razlikovni element je u tome što obvezna kontrola pristupa ne dozvoljava subjektima sustava odluku o sigurnosnoj politici, tj. o dodjeljivanju potrebnih atributa za pristup objektima. Ovaj model autorizacije najčešće se koristi u višerazinskim sustavima poput vojske i drugih vladinih organizacija gdje se svakodnevno radi s veoma osjetljivim podacima. Kako bi se sačuvao integritet podataka, svi subjekti i objekti moraju imati oznake osjetljivosti koje definiraju razinu povjerenja potrebnu za pristup pojedinim podacima. Pravilo je da razina osjetljivosti subjekta mora biti viša ili jednaka od objekta nad kojim se želi izvršiti primjerice operacija čitanja. Sustav osjetljivosti dokumenata uspastavio je vojni savez NATO još nakon drugog svjetskog rata:

Slika 17: Sustav osjetljivosti dokumenata [18]

Vezano uz mandatorni model pristupa, važno je spomenuti još dvije metode prava pristupa:

1. Lattice
2. Bell-LaPadula

Model Lattice koji se obično koristi u vladinim strukturama, dodjeljuje subjektu i objektu uređeni skup klasifikacija, a objektu s određenom klasifikacijom mogu pristupiti isključivo subjekti čija je klasifikacija viša ili jednaka onoj od objekta. U modelu Bell-LaPadula, filozofija razmišljanja je obratna - subjektima s nižom klasifikacijom od objekta onemogućava se pristup, dok se još uz to onemogućava pisanja u objekte s nižom klasifikacijom od subjekta koji želi obaviti akciju pisanja.

Izvor informacija: [60]

--Ante Malenica 22:44, 10. lipnja 2013. (CEST)

Kontrola temeljena na ulogama

Bit kontrole temeljene na ulogama je da svaki korisnik unutar organizacije ili cjeline koja se koristi ima svoju ulogu i prema tim ulogama su svima dodijeljene određene ovlasti i mogućnosti pristupa podacima i mijenjanja istih, sukladno ovlastima. Pri korištenju modela temeljenog na ulogama, unutar organizacije ili korištene cjeline je potrebno imati definirane grupe i funkcijske uloge na temelju kojih se korisnicima dodjeljuju ovlasti. Korisnik može biti u više grupa i može imati više uloga sa različitim ovlastima i pristupima različitim podacima, a uloge dodjeljuje administrator.

Pri definiranju kontrole temeljene na ulogama načešće se koriste oznake kao što su:

S (eng. Subject) - korisnik ili program

R (eng. Role) - uloga, tj. posao ili naslov koji definira razinu autoriteta

P (eng. Permissions) - dozvola načina korištenja resursa

SE (eng. Session) - mapiranje koje uključuje S, R i/ili P

SA - dodjela subjektu

PA - dodjela prava

RH - parcijalno uređena hijerarhija uloga

Izvor informacija:[61][62]

--Sara Gračan 15:04, 12. lipnja 2013. (CEST)

Bilježenje

Bilježenje još možemo zvati i nadzor i praćenje rada, a ti pojmovi označavaju jednoznačno praćenje aktivnosti koje koje korisnik provodi dok je prijavljen u sustav. Bilježenje je isto i način osiguranja da korisnici unutar sustava izvršavaju samo one aktivnosti za koje su ovlašteni.

Područja nad kojima se mora provoditi nadzor su:

ovlašteni pristup (korisnička imena, datum i vrijeme događaja, tipovi događaja, datoteke kojima je pristupano, korišteni programi),

privilegirane aktivnosti,

neovlašteni pokušaji pristupa,

sistemska upozorenja i greške

Praćenje aktivnosti se može bilježiti na razne načine, ali se obično implementira tako da se bilježe aktivnosti( engl. logging) korisnika u posebne log datoteke, što je najčešći način bilježenja tehničkih komponenti informacijskog sustava kao što su operacijski sustavi ili aplikacije. Aktivnosti je potrebno bilježiti u slučaju incidenta da bi se mogla osigurati pravovremena podrška, te da se izbjegnu eventualne velike posljedice. Kod složenijih informacijskih sustava je od izuzetne važnosti da se bilježenje aktivnosti vezanih za sigurno funkcioniranje sustava vrši kontrolirano. S obzirom da je pregledavanje višestrukih log datoteka u velikim sustava nepraktično, a možda čak i nemoguće, postoje sustavi za centralizirano bilježenje koji omogućuju ručno ili automatizirano pregledavanje log zapisa, te omogućuju njihove arhiviranje koje je u skladu s prije definirano sigurnosnom politikom. Pri korištenju sustava za centralizirano bilježenje se osigurava dodatna razina sigurnosti na sustavima koji udaljeno šalju zabilježene aktivnosti- ukoliko ih neovlaštena osoba pokuša kompromitirati, centralni sustav čuva sve aktivnosti koje su se dogodile prije pokušaja kompromitiranja, te se one ne mogu mijenjati, a osoba koja je pokušala kompromitirati sustav ne može ukloniti svoje tragove i aktivnosti.

Datoteke je potebno zaštititi od aktivnosti kao što:

isključivanje sustava za bilježenje,

izmjene tipa zabilježenih informacija,

izmjena ili brisanje podataka,

te je potrebno spriječiti mogućnost prekida nadziranja zbog nedostatka prostora na disku.

Arhitektura sustava za bilježenje

Arhitektura sustava za praćenje se temelji na interakciji između uređaja na mreži, servera za praćenje i billing servera. Mrežni uređaji skupljaju podatke o potrošnji i aktivnostima koji se nakon toga šalju na server za praćenje, a podaci se najčešće šalju uz pomoć protokola za praćenje. Server za praćenje analizira prikupljene podatke, a analiziranje može uključivati sažimanje informacija, eliminiranje duplikata ili generiranje zapisa o aktivnosti. Nakon što su podaci analizirani na serveru za praćenje, oni se šalju na billing server gdje se analiziraju troškovi, trendovi i kapacitet planiranih funkcija. Glavni cilj pri analiziranju trendova i kapaciteta je predviđanje buduće uporabe sustava, a s obzirom da niti jedno predviđanje ne može biti u potpunosti točno, dopušteni su manji gubici u paketima. Što se tiče sigurnosnih potreba za analizu trendova i kapaciteta, one ovise o podacima o potrošnji, ali i o senzibilitetu i važnosti podataka. Što je podatak važniji i osjetljiviji, to je i sigurnost veća.

Slika 18 : Prikaz arhitekture sustava za bilježenje [19]

Izvor informacija:[63][64][65]

--Sara Gračan 15:05, 12. lipnja 2013. (CEST)

Praktični dio

Za praktični primjer odlučili smo se prikazati enkripciju i dekripciju izvedenu u php-u pomoću MCrypt biblioteke na osnovu tutorijala za korištenje MCrypt biblioteke. Modificirali smo php dio koda i dodali html formu za unos proizvoljnih podataka.

Ovako to izgleda pri unosu:

Slika 19: Unos podataka u obrazac

Kada se izvrši:

Slika 20: Izvršeni kod

Pregled cijelog koda u php formatu[66] i txt formatu [67]

Kriptiranje

Slika 21: [20]

Otvaranje modula željenog algoritma, u ovom slučaju rijndael-256(AES) u modu ctr kroz mycrypt_module_open poziv i postavljanje za vrijednost varijable $td koju će koristiti druge funkcije.

Slika 22: [21]

Poruka se serijalizira kako bi podržavala php varijable i polja.

Slika 23: [22]

Kreira se incijalizacijski vektor prikladne duljine za 256-bitnu enkripciju.

Slika 24: [23]

Inicijaliziraju se bufferi.

Slika 25: [24]

Izvodi se kriptiranje poruke putem mcrypt_generic funkcije uz parametre algoritma $td i poruku $msg.

Slika 26: [25]

Inicijalizacijski vektor dodaje se ispred kriptoteksta za lakši prijenos ili spremanje. Računa se autentifikacijski kod poruke koristeći pbkdf2[68](Password-Based Key Derivation Function 2), tj. funkciju za dobivanje ključa baziranu na lozinci, koja je dio PKCS[69] (standarda kriptografije javnog ključa RSA laboratories). Mac(Master Autentification Code) se dodaje na kraj kriptoteksta, a poruka sad sadrži inicijalizacijski vektor, kriptotekst i mac.

Slika 27: [26]

Počiste se bufferi i zatvara se modul za kriptiranje.

Slika 28: [27]

Rezultat kritptiranja možemo dobiti i u bazi 64, ako smo tako specificirali, što nismo, i rezultat dobivamo u čistom binarnom obliku.

Dekriptiranje

Izvodi se obrnuto od kriptiranja.

Slika 29: [28]

Ukoliko smo postavili bazu 64 prvo dekodiramo poruku.

Slika 30: [29]

Otvaramo mycrypt modul sa specificiranim algoritmom i modom koji su jednaki kao i u prvom dijelu. Iz poruke vadi se inicijalizacijski vektor, određuje se veličina mac-a i vadi se van iz poruke, nakon čega se iz poruke vadi kriptirana poruka.

Slika 31: [30]

Prije same dekripcije, izračuna se mac iz inicijalizacijskog vektora i kriptoteksta, te se uspoređuje s macom dobivenim u poruci kako bi se utvrdilo je li bilo kakvih promjena.

Slika 32: [31]

Inicijaliziraju se bufferi i kriptotekst se dekriptira, poruka se deserijalizira radi podrške za varijable i polja, bufferi se isprazne, modul se zatvara i vraća nam se originalna poruka.

Ovaj kod izračunava ključ na temelju hash vrijednosti dobivene iz lozinke koju se dodatno posoli(Salting [70]). Taj dio koda nećemo prikazati, a možete ga pronaći na izvoru informacija.

Izvor informacija: [71]

--Vanja Buterin 22:56, 11. lipnja 2013. (CEST)

Zaključak

Područje autentifikacije, autorizacije i bilježenja vrlo je široko i sadrži paletu raznolikih rješenja i primjena. Skup odabranih rješenja ovisiti će ponajprije o tipu kontrole koju neki entitet želi uvest. Banke će se naprimjer odlučiti za certifikate i protokole poput SSL-i TLS-a, poput PBZ-a koji za svoje PBZ365@NET netbanking uslugu koristi 3DES-EDE-CBC protkol u 168-bitnoj enkripciji, dok će provider email usluga poput Google-a za svoju webmail uslugu primjeniti RC4 protokol za sigurnost u 128-bitnoj enkripciji.

Izvor informacija: [72][73]

--Vanja Buterin 14:50, 12. lipnja 2013. (CEST)