Prijedlog koncepta integriranog središnjeg sustava ... · minimalni skup atributa koji definiraju identitet koji će se ostvariti kroz uspostavu centralnog direktorija elektroničkog

www.e-hrvatska.hr 1

REPUBLIKA HRVATSKA

Prijedlog koncepta integriranog središnjeg sustava autentikacije i autorizacije Verzija 1.1

www.e-hrvatska.hr 2

Naziv dokumenta: Prijedlog koncepta integriranog središnjeg sustava autentikacije i

autorizacije

Oznaka verzije dokumenta: Verzija 1.1

Datum dokumenta: 8. lipnja 2010.

Status dokumenta: Radna verzija

Svrha dokumenta:

Definiranje specifikacija funkcionalnih i nefunkcionalnih zahtjeva sustava za autentikaciju i autorizaciju korisnika u elektroničkoj upravi primijenjenoj na uredsko poslovanje u tijelima državne i

javne uprave, kao i lokalne samouprave

Veza: Strategija razvoja elektroničke uprave u Republici Hrvatskoj za

razdoblje od 2009. do 2012. godine

Cilj: Uspostaviti jednoznačan sustav upravljanja elektroničkim

ispravama

Nositelji projekta: Središnji državni ured za e-Hrvatsku (SDUeH)

Ministarstvo uprave

www.e-hrvatska.hr 3

Uvod

Strategijski i pravni okvir

U skladu s okvirom Vlade Republike Hrvatske izraženim kroz „Strategiju reforme državne uprave za razdoblje 2008. - 2011.“, usvojenim 19. ožujka 2008., kao i „Strategiju razvoja elektroničke uprave u Republici Hrvatskoj za razdoblje od 2009. do 2012. godine“ usvojenom 21. siječnja 2009. definirani su prioriteti Vlade u cilju razvoja informacijskog društva i društva u cjelini. Osim informatizacije državne uprave, potrebno je cjelokupnu državnu upravu i uredsko poslovanje približiti građanima kao krajnjim korisnicima. U tu svrhu potrebno je razviti adekvatan model načina, dostupnosti i razina pristupa korisnika elektroničkim uslugama državne uprave.

U skladu s direktivama Europske komisije i eEurope inicijativom „i2010 – A European Information Society for growth and employment“, europska politika u području informacijskog društva definirana je kroz olakšanu komunikaciju i protok informacija između tijela državne uprave, poslovnih korisnika i građana, i fokusirana na povećanje efikasnosti, transparentnosti, dostupnosti i sudjelovanje svih korisnika sustava. U okviru provedbe inicijative i2010, Europska komisija kroz program IDABC potiče elektroničko poslovanje u javnoj upravi.

Svrha

Ovim projektom započinje uspostava središnjeg sustava autentikacije i autorizacije što je definirano jednim od ciljeva ranije navedene Strategije (Strategija razvoja elektroničke uprave u Republici Hrvatskoj za razdoblje 2009. do 2012.) u kojoj između ostalog stoji: „CILJ 4.1.2. Uspostaviti središnji sustav autentikacije i autorizacije. U cilju jasnog i pravno utemeljenog dodjeljivanja ovlaštenja djelovanja i korištenja resursa u sustavu e-uprave uspostavit će se središnji sustav autentikacije i autorizacije, kako državnih službenika uključenih u sustav e-uprave, tako i korisnika njezinih usluga. Osnova ovog sustava bit će upravljanje elektroničkim identitetima (e-identitetima) čijim je uvođenjem namjera stvoriti jedinstven sustav autentikacije i autorizacije u okruženju elektroničkog (a ne fizičkog) komuniciranja korisnika usluga e-uprave i tijela državne uprave. Sustav e-identiteta će građanima omogućiti uspješno, sigurno i vremenski povoljno korištenje javnih usluga elektroničkim putem (kroz izravnu, interaktivnu on-line komunikaciju korištenjem Interneta, kroz ostale usluge u sustavu elektroničkih komunikacija primjenom fiksnih i mobilnih telekomunikacijskih sustava).“ Ovim projektom definiraju se načela i smjernice razvijanja tog sustava što je osnovna podloga za širu javnu raspravu i kasniju izvedbu sustava.

www.e-hrvatska.hr 4

Sažetak

Ovaj dokument predstavlja početni korak i preporuke u uspostavljanju nacionalnog sustava elektroničkog identiteta koji će se koristiti u za potrebe autentikacije i autorizacije u sustavima elektroničkih usluga, odnosno elektroničke uprave. Strategija razvoja elektroničke uprave u Republici Hrvatskoj za razdoblje od 2009. do 2012. godine oslikava prioritete Vlade RH u cilju razvoja informacijskog društva kroz procese informatizacije državne uprave i približavanje državne uprave građanima kao krajnjim korisnicima. Ova strategija je i u skladu sa direktivama i inicijativama Europske komisije za olakšanom komunikacijom i protokom informacija unutar elektroničke uprave, prema građanima i poslovnim subjektima, a s ciljem povećanja učinkovitosti, transparentnosti te dostupnosti.

Osnova sustava je uspostava integriranog i središnjeg sustava elektroničkog identiteta kao podloge, te pripadnih servisa koji će stvarnim uslugama elektroničke uprave omogućiti učinkovito utvrđivanje i provjeru identiteta korisnika usluga. Sustav će kao takav biti i osnova za uspostavu autorizacijske infrastrukture koja će omogućiti distribuciju prava korištenja, administriranja i nadgledanja informacijskih sustava elektroničke uprave.

Doprinosi ovog dokumenta sastoje se u sljedećim isporukama (stavkama):

1. Okvir za provedbu projekta: Definicija glavnih zahtjeva s obzirom na korisnički pogled na sustav elektroničkog identiteta, funkcionalnosti i ograničenja, te trenutno okruženje projekta s obzirom na pravni okvir. Prikazano je i postojeće stanje s aspekta autentikacijskih i autorizacijskih sustava koji se koriste u RH. Ti sustavi funkcioniraju zasebno opslužujući pojedine entitete (TDU, tijela lokalne uprave i sl.), uz postojanje inicijativa koje bi omogućili integraciju sustava i usluga između različitih tijela. Sukladno tome, vidljiva je potreba za integracijom autentikacijskih sustava, odnosno za postojanjem integriranog autentikacijskog servisa na nacionalnoj razini koji bi omogućio učinkovitu organizaciju i integraciju usluga elektroničke uprave uz uklanjanje redundantnih elemenata, kako u vidu infrastrukture, tako i u vidu organizacijskih elemenata. Sustav osobnog identifikacijskog broja OIB-a također je prepoznat kao bitan integracijski korak prema navedenom cilju, jer predstavlja osnovni element jednoznačnog elektroničkog identiteta (autentikacije) te upravljanje njegovim životnim ciklusom. Isto tako, prepoznata je i nužnost učinkovitog korištenja nacionalne PKI usluge koju održava FINA u postupcima utvrđivanja elektroničkog identiteta koji zahtijevaju viši stupnjeve povjerljivosti, odnosno sigurnosti.

2. Smjernice za provedbu projekta: Definirana su osnovna svojstava te prikazana snimka uspješne međunarodne prakse koja može poslužiti kao dobar primjer pri uspostavi

www.e-hrvatska.hr 5

sustava. Dan je prijedlog sigurnosnih razina pri utvrđivanju elektroničkog identiteta odnosno autorizacije ovlasti. Određivanje sigurnosne razine za pojedine usluge nužan je preduvjet koji će omogućiti funkcioniranje usluga bez gubitka integriteta sustava te uz sigurnost i zaštitu informacija. Isto tako, prikazane su i smjernice za identifikaciju i analizu rizika pri korištenju elektroničkih sustava autentikacije i autorizacije, kao i smjernice za ostvarenje procesa kreiranja i registracije elektroničkih vjerodajnica u sustavu. Konačno, definirani su i osnovni principi funkcioniranja sustava: povjerljivost, autentičnost, nepovredljivost, integritet, dostupnost i skalabilnost. Nacionalna identifikacijska, autentikacijska i autorizacijska agencija (u daljnjem tekstu NIAAA) predviđena je kao mjesto upravljanja radom sustava kao i mjesto na kojem se nalaze opće usluge te autentikacijske i autorizacijske usluge najviše razine općenitosti i prihvaćenosti. Koje tijelo će preuzeti funkciju NIAAA u ovom dokumentu nije definirano i ostavlja se za odluku institucijama nadležnim za uspostavu cjelokupnog nacionalnog IAA sustava.

3. Model sustava: Prikazan je konceptualni model sustava NIAAS (Nacionalni identifikacijski, autentikacijski i autorizacijski sustav) sa elektroničkim identitetom kao osnovnim nositeljem informacija o korisnicima u sustavu. Predložena je povezanost elektroničkog identiteta sa OIB sustavom te njegova ovisnost o životnom ciklusu OIB identifikatora. Isto tako, zadaća integriranog autentikacijskog sustava je i da pruži minimalni skup atributa koji definiraju identitet koji će se ostvariti kroz uspostavu centralnog direktorija elektroničkog identiteta. Također, u modelu su definirani i osnovni postupci nad elektroničkim identitetom tijekom njegovog životnog ciklusa: kreiranje, spremanje, održavanje te brisanje (odnosno deaktivacija). Životni ciklus OIB identifikatora se mora upotrijebiti za upravljanje životnim ciklusom elektroničkog identiteta. Konačno, sustav omogućuje svim servisima povezivanje s ciljem korištenja usluge utvrđivanja identiteta.

4. Model identifikacije i autorizacije: Cilj ove isporuke je definiranje preporuka pri identifikaciji sigurnosne razine potrebne za izvođenje usluge. Taj postupak može biti zahtjevan u slučajevima kada se pojedine usluge dobivaju kombiniranjem više podusluga pod nadležnostima različitih tijela uprave. Dodatno, definirane su osnovne uloge korisnika u sustavu na osnovnoj razini elektroničkog identiteta: pojedinac, organizacija i agent (zastupnik). Ove uloge predstavljaju osnovnu klasifikaciju pri pristupanju korisnika sustavu NIAAS, dok se daljnja klasifikacija i razrada uloga ostavlja na sustavima koji sudjeluju u ostvarenju usluga.

5. Okviri i smjernice za sigurnu komunikaciju unutar sustava: Analizirani su aspekti sigurnog funkcioniranja predloženog sustava, moguće prijetnje te njihov utjecaj na

www.e-hrvatska.hr 6

sustav. Sukladno tome, predloženi su osnovni zahtjevi s obzirom na kontrolni element sustava, odnosno kontrolu upravljanja te korištenja elektroničkih identiteta.

6. Predstavljanje projekta i primjene u Programu e-Ured: Isporuka obuhvaća prezentaciju projekta dionicima, predstavnicima TDU i dobavljačima, te prikupljanje primjedbi i sugestija s osvrtom na primjenu u Programu e-Ured.

www.e-hrvatska.hr 7

Sadržaj

1 Okvir za provedbu projekta................................................................................................. 12

1.1 Izrada snimke postojećeg stanja.................................................................................. 12

1.1.1 Snimka postojećih autorizacijskih sustava u Hrvatskoj ......................................... 12

1.1.1.1 Hijerarhija PKI u RH ..................................................................................................... 16

1.1.1.2 Cross-certificiranje ...................................................................................................... 19

1.1.2 Snimka osnovnih pravnih okruženja projekta ....................................................... 19

1.1.3 Snimka organizacijskog okruženja projekta .......................................................... 21

1.1.3.1 HR PKI Bridge CA (NCARH) ........................................................................................... 22

1.1.3.2 Interoperabilnost direktorija i NCARH ......................................................................... 22

1.2 Definicija korisničkog okvira ........................................................................................ 23

1.2.1 Utvrđivanje funkcije sustava ................................................................................ 23

1.2.2 Utvrđivanje načina isporuke usluge korisnicima ................................................... 25

1.2.3 Definiranje zahtjeva za integritetom informacija .................................................. 26

1.2.4 Definiranje funkcionalnih zahtjeva za upravljanje autorizacijama ......................... 27

1.2.5 Utvrđivanje mogućih problema u funkcioniranju sustava ..................................... 27

1.3 Definicija sustava identifikacije ................................................................................... 29

1.3.1 Zahtjev za jednoznačnim utvrđivanjem identiteta i tipa korisnika ........................ 30

1.3.2 Utvrđivanje načina uspostave integriranog sustava identifikacije ......................... 33

2 Smjernice za provedbu projekta ......................................................................................... 39

2.1 Sigurnosne razine u autentikacijskom procesu ............................................................ 39

2.1.1 Referentni model procesa autentikacije ............................................................... 39

2.1.2 Definicija autentikacijskih sigurnosnih razina ....................................................... 42

2.1.3 Utvrđivanje potrebne sigurnosne razine .............................................................. 45

2.1.4 Identifikacija rizika ............................................................................................... 45

www.e-hrvatska.hr 8

2.1.5 Referentna matrica za određivanje potrebne sigurnosne razine .......................... 49

2.1.5.1 Primjer primjene referentne matrice........................................................................... 50

2.1.6 Autentikacijski mehanizmi ................................................................................... 51

2.1.6.1 Tipovi tokena .............................................................................................................. 51

2.1.6.2 Model autentikacijskog protokola s obzirom na prijetnje ............................................ 52

2.1.6.3 Model valjanosti autentikacijskih atributa ................................................................... 54

2.1.7 Utvrđivanje identiteta i prava pristupa servisima e-uprave .................................. 54

2.2 Definiranje svojstava sustava ...................................................................................... 56

2.2.1 Sigurnost i zaštita dokumenata ............................................................................ 58

2.2.2 Osiguravanje integriteta zajedničkih podataka ..................................................... 59

2.2.3 Interoperabilnost među jedinicama u sustavu ..................................................... 59

2.2.4 Skalabilnost sustava ............................................................................................. 60

2.2.5 Osnovni servisi portala ......................................................................................... 60

2.3 Provedba potrebnih analiza ........................................................................................ 62

2.3.1 Analiza prethodno provedene međunarodne prakse ........................................... 66

2.3.1.1 Češka .......................................................................................................................... 66

2.3.1.2 Švedska ....................................................................................................................... 66

2.3.1.3 Austrija ....................................................................................................................... 67

2.3.1.4 Estonija ....................................................................................................................... 67

2.3.1.5 Velika Britanija ............................................................................................................ 67

2.3.1.6 Nizozemska ................................................................................................................. 68

2.3.1.7 Novi Zeland ................................................................................................................. 68

2.3.1.8 Australija .................................................................................................................... 69

2.3.1.9 Ostale inicijative u sklopu EU....................................................................................... 70

2.3.1.10 ISA: Interoperability Solutions for European Public Administrations (1) ................... 71

2.3.1.11 STORK: Secure Identity Across Borders Linked (2) .................................................... 71

2.3.2 Analiza i prilagodba predloženih principa ............................................................. 72

2.3.3 Analiza potrebnih podataka za inicijalnu registraciju ............................................ 75

www.e-hrvatska.hr 9

2.3.4 Analiza dostupnosti usluge................................................................................... 76

2.3.5 Analiza korištenja usluga tijela državne i javne uprave i lokalne samouprave ....... 76

3 Model sustava .................................................................................................................... 78

3.1 Prijedlog konceptualnog modela ................................................................................. 78

3.1.1 Opis životnog ciklusa u procesu utvrđivanja identiteta ......................................... 84

3.1.2 Detaljni opis pojedinih faza životnog ciklusa ........................................................ 84

Procedure upravljanja životnim ciklusom certifikata u FINA-i ...................................................... 87

4 Modeli identifikacije i autorizacije ...................................................................................... 91

4.1 Definiranje potrebnih razina pristupa korisnika ........................................................... 91

4.1.1 Identifikacija potrebnih razina pristupa ................................................................ 91

4.1.2 Identifikacija uloga korisnika ................................................................................ 92

4.2 Detalji implementacije ................................................................................................ 93

4.2.1 Definiranje svojstava faktora autentikacije .......................................................... 94

5 Okviri i smjernice za sigurnu komunikaciju unutar sustava ............................................... 105

5.1 Izrada koncepta analize sigurnosnih aspekata ........................................................... 105

5.1.1 Analiza integriteta i dostupnosti poruka ............................................................. 110

5.1.2 Analiza identifikacijskih ključeva ........................................................................ 112

5.2 Izrada koncepta definiranja mogućih prijetnji ........................................................... 114

5.2.1 Identifikacija prijetnji u komunikaciji .................................................................. 115

5.2.2 Analiza uporabe certifikata ................................................................................ 116

5.2.3 Koncept sustava upravljanja digitalnim identitetima .......................................... 117

5.2.4 Definiranje ulaznih točaka pri pristupu u sustav ................................................. 117

5.3 Nadgledanje i upravljanje sustavom .......................................................................... 117

5.3.1 NIAAS: Prijedlog registracijske i autorizacijske agencije ...................................... 118

5.3.2 Registracija korisnika za usluge eUprave ............................................................ 122

www.e-hrvatska.hr 10

5.3.3 Zahtjevi na sigurnosne razine s obzirom na fazu registracije .............................. 122

5.3.3.1 Identifikacija korisnika .............................................................................................. 123

5.3.3.2 Izdavanje vjerodajnica ............................................................................................... 124

5.3.3.3 Pouzdanost izdavatelja vjerodajnica .......................................................................... 125

5.3.3.4 Registracija korisnika: Prikaz zahtjeva na sigurnosne razine ....................................... 125

5.3.4 Evidencija o položajima i pravima korisnika ....................................................... 127

6 Koncept pripreme za javnu raspravu projekta ................................................................... 128

6.1 Definiranje servisa dostupnih korisnicima ................................................................. 128

6.2 Obrazloženje prednosti sustava ................................................................................ 131

6.3 Koncept početnog poslovnog slučaja ........................................................................ 134

7 Prilog 1 – Koncept korištenja NIAAS-a za usluge autentikacije i autorizacije na sigurnosnim razinama 0 i 1 .......................................................................................................................... 136

7.1 Opis sigurnosnih razina 0 i 1 ...................................................................................... 136

7.1.1 Osnovni skup podataka centralnog imenika ....................................................... 137

7.1.2 Prošireni skup podataka centralnog imenika ...................................................... 138

7.2 Scenarij korištenja NIAAS sustava na razinama 0 i 1 .................................................. 139

7.2.1 Sustav autentikacije na sigurnosnoj razini 0 ....................................................... 141

7.2.2 Sustav autentikacije na sigurnosnoj razini 1 ....................................................... 141

7.3 Sigurnosne zaštite ..................................................................................................... 142

7.3.1 Sigurnosne zaštite za korištenje ponovljivih lozinki ............................................ 142

7.3.2 Sigurnosne zaštite za korištenje jednokratnih lozinki ......................................... 143

7.3.3 Ostale mjere zaštite ........................................................................................... 143

7.4 Dokumentacija implementacije i korištenja sustava .................................................. 144

7.5 Provjera sukladnosti sustava pružatelja usluga s NIAAS-om ...................................... 145

7.6 Ostala pravila i postupci za provođenje prije i tijekom rada NIAAS-a ......................... 145

7.7 Komunikacija sustava pružatelja usluga s NIAAS-om ................................................. 146


7.7.1 Komunikacija u svrhu autentikacije korisnika ..................................................... 147

7.7.2 Izmjena korisničke lozinke.................................................................................. 148

7.7.3 Komunikacija u svrhu rada sa proširenim skupom podataka centralnog imeničkog direktorija ......................................................................................................................... 148

7.8 Dodatak A – očekivano opterećenje i performanse sustava ...................................... 149

7.9 Dodatak B – veze sa drugim sustavima autentikacije ................................................. 149

8 Prilog 2 – Uvjeti za izdavanje certifikata FINA-e ................................................................ 151

8.1 Opći uvjeti za izdavanje certifikata ............................................................................ 151

8.2 Dokumentacija .......................................................................................................... 151

8.3 Korisnički računi ........................................................................................................ 151

8.3.1 Fizičke osobe - građani ....................................................................................... 151

Korisnički računi ....................................................................................................................... 151

8.3.2 Poslovni subjekti ................................................................................................ 152

Korisnički računi ....................................................................................................................... 152

Korisnički podračuni ................................................................................................................. 152

8.4 Identifikacija tražitelja certifikata .............................................................................. 152

8.4.1 Fizičke osobe - građani ....................................................................................... 152

8.4.2 Poslovni subjekti ................................................................................................ 152

8.5 Dodatna provjera točnosti identifikacijskih podataka ................................................ 153

8.6 Dokumentacija za utvrđivanje identiteta ................................................................... 153

8.7 Odbijanje Zahtjeva .................................................................................................... 153

9 Prilog 3 – Simetrični i asimetrični kriptosustavi ................................................................. 154

9.1 Simetrični kriptosustav.............................................................................................. 154

9.2 Asimetrični kriptosustav ............................................................................................ 155

9.3 Sažetak poruke ......................................................................................................... 156

10 Kazalo pojmova ............................................................................................................ 158


1 OKVIR ZA PROVEDBU PROJEKTA

Svrha poglavlja je izrada vizije kojom je definiran generalno primarno korisnički pogled na glavne zahtjeve projekta, glavne funkcionalnosti, glavna ograničenja i okruženje projekta s pravne i organizacijske strane. Ovo poglavlje obuhvaća izradu snimke postojećeg stanja, definiciju korisničkog okvira te definiciju sustava identifikacije.

1.1 Izrada snimke postojećeg stanja

On-line autentikacija omogućava korisnicima i tijelima državne uprave da imaju povjerenje u identitet druge strane u transakciji putem Interneta (on-line transakcija). Autentikacija je neophodna infrastrukturna komponenta u ostvarivanju ciljeva e-vlade.

U sustavima elektroničke uprave posebna se pažnja pridaje funkciji informiranja korisnika i razmjeni elektroničkih poruka pri kojoj svaki korisnik u svakom trenutku mora biti u mogućnosti jednoznačno utvrditi identitet drugog sudionika u elektroničkoj komunikaciji.

Stoga se kao preduvjet nameće uvođenje novih obrazaca i postupaka potvrđivanja identiteta osoba koje izrađuju sadržaje, osoba koje im pristupaju (koje ih koriste) te osoba na koje se podaci odnose. Istodobno, usluge elektroničke uprave pružaju se osobama za koje se identitet ne može više utvrđivati na postojeće načine te je nužno uspostaviti elektroničke sustave elektroničke autentikacije i autorizacije, ne samo korisnika usluga već i državnih službenika koji djeluju u sustavu elektroničke uprave.

Pri tome će središnje mjesto imati uspostava integriranog sustava autentikacije i autorizacije. Ovaj je sustav neizostavna kategorija elektroničkog poslovanja koje se izgrađuje razvojem sustava e-uprave i koje traži nove oblike identifikacije fizičkih i pravnih osoba.

1.1.1 Snimka postojećih autorizacijskih sustava u Hrvatskoj

U interakciji između vladinih informacija i poslovnih ili privatnih korisnika postoje osjetljivi podaci i pomoću raznih metoda zaštite potrebno je osigurati njihovu privatnost. Osiguranje je potrebno posebno u slučaju novčanih transakcija, pravno obvezujućih izjava ili kada transakcija rezultira otkrivanjem osobnih informacija. Razina osiguranja u identificiranju korisnika ovisi o svim strankama angažiranima u transakciji, pri čemu ovjera identiteta smanjuje nesigurnosti te podiže povjerenje u elektroničkim interakcijama. Autentikacija je element šireg sustava prakse, procedura i tehničke implementacije, koji rade zajedno kako bi osigurali informacijski sustav i mrežnu komunikaciju koja služi za podršku.


Korištenje kvalificiranih certifikata i ključeva u tim certifikatima u elektroničkim komunikacijama znači neporecivost u elektroničkim komunikacijama što predstavlja napredni elektronički potpis prema Zakonu o elektroničkom potpisu.

Normalizirani certifikati i ključevi u tim certifikatima mogu se koristiti za potrebe identifikacije strane u elektroničkim komunikacijama što predstavlja elektronički potpis prema Zakonu o elektroničkom potpisu.

U Hrvatskoj postoji Nacionalno certifikacijsko tijelo Republike Hrvatske (NCARH) u okviru Ministarstva gospodarstva, rada i poduzetništva. FINA je za sada jedini dobavljač kvalificiranih certifikata u RH, kojih može biti više. Vlada RH je poslove certificiranja za potrebe Tijela državne uprave (TDU) povjerila FINA-i koja izdaje digitalne certifikate koje može koristiti javni i privatni sektor.

Postoji i rješenje koje koriste banke u Hrvatskoj, a zasniva se na materijalnom objektu, zalogu (token) i nematerijalnom dijelu koji predstavlja poznavanje lozinke (PIN – Personal Identification Number).

FINA izdaje i normalizirane certifikate i ključeve u tim certifikatima koji se koriste za enkripciju podataka. Razine sigurnosti certifikata koje izdaje CA u FINA PKI navedene su u tabeli 1, kao i kratki opis prijedloga primjene u aplikacijama koje odgovaraju svakoj razini.

Tabela 1. Razine sigurnosti certifikata (FINA)

Razina sigurnosti Klasa Područje primjene

Standardna 1 Ova je razina prikladna u okolinama u kojima postoje rizici i posljedice prouzrokovane kompromitiranjem podataka, ali nemaju veće značenje. To može biti pristup tajnim podacima gdje vjerojatnost zlonamjernog pristupa nije velika. U ovoj sigurnosnoj razini se podrazumijeva da je mala vjerojatnost da korisnici budu zlonamjerni.

Srednja 2 Ova razina je prikladna za okoline u kojima su rizici i posljedice kompromitiranja podataka umjereni. Može se koristiti u transakcijama koje imaju znatnu novčanu vrijednost ili rizik od krivotvorenja, ili u onim transakcijama koje imaju pristup povjerljivim informacijama u kojima je vjerojatnost zlonamjernog pristupa znatna.


Razina sigurnosti Klasa Područje primjene

Visoka 3 Ova razina je prikladna za uporabu u transakcijama u kojima je ugroženost podataka visoka, ili su posljedice propusta u sustavu zaštite velike. To su transakcije vrlo visoke vrijednosti ili s velikim rizikom od krivotvorenja.

U tabeli 2 prikazane su temeljne karakteristike FINA PKI certifikata.

Tabela 2. Temeljne karakteristike FINA PKI certifikata

OPIS KARAKTERISTIKE Razina sigurnosti

Standardna Srednja Visoka

Period važenja (godine) 5 2 1

Osiguranje od poslovnih rizika DA DA DA

SSCD NE DA DA

I&A

Inicijalni I&A kod RA ili LRA DA DA DA

Ponovni I&A kod RA ili LRA (godine) 5 4 3

Obnavljanje/opoziv

Obnavljanje – automatski DA DA NE

Obnavljanje – na zahtjev DA DA DA

Opoziv i objava CRL-a (sati) 24 12 6

Od BSI (British Standards Institution) ICD (International Code Designator) je dodijeljen OID za FINU. Za potrebe FINA PKI uvedena je konstrukcija OID-a prikazana u tabeli 3:


Tabela 3. Konstrukcija OID polja za FINA PKI

OID polje Atribut Kod Opis

FINA PKI

ISO 1 ISO

ORG 3 ISO organizacija

ICD 124 International Code Designator

FINA 1104 ID za FINU prema ICD-u

PKI 5 PKI objekti u FINI

Policy Policy XX

Kodiranje verzije politike

1X – RDC CP

2X – TDU CP

3X – DEMO PDS

4X – TSP

Tip Tip certifikata X Kodiranje tipa certifikata

Profil Profil X Kodiranje politike prema EU i korištenja SSCD

Limit

Razina sigurnosti (Preporučeni limit)

X Kodiranje razine sigurnosti - preporučenog financijskog limita pouzdanja u certifikat

CA sustav u FINA PKI omogućava izdavanje:

Standardnih certifikata

ID certifikata s dva para asimetričnih ključeva (potpis i enkripciju).


EN označeni certifikati imaju KeyUsage oznaku: Key Encipherment, dok DS označeni certifikati imaju KeyUsage oznaku: Digital Signature.

Profili certifikata prikazani su tabelom 4.

Tabela 4. Profili certifikata

Profil Namjena Uporaba ključa

Osnovni profil Specijalizirani profil SSCD EN DS

WEB Web korisnik X X RFC 2459 Promjenjivo Izbor

Web server X X RFC 2459 Promjenjivo Izbor

ID

Enterprise X RFC 2459 Promjenjivo Izbor

X RFC 2459 Promjenjivo Izbor

Entrust aplikacija

X RFC 2459 Entrust OID Izbor

X RFC 2459 Entrust OID

Administracija X RFC 2459 Entrust OID

Izbor X RFC 2459 Entrust OID

VPN Uređaji X RFC 2459 IPSEC

Izbor X RFC 2459 IPSEC

1.1.1.1 Hijerarhija PKI u RH

Elektroničke transakcije i elektroničko poslovanje su postale uobičajeni način za sve vrste poslovanja, te se odvijaju preko javnih, privatnih i poslovnih mreža. Iznimno je važan element u elektroničkom poslovanju mogućnost utvrđivanja izvornosti elektroničke informacije, na sličan način kao što se utvrđuje izvornost vlastoručno potpisanih dokumenata. Provjeru izvornosti i cjelovitosti informacije u elektroničkom obliku moguće je ostvariti uporabom elektroničkog potpisa. Infrastruktura koja omogućuje uporabu elektroničkog potpisa naziva se infrastruktura javnog ključa (PKI) i ostvaruje se primjenom asimetričnog kriptografskog sustava. PKI omogućava tajnost, kontrolu pristupa, integritet, autentikaciju i neporecivost servisa. PKI


upravlja generiranjem i distribucijom javnog i privatnog ključa i objavljuje certifikate u javnim imenicima.

Tripartitno povjerenje se odnosi na situaciju u kojoj dvije strane unaprijed vjeruju jedna drugoj, iako prethodno nisu uspostavile poslovnu ili osobnu vezu. To se događa zato jer svaka od njih ima uspostavljen odnos sa zajedničkom trećom stranom (autorizacijskom agencijom), ta je treća strana jamac za uspostavu povjerenja između prve dvije.

Domena povjerenja je domena kojom upravlja jedan PMA, unutar iste domene može poslovati jedan ili više CA-ova. Svaka domena ima jedan glavni (principal) CA (PCA) i vlastiti repozitorij. Arhitektura može biti hijerarhijska ili povezujuća. Na sljedećoj je slici prezentirana arhitektura PKI u RH, interoperabilnost i povezivanje s drugim PKI domenama izvan RH.

Slika 1. Arhitektura NCARH

Nacionalni CA za Hrvatsku (NCARH) prikazan na slici 1, djeluje kao provoditelj povjerenja u domeni HR PKI i povezuje PKI domene unutar i izvan Republike Hrvatske. NCAHR povezuje domene povjerenja parom cross-certifikata sa PCA-ovima. NCARH je "most povjerenja" (Bridge of trust) i osigurava:

povezivanje domena povjerenja unutar RH,


povezivanje domene povjerenja HR PKI s domenama povjerenja izvan Republike Hrvatske

izdavanje ARL za CA u domeni HR PKI.

Ministarstvo gospodarstva, rada i poduzetništva nadležno je ministarstvo za provedbu Zakona o elektroničkom potpisu i pripadajućih Pravilnika. Ministarstvo ima status krovnog ovjerovitelja. Ministarstvo vodi evidenciju davatelja usluga certificiranja koji izdaju kvalificirane certifikate, te provodi inspekcijski nadzor nad radom davatelja usluga certificiranja.

PMA HR PKI postavlja/upravlja i objavljuje politike u domeni HR PKI i upravlja radom NCARH i repozitorijom. PMA je odgovoran za certificiranje i akreditaciju u domeni HR PKI i ima odgovornost za nadzor svih PKI operacija. PMA je također odgovoran za:

uspostavu i odobravanje operativnih standarda i procedura u HR PKI,

uspostavu i odobravanje prikladnih mehanizama kontrola i izvještajnih procedura za HR PKI,

odobravanje i opoziv certifikata za CA,

donošenje odluka u slučaju sporova između CA i RA,

uspostavu, odobravanje, održavanje i objavljivanje CA-a za NCARH.

Akreditacijski tim formira PMA HR PKI. Zadaća je ovog tima da zajedno s Ministarstvom provodi postupak akreditacije (postupak provjere informacijske sigurnosti koji obuhvaća i tehnološke, informatičke, organizacijske, fizičke i ostale sposobnosti) ovjerovitelja/davatelja usluga certificiranja.

PKI interoperabilnost

Cilj PKI interoperabilnosti je implementacija povezivanja između različitih PKI domena. Tri su područja koja treba uzeti u obzir kod razmatranja povezivanja različitih PKI domena. Prvo je područje tehničke naravi - protokol, struktura podataka i ostali aspekti (primjerice razmjena certifikata i informacija o listi opozvanih certifikata). Drugo je područje politike i uspostavljanja poslovnog odnosa, koje sadrži netehničke detalje odnosa između dvije PKI domene koje žele elektronički razmjenjivati podatke. Treće je područje zakonski okvir koji osigurava vjerodostojnost (pravomoćnost) elektroničkog potpisa. Prema projektima PKI interoperabilnosti temeljenima na međunarodnoj praksi (EU, SAD i Australija), preporučaju se slijedeći modeli povezivanja:


Cross-certificiranje - uspostavljanje relacije povjerenja između dva CA - jedan CA izdaje cross-certifikat drugome CA-u i obrnuto.

Bridge CA - Bridge CA djeluje kao poseban trust model. Umjesto bilateralnog cross-certificiranja između različitih CA-ova, potrebno je da se CA-ovi cross-certificiraju samo s Bridge CA prema jednoj ili više politika certificiranja. Tamo gdje se politike preklapaju, CA-ovi imaju "trusted path" posredstvom Bridge CA.

Certificate trust list (CTL) je potpisana struktura podataka koja između ostalog sadrži listu "trusted CAs" (povjerljivih CA). Lista također sadrži identifikatore politike i podržava ekstenzije.

1.1.1.2 Cross-certificiranje

Ovdje su opisane glavne procedure koje provodi Ministarstvo pri procjeni sposobnosti CA-a koji je podnio zahtjev za cross-certificiranje sa NCARH-om. Sljedeći se termini odnose na ocjenu ispunjavanja zahtjeva pri postupcima akreditacije:

Zadovoljava - u potpunosti je ispunjen navedeni zahtjev

Manjkavost - djelomično/nepotpuno ispunjen navedeni zahtjev

Neusklađenost - nije ispunjen navedeni zahtjev,

Akreditacija daje trećim stranama - krajnjim korisnicima certifikata, povjerenje da je implementirani PKI sustav ovjerovitelja koji izdaje kvalificirane certifikate siguran. PMA HR PKI donosi konačnu odluku o izdavanju cross-certifikata na temelju prijedloga akreditacijskog tima. Akreditacijski tim predlaže odluku na temelju izvještaja o pregledu dokumentacije, revizijskog izvještaja o implementaciji CA sustava i komentara na CA-ov izvještaj ili CA-ovih komentara na izvještaj. U slučaju manjkavosti akreditacijski tim daje CA-u mogućnost poduzimanja korektivnih akcija koje će biti provjerene pri sljedećem periodičkom ili izvanrednom pregledu CA poslovanja. CA poduzima korektivne akcije u roku od 60 dana, ako je ustanovljena jedna ili više neusklađenosti. Četiri ili više manjkavosti u odnosu na isti zahtjev kvalificiraju se kao neusklađenost. Zahtjev će bit odbijen ako nakon korektivnih akcija postoje još neusklađenosti. Certifikat će se izdati ako nema neusklađenosti. Certifikat je valjan za period od pet godina, uz mogućnost, opoziva ili prekida rada.

Više o FINA-inim općim uvjetima za izdavanje certifikata može se naći u Prilogu 2.

1.1.2 Snimka osnovnih pravnih okruženja projekta

Pravni okvir projekta određuju sljedeći akti:


- Zakon i uredba o informacijskoj sigurnosti te pojedini pravilnici UVNS-a i ZSIS-a

- Zakon o sustavu državne uprave (»Narodne novine« br. 75/93., 92/96., 48/99., 15/00., 127/00., 59/01., 199/03. 79/07.)

- Zakon o ustrojstvu i djelokrugu središnjih tijela državne uprave (»Narodne novine«, br. 199/03., 30/04., 136/04., 22/05., 44/06., 5/08., 27/08.)

o Uredbe o unutarnjem ustrojstvu

o Pravilnici o unutarnjem redu

- Zakon o općem upravnom postupku

- Zakon o osobnom identifikacijskom broju (»Narodne novine« br. 60/08)

o Pravilnik o osobnom identifikacijskom broju,

- Zakon o zaštiti osobnih podataka

- Zakon o osobnoj iskaznici

o Pravilnik o osobnoj iskaznici

o Pravilnik o obrascima i evidenciji osobnih iskaznica,

- Zakon o elektroničkom potpisu (»Narodne novine« br. 10/02, 80/08)

o Pravilnik o evidenciji davatelja usluga certificiranja elektroničkih potpisa (»Narodne novine« br. 54/02, 112/07)

o Pravilnik o registru davatelja usluga certificiranja elektroničkih potpisa koji izdaju kvalificirane certifikate (»Narodne novine« br. 54/02)

o Pravilnik o mjerama i postupcima uporabe i zaštite elektroničkog potpisa i naprednog elektroničkog potpisa, sredstava za izradu elektroničkog potpisa, naprednog elektroničkog potpisa i sustava certificiranja i obveznog osiguranja davatelja usluga izdavanja kvalificiranih certifikata (»Narodne novine« br. 54/02)

o Pravilnik o tehničkim pravilima i uvjetima povezivanja sustava certificiranja elektroničkih potpisa (»Narodne novine« br. 89/02)


o Uredba o djelokrugu, sadržaju i nositelju poslova certificiranja elektroničkih potpisa za tijela državne uprave (»Narodne novine« br. 146/04)

- Zakon koji se referencira na "Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures", a definira pravni, institucionalni i tehnološki okvir uporabe elektroničkog potpisa u RH.

1.1.3 Snimka organizacijskog okruženja projekta

Važna stavka u organizacijskom okruženju projekta je rad na uspostavljanju tehnološki neutralnih pristupa za djelotvornu autentikaciju i autorizaciju osoba i entiteta na lokalnoj,ali i međunarodnoj razini, u skladu sa smjernicama OECD-a za sigurnost informacijskih sustava i mreža, te smjernicama OECD-a o zaštiti privatnosti i prekograničnom protoku osobnih podataka. U tu svrhu potrebno je:

Poticati razvoj, pružanje i korištenje elektronske provjere identiteta u uslugama koje utjelovljuju standardna načela poslovne prakse, uključujući tehničke i ne-tehničke mjere zaštite. Bitno je pri tome poštivati razine dostupnosti podataka i sudionika, posebice s obzirom na sigurnost i privatnost podataka i identiteta sudionika interakcije.

U privatnom i javnom sektoru potrebno je poticati poslovnu i pravnu kompatibilnost i tehničku interoperabilnost autentikacijskih shema i protokola, kako bi se olakšale interakcije i transakcije između različitih sektora i pravnih entiteta. Kompatibilnost i interoperabilnost usluga potrebno je osigurati na nacionalnoj i međunarodnoj razini.

Poduzeti korake za podizanje svijesti svih sudionika, uključujući i privatne i pravne osobe, o prednostima korištenja elektroničkih provjera na nacionalnoj i međunarodnoj razini.

Postojeći institucionalni okvir je sljedeći:

Ministarstvo uprave, odnosno Uredi državne uprave u županijama vode podatke o osobnim stanjima građana.

Ministarstvo unutarnjih poslova vodi evidencije o izdanim osobnim iskaznicama, kao i evidenciju o strancima.

Ministarstvo pravosuđa vodi registar trgovačkih društava.

Porezna uprava izdaje osobni identifikacijski broj.


Državni zavod za statistiku vodi registar poslovnih subjekata.

Financijska agencija je registrirani izdavatelj kvalificiranih certifikata.

Svako tijelo državne uprave vodi evidenciju o položajima i radnim mjestima u svojoj organizaciji.

1.1.3.1 HR PKI Bridge CA (NCARH)

U okviru PKI projekta Republike Hrvatske uspostavljen je NCARH (Nacionalni CA za Republiku Hrvatsku) radi postizanja interoperabilnosti između različitih PKI domena u zemlji, te povezivanje sa PKI domenama u inozemstvu. Ovaj koncept omogućuje lako povezivanje različitih domena. Bridge CA je CA koji djeluje kao "most povjerenja" između različitih PKI domena cross-certificiranjem sa PCA-om bilo koje domene. Svi certifikati nisu kreirani na jednak način, postoje zajednička pravila sigurnosti koja su važan dio politike izdavanja certifikata. Politika Bridge CA koristi policy mappings ISO/ITU x.509 standarda radi sprječavanja pristupa certifikatima niže razine sigurnosti u domene više razine sigurnosti. Policy mapping podatak omogućuju CA-u procjenu politike certificiranja u cross-certifikatu i donošenje odluke o razini sigurnosti certifikata. HR PKI PMA je izdao Politiku certificiranja koja je glavni dokument i osnova za izdavanje certifikata NCARH. Ova politika sadrži pravila rada NCARH i načine na koje će NCARH izdavati certifikate drugim CA-ovima i određivanje razina sigurnosti traženih certifikata.

Postoje tri razine sigurnosti certifikata, standardna srednja i visoka. HRPKI PMA će procijeniti politiku certificiranja CA koji traži cross-certificiranje i odrediti razinu sigurnosti cross-certifikata. Posredovanje NCARH stvara specijalne zahtjeve za aplikacije na strani klijenta. Razvoj certifikacijske staze: Bridge CA je kombinacija hijerarhijske i mrežne PKI arhitekture. Aplikacije za razvoj certifikacijskog lanca samo iz hijerarhijske PKI strukture (takva je većina aplikacija) moraju se dopuniti dijelom koji se odnosi na mrežni PKI da bi se moglo vrednovati certifikate koji preko Bridge CA kontaktiraju njihovu PKI domenu. Povezivanjem različitih PKI domena uvode se različite politike certificirana, što može umanjiti sigurnost sustava. Radi toga se uvode drugi parametri koji strože određuju pravila povezivanja. To su x.509 ekstenzije certifikata certificate policies i policy mappings, koje reduciraju razine sigurnosti. Također nameConstraint ekstenzija značajna je u sprječavanju neželjenih staza povjerenja.

1.1.3.2 Interoperabilnost direktorija i NCARH

Osim certifikacijskog lanca, korisnici različitih PKI sustava povezani preko NCARH moraju doći do certifikata krajnjeg korisnika i do podataka liste opozvanih certifikata za svaki certifikat iz certifikacijskog lanca. Ovi podaci se nalaze u imenicima (direktorijima). Vlasnički protokoli i ograničenja na strani korisnika su tehničke barijere u interoperabilnosti imenika, a postoje također ograničenja u politici pristupa (osjetljivost informacija).


1.2 Definicija korisničkog okvira

U digitalnom okruženju, autentikacija postavlja druga složena pitanja i probleme koje treba riješiti. Neka od pitanja se odnose na to kako je definiran identitet i kako ga je moguće vrednovati na način da se uspostavi povjerenje i omogući formalizacija u cilju automatske obrade zahtjeva. Dok su u mnogim aspektima ova pitanja ista kao u fizičkom svijetu, povećana razina dvosmislenosti, zajedno s ozbiljnim sigurnosnim prijetnjama u komunikaciji, uvodi nove složenosti i izazove koji moraju biti riješeni. Izazovi se mogu podijeliti na tehnološke (npr. interoperabilnost, sigurnost), pravne (npr. pravno priznanje, odgovornost, privatnost) i ekonomske (npr. troškovi implementacije i korištenja).

Međunarodna iskustva vezana uz autentikaciju, uključujući i one koje se odnose na implementacije u Australiji, Singapuru, Velikoj Britaniji, Irskoj i Kanadi ukazuju na važnost odvajanja identifikacije i autentikacije od autorizacije (pristupa uslugama). Proces autentikacije podrazumijeva registraciju svojstava pojedinca koja služe kao faktori za elektroničku identifikaciju prilikom pristupa u sustav.

1.2.1 Utvrđivanje funkcije sustava

Autentikacija je općenito potrebna za upravljanje rizicima ili sprječavanje negativnih posljedica koje mogu nastati ako transakcija ne uspije na neki način. Ovi rizike i njihove posljedice mogu snositi tijela državne uprave, korisnici, obje strane u transakciji ili, u rijetkim slučajevima, treća strana. Rizici postoje kada su u transakcije uključene:

privatne informacije; financijske vrijednosti; provjeravanje korisničkog prava na nešto; promjene pravnog statusa.

Autentikacija podrazumijeva identifikaciju uz predočenje ispravnih identifikatora. Autentikacija se potom autorizira od strane nadležnog tijela. Identifikacija je osnova za sve aspekte sigurnosti. Svi korisnici, bili to pružatelji usluga ili privatni i poslovni korisnici informacijskog sustava (IS) moraju imati jedinstveni identifikator. Identifikator je isto što i korisnik, koji želi koristiti sredstva IS-a, i to njega razlikuje od svih drugih entiteta u sustavu. Bez identifikacije nema osnove za dodjelu ovlaštenja (autorizacije) ili provođenja i nadziranja odgovornosti. Mnogi su informacijski sustavi primarno zaokupljeni sa identifikacijom pojedinaca (bilo kao privatne bilo kao pravne osobe). Ipak, ljudi su samo jedna vrsta korisnika. U današnjem korisnik/poslužitelj mrežnom okruženju, programi, sklopovi, i mreže također trebaju imati ispravnu identifikaciju kako bi se


osigurala i provela informacijska sigurnost. Informacijski korisnici moraju imati dodijeljena dovoljna ovlaštenja kako bi mogli koristiti informaciju, a informatička sredstva (uređaji i programi) moraju osigurati dovoljnu sigurnost za te informacije. Komunikacijska mreža mora biti ovlaštena za transport informacija prije nego ih preuzima. Ova razina je neophodna za osiguranje informacijske sigurnosti.

Identifikacija je ono što korisnik prezentira i pokazuje da je to što je. U tom kontekstu, potrebno je definirati osnovna svojstva identifikatora:

Jednoznačnost – Identifikatori moraju biti jedinstveni kako bi se korisnik mogao pozitivno identificirati (predstaviti). Identifikator mora biti globalan - to znači, da identifikator mora pripadati jednom korisniku unutar cijelog sustava. Bilo koji specifični korisnik mora imati samo jedan identifikator, iako on provodi mnoge uloge u organizaciji. To pojednostavljuje povezivanje, kako za korisnika tako i za informacijski sustav, izdavanje i upravljanje identitetom, te smanjuje konfuziju u praćenju i kontroli korisnika koja sredstva koristi.

Između pojedinaca i identifikatora mora postojati relacija jedan prema jedan. To osigurava pojedinačnu odgovornost, te potvrđuje da je to osoba koja je predstavljena identifikatorom. Identifikatori se ne smiju dijeliti jer u tom slučaju nije moguća promocija osobne odgovornosti. To je posebno važno za kontrolu pristupa informacijama visokog integriteta i tajnosti. Kriva identifikacija je česti problem čak i u fizičkom svijetu. Identifikacija postaje još teža u elektroničkom svijetu gdje identifikacija mora biti formalna i specifična. Zbog toga je potrebno voditi jedinstvenu centraliziranu evidenciju o izdanim identifikatorima, odnosno certifikatima vezanima za te identifikatore.

Univerzalnost – Ista vrsta (tip) identifikatora treba biti raspoloživa za sve korisnike – pojedince, sustave, ili programe – sve što zahtjeva pristup informacijama. To pojednostavljuje proces verifikacije identifikatora i njegovo elektroničko pohranjivanje, te dozvoljava da svi korisnici budu kontrolirani na isti način budući da imaju identifikator istog tipa i formata.

Identifikatori ne smiju biti kontekstno-zavisni, to znači da se ne smiju razlikovati od okoline do okoline primjene. Jedan identifikator će identificirati korisnika bilo gdje za bilo koji razlog primjene. To ne znači da neće biti postupaka verifikacije identifikatora koji će se zasnivati na specifičnim situacijama.

Autorizacija (verifikacija autentikacije) – Treba postojati jednostavan i standardiziran postupak provjere identifikatora radi jednostavnosti arhitekture standardnog sučelja. Postupak verifikacije mora biti raspoloživ, budući da bez verifikacije identiteta nema


dodjele ovlaštenja. Ponekad postoji potreba višestruke verifikacije u različitim vremenima kako bi se postigao viši stupanj jamstva u identitet ili u slučaju kad postoji sumnja da je neka od metoda verifikacije kompromitirana.

Nekrivotvorljivost – Identifikator mora biti otporan na krivotvorenje kako bi se spriječilo krivo predstavljanje. Identifikatori koji se fizički kontroliraju (identifikatori poslovnih subjekata koji se autenticiraju od strane sigurnosnog osoblja) trebaju sprečavati vizualno krivotvorenje. Korištenje holograma, koji su teški za krivotvorenje i skupi za reprodukciju je često korišteno rješenje u već postojećim sustavima. Elektronički identitet ima različit skup svojstava koje treba razmotriti budući se autentikacija (provjera) i autorizacija (verifikacija) provode elektronički. Koriste se kriptografske metode kako bi se uklonili napadi ponavljanja (reproduciranja) i elektroničkog krivotvorenja.

Prenosivost – Identifikator mora biti prenosiv sa lokacije na lokaciju sa kojih korisnik treba pristup. Ipak, postoje mnoge stvari koje čine prenosivost teškom. Zavisnost o infrastrukturi sprečava prenosivost na onim lokacijama gdje ne postoji infrastruktura.

Lakoća korištenja – Identifikator mora biti jednostavan za korištenje u svim transakcijama koje ga zahtijevaju. Njegova zavisnost o infrastrukturi – specijalni kartični čitači, operacijski sustavi računala, i dr. – će otežati njegov prihvat te ga može učiniti potpuno neupotrebljivim, osim ako organizacija nije spremna osigurati potrebnu infrastrukturu.

1.2.2 Utvrđivanje načina isporuke usluge korisnicima

Prilikom zahtjeva za utvrđivanjem identiteta, privatne i pravne osobe komuniciraju sa centralnim sustavom korištenjem sigurnosnih algoritama. Povratna informacija (traženi podaci) može se objaviti javno ili privatno. Javno dostupni podaci ne moraju se nužno slati sigurnim komunikacijskim kanalom i korištenjem kriptiranja. Privatni podaci se mogu prikazati na terminalnom uređaju sa kojeg je stigao zahtjev (ako se radi od odgovoru na zahtjev u realnom vremenu), odnosno, putem sigurne adrese e-pošte. U ovom slučaju je potrebno uzeti u obzir i mogućnost da korisnik nema pristup sigurnoj adresi e-pošte, pa je potrebno tražene podatke poslati na adresu korisnika pismenim putem.

Za slanje privatnih poruka koristi se infrastruktura javnog ključa (PKI). To je sustav (infrastruktura) koji koristi certifikate koji su zasnovani na kriptografiji javnog ključa za autentikaciju identifikatora. Kriptografija javnog ključa se zasniva na kriptografskoj metodi koja koristi dva međuzavisna ključa. Što se kriptira sa jednim ključem može se dekriptirati samo sa drugim ključem. U ovoj metodi jedan ključ je javni, a drugi je privatni. Kako bi se poslala privatna poruka nekome, potrebno je poruku kriptirati sa njegovim javnim ključem, a time bi primatelj


mogao dekriptirati poruku primjenom svog privatnog ključa. Za dokaz identiteta, pojedinac može kriptirati poruku sa privatnim ključem, a svatko je može dekriptirati sa javnim ključem pošiljaoca čime se osigurava potvrda identiteta onoga koji je poslao poruku, budući taj ključ posjeduje samo autorizirani korisnik.

Prilikom oblikovanja okvira za informiranje korisnika o statusu transakcija treba uzeti u obzir i sljedeća pitanja:

Da li će korisničke grupe biti sposobne koristiti potrebne tehnologije?;

Da li će korisnička grupa pristupati sustavu sa istog računala (npr. mnogi korisnici jednog računala u kućanstvu)?;

Koliko će tehnologija ovjere vjerodostojnosti koštati korisnika (uključujući bilo kakvu potrebnu dogradnju tehnologije u osobnom vlasništvu)? Mogu li si korisnici priuštiti to?;

Koliko je znanja i truda potrebno uložiti u osposobljavanje korisnika za korištenje sustava?;

Da li korisnici vide u autentikacijskom procesu dovoljnu sigurnost i da li je upravljanje njihovim rizicima učinkovito?;

Kakav je općenit pogled korisnika na pouzdanost sustava i važnost rizika?

1.2.3 Definiranje zahtjeva za integritetom informacija

Tehnike za integritet podataka (data integrity techniques) su sigurnosni servisi kojima je cilj spriječiti neautoriziranu promjenu poruke (odnosno sadržaj podataka). U modernoj kriptografiji integritet podataka je blisko povezan i proizlazi iz klasičnog pojma u komunikacijama: koda za otkrivanje grešaka (error-detection code). Kod za otkrivanje pogrešaka podrazumijeva razne procedure za otkrivanje pogrešaka koje su promijenile poruku zbog greški u komunikaciji. Smatra se da je korištenje informacija, koje su promijenjene na zlonamjeran način, jednako rizično kao i korištenje informacija koje su defektne zbog grešaka u komunikaciji ili obradi podataka. Zbog toga su principi rada tehnika za osiguranje integriteta podataka i tehnika za osiguranje otkrivanja pogrešaka u osnovi isti. Naime pošiljatelj poruke napravi kontrolnu vrijednost (check value) kodirajući određenu zalihost poruke i doda tu kontrolnu vrijednost samoj poruci. Primatelj poruke provjerava ispravnost primljene poruke na temelju provjere kontrolne vrijednosti i pravila kodiranja koje je prije dogovorio s pošiljateljem poruke.

Kriptografske transformacije u sklopu tehnika za osiguranje integriteta podataka, slično enkripcijskim algoritmima, koriste za šifriranje ključeve. Na osnovi ključa, primatelj poruke kod


provjere korektnosti poruke može jednoznačno znati tko mu je poslao poruku tj. tko je kreirao zaštitu integriteta podatka. Kao posljedica nastojanja da se spriječi adaptivni napadač kod kriptografskih tehnika s javnim ključem, uvodi se integritet podataka bez izvora identifikacije (data integrity without source identification) gdje se gubi informacija tko je poruku poslao, ali je primatelj poruke siguran (koliko može biti siguran) da nitko nije istu zloupotrijebio.

1.2.4 Definiranje funkcionalnih zahtjeva za upravljanje autorizacijama

Administriranje identifikatora uključuje kreiranje i opoziv identifikatora, proces distribucije identifikatora, te integraciju identifikatora u autentikaciju, autorizaciju i administraciju sustava (NIAAAS). Problem upravljanja imenima uključuje mogućnost kreiranja jedinstvenih imena i njihovu distribuciju kroz usluge imena do sustava koji ih zahtijevaju. Distribuirani dio usluge (servisa) imena se obično odnosi na upravljanje direktorijima (directory management) - LDAP. To je postupak stvaranja direktorija identifikatora koji su tada raspoloživi procesima koji ih trebaju.

Centralizirana administracija – Centralizirana administracija identifikatora dozvoljava bolju kontrolu istih. To pomaže kontroli jedinstvenosti i univerzalnosti identifikatora. Također, dobivamo specifičan postupak verifikacije identifikatora. Ipak, postajanje samo jednog autoriteta za identifikatore može produljiti vrijeme za njegovo izdavanje. To može usporiti proces autentikacije identifikatora.

Distribuirana administracija – Distribuirano izdavanje identifikatora čini izdavanje identifikatora lakšim, posebno ako se želi fizička verifikacija. Distribuirana identifikacija smanjuje iznos vremena za dobivanje identifikatora, te može razriješiti specifičnosti izdavanja za pojedinu lokaciju. Ipak, ona može otežati održavanje standarda za verificiranje budući da svaka lokacija implementira proces na svoj vlastiti način. Distribuirana administracija prouzrokuje lokalne poslove, a može i delegirati ovlasti administriranja. Ona traži i uspostavu sinkronizacije kako promjene napreduju kroz sustav. Također, povećava se broj administratora koji mogu zlorabiti sustave.

1.2.5 Utvrđivanje mogućih problema u funkcioniranju sustava

Identifikacija mogućih uskih grla u funkcioniranju sustava odnosi se prvenstveno na neprihvaćanje dijela javnosti (potencijalnih korisnika) prema novom sustavu koji uzrokuje djelomične promjene u postojećim poslovnim procesima funkcioniranja pojedinih tijela državne uprave, ali i otporu dijela korisnika prema novim tehnologijama, te je stoga izuzetno bitna priprema i edukacija javnosti (potencijalnih korisnika) vezana za rad sustava e-uprave i prednosti korištenje elektroničke autentikacije i autorizacije pri prijavi u sustav. Također, mogući problem u funkcioniranju sustava mogu predstavljati i građani s dvojnim državljanstvom.


Osim toga, s tehničkog aspekta projekta, da bi se izbjegla moguća uska grla potrebno je uvođenje širokopojasnog Interneta u cijelu Hrvatsku, omogućavanje povoljnije nabavke čitača pametnih kartica (koja bi trebala prvi puta biti besplatna, odnosno ne bi trebala uvoditi dodatne troškove gledano sa strane korisnika) i ostale opreme potrebne za funkcioniranje krajnjih korisnika.

Glavni rizici i pitanja koja se tiču funkcioniranja cjelokupnog sustava autentikacije uključuju: Pitanja građanskih prava

o Ukoliko se odabere vrlo nametljiv pristup autentikaciji, što može uzrokovati značajnu negativnu javnu reakciju pokreta koji zagovaraju građanske slobode i vjerojatno će donijeti negativne reakcije šire javnosti.

o Moguća percepcija javnosti da je uvođenje elektronske provjere identiteta dodatno potraživanje na njih od strane Vlade.

o Percepcija gubitka privatnosti ili građanskih sloboda može dovesti do gubitka povjerenja u autentikaciju i ometati ukupni sustav transakcija.

o Implementacija sustava autentikacije može dovesti do korisničke zbunjenosti i nezadovoljstva u nekim sektorima.

o U razmatranju prijedloga rješenja, teško je zadovoljiti sve strane, ali nužno je riješiti potencijalno kontroverzna pitanja.

Pravna pitanja o Ključno rizično područje, koje će vjerojatno dovesti do pitanja privatnosti u

elektroničkom autenticiranju, sigurnosti modela prijave, ali i pogreške i netočnosti u podacima i sistemima.

o Financijski gubitak se može pojaviti ako transakcija ne uspije ili ako je prihvaćena lažna transakcija.

Međunarodna pitanja o Ako se provjera identiteta odnosi i na međunarodne transakcije, mogući su

problemi zbog proturječnih standarda i nemogućnosti uspostave povjerenja među različitim sustavima za upravljanje identitetima korisnika.

Sigurnost o Nužne su odgovarajuće sigurnosne arhitekture kako bi se isporučila potrebna

razina sigurnosti namijenjena i za sprečavanje gubitka integriteta poruka, krađa identiteta i softverskih napada na sustav.

o Problem zloupotrebe sustava ili podataka od strane osoblja pružatelja usluge (pojedinih tijela državne uprave).

o Fizički rizik za pojedinca koji se može pojaviti kao posljedica ozbiljnih kršenja pitanja privatnosti, kao što je slučaj s postojećim sustavima vlasti koje drže osobne podatke.


1.3 Definicija sustava identifikacije

Faktori koji se mogu koristiti za autentikaciju identiteta nekog entiteta su oni faktori koji su jedinstveni za taj specifični entitet. Faktori moraju biti poznati i isporučivi kako entitetu koji se autenticira tako i procesu koji provodi autentikaciju entiteta.

Osnovni faktori koji se koriste u autentikaciji, a koji su raspoloživi svim tipovima entiteta:

Nešto što znate – dijeljena tajna, lozinka, nešto što korisnik i autentikator znaju. Autentikacija lozinkom je relativno jeftina i lagana za implementaciju, te je to razlog što gotovo svi sustavi provode autentikaciju upotrebom lozinki. Zajednički problem lozinki je slaba sigurnost – ako ih korisnici odabiru, one su nedovoljno duge, nedovoljno slučajne, te se ne mijenjaju dovoljno često, kako bi bile sigurne. Pored toga, mnogi sustavi ne spremaju lozinke u dovoljno sigurne lokacije ili sa dovoljno jakom zaštitom kako bi se spriječio uobičajeni napad lozinke.

Nešto što imate – fizički identifikator (npr. identifikacijska kartica, token, smart kartica).

Nešto što jeste – mjerljiva svojstva (otisak prsta, facijalne karakteristike, boja glasa). Mjerenje fizičkih svojstava se naziva biometrija. Ako je entitet koji se autenticira program ili sustav, mjerenje se može odnositi na kriptografsku kontrolnu sumu (checksum, hash vrijednost).

Osim osnovnih faktora moguće je definirati i implicitne faktore. Implicitni faktori su atributi entiteta koji se mogu odrediti bez interakcije sa entitetom. Najznačajniji implicitni faktor je lokacija. Poznavajući gdje se pojedini entitet nalazi, može implicirati da je on prošao već neke druge sigurnosne kontrole. Ako je korisnik u uredu tvrtke, tada postoji veliko očekivanje da je on legitiman korisnik. To je tzv. "gdje si ti" faktor.

Fizička lokacija – Poznavajući fizičku lokaciju entiteta povećava se vjerojatnost da je entitet povjerljiv. Ako je korisnik u sigurnom području, tada je za očekivati da je prošao fizičke sigurnosne kontrole. Ideja je da ukoliko je osoba prošla sigurnosnu kontrolu, da je ona autenticirana.

Logička lokacija – Logička lokacija se koristi na sličan način. Ako je korisnik na internoj mreži, tada je za očekivati da je on u sigurnoj lokaciji. Mogućnost identifikacije računala daje mogućnost indikacije da li osoba pristupa sustavu sa svog osobnog računala. To također povećava vjerojatnost da je osoba to što kaže da je.


Najsigurnije je korištenje višestrukih faktora pri autentikaciji. Općenito korištenje više faktora u autentikaciji transakcija daje jaču autentikaciju. Primjer autentikacije sa dva faktora je kombinacija biometrije (fotografije) i bankovne kartice, što je fizički ID koji zahtjeva lozinku ili PIN se koristi cijelo vrijeme.

Takav sustav mora obuhvatiti:

Autentikaciju i autorizaciju - osiguranje da su krajnji korisnici oni koji što tvrde da jesu i da imaju pravo na pristup određenoj usluzi ili skupu usluga.

Jedinstvene autentikacijske faktore – korisnici imaju jedan korisnički račun (ili neku dodatnu sigurnosnu frazu), ili digitalni certifikat, za upotrebu u svim on-line javnim uslugama.

Integritet poruka – jamči se pouzdana komunikacija i isporuka dokumenata i poruka između pojedinih servisa tijela državne uprave te pojedinaca i organizacija, uključujući i opciju prilagodbe i integracije postojećih sustava i aplikacija.

Sigurnost - u skladu s preporukama Europske komisije, potrebno je osigurati visoku razinu sigurnosti, zaštitu privatnosti i sl.

1.3.1 Zahtjev za jednoznačnim utvrđivanjem identiteta i tipa korisnika

Jednoznačno utvrđivanje identiteta moguće je ostvariti upotrebom jednog ili više od sljedećih predloženih autentikacijskih mehanizama.

Korisničko ime / lozinka, PIN, tajni odgovor

Najčešći se autentikacijski procesi temelje na jednom ili više faktora koji su poznati korisniku, ali da su takvi podaci tajna, npr. lozinka i PIN. Prednosti tih metoda su da su relativno jeftine i jednostavne za postavljanje, i zahtijevaju malo obrazovanje korisnika zbog familijarnosti s takvim procesima. Lozinka ili PIN su relativno jednostavni za zamijeniti ako su ugroženi ili izgubljeni. Sustavi koji koriste lozinke će se također tipično zaključati korisnički račun ako je unesena pogrešna lozinka više od definiranog broja puta, u procesu prijave. Prijava u sustav pomoću PIN-a se često koristi u kombinaciji sa 'nečim što imamo', npr. kreditnom karticom.

Najveći nedostatak lozinki i PIN-ova je da oni ne nude vrlo visoku razinu sigurnosti. Većina korisnika obično odabere jednostavne lozinke koje se lako pogoditi (kao što je njihovo ime, datum rođenja, ili ime kućnog ljubimca), a to je relativno lako 'probiti'. Ovaj rizik može biti


ublažen strožom politikom izbora lozinki (npr. zahtijeva se najmanje osam znakova, uključujući i brojke i slova, te provjera da takva lozinka prije nije bio iskorištena kod nekog drugog korisnika). Korisnici također imaju tendenciju da zaborave svoje lozinke. Najčešći uzrok je da sustav generira lozinke koje je teško zapamtiti. Službe za korisnike često koriste unaprijed dogovoreno "tajno pitanje" (npr. majčino djevojačko ime, ili poseban identifikator) za potvrdu identiteta korisnika koji tvrdi da je zaboravio svoju lozinku.

Daljnji rizik lozinka je da su često dijele. Prečesto korisnici također pohranjuju lozinke na nesiguran način ili na nesigurna mjesta (npr. na post-it zabilješke nalijepljene na računalo). Također, događa se da se lozinke dijele unutar kruga ljudi (poslovni suradnici, obitelj).

Infrastruktura javnog ključa (Public Key Infrastructure, PKI) i digitalni certifikati

PKI infrastruktura čini široko korištenje javnog ključa za šifriranje mogućim kroz korištenje digitalno potpisanih certifikata, tzv. digitalnih potvrda. Svaki korisnik generira ključ za šifriranje, koji je pohranjen bilo softverski, bilo sklopovski; ovakav privatni ključ se može koristiti za potpisivanje (ovlašćivanje) transakcija. Digitalni certifikat sadrži javni ključ koji je matematičkim algoritmima povezan sa privatnim ključem pojedinca. To znači da se korisnik može koristiti svojim privatnim ključem (i niti jednim drugim ključem) za dešifriranje i čitanje poruka koje su šifrirane s javnim ključem, dok pružatelj usluge koji prima transakciju može koristiti javni ključ korisnika (i niti jedan drugi ključ) u digitalnom certifikatu za provjeru da je privatni ključ dotičnog korisnika potpisao transakciju.

Još uvijek postoje rizici oko korištenja PKI, posebice oko sigurnosti privatnih ključeva i vjerodostojnosti inicijalne provjere od strane registracijske agencije. Iako PKI ne omogućuje krivotvorenje privatnih ključeva, ne može se razabrati tko zapravo koristi koji ključ. Slaba sigurnost oko čuvanja privatnih ključeva (naročito kad su pohranjeni na računalima) mogu ozbiljno ugroziti razinu autentikacije koju zapravo pružaju PKI rješenja.

Softverski pohranjeni ključevi

Softverski bazirano pohranjivanje ključeva privatni ključ pohranjuje na disk, te koristi šifriranje da bi se privatni ključ zadržao povjerljivim. Za pristup privatnom ključu potrebni su lozinka ili PIN. (Privatni ključ je pohranjen u šifriranom obliku na disku i lozinke se koriste za njegovo dešifriranje.) Ovaj pristup nudi veću sigurnost nego samo lozinka ili PIN. Glavni nedostaci su određeni sa cijenom i fizičkom sigurnošću diska. Dodatni softver mora biti kupljen i instaliran na svako računalo na kojem se koristi, a digitalni certifikati koji sadrže javne ključeve su također skupi. Postoje i dodatni sigurnosni rizici - privatni ključevi mogu biti ukradeni ili izbrisani dobivanjem pristupa na PC (i lozinke), a mogu se izgubiti zbog softverskih ili hardverskih problema. Softverski pohranjeni ključevi mogu se dijeliti bez znanja sustava. Većina računalnih


aplikacija nema ugrađenu podršku za autentikaciju ključevima koji se koriste u digitalnim certifikatima.

Sklopovski pohranjeni ključevi

Ova kategorija autentikacijskog mehanizma pokriva raspon opcija, a sve se temelje na korištenju fizičkog uređaja (obično se naziva 'token') na kojem je pohranjen privatni ključ i odgovarajući digitalni certifikat. Ovaj pristup ima prednosti pred softverski pohranjenim ključevima kroz povećanu robusnost i razinu sigurnosti. Certifikati su jednostavni za korištenje, a mogu općenito biti dopunjeni lozinkom ili PIN-om koji je potreban za pristup informacijama pohranjenim u tokenu (npr. pametna kartica s PIN-om). Za razliku od softverski pohranjenih ključeva, tajna informacija nije pohranjena na računalu koji može biti ranjiv na napad, ali uvijek putuje s korisnikom. Stoga se može koristiti na bilo kojoj lokaciji koja ima odgovarajući čitač tokena.

Kao i softverski bazirano pohranjivanje ključeva, i sklopovski bazirano pohranjivanje ključeva je relativno skupo i zahtijeva softver koji će ih je provjeriti. Neki sklopovski uređaji kao što su pametne kartice također zahtijevaju dodatni čitač da bi se kartica uopće mogla pročitati. Token može biti zaboravljen, izgubljen, ukraden ili pogrešno postavljen. Kao i lozinke, i tokeni se mogu dijeliti. Tehničke poteškoće mogu nastati, budući da većina računalnih programi nema izvornu podršku bilo za provjeru vlasništva takvih uređaja, bilo autentikaciju ključevima koji se koriste u digitalnim certifikatima.

Digitalni certifikati

Digitalni certifikati su autentikacijski mehanizam pomoću javnog ključa za šifriranje. Digitalne certifikate izdaju CA koje vrše početnu identifikaciju nositelja certifikata i jamče za izdani certifikat. Korisnik šalje svoj javni ključ i dokaz identiteta CA. Ako su zadovoljeni uvjeti identifikacije, onda će CA izdati digitalni certifikat koji sadrži javni ključ korisnika. U stvari, certifikat je transakcija s okolinom, 'ovlaštena' korištenjem vlastitog privatnog ključa od CA. Tipično, komercijalni CA će se izdati više od jedne klase certifikata. Klase se razlikuju po količini podataka s kojima CA potvrđuju identitet korisnika.

Certifikati mogu biti izdati od strane javnih poduzeća ili tijela državne uprave koje je osnovano kao CA, ili pojedine agencije mogu preuzeti ulogu CA direktno za svoje djelatnike. U oba slučaja, postoji potreba za odgovarajuće priznanje CA prije izdaje certifikata koje treba biti prihvaćeno od bilo koje strane u sustavu. Takvi certifikati su relativno skupi.

Šifriranje javnim ključem


Kao što je već prije navedeno, javni ključ za šifriranje, se razlikuje od normalnog šifriranja u tome što koristi par ključeva. Dva ključa u svakom paru imaju takav odnos da se poruku koja je kodirana s jednim ključem može dešifrirati samo sa drugim ključem.

Izdavanjem jednog ključa - čineći ga 'javnim' i tajenjem drugog ključa – čineći ga 'privatnim' osoba koja generira ključeve može primati povjerljive poruke i potpisati transakcije. PKI infrastruktura pruža potvrdu da je pojedini javni ključ od dotičnog korisnika.

Biometrija

Biometrija se odnosi se na provjeru procesa koji se temelje na identifikaciji pojedinaca pomoću jedinstvene ljudske osobine, kao što su otisci prstiju, skeniranje mrežnice, prepoznavanje lica, prepoznavanje glasa. Biometrija nudi visok stupanj sigurnosti, i ne može se dijeliti s drugom osobom. Gotovo je nemoguće izgubiti biometrijski identifikator, niti ga je moguće zaboraviti. Biometrijski faktori se nalaze sa svojim vlasnikom cijelo vrijeme, tako da su vrlo lako prenosivi. Najveći nedostatak biometrijske autentikacije je da obično zahtijeva specijalizirane uređaje koji još uvijek nisu široko rasprostranjeni i dostupni te se još ni ne smatraju 100% točnima. Tu su također i pitanja privatnosti i kulturne prihvatljivosti oko nekih biometrijskih postupaka, jer se neki vežu uz otkrivanje kriminalne aktivnosti (npr. otisak prsta). Biometrijska autentikacija je obično skupa, ali niti ona nije potpuno sigurna jer se prikupljeni biometrijski podaci uspoređuju s onima u bazi pri čemu može doći do greške, namjerne zamjene i sl.

1.3.2 Utvrđivanje načina uspostave integriranog sustava identifikacije

Identifikacija mora biti raspoloživa za sve pristupne metode. Ona mora biti zasnovana u uvjetima radne okoline tvrtke kako bi se zadovoljila jedinstvenost imena, te mora biti zasnovana na infrastrukturi javnih ključeva za elektroničku verifikaciju (PKI).

Integrirani sustav identifikacije mora nužno imati jedinstveno imenovanje (označavanje) identifikatora. Standardi imenovanja su izgrađeni na X509 OSI standardu za usluge imenika (directory service). X509 definira strukturu direktorija koja je u biti hijerarhijska, te koristi parove vrijednosti ključnih riječi. On definira LDAP (Light-weight Directory Access Protocol) pristupni korisnik/poslužitelj protokol koji se koristi kada se kontaktiraju serveri za imenike (direktorije) sa identifikatorima.

Usluga imenika (directory service) je proces koji se koristi za upravljanje jedinstvenim imenima za koja se zahtjeva da imaju jedinstvene identifikatore. To zahtjeva centralni registar koji sadrži korisničku informaciju kao što su identifikator, javni ključ, digitalni certifikat, te druge informacije. Integracija u postojeće sustave koji direktno ne podržavaju LDAP zahtjeva uvođenje LDAP u poveznike (gateway) za usluge imenovanja.


U uspostavljanju integriranog sustava identifikacije i autorizacije moguće su četiri konceptualne opcije koje obuhvaćaju praktične varijacije pružanja provjere i koja su primijenjena u drugim sustavima:

1) Jedna centralna autorizacijska agencija verificira i potvrđuje identitet pojedinaca. Cijeli skup osobnih podataka o pojedincima se dijeli u trenutku kad se odvija transakcija između tijela državne uprave koje pruža uslugu i autorizacijske agencije.

2) Jedna centralna autorizacijska agencija verificira i potvrđuje identitet pojedinaca. Samo dio osobnih podataka o pojedincima se dijeli u trenutku kad se odvija transakcija između tijela državne uprave koje pruža uslugu i autorizacijske agencije.

3) Višestruko odobrene autorizacijske agencije verificiraju i potvrđuju identitet pojedinaca. Cijeli skup osobnih podataka o pojedincima se dijeli u trenutku kad se odvija transakcija između tijela državne uprave koje pruža uslugu i autorizacijske agencije za tu transakciju.

4) Svaka agencija upravlja provjerom svojih klijenata u skladu sa skupom propisanih standarda i korištenje obaveznih procesa i tehnologija.

Autentikacija u distribuiranim sustavima se odvija putem protokola. Protokol je precizno definiran slijed komunikacijskih koraka i računskih operacija. Komunikacijski koraci prenose poruke od jednog pružatelja usluge do drugog, dok računske operacije ažuriraju unutarnje stanje pružatelja usluge. Nakon završetka protokola moguća su dva ishoda. Jedan označava da je autentikacija uspješno obavljena, dok drugi označava neuspjeh.

Rezultat svake autentikacije je ovisan o samome protokolu kojim se provodi. Na primjer autentikacija prilikom uspostave komunikacijske veze rezultira izmjenom ključa sesije, dok autentikacija prilikom prijave na računalo rezultira stvaranjem novog procesa u ime korisnika koji se prijavio.

Autentikacijski okvir predstavlja skup autentikacijskih procedura koje su nužne u izgradnji sigurnog distribuiranog sustava. Te procedure se mogu podijeliti u slijedeće skupine:

Inicijalizacija host-ova. Svi procesi se izvršavaju isključivo unutar host-a (host predstavlja računalni sustav na kojem se izvršavaju usluge pojedinog tijela državne ili lokalne uprave). Neki host-ovi (npr. radne stanice) se ponašaju kao ulazne točke u sustav na način da omogućavaju korisnicima prijavljivanje na sustav. Cjelokupna sigurnost distribuiranog sustava je izravno ovisna o sigurnosti svakog host-a zasebno. U slučaju otvorene mreže nije moguće svakog host-a fizički zaštititi, stoga je potrebno osigurati programsku zaštitu zahtijevane razine. Prilikom inicijalizacije host-a potrebno je pokrenuti sve pripadajuće programe koji omogućuju sigurnu autentikaciju host-a u sustav.


Prijava korisnika. Identitet korisnika se utvrđuje prilikom prijave na sustav. Sve naknadne aktivnosti se odnose na taj identitet. Stoga je vrlo važno da identifikacija korisnika bude što je moguće sigurnija i točnija. Također treba paziti da autentikacija korisnika na određenom host-u bude obostrana, jer korisnik ne može biti siguran da identitet host-a nije narušen, pogotovo ako se radi o otvorenoj mreži.

Peer-to-peer komunikacija (komunikacija između točaka sustava). Distribuirani sustavi mogu distribuirati izvršavanje određenog zadatka na više različitih host-ova. Korektno izvršavanje ovakvog zadatka je moguće samo ako procesi međusobno mogu jednoznačno odrediti identitet. U ovakvim slučajevima se također koristi autentikacija između pojedinih procesa.

Komunikacija unutar domene. Kod većine distribuiranih sustava ne postoji centralizirana administracija. Za primjer možemo uzeti fakultetski sustav koji se sastoji od više zavodskih podsustava koji su zasebno administrirani. Identifikacija principala kroz podsustave zahtijeva dodatne autentikacijske mehanizme unutar domena.

Primjer distribuiranog sustava sa autentikacijom prikazan je na slici 2.


Slika 2. Primjer distribuiranog sustava sa autentikacijom

Sustav se sastoji od servera punjenja i evidencije usluga, autentikacijskog servera i više host-ova. Svi protokoli koji se koriste za autentikaciju podrazumijevaju upotrebu algoritama za kriptiranje. Prijava korisnika na sustav se odvija putem pametne kartice koja omogućava digitalni potpis i jedinstven identifikator korisnika. Server punjenja i evidencije usluga i autentikacijski server su fizički osigurani što znači da se nalaze na fizički sigurnom mjestu (npr. unutar neke zaključane prostorije i sl.) i ne postoje korisnički računi na tim računalima. Server punjenja i evidencije usluga se koristi za autentikaciju host-a prilikom inicijalizacije. Server sadrži bazu podataka sa informacijama o pojedinom host-u.


Autentikacijski server sadrži podatke o svakom korisniku, tj. za svakog korisnika se čuvaju podaci o njegovoj pametnoj kartici, te za svaki udaljeni server se čuvaju kriptografski javni ključevi. Ovo je primjer pojednostavljenog sustava u kojem su server punjenja i evidencije usluga i autentikacijski server na centraliziranoj lokaciji. Decentralizirani sustavi zahtijevaju još jedan autentikacijski server između.

Autentikacija u distribuiranom sustavu se može opisati sa tri glavna protokola:

Sigurni protokol punjenja host-a pružatelja usluge koristi se prilikom inicijalizacije host-ova da bi se host inicijalizirao u dobro definirano stanje rada kako bi mogao sigurno obavljati zadatke.

Korisnik-host protokol pokriva potrebe korisničke prijave na sustav i omogućava dvosmjernu autentikaciju između korisnika i host-a.

Autentikacijski protokol između točaka sustava se koristi za autentikaciju između procesa gdje obostrano autenticira oba procesa.

Klijent-poslužitelj autentikacija je specijalan oblik autentikacije između točaka sustava pa je stoga nije potrebno posebno objašnjavati.

Ovi protokoli su međusobno povezani na način da se informacija dobivena od jednog protokola koristi kod drugog protokola. Prema slici 3. vidljivo je da licenca host-a generirana prilikom sigurne inicijalizacije hosta putem sigurnog protokola punjenja host-a pružatelja usluge služi prilikom generiranja certifikata prijave u korisnik-host protokolu.

Prikaz njihovog međusobnog odnosa se nalazi na slici 3.


Slika 3. Autentikacija u distribuiranom sustavu


2 SMJERNICE ZA PROVEDBU PROJEKTA

Smjernice za provedbu projekta nadovezuju se na okvir za provedbu projekta i temeljene su na izradi snimke okruženja. Ovo poglavlje obuhvaća definiranje svojstava sustava, upravljanje pravima pristupa te snimku i prilagodbu međunarodne prakse.

Pri implementaciji sustava i u samim sustavima moraju se primjenjivati sigurnosne mjere opisane u normi ISO 27001.

2.1 Sigurnosne razine u autentikacijskom procesu

Autentikacija može imati različita značenja ovisno o kontekstu u kojem se pojam koristi. Široki raspon značenja vezan je za rješavanje različitih provjera autentičnosti fizičkih i pravnih osoba, adresiranja podataka, dokumenta i drugih dijelova sustava. U skladu s ovim značenjem, ovjera se postiže kroz procese koji imaju različite stupnjeve detalja identiteta i tehničkih specifičnosti. Ovi procesi imaju za cilj utvrđivanje da li je netko ili nešto ono što tvrdi da je, odnosno ono za što se predstavlja. Kao takva, autentikacija predstavlja ključni doprinos uspostavljanju odnosa povjerenja u digitalnom okruženju. Autorizacija ima funkciju utvrđivanja valjanosti autentikacije i potvrdu tvrdnje identiteta korisnika,entiteta ili druge pravne osobe u informacijskom sustavu. Ovakva definicija autentikacije i autorizacije može se opisati kao dva slijedna procesa sa jednim zajedničkim rezultatom:

Prilikom autentikacije prilaže se (odnosno šalje nekim komunikacijskim kanalom) ključ identifikacije entiteta. Slanje korisničkih podataka ne znači nužno i potvrdu da su korisnički podaci ispravni i da će zahtjev za autorizacijom biti prihvaćen.

Zahtjev za autentikacijom se pokušava autorizirati od strane nositelja certifikata.

U cilju definiranja potreba određenih usluga za načinom autorizacije te potrebnom infrastrukturnom podrškom u okviru ovog dokumenta predlažemo klasifikaciju sigurnosnih razina. Prijedlog je da za sve usluge koje se u sustavu ostvare, nadležno tijelo ili ustanova koju tu uslugu pruža, definira potrebnu sigurnosnu razinu. Izbor sigurnosne razine uvjetovati će i način izvedbe IAA sustava a u skladu s preporukama iz ovog dokumenta.

2.1.1 Referentni model procesa autentikacije

Konceptualni prikaz cjelokupnog procesa autentikacije daje slika 4.


Slika 4. Referentni model procesa autentikacije

Slijedno prikazu sa slike 4, autentikacijski proces se može podijeliti na dvije faze: registracija korisnika i elektronička autentikacija.

1. Registracija korisnika: Proces u kojem se korisniku (fizička ili pravna osoba) dodjeljuju i isporučuju elektroničke vjerodajnice (digitalni identitet) kao što su npr. korisničko ime/zaporka ili digitalni certifikat. Dobivene vjerodajnice korisnik će koristiti u drugom koraku. Registracija se općenito sastoji od sljedećih koraka:

Dokazivanje identiteta: Provjera identiteta korisnika (bilo fizičke ili pravne osobe).

Dostavljanje elektroničkih vjerodajnica korisniku: Podatci o korisniku se spremaju u sustav te se generiraju elektroničke vjerodajnice. Generirane vjerodajnice se isporučuju korisniku.

2. Elektronička autentikacija pri korištenju usluga: Tijekom korištenja usluga elektroničke uprave, korisnik (fizička ili pravna osoba) koristi dobivene vjerodajnice s ciljem dokazivanja svoga identiteta. Konceptualno, korak elektroničke autentikacije se može opisati u sljedećim koracima:


Predstavljanje vjerodajnica: Korisnik se identificira korištenjem autorizacijskih vjerodajnica. Verifikaciju autorizacija obavlja verifikacijski entitet.

Dostavljanje atributa: Verifikacijski entitet dostavlja atribute korisnika (ne moraju nužno biti samo autorizacijski atributi) autorizacijskom sučelju elektroničke usluge.

Pod pojmom autentikacije podrazumijeva se proces uspostavljanja veze između stvarnog i elektroničkog identiteta. Postupak autorizacije identiteta, odnosno određivanja aktivnosti koje su mu omogućene, je odvojeni postupak koji se obavlja u procesu autorizacije (Slika 4). Odvajanje procesa registracije, autentikacije i autorizacije u posebne entitete donosi niz prednosti kao što su veće mogućnosti u očuvanju privatnosti.

Entiteti i uloge u sustavu su:

Korisnik - U fazi registracije, entitet koji želi na osnovu svoga fizičkog identiteta ostvariti pravo na elektronički identitet s ciljem korištenja elektroničkih usluga. U fazi autentikacije, entitet koji na osnovu dobivenog elektroničkog identiteta, pristupa sustavu s ciljem ostvarenja određenih usluga.

Registracijski entitet - Registracijski autoritet (RA) koji je odgovoran za verifikaciju i potvrdu fizičkog identiteta korisnika u fazi registracije, tipično kroz provjeru zakonski definiranih isprava ili kroz provjeru zapisa u bazama podataka. Registracijski entitet nakon verifikacije fizičkog entiteta pokreće postupak generiranja i dostavljana elektroničkih vjerodajnica.

Davatelj elektroničkih vjerodajnica - CSP (Credentials Service Provider) registrira fizički entitet te generira elektroničke vjerodajnice te ih međusobno povezuje. Između RA i CSP postoji definirana veza, uglavnom su RA i CSP odvojene funkcije istog entiteta. Međutim, RA može biti i dio organizacije kojoj ne pripada CSP, te u sustavu može biti i više CSP entiteta u slučaju distribuiranog sustava.

Verifikacijski entitet – VE (Verifying Entity). U postupku autenticiranih elektroničkih transakcija, ovaj entitet utvrđuje da li korisnici transakcija imaju valjane elektroničke vjerodajnice tj. da li odgovaraju njihovim identitetima. CSP i VE mogu biti isti entiteti, ali i odvojeni u slučaju distribuiranog sustava.

Autorizacijsko sučelje – U stvarnosti, ovdje može biti bilo koji entitet koji ovisi o rezultatima postupka elektroničke autentikacije pri izvođenju definiranih transakcija (Relying party). Ovaj entitet može biti stopljen sa verifikacijskim entitetom, dok su u distribuiranim sustavima odvojene komponente, pri čemu komponente koje ovise o verifikacijskom entitetu primaju od istoga autentikacijske atribute (autentikacijske tvrdnje) kroz specificirane postupke komunikacije.


Procesi u sustavu su:

Dokazivanje identiteta - Postupak utvrđivanja identiteta korisnika pri registraciji za usluge elektroničke uprave. Ovaj postupak obavlja RA, a detalji i zahtjevi ovise o autentikacijskoj razini usluge na koju se registrira.

Generiranje i dostava elektroničkih vjerodajnica - CSP registrira entitete te generira elektroničke vjerodajnice te povezuje stvarni i elektronički identitet korisnika. Nakon toga korisniku se dostavljaju vjerodajnice. Postupak i zahtjevi prema ovom postupku ovise o autentikacijskoj razini.

Elektronička autentikacija - Korisnik usluge demonstrira svoj elektronički identitet kroz dokaz o posjedovanju istoga prema VE. VE će na osnovu priloženih podataka utvrditi i povezati stvarni i elektronički identitet korisnika te proslijediti njegove autentikacijske atribute prema mjestu ostvarivanja elektroničke usluge.

Dostava atributa - Umjesto ostvarivanja elektroničke usluge (servis) će zaprimiti autentikacijske atribute (odn. općenito, atribute koji ne moraju nužno biti samo autentikacijski) od strane VE s kojim postoji odnos vjerovanja (eng. trust relationship). Dobiveni atributi koriste se za odlučivanje da li će se korisniku omogućiti ili onemogućiti korištenje navedene usluge.

Na osnovu prethodne raščlambe, u nastavku ovog dokumenta se predlaže:

1. Definicija pet sigurnosnih razina s obzirom na potencijalne rizike i štete u slučaju neodgovarajućeg korištenja autentikacijskog sustava. Analizirani rizici i pripadne štete su osnovni kriteriji koji omogućuju pružateljima elektroničkih usluga određivanje odgovarajuće razine sigurnosti, detaljno opisana u ovom poglavlju.

2. Definicija zahtjeva potrebnih za ostvarenje željene sigurnosne razine u fazi registracije korisnika, detaljno opisana u poglavlju 5.3.3.

3. Definicija zahtjeva potrebnih za ostvarenje željene sigurnosne razine u fazi autentikacije korisnika, detaljno opisana u ovom poglavlju.

2.1.2 Definicija autentikacijskih sigurnosnih razina

Sigurnosne razine definiraju stupanj sigurnosti da je korisnik ispravno povezan sa svojim elektroničkim identitetom. U tom kontekstu, autentikacijske sigurnosne razine su definirane kao rezultat zadovoljavanja niza zahtjeva koji osiguravaju dvije komponente:


prihvatljivi stupanj povjerenja u postupak dokazivanja identiteta, koji je dio faze registracije (Slika 4),

prihvatljivi stupanj povjerenja u postupak dostave elektroničkih vjerodajnica, koji je dio faze elektroničke autentikacije (Slika 4).

Na osnovu iskustava međunarodne prakse (poglavlje 2.3.1) te provedene analize, predlaže se definicija pet autentikacijskih sigurnosnih razina kako je to prikazano u tabeli 5.

Tabela 5. Prijedlog autentikacijskih sigurnosnih razina

Sigurnosna razina Opis

Razina 0 Vrlo niska sigurnosna razina Razina 1 Niska sigurnosna razina Razina 2 Srednja sigurnosna razina Razina 3 Visoka sigurnosna razina Razina 4 Vrlo visoka sigurnosna razina Najniža sigurnosna razina, razina 0, predstavlja razinu kod koje je pristup usluzi potpuno slobodan te se za ovu razinu ne trebaju izvesti nikakvi IAA mehanizmi. Postupak dokazivanja identiteta moguće je ostvariti pomoću OIB identifikatora.

Sigurnosna razina 1 namijenjena je za kontrolu i omogućavanje pristupa uslugama i podacima uz nizak stupanj zaštite. Najčešće korišten mehanizam dokazivanja identiteta ili posjedovni token na ovoj razini je korištenje korisničkog imena i lozinke (login/password).

Sigurnosna razina 2 predstavlja srednju razinu zaštite. Pored identifikacije i autentikacije korištenjem korisničkog imena i lozinke u postupku autentikacije mora se koristiti i barem jedan mehanizam dokaz posjedovanja određenog objekta od strane korisnika koji pristupa usluzi, kao što je to npr. token koji generira jednokratne lozinke.

Sigurnosna razina 3 namijenjena je uslugama koje traže visoku razinu zaštite. Ova razina zasnovana je na infrastrukturi javnog ključa (PKI).

Najviša sigurnosna razina, razina 4, predviđena je za pristup uslugama koje zahtijevaju najviši stupanj provjere. Pored infrastrukture javnog ključa na ovoj razini koriste se i biometrijske metode autentikacije ili osobnu provjeru korisnika.

Pored ove osnovne podjele, pojedine razine mogu se dodatno razraditi temeljem određenih tehnoloških rješenja koja se primjenjuju kao što je to prikazano u Tabela 6.


Tabela 6. Razrada sigurnosnih razina i korištenja tokena

Sigurnosne razine

Razina 0 Razina 0.1 Slobodan pristup bez identifikacije

Razina 0.2 Pristup na osnovu OIB identifikatora

Razina 0.3 Pristup na osnovu pseudonima

Razina 1 Razina 1.1 Korisničko ime i lozinka

Razina 1.2 Korisničko ime i jednokratna lozinka

Razina 2 Razina 2.1 Posjedovanje pametne kartice

Razina 2.2 Posjedovanje HW tokena

Razina 3 Razina 3.1 Pametna kartica sa PKI podrškom

Razina 3.2 HSM modul

Razina 4 Razina 4.1 PKI sa biometrijom otiska prsta

Tako se, na primjer, za razinu 0 može definirati i razina 0.1 kao pristup s pseudonimom. Ovaj način pristupa koristan je za usluge koje ne zahtijevaju autentikaciju no imaju potrebu korisniku koji je pristupio sustavu poslati neke povratne informacije ili pružiti mogućnost pregleda prošlih aktivnosti. Iako se pri ovakvoj razini može izvesti pristup preko korisničkog imena i lozinke, oni nisu vezani za osobu ili tvrtku te ne spadaju u razinu pristupa 1.

Na sličan način izvedba razine 1 može se ostvariti preko korisničkog imena i lozinke ali i korištenjem jednokratne lozinke (One Time Password - OTP) koja i sama može biti izvedena na razne načine.

Na razini 2 dokaz posjedovanja može biti izveden na razne načine. Tako npr. korisnik može umetanjem pametne kartice u čitač na računalu potvrditi posjedovanje kartice kao druge razine provjere. Mnoga rješenja koja spadaju u ovu razinu zasnivaju se na korištenju elektroničkog uređaja (token) koji pruža odgovor na upit poslan od strane sustava, najčešće u obliku niza brojeva koji se mogu unijeti prilikom pristupa usluzi.


Razina 3 predstavlja visoku razinu zaštite. Izvedba PKI sustava potrebnog za ovu razinu zahtjeva da su ključevi/certifikati pohranjeni u sigurnu okolinu te se za osobne potrebe uglavnom koriste procesorske pametne kartice dok se za uspostavu ove razine između dva IS koriste sklopovski sigurnosni moduli (Hardware security module - HSM).

Kako bi pokazali da čak i na najvišoj razini možemo imati brojne podrazine i opcije možemo navesti da je danas otisak prsta najčešći biometrijski parametar koji se koristi pri autorizaciji ali da postoje i drugi (rožnica, dlan,...) no da isto tako i osobnu provjeru korisnika možemo svrstati u ovu sigurnosnu razinu.

2.1.3 Utvrđivanje potrebne sigurnosne razine

Sigurnosna pouzdanost određena je svojstvima cjelokupnog autentikacijskog procesa, što znači ne samo u fazi autentikacije, nego i u fazi registracije. Zbog toga je za utvrđivanje potrebne sigurnosne razine pojedine usluge potrebno provesti:

1. Analizu rizika, njihovih pojavnosti te utjecaj na moguće štete opisan razinom ozbiljnosti. Na osnovu standardizirane referentne matrice utvrditi odgovarajuću sigurnosnu razinu kao najveću iz skupa potrebnih razina za pojedine rizike. Ovaj postupak detaljno je opisan u poglavlju 2.1.4.

2. Analizu registracijskih mehanizama, odnosno postupaka koji se dešavaju u fazi registracije. Za ostvarenje potrebne sigurnosne razine nužno je da obje faze, i registracija i operativna faza sustava, zadovoljavaju odgovarajuće zahtjeve. Ova analiza je detaljno opisana u poglavlju 5.3.3 Zahtjevi na sigurnosne razine s obzirom na fazu registracije.

3. Analizu autentikacijskih mehanizama i metoda kao što su: izbor nositelja vjerodajnica (tokena), dostava autentikacijskih atributa i mehanizmi udaljene autentikacije entiteta. Detaljan opis ove analize nalazi se u poglavlju 2.1.6.

2.1.4 Identifikacija rizika

Rizici koji se mogu pojaviti u cjelokupnom životnom ciklusu elektroničkog identiteta određuju i potrebne sigurnosne razine odnosno mehanizme rješavanja i osiguravanja od mogućih šteta. Zbog toga su ovdje analizirani rizici u kontekstu vjerojatnosti pojave štete kao posljedice pogrešnog korištenja stvarnih (u fazi registracije) i elektroničkih identiteta (u fazi elektroničke autentikacije). Kao referenca za rizike identificirane i opisane u sljedećim tablicama uzet je projekt STORK ukratko opisan u poglavlju 2.3.1.11 ovog dokumenta, te opširnije na https://www.eid-stork.eu/index.php?option=com_frontpage&Itemid=1.

Tabela 7 opisuje detektirane rizike u procesima elektroničke autentikacije.


Tabela 7. Rizici u procesima autentikacije

Rizik Tip Opis

1 Nepostojeći stvarni identitet

Nepostojeći entitet iz stvarnog svijeta dobiva elektronički identitet u sustavu.

2 Pogrešni detalji Pogrešne (lažne) informacije o klijentu će biti povezane sa elektroničkim identitetom u sustavu.

3 Ukradene vjerodajnice Nositelj vjerodajnica (token) ukraden tijekom dostave korisniku, ili ukraden i naknadno bespravno korišten s ciljem prikupljanja informacija o korisniku.

4 Krađa stvarnog identiteta U vrijeme registracije u sustav, stvarni identitet je neovlašteno predstavljen.

5 Presretanje i otkrivanje tajnih autentikacijskih podataka

Tajne informacije (PIN, tajni ključ, i sl.) su presreteni u prijenosu tijekom korištenja vjerodajnica, ili namjerno ili nenamjerno otkriveni.

6 Zadržavanje tajnih podataka u nesigurnom okruženju (terminalu)

Tajni podaci su zadržani u nesigurnom okruženju (npr. u nesigurnom terminalu).

7 Neautorizirano korištenje pristupnih vjerodajnica

Pristupne vjerodajnice verificiraju korisnika koji nije vlasnik istih, tj. čiji elektronički identitet ne odgovara stvarnom identitetu.

8 Kompromitirane vjerodajnice

Vjerodajnice se koriste u sustavu nakon trenutka kad su kompromitirane na bilo koji način.

9 Korištenje vjerodajnica pod bitno drukčijim uvjetima

Vjerodajnice su izdane (klijent registriran) pod novonastalim uvjetima koji se bitno razlikuju od uvjeta pod kojim se vjerodajnice naknadno koriste u autentikacijskoj fazi. Novonastali uvjeti uobičajeno ne bi dozvolili izdavanje vjerodajnica.

10 Korištenje vjerodajnica u druge svrhe

Vjerodajnice se koriste u svrhe za koje inicijalno, pri registraciji, nisu bile predviđene.


11 Neovlašteno korištenje vjerodajnica

Vlasnik vjerodajnica, bilo stvarni, bilo novi vlasnik koji ih je neovlašteno prikupio, koristi iste za svrhe koje nisu bile predviđene pri registraciji i izdavanju.

12 Hakerski napad Zlonamjerni vanjski entitet koristi elektroničke usluge s ciljem nelegalnog ostvarivanja dobiti, kompromitiranja sustava ili onemogućavanja normalnog funkcioniranja sustava.

13 Disperzirano spremanje povjerljivih informacija

Informacije o korisnicima su fragmentirane u sustavu te na taj način predstavljaju potencijalni rizik.

Tabela 8 prikazuje razine vjerojatnosti odnosno mogućnosti pojave određenog rizika i njegove realizacije:

Tabela 8. Razine pojavnosti rizika

Mogućnost pojave Opis

Skoro sigurna Postoji visoka razina motivacije da izvor prijetnje iskoristi određeni rizik odnosno realizira iskorištavanje rizika. Isto tako, izvor prijetnje je dovoljno sposoban da ostvari iskorištavanje rizika.

Vrlo vjerojatna Postoji visoka razina motivacije da izvor prijetnje iskoristi određeni rizik odnosno realizira iskorištavanje rizika. Isto tako, izvor prijetnje je dovoljno sposoban da ostvari iskorištavanje rizika. Međutim, postoje odgovarajuće mjere u sustavu koje onemogućavaju realizaciju rizika.

Umjereno vjerojatna Postoji srednja razina motivacije da izvor prijetnje iskoristi određeni rizik odnosno realizira iskorištavanje rizika. Isto tako, izvor prijetnje je sposoban da ostvari iskorištavanje rizika. Međutim, postoje odgovarajuće mjere u sustavu koje onemogućavaju realizaciju rizika.

Malo vjerojatna Postoji mala razina motivacije da izvor prijetnje iskoristi određeni rizik odnosno realizira iskorištavanje rizika. Postoje odgovarajuće mjere u sustavu koje onemogućavaju realizaciju rizika.


Rijetka Postoji jako mala razina motivacije da izvor prijetnje iskoristi određeni rizik odnosno realizira iskorištavanje rizika. Izvor prijetnji je nedovoljno sposoban da ostvari iskorištavanje rizika. Postoje odgovarajuće mjere u sustavu koje onemogućavaju realizaciju rizika.

Tabela 9 klasificira moguće štete nastale realizacijom, odnosno iskorištavanjem rizika u sustavu. Ova klasifikacija bi trebala poslužiti kao pomoć agencijama koje će nuditi elektroničke usluge u postupku analize istih s obzirom na utjecaj i pojavnost rizika te analizu šteta. Konačan rezultat analize bi trebao definirati zahtijevanu sigurnosnu autentikacijsku razinu pri korištenju usluge.

Tabela 9. Klasifikacija šteta koje mogu nastati iskorištavanjem rizika

Mogućnost pojave Opis

Gubitak integriteta Pod pojmom integriteta podataka podrazumijeva se zahtjev da informacije u sustavu budu zaštićene od nedozvoljenih modifikacija. Gubitak integriteta nastaje u trenutku kada se podatci mijenjaju od strane neautoriziranog entiteta, namjerno ili nenamjerno. U slučaju da navedeni gubitak nije korigiran, daljnja upotreba sustava može korumpirati cijeli sustav te eventualno dovesti i do njegovog gašenja.

Gubitak dostupnosti Osnovni zahtjev na elektroničke usluge je njegova dostupnost. Međutim, gubitak dostupnosti je šteta koja se često javlja, naročito u sustavima koji nisu dizajnirani s ciljem robusnosti na navedeni problem.

Gubitak povjerljivosti Pod pojmom povjerljivosti podrazumijeva se svojstvo sustava da čuva osobne podatke od neautoriziranog objavljivanja. Gubitak povjerljivosti u tom smislu može uzrokovati dodatne štete različite ozbiljnosti. Neovlašteno objavljivanje privatnih podataka može dovesti do gubitka povjerenja u sustav, do pravnih problema, a samim time je i funkcionalnost cjelokupnog sustava kompromitirana.


Gubitak vezan uz osobnu sigurnost

Neautorizirani pristup i čitanje privatno osjetljivih podataka može dovesti i do ugrožavanja osobne sigurnosti korisnika sustava. Primjer može biti čitanje medicinskih podataka korisnika te njihovo neautorizirano mijenjanje.

Financijski gubitak Pojedini IT sustavi su usko povezani i sa financijskim transakcijama ili sa procesima koji imaju odgovarajuću financijsku težinu. Nepravilno korištenje takovih sustava kroz neautorizirani pristup, modifikaciju ili čitanje podataka (namjerno ili nenamjerno) može dovesti do financijskih gubitaka. Isto tako, nepravilno funkcioniranje sustava zbog gore navedenih šteta, moguće je ispraviti, ali uz odgovarajuće troškove koji dakle doprinose ovoj šteti.

Konačno, Tabela 10 prikazuje razine ozbiljnosti iskorištavanja nekog rizika, odnosno štete nastale pojavom rizika:

Tabela 10. Razine ozbiljnosti

Z Zanemariva Šteta zahtjeva rutinske operacije za ispravljanje N Niska Šteta ugrožavaju funkcioniranje usluge, ispravke je moguće interno

napraviti S Srednja Šteta zahtjeva znatnu reviziju i modifikaciju usluge koja je pogođena V Visoka Šteta zahtjeva, uz znatnu reviziju i modifikaciju, intervenciju na višoj

razini J Jako visoka Šteta ozbiljno ugrožava postojanje usluge, i izaziva znatne probleme

kako klijentima tako i agenciji, zahtjeva potpunu reviziju i

2.1.5 Referentna matrica za određivanje potrebne sigurnosne razine

Na osnovu prethodnih izlaganja definiramo mjeru rizika kao vezu između razine pojavnosti (Tabela 8) i razine ozbiljnosti (Tabela 10) grešaka koje nastaju iskorištavanjem rizika. Na osnovu definirane mjere rizika, agencije pružatelji usluga mogu analizirati svoje usluge te utvrditi potrebnu razinu autentikacijske sigurnosti. Tabela 11 je referentna matrica koja omogućuje preslikavanje potencijalnih rizika u korištenju usluge i njihov utjecaj (ozbiljnost) na minimalno potrebnu sigurnosnu razinu.


Tabela 11. Referentna matrica za određivanje potrebne sigurnosne razine

Razina ozbiljnosti

Pojavnost Jako visoka J Visoka V

Srednja S

Niska N

Zanemariva Z

Rizik

Skoro sigurna * * Razina 4 Razina 3 Razina 3

Vrlo vjerojatna * Razina 4 Razina 4 Razina 3 Razina 2

Umjereno vjerojatna

Razina 4 Razina 4 Razina 3 Razina 2 Razina 1

Malo vjerojatna Razina 4 Razina 3 Razina 2 Razina 2 Razina 1

Rijetka Razina 3 Razina 3 Razina 2 Razina 1 Razina 0

* Nije primjenjivo u sustavima udaljene autentikacije korisnika

2.1.5.1 Primjer primjene referentne matrice

Kao primjer primjene referentne matrice u određivanju minimalno dovoljne sigurnosne razine uzet ćemo neku uslugu X te razmotriti potrebnu razinu sigurnosti s obzirom na moguće pojavljivanje rizika za rizike 11 (Neovlašteno korištenje vjerodajnica) i 3 (Ukradene vjerodajnice) prikazane u Tabela 7. Na osnovu provedene analize koju je izveo pružatelj usluge utvrđeno je:

Rizik 11 (Neovlašteno korištenje vjerodajnica) ima umjereno vjerojatnu mogućnost pojavnosti te zanemarivu (Z) razinu ozbiljnosti s obzirom na gubitak osobne sigurnosti (Tabela 9), nisku (N) razinu ozbiljnosti s obzirom na gubitak integriteta, dostupnosti i financijski gubitak, i visoku (V) razinu ozbiljnosti s obzirom na gubitak povjerljivosti. Na osnovu referentne matrice, utvrđena je minimalna sigurnosna razina 4 za rizik 11.

Rizik 3 (Ukradene vjerodajnice) ima rijetku pojavnost, zanemarivu (Z) ozbiljnost s obzirom na gubitak osobne sigurnosti, srednju (S) ozbiljnost s obzirom na gubitak integriteta, dostupnosti, povjerljivosti te financijske gubitke. Na osnovu referentne matrice utvrđena je minimalna sigurnosna razina 2 za navedeni rizik.

Rezultantna potrebna razina sigurnosti za uslugu X s obzirom na navedene rizike je maksimum u skupu zahtijevanih razina sigurnosti za sve analizirane rizike. To će u navedenom primjeru biti razina 4 (max(4,2)).


2.1.6 Autentikacijski mehanizmi

U kontekstu ovog poglavlja, pod pojmom autentikacijskih mehanizama podrazumijevaju se procesi i entiteti te njihova svojstva koji su karakteristični u fazi autentikacije. To obuhvaća:

tipove nositelja tajni odnosno tipove tokena kao instrumente u procesu autentikacije entiteta te njihovo korištenje u sustavu

model autentikacijskog protokola prema mogućim prijetnjama model kolanja autentikacijskih (i drugih, ne nužno autentikacijskih) atributa u sustavu.

2.1.6.1 Tipovi tokena

U ovom poglavlju opisani su tipovi tokena (nositelja informacija potrebnih za utvrđivanje elektroničkog identiteta) koji su prisutni u postojećim sustavima elektroničke autentikacije. Tipovi tokena opisani su po osnovnim karakteristikama vezanim uz implementaciju metode autentikacije (nešto što znaš, nešto što imaš, nešto što jesi) te klasificirani u predložene sigurnosne razine. Isto tako, tehnološki napredak omogućuje uvođenje i implementaciju novih tipova tokena u sustav. Stoga ovaj dokument ne specificira tip tokena koji se koristi u određenoj sigurnosnoj razini, nego daje preporuke na njegova svojstva.

Tabela 12. Mogući tipovi tokena u autentikacijskom sustavu

Tip tokena Opis

Lozinka ili PIN Tajni niz znakova kojeg korisnik koristi pri autentikaciji

Skup lozinki ili PIN-ova Lista tajnih znakova koje korisnik koristi pri autentikaciji u sustavu

Uređaj za generiranje jednokratnih lozinki (OTP uređaj)

Sklopovski uređaj koji generira jednokratne lozinke. Uređaj može imati numeričku tipkovnicu za unos PIN koda, biometrijski čitač i sl. Jednokratna lozinka generira se korištenjem hash algoritma tajnim ključem koji se nalazi na uređaju te tranzijentnog podatka koji može biti generiran na osnovu vremena, brojača ili izazova kojeg je uređaj dobio od druge strane. Jednokratna lozinka se generira na uređaju te ju korisnik unosi (bilo ručno bilo direktno ukoliko je uređaj spojen na računalo). Dobivenu lozinku verificira verifikacijski entitet u sustavu. U ovu skupinu spadaju i sustavi generiranja jednokratnih zaporki pomoću SMS poruka.


Programski kriptografski token

Kriptografski ključ koji je tipično spremljen na računalu, USB kartici ili nekom drugom mediju. Autentikacija se ostvaruje kroz sustav dokazivanja posjedovanja i kontroliranja ključa. Token će biti kriptiran ključem koji se dobiva na osnovu lozinke koja je poznata samo korisniku tokena.

Sklopovski kriptografski token

Kriptografski token koji se pohranjuje na medij koji omogućuje zaštitu ključa (pametna kartica i sl.). Autentikacija se ostvaruje kroz dokazivanje posjedovanja uređaja i kontrole nad tajnim ključem. To znači ta ovaj tip tokena zahtjeva unos lozinke ili biometrijskih podataka koji omogućuju aktivaciju autentikacijskog ključa. Drugo bitno svojstvo ovog tipa tokena je nemogućnost prikaza odnosno predočavanja tajnog ključa (sve kriptografske operacije s tajnim ključem odvijaju se na samom tokenu).

Tabela 12 prikazuje moguće tipove tokena i njihova svojstva. Njihova primjena ovisi o željenoj sigurnosnoj razini. Programski i sklopovski kriptografski tokeni pružaju mogućnost više sigurnosne razine nego lozinke ili sustavi lozinki. Krađa identiteta u sustavu koji koristi lozinke je lakše ostvariva od krađe identiteta u sustavu sa sklopovskim tokenima ili OTP tokenima. Na osnovu navedenoga, Tabela 13 predlaže veze između sigurnosnih razina i mogućih tipova tokena koji se mogu koristiti da bi se zahtjevi sigurnosnih razina poštivali.

Tabela 13. Tipovi tokena i sigurnosne razine

Dozvoljeni tipovi tokena Sigurnosna

razina 0 1 2 3 4

Sklopovski kriptografski token + biometrijska kontrola ključa X X X X X Sklopovski kriptografski token + kontrola ključa lozinkom X X X X

OTP token X X X Lozinke ili PIN-ovi (korisnički definirani ili definirani od sustava) X X

2.1.6.2 Model autentikacijskog protokola s obzirom na prijetnje

Tabela 14 prikazuje tipične prijetnje u sustavima elektroničke autentikacije te njihova osnovna svojstva. Tabela 15 prikazuje potrebne zaštite od definiranih prijetnji po sigurnosnim razinama.


Tabela 14. Prijetnje u autentikacijskim sustavima

Prijetnja Opis

Prisluškivanje (eavesdropping)

Napad zasnovan na promatranju autentikacijskog protokola s ciljem naknadne analize. Najčešći način iskorištavanja sustava je u formi da prisluškivač dođe u posjed tokenu te naknadno zloupotrebi pribavljeni elektronički identitet.

Pogađanje lozinki (password guessing)

Uzastopno pogađanje lozinki. Ovaj oblik napada se naročito koristi u sustavima koji koriste lozinke koje generiraju sami korisnici zbog njihove moguće slabosti.

Reprodukcija (replay) Reprodukcija prethodno uočenih autentikacijskih poruka.

Oponašanje (impersonation) Oponašanje korisnika sustava, oponašanje verifikacijskog entiteta u sustavu, oponašanje sustava korisnika autentikacijskih atributa prema verifikacijskom entitetu.

Preuzimanje sesije (hijacking)

Napad zasnovan na preuzimanju prethodno uspostavljenje autentikacijske sesije.

Posrednik (man-in-the-middle)

Napad u kojem se napadač predstavlja kao verifikacijski entitet prema korisniku, ili kao korisnik prema verifikacijskom entitetu te na taj način pridobiva osjetljive podatke ili je u mogućnosti promijeniti lozinke.

Tabela 15. Zaštita od prijetnji po sigurnosnim razinama

Zaštita od prijetnje Sigurnosna

razina 0 1 2 3 4

Prisluškivanje X X X X Pogađanje lozinki X X X X

Reprodukcija X X X X X Oponašanje X X X Preuzimanje sesije X X X Posrednički napad X X X


2.1.6.3 Model valjanosti autentikacijskih atributa

Tabela 16 predlaže vremenski okvir valjanosti autentikacijskih atributa po sigurnosnim razinama. Autentikacijski atributi će isteći nakon definiranog vremenskog perioda. Nakon isteka perioda, oni neće biti prihvaćeni kao valjani u sustavu.

Tabela 16. Vrijeme valjanosti autentikacijskih atributa po sigurnosnim razinama

Vrijeme valjanosti atributa Sigurnosna

razina 0 1 2 3 4

12 h X X

2 h X X X Trenutno X X X X X

2.1.7 Utvrđivanje identiteta i prava pristupa servisima e-uprave

Autentikacija je postupak verificiranja identiteta korisnika, kako građana tako i djelatnika u tijelima državne uprave. Korisnici uključuju pojedine osobe, računalne uređaje i sredstva IS-a. Pozitivna, točna i pravovremena identifikacija je potrebna kako bi se osiguralo da odgovarajući korisnik dobije pristup do odgovarajućeg servisa. Iako se misli da identifikacija i autentikacija pripadaju samo korisnicima, potrebno je napomenuti da se sva informacijska sredstva moraju identificirati i autenticirati. Bez autentikacije nije moguće osigurati da je informacija kojoj se pristupa upravo ta koja je tražena.

Autentikacija je obično interakcija između dva entiteta: objekt autentikacije (korisnik ili klijent) koji daje svoju izjavu o identitetu, te autentikator (peer ili poslužitelj) koji provodi verifikaciju identiteta. Korisnik osigurava autentikacijsku informaciju, što uključuje deklarirani identitet te povratnu informaciju prema autentikatoru. Da bi proveo autentikaciju autentikator primjenjuje autentikacijsku funkciju na dodatnu (popratnu) informaciju te uspoređuje rezultat sa očekivanim rezultatom. Ako se rezultat autentikacijske funkcije poklapa sa očekivanim rezultatom identitet je verificiran. Autentikacijska informacija može biti jednostavna lozinka ili složeni skup parametara i poruka. Slično, autentikacijska funkcija može biti jednostavna funkcija (kao što je u slučaju usporedbe lozinki) ili složena aplikacija kriptografskih algoritama (kao što je to slučaj kod digitalnih potpisa).

Ako su autentikacijska informacija i autentikacijska funkcija potpuno pod kontrolom dva entiteta autentikacijska shema se naziva dvostrana shema. Međutim, u mnogim slučajevima je veća


mogućnost proširenja i veća sigurnost koristiti pomoć treće strane (ili čak više trećih strana) za autentikaciju. Te sheme se nazivaju sheme povjerljivih trećih strana.

Drugi faktor koji treba razmotriti je integritet i tajnost autentikacijske informacije, te pravo pristupa pojedinim servisima. Važno je da informacija koja se koristi za autentikaciju bude sigurna i da se ne može dobiti od neovlaštene strane. Moraju se također poduzeti mjere da se autentikacijska informacija zaštiti za vrijeme prijenosa u mreži. Rizik prijenosa je posebno važan u slučaju VPN-ova, gdje se autentikacijska informacija šalje kroz Internet (intranet).

Vlasnici sredstava žele dozvoliti ovlaštenim korisnicima pristup do njihovih sredstava (elektroničkih podataka) računala, štampača, mreža, i aplikacija, te da neovlaštene korisnike drže po strani. Autentikacija je također tražena i od korisnika kako bi bili sigurni da su programi/aplikacija i podatci koje oni koriste autentični. Ako oni nisu autentični tada mogu biti pogrešni, mogu sadržavati računalne viruse, Trojanske konje (Trojanski kod), i dr.

Autorizacija je proces koji je potreban da se osigura valjan pristup autenticiranim korisnicima kroz povjerljivost, integritet i raspoloživost informacijskih sredstava. Potreba za elektroničkom (digitalnom) autentikacijom i autorizacijom se ubrzava zbog sveopćeg širenja elektroničke komunikacije na mreži gdje se ne mogu identificirati korisnici fizički ili osobno.

Stroga su autentikacija i autorizacija kritične za sve vidove sigurnosti. Ako je metoda autorizacije kompromitirana, tada smo izgubili mogućnost razlikovanja tko dobiva pristup informacijama. Tada postoji mogućnost gubljenja privatnosti, povjerljivosti i integriteta bez znanja tko pristupa informacijama i tko ih mijenja. Zahtjeva se konzistentna metoda autorizacije kako bi se izbjegao napad "slabe veze" u kojem bi napadač koristio slabost metode autorizacije za dobivanje pristupa informacijama. Postupci autentikacije i autorizacije moraju biti lagani, s nemogućnošću upada, te brzi i točni, inače neće biti široko prihvaćeni.

Greške autorizacije mogu biti klasificirane ili kao pozitivna greška ili kao negativna greška. Pozitivna greška autorizacije znači da je neki entitet, koji ne bi trebao dobiti dozvolu pristupa, dobio pristup. Neovlašteni pristup dovodi do otkrivanja informacije, korupcije podataka ili brisanja informacije. On dozvoljava napadaču da provede i još veću devastaciju sustava. Negativna greška autentikacije znači da je entitetu kojem je dozvoljen pristup, taj pristup zabranjen. Jedna negativna greška dovodi do ponovne autorizacije, dok kontinuirana negativna greška dovodi do odbacivanja servisa.


2.2 Definiranje svojstava sustava

Integritet sustava se temelji na sljedećim načelima prikazanima u tabeli 17.

Tabela 17. Načela integriteta sustava

Princip Opis

Povjerljivost Prenesene informacije ostaju privatne, a sadržaj je dostupan samo primatelju.

Autentičnost Stranke u komunikaciji su precizno identificirane.

Nepovredljivost Korisnik ne može poreći odvijanje transakcije, osim u slučaju dokazane prijevare ili sigurnosnog incidenta.

Integritet Informacija se ne može neadekvatno mijenjati.

Dostupnost

Omogućen je pristup informaciji ili usluzi kada je potrebno od strane ovlaštenog korisnika. To uključuje i kontrolu pristupa resursima koji su u vlasništvu drugih pružatelja usluge (drugog TDU) za koja postoji potrebna razina autentikacije.

Ključni aspekt je osigurati odgovarajuću razinu sigurnosti u procesu utvrđivanja identiteta te zadovoljiti povjerenje javnosti. Kako bi se osiguralo da pojedinačna TDU zadovoljavaju minimalne razine povjerenja i sigurnosti, potrebno je ovjeriti (certificirati) sustave usluga pojedinih TDU prije nego što se smiju povezati na sustav provjere na stalnoj osnovi.

Osiguranje privatnosti. Postoje dva ključna aspekta koji se moraju razmotriti u dizajnu modela pristupa:

Integritet podataka – model podrazumijeva dvosmjernu razmjenu osobnih podataka između autorizacijske agencije i pružatelja usluge pri čemu je bitno da su informacije (podaci) odgovarajući, odnosno potrebno je zaštiti integritet poruka.

Jedinstveni identifikator – predloženi model podrazumijeva provjeru autentičnosti u središnjoj autorizacijskoj agenciji koja dodjeljuje korisnicima prava za korištenjem na temelju predočenih vjerodajnica koje. Svaki korisnik se mora moći jedinstveni identificirati u bilo kojem procesu na temelju njegovih vjerodajnica.


Analiza centraliziranih i distribuiranih metoda provjere autentičnosti. Ovo područje je od posebne važnosti za bilo koju arhitekturu rješenja on-line provjera identiteta. Postoji nekoliko argumenata za i protiv i centraliziranih i distribuiranih metoda provjera autentičnosti. U korist distribuiranih modela mogu se navesti sljedeći razlozi:

distribuirane arhitekture imaju tendenciju ostvarivanja boljih performansi i propusnosti;

distribuirane arhitekture su lakše za implementaciju jer nije potrebno cross-certificiranje;

distribuirani model omogućuje izravne veze između korisnika i pružatelja usluge međusobno i pojednostavljenje komunikacijsko i aplikacijsko sučelje;

nepotpuno ili nedovoljno sigurno rješenje kod distribuiranog modela će dovesti do manjeg otkrivanja informacija nego kod centraliziranog rješenja;

distribuirani model nudi veću skalabilnost, jer je manje vjerojatno da će postati preopterećen;

distribuirani model nudi veću dostupnost, jer smanjuje rizik od nemogućnosti pristupa cijelom sustavu na samo dio sustava;

distribuirani model nudi veću sigurnost jer smanjuje rizik od sigurnosnih upada, jer ne postoji središnja meta napada;

distribuirani model nudi znatno veću privatnost, jer ni jedna središnja točka ne zna sve transakcije koje je obavio pojedini korisnik.

U korist centraliziranih modela mogu se navesti sljedeći razlozi:

centralizirani sustav značajno smanjuje operativna pitanja upravljanja i održavanja mnogih bilateralnih odnosa između davatelja usluga korisnika;

centralizirani sustav osigurava da su korisnici potvrđeni i mogu biti opozvani neovisno pružatelja usluga;

centralizirani sustav omogućuje veću kontrolu u komunikaciji između korisnika i više pružatelja usluga;

lakše je kontrolirati korištenje opreme i podesiti okolinu za zadovoljavajuće performanse;

lakše je održavati kontrolu nad razinama usluga i pripadnim razinama pristupa;


jednom autenticirani i autorizirani korisnik može pristupiti svim uslugama u sustavu, od bilo kojeg pružatelja usluge, u skladu sa razinom pristupa za koju je autoriziran.

2.2.1 Sigurnost i zaštita dokumenata

Sa strane sigurnosnog aspekta potrebno je obuhvatiti sljedeće scenarije:

Obrada zahtjeva za podacima koji su dislocirani – krajnji korisnik zahtijeva podatke koji se nalaze u više različitih registara tijela državne uprave;

Siguran prijenos zahtjeva za transakcijama – ispunjeni obrazac se usmjerava od korisnika (pri čemu korisnik dobiva odgovor/potvrdu o primitku zahtjeva) do registara gdje se nalaze tražene informacije;

Siguran odgovor na zahtjev krajnjeg korisnika – krajnji korisnik zahtijeva informacije od tijela državne uprave pri čemu je potrebno dostaviti podatke na neku sigurnu adresu elektroničke pošte i obavijestiti korisnika o primitku odgovora. Korisnik mora biti autenticiran da bi pristupio sigurnom pretincu elektroničke pošte;

Sigurna komunikacija među tijelima državne uprave – autenticiranje i sigurno preusmjeravanje podataka među tijelima državne uprave.

Ovi servisi su omogućeni korištenjem sljedećih tehnologija i protokola:

TCP/IP

HTTP

HTTPS

HTML

XML

X.509 certifikati

W3C XML validacija

SOAP

SMTP

WS-Security, WS-Trust, WSPolicy.


XML se koristi kao standardni format podataka za sve poruke u i kroz sustav. Potrebno je omogućiti pouzdana dvostranu SOAP komunikaciju između strana u transakciji. Na sljedećem dijagramu je opisan način uporabe pojedinih tehnologija.

2.2.2 Osiguravanje integriteta zajedničkih podataka

Jedna od ideja u osiguravanju integriteta zajedničkih podataka je korištenje centralne autentikacije kojom bi se osiguralo autenticiranje pojedinca (moguće i na različitim autentikacijskim razinama) na središnjem mjestu, kao što je portal vlade RH. Oni bi tada mogli obavljati transakcije (na razini za koju su se autenticirali) sa različitim tijelima državne uprave. Takav sustav je poželjan ako korisnici trebaju komunicirati i razmjenjivati podatke s nekoliko agencija paralelno. To se možda usporediti sa posjedovanjem glavnog ključa.

Nedostatak centralizirane autentikacije je moguća percepcija da se drugi procesi (kao što je razmjena informacija) mogu odvijati bez znanja korisnika u sklopu autentikacije i razmjene informacija. Centralizirana autentikacija (čak i ako se koriste različite razine autentikacije) također smanjuje sposobnost državnih tijela da bi nadgledala provjere autentikacijskih tehnika u skladu s njihovim prosudbama o rizicima koji su uključeni u transakcije.

U osiguravanju integriteta podataka bitno je nekoliko funkcionalnih područja:

Registracija i upis – korisničko sučelje za autentikaciju i autorizaciju;

Web korisničko sučelje – web usluga portala zahtijeva međusobnu HTTPS sjednicu. Ona je na raspolaganju "pouzdanim korisnicima" (kao što je aplikacije i registri TDU).

Transakcijski sustav – sustav za obradu transakcija i usmjeravanje; pruža sučelja koja omogućuju elektroničke zahtjeve i obrasce prema uslugama tijela državne uprave. Transakcijski sustav može raditi kroz dva načina:

o 'ad-hoc' korištenje sa jasno definiranim protokolom za prijavu koji uključuje i razmjenu XML dokumenata;

o trajno spojeni korisnici pri čemu je aktivna dvostrana komunikacija između korisnika i pružatelja usluga.

2.2.3 Interoperabilnost među jedinicama u sustavu

Interoperabilnost među jedinicama u sustavu moguće je ostvariti ako je implementacija zasnovana na otvorenim standardima. Predlaže se korištenje sljedećih standarda:

XML – standard temeljen na oznakama koji služi za razmjenu strukturiranih podataka;


SAML – sigurnosni standard temeljen na XML-u, služi za prijenos autentikacijskih i autorizacijskih informacija;

SSL – (Secure Sockets Layer), protokol razvijen za prijenos privatnih podataka putem Interneta. SSL radi pomoću privatnog ključa za šifriranje podataka koji se prenose preko SSL veze. Također se naziva HTTPS;

Kerberos – sustav za autentikaciju dizajniran da omogući privatnu razmjenu informacija između dviju strana putem Interneta. Bazira se na dodjeljivanju jedinstvenog ključa svakom korisniku koji prijavi na mrežu. Ključ se umeče u poruke da bi se moglo identificirati pošiljatelja poruke;

Korištenje LDAP protokola za autentikaciju korisnika putem Interneta.

2.2.4 Skalabilnost sustava

Karakteristike korisnički orijentiranih servisa trebaju uzeti u obzir paradigme skalabilnosti on-line usluga s više agencija i kontrolu nad autentikacijskim razmjenama. U tu svrhu potrebno je promatrati autentikaciju ne samo kao identitet korisnika, nego i kao njegova svojstva. Osim toga, da bi usluge mogle biti isporučene korisnicima, u pojedinim slučajevima autentikacija mora biti dinamična jer se može dogoditi da početna razina kojom je korisnik autoriziran nije dostatna za pristup nekim povjerljivim servisima više razine unutar jedne sesije te je potrebno dinamički autenticirati i autorizirati korisnika na nekoj višoj razini.

2.2.5 Osnovni servisi portala

Slijedi tipičan (ali ne kompletan) skup usluga na strani pristupnog portala koje se mogu nadograđivati na provjeru autentikacije i autorizacije za pristup web servisima.

Registracija korisnika. Na portalu, ili bilo kojoj vanjskoj aplikaciji povezanoj s portalom, mora biti omogućena registracija novog krajnjeg korisnika. Kada se krajnji korisnici provode proces prve registracije na portalu oni nemaju nikakve vjerodajnice koje su već predočene i pohranjene na portalu (i autorizirane od autorizacijske agencije). Da bi se registrirao kao pojedinac (privatni korisnik) sa korisničkim imenom/lozinkom, krajnji korisnik mora dati svoje osobne podatke (ime, prezime, adresa, OIB), kao i svoju adresu e-pošte. Poslovni korisnici se također registriraju sa podacima o organizaciji (OIB, adresa, ime i prezime odgovorne osobe).

Davanje prava za korištenje usluge. Ovo omogućava portalu upis registriranih korisnika za pojedine servise. Krajnji korisnik mora predočiti svoje faktore za autentikaciju na potrebnoj razini usluge. Ako je operacija davanja prava završila uspješno, vraća se informacija o statusu usluge zajedno sa identifikatorima usluge.


Prijava korisnika u sustav. Proces autentikacije korisnika počinje predočenjem korisničkih podataka i faktora za autentikaciju na potrebnoj razini te prosljeđivanjem tih podataka autorizacijskoj agenciji koja vrednuje prikupljene podatke na temelju prethodno predočenih vjerodajnica, te ako je provjera uspješna, autorizira korisnika za rad sa sustavom. Ako je proces autentikacije prošao uspješno, korisničkoj aplikaciji je vraćen sigurnosni identifikator. Jedan scenarij prijave zahtijeva posebno razmatranje, to je slučaj kad krajnji korisnik ima autentikacijske faktore za prijavu na nižoj razni i želi se predočiti ispravne vjerodajnice za inicijalnu registraciju na višoj razini. Portal treba otkriti ovo stanje i izraditi odgovarajući poziv(e) za aktivaciju provjere predočenih podataka od strane autorizacijske agencije.

Oduzimanje prava korisniku za korištenje usluge. Ova usluga je omogućena samo registriranim korisnicima. Prava se mogu oduzeti na vlastiti zahtjev, automatski (npr. istekao je mandat državnom dužnosniku) ili na zahtjev autorizacijske agencije zbog sumnji u zloporabu korisničkih podataka.

Ažuriranje lozinke/sigurnosne fraze. Kada krajnji korisnik zaboravi lozinku, odnosno ona je istekla, moguće je pozvati metodu za ažuriranje lozinke. To je moguće uz unos sigurnosne fraze kod zaboravljene lozinke, odnosno istekle lozinke kao uvjerenje posjedovanja pripadnih korisničkih podataka. Analogno, u slučaju zaboravljene sigurnosne fraze, potrebno je predočiti lozinku, da bi se sigurnosna fraza mogla obnoviti.

Da bi se sustav mogao primijeniti u uredskom poslovanju mora zadovoljiti sljedeće pretpostavke:

Javni korisnici bi trebali biti u mogućnosti odabrati da li žele pristupiti uslugama koje zahtijevaju autentikaciju preko Interneta;

Konzistentnost autentikacijskih principa kao što su tehnološka neutralnost, dostupnost i prihvatljivost,

Utvrđivanje prava na uslugu ostaje u domeni odlučivanja pojedinog korisnike odnosno tijela državne uprave, te nije funkcija autorizacijske agencije. Uloga autorizacijske agencije je u izdavanju i potvrđivanju vjerodajnica i pohrani registracijskih detalja (više o tome u poglavlju 5.3.4.).

Neki poslovi zahtijevaju veću sigurnost od ostalih. Primjeri su promjena vlasništva nad zemljom ili dobivanja dozvole korištenja vatrenog oružja. Iz tog razloga, neki procesi će i dalje uključivati fizičku prisutnost pri pružanju usluga pojedinih tijela državne uprave.


2.3 Provedba potrebnih analiza

Tabela 18 prikazuje zahtjeve na autentikacijske faktore, kao i odgovarajuća tehnološka rješenja.

Tabela 18. Zahtjevi na autentikacijske faktore

Funkcijski zahtjevi Blokovi za izgradnju (pametne kartice, biometrija, PKI)

Međusobno povjerenje i sigurnost Uspostava sigurne okoline, pobuda/odgovor, povjerljivi kanali, višefaktorska autentikacija

Identitet (skup osobnih podataka) Nacionalni registar stanovništva, RA servisi

Autentikacija (dokaz predočenog identiteta)

PIN i biometrija

Potpis (dokaz odobrenja, izjave,..) Elektronički potpis, PKI infrastruktura

Digitalni certifikati se smještaju na pametne kartice (token) koje se dodjeljuju pojedinim osobama, čiji identitet predstavljaju. Takvo tehnološko rješenje mora podržati sljedeće zahtjeve:

Sustav treba podržati različite sigurnosne profile, treba biti povjerljiv za nositelja tokena, treba biti pouzdan te treba zaštiti osobne podatke nositelja tokena, koji se nalazi na njemu

Izvođenje i pristup e-Identitetu kao i njegova autentikacija mora biti brza i prilagođena načinu korištenja

Sustav mora biti dokaziv

IAS (Identification, Authentication, Signature) funkcionalnost mora biti izvedena na siguran i upravljiv način

Zahtjevi na identifikaciju nositelja tokena uključuju:

Osobni podatci nositelja moraju biti u elektroničkom obliku

Skup osobnih podataka će zbog interoperabilnosti kao minimum sadržavati:

o Nacionalni identifikacijski broj (opcionalno)

o Prezime, osobno ime


o Spol

o Datum rođenja

o Mjesto rođenja (opcionalno)

o Nacionalnost (opcionalno)

Ovi podatci su opcionalno zaštićeni sa PIN i/ili biometrijskim rješenjima.

Podatci koji se odnose na token (pametnu karticu) moraju, za potrebe interoperabilnosti, kao minimum sadržavati:

o Ime/referencu izdavatelja tokena

o Broj tokena

o Ime zemlje koja ga je izdala

o Datum izdavanja

o Datum prestanka važnosti

Zahtjevi na autentikaciju nositelja tokena uključuju:

Sustav treba omogućiti sigurnu i pouzdanu funkciju autentikacije nositelja

Potpisni ključ za potrebe autentikacije ima slijedeća svojstva:

o Biti će prisutan

o Pojaviti će se samo jednom i bit će zaštićen tako da se on ne može proizvesti

o Biti će zaštićen od neovlaštene upotrebe sa PIN-om ili opcionalno biometrijom

o Zahtjevi na obradu PIN-a bit će usklađeni s ISO 7816-4 normom

o Ako je primijenjena biometrija primjenjuje se slijedeće:

Potpuna usklađenost sa normom ISO 7816-11


Biometrijski OID koji podržava višestruke biometrijske tehnologije mora biti usklađen s normom ISO 19785-1

Podatci otiska prstiju se preporučaju. Implementacija treba biti usklađena sa ISO 19794-2 normom

Biometrijski obrazac treba biti smješten na tokenu

Biometrijsko uspoređivanje treba biti na tokenu

Zahtjevi na elektronički potpis uključuju:

Sustav će podržati sigurnu i pouzdanu funkciju elektroničkog potpisa nositelja tokena za potrebe zakonske valjanosti pozitivne potvrde/odobrenja nositelja kao i za potrebe garancije neporecivosti u odnosu na potpisani informacijski objekt.

Za EU elementi PKI sustava moraju biti usklađeni sa kvalificiranim elektroničkim potpisom, kako je definirano člankom 5.1 EU direktive 1999/93/EC za elektronički potpis.

Elementi PKI sustava moraju biti usklađeni s normom ETSI QCP 101 456 i normama CWA 14890-1 i CWA 14890-2.

Usklađenost s normom ETSI QCP 101 456 uključuje naročito:

o Procedure registracije

o Informacijski sadržaj certifikata

o Obveze certifikacijskog tijela (CA)

o Odgovornost za zaštitu e-Identiteta ( eID tokena) i njegovog sadržaja

o Punjenje drugih aplikacija na token

o Ponovo izdavanje eID tokena

o Sprečavanje neovlaštenog korištenja eID tokena i njegovih certifikata

o Poništavanje eID tokena

o Zahtjeve za podršku PKI infrastrukture (tj. CWA 14171)

o Dobivanje i zaštita CA certifikata


o Dobivanje informacija o statusu certifikata

Usklađenost s normama CWA 14890-1 (area K) i CWA 14890-2 (area K) što naročito uključuje:

o Generiranje parova ključeva (javni i privatni ključ) na samom tokenu

o Uskladištenje ključeva na tokenu

o Usklađenost s normom ISO 7816-15 (PKCS 15) i kripto objektima

o Funkcija potpisivanja treba biti zaštićena s PIN i/ili biometrijom

o Podatci koji se potpisuju se ne mogu mijenjati

o Formati elektroničkih potpisa i njihovih certifikata moraju biti interoperabilni

o Zaštita poruka treba biti podržana (simetrični kripto uređaj)

o Svi algoritmi koji su prihvaćeni od EU WS eSign grupe trebaju biti podržani

o Javna raspoloživost funkcije verifikacije certifikata od strane pouzdanih (relying) strana

PKI infrastruktura treba biti implementirana na slijedeći način:

o Minimalno 2 certifikata ( 1 za potpis; 1 za ostale funkcije)

o Usklađenost s X.509 V3 minimalnim profilom što uključuje:

Ime CA

Ime nositelja certifikata

Jedinstveni identifikator nositelja tokena/certifikata

Period valjanosti certifikata

Serijski broj certifikata

Kazalo (pointer) na informaciju o CA politici certifikata.

Gornje zahtjeve zadovoljava PKI infrastruktura sa kvalificiranim certifikatima prema EU direktivi 1999/93/EC. Zaštita osobnih podataka, koji su vezani za e-Identitet je nužnost i ona je regulirana


EU direktivom 95/46/EC za zaštitu podataka, te našim Zakonom o zaštiti osobnih podataka (NN 103/2003, 118/2006).

2.3.1 Analiza prethodno provedene međunarodne prakse

Velik broj zemalja, kako u Europi, tako i u Svijetu, pokazale su snažnu inicijativu ka ostvarenju usluga "eGovernment"-a, i to uglavnom, u ovom trenutku, s ciljem uspostave usluga na nacionalnoj razini. U nastavku navodimo primjere i opis sustava iz nekoliko zemalja (Za više detalja, upućujemo na eGovernment Fact Sheets koje objavljuje ePractice portal pod ovlastima Europske Komisije na internet stranicama: http://www.epractice.eu/en/factsheets/).

2.3.1.1 Češka

Češka je donijela zakon o elektroničkoj upravi koji je u primjeni od Srpnja 2009. a temelji se na sljedeći načelima:

elektronički dokument ima istu valjanost kao i papirnati

omogućena je digitalizacija papirnatih dokumenata

razmjena elektroničkih dokumenata mora biti što jednostavnija i potpuno sigurna kroz postupke certificiranog elektroničkog potpisa.

Ostvaren je jedinstveni portal kao mjesto za dobivanje svih informacija i ostvarivanje usluga. Isto tako, realizirana je nacionalna mreža s ciljem ostvarivanja veze među raznim tijelima državne uprave i lokalne uprave. Isto tako realiziran je i POINT sustav radnih točaka lociranih u poštama, gradskim uredima, veleposlanstvima, na kojima građani mogu ostvariti usluge dobivanja informacija i izvadaka. Cilj ovog sustava je javni pristup svim dostupnim informacijama s jednog mjesta.

2.3.1.2 Švedska

Međunarodno priznata kao jedna od zemalja sa najuspješnijom primjenom usluga elektroničke uprave. Za građane ne postoji jedno mjesto pristupa i ostvarivanja usluga, nego postoji mogućnost više tematskih portala u kojima se grupiraju pojedine usluge (zdravstvo, zapošljavanje, porezi, ...). S druge strane, za poslovne subjekte postoji jedan portal kao mjesto ostvarivanja usluga.

U sklopu aktivnosti eUprave, realizirana je i nacionalna intranet mreža SGSI (Swedish Government Secure Intranet) za sigurnu komunikaciju među vladinim organizacijskim jedinicama, ali i prema članicama Europske Zajednice te tijelima Europske Komisije kroz TESTA mrežu.


Od 2005., švedska vlada je uvela službenu identifikacijsku karticu koja sadrži biometrijske podatke. Ova kartica nije obavezna a predviđa se buduća primjena i u ostvarivanju usluga e-uprave. Isto tako u opticaju su i neslužbene e-Legitimation kartice, tj. neslužbene eID kartice ili programski eID identifikatori koje izdaju banke. eID kartice se mogu koristiti u sustavu ostvarivanja usluga elektroničke uprave, a neke usluge i zahtijevaju njihovu primjenu.

2.3.1.3 Austrija

U Austriji je u opticaju CitizenCard, što može biti bilo koji uređaj (pametna kartica, mobilni uređaj, USB token, ...) koji ima mogućnosti digitalnog potpisivanja i sigurne pohrane osobnih podataka. Pružatelji usluga iz javnog i privatnog sektora koriste CitizenCard uređaje za potrebe autentikacije. Sustav je okarakteriziran po svojoj neutralnosti prema implementacijskoj tehnologiji.

U studenom 2008. objavljen je MOCCA srednji sloj za CC (CitizenCard) koji omogućuje implementaciju autentikacijskih procesa na web portalima bez potrebne instalacije dodatne programske podrške na klijentskim računalima.

Isto tako pokrenut je portal help.gv.at (myhelp.gv.at) koji omogućuje korisnicima CC da upišu svoje podatke. Osobni podatci su sigurno spremljeni i dostupni autenticiranim korisnicima. Na osnovu unesenih podataka, portal filtrira, nudi i prikazuje relevantne informacije i usluge. Npr. podsjetnik o skorom isteku valjanosti putovnice, informacije lokalne uprave itd.

2.3.1.4 Estonija

Od 2002 godine Estonija je uvela identifikacijske pametne kartice. ID kartica sadrži osobne podatke i dva PIN-om zaštićena digitalna certifikata. Kartice se mogu koristiti za ostvarivanje usluga elektroničke uprave kao i usluga elektroničke trgovine pri čemu se certifikati koriste za autentikaciju i digitalno potpisivanje.

Razmjena podataka unutar tijela državne uprave odvija se po posebnoj intranet mreži EEBone. EEBone povezuje sve vladine urede te osigurava siguran intranet pristup te pristup internetu. Na EEBone se oslanja i X-Road middleware sloji X-Road centar za razmjenu podataka između baza podataka pod jurisdikcijom različitih tijela državne uprave. Autentikacija i autorizacija korisnika za korištenje X-Road-a moguća je pomoću ID kartice ili pomoću vjerodajnica koje izdaju komercijalne banke.

2.3.1.5 Velika Britanija

U Velikoj Britaniji je u korištenju sustav sa centralnim mjestom koje je zaduženo za registraciju i autentikaciju korisnika, tzv. "Government Gateway". Osnovna uloga GG-a je podrška sigurnih i autenticiranih transakcija elektroničke uprave preko interneta. Autentikacija korisnika koji mogu biti pojedinci, organizacije ili "agenti" (predstavnici) je zasnovana na lozinkama ili na


certifikatima, a ovisi o tipu i zahtijevanom stupnju sigurnosti pojedine transakcije. Također jer planirano korištenje identifikacijske e-ID kartice za potrebe digitalnih potpisa. Osnovne komponente centralizirane "Government Gateway" arhitekture su: autentikacija i autorizacija, single sign-on funkcionalnost, integritet razmjene podataka, sigurnosni mehanizmi. Skup funkcionalnosti koje čine sustav su:

autentikacija i autorizacija korisnika (građani, organizacije, predstavnici)

transakcija i razmjena dokumenata među organizacijama uprave, između TDU i vanjskih organizacija (poslovnih subjekata), te između TDU i građana

sustav za plaćanje transakcija

2.3.1.6 Nizozemska

Osnovna komponenta aktivnosti elektroničke uprave u Nizozemskoj je tzv. "DigID" inicijativa (Digital Identity) a njena svrha je omogućiti građanima i poslovnim subjektima centralno mjesto ostvarivanja autentikacijskih procesa za servise elektroničke uprave http://www.digid.nl/. DigID ima funkciju posrednika odnosno ostvaritelja autentikacijskih usluga za državna tijela i verifikacije identiteta korisnika usluga. Sustav podržava više razina sigurnosti (osnovna, srednja i visoka) i primjene odgovarajućih autentikacijskih vjerodajnica kao što su lozinke, jednokratne lozinke, SMS autentikacija i PKI certifikati. Tijelo uprave koje je zaduženo za pojedinu uslugu odlučuje u koju sigurnosnu razinu spada navedena usluga. Isto tako sustav ostvaruje i SSO funkcionalnost kroz zajedničke vjerodajnice za više usluga lokalne ili državne uprave koje podržavaju DigID. Time je autentikacijska usluga centralizirana a korisnici usluga se pri inicijaciji korištenja iste preusmjeravaju prema DigID-u koji obavlja autentikaciju.

Uz DigID, za međusobnu razmjenu podataka među vladinim agencijama uspostavljena je OSB kao sabirnica elektroničkih usluga (Government service bus). OSB definira formate digitalnih dokumenata i njihovu razmjenu kroz digitalne poruke. Razmjena je specificirana kroz definiciju zaglavlja, formata i sigurnosnih zahtjeva, što je sadržano u OSB standardu. Sustav koristi OIN, identifikacijski broj agencije a postupak identifikacije zasniva se na PKI x509 certifikatima.

2.3.1.7 Novi Zeland

Za potrebe ostvarivanja usluga elektroničke uprave, uspostavljena su dva servisa (https://www1.i.govt.nz/cls/static/homepage):

1. Servis "igovt logon service" za prijavu na usluge elektroničke uprave. Servis je zadužen za postupke čuvanja i ovjeravanja "logon" podataka (korisničkog imena, lozinke i eventualno OTP lozinke). Usluge TDU za koje se korisnik prethodno registrirao koriste igovt servis za provjeru


ispravnosti logon podataka. Na taj način, korisnik može koristiti jedne logon podatke za pristup više usluga.

2. Servis verifikacije identiteta (igovt verification service) omogućuje dokazivanje identiteta prilikom ostvarivanja usluga elektroničke uprave. Može se poistovjetiti sa osobnim predstavljanjem putem putovnice na fizičkim mjestima ostvarivanja usluge. Pri pristupanju nekoj usluzi, državno tijelo zaduženo za istu će preko igovt verification servisa dobiti potrebne podatke tj. dokaz o stvarnom identitetu klijenta usluge.

Pored ostvarivanja navedenih usluga, na istom mjestu se i kreiraju log podatci o federiranju korisničkih podataka i identitetskih vjerodajnica u sustavu.

2.3.1.8 Australija

Infrastruktura pod nazivom VANguard pruža usluge e-autentikacije, verifikacije digitalnog potpisa, SSO, timestamping (elektronički dokaz o točnom vremenu elektroničke transakcije), generiranje sigurnosnih tokena itd. VANGuard sustav omogućuje poslovnim korisnicima pristup uslugama elektroničke uprave (na državnoj i lokalnoj razini). VANguard vrši verifikaciju digitalnih certifikata pri čemu podržava više dostavljača certifikata. Osnovne usluge VANguard i njihovi opisi:

Autentikacija korisnika: Agencija koja je zadužena za određenu uslugu preusmjerava korisnike usluge u trenutku prijave. Korisnik se prijavljuje na VANguard pri čemu prilaže svoj digitalni potpis. Nakon što VANguard autentikacijska komponenta verificira korisnikov potpis, potvrđuje agencijskom servisu autentičnost korisnika.

Verifikacija digitalnog potpisa: Omogućuje popunjavanje i potpisivanje elektroničkih formi pri čemu je verifikacija potpisa preusmjerena prema VANguard sustavu.

SSO funkcionalnost: Kada se korisnik autenticira korištenjem VANguard sustava, onda nije potrebna ponovna autentikacija za servise iz određenog skupa usluga.

Zapis o točnom vremenu elektroničke transakcije (timestamping): Točno i zakonski potvrđeno praćenje vremena određenih transakcija između servisa e-uprave i poslovnih klijenata.

Postoji još nekoliko zanimljivih projekata kao što su Gatekeeper projekt koji ima za cilj korištenje PKI infrastrukture za ostvarivanje usluga elektroničke uprave, te sveobuhvatni NeAF (National e-Autentication Framework) okvir za međusobnu autentikaciju pojedinaca, organizacija, poslovnih subjekata te državnih tijela koji pružaju usluge elektroničke uprave.


2.3.1.9 Ostale inicijative u sklopu EU

U okviru EU pokrenute su brojne inicijative za uvođenje e-Identiteta kako bi se realizirao zahtjev za globalizacijom kretanja građana, korištenja javne administracije, provođenje e-Poslovanja, formiranja i korištenja zajedničkog tržišta (EEA - European Economic Area) unutar zemalja EU i šire. Zakonski okvir za sve europski e-Identitet kao i ograničenja dana su u EC Treaty članku 18 (http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:12002E018:EN:HTML).

Sukladno tom okviru dane su i sugestije i preporuke koje se mogu sažeti:

Koristiti i interpretirati, koliko god je moguće, postojeću regulativu kao što je EU direktiva 1999/93/EC za elektronički potpis.

Upotrijebiti sve raspoložive norme i promovirati razvoj novih normi za autentikaciju entiteta kako bi se podržala upotreba sve europskog e-Identiteta.

Članice EU-a mogu koristiti e-Identitete na različitim sigurnosnim razinama. Bilo bi lakše da se postigne konsenzus na nižim sigurnosnim razinama.

Pored toga treba vrednovati mogućnost korištenja postojećih nacionalnih i Europskih zakona za putovnice, kao drugi blok za izgradnju zakonskog okvira za sve Europski e-Identitet.

Kroz prethodno navedene primjere međunarodne prakse može se uočiti širok spektar mogućih i implementiranih rješenja u sustavima autorizacije i autentikacije za usluge elektroničke uprave. Pojedina rješenja imaju granulirane i izdvojene razine sigurnosti koje se primjenjuju po pojedine razine ovisno potrebama stvarne usluge koja se ostvaruje. Razina rizika koji su uključeni u svaki tip on-line transakcija varira. U transakcijama gdje se smatra da je rizik visok, preporučuje se "jaki" proces autentikacije; gdje je manji rizik, i "slabiji" oblici autentikacije se smatraju prihvatljivim. Ovakav pristup ovisi o prihvaćanju dogovorenog okvir za utvrđivanje razine rizika. Autentikacija ovog tipa je već u uporabi od strane vlade SAD-a i Velike Britanije. Alternativno rješenje primjenjuje "jaki" proces autentikacije za pristup svim transakcijama. Ovaj pristup je već usvojen u pojedinim zemljama, primjeri su Singapur i neke europske zemlje poput Finske. Zajednički faktor u svim slučajevima je da ove zemlje imaju dugogodišnje prihvaćanje korištenja jedinstvenog identifikatora koji pojedinci koriste u svom poslovanju s Vladom. Također je opće prihvaćeno, čak se i očekuje, da se znatna količina osobnih podataka automatski prenosi na tijela državne uprave i javno je dostupna.

U nastavku ćemo opisati nekoliko europskih projekata koji imaju za cilj primjenu usluga elektroničke uprave na pan-europskoj razini kroz ostvarivanje principa interoperabilnosti nacionalnih elektroničkih usluga.


2.3.1.10 ISA: Interoperability Solutions for European Public Administrations (1)

Cilj ovog pan-europskog programa je da poboljša elektroničku kooperaciju i razmjenu između javnih administracijskih ustanova u članicama EU. Osnovni zahtjev na projekt je svladavanje elektroničkih barijera na međudržavnoj razini unutar EU kroz uspostavu pan-europskih elektroničkih javnih usluga (servisa). Vremenski okvir programa je od 2010. do 2015. godine sa financijskim budžetom od 164 milijuna eura. Ovaj program može se smatrati nastavkom inicijative Europske Komisije koja je bila ostvarena kroz program IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens).

2.3.1.11 STORK: Secure Identity Across Borders Linked (2)

Cilj ovog projekta je uspostava europske platforme za eID interoperabilnost koja će omogućiti korisnicima pristup elektroničkim uslugama na međudržavnoj razini korištenjem nacionalnog sustava elektroničkog identiteta (eID sustava). Osnovna značajka ovog pilot sustava je pristup upravljanju elektroničkog identiteta kao korisnički orijentiranog sustava (user-centric), što znači da sustav ne čuva nikakve osobne podatke, a korisnik je taj koji kontrolira koji podatci će biti dostavljeni usluzi koja zahtjeva elektroničko identificiranje korisnika kao klijenta. Osnovna prednost ovog pristupa u razmjeni podataka o elektroničkom identitetu na međudržavnoj razini je kompatibilnost prema diverzificiranoj pravnoj legislativi u državama koja zahtijevaju osnovna ljudska prava kao što su privatnost.

STORK sustav je zamišljen kao distribuirani sustav koji će omogućiti integraciju elektroničkih usluga pri čemu se uzima u obzir postojeće stanje i infrastruktura u upotrebi u zemljama članicama EU. Projekt ima za cilj razvoj specifikacije koja će omogućiti međusobno prepoznavanje nacionalnih sustava elektroničkog identiteta eID. U sklopu projekta predviđa se izvedba nekoliko pilot projekata s ciljem demonstracije razvijenih koncepata, među kojima su aplikacije promjene adrese, usluge studentske mobilnosti i regulacije studentskih prava, sigurna komunikacija uz korištenje i međusobnu interoperabilnost nacionalnih eID sustava, elektronička dostava itd.

Inicijative za interoperabilnost među PKI domenama. Postoji nekoliko inicijativa za rješavanje problema interoperabilnosti različitih PKI domena. Neki od projekata su slijedeći:

European Bridge CA Initiative

US Federal Bridge initiatives

Government of Canada PKI

Australian Government Gatekeeper Project


2.3.2 Analiza i prilagodba predloženih principa

Autentikacijski projekt NIAAS predstavlja kombinaciju smjernica definiranih međunarodnom praksom i prilagođenih specifičnostima hrvatskih potreba. Svrha ovog dokumenta je u utvrđivanju ključnih prioriteta prilikom identifikacije, provjere valjanosti pristupa i identificiranju mogućih problema u nacrtu politike autentikacije u on-line transakcijama servisa Moja uprava.

Autentikacija služi kao dokaz kao i zaštita pojedinačnih identiteta, te predstavlja ključnu komponentu za uspješno ostvarenje vladinih ciljeva u području on-line državne uprave. Stoga je bitno da se dobije sveobuhvatno razumijevanje o što je više moguće pitanja vezanih za autentikacijske procese, kako bi bili u mogućnosti uvjeriti sve sudionike procesa o svojstvima i prednostima ovog projekta.

NIAAS se bavi stvaranjem skupa pravila kako bi se osiguralo da se:

utvrdi identitet korisnika;

pružene usluge pojedinih tijela državne uprave putem Interneta isporuče pravom korisniku;

štiti privatnost korisnika i informacija.

Primjena predloženih principa mora se temeljiti na sljedećim principima i činjenicama:

usklađivanju postojećih različitih sustava i procesa autentikacije koji se već nalaze u upotrebi na različitim razinama i tijelima državne uprave;

tehnološkoj neutralnosti – predloženi principi su tehnološki neutralni i moguće ih je implementirati na različitim platformama i u različitim tehnologijama;

korisničkoj fokusiranosti – stavljanje naglaska na potrebe korisnika, uzimajući u obzir dostupnost servisa, lakoću korištenja, razumljivost i integritet poruka;

izbjegavanju nepotrebne kompleksnosti– pretpostavka je da će zahtjevi za koje je potrebna viša razina autentikacije i autorizacije, s obzirom na ukupni broj transakcija biti relativno niska;

potrebno je obratiti posebnu pažnju zaštiti privatnosti:

relativni prioritet je stavljen na procese od javnog interesa;

poželjno je da NIASS bude centraliziran;


određivanju opsega i razina transakcija koje mogu zahtijevati autentikaciju, u odnosu na njihovu složenost i rizik.

Postojeća situacija u Hrvatskoj:

Zasebni informacijski sustavi i baze podataka

Autorizacija putem lokalnih autorizacijskih sustava

Upitni zakonski okviri

Korištenje elektronske zaštite dokumenta na niskoj razini

U okviru EU nekoliko članica već primjenjuju elektronički identitet u formi (pametnih kartica) za potrebe svojih građana. Pod pojmom eID u sklopu aktivnosti na razini EU podrazumijevaju se projekti, infrastruktura i sustavi koji za cilj imaju ostvarenje sustava elektroničkog identiteta. U užem smislu eID je termin koji se upotrebljava za definiciju elektroničkog identiteta odnosno elektroničke reprezentacije subjekta u smislu specificiranih atributa koji ga identificiraju u sustavima elektroničkih usluga. Slijedno tome, eID token predstavlja sklopovlje ili programsku podršku (ili kombinaciju) koja služi kao nositelj vjerodajnica odn. informacije koje potvrđuju identitet subjekta. Glavni cilj ovih eID tokena je opskrbiti građane za potrebe identifikacije, autentikacije i elektroničkog potpisivanja. Finska je bila prva zemlja u EU koja je uvela eID. Nakon toga njoj su se pridružile Austrija, Belgija, Italija, Estonija, Nizozemska i Švedska te potom Španjolska i Portugal. Sve ove zemlje su razvile svoj nacionalni eID token za e-Government procese. One su razvile svoje sustave prema različitim ciljevima i s različitim razinama očekivanja.

Neke zemlje su razvile sustav samo za potrebe identifikacije (Italija) dok su druge razvile sustav kao više aplikacijski token (Estonija, Belgija). Isto tako osjetljivost na privatnost je različito tretirana, tako da su neke zemlje podigle razinu zaštite privatnosti vrlo visoko u odnosu na druge. Isto tako zahtjevi na interoperabilnost nisu bili ugrađeni u fazi dizajna, nego su razvijani prvenstveno za vlastite potrebe unutar svoje zemlje. Stoga imamo unutar EU vrlo dobrih rješenja, ali koja su prilično daleko jedan od drugog. eID token izdan u jednoj zemlji nije funkcionalan u drugoj. EU stoga pridaje vrlo veliku pažnju prema elektroničkom identitetu (eID) i neizbježnoj interoperabilnosti.

Prema Europskoj inicijativi i2010 stoji da će sve zemlje EU-a kroz period od 2006-do 2010 raditi na međusobnom prepoznavanju nacionalnih eID-a kroz testiranja, pilotske projekte i implementaciju pogodnih rješenja i metodologija. To je ono što se i danas čini kroz mnoga tehnička povjerenstva, grupe i radionice pod okriljem EC-a i njezinih institucija, iz čega proizlaze


prijedlozi i preporuke za normizaciju u tom području, a koja je dana u Isporuci 5. Kako je rečeno 9 zemalja EU već je startalo svoje nacionalne eID projekte, dok drugih 14 analizira tehnologije pametnih kartica (eID tokena) za njihove nadolazeće eID projekte.

Interoperabilnost je uvijek bila važna za industriju pametnih kartica. Za svaki program koji koristi tu tehnologiju kartice se moraju čitati bez problema od strane čitača koji su vezani na PC računalo ili računalnu mrežu. To je pogotovo važno kada se zna da su čitači kartica proizvedeni od različitih proizvođača, te se koriste u različitim uvjetima ili geografskim okruženjima. ECC (European Citizen Card) norme stoga razrađuju tu problematiku interoperabilnosti. Stoga su zemlje koje sada uvode svoj nacionalni eID, kao Hrvatska, u određenoj prednosti jer već u fazi dizajna, tj. od početka, mogu koristiti iskustva dobre prakse i predloženu normizaciju, kako bi proizvele sigurne i interoperabilne e-identitete.

Na temelju međunarodne prakse, iskustava iz sustava za autentikaciju i autorizaciju koji su već implementirani, činjenice da je sustav autentikacije i autorizacije jedan od glavnih podsustava koncepta Moje Uprave, potrebno je omogućiti:

Omogućavanje upravljanja korisničkim identitetima.

Definiranje postupka dodavanja novog korisnika i upis njihovih vjerodajnica.

Verifikacija informacija koje se koriste u on-line uslugama bez obzira na vlasnike (TDU, privatni ili poslovni korisnici).

Sljedeći koncepti i postupci su ključni za funkcioniranje sustava:

Registracija. Registracija je mogućnost da krajnji korisnik stekne aktivne faktore za autentikaciju temeljene na pohranjenim vjerodajnicama u registru o korisnicima. Krajnji korisnik koji je završio postupak registracije stječe sposobnost da se identificira na pristupnom portalu, pri čemu se predstavlja pomoću dobivenih korisničkih podataka (korisničko ima\lozinka ili digitalni certifikat) i prijavljuje se na sustav (putem web servisa pomoću kojeg je moguće pristupiti sučeljima i portalima koje koriste aplikacije trećih osoba). Vjerodajnice su povezane u skupine od jedne ili više, u kojima svi krajnji korisnici koji posjeduju iste vjerodajnice predstavljaju isti entitet (tj. u poslovnim procesima, iste organizacije). Krajnji korisnik se može registrirati kao pojedinac (građanin), organizacija ili agent. U slučaju da se registrira kao pojedinac, nije moguće imati dodatne članove, dok u slučajevima kad se korisnik registrira kao organizacija ili agent, moguće je stvoriti i registrirati dodatne krajnje korisnike u grupi, koji pak mogu stvarati i registrirati dodatne korisnike.


Dodjeljivanje prava. Dodjeljivanje prava je proces u kojem se krajnji korisnik veže uz pravo za korištenje određene elektroničke usluge putem on-line sučelja. Dodjeljivanje prava je uvijek povezano s određenim skupom identifikatora, tj. identifikatorom grupe kojim se može prepoznati vlasnik usluge. Višestruko dodjeljivanje prava je također dozvoljeno, npr. jedan poslovni subjekt se može upisati u registar korisnika s više različitih korisničkih shema (kao što je jedna za direktora i jedna za zaposlenike). Svaki shema mora koristiti različiti skup faktora autentikacije (temeljenih na različitim vjerodajnicama) i identifikatora.

Identifikatori. Identifikator i su skup jednog ili više parova ime-vrijednost koji zajedno definiraju jedinstveni ključ s pravima vlasnika. Pojedinačni par ime-vrijednost predstavlja jedan identifikator. Dio para koji predstavlja ima se naziva identifikator tipa. Obično se u pojedinim uslugama koristi niz tipova identifikatora da bi se definiralo pozadinski ključ te usluge koji je konzistentan u svim upitima za tu uslugu.

Usluga. Usluga predstavlja skupinu od jedne ili više vrsta transakcije koja se može podnijeti putem portala prema krajnjim korisnicima, a koje dijele isti skup identifikatora kojima vlasnik usluge jedinstveno identificira pošiljatelja transakcija. Usluga je razina granulacije na kojoj se provjerava pravo pristupa korisnika.

Klasa transakcije. Klasa transakcije identificira određeni tip dokumenta koji se podnosi putem portala krajnjim korisnicima koji su zahtijevali tu uslugu. Uspješno ostvarivanje prava za uslugu daje pravo krajnjem korisniku da mu se isporuče dokumenti koji su rezultat svih klasa transakcija definiranih za tu uslugu.

2.3.3 Analiza potrebnih podataka za inicijalnu registraciju

Proces inicijalne registracije je sljedeći:

Krajnji korisnik odabire vrstu registracije (npr. pojedinac)

Krajnji korisnik odabire tip autentikacije i za to potrebnih vjerodajnica koje mora predočiti

o Za korisničko ime/ lozinku potrebno je unijeti ime i prezime, OIB, adresu stanovanja, željeno korisničko ime i lozinku, adresu e-pošte

o U slučaju upotrebe digitalnog certifikata potrebno je odabrati koji digitalni certifikat se želi koristiti kako bi se osiguralo da je valjan.

Krajnji korisnik odabire uslugu(e) koje želi da mu budu dostupne.


Preostali koraci registracije se odvijaju asinkrono:

Identifikatore se šalju na validaciju autorizacijskoj agenciji.

Korisniku se šalju podaci o potvrdi registracije poštom.

Korisnik podastire dobivene podatke i aktivira uslugu.

U procesu registracije potrebno obratiti posebnu pažnju na nemoćne, skrbnike i ostale koji fizički nisu u mogućnosti podnijeti zahtjev za dobivanje autentikacijskih faktora niti se koristiti uslugama elektroničke uprave.

2.3.4 Analiza dostupnosti usluge

U implementaciji pristupa uslugama postoje dvije opcije:

Prva opcija je korištenje otvorenih standarda i načela otvorenog koda, pri čemu određene komponente i sučelja za programiranje aplikacija ne trebaju biti navedena ako su u skladu sa standardima. Komponente koje su u skladu sa standardima mogu biti razvijene od strane pojedine agencije;

Druga opcija je korištenje gotovih aplikacija na postojećim zatvorenim tehnologijama, pri čemu se obično ima u vidu određeni proizvod, bez konsenzusa o potrebnim komponentama.

Bez obzira na opcije, glavni kanal pristupa trebaju biti Internet preglednici. Osim toga za pristup je moguće koristiti i mobilne telefone, PDA uređaje i sl. koji podržavaju transportni protokol ekvivalentan HTTPS-u i koji imaju mobilni Internet preglednik.

2.3.5 Analiza korištenja usluga tijela državne i javne uprave i lokalne samouprave

Korištenje autentikacije u tijelima državne za uprave za identificiranje korisnika pojedinih usluga može se promatrati kao ciklus u kojem postoji sve veći broj korisnika koji se pouzdaju u on-line komunikacije s tijelima državne uprave, što dovodi do povećanja važnost on-line komunikacije za pojedina tijela državne uprave. S druge strane, to će potaknuti agencije na povećanje broja i funkcija on-line usluga, a to će opet implicirati povećanje privlačnosti takvog načina komunikacije za korisnike. Rezultat je povećanje broja korisnika koji koriste on-line transakcije u komunikaciji s tijelima državne uprave. Ciklus povećanja broja korisnika koji koriste on-line transakcije u komunikaciji s tijelima državne uprave je prikazan na slici 5.


Slika 5. Povećanje broja korisnika koji koriste on-line transakcije u komunikaciji s TDU


3 MODEL SUSTAVA

Svrha poglavlja je izrada prijedloga konceptualnog modela, opis životnog ciklusa utvrđivanja identiteta, definiranje različitih razina pristupa korisnika s detaljima implementacije.

3.1 Prijedlog konceptualnog modela

Slika 6. Konceptualni model nacionalnog autentikacijskog sustava

Slika 6 prikazuje konceptualni model sustava autentikacije i autorizacije NIAAS (Nacionalni Identifikacijski, autentikacijski i autorizacijski sustav). Ovaj model predviđa jedinstveni elektronički identitet korisnika sustava (građani, tvrtke, organizacije, agenti) kao polazni i centralni element sustava. S obzirom na postojeću situaciju u RH, predlaže se da se sustav jedinstvenog elektroničkog identiteta zasniva na OIB identifikatoru kao jedinstvenom nositelju podataka o osobama u RH. U tu svrhu potrebno je provesti analizu primjenjivosti OIB-a te predložiti eventualne i potrebne operativne i tehničke izmjene u postojećim sustavima. Polazišna točka jedinstvenog elektroničkog identiteta povezana je sa centralnim imeničkim direktorijem u kojem se nalazi osnovni skup atributa koji minimalno definiraju entitet korisnika u sustavu. U procesima autentikacije osnovni skup atributa, odnosno njegov podskup koji definira elektronički identitet prosljeđuje se zainteresiranim stranama, odnosno sustavima u TDU, lokalnim tijelima, organizacijama i sl. koji ostvaruju elektroničke usluge. Tijela korisnici


NIAAS sustava mogu za svoje potrebe proširivati osnovni skup atributa elektroničkog identiteta dodatnim, specifičnim atributima koji će biti upravljani u njihovoj nadležnosti. Isto tako, definicija potrebne sigurnosne razine, autorizacijskih politika te uloga u uslugama koje ostvaruju nalazi se u njihovoj nadležnosti. Zadaća NIAAS sustava je sigurna dostava i valjanost autentikacijskih atributa elektroničkog entiteta. U nadležnosti NIAS sustava ostaje upravljanje jedinstvenim elektroničkim identitetom te upravljanje osnovnim atributima koji su potrebni za ostvarenje sigurnosne razine 0 (Tabela 5). Sustav treba biti dovoljno fleksibilan da omogući interoperabilnost i razmjenu osnovnih i specifičnih atributa među korisnicima sustava koji ostvaruju elektroničke usluge (TDU, lokalna uprava, organizacije, ...) odnosno definiranje odnosa povjerenja kako bi se smanjila nepotrebna redundancija, odnosno povećala efikasnost sustava s obzirom na postojanje dupliciranih atributa gdje je to moguće.

Slika 7 prikazuje načelnu arhitekturu prijedloga nacionalnog identifikacijskog, autentikacijskog i autorizacijskog sustava NIAAS. Sustav je zamišljen kao hijerarhijski i distribuiran, proširiv, namijenjen osobama, djelatnicima tijela državne uprave kao i organizacijama odnosno tvrtkama te prilagođen različitim sigurnosnim razinama ovisno o potrebi pojedine usluge.

Nužno je naglasiti povezanost elektroničkog identiteta sa OIB identifikatorom koji u Republici Hrvatskoj predstavlja jednoznačni ključ za identifikaciju kako fizičkih, tako i pravnih osoba. Kao takav, OIB sustav omogućuje jednoznačnost elektroničkog identiteta u predloženom integriranom autentikacijskom konceptualnom modelu. Isto tako, životni ciklus OIB identifikatora se može upotrijebiti za upravljanje životnim ciklusom elektroničkog identiteta.

Predloženi konceptualni model se može slikovito opisati principom: centralizirana autentikacija, distribuirana autorizacija.


Slika 7. Arhitektura NIAAs

Osnovno načelo ovog prijedloga je hijerarhijska arhitektura i distribuiranost (slika 7). Pod pojmom hijerarhijska arhitektura smatra se organizacija sustava identifikacije, autentikacije i autorizacije (u daljnjem tekstu IAA) na način da usluga na višoj hijerarhijskoj razini može koristiti sve atribute i podatke o korisniku sa nižoj hijerarhijskoj razini, ukoliko za to postoji potreba i regulirani odnosi između razina (kroz odnose povjerenja i definirane politike upravljana) kako bi se osigurala što efikasnija implementacija sustava, ali u isto vrijeme izbjegao problem nekonzistentnosti podataka, a time i mogućih problema oko odobravanja ili neodobravanja pristupa određenim servisima.

Drugo važno načelo je distribuiranost čime se osigurava mogućnost da pojedini pružatelji usluga mogu kontrolirati korištenje usluge kroz lokalnu infrastrukturu, ali uz uvijek postojeću mogućnost korištenja autentikacijskih metoda iz ostalih dijelova sustava. Ovo načelo također osigurava uključivost postojećih IAA infrastruktura u nacionalni sustav što je važno kako bi


sustav bio prihvaćen od što većeg broja sadašnjih pružatelja usluga, kao i potrebe da se prelasci na nova rješenja mogu odvijati postupno i u razumnim rokovima. Izbjegavanje potpuno centraliziranog sustava osigurava i bolju prilagodljivost specifičnim potrebama pojedinih tijela i pružatelja usluge.

Sustav je u svojoj arhitekturi proširiv tako da je prilagođen potrebi izvedbe u manjem opsegu za potrebe pilot faze i proširenju do potpune funkcionalnosti u kasnijim fazama.

Kad se govori o korisniku, u dokumentu se podrazumijeva da korisnik može biti osoba koja nekoj usluzi pristupa privatno, da korisnik može biti osoba koja nekoj usluzi pristupa kao djelatnik nekog TDU-a, ili kao osoba koja usluzi pristupa kao djelatnik neke organizacije ili tvrtke. No u isto vrijeme sustav je predviđen da korisnik može biti i druga usluga (znači ne više osoba) te da na isti način pristup razmjeni podataka između dvije usluge obrađuje u skladu sa specifičnostima takvih zahtjeva.

Uz sve gore navedeno sustav ipak ima određenu središnju točku koja upravlja radom sustava. Nacionalna IAA agencija (NIAAA) predviđena je kao mjesto upravljanja radom sustava kao i mjesto na kojem se nalaze opće usluge te autentikacijske i autorizacijske usluge najviše razine općenitosti i prihvaćenosti. Koje tijelo će preuzeti funkciju NIAAA u ovom dokumentu nije definirano i ostavlja se za odluku institucijama nadležnim za uspostavu cjelokupnog nacionalnog IAA sustava.

Komunikacija između dionika sustava koji posjeduju lokalne autentikacijske i autorizacijske module obavlja se kroz sigurnu nacionalnu IAA mrežu dok se komunikacija između korisnika i pružatelja pojedinih usluga odvija preko različitih mreža od kojih neke mogu biti sigurne a neke otvorenog tipa ovisno o samoj usluzi. Danas već postoji uspostavljena Hitronet mreža koja je pogodna i za funkciju nacionalne IAA mreže dok se sigurni segmenti mreže prema komercijalnim sudionicima mogu lako uspostaviti.

U okviru sustava predviđena je mogućnost uključivanja više organizacija i tijela koja pružaju određene autentikacijske i autorizacijske funkcionalnosti. Ovaj prijedlog sustava omogućuje i konkurenciju određenih sustava čime se za pojedine usluge može omogućiti više alternativnih pružatelja autentikacijskih i autorizacijskih mehanizama, a time i pronalaženje efikasnijih, jeftinijih, bržih mehanizama te brojnih kombinacija ovisno o specifičnim potrebama servisa. Dok je za neke nacionalne usluge možda takav izbor manje primjenjiv, za neke druge usluge ili za npr. komercijalne pružatelje usluga on može biti itekako atraktivan.

Na sljedećoj slici (slika 8) može se vidjeti osnovni način uspostave NIAAS sa stanovišta raspodjele identifikacijskih, autentikacijskih i autorizacijskih funkcionalnosti.


Osnovni prijedlog bio bi da NIAAA administrira opće usluge te autentikacijske i autorizacijske usluge najviše razine općenitosti i prihvaćenosti. Pod pojmom najviše razine smatramo razinu koja će vjerojatno biti prihvaćena kao referentna za većinu korisnika IAA sustava. U okviru nadležnosti NIAAA bila bi infrastruktura potrebna za osnovnu identifikaciju i autentikaciju. Prijedlog je da se identifikacija i autorizacija temeljena na OIB-u, te nekim osnovnim podacima o korisnicima obavezno koristi u okviru nadležnosti NIAAA. Naime, može se predvidjeti da će za većinu usluga namijenjenih građanima identifikacija te autentikacija i autorizacija, bez obzira na kasnije definirane i objašnjene sigurnosne razine, kao zajednički identifikator imati OIB. Svi ostali dionici koji koriste proširene IAA funkcionalnosti ili pak određene lokalne autorizacijske mehanizme mogu u okviru autorizacijskih procedura koristiti i NIAAA za provjeru osnovnih kriterija autorizacije čime se ostvaruje ranije spomenuti hijerarhijski model.

Slika 8. Uspostava NIAAS


Kao što se na primjeru iz slike 8 može vidjeti, NIAAS omogućuje različite mogućnosti autorizacije. U osnovnom scenariju korisnik (građanin, službenik, tvrtka) pristupa usluzi kod npr. nekog TDU. Ovisno o sigurnosnoj razini te modelu autorizacije pristup servisu može biti odobren temeljem komunikacije sa NIAAA korištenjem sigurne veze od TDU prema NIAAA. Pristup može biti odobren temeljem odobrenja od lokalnog sustava autorizacije, temeljem lokalnog sustava koji dio provjera odradi s NIAAA, ali i temeljem korištenja proširenog autorizacijskog sustava nekih drugih dionika u sustavu.

U isto vrijeme ovakva arhitektura sustava omogućuje da se na različite načine obrađuju zahtjevi za autorizacijom različitih sigurnosnih razina. Tako za određenu sigurnosnu razinu može biti dovoljan samo NIAAA dok će neku drugu višu sigurnosnu razinu morati biti uključen lokalni sustav ili kombinacija više njih.

Na ovaj način moguće je implementirati različite scenarije upravljanja autorizacijama a prema zakonskim nadležnostima za pojedine registre ili pojedine tipove usluga kojima korisnik želi pristupiti.

Generalna uloga sinkronih i asinkronih sučelja. Ilustracija na slici 9 prikazuje tipično korištenje sinkronog i asinkronog sučelja:

Autentikacija i autorizacija putem Web sučelja se odvijaju u stvarnom vremenu (sinkrona komunikacija), kao i autentikacija korisnika na trećoj strani.

Interakcije zasnovane na porukama kao npr. poslovni obrasci između privatnih ili poslovnih korisnika i TDU, ili između TDU međusobno, se koriste za asinkronu komunikaciju. Iako su ove interakcije asinkrone, moguć je trenutan odgovor dijela sustava na takve poruke.


Slika 9. Pravila korištenja sinkrone i asinkrone komunikacije

3.1.1 Opis životnog ciklusa u procesu utvrđivanja identiteta

1. Inicijalna registracija u identifikacijski sustav (jednokratno) i povezivanje sa OIB-om

2. Autentikacija i autorizacija

3. Zahtjev za uslugom

4. Izvršavanje/prikazivanje zahtjevnih podataka (i eventualno naplaćivanje)

3.1.2 Detaljni opis pojedinih faza životnog ciklusa

1. Inicijalna registracija u identifikacijski sustav i povezivanje sa OIB-om

Predaja zahtjeva za dobivanje ID

Inicijalna provjera identiteta osobe

Kreiranje ID-a osobe, sinkronizacija s podacima iz OIB i drugih registara

Izdavanje autentikacijskih podataka (username, password, certifikati, biometrija i sl.)


Hijerarhijska i distribuirana arhitektura upravljanja dozvolama

Definicija pripadnosti sigurnosnim razinama

2. Autentikacija i autorizacija

Slanje korisničkih autorizacijskih podataka

Verificiranje autorizacijskih podataka

Provjera mogućnosti pristupa, sigurnosnih razina,...

Povezivanje osobe s podacima u bazi

3. Zahtjev za uslugom

Dobivanje upita od strane korisnika

4. Izvršavanje/prikazivanje zahtjevnih podataka (i eventualno naplaćivanje)

Dohvat traženih podataka i slanje korisniku

Inicijalna registracija. Krajnji korisnik koji još nema elektronski identitet i potrebne faktore autentikacije kojim je moguće utvrditi identitet na raznim sigurnosnim razinama treba predati zahtjev za dobivanje elektronskog identiteta u najbližoj ispostavi neke od široko rasprostranjenih državnih agencija, kao što su FINA, Hrvatska Pošta ili HZZO. Pri tome se vrši inicijalna fizička provjera identiteta osobe i provjera vjerodostojnosti predočenih podataka (slika 10).

Slika 10. Inicijalna registracija


Registracija postojećih korisnika. Najčešći scenarij uporabe NIAAS je autentikacija krajnjih korisnika koji su već registrirani u sustavu (slika 11). To omogućuje krajnjim korisnicima prijavu na portal korištenjem njihovih identifikatora (korisničko ime\lozinka ili uporaba digitalnog certifikata).

Slika 11. Registracija postojećih korisnika

Koraci u zahtjevu za uslugom prikazani na slici 12. U trenutku kada korisnik pristupi pojedinom servisu davatelja usluga, odnosno tijela državne uprave (korak 1), potrebno je izvršiti autentikaciju. Davatelj usluge (TDU) šalje zahtjev centralnoj agenciji za autorizaciju (korak 2) pri čemu kao povratnu informaciju dobiva rezultat autorizacije (korak 3). Ukoliko je autorizacija uspjela (korak 4), šalje se upit pojedinom registru unutar TDU, odnosno vrši se TRC (Trust relationship Contract) – uspostava relacije povjerenja prema registrima drugih TDU ako se traženi podaci nalaze u njima. U koracima 5 i 6 se rezultat zahtjeva za uslugom prvo isporučuje pružatelju usluge, te se potom predočava krajnjem korisniku.


Slika 12. Koraci u zahtjevu za uslugom

Procedure upravljanja životnim ciklusom certifikata u FINA-i

Zadaće organizacijskih dijelova u FINA PKI po ovim poslovima su:

1. Inicijalno izdavanje certifikata

Varijanta I.

Varijanta II.

2. Obnova certifikata i ključeva

3. Vraćanje ključeva

4. Opoziv certifikata

5. Suspenzija certifikata

Točke koje slijede će opisati svaku od ovih aktivnosti i definirati postupke korisnika FINA PKI i postupke i odgovornosti LRA i RA u tim aktivnostima.

Varijanta I.

Postupci po ovoj varijanti inicijalnog izdavanja certifikata su:


Zaprimanje i obrada zahtjeva u LRA FINA PKI

I&A u LRA FINA PKI (i alternativna rješenja)

Upis tražitelja certifikata u Registar korisnika FINA PKI

Odobravanje zahtjeva i generiranje aktivacijskih (inicijalizacijskih) podataka

Distribucija aktivacijskih (inicijalizacijskih) podataka

Isporuka aktivacijskog koda

Generiranje certifikata i ključeva

Provedba sigurnosnih postupaka

Objava certifikata u imeniku

Varijanta II.

Postupci po ovoj varijanti inicijalnog izdavanja certifikata su:

Zaprimanje i obrada zahtjeva u LRA FINA PKI (i alternativna rješenja)

I&A u LRA FINA PKI (i alternativna rješenja)

Upis tražitelja certifikata u Registar korisnika FINA PKI

Odobravanje zahtjeva i generiranje certifikata

Distribucija Smart kartica i PIN-ova

Obnavljanje ključeva i certifikata

Ako certifikat nije opozvan, korisnik treba dobiti obavijest putem e-pošte da može u roku od tri mjeseca prije isteka roka valjanosti certifikata dostaviti zahtjev za izdavanje novog certifikata, sa pripadajućim parom ključeva. Takav zahtjev može biti poslan u LRA ili RA elektroničkom porukom potpisanom starim parom ključeva. RA izdaje novi identifikacijski broj i autorizacijski kod s kojima korisnik može registrirati svoj novi javni ključ i preuzeti svoj novi certifikat.

Za korisnike koji koriste FINA ID certifikate, obnova ključeva na CA provodi se automatski temeljem mrežnog PKIX-CMP protokola i uz pomoć SW instaliranog kod korisnika (u tu svrhu korisnik treba biti priključen na računalnu mrežu preko kojeg je dostupan FINA PKIX-CMP servis


za obnovu certifikata). Korisnik vrši generiranje novih ključeva i njihovu registraciju prije njihovog isteka.

Obnavljanje certifikata znači kreiranje novog certifikata sa istim imenom subjekta, ali sa novim parom ključeva, rokom valjanosti i novim serijskim brojem, pri čemu se onemogućuje korištenje starog certifikata istog subjekta od trenutka izdavanja novog certifikata.

Certifikat se može obnoviti ako:

paru ključeva nije istekao rok valjanosti,

privatni ključ nije kompromitiran,

informacije o subjektu su ispravne.

Vraćanje ključeva

Vraćanje ključeva je servis za korisnike ID certifikata. Da bi se izbjegle moguće zlouporabe, I&A korisnika jednak je onom kao kod inicijalne registracije korisnika.

Opoziv

Opoziv se zahtjeva kada korisnik više ne treba certifikat, ili kada je privatni ključ korisnika kompromitiran ili se sumnja u kompromitiranost.

Korisnik (fizička osoba-građanin/poslovni subjekt) može zatražiti opoziv certifikata u bilo kojem trenutku zbog bilo kojeg razloga. Korisnik mora odmah uputiti zahtjev za opoziv certifikata, ako:

neka od informacija u certifikatu promijeni ili zastari

dođe do kompromitiranja privatnog ključa ili medija na kojem je spremljen

osoba ovlaštena za potpisivanje više ne radi kod poslovnog subjekta ili više nema ovlasti za potpisivanje

RA može opozvati certifikat iz slijedećih razloga:

zahtjev suda ili nadležnog organa

informacija u certifikatu je izmijenjena ili nije više valjana

kompromitiranost ili sumnja na kompromitiranost privatnih ključeva, ili sadržaja na medijima


propust korisnika u ispunjavanju obveza iz Ugovora o certifikatu

ako CA/RA smatra da certifikat nije izdan pravilno, odnosno u skladu sa navodima i obvezama iz Ugovora o certifikatu, CP-a ili PDS-a za DEMO certifikate

Procedure za opoziv certifikata

Zahtjev za opoziv certifikata treba u najkraćem roku biti predan izravno u RA ili putem LRA koji je autoriziran da prihvati takve zahtjeve u ime RA.

Zahtjev za opoziv može biti poslan elektroničkim kanalima ako je pritom potpisan privatnim ključem korisnika. Ako se zahtjev podnosi osobno, potrebno je na osnovu identifikacijskog dokumenta izvršiti I&A podnositelja zahtjeva kao i kod zaprimanja Zahtjeva za izdavanje certifikata.

Kada CA ili RA zahtjeva opoziv bez zahtjeva korisnika ili LRA zaposlenika, tada CA/RA mora dokumentirati razlog za opoziv. Svi autenticirani zahtjevi za opoziv i sve rezultirajuće akcije koje poduzima RA, biti će bilježeni i pohranjeni u skladu sa CP-om.


4 MODELI IDENTIFIKACIJE I AUTORIZACIJE

4.1 Definiranje potrebnih razina pristupa korisnika

Razina autentikacije može zavisiti od kvalitete identifikatora te isto tako od pristupne metode. Manje povjerljivi identifikator ili udaljeniji pristup doprinosi jačim zahtjevima na autentikaciju. Pristupna metoda pokazuje da je korisnik u uredu tvrtke već prošao fizičku kontrolu sigurnosti, ili se može pokazati sigurnosna razina pristupne metode – mobilni telefon je manje siguran nego kućna veza. Sve ovo utječe na zahtijevanu razinu autentikacije te na razinu dodijeljene autorizacije.

4.1.1 Identifikacija potrebnih razina pristupa

Autentikacija služi za verifikaciju identiteta, kako bi se spriječila impersonalizacija (krivo predstavljanje), te kako bi se osigurala razina povjerenja koja je nužna za korištenje ovlaštenja (autorizacija). Vrsta zahtijevane autentikacije zavisit će od kvalitete identifikatora, pristupne metode, i zahtijevanih ovlaštenja (privilegija). Sve ove informacije ne moraju biti poznate na prvom kontaktu gdje se provodi inicijalna registracija. Što se zahtijevaju veća prava (više privilegije) to mora biti jača autentikacija.

Višestruka autentikacija

U modelu višestruke autentikacije svaka aplikacija ima potpunu kontrolu korištenog identifikatora za entitet i metode za autentikaciju. To zahtjeva da se korisnik autenticira za svaku aplikaciju, računalni sustav ili mrežu, što povećava administraciju. Dodavanje ili odstranjenje korisnika obično zahtjeva ažuriranje mnogih baza identifikacije i autentikacije.

Potreba za višestrukom autentikacijom proizlazi zbog različitosti sustava, mreža i aplikacija koji svi koriste vlastitu identifikaciju i autentikaciju. Sustav provodi svoju vlastitu autentikaciju bez obzira da li postoji određena razina povjerenja u autentikaciju koja je provedena od drugog sustava.

Jednostruka autentikacija (SSO)

Jednostruka autentikacija po sesiji, (single sign-on, SSO), je velika prednost za korisnike. Povijesno, svako računalo, svaki program, svaka usluga mora se autenticirati pojedinačno. To je dovelo do situacije gdje se je korisnik morao prijaviti na mrežu, prijaviti na računalo, te ponovo prijaviti na aplikaciju. Sa SSO autentikacijom korisnik se autenticira jednom po sesiji i tada prezentira identifikacijske ključeve (credentials, službene potvrde-dozvole) svakom sustavu ili aplikaciji koja treba imati mogućnost identifikacije entiteta. To zahtjeva da sustav autentikacije


treba biti poznat i povjerljiv za sva računala, mreže i aplikacije koje bi inače trebale provoditi autentikaciju.

SSO može biti također pogodan za administratore, budući da kreira standardni postupak autorizacije kroz tvrtku. On također kreira centraliziranu bazu podataka informacija za autentikaciju. Time se također kreira jedna točka administracije za upravljanjem korisničkom autentikacijom. SSO zahtjeva distribuirani proces autentikacije zbog performansi i raspoloživosti. Najveća zapreka primjeni jest što sve aplikacije moraju koristiti neku od standardiziranih metoda autentikacije. Za novi razvoj to nije problem, ali za postojeće aplikacije te za integraciju sa komercijalnim programima to može biti skupo te može zahtijevati značajno vrijeme implementacije. SSO nije prikladan za sve sigurnosne razine. Korisnički identiteti koji u jednoj okolini imaju povećana prava (administratori) bi se uvijek trebali tretirati nekim drugim načinom prijave na sustav koji uključuje snažniju autentikaciju.

Višerazinska autentikacija (prema snazi autentikacije)

Višerazinska autentikacija je proces koji zahtjeva različite vrste autentikacije koje ovise o metodi pristupa, zahtijevanim sredstvima, te zahtijevanim dozvolama. Time se dozvoljava bolja implementacija principa najnižih ovlaštenja, te se može proširiti pristup do nezaštićenih lokacija ako je korisnik dovoljno autenticiran.

Razmotrimo slučaj opće namjenske bankovne kartice. To može biti smart kartica koja sadrži e-novac, ATM kartica, ID kartica za druge bankovne transakcije. Upotreba kartice kao gotovinske kartice možda neće zahtijevati nikakvu autentikaciju iznad one koja provjerava fizičko posjedovanje kartice, budući iznos novca može biti limitiran na relativno mali iznos. Korištenje kartice na ATM uređaju zahtjeva fizičku karticu i PIN broj kako bi se vršio polog ili podizanje novca do umjerenih granica. No pored toga, sa bankovnom ID karticom mogu se zahtijevati jači postupci autentikacije budući se njome omogućavaju transferi veće količine novaca. U tom slučaju se mogu zahtijevati biometrijski postupci, otisci prsta ili fotografije. Razina autentikacije zasnovana na razini zahtijevane autorizacije nije rijetka.

4.1.2 Identifikacija uloga korisnika

Slijedi kratak pregled vrsta krajnjih korisnika koji se mogu pojaviti na pristupnom portalu u sustav.

Pojedinci. Sustav može dopustiti neregistrirane (anonimne) osobe koje će imati mogućnost navigacije web-sjedištem, pregledavanja sadržaja bez dodavanja, mijenjanja i korištenja usluga za koje nije potrebna autorizacija (kao npr. obavijesti pojedinog TDU od općeg interesa). Oni također mogu ispuniti pojedine obrasce i dostaviti ih putem portala anonimno. Kada se krajnji


korisnik registrira sa svojim autentikacijskim faktorima (i dobije pravovaljanu autorizaciju od autorizacijske agencije) može učiniti sve gore navedene radnje, te je osim toga u mogućnosti pristupiti pojedinim uslugama koje sadrže tajne ili povlaštene informacije, kao i ažurirati svoje osobne podatke (što može uključivati personalizaciju podataka, dostupnost pojedinih usluga itd.). Predočeni poznati faktori autentikacije za usluge dostupni su na cijelom spektru usluga koje su omogućene na portalu. U ovom scenariju krajnji korisnik se može prijaviti za bilo koju uslugu ili aplikaciju od treće strane bez direktne posjete portalu treće strane (i ponovnim autoriziranjem).

Organizacije. Organizacije predstavljaju pravni subjekt kojega zastupaju pojedinci koji su nositelji prava pristupa u ime organizacije. Moguće je diferencirati različite uloge unutar iste organizacije.

Agenti. Agenti su organizacije kojima je formalno dozvoljeno da djeluju u korist pojedinca ili drugih organizacija u cilju izvršavanja usluga dostupnih na portalu sa svim specifičnim funkcionalnostima dostupnima i putem web servisa.

Aplikacije. Automatizirane aplikacije koje opet moraju biti autenticirane i ograničene u privilegijama (npr. "backup aplikacija").

4.2 Detalji implementacije

U izradi i implementaciji koncepta pridruživanja različitih tehnika pristupa različitim razinama pristupa potrebno je pridržavati se sljedećih principa:

Sigurnost – moraju se zaštiti informacije u vlasništvu korisnika i pružatelja usluge.

Prihvatljivost – nužno je da predloženi principi autentikacije budu općenito prihvatljivi potencijalnim korisnicima, uzimajući u obzir različite potrebe korisnika, te izbjeći stvaranja barijera korištenjem otvorenih i detaljno dokumentiranih protokola i standarda koji su široko prihvaćeni i implementirani u drugim zemljama.

Zaštita privatnosti – osigurati da predloženi pristup autentikacije štiti privatnost na odgovarajući način.

Sveobuhvatni pristup – balansiranje korisnika i pružatelja usluga oko neovisnosti informacija, te troškovno učinkovitog rješenje za sve zainteresirane strane.

Prilagođenost zahtjevima – izbjegavanje nepotrebne kompleksnosti, u skladu s pretpostavkom da će razine autentikacije potrebne za većinu transakcija biti relativno niska.


Fokusiranje na korisnika – osiguravanje da su preporučena rješenja dovoljno praktična, jednostavna za korištenje i tehnološki i platformski neovisna što je više moguće.

Trajnost rješenja – definiranje rješenja koje je trajno te dovoljno fleksibilno kako bi podržalo moguće promjene i širok spektar aktualnih i budućih transakcija.

Dostupnost i pouzdanost – osiguravanje široke mogućnosti pristupa.

Analiza rizika – pružanje pristupa temeljenog na dogovorenoj razini povjerenja u cilju zaštite identiteta i osobnih informacija.

Pravna usklađenost – rješenje mora biti u skladu sa relevantnim zakonima, uključujući i pravo na zaštitu privatnosti.

Pravna sigurnosti – odnos između stranaka mora biti reguliran na način da pruža pravnu sigurnost.

Nepovredljivost – pitanje nepovredljivosti treba razmatrati za one transakcije koje to zahtijevaju, tako da stranke kasnije ne mogu zanijekati da su sudjelovale u transakcijama.

Funkcionalna jednakost – autentikacijski zahtjevi trebaju biti slični onima koji se primjenjuju na postojeće transakcije, osim gdje priroda on-line transakcija značajno mijenja razinu rizika.

Da bi zadovoljila nabrojane principe ali i očekivanu svjetsku razinu sigurnosti, implementacija mora biti ostvarena uz sukladnost sa standardom ISO 27001.

4.2.1 Definiranje svojstava faktora autentikacije

Razina i vrsta autentikacije zavisi od vrste identifikatora, pristupne metode, zahtijevane autorizacije, te područja koje je pokriveno autentikacijom. Potrebno je osigurati adekvatnu autentikaciju kako za lokalne pristupe unutar sigurnosne brane tvrtke (firewall), tako i za udaljene pristupe sa javne mreže. Treba imati mogućnost obrade širokog spektra korisnika koji koriste informatička sredstva informacijskog sustava. Postoje korisnici koje ne treba autenticirati. Takvi korisnici, što uključuje programe, računalne mreže i dr., moraju imati mogućnost da dokažu da su oni entiteti za koje se deklariraju. Isti faktori, „nešto što znaš“, „nešto što imaš“, i „nešto što jesi“ se primjenjuju u autentikaciji neljudskih entiteta. Neljudski entiteti se obično oslanjaju na dijeljenim tajnama ili mjerljivim svojstvima (kriptografska kontrolna suma) koja verificiraju identitet.


Dvostrana autentikacija

Dvostrana autentikacija može imati jednosmjernu i dvosmjernu shemu. U jednosmjernoj shemi, klijent mora biti autenticiran od strane servera, no server ne treba biti autenticiran od strane od strane svog klijenta. U dvosmjernoj shemi, klijent i server moraju biti međusobno autenticirani jedan prema drugome. Dvosmjerni protokol može se jednostavno sastojati od dva nezavisna jednosmjerna protokola. Ponekad se međusobna autentikacija može provesti kroz isti protokol razmjene.

Mnoge dvostrane autentikacijske sheme se temelje na činjenici da i korisnik i uslužna strana (peer) znaju jednu ili više informacija koje ne zna nitko drugi. Ta informacija se naziva dijeljena tajna. Poznavanje tajne je dokaz identiteta za korisnika. Mehanizmi kreiranja tajnih informacija trebaju osigurati da samo te dvije strane znaju tajnu ukoliko su uključene moguće i drugi. Općenito, tajna informacija mora biti distribuirana izvan normalnih komunikacijskih kanala za koje se provodi autentikacija.

Striktno govoreći, korisnik i uslužna točka (peer) ne moraju poznavati isti komad informacije. Uslužno mjesto zna informaciju koja se može izvesti samo iz tajne koju posjeduje korisnik. U drugim slučajevima, informacija koja se dijeli nije uopće tajna, kao što je u slučaju autentikacije korištenjem kriptografije javnog ključa, kada korisnik dijeli sa svojim partnerom javni ključ.

Razlike između različitih shema dvostranih autentikacija leže u tome kako se autentikacijska informacija, autentikacijska funkcija i očekivani rezultati kreiraju, spremaju i prenose između dviju strana.

Autentikacijska informacija može biti ili statička (npr. fiksna lozinka) ili dinamička (npr. one-time lozinka OTP - jednokratna lozinka, bez obzira da li je implementirana u sklopovskom uređaju – tokenu, ili programski). Ako je autentikacijska informacija dinamička, njena promjena zavisi od klijenta, servera ili oboje. Slično, očekivani rezultati mogu imati iste vrste varijacija. Autentikacijska funkcija može koristiti ili simetrični ili asimetrični kriptografski algoritam.

Nakon što je tajna kreirana, korisnik i poslužitelj moraju je pohraniti ili spremiti neki njen derivat. Dvije strane moraju imati međusobno povjerenje u djelotvornost pohranjivanja tajne: ako korisnik izgubi kontrolu nad tajnom, poslužitelj bi mogao dati uljezu mogućnost da dođe do vrijednih informacija; ako server izgubi kontrolu nad korisničkom tajnom, kompromitiran je korisnički identitet.

Sam akt autentikacije u komunikacijskim uvjetima zahtjeva da korisnik i uslužna točka izmjenjuju informaciju kroz komunikacijski kanal. U mrežnim uvjetima, autentikacijska shema treba imati u vidu da drugi mogu slušati što se prenosi u mreži.


Postoje mnoge varijante dvostranih autentikacijskih shema: lozinke, pobuda/odziv, one-time lozinke(OTP), token kartice, smart kartice i dr. Te vrste nisu međusobno isključive, te autentikacijske sheme obično imaju karakteristiku više od jedne vrste.

Lozinke

Kroz dugi period one su bile adekvatna metoda elektroničke autentikacije, ali sa povećanom pojavom računala, svaki sa svojom lozinkom, te implementacijom e-poslovanja gdje je svatko u svijetu korisnik, lozinke bi smjele predstavljati buduće potrebe elektroničkog društva.

Ponovljive lozinke su najraširenija metoda za autentikaciju danas. U ovom načinu rada koristimo istu lozinku svaki puta kada autenticiramo svoj identitet. Ponovljive lozinke su jednostavne za korištenje i lake za implementaciju, no sa njima ima dosta problema. Prvo one moraju biti lake za pamćenje, budući da se ne smiju zapisivati, a moraju biti teške za pogađanje. Tradicionalno, sigurnosni konzultanti savjetuju izbor lozinki koje se teško pogađaju i koje se trebaju često mijenjati.

Drugi je problem da su ponovljive lozinke, ako su implementirane na trivijalan način, sklone uobičajenim napadima – razbijanje lozinki i njuškanju po mreži. Moć današnjih računala se koristi u pogađanju lozinki kroz pretraživanje imenika. Često kada se lozinka probije njezino kompromitiranje se ne otkriva kroz duže vrijeme što daje napadaču dovoljno vremena da učini štetu i pobriše svoje tragove. Njuškanje po mreži je praćenje prometa u mreži od klijenta do servera ponekad u izvornom tekstu, pa čak i ako je lozinka kriptirana, kroz komunikaciju lozinka se može probiti ukoliko je enkripcija sumnjiva.

Lozinke za jednu upotrebu (One-time Pasword, OTP) predstavljaju strategiju korištenja lozinke samo jednom, pa i ako je ona uhvaćena, ona se ponovo ne koristi i ne predstavlja nikakvu prijetnju za buduće korištenje. OTP lozinke su potrebne zbog pojave mreža i raspodijeljenog računarstva: korištenje lozinki koje se koriste u mreži bez enkripcije dovodi do njuškanja i traženja lozinki po mreži. Strategija OTP lozinki se zasniva na sekvenci pseudoslučajnih brojeva, gdje se za danu slučajnu vrijednost može izračunati slijedeća lozinka (ne stvaraju ih sami korisnici). OTP lozinke se najčešće računaju u sklopovskim uređajima (tokenima). Računalne lozinke se često koriste, također u autentikaciji neljudskih entiteta. Ovisno o načinu implementacije, OTP lozinke mogu imati problema sa sinkronizacijom. To znači ako je implementacija zasnovana na vremenu tada sat (clock) u OTP uređaju mora odgovarati satu na sustavu na koji se želi pristup; ako se implementacija zasniva na korištenju, te ako se OTP uređaj koristi bez uspješne komunikacije sa host računalom, tada ta dva uređaja mogu izaći iz sinkronizacije. Kada se to dogodi, OTP uređaj treba biti sinkroniziran uz pomoć administratora.


Lozinke pobude/odziva su druga metoda kojom se adresira problem njuškanja lozinki po mreži. Sustav pobude/odziva se implementira tako da usluga izdaje pobudu na koju se očekuje ispravan odgovor. To se može implementirati sa različitim pitanjima koja zahtijevaju ispravne odgovore ili kroz korištenje kriptografije. Kriptografska pobuda/odziv metoda uzima pobudu, slučajni broj, kriptira ga, i vraća kriptiranu vrijednost. Usluga dekriptira odgovor kako bi vrednovala da je enkripcija izvršena sa ključem koji je znan samo specifičnom entitetu.

Autentikacija shemom lozinki je možda najstarija, ali još uvijek najraširenija dvostrana autentikacija. Korisnik i uslužno mjesto su prethodno dogovorili tajnu riječ ili frazu koju samo oni znaju. Informacija koju osigurava korisnik je sama lozinka.

Kao osnovna razina, autentikacijska funkcija je operacija usporedbe. Sheme autentikacije sa lozinkama imaju nekoliko nedostataka. Prvo, lozinke je često teško zapamtiti (te su zbog toga često zapisane negdje) ili su lagane za pogodit. Budući su lozinke generirane od ljudi one imaju karakteristike koje proizlaze iz kombinacije slova koje formiraju riječi. To omogućuje napade koji se nazivaju napad rječnika, a istraživanja pokazuju da se 40% lozinki pogađa korištenjem jednostavnih riječi ili njihovih kombinacija. Dodavanjem slučajnih vrijednosti lozinkama za vrijeme njihovog uskladištenja, što se naziva sjeme, povećava entropiju lozinki, što ih čini težim za pogađanje.

Drugi problem sa lozinkama je potreba za njihovim spremanjem. Uslužno mjesto (poslužitelj) mora spremiti lozinku, pa korisnik ovisi o fizičkoj sigurnosti poslužitelja. Jedan način smanjenja rizika je da se sprema različiti skup vrijednosti koji koristi hash u jednom smjeru. U tom slučaju autentikacijska funkcija je jednosmjerna hash funkcija, a očekivani rezultat je hash vrijednost lozinke. Budući da je jednosmjerna hash funkcija ireverzibilna, netko tko dođe do hash vrijednosti ne može rekonstruirati original, ali može pokušati napad tehnikama grube sile ili pokušavajući rekonstruirati hash iz tablica često korištenih lozinki. Ovi napadi se u praksi uspješno odbijaju korištenjem jedinstvenih slučajnih javno poznatih dodataka na lozinku (salt ili nonce).

Sljedeći problem sa lozinkama je da se prenose od korisnika do mjesta usluge preko mreže. Zavisno o sigurnosti mreže ili ovisno o korištenoj zaštiti prijenosa, lozinke mogu biti predmet prisluškivanja. Nije važno kako je lozinka izabrana, ako postoji mogućnost da se ona skine sa mreže. Budući je to pasivan napad, može proći dosta vremena dok se on otkrije.

Konačno, uslužno mjesto (server) nema mogućnost diskvalifikacije napadača od pogađanja stotine pokušaja u nadi da će jedan pogoditi. Neki sustavi prepoznaju takve napade te stavljaju korisnika u kutiju za penalizaciju u nadi da će odbaciti napadača.


Pobuda /odziv (CHAP)

Shema autentikacije pobuda/odziv je shema zasnovana na lozinkama u kojoj poslužitelj pita korisnika pitanje - to znači predstavlja pobudu - a korisnik mora odgovoriti na odgovarajući način ili autentikacija završava u grešci. Ovdje je autentikacija dinamička. Na primjer, korisnik i servisno mjesto imaju listu od 100 slučajnih riječi, i liste su egzaktno iste. Te liste su dijeljena tajna. Uslužno mjesto može pitati za 82 ulaz u listu, a korisnik mora dostavit taj element. Drugi primjer je upotreba dijeljene tajne kao ključa za enkripcijski algoritam. Uslužno mjesto šalje korisniku slučajnu frazu, korisnik je obradi korištenjem dijeljenog ključa te je vraća natrag. Uslužno mjesto također obradi frazu sa dijeljenim ključem te uspoređuje korisnički rezultat sa svojom vlastitom obradom. U ovom slučaju osigurana informacija od strane korisnika je slučajna fraza obrađena tajnim ključem.

Budući da pobuda dolazi od uslužnog mjesta, ono također određuje koliko pokušaja se dozvoljava prije nego nastupa predaja. Uslužno mjesto može također zatvoriti korištenje od strane takvog korisnika za određeni period vremena.

OTP lozinke (jednokratne lozinke)

Jedna od glavnih nedostataka sheme lozinki, kao što je spomenuto, da netko može doći do dijeljene tajne prisluškujući prijenos lozinke od korisnika do uslužnog mjesta. Čak i ako je dijeljena tajna ključ kojim se kriptira pobudna vrijednost, skupljanje dovoljno primjera pomaže razbijanju ključa ako izbor pobuda/odziv sustav nije dobro dizajniran. Napadač može tada za svoje potrebe ponoviti lozinku ili odgovor uslužnom mjestu te može preuzeti identitet originalnog korisnika. Jedan način da se to spriječi je uvođenje OTP lozinki , o kojem slučaju je lozinka valjana samo za jednu sjednicu autentikacije – ne prije i ne poslije. U tom slučaju napadač ne može ponoviti uhvaćenu lozinku ili odziv (odgovor). Tipično je da se lista OTP lozinki međusobno generira od strane korisnika i uslužnog mjesta. Naravno da je održavanje liste lozinki samo za sebe složenije nego držanje jedne lozinke, te OTP lozinke same za sebe ne smanjuju mogućnost proboja fizičke sigurnosti na uslužnom mjestu.

Token kartica

Metode autentikacije zasnovane na lozinkama imaju jedan ozbiljan problem, koji ne može fiksirati niti jedan algoritam ili protokol, a to je ljudski faktor u petlji. Lozinke moraju biti teške za pogoditi, te se moraju često mijenjati. Nažalost, “teško za pogoditi” povlači “teško za zapamtiti”. Korisnici izabiru lozinke tako da im nešto znače: rođendan, imena djece ili neka uobičajena riječ od šest do osam slova. Takve lozinke imaju slabu entropiju te se lako pogađaju napadom grube sile kao napad na rječnik. Dobre lozinke su duge i slučajne. Ipak, svaka lozinka, neovisno o tome koliko je duga i slučajna se može pogoditi ukoliko imamo dovoljno vremena. Korisnici koriste


istu lozinku predugo od straha da će novu zaboraviti. Strah od zaborava vodi k tome da se lozinka zapisuje. Dijeljena tajna je dobra samo ako se dijeljena informacija drži tajnom, shema je kompromitirana u trenutku kada tajna pada u pogrešne ruke.

Jedan način da se zaobiđu nedostaci ljudskog faktora je da imamo uređaj koji donosi lozinke. Token uređaj služi toj namjeni. Token uređaj generira različiti niz od osam znakova svaki puta kada se upotrijebi, pa je ona specijalni slučaj OTP sheme. Važna stvar kod token uređaja je da one održavaju niz koji je predvidiv. Neki token uređaji drže algoritam za generiranje tajnim; druge koriste tajno sjeme sa poznatim algoritmom. Mehanizam generiranja je poznat samo autentikatoru i token uređaju. Nakon što je token uređaj sinkronizirana sa uslužnim uređajem, korisnik može koristiti tokene generirane od uređaja kao lozinku.

Svaki token uređaj ima jedinstvenu početnu 64-bitnu vrijednost koja se kombinira sa algoritmom za generiranje slučajnih brojeva kako bi se generirao novi kod svakih 60 sekundi. Samo pripadni server zna koji je broj isparavan u danom momentu za tu kombinaciju korisnika i karticu. Korisnički unesen PIN se kombinira sa vrijednošću tokena kako bi se formirala autentikacijska informacija, tako da golo posjedovanje token uređaja nije dovoljno za dokaz identiteta.

Pametne kartice

Naziv pametna (smart) kartica opisuje komplet malog, veličine kreditne kartice, elektroničkog uređaja koji se koristi za pohranu podataka i identifikaciju. Pametne kartice su integrirani sklopovi sa memorijom i procesorom. Pametne kartice sa procesorom mogu imati svoj vlastiti operacijski sustav i mogu izvoditi programe. U stvari, pametne kartice dokazuju da su one idealno mjesto za implementaciju kriptografskih algoritama i smještaj ključeva, posebno kada je uključen kriptografski koprocesor kako bi se ubrzao algoritam kriptiranja.

ISO ima nekoliko standarda u razvoju koji upravljaju vrstama i sučeljima koji se odnose na identifikacijske kartice. ISO 7816 specificira identifikacijske kartice sa elektroničkim kontaktima, njihove fizičke karakteristike, lokacije kontakata, prijenosne protokole za podatke na ulazu i izlazu.

Slično pojavi kreditnih kartica, pametne kartice spremaju informaciju na ugrađeni mikroprocesorski chip koji se može čitati sa osobnim identifikacijskim brojem (PIN), rađe nego sa magnetskim zapisom (stripom), koji može biti pročitan od bilo koga. Ona se može koristiti za sigurno spremanje i obradu informacije za različite aplikacije.

Pametne kartice se mogu koristiti kako za fizičku identifikaciju tako i za elektroničku (digitalnu) identifikaciju. One se mogu štampati sa slikom vlasnika, te mogu sadržavati elektroničku


identifikaciju unutar svoje elektronike. To je fizički identifikator, čije posjedovanje se zahtjeva kako bi se dobio pristup. Kada se koristi sa lozinkom (PIN) tada se lako osigurava dvofaktorska autentikacija.

Fizička identifikacija se zahtjeva kako bi se osigurala fizička sigurnost. Uobičajeno je da se zahtjeva fizički ID kako bi se dozvolio pristup sredstvima tvrtke. Fizički ID obično sadrži fotografiju pojedinca. Pametne kartice mogu sadržavati identifikaciju za centraliziranu kontrolu ili podatke za pristup za lokalnu kontrolu.

Elektronička (digitalna) identifikacija se koristi za svaki elektronički pristup. Ova identifikacija će biti autenticirana elektronički bez bilo kakve ljudske intervencije. Elektronički čip na pametnoj kartici može sadržavati privatni ključ pojedinca, smješten u kriptiranoj formi, sa PIN-om koji je poznat samo tom pojedincu. Dakle, posjedovanje kartice i poznavanje PIN-a dozvoljava pojedincu korištenje privatnog ključa za autentikaciju.

Pametne kartice imaju nekoliko prednosti u komunikacijskoj okolini. Informacija tajnog ključa je zapisana u EEPROM-u koji je zaštićen od proboja mehanizmom kao što su ireverzibilni osigurači i senzori za fluktuacije napona. Budući da ključ nikada ne napušta karticu, autentikacija korištenjem pametne kartice umjesto čovjeka na tipkovnici je pojačana. Kartica je portabilna, tako da ključevi slijede osobu. Budući da svako korištenje ključa daje napadaču više informacije kako bi razbio ključ, pametna kartica održava točan broj upotrebe pojedinog ključa. Pametna kartica je ipak ranjiva. Naime, signal se mora prenijeti od pametne kartice do uređaja za autentikaciju, on je podložan prisluškivanju.

Tehnologija pametnih kartica je mehanizam za sigurno spremanje autentikacijske potvrde i omogućuje njihovu prenosivost. Dakle pametne kartice se mogu koristiti kako u dvostranim autentikacijama tako i u autentikaciji od povjerljivih trećih strana.

Svrha pametnih kartica

Ranije navedene tehnologije predstavljaju jednu od ključnih tehnoloških podloga za korištenje PKI infrastrukture u sigurnosnim sustavima. Naime, uporaba kriptografskih ključeva izvan sigurne okoline kompromitira cjelokupnu arhitekturu sigurnosnog sustava. Ako neki od npr. tajnih ključeva napusti sigurnu okolinu i postane dostupan osobama koje nisu njegovi vlasnici tada cijeli protokol osiguranja vjerodostojnosti postaje ništavan. U tom smislu pametne kartice omogućuju da tajni ključ nikada ne napušta sigurnu okolinu i nemoguće ga je pročitati, a njegovo korištenje omogućeno je samo unutar sigurne aplikacije koja se izvodi na samoj kartici. Na taj način osigurano je funkcioniranje kriptografskih algoritama, a u isto vrijeme i tajnost pojedinih ključeva.


Ručni uređaji za autentikaciju (HHAD - Hand Held Autentication Device)

HHAD su prenosivi uređaji, obično u veličini kreditnih kartica, koji imaju lokalno spremište podataka i mogućnost računanja. Oni koriste različite tehnika za izdavanje jedinstvenih OTP ili pobuda-odziv lozinki. Lozinke su obično prikazane na LCD ekranu tako da su čitljive za korisnike. Ti uređaji (token, watchdog) obično zahtijevaju PIN te imaju ugrađenu listu sa ključevima. Isti algoritmi koji se koriste u HHAD uređajima mogu se programirati u informacijskom sustavu za autentikaciju. Postoje više vrsta takvih uređaja.

Uređaji zasnovani na sekvenci izdaju nove lozinke svaki puta kada se uređaj koristi. Ako je uređaj neuspješno korišten ili ako je aktiviran bez uspostave veze na poslužitelj, tada poslužitelj i kartica izlaze iz sinkronizacije, te se zahtjeva primjena neke metode koja će provesti ponovnu sinkronizaciju kako bi kartica bila ponovno korisna.

Uređaji zasnovani na vremenu generiraju novu lozinku svake specifične jedinice vremena. Neispravno vrijeme na serveru može dovesti do toga da uređaj postane beskoristan.

Uređaji zasnovani na certifikatima sadrže digitalne certifikate, što su u stvari strukture podataka koje povezuju identitete korisnika i njihovih pripadnih ključeva. One se izdaju od ovlaštenih certifikacijskih centara (CA). Certifikati zajedno sa pripadnim ključevima mogu se koristiti za autentikaciju i digitalno potpisivanje, a isto tako i za druge operacije sigurnosnih protokola kao što je razmjena ključeva. Strukture se lako integriraju u WEB aplikacije koje koriste SSL protokol.

Biometrijska autentikacija

Biometrijska autentikacija koristi jedinstvenost izvjesnih fizičkih svojstava i karakteristika pojedinaca, kao što su otisci prstiju, slika rožnice oka, uzorak glasa ili facijalne karakteristike. Ta fizička svojstva ili karakteristike mogu se reprezentirati digitalno kao biometrijski podaci ili biometrija. Biometrija je jedini način da budemo popuno sigurni da je pojedinac onaj za koji se je deklarirao.

U prošlosti, biometrija je bila potisnuta problemima koštanja i točnosti. Nove tehnologije su povećale točnost i snizile cijenu koštanja. Danas su skeneri za otiske prstiju kao i drugi biometrijski uređaji široko raspoloživi i dostupni po cijeni. Ti proizvodi obično smještaju biometriju pojedinaca na server računalo te koriste senzore za detekciju ili mjeru pojedinaca na osnovi stvarnog vremena. Ako se prikupljena biometrija slaže sa pohranjenim podatcima, dotični je pojedinac autenticiran. Kako bi se smanjio rizik od krivog predstavljanja biometrije od strane korisnika (budući da su to obično elektronički podatci koji se mogu reproducirati),


sofisticirani sustavi koriste više kombinacija biometrije te forsiraju variranje signala. Na primjer, uređaj za dobru autentikaciju može imati osjet temperature prsta, vlažnost kože, te brzinu i pritisak, pored standardnog ispitivanja otiska.

Neljudski entiteti koji zahtijevaju autentikaciju mogu koristiti svoje vlastite mjere. Kriptografska kontrolna suma se može izračunati kako bi se odredilo da li je program ono za što kaže da je, dok sklopovski uređaji imaju stalnu identifikaciju, kao što su serijski brojevi, koji su neizmjenjivi.

U doba krađe digitalnih identiteta biometrijske tehnike autentikacije postaju sve značajnije. Pretpostavka je da je biometrija - mjerenje fizikalnih svojstava ili ponašanja mnogo je pouzdaniji pokazatelj identiteta nego postojeći sustavi lozinki i PIN-ova. Zbog toga se instaliraju sustavi plaćanja zasnovani na otisku prsta kao i na graničnim prijelazima za kontrolu putovnica. Postoje tri načina da se identificiramo na računalni sustav na osnovu „onoga što znamo“, „onoga što imamo“ i „onoga što jesmo“. Ono što znamo, lozinka ili PIN, je nešto što je slabo pouzdano budući da može biti ukradeno, izgubljeno ili pogođeno. Ono što imamo, kao što su RFID kartice i tokeni (kriptirana informacija o identitetu na memorijskoj kartici) također može biti ukradeno. Stoga projektanti sustava za autentikaciju koriste dvofaktorsku shemu token (ono što imamo) i lozinku (ono što znamo).

Biometrija pripada klasi „ono što jesmo“, te se može podijeliti u fiziološka rješenja ili rješenja koja su vezana na ponašanje. Rješenja koja su vezana na ponašanje uključuju prepoznavanje potpisa, prepoznavanje glasa, dinamiku tipkanja i analizu hoda. Fiziološka rješenja uključuju otiske prstiju, ispitivanje dužice i mrežnice oka, ruke, prsta, lica, geometriju uha, žile na rukama, podnožje noktiju, otisak dlana.

Autentikacija kroz povjerljivu treću stranu

Kao što je prethodno opisano, korištenje dvostrane sheme autentikacije zahtjeva da korisnik i uslužno mjesto dijele komad tajne informacije. Svaki par korisnika i uslužne točke mora dijeliti različite komade tajne informacije. Kako broj tajnih informacija raste sve je teže upravljanje kreiranjem, spremanjem i prijenosom tajnih informacija.

Sheme povjerljivih trećih strana koriste specijalni entitet (ili njih više), čija je odgovornost pomoć pri autentikaciji. Kada se korisnik mora autenticirati na uslužnoj točki, treća povjerljiva strana garantira (potvrđuje) za korisnički identitet ili osigurava informaciju koja se može koristiti u autentikaciji. Oboje, korisnik i poslužitelj vjeruju trećoj strani koja osigurava uslugu autentikacije. Povjerljiva treća strana može koristiti i simetričnu i kriptografiju javnog ključa.

Sustav javnog ključa već ima ugrađen mehanizam za autentikaciju. Tako dugo dok postoji jednoznačno preslikavanje javnog ključa i korisnika koji ga je kreirao, te tako dugo dok korisnik


drži privatni ključ tajnim, postupak kriptiranja ili potpisivanja je dokaz identiteta. Problem u toj shemi je uspostava povjerljivog preslikavanja od korisnika na korisnikov javni ključ. Praktično rješenje je koristiti povjerljivu treću stranu koja garantira i potvrđuje to preslikavanje i međusobnu pripadnost. Postoje dva rješenja, hijerarhijski autoritet, kako se koristi u X.509 PKI (Public Key Infrastucture) infrastrukturi, te mreža povjerenja, kako se koristi u PGP (Pretty Good Privacy).

X.509 PKI infrastruktura

Kako bi se provela autentikacija, korisnik pristupa CA (certifikacijsko tijelo) sa dokazom svog identiteta i javnim ključem. CA izrađuje certifikat sa imenom korisnika koje je jedinstveno u cijelom sustavu (i naziva se razlikujuće ime), korisničkim javnim ključem, te nekim drugim informacijama koje se koriste za jasnoću i valjanost certifikata. Certifikat je tada digitalno potpisan od strane CA. Svatko tko vjeruje u legitimnost od CA će vjerovati u sadržaj certifikata, a prema tome i u identitet korisnika. Izdani certifikati se obično spremaju u bazu podataka sustava, a CA zadržava kopiju u slučaju dokazivanja i obrane.

CA ima ugrađeno povjerenje unutar konteksta sustava koji poslužuje CA. On može izdavati svoje vlastite certifikate. Jedan važan certifikat je njegov vlastiti koji povezuje (preslikava) CA sa njegovim javnim ključem; vlastito potpisan certifikat se često smatra korijenskim (root) certifikatom.

Ponekad je samo jedan CA za cijeli sustav, ali često ovakav aranžman stvara veliku navalu na jedan entitet za autentikaciju. CA-ovi mogu biti raspoređeni u hijerarhiju, kako je pokazano na slici 13. Certifikat CA je potpisan direktno sa CA direktno iznad njega: CA1 potpisuje certifikate za CA3 i CA4, a CA4 potpisuje certifikate za CA6. Kada korisnik A, sa certifikatom koji je potpisan od CA5 , želi biti autenticiran od korisnika B, mora postojati certifikacijski put od A do B: A je potpisan od CA5, koji je potpisan od CA3, koji je potpisan od CA1, koji potpisuje CA4, koji je potpisan CA6, a koji potpisuje korisnika B. Ova dva korisnika moraju imati jednu zajedničku točku povjerenja u certifikacijskoj hijerarhiji – u ovom slučaju to je CA1. Korisnik A ne može biti autenticiran kod korisnika C budući da ne postoji zajednička točka povjerenja.


Slika 13. Primjer X.509 certifikacijske hijerarhije

Certifikati nose podatak o vremenskom periodu valjanosti, tako da će oni s vremenom nestati. Kada certifikat nije više valjan iz nekih drugih razloga, kada se npr. mijenjaju korisnički atributi, tada je potrebno opozvati certifikate. CA objavljuje listu opoziva CRL (Certificate Revocation List). Bilo koji certifikat u CRL listi se proglašava nevažećim. Problem sa CRL je taj da ona nije specijalno vremenski upravljana, budući da opozivi nisu vremenski predvidivi, pa su objave CRL liste obično periodičke i ne mogu biti prečeste.


5 OKVIRI I SMJERNICE ZA SIGURNU KOMUNIKACIJU UNUTAR SUSTAVA

Svrha dokumenta je analiza sigurnosnih aspekata, definiranje mogućih prijetnji i definiranje kontrolnog sustava za upravljanje digitalnim identitetima.

5.1 Izrada koncepta analize sigurnosnih aspekata

Smjernice za ispravnu i sigurnu komunikaciju se zasnivaju na izboru identifikatora, pri čemu treba definirati neka svojstva identifikacije:

Odrediti što će se koristiti za identifikatore

Odlučiti tko će izdavati identifikatore

Postaviti zahtjeve neophodne za izdavanje identifikatora

Odrediti zahtjeve na identifikaciju za svaku klasu transakcija

Odrediti kako će se identifikacija administrirati

Izlistati zahtjeve za izdavanje identifikatora

Odrediti razloge za opoziv identifikatora

Odlučiti kako će se informacija o identifikatorima implementirati i koristiti

Digitalni potpis mora imati sva svojstva vlastoručnog potpisa, a to su sljedeća:

1) vlastoručni potpis je autentičan, a to znači da ga može izdati samo potpisnik osobno,

2) vlastoručni potpis moguće je provjeriti usporedbom s prethodnim potpisima,

3) vlastoručni potpis izražava autorstvo ili slaganje sa sadržajem dokumenta i njegov je neodvojivi dio,

4) vlastoručni potpis ne može se poreći.

Ova svojstava ne znače da se vlastoručni potpis ne može krivotvoriti, ali postoje metode s kojim se može s velikom sigurnošću utvrditi da li je on krivotvoren.


Dokumente u digitalnom obliku lako je mijenjati, a da bi oni imali pravnu ili neku drugu vrijednost potrebno im je osigurati autentičnost. Ta autentičnost se osigurava digitalnim potpisivanjem dokumenta. Digitalni potpis je u osnovi funkcija sadržaja digitalnog dokumenta i privatnog ključa potpisnika. Vjerodostojnost potpisanog dokumenta se obavlja upotrebom sadržaja dokumenta i javnog ključa potpisnika.

Digitalni potpis se može izraziti formulom:

Digitalni potpis = E[ H( m ), SA ] ,

a digitalno potpisani dokument:

Digitalno potpisani dokument = { m; E[ H( m ), SA ] },

gdje su:

m – digitalni dokument koji se potpisuje,

H( m ) – sažetak digitalnog dokumenta, a H funkcija sažetka,

SA – privatni ključ potpisnika,

E – funkcija kriptiranja (asimetrično kriptiranje).


Slika 14. Protokol digitalnog potpisivanja dokumenta: digitalni dokument potpisuje Alice te ga šalje Bobu, a Bob ga nakon primitka provjerava, gdje je D funkcija dekriptiranja, PA javni ključ

koji pripada Alice, H'( m ) sažetak kojeg izračunava Bob iz primljeno

Digitalno potpisivanje bit će objašnjeno na sljedećem primjeru (slika 14). Pretpostavimo da Alice šalje dokument Bobu. Ona nekim određenim algoritmom sažimanja sažme digitalni dokument. Taj sažetak kriptira svojim privatnim ključem (ovdje je potrebno istaknuti da asimetrični algoritam kriptiranja mora imati prethodno objašnjeno svojstvo koje omogućava i kriptiranje privatnim ključem, a dekriptiranje javnim ključem). Na taj način je digitalno potpisala dokument. Šalje dokument s digitalnim potpisom (digitalno potpisani dokument) Bobu. On po primitku digitalno potpisanog dokumenta izdvaja njegov sadržaj, sadržaj bez potpisa, te izračunava njegov sažetak istim algoritmom sažimanja koji je koristila Alice. S Aliceinim javnim ključem dekriptira digitalni potpis istim asimetričnim algoritmom kojim ga je Alice kriptirala. Dekriptirani sadržaj digitalnog potpisa uspoređuje sa sažetkom koji je on izračunao. Ako je usporedba uspjela onda se radi o autentičnom i besprijekornom dokumentu kojeg je uistinu poslala Alice. Bob zna da je taj dokument poslala Alice jer samo ona zna svoj privatni ključ. Na ovaj način je moguće postići osobine vlastoručnog potpisa:

1) digitalni potpis je autentičan, što znači da ga može napraviti samo posjednik privatnog ključa,

2) digitalni potpis je moguće provjeriti uporabom javnog ključa potpisnika,


3) digitalni potpis izražava autorstvo ili slaganje sa sadržajem dokumenta, a pošto je funkcija dokumenta slijedi da je neodvojiv od sadržaja,

4) digitalni potpis se ne može poreći.

Važno je istaknuti da uz sve ove sigurnosne zahtjeve, integritet, autentičnost i neporecivost, digitalni potpis ne osigurava tajnost.

Digitalni certifikat je digitalno potpisani dokument koji povezuje javni ključ s osobom kojoj pripada (vlasnikom javnog ključa). Uveden je iz tog razloga što sudionici u komunikaciji, da bi uopće mogli komunicirati, moraju na neki način doznati ključeve svojih partnera. Osim toga, moraju biti uvjereni da partneri nisu uljezi koji se lažno predstavljaju. Certifikat se digitalno potpisuje iz tog razloga što se osigurava njegov integritet, koji jamči potpisnik. Potpisnik digitalnog certifikata naziva se certifikacijski centar (engl. Certification Authority - CA). Certifikacijski centar (CA) je ustanova ili tijelo kojoj svi korisnici certifikata vjeruju i čiji javni ključ, koji se koristi za provjeru potpisa na certifikatu, mora biti pouzdano ispravan. O certifikacijskim centrima bit će riječi u nastavku ovog rada.

Sve ove sigurnosne mehanizme navedene u ovom poglavlju objedinjuje složeni sustav u kojem se odvija sigurna komunikacija, a koji se naziva infrastruktura javnog ključa (engl. Public Key Infrastructure - PKI). Jedan od osnovnih modela certifikata koji čini osnovu za ostvarenje velikog broja sustava temeljenih na PKI – u ima oznaku X.509 (slika 15).


Slika 15. Verzija 3 digitalnog certifikata X509.

Objašnjenja pojedinih polja X.509 certifikata (odozgo prema dolje):

1. Verzija – Moguće vrijednosti su v1, v2 i v3.

2. Serijski broj – Pozitivan cijeli broj koji je jedinstven unutar CA, a aplikacija koja ostvaruje CA brine se o ispunjenju ovih uvjeta.

3. Potpis – Identifikacija algoritma koji je korišten pri potpisivanju certifikata od strane CA.

4. Izdavač – Polje koje služi za identifikaciju izdavača certifikata, a ime organizacije koja se upiše u ovo polje mora biti javno registrirano ime organizacije, i u sklopu njega mora biti minimalno ime države izdavanja certifikata. Dozvoljeni su i drugi elementi koji pobliže definiraju organizaciju.


5. Period važenja (valjanosti) – U ovom polju se definira period valjanosti certifikata i u njemu su definirana dva datuma. To su datum početka valjanosti certifikata i datum prestanka valjanosti certifikata.

6. Subjekt – Ovo polje identificira entitet vezan sa javnim ključem. Za kvalificirani certifikat ovo polje mora imati vrijednost prepoznatljivog imena subjekta (definiranih u standardu X.500).

7. Informacija o javnom ključu subjekta – Ovo polje sadrži javni ključ subjekta i podatke o korištenom kriptografskom algoritmu.

8. Jedinstveni ID izdavača – Ovo polje je opcionalno i RFC3280 ne preporučuje njegovo korištenje.

9. Jedinstveni ID subjekta – Ovo polje je također opcionalno i RFC3280 ne preporučuje njegovo korištenje.

10. Proširenje – Opcionalno polje koje omogućuje proširenje.

11. Digitalni potpis – Digitalni potpis (prethodno opisana polja certifikata se digitalno potpišu) od strane CA.

5.1.1 Analiza integriteta i dostupnosti poruka

Integritet informacije znači da su informacije autentične i potpune i možemo se osloniti na to da su dovoljno precizne za svoju svrhu. Termin integriteta često povezan sa informacijskom sigurnosti, jer predstavlja jedan od primarnih pokazatelja sigurnosti.

Kriptografski postupci matematičke su funkcije, odnosno algoritmi kojima se nizovi bitova jasnog teksta preračunavaju u nizove bitova kriptiranog teksta i obratno. Kriptiranje je postupak prevođenja podatka u izvornom obliku (jasni tekst ili engl. cleartext) u oblik u kojem se taj podatak više ne raspoznaje (kriptirani tekst ili engl. ciphertext). Kriptiranje se formalno može zapisati u sljedećem obliku:

C = E(P, KE),

gdje su:

P – jasni tekst,

C – kriptirani tekst,


E – funkcija kriptiranja,

KE – ključ kriptiranja.

Obrnuti postupak prevođenja kriptiranog teksta u jasni tekst naziva se dekriptiranje. Njegov formalni opis je:

P = D(C, KD),

gdje su:

P – jasni tekst,

C – kriptirani tekst,

D – funkcija dekriptiranja,

KD – ključ dekriptiranja.

Funkcije kriptiranja i dekriptiranja zajedno čine kriptosustav.

Glavni ciljevi kriptografije ili sigurnosni zahtjevi su povjerljivost, raspoloživost, besprijekornost, autentikacija, autorizacija te neporecivost. Prva tri zahtjeva osnovni su sigurnosni zahtjevi.

1. Povjerljivost ili tajnost osigurava da sadržaj informacije bude pristupačan samo ovlaštenim korisnicima (korisnicima kojima je namijenjena), i nikomu drugomu.

2. Raspoloživost osigurava da informacije budu na raspolaganju ovlaštenim korisnicima.

3. Besprijekornost ili integritet osigurava da informacije u sustavu mogu mijenjati samo za to ovlašteni korisnici, odnosno osigurava nepromjenjivost podataka.

4. Autentikacija je postupak provjere identifikacije odnosno utvrđivanje vjerodostojnosti korisničkog identiteta.

5. Autorizacija je postupak koji obuhvaća provjeru ovlasti odnosno provjeru prava pristupa za autenticiranog korisnika.

6. Neporecivost predstavlja zaštitu od opovrgavanja, a to znači onemogućavanje negiranja prethodno počinjenog dijela od strane korisnika.

Sve sigurnosne zahtjeve osim raspoloživosti rješava kriptiranje.


Slika 16. Prikaz sudionika komunikacije u kojoj se koristi kriptiranje. Alice šalje poruku Bobu kriptiranu ključem KE, a Bob je dekriptira ključem KD, dok Eve predstavlja neovlaštenog

korisnika koji može prisluškivati nesigurni kanal.

Važno je istaknuti da u prikazu na slici 16. komunikacija između izvora i odredišta predstavlja sigurni kanal zahvaljujući kriptiranju poruka.

Osnovna podjela kriptografskih algoritama je na simetrične i asimetrične algoritme (simetrična i asimetrična kriptografija). Više o simetričnim i asimetričnim algoritmima kriptiranja može se naći u Prilogu 3.

5.1.2 Analiza identifikacijskih ključeva

Da bi se osigurala autentikacija identiteta putem identifikacijskih ključeva, potrebno je ispuniti sljedeće uvjete:

Niti jedan korisnik ili uređaj nije imao pristup privatnom ključu pri identifikaciji

Javni ključ je odgovarajući za dotični privatni ključ

Proces generiranja potpisa ne može biti izdan od strane nekog drugog uređaja.

Ovaj problem potrebno je promatrati kroz fokus Public Key Infrastructure (PKI).

Infrastruktura javnog ključa (PKI) složeni je sustav koji objedinjuje certifikate, certifikacijsku ustanovu (certifikator), bazu certifikata i opozvanih certifikata, korisnike certifikata, te sve


njihove međusobne interakcije. Prije svega PKI je sustav koji omogućuje autentikaciju. Koristeći simetričnu i asimetričnu kriptografiju osigurava brojne usluge uključujući povjerljivost podataka, njihov integritet te upravljanje ključevima (key managament), odnosno certifikatima.

PKI arhitektura

Osnovne komponente PKI sustava su krajnji entitet ili korisnici PKI sustava, certifikacijski centar ili certifikator (engl. Certification Authority – CA), registracijski centar ili registrator (engl. Registration Authority – RA), spremnik ili baza valjanih i opozvanih certifikata (engl. Certificate/CRL Repository), te izdavač opozvanih certifikata (engl. CRL Issuer), slika 17.

Slika 17. PKIX sustav, sustav infrastrukture javnog ključa temeljenog na X.509.

Objašnjenje pojedinih komponenti:


1. Krajnji entitet – subjekti certifikata, a ponekad se zovu i krajnji korisnici, koji ne moraju biti fizičke ili pravne osobe već i uređaji kao što su serveri i usmjernici, zatim programi i procesi, odnosno sve što može biti identificirano imenom na certifikatu.

2. Certifikacijski centar (CA) – ustanova koja potpisuje i izdaje certifikate. Osnovne operacije certifikacijskog centra su izdavanje certifikata, njihovo obnavljanje i po potrebi njihov opoziv. CA svojim potpisom jamči ispravnost podataka u certifikatu. CA izravno ili preko registracijskog centra (RA) registrira krajnje entitete ili korisnike i verificira njihov identitet na odgovarajući način. CA obavlja ponekad i funkciju sigurnog pohranjivanja ključeva. On je izvor povjerenja u PKI, a povjerenje je osnova na kojoj se zasniva PKI.

3. Registracijski centar (RA) – opcionalna komponenta PKI sustava, a može biti i dio certifikacijskog centra. Kao što mu i samo ime kaže, njegova uloga je vezana za registriranje krajnjih entiteta, odnosno korisnika PKI sustava. Osim ove uloge, RA može provjeravati posjeduje li korisnik privatni ključ koji odgovara javnom ključu koji će se nalaziti na certifikatu, ili može sam generirati par ključeva. On može biti i posrednik između korisnika certifikacijskog centra prilikom informiranja o kompromitiranju privatnog ključa. Sve ove funkcije su obavezni dio PKI sustava, te ako ih ne obavlja RA mora ih obavljati CA. RA je također i korisnik PKI sustava te ima svoj javni ključ i certifikat izdan od ovlaštenog CA. RA ne smije obavljati funkcije izdavanja i opoziva certifikata.

4. Spremište ili baza certifikata – predstavlja sustav ili skup distribuiranih sustava koje pohranjuju certifikate i listu opozvanih certifikata, dostupnih svim unutarnjim ali i vanjskim korisnicima PKI sustava koji koriste certifikate za identifikaciju.

5. Izdavač opozvanih certifikata – komponenta PKI sustava koja izdaje listu opozvanih certifikata. Certifikati se izdaju s određenim periodom valjanosti. Certifikati iz raznih razloga mogu postati nevažeći i prije isteka tog perioda. Svaki opozvani certifikat identificiran je svojim serijskim brojem u listi opozvanih certifikata. Lista opozvanih certifikata je javno dostupna svima.

5.2 Izrada koncepta definiranja mogućih prijetnji

Vrste rizika koje se mogu pojaviti i na strani korisnika i na strani davatelja usluge mogu prouzročiti:

neugodnosti kod nositelja identiteta;

rizik od gubitka imovine i ugroženu osobnu sigurnost za nositelja identiteta;


objavljivanje osobnih ili komercijalno osjetljivih podataka trećim osobama;

rizik od financijskog gubitka za bilo koje stranu;

rizik gubitka ugleda za korisnike, uključujući i gubitak povjerenja građana prema vladinim servisima i tijelima državne uprave;

učinke na počinjenje ili otkrivanje teških zločina.

5.2.1 Identifikacija prijetnji u komunikaciji

S pojavom interneta kao dio osnovnog komunikacijskog okruženja pojavilo se mnoštvo prijetnji pri razmjeni informacija. U kontroli komunikacije bitno je osigurati sljedeća svojstva:

Identitet korisnika

Autorizaciju korisnika

Integritet podataka

Sigurnost i povjerljivost podataka

Raspoloživost podataka

Također, prijetnju u komunikaciji predstavlja i pojava grešaka u identifikaciji. Greške identiteta uzrokovane su miješanjem identifikatora za dva različita entiteta. Može se dogoditi da identifikatori nisu jedinstveni zbog nepažnje od strane ljudi koji ih uspoređuju. Problem često prođe nedetektiran kada se informacija smjesti pod pogrešnim identifikatorom. To je sve do momenta kada se treba informacija, pa informacija uzrokuje konfuziju ili gore posljedice. Mnoge greške identiteta se događaju budući da se informacija sprema sa identifikatorom koji nije jedinstven ili se zlorabi. Teško je formirati listu atributa koja će jednoznačno identificirati osobu bez izdavanja e-osobnih iskaznica. Tvrtke nastavljaju upotrebu imena, datuma rođenja, djevojačko ime majke i sl. kako bi se jednoznačno identificirao pojedinac. Međutim, često se događa provjera samo dijela identifikatora te pretpostavi da su korisnici u redu, a u stvari nisu.

Prijetnja identiteta. Prijetnja u iskazivanju vlastitog identiteta se pojavljuje u slučajevima kad se jedna osoba identificira kao neka druga stvarna osoba ili kao neka imaginarna osoba. Zbog toga je potreban poseban oprez pri identifikaciji osobe, odnosno potrebno je zahtijevati predočenje onih faktora ili atributa kojima je moguće jednoznačno odrediti identitet zahtjevatelja usluge, pri čemu je identifikacija moguća svojstvima koja su povezana s nečim što znamo, nečim što imamo ili nečim što jesmo.


Prijetnje pri prijenosu podataka u Internet okolini. Budući da se i identifikacijski i korisnički podaci prenose putem Interneta, potrebno je ispravno podesiti parametre sigurne komunikacije. Tu su uključeni pristupni poslužitelji, mrežni usmjernici, korištenje sigurnog komunikacijskog protokola (https), kao i detektiranje incidenata i ispravno postupanje s istima.

Kod distribuiranih sustava postoji niz potencijalnih sigurnosnih prijetnji od strane napadača kao i sa strane legitimnih korisnika. Te potencijalne prijetnje se mogu klasificirati u dvije skupine.

Prvu skupinu čine napadi na računala domaćine (host) u sustavu. Tu spadaju razne vrste napada počevši od lakših oblika kao što je mijenjanje određenog procesa do preuzimanja kontrole nad cijelim računalom.

Drugu skupinu čine napadi na komunikacijske kanale u kojima se komunikacija odvija putem poruka. Ova skupina se može podijeliti na tri podskupine:

o T1 – prisluškivanje poruka koje putuju komunikacijskim kanalima

o T2 – namjerna izmjena i umetanje poruka u mreži kako bi se sabotirala izvorna informacija i zamijenila nekom drugom

o T3 – odgovor na stare poruke (kombinacija T1 i T2)

5.2.2 Analiza uporabe certifikata

Osim izdavanja digitalnih certifikata izdavač certifikata mora pružati i druge usluge, uključujući upravljanje certifikatima i vremensko ograničavanje valjanosti certifikata. Da bi se to pravilno odredilo potrebno je zadovoljiti sljedeće karakteristike:

Opseg valjanosti – identitet osobe, organizaciju vrijednosti certifikata, podatke o nositelju certifikata

Robusnost – sigurnost ključa, pouzdanost

Troškovi i učinkovitost – podaci o zahtjevima, održavanje, kontekstualni rizici

Transparentnost – jednostavnost, razumijevanje, dostupnost podataka

Teret odgovornosti – dijeljenje rizika i odgovornosti.


5.2.3 Koncept sustava upravljanja digitalnim identitetima

Registracija zahtijeva od klijenta da pruži nepobitne dokaze o osobnom identitetu. Za ispunjavanje ovog cilja, razina povjerenja o klijentu (dokaz identiteta) mora biti dovoljno robustan kako bi se zadovoljile potrebe za bilo koju uslugu agencije. Uspostaviti potreban nivo povjerenja znači zadovoljiti sve komponente sa sljedećim ciljevima:

Utvrditi da postoji identitet (tj. da identitet nije fiktivan).

Utvrditi da je to „živući“ identitet.

Utvrditi da povezanost osobe koja se predstavlja tim identitetom sa samim identitetom.

Omogućiti najviši stupanj povjerenja o jedinstvenosti identiteta podnositelja zahtjeva za traženu uslugu.

Omogućiti najviši stupanj povjerenja o jedinstvenosti identiteta podnositelja zahtjeva kao osobe.

Registracija će biti uspješna i certificirana samo ako su zadovoljeni sve ove komponente.

5.2.4 Definiranje ulaznih točaka pri pristupu u sustav

Ulazne točke za pristup u sustav moguće je podijeliti na udaljene (lokalne) i centralne, pri čemu se lokalne nalaze na mjestima pogodnim za korisnike i povezane su putem interneta, a centralne se nalaze u vladinim agencijama ili sigurnim lokacijama i povezane su na sustav putem intraneta.

5.3 Nadgledanje i upravljanje sustavom

Obzirom na postojeće stanje i na postojeće trendove u sustavima upravljanja elektroničkim identitetom pri ostvarivanju usluga elektroničke uprave (i elektroničkih usluga općenito), u ovom poglavlju prikazan je prijedlog uspostave takvog sustava kroz uspostavu NIAAS agencije. Pojam "agencija" u navedenom prijedlogu ima više zastupljenu svoje logičko značenje, nego fizičko u smislu da se u ovom poglavlju opisuju osnovni zahtjevi te specificiraju ovlasti odnosno funkcionalnost iste kao krovnog servisa koji će omogućiti upravljanje elektroničkim identitetom i njegovu primjenu pri ostvarivanju elektroničkih usluga. Stoga je osnovna uloga NIAAS-a u sljedećim komponentama:


Objedinjeno mjesto prijave korisnika (registracije) za usluge elektroničke uprave

SSO funkcionalnost pri korištenju usluga eUprave

Ostvarivanje interoperabilnosti među TDU koji ostvaruju usluge elektroničke uprave u području utvrđivanja elektroničkog identiteta

Ostvarivanje interoperabilnosti prema pan-europskoj inicijativi korištenja elektroničkog identiteta

Zbog postojećih sustava autorizacije koji trenutno funkcioniraju na razini TDU i zbog tendencija uvođenja novih sustava, nužno je postići konsenzus oko izbjegavanja redundantnih funkcionalnosti na razini RH, što je i svrha ovog projekta gledano s aspekta autentikacije i autorizacije. Isto tako je nužno da TDU kao i tijela lokalne uprave koja žele iskoristiti objedinjeni sustav autentikacije i autorizacije stimuliraju korištenje navedenog sustava te da u svoje planove uključe gašenje postojećih redundantnih i lokaliziranih sustava autentikacije.

5.3.1 NIAAS: Prijedlog registracijske i autorizacijske agencije

Da bi korisnici mogli pristupiti pojedinim uslugama eUprave, potrebno je da dokažu svoj identitet. Isto tako, korisnici žele biti sigurni da pristupaju ovlaštenoj i autentičnoj usluzi eUprave. Taj odnos vjerodostojnosti ostvaruje se kroz uspostavu autentikacijskih i autorizacijskih mehanizama. S druge strane, prihvaćenost pojedine usluge odnosno servisa eUprave ovisi o lakoći korištenja istog. Budući da su središnja mjesta ostvarivanja usluga dislocirana po pojedinim TDU entitetima, procesi autentikacije i autorizacije korisnika usluga predstavljaju problem u takvom okruženju. Moguće rješenje predstavlja organizacija sustava sa jednom agencijom koja bi u sustavu bila objedinjena točka pristupa pojedinim servisima. Ovo rješenje predstavlja jedan od mogućih modela prikazanih u tabeli 19. Za svaki model navedeni su i njegove osnovne značajke.

Tabela 19. Modeli autorizacije

Model 1: Centralna agencija sa sljedećim

aktivnostima:

točka registracije za sva TDU

točka izdavanja (ili zaprimanja zahtjeva) vjerodajnica (engl. credentials) za ostvarenje usluga eUprave

pohrana podataka o identitetu i vjerodajnicama relevantnih za ostvarenje usluga eUprave

potvrda valjanosti vjerodajnica prema TDU koje realizira uslugu


Model 2: Centralna agencija sa sljedećim

aktivnostima:

točka registracije za sva TDU

točka izdavanja (ili zaprimanja zahtjeva) vjerodajnica (engl. credentials) za ostvarenje svih usluga eUprave

bez spremanja podataka o identitetu i vjerodajnicama relevantnim za ostvarenje usluga eUprave

potvrda valjanosti vjerodajnica prema TDU koje realizira uslugu

Model 3: Više agencija sa sljedećim aktivnostima:

korisnik može odabrati jednu od više agencija koja će:

o izvesti registraciju za sva TDU

o proslijediti vjerodajnica (engl. credentials) za ostvarenje usluga eUprave

o pohraniti podatke o identitetu i vjerodajnica relevantnih za ostvarenje usluga eUprave

o potvrditi valjanosti vjerodajnica prema TDU koje realizira uslugu

Model 4: Svako TDU će obaviti:

registraciju korisnika za usluge u svojoj domeni

izdati vjerodajnice za ostvarenje usluga u svojoj domeni

S obzirom na trenutno stanje (Poglavlje 1.1), Model 2 se čini najprihvatljivijim za realizaciju. On omogućuje realizaciju sustava kroz federirano upravljanje elektroničkim identitetima. Sukladno tome, predlaže se osnivanje centralne nacionalne agencije za ostvarenje usluge NIAAS sa aktivnostima navedenim u tablici.

Osnovne usluge koje bi opsluživala NIAAS su:

1. Objedinjeno mjesto registracije korisnika, tj. pristupa korisnika pojedinim uslugama po prvi put.

2. Jedinstveno mjesto prijave korisnika usluga korištenjem istih autentikacijskih vjerodajnica (neovisno da li se radi o unosu korisničkog imena i lozinke, OTP-a, predaji digitalnog certifikata itd).

3. Omogućiti SSO funkcionalnost s ciljem omogućavanja korisnicima pristup uslugama iz raznih TDU pri čemu se korisnici preko NIAAS usluge autenticiraju samo jednom.


4. Sučelje za pridruživanje i propagaciju korisničkih vjerodajnica i odgovarajućih atributa specifičnih za ostvarivanje određene usluge te interoperabilnost među uslugama TDU (poglavlje 2.3.3).

5. Interoperabilnost među uslugama različitih TDU kroz postupke propagacije autentikacijskih vjerodajnica i međusobne razmjene odgovarajućih autorizacijskih atributa korisnika, usluga i drugih entiteta, kao npr. u sustavu federiranog upravljanja identitetima.

6. Razmjenu dokumenata i povjerljivih informacija između TDU usluga i vanjskih entiteta (korisnika, poslovnih procesa) ili unutarnjih entiteta (usluga drugih TDU, ...) na siguran način koji odgovara zahtijevanoj sigurnosnoj razini pojedine usluge.

Slika 18. Konceptualni pregled uloga NIAAS servisa i agencije

Konceptualno, uloga i osnovni elementi autentikacijskog i autorizacijskog servisa NIAAS prikazani su na slici 18:


Osnovna komponenta u sklopu NIAAS usluge je razmjena i propagacija identiteta u sustavu elektroničke uprave Republike Hrvatske. S obzirom na postojeće stanje, evidentno je da u sklopu više tijela državne uprave postoje identifikatorski direktoriji koji se trenutno koriste za lokalne potrebe. Isto tako, neke nove usluge elektroničke uprave niti ne moraju imati pristup lokalnom direktoriju elektroničkih identiteta, nego mogu koristiti direktorije drugih TDU uz uvjet da između TDU vlasnika usluge i TDU posjedovatelja direktorija postoji ugovorni odnos. Na taj način se troškovi održavanja sustava smanjuju te se eliminira mogućnost postojanja redundantnih sustava i resursa sa istom ili sličnom funkcijom. Uloga NIAAS usluge je međusloj koji će ostvariti interoperabilnost među TDU na području ostvarivanja autentikacijskih mehanizama te upravljanja elektroničkim identitetima. NIAAS će definirati standarde interoperabilnosti koje je potrebno implementirati da bi tijela državne uprave ili tijela lokalne uprave mogla koristiti autentikacijski servis za potrebe utvrđivanja elektroničkog identiteta korisnika.

Autorizacija građana predstavlja komponentu NIAAS sustava koja će omogućiti jedinstveno mjesto registracije za sve usluge elektroničke usluge i jedinstveno mjesto prijave odnosno prilaganja elektroničkih vjerodajnica. Svrha NIAAS-a je da ostvari SSO funkcionalnost kroz korištenje modula za propagaciju identiteta te pozadinskog sustava prikupljanja potrebnih atributa da bi korisnik mogao ostvariti traženu uslugu.

Autorizacija djelatnika TDU sadrži određene specifičnosti zbog njihove uloge u sustavu. Ostvarivanje neke usluge počinje postupkom zahtjeva iste od strane korisnika. U slučajevima kada se usluge sastoje od podusluga koje pripadaju različitim tijelima (agencijama), moguć je scenarij da djelatnici agencije od koje usluga potječe trebaju dohvatiti podatke iz druge agencije, ali u ulozi agenta za građanina koji je zahtijevao uslugu. Isto tako, djelatnici agencija koji sudjeluju u realizaciji usluga imaju različite autorizacijske atribute koji im daju veće ovlasti, što ih razlikuje od građana.

Autorizacija usluga omogućuje pristup određene usluge nekoj drugoj usluzi. Taj scenarij je moguć u slučajevima kada se zahtjeva impersonalizacija korisnika usluga ili kada sigurnosni zahtjevi pristupa nekoj usluzi dozvoljavaju anonimnost korisnika.

Repozitorij usluga je komponenta NIAAS sustava koja služi za registraciju svih usluga koje postupke utvrđivanja elektroničkog identiteta ostvaruju pomoću NIAAS-a.

Komponenta za nadzor (engl auditing, accounting) zadužena je za praćenje i pohranu transakcijskih aktivnosti u sustavu kao što su dostava atributa, realizacija usluga, pristupanje repozitorijima usluga itd. Uloge osoba i korisnika i interakcije sa uslugama mogu odvijati po složenim i scenarijima kada korisnici usluga mogu u različitim


instancama vremena poprimiti različite uloge (osobno, zaposlenik, druga usluga itd). Različite uloge koje određeni korisnik usluge može dobiti mogu sa sobom nositi i različita prava korištenja navedene usluge (servisa). Isto tako, ista uloga u uslugama koje izvode različita TDU može imati različita prava korištenja istih. Stoga je bitno u sustavu osigurati evidenciju i praćenje položaja odnosno ostvarenih uloga pojedinih korisnika te aktivnosti koje korisnik usluge izvodi.

5.3.2 Registracija korisnika za usluge eUprave

Kako je već prikazano u poglavlju 2.1.1, pojedine usluge u sustavu eUprave zahtijevat će odgovarajuće sigurnosne razine uspostave autentikacijskih i autorizacijskih odnosa. Isto tako, da bi korisnik mogao koristiti neku uslugu, nužno je da se isti korisnik/entitet registrira za navedenu uslugu kroz NIAAS agenciju. Registracija uključuje verifikaciju identiteta onoga tko želi koristiti određenu uslugu s ciljem kreiranja autentikacijskih vjerodajnica s kojima će klijent ostvarivati navedenu uslugu.

Konceptualno, autentikacija entiteta u sustavima elektroničkih usluga zahtjeva dvije faze, kako je to pokazano u poglavlju 2.1.1 , Slika 4:

1. Registracija korisnika: Proces u kojem se korisniku (fizička ili pravna osoba) dodjeljuju i uručuju elektroničke vjerodajnice kao što su npr. korisničko ime/zaporka, digitalni certifikat. Dobivene vjerodajnice korisnik će koristiti u drugom koraku.

2. Elektronička autentikacija pri korištenju usluga: Tijekom korištenja usluga elektroničke uprave, korisnik (fizička ili pravna osoba) koristi dobivene vjerodajnice s ciljem dokazivanja svoga identiteta.

Postupak registracije se može opisati u sljedećim koracima:

1. Dokazivanje identiteta: Provjera identiteta korisnika (bilo fizičke ili pravne osobe). 2. Dostavljanje elektroničkih vjerodajnica korisniku: Podatci o korisniku se spremaju u

sustav te se generiraju elektroničke vjerodajnice. Generirane vjerodajnice se isporučuju korisniku.

5.3.3 Zahtjevi na sigurnosne razine s obzirom na fazu registracije

U poglavlju 3 specificirane su potrebne autentikacijske razine s aspekta faze elektroničke autentikacije pri korištenju usluga. Međutim, bitno je napomenuti da su sigurnosne razine određene organizacijskim i tehničkim značajkama cjelokupnog procesa koji uključuje i korak


registracije. U ovom poglavlju definirani su zahtjevi prema postupku registracije entiteta s obzirom na autentikacijske razine.

Primijenjeni postupci pri postupku registracije (registracijski mehanizmi) predstavljaju ključni, prvi korak pri ostvarivanju zahtijevane sigurnosne razine (autentikacijske razine) odnosno ispunjenju njenih zahtjeva. Faktori koji utječu na registracijski mehanizam su sljedeći:

Identifikacija korisnika (dokazivanje identiteta): Potrebna dokumentacija odnosno isprave za utvrđivanje stvarnog identiteta korisnika, zahtijevana fizička prisutnost pri registraciji, verifikacija specifičnih atributa prije pokretanja postupka izdavanja elektroničkih vjerodajnica.

Izdavanje vjerodajnica (generiranje i dostava): Postupak izdavanja i dostavljanja vjerodajnica: osobno u materijalnom obliku ili putem elektroničke komunikacije (elektronička pošta) i sl.

Pouzdanost izdavatelja: Identitet i kvaliteta entiteta koji izdaje vjerodajnice CSP.

Navedeni faktori su od kritičnog značaja za ostvarenje odgovarajuće sigurnosne razine, i zasnovani su na autentikacijskim politikama implementiranim u sklopu IDABC projekta (3).

5.3.3.1 Identifikacija korisnika

U ovom postupku, potrebno je razlikovati mehanizme koji zahtijevaju/ne zahtijevaju fizičku prisutnost korisnika, te mehanizme koji zahtijevaju/ne zahtijevaju prilaganje odgovarajućih isprava te popis isprava u slučaju zahtijevanja.

Fizička prisutnost korisnika pri prvom pristupu sustavu odnosno nekoj usluzi uz predočenje odgovarajućih, pravno valjanih isprava predstavlja pouzdan mehanizam utvrđivanja identiteta tako da se u sklopu NIAAS sustava korištenje ovog mehanizma preferira lice-u-lice (eng. face to face) inicijalna registracija. Međutim, uzimajući u obzir trendove, utvrđivanje identiteta korištenjem drugih mehanizama ili strana s kojim je uspostavljen model povjerenja bi također trebalo biti dozvoljeno, u najmanju ruku na nižim sigurnosnim razinama. Zbog toga ova specifikacija dozvoljava uvođenje i drugih vidova registracije koji ne zahtijevaju fizičku prisutnost u trenutku kada atributi potrebni za registraciju budu dostavljeni od strana i na način koji su predviđeni zakonskim okvirom.

Tabela 20 prikazuje klasifikaciju zahtjeva za identifikacijom korisnika pri registraciji s obzirom na sigurnosnu razinu.


Tabela 20. Klasifikacija zahtjeva pri identifikaciji korisnika

Zahtjev Sigurnosna

razina 0 1 2 3 4

Nije potrebna registracija korisnika (korisnici su predregistrirani za razinu kroz sustav OIB-a)

x

Fizička prisutnost klijenta nije potrebna, registracija je ostvarena elektroničkim putem (online) pri čemu korisnik predstavlja svoj OIB kao

dokaz identiteta x

Fizička prisutnost klijenta pri registraciji je potrebna uz predočenje valjane identifikacijske isprave (osobna iskaznica, putovnica, ...)

ILI Fizička prisutnost nije potrebna, registracija je ostvarena elektroničkim

putem (online) na osnovu identifikacijskih podataka koji jedinstveno identificiraju korisnika i koji su potvrđeni (potpisani) od strane s kojom

postoji odnos povjerenja

x x x x

5.3.3.2 Izdavanje vjerodajnica

Drugi korak u postupku vjerodajnica čija svojstva utječu na sigurnosnu razinu je korak izdavanja vjerodajnica. Što je ovaj korak pouzdaniji, to će i u sustavu poveznica između stvarnog identiteta i elektroničkog identiteta tj. vjerodajnica u sustavu biti pouzdanija. Faktori koji utječu na ovaj korak su način dostave vjerodajnica, te način preuzimanja istih.

Tabela 21 prikazuje klasifikaciju zahtjeva za postupak izdavanja vjerodajnica pri registraciji s obzirom na sigurnosnu razinu.


Tabela 21. Klasifikacija zahtjeva za korak izdavanja vjerodajnica

Zahtjev Sigurnosna

razina 0 1 2 3 4

Nije potrebno slanje vjerodajnica x Vjerodajnice se šalju standardnom poštom pri čemu se mogu predati samo

osobno i na način koji spriječava neovlašten uvid u vjerodajnice ILI

Vjerodajnice se šalju elektroničkom poštom ili se mogu dohvatiti u trenutku registracije (online) pri čemu se zahtjeva promjena nekog od elemenata

vjerodajnica (obično. lozinka) pri prvoj primjeni

x

Vjerodajnice se preuzimaju osobno uz predočenje valjanih identifikacijskih isprava

x x x

5.3.3.3 Pouzdanost izdavatelja vjerodajnica

Treća komponenta čija svojstva utječu na ostvarenu razinu sigurnosti pri postupku registracije je pouzdanost izdavatelja elektroničkih vjerodajnica. U postojećim sustavima, izdavatelji fizičkih dokumenata za dokazivanje identiteta su tijela državne uprave, dok izdavatelji elektroničkog identiteta mogu biti i druge strane. Ovdje je bitno naglasiti razliku između kvalificiranih izdavatelja prema Aneksu 2 Direktive 1999/93/EC, te nekvalificiranih izdavatelja, pri čemu samo kvalificirani izdavatelji certifikata mogu pružiti najvišu razinu sigurnosti (4). Tabela 22 prikazuje faktore koji utječu na sigurnosnu razinu s aspekta pouzdanosti izdavatelja vjerodajnica.

Tabela 22. Klasifikacija zahtjeva s obzirom na pouzdanosti izdavatelja vjerodajnica

Zahtjev Sigurnosna

razina 0 1 2 3 4

Kvalificirani izdavatelj po Aneksu II Direktive 1999/93/EC x x x x Izdavatelj nije kvalificiran (postoji zakonska regulativa koja ga ovlašćuje) x x

5.3.3.4 Registracija korisnika: Prikaz zahtjeva na sigurnosne razine

Tabela 23 sumarno prikazuje osnovne zahtjeve u postupcima registracije korisnika za sigurnosnu razinu 0.


Tabela 23. Zahtjevi na postupak registracije s obzirom na sigurnosne razine

Razina sigurnosti

Registracija

0

Ne zahtjeva se registracija korisnika, tj. kroz sustav OIB-a korisnici su registrirani za ovu razinu

Ne postoji potreba za pouzdanom potvrdom identiteta niti potreba za detaljnim vođenjem i praćenjem podataka o registraciji korisnika

Korisnik potvrđuje identitet primjenom OIB-a Nije potrebno slanje vjerodajnica korisniku

1

Fizička prisutnost pri registraciji može i ne mora biti zahtjev U slučaju da fizička prisutnost nije zahtijevana, identitet korisnika se ostvaruje

kroz mehanizme koji jedinstveno identificiraju korisnika i koji su potvrđeni (potpisani) od strane s kojom postoji odnos povjerenja

izdavatelj vjerodajnica ne mora biti kvalificiran, ali postoji zakonska regulativa ili ugovorni odnos koji ga ovlašćuje za izdavanje vjerodajnica u sustavu

2, 3 i 4

Fizička prisutnost pri registraciji može i ne mora biti zahtjev U slučaju da fizička prisutnost nije zahtijevana, identitet korisnika se ostvaruje

kroz mehanizme koji jedinstveno identificiraju korisnika i koji su potvrđeni (potpisani) od strane s kojom postoji odnos povjerenja

izdavatelj vjerodajnica je kvalificiran

Zadaća pružatelja pojedine usluge je da analiziraju rizike i posljedice neovlaštenog korištenja iste, odnosno dostavljanja usluge prema neovlaštenim klijentima (npr. zbog man-in-the-middle napada, nedovoljne razine sigurnosti pri dostavi vjerodajnica, ukradenih lozinki itd.). Na osnovu obavljene analize, pružatelj usluga će izabrati željenu sigurnosnu razinu ponuđenu od strane nacionalnog autentikacijskog i autorizacijskog servisa. Isto tako, u ovom trenutku, tijela pružatelji usluga (TDU i ostali) imaju u primjeni specifične razine sigurnosti koje se mogu, ali i ne moraju poklapati sa razinama sigurnosti definiranim u ovom dokumentu (i ponuđenim od strane nacionalnog autentikacijskog servisa). Zadaća tih agencija je također mapiranje specifičnih razina sigurnosti u internoj upotrebi prema standardiziranim razinama definiranim od strane nacionalnog autentikacijskog servisa.

Pojedini servisi zahtijevaju različite razine sigurnosti, pa samim time to znači da korisnici mogu imati više autentikacijskih vjerodajnica koji odgovaraju pojedinim razinama opisanim u poglavlju 2.1.1. ali samo jednu za odgovarajuću razinu. Uzimajući u obzir postojeće stanje te postojanje OIB identifikatora koji je dovoljan za razinu sigurnosti 0 prema klasifikaciji iz poglavlja 2.1.1, u


ovom slučaju nije potrebna dodatna registracija za sve usluge koje zahtijevaju navedenu razinu sigurnosti. Međutim, za usluge koje zahtijevaju više razine sigurnosti nužna je registracija entiteta za navedene usluge, a slijedom toga i izdavanje potrebnih vjerodajnica koje će zadovoljiti traženu sigurnosnu razinu. U svakom slučaju, prikladno je da u sustavu eUprave postoji objedinjeno mjesto koje će omogućiti barem skupljanje zahtjeva za registraciju prema uslugama koje zahtijevaju višu razinu sigurnosti, pri čemu izdavatelj vjerodajnica ne mora biti NIAAA agencija (niti je predviđeno da bude). Isto tako, za složene usluge koje zahtijevaju dohvat/modifikaciju podataka u registrima za koje je nadležno više TDU, tj. za usluge koje zahtijevaju interoperabilnost TDU, utvrđivanje potrebne razine sigurnosti, te samim time i registracija entiteta za navedenu uslugu, zahtijeva pomno snimanje poslovnih procesa te mogućih scenarija te primjenu principa kumulativnosti. To znači da će u složenim uslugama koje se sastoje od više podusluga zahtijevana razina sigurnosti biti definirana razinom najzahtjevnije podusluge.

Postupak registracije ovisit će o sljedećim okolnostima, tj. da li se radi o:

Registraciji pojedinaca (principal)

Registracija pojedinaca kao predstavnika određenih poslovnih subjekata, organizacija, TDU itd. (agent)

Registracija pojedinaca kao predstavnika drugih pojedinaca (agent)

Korisnik koji je uspješno obavio registraciju stječe mogućnost da bude prepoznat (autenticiran) od strane NIAAS servisa u trenutku kada prikaže dobivene vjerodajnice (credentials). Vjerodajnice mogu biti pridružene jednom korisniku (u slučaju registracije principala) ili grupi korisnika (u slučaju registracije agenta).

Isto tako, registracija korisnika se veže prema sigurnosnoj razini a ne prema određenoj usluzi. To znači da se korisnici ne moraju registrirati za neku uslugu iz sigurnosne razine N ukoliko je se prethodno registrirao za neku drugu uslugu koja je zahtijevala istu sigurnosnu razinu. Neki sustavi zahtijevaju pored registracije i naknadnu aktivaciju svake od usluga, međutim to povećava složenost cijelog postupka korištenja elektroničkih usluga, što nije poželjno.

5.3.4 Evidencija o položajima i pravima korisnika

Uzimajući u obzir postojeće stanje u RH, hijerarhijska arhitektura i distribuiranost sustava identifikacije, autentikacije i autorizacije vidi se kao nužnost. Pod pojmom hijerarhijske arhitektura smatra se organizacija sustava na način da usluga na višoj hijerarhijskoj razini može koristiti sve atribute i podatke o korisniku sa nižih hijerarhijskih razina kako bi se osigurala što


efikasnija implementacija sustava ali u isto vrijeme izbjegao problem nekonzistentnosti podataka.

Korisnik sustava, odnosno usluga eUprave može biti određena osoba koja usluzi može pristupiti kao pojedinac, tj. privatna osoba, ali i kao djelatnik nekog TDU, djelatnik organizacije ili tvrtke. Isto tako, korisnik neke usluge (servisa) može biti i druga usluga (servis), i to usluga koja pripada drugom TDU. To znači da se uloge osoba i korisnika i interakcije sa uslugama mogu odvijati po složenim i scenarijima kada korisnici usluga mogu u različitim instancama vremena poprimiti različite uloge (osobno, zaposlenik, druga usluga itd). Različite uloge koje određeni korisnik usluge može dobiti mogu sa sobom nositi i različita prava korištenja navedene usluge (servisa). Isto tako, ista uloga u uslugama koje izvode različita TDU može imati različita prava korištenja istih. Stoga je bitno u sustavu osigurati evidenciju i praćenje položaja odnosno ostvarenih uloga pojedinih korisnika te aktivnosti koje korisnik usluge izvodi. Sukladno tome, predlaže se hijerarhijska organizacija atributa korisnika po servisima te uspostava sustava njihove propagacije u slučaju interakcija servisa. TDU koje je zaduženo za odgovarajuću uslugu može održavati navedenu uslugu kroz dva scenarija:

1. Pohranom atributa korisnika navedene usluge. Prednost ovog pristupa je u slučaju da postoje pojedini atributi koji su specifični za određenu uslugu, te se oni na taj način mogu i spremiti odnosno povezati sa uslugom.

2. TDU ne vrši pohranu navedenih atributa, nego ovisi o podatcima iz drugog izvora kao što su NIAAS ili neko drugo TDU s kojim postoji ostvaren ugovor o razmjeni atributa.

S obzirom na postojeće stanje, preporučuje mogućnost korištenja oba scenarija, ovisno o mogućnostima realizacije.

6 KONCEPT PRIPREME ZA JAVNU RASPRAVU PROJEKTA

6.1 Definiranje servisa dostupnih korisnicima

U tabeli 24 se nalazi popis tipova usluga i predloženih pripadnih razina povjerenja, pri čemu se razine povjerenja mogu podijeliti na:

Razina 0: anonimne transakcije – dozvoljen je pristup transakcijama koje ne zahtijevaju ili ne dopuštaju osobi da bude identificirana, ili zahtijevaju zaštitu identiteta osobe.

Razina 1: pseudo-anonimne transakcije – dozvoljen je pristup transakcijama koje ne zahtijevaju da se osoba identificira, ali zahtijevaju podatke za daljnje kontaktiranje da bi se usluga isporučila.


Razina 2: autenticirane transakcije – dozvoljen je pristup transakcijama koje zahtijevaju da se osoba identificira.

Razina 3: autorizirane transakcije – dozvoljen je pristup transakcijama koje zahtijevaju da se osoba identificira, da se provjeri integritet podataka koji se razmjenjuju i da se stvori dovoljno dokaza koji pokazuju da je osoba pristala biti vezana uz transakciju.

Tabela 24. Razine povjerenja

Tip usluge Razina 0 Razina 1 Razina 2 Razina 3

Dobivanje informacije x x

Izdavanje dozvole/potvrde x x x

Pravni procesi x x

Prijave/žalbe/izmjene podataka x

Korisničko plaćanje x

Monetarne transakcije prema korisniku x

Analiza tabele pokazuje da su glavne karakteristike na razini povjerenja 3 usluge koje su povezane s novčanim transakcijama prema korisniku (isplata) ili regulatornim aktivnostima koje često uključuju davanje neke vrste prava ili obveze, uglavnom s ekonomskim posljedicama. Pravni procesi koji često uključuju osobne odnose, također su značajne usluge razine povjerenja 3. Razina povjerenja 2 se koristi u transakcijama koje uključuju korisničko plaćanje (npr. uplata poreza), prijava ili izmjena korisničkih podataka, te moguće žalbe na pojedine odluke tijela državne uprave, jednostavnije pravne procese. Razina povjerenja 1 se koristi u transakcijama gdje se izdaju jednostavne dozvole ili potvrde te gdje je potrebno dobiti asinkronu povratnu informaciju, dok se razina povjerenja 0 koristi za dobivanje sinkronih povratnih informacija.

Skup svojstva servisa uključuje:

NIAAS omogućava provjeru autentikacijskih i autorizacijskih razina definiranih u poglavlju 2.1.1. Omogućuje krajnjim korisnicima (građanima, organizacijama i posrednicima) SSO prema svim tijelima državne uprave, na nacionalnoj, regionalnoj i lokalnoj razini. Ovo svojstvo je omogućeno i kroz korištenje Internet preglednika, ali i aplikacijski kroz


korištenje softvera koja omogućava pristup drugim servisima i portalima TDU bez potrebe za daljnjom autorizacijom.

Transakcije i usmjeravanje poruka (dokumenti i poslovni obrasci) između objekta mogu se pouzdano razmijeniti između pojedinih TDU i poslovnih organizacija, posrednika i građana.

Sigurna komunikacija putem e-pošte olakšava komunikaciju između korisnika sustava.

Mogućnost plaćanja pruža fleksibilno sredstvo za elektroničko plaćanje – zadužuje debitne ili kreditne kartice.

Integracijski sustav nudi pouzdanu dostavu i integritet poruka, kao i mogućnost za lokalnu integraciju postojećih sustava i aplikacija.

Služba za korisničku potporu omogućava korisnicima koji nemaju Internetsku vezu ili potrebno znanje, pristup on-line uslugama pojedinih tijela državne uprave.

Krajnji korisnici NIAAS mogu biti pojedinci (građani), organizacije (tvrtke, poslovni korisnici) ili posrednici (druga tijela državne uprave). Unutar kategorije posrednika moguće je definirati i potkategorije državnog službenika kao pojedinca, te posrednika koji ima funkcionalnost na razini cijelog tijela državne uprave.

Postoje dvije osnovne metode povezivanja na sustav:

Ad-hoc putem Interneta korištenjem Internet preglednika i aplikativnog softvera. To je metoda kojom se prvenstveno koriste krajnji korisnici. U mnogim slučajevima, krajnji korisnici neće biti svjesni da se oni koriste usluge i usluge treće strane kroz preusmjeravanje i međudjelovanje zahtjeva za uslugom. Na taj način krajnji korisnik će vidjeti samo portal ili aplikacije na kojima rade.

Korištenjem Intraneta od strane internih korisnika (djelatnika tijela državne uprave).

Standardna sučelja unutar sustava autentikacije prikazana su na slici 19.


Slika 19. Standardna sučelja NIAAS

6.2 Obrazloženje prednosti sustava

Koristi od on-line modela komunikacije i autentikacije su realizirane samo ako postoje tijela državne uprave, koja svoje usluge nude putem Interneta, te ako su korisnici izabrati pristup tim uslugama na ovaj način. Analiza pokazuje da je koristi moguće ostvariti u više područja kao što su direktne prednosti za korisnika (za veliku većinu usluga nije potrebno dolaziti do tijela uprave


koje pruža uslugu), u području socijalnih vrijednosti, financijskim uštedama, olakšanom korištenju i isporuci usluga, te predstavlja ulaganje u razvoj i vrijednost za budućnost.

Tabela 25. Analiza prednosti sustava

Područja u kojima se ostvaruje korist

Usluga od TDU prema korisnicima

Usluga između pojedinih TDU

Unutarnja učinkovitost TDU

Direktna korist za korisnike (realizirano od strane korisnika)

-vremenska ušteda

-zadovoljstvo korisnika

-vremenska ušteda

-zadovoljstvo korisnika

-mogućnost vrednovanja usluge

-vremenska ušteda

-smanjen broj pritužbi

Socijalna vrijednost (indirektne vrijednosti)

-poboljšano povjerenje u upravu, uključujući i poboljšanu transparentnost upravnih procesa;

-bolje pružanje usluga – pristup uslugama izvan radnog vremena pojedinog pružatelja usluge, te uklanjanje čekanja u redovima za pristup

uslugama.

Financijske uštede

-smanjeno radno opterećenje u smislu vremena potrebnog za provjeru identiteta;

-zajednička infrastruktura;

-smanjeni troškovi pogona;

-izbjegavanje dupliciranja troškova u održavanju,prostoru i sl.

Buduće vrijednosti

(sustav predstavlja platformu za daljnji

razvoj)

-poboljšana točnost podataka – dosljedna klasifikacija i oblikovanje podataka, te stalnost identiteta podataka;

-čišćenje redundantnih podataka – smanjenje internih podataka i osiguravanje integriteta podataka;

-povećana efikasnost sustava – povećanje učinkovitosti, praktičnosti i dostupnosti podataka;

-raspoloživost sustava – povećani opseg korisnika sustava i kvalitetniji načini informiranja;

-smanjenje potrebe za radnom snagom;

-povećana pouzdanost sustava.


Osim toga, NIAAS sustav ima i sljedeće prednosti:

Omogućuje korisnicima prijavu na bilo koji on-line servis/uslugu koristeći iste autentikacijske faktore, što može biti kombinacija korisničko ime/lozinka sa ili bez uključenog dodatnog sigurnosnog izraza (za dodatnu sigurnost) ili kombinacija sa digitalnim certifikatom, tokenom i PIN-om.

Pruža pravu SSO (Single Sign On) uslugu cijelom sustavu što omogućuje korisnicima pristup resursima kompletnim uslugama te autorizacijske razine (unutar sjednice Internet preglednika), pri čemu se fizička autentikacija i autorizacija obavlja samo jednom kroz središnji sustav autentikacije i autorizacije u autorizacijskoj agenciji.

Omogućava korisnicima korištenje svih usluga direktno ili delegira autorizacije na druge TDU i pripadne registre i sustave prijava.

Omogućava povezivanje korisničkog računa sa širokim rasponom različitih državnih identifikacija (na primjer može se povezati MBO (broj osiguranika u HZZO-u), JMBAG (jedinstveni matični broj akademskog građana) sa korisničkim faktorima autentikacije, te se omogućava korištenje i tih korisničkih atributa u sustavim koji ih zahtijevaju).

Osigurava sigurnu predaju i podnošenje elektroničkih obrazaca i transakcija prema servisima TDU, koristeći iste vjerodajnice kojima je ustanovljena prijava na sustav za potpisivanje podnesaka.

Pruža mehanizam za sigurnu komunikaciju s tijela državne uprave sa korisnicima kada je potrebna razmjena osjetljivih osobnih informacija.

Osigurava interoperabilnost u transakcijama između različitih servisa, bez obzira na specifične aplikacije ili tehnologije koje se koriste.

Definira korištenje otvorenih standarda u komunikaciji i tehnološki neutralnih usluga.

Omogućava lakši i brži način za spajanje specifičnih registara podataka na Internet i usmjeravanje ovjerenih transakcija između tijela državne uprave.

Smanjuje troškove implementacije, smanjuje rizike primjenom poznatih sigurnosnih protokola pristupa i smanjuje vrijeme isporuke

Složenost poslovnih procesa sustava je skrivena korisnicima, što olakšava rad i pružateljima usluga i isporuku usluga korisnicima.


6.3 Koncept početnog poslovnog slučaja

Koncept postavljanja usluge na portal. Za postavljanje pojedinih usluga na portal s uslugama, tijelo državne uprave koje je vlasnik usluge treba provesti sljedeće korake:

1) Utvrditi zrnatost usluge. Lokalne vlasti i tijela državne uprave trebaju odlučiti kako najbolje postaviti odnos između svojih ciljanih korisnika i usluga na koje se žele upisati (tj. kako će se transakcije grupirati zajedno u jednu uslugu). Pri tome je bitno razmotriti sljedeća pitanja:

- Preraspodjela prava na uslugu (na primjer, mogućnost da korisnik preda prava svomu agentu ili posredniku koji će poduzimati transakcije u njegovo ime) može se obrađivati samo na razini usluga, a ne na razini transakcije. Ključni faktor je utvrđivanje koju vrstu usluga će krajnji korisnik sam željeti izvršavati, a koje će možda prenijeti na svoje posrednike.

- Kombinacija autentikacijskih faktora i usluga koje su uključene mora biti jedinstvena. Međutim, postoje iznimke kada se ovo pravilo ne može provesti. Ovaj problem je najlakše predočiti primjerom. Tijelo lokalne vlasti može odlučiti da su autentikacijski faktori potrebni za uvid u stanje dugova na ime režija kućanstva su broj kućanstva i poštanski broj. Broj kućanstva se dodjeljuje na razini kućanstva, a ne na razini građana. Dakle, više od jedne osobe u domaćinstvu, može imati istu kombinaciju broja kućanstva, poštanskog broja i usluge koji oni žele koristiti.

2) Utvrditi autentikacijske razine. TDU ili tijelo lokalnih vlasti mora utvrditi razinu sigurnosti potrebne za svaku transakciju prije grupiranje poslova u usluge. Za ilustraciju, ako je u jednu uslugu grupirano 5 transakcija, a jedna od njih zahtjeva digitalni certifikat, onda je potrebna sigurnost na razini digitalnog certifikata za izvršavanje usluge.

3) Pridijeliti tipove korisnika. TDU ili tijelo lokalnih vlasti treba odrediti koje vrste krajnjih korisnika će koristiti uslugu – pojedinci (građani), poslovni korisnici (osobe koje djeluju u ime organizacija) i/ili agenti.

4) Definirati naziv usluge i dati opisni tekst. Da bi se usluga registrirala na portal, davatelj usluge treba predočiti informacije o imenu usluge; URL-u stranice na kojoj je usluga dostupna i URL-u stranice na kojoj se nalaze uvjeti korištenja usluge.

5) Definirati autentikacijske faktore za uslugu. Kao što je spomenuto, za svaku uslugu krajnji korisnik treba unijeti skup autentikacijskih faktora. Oni se koriste za povezivanje vjerodajnica korisnika (korisničko ime/lozinka ili digitalni certifikat) sa službom za


pružanje usluge. Za opis autentikacijskih faktora potrebno je predočiti ime i poslovna pravila za svaku definiranu uslugu, broj i potrebne faktore za autentikaciju i tekst koji opisuje željene faktore koje mora priložiti korisnik.

6) Definirati jedinstveni identifikator usluge. Ovaj identifikator treba na sažeti način (ne više od 15 znakova) svojstva usluge.


7 PRILOG 1 – KONCEPT KORIŠTENJA NIAAS-A ZA USLUGE AUTENTIKACIJE I

AUTORIZACIJE NA SIGURNOSNIM RAZINAMA 0 I 1

Problemi koji se rješavaju ovim konceptom su:

Definiranje konceptualnih mehanizama autentikacije za pristup sadržajima koji su klasificirani za slobodan pristup (razina 0) i sadržajima koji su klasificirani kao podložni kontroli i omogućavanje pristupa uz nizak stupanj zaštite (razina 1). Sadržaji koji su klasificirani drugačije ne pripadaju pod opseg ovog projekta.

Stvaranje politike i okvira za implementaciju ovih mehanizama na način koji će biti prikladan za korištenje od strane pružatelja usluga, počevši s tijelima državne uprave ali u budućnosti i komercijalnih subjekata, uz minimalne troškove implementacije za sve strane koje surađuju.

Rezultati ovog aspekta projekta trebaju biti:

1. Sustav autentikacije koji će rješavati navedene probleme (u ulozi infrastrukturnog sustava)

2. Skup dokumentacije koja opisuje implementaciju i korištenje ovog sustava od strane pružatelja usluga

3. Skup dokumentacije koja definira način provjere sukladnosti implementacija korištenje ovog sustava od pružatelja usluga

4. Skup politika koje definiraju pravila i postupke koji se primjenjuju tijekom aktivnog rada ovog sustava, uključujući i korisničku podršku.

Načini implementacije i detaljni opisi rezultata su predmet daljnjeg teksta ovog dokumenta.

7.1 Opis sigurnosnih razina 0 i 1

Sigurnosne razine 0 i 1 su u općem slučaju razine koje koriste usluge vezane uz pružanje informacija. To se naročito odnosi na razinu 0, dok se razina 1 može koristiti u sustavu i za dobivanje većih ovlasti od čitanja uz uvjet postojanja lokalizirane politike autorizacijskih ovlasti u TDU koji su vlasnici usluga. Ovaj scenarij je trenutno vrlo vjerojatan, s obzirom da većina postojećih sustava koriste sigurnosne tokene zasnovane na korisničkom imenu i lozinki.

Na razini 0 nije potrebna dodatna autentikacija elektroničkog identiteta korisnika. Jedina poveznica između fizičkog korisnika i njegovog identiteta u sustavu je OIB identifikator


koji korisnici opcionalno pružaju, jer je OIB javan i bez autentikacije nije moguće povezati ga vjerodostojno sa osobama. Ova razina prikladna je za općenite usluge pristupa javno dostupnim informacijama, kao što su uvid u postojanje na popisu birača, usluge lokalne uprave za pristup informacijama kao što je katastar itd.

Sigurnosna razina 1 namijenjena je za kontrolu i omogućavanje pristupa uslugama i podacima uz nizak stupanj zaštite. Najčešće korišten mehanizam dokazivanja identiteta ili posjedovni token na ovoj razini je korištenje korisničkog imena i lozinke (login/password). Ovlasti elektroničkog identiteta autenticiranog na ovoj sigurnosnoj razini ovise o autorizacijskim politikama koje određuju TDU zasebno, svatko za sebe. Najčešće, za građane to su ovlasti čitanja odnosno pristupa informacijama, dok su za zaposlenike odnosno korisnike s definiranim autorizacijskim ulogama, ovlasti propagiraju i na mogućnosti promjene podataka.

Postojanje centralnog imeničkog direktorija na razini NIAAS sustava predstavlja jedan od bitnih preduvjeta korištenja navedenih sigurnosnih razina odnosno elektroničkog identiteta na navedenim razinama na jedinstven i integriran način od strane svih tijela koja koriste NIAAS autentikaciju. Pri tome se eksplicitno ne isključuje postojanje lokaliziranih direktorija u tijelima uprave i samouprave koja sadrži identitete zaposlenika te detaljno razrađene i definirane strukture uloga i autorizacija putem kojih ovi surađuju s NIAAS-om.

Pri implementaciji sustava i u samom sustavu moraju se primjenjivati sigurnosne mjere opisane u standardu ISO 27001.

7.1.1 Osnovni skup podataka centralnog imenika

Centralni imenička uspostavljen na razini NIAAS sustava bi sadržavao osnovni skup podataka potrebnih za održavanje elektroničkog identiteta i autentikaciju na sigurnosnim razinama 0 i 1, te mehanizme proširenja ovog skupa podataka za potrebe TDU. Svi ostali atributi na osnovu kojih se utvrđuju autorizacijske ovlasti (uloge, atributi vezani uz radna mjesta itd.) u nadležnosti su tijela vlasnika podataka, odnosno elektroničke usluge koju ostvaruju, uz sukladnost politikama i propisima koje postavlja NIAAS. Shodno tome, Tabela 26 prikazuje taj osnovni skup podataka u centralnom direktoriju:

Tabela 26. Osnovni skup podataka o identitetu u centralnom imeniku NIAAS-a

Podatak Obavezan Naziv Opis OIB DA OIB OIB (identifikator osobe) Ime DA FirstName Ime osobe

Prezime DA LastName Prezime osobe


Lozinka DA Password Autentikacijski token za sigurnosnu razinu 1

(lozinka) Primarna

e-mail adresa

NE PrimaryEmail Primarna e-mail adresa za kontakt osobe

Javni ključ NE PublicKey Javni ključ osobe u sustavu PKI-a (za buduću

upotrebu)

U Tabeli 26 osnovnog skupa podataka u centralnom imeniku NIAAS-a značenja stupaca su slijedeća:

Podatak: Naziv podatka koji će se koristiti u dokumentaciji kada se on referencira.

Obvezan: Označava da li podatak uvijek mora biti unesen u informacijsku bazu.

Naziv: Naziv podatka koji će se koristiti u protokolima komunikacije, programskom kodu i drugim mjestima koja su bitna za komunikaciju i radu sustava a nisu vidljiva krajnjim korisnicima. Ovaj naziv sastoji se od slova engleske abecede i znamenki 0-9.

Opis: Opis podatka.

U svrhu autentikacije korisnika na sigurnosnim razinama 0 i 1 će se u svojstvu korisničkog imena (username, user ID) koristiti podatak "OIB" te će u ovoj dokumentaciji "korisničko ime" i "OIB" u ovom kontekstu biti jednoznačni. Razlozi ovome su izbjegavanje uspostavljanja podatka posebnog korisničkog imena koji ima istu jedinstvenost (osobinu primarnog ključa) kao i podatak "OIB" te izbjegavanje stvaranja zasebnog korisničkog imena za svakog građana što je postupak koji se mora obaviti mehanički i čiji rezultat je jednake brojnosti (količine podataka) kao i OIB, čime će se izgubiti osobine pristupačnosti i pamtljivosti takvog korisničkog imena.

Pružatelji usluga mogu, prema potrebi i lokalnoj odluci, uvesti lokalno korisničko ime koje će lokalno biti upareno sa OIB-om, ali za komunikaciju sa NIAAS-om se smije koristiti samo OIB.

7.1.2 Prošireni skup podataka centralnog imenika

Osnovni skup podataka uključuje obavezne podatke za održavanje elektroničkog identiteta, međutim da bi se olakšalo korištenje sustava i njegova primjena u okolnostima gdje nije moguće ili nije praktično implementirati lokalnu informacijsku bazu podataka sa dodatnim informacijama o identitetu, imenik će biti moguće proširivati sa dodatnim informacijama od strane pružatelja usluga.


Pružatelji usluga koji su zainteresirani za ovu mogućnost moraju zatražiti pristup ovim uslugama od NIAAS-a zajedno sa adresama sustava koji će podacima pristupati (na primjer: IPv4, IPv6 adrese), na temelju kojega će im NIAAS izdati slijedeće podatke:

Jedinstveni naziv prostora imena (namespace) kojeg će ovaj pružatelj usluga koristiti i po kojoj će njegovi podaci biti poznati. Ovaj naziv će se sastojati od slova engleske abecede i znamenki 0-9 te će biti maksimalne duljine 8 znakova (na primjer: "PORUPSB").

Korisničko ime i lozinku putem kojeg će sustav pružatelja usluga moći pristupati uslugama za dohvat i modifikaciju podataka.

Potvrdu da se ovim informacijama može pristupati samo sa dozvoljenih adresa i popis ovih adresa.

Podaci koji će se na ovaj način pohranjivati će se sastojati od naziva i sadržaja (key-value pair). Naziv će se sastojati od slova engleske abecede i znamenki 0-9, maksimalne duljine 20 znakova (na primjer: "DatumIsplatePovrata"). Sadržaj će biti tekstualno polje koje može sadržavati sve uobičajene znakove svjetskih abeceda (bez kontrolnih znakova ekvivalentnima ASCII znakovima 0-31) maksimalne duljine 2000 znakova. Ovaj dokument ne specificira koji podaci se mogu pohranjivati u ovom obliku unutar centralnog imeničkog direktorija niti nazive koje će se koristiti.

Svi podaci pohranjeni na ovaj način biti će smatrani privatnima u odnosu na pružatelja usluga koji ih unosi (pružatelji usluga će moći dohvatiti samo podatke koje su unijeli) osim ako se u suradnji sa NIAAS-om ne dogovori suradnja između različitih pružatelja usluga. U ovom slučaju pružatelji usluga će moći pristupati dogovorenim podacima drugih pružatelja usluga koristeći iste mehanizme pristupa ali koristeći jedinstven naziv prostora imena druge ustanove kao prefiks (na primjer: "PORUPSB.DatumIsplatePovrata").

S obzirom na razinu sigurnosti koja se štiti, podaci pohranjeni na ovaj način mogu biti samo oni koji su klasificirani sigurnosnim razinama 0 i 1.

7.2 Scenarij korištenja NIAAS sustava na razinama 0 i 1

NIAAS sustav se može prikazati kao dostavljač identiteta (eng. identity provider) s podacima iz centralnog imenika. Stoga je NIAAS zadužen za cjelokupni životni ciklus identiteta: njegovo stvaranje, korištenje te brisanje/deaktiviranje. Zbog postojanja nacionalnog sustava OIB-a, ovaj životni ciklus mora biti blisko povezan sa životnim ciklusom OIB-a.

S druge strane su tijela državne uprave ili lokalne samouprave koji se mogu shvatiti kao dostavljači usluga (eng. service providers) te su zaduženi za upravljanje podacima koji su


relevantni za ostvarenje usluga: definicije uloga na osnovu kojih se ostvaruju autorizacije nad podatcima, poveznice između uloga i korisničkih podataka (npr. za zaposlenike itd).

Slika 20. Koncept korištenja NIAAS sustava na sigurnosnoj razini 1

Slika 20 prikazuje koncept korištenja NIAAAS sustava elektroničkog identiteta na sigurnosnoj razini 1. NIAAS održava centralni imenik te omogućuje korisnicima autentikaciju putem elektroničkog identiteta. Kao rezultat uspješne autentikacije NIAAS prosljeđuje tijelu davatelju usluge tvrdnje (eng. assertions) koje verificiraju da je korisnik uspješno potvrdio svoj elektronički identitet eID na određenoj sigurnosnoj razini (u ovom slučaju razina 1).

Ukoliko je korisnik usluge građanin bez dodatnih uloga u TDU, onda je za uspješnu autorizaciju odnosno obavljanje usluge nužno postojanje utvrđenog ugovora povjerenja (trust relationship) između tijela davatelja usluge i NIAAS sustava kao davatelja identiteta. Ukoliko taj ugovor postoji i lokalna autorizacijska politika u TDU dozvoljava traženu operaciju (npr. pristup informacijama, čitanje podataka), onda će elektronička usluga biti dostavljena korisniku. Ovaj scenarij omogućuje tijelima davateljima usluga da sve troškove vezane uz autentikaciju eliminiraju te da za njihove potrebe, postupke autentikacije preusmjere na NIAAS sustav.

Ukoliko je korisnik usluge ujedno i zaposlenik u tijelu pružatelju usluge s odgovarajućom ulogom koja je definirana u lokalnom direktoriju TDU, onda postoji mogućnost povezivanja (federiranja) NIAAS identiteta i lokalnog korisničkog identiteta (NIAAS eID atributi se dodatno proširuju lokalnim atributima, neovisno o proširenim skupom podataka u imeniku). U trenutku povezivanja ova dva identiteta, tijelo pružatelj usluge će ubuduće dozvoliti SSO funkcionalnost korisniku pri čemu će dodjeljivanje ovlasti korisniku (postupak autorizacije) obaviti na način kao da je korisnik koristi lokalni identitet.


U praktičnoj implementaciji stoga se razlikuju slijedeći scenariji koje provode davatelji usluga u odnosu na stanje elektroničkog identiteta korisnika i o specifičnoj usluzi:

1. Od NIAAS-a se traži samo potvrda o tome da je korisnik uspješno autenticiran, bez dodatnih provjera prava pristupa (odnosno autorizacije).

2. Lokalni davatelj usluga posjeduje informacijsku bazu prava pristupa (autorizacije) te nakon uspješne autentikacije korisnika od strane NIAAS-a provjerava korisnika u ovoj bazi i dalje postupa prema nađenim informacijama.

3. Lokalni davatelj usluga koristi kombinaciju lokalne informacije baze (ako postoji) i proširenog skupa podataka u imeniku za autorizaciju korisnika.

NIAAS će dozvoliti pokušaje korištenje usluga autentikacije na sigurnosnim razinama 0 i 1 samo s adresa koje su unaprijed dozvoljene (white list). Ove adrese mogu biti različitog oblika ovisno o protokolima koji se koriste (na primjer: IPv4, IPv6). Pružatelji usluga trebaju u NIAAS-u registrirati adrese sa kojih će pristupati sustavu u svrhu autentikacije.

7.2.1 Sustav autentikacije na sigurnosnoj razini 0

U skladu s Prijedlogom koncepta integriranog središnjeg sustava autentikacije i autorizacije, sustav autentikacije na sigurnosnoj razini 0 treba dozvoljavati slobodan pristup bez autentikacije (podrazina 0.1), te stoga ne može ni na kojoj razini jamčiti identitet ili autentičnost korisnika. Kao posljedicu toga, sustavi pružatelja usluga koji implementiraju autentikaciju na sigurnosnoj razini 0 (podrazine 0.1 i 0.3) ne moraju kontaktirati NIAAS u nijednoj fazi korištenja.

Ako sustavi pružatelja usluga implementiraju kontrolu pristupa OIB-om (razina 0.2 i razina 0.3 ako je povezana s OIB-om), NIAAS mora pružati mogućnost provjere ispravnosti OIB-a, međutim kako provjera identiteta nije izvršena, NIAAS ne smije na osnovu ove provjere ispravnosti pružati nikakve dodatne informacije o korisniku.

7.2.2 Sustav autentikacije na sigurnosnoj razini 1

U skladu s Prijedlogom koncepta integriranog središnjeg sustava autentikacije i autorizacije, sustav autentikacije na sigurnosnoj razini 1 treba omogućiti autentikaciju korisnika korištenjem kombinacije korisničkog imena te dvije varijanti lozinke: ponovljive lozinke i jednokratne lozinke. Sustavi pružatelja usluga mogu implementirati bilo koju od ovih varijanti, uz adekvatne sigurnosne zaštite.


7.3 Sigurnosne zaštite

U bilo kojoj varijanti autentikacije lozinkama, korištenjem bilo koje vrste protokola, mora biti zadovoljen jedan od slijedećih uvjeta:

Lozinka se prenosi protokolom bez dodatne enkripcije ili skrivanja ali protokol niže razine kojim se lozinka prenosi mora implementirati jaku razinu enkripcije (na primjer: SSL/TLS)

Lozinka se prenosi korištenjem jake razine skrivanja, protokolima vrste "pobuda/odziv" (CHAP), u kojima se sama lozinka nikada ne prenosi komunikacijskim kanalom

7.3.1 Sigurnosne zaštite za korištenje ponovljivih lozinki

Ponovljive lozinke su izrazito osjetljive na veliki broj napada koji imaju za cilj lažno predstavljanje korisnika. Napadi ne uključuju samo pogađanje originalne korisničke lozinke, nego ovisno o protokolu mogu biti usmjereni na bilo koji međukorak u korištenju lozinku koji ne sadrži adekvatnu zaštitu (na primjer: replay attack, password equivalents).

Da bi se smanjili rizici korištenja ponovljivih lozinki, na strani NIAAS-a moraju biti zadovoljeni slijedeći uvjeti:

Ponovljiva lozinka se nakon stvaranja ili unosa od strane korisnika nikada ne smije pohranjivati u običnom obliku (plaintext) bez skrivanja.

Za skrivanje lozinki kod pohrane unutar NIAAS-a se moraju koristiti algoritmi nereverzibilne enkripcije ili kompresije sadržaja (hash algoritmi) na način u kojem se, ukoliko napadač dođe do sadržaja informacijske baze NIAAS-a, dobivenim podacima ne može izravno obavljati autentikacija niti jednim protokolom koji NIAAS nudi, niti se mogu koristiti metode ubrzavanja napada sirovom snagom (rainbow tables) za otkrivanje originalnih korisničkih lozinki. Za podršku različitih protokola autentikacije, skrivene lozinke mogu u imenik biti zapisane u većem broju oblika (na primjer: salted MD5, HTTP digest "HA1" string iz dokumenta RFC 2617).

Ponovljive lozinke ne smiju biti kraće od 8 znakova. Lozinke se sastoje od slijedećih skupova znakova: velika i mala slova engleske abecede te brojke. Ponovljive lozinke moraju uključivati barem 2 znaka iz svakog od ovih skupova.

U sustavima pružatelja usluga moraju biti zadovoljeni slijedeći uvjeti:

Unesena lozinka se nikada ne smije zapisivati u lokalnom sustavu, bilo u čistom obliku ili skrivena, bez obzira na svrhu


7.3.2 Sigurnosne zaštite za korištenje jednokratnih lozinki

Zbog naravi algoritma, izdavanjem jednokratnih lozinki mora upravljati NIAAS, koji za potrebe sustava korisnicima njima izravno izdaje popise lozinki (bez sudjelovanja sustava pružatelja usluga). Ovaj popis izdanih jednokratnih lozinki ne smije sadržavati više od 20 budućih (neiskorištenih) jednokratnih lozinki. Duljina jednokratnih lozinki mora biti minimalno 64 bita, kreiranih algoritmom koji osigurava visoku entropiju nad svim i nad cijelim lozinkama. Za lakše korištenje, jednokratne lozinke moraju biti izdane korisnicima u nekom lako iskoristivom obliku (na primjer: six-word zapis iz dokumenta RFC2289).

Mogućnost korištenja jednokratnih lozinki je posebno atraktivna u kombinaciji sa sklopovskim rješenjima, te implementacija u NIAAS-u treba omogućiti korištenje ovakvog rješenja za pojedine ili sve korisnike. Primjeri sklopovskih implementacija OTP-a su "RSA SecurID" tvrtke EMC i "Yubikey" tvrtke "Yubico."

7.3.3 Ostale mjere zaštite

Prema preporuci Prijedloga koncepta integriranog središnjeg sustava autentikacije i autorizacije, sustavi pružatelja usluga ne bi trebali pretpostavljati da je autenticirani korisnik još uvijek validan 12 sati nakon autentikacije. Ova mjera efektivno ograničava trajanje korisničke sjednice sa sustavom.

Radi zaštite od napada sirovom snagom, NIAAS mora ograničiti pokušaje autentikacije za pojedinog korisnika na maksimalno 1 u 3 sekunde bez obzira na varijantu lozinke koja se koristi, protokol ili metodu koji se koriste za autentikaciju. Ako za istog korisnika pristigne ponovni pokušaj autentikacije u vremenu kraćem od 3 sekunde od prijašnjeg neuspješnog pokušaja, mora se implementirati čekanje u trajanju do 3 sekunde. U slučaju da NIAAS detektira više od 20 uzastopnih neuspješnih pokušaja autentikacije za jednog korisnika (bez obzira na adresu), mora biti odaslano administratorsko upozorenje osoblju koje može odlučiti da li privremeno blokirati sve daljnje pokušaje autentikacije za pojedinog korisnika i/ili adrese, prema ozbiljnosti problema.

U skladu s odgovarajućim poglavljima standarda ISO 27001, sve operacije u NIAAS-u nad informacijskom bazom korisnika te pokušaji autentikacije (bez obzira na uspješnost) se trebaju detaljno evidentirati (logirati). U evidenciji moraju biti prisutni podaci o pružatelju usluge, OIB-u korisnika, vremenu pokušaja (s rezolucijom od minimalno jedne sekunde), adresi odakle je došao pokušaj autentikacije (koja može biti različita ovisno o sustavu putem kojega je pokušaj došao) te uspješnosti pokušaja. Preporučeno vrijeme čuvanja ovih podataka je minimalno 12 mjeseci.


7.4 Dokumentacija implementacije i korištenja sustava

U sklopu implementacije projekta opisanim ovim dokumentom, NIAAS mora producirati dokumentaciju koja opisuje sustav i njegovo korištenje. Ova dokumentacija mora sadržavati slijedeće informacije:

1. Opis implementacije sučelja prema informacijskoj bazi OIB-a

2. Opis integracije praćenja životnog ciklusa OIB-a u svrhu implementacije autentikacije (među ostalim: kada i kako se povezuju novi OIB-ovi s elektroničkim identitetom za autentikaciju, kako se onemogućuje autentikacija za OIB-ove koji više ne vrijede)

3. Opis načina pohrane informacija potrebnih za rad sustava (shema baza podataka, opis pomoćnih datoteka i drugih pohranjenih informacija)

4. Plan povećanja kapaciteta ove usluge ako se ukaže potreba za njime, a s obzirom na dva aspekta: povećanje opsega informacija koje se pohranjuju u NIAAS-u i povećanje broja zahtjeva za autentikacijom u jedinici vremena

5. Popis kriptografskih i autentikacijskih algoritama i protokola koji se koriste u implementaciji u pojedinim točkama implementacije, sa kratkim objašnjenjem načina na koji se koriste i kratkim obrazloženjem zašto su ti algoritmi izabrani

6. Popis protokola koje NIAAS nudi trećim stranama za korištenje sustava, s pojašnjenjima pojedinih detalja ako oni odstupaju od standarda ili uobičajenih implementacija ovih protokola, te obrazloženjima razloga ovih odstupanja

7. Za svaki ponuđeni protokol autentikacije, barem jedan primjer programskog koda koji u ulozi sustava pružatelja usluga obavlja autentikaciju preko NIAAS-a, u nekom od popularnih programskih jezika: Java, C#, C++, PHP (koji koriste odgovarajuće biblioteke, prema potrebi).

Dokumenti u točkama 5, 6 i 7 zvati će se skupnim imenom "Dokumentacija implementacije za pružatelje usluga" i trebaju biti izravno i javno dostupni svim pružateljima usluga koji žele koristiti mogućnosti NIAAS-a za autentikaciju na sigurnosnim razinama 0 i 1. Iz informacija u ovoj dokumentaciji mora biti izravno moguće na strani pružatelja usluga implementirati autentikaciju na sigurnosnim razinama 0 i 1 putem NIAAS-a.

Svrha javne objave popisa korištenih kriptografskih algoritama i protokola (sa načinima njihovog korištenja) je povećanje otvorenosti sustava i omogućavanje validacije dizajna sustava od trećih strana.


7.5 Provjera sukladnosti sustava pružatelja usluga s NIAAS-om

Za uspješnu interoperabilnost sustava pružatelja usluga s NIAAS-om u svrhu autentikacije korisnika na sigurnosnim razinama 0 i 1 NIAAS će definirati politiku, plan i mehanizme provjere sukladnosti implementacija sustava pružatelja usluga s NIAAS-ovim uslugama (na primjer: testni slučajevi, testni poslužitelji). Ovi će biti opisani u posebnom skupu dokumentacije, koja je također javno dostupna.

Sustavi na strani pružatelja usluga koji prođu provjeru sukladnosti će moći biti zvani "Certificirani kao sukladni s NIAAS-om za autentikaciju na sigurnosnim razinama 0 i 1."

Pružatelji usluga ovu provjeru (odnosno certifikaciju) trebaju proći opcionalno jer se iz skupa dokumenata "Dokumentacija implementacije za pružatelje usluga" mora moći izravno implementirati sukladan sustav koji komunicira sa NIAAS-om. Svrha njenog postojanja je smanjenje radnog opterećenja podrške NIAAS-a – upiti pružatelja usluga koji nisu prošli ovu provjeru mogu biti obrađeni s nižim prioritetom.

7.6 Ostala pravila i postupci za provođenje prije i tijekom rada NIAAS-a

Prije puštanja usluge autentikacije korisnika na sigurnosnim razinama 0 i 1 od strane NIAAS-a, moraju biti ostvareni sljedeći uvjeti:

Stvaranje javno dostupnog web sjedišta (klasificiranog pod sigurnosnom razinom 0) koji će korisnicima opisati NIAAS i njegove usluge autentikacije na sigurnosnim uslugama 0 i 1.

Ovo web sjedište mora sadržavati dokumentaciju sustava ranije definiranu pod nazivom "Dokumentacija implementacije za pružatelje usluga" i dokumentaciju iz poglavlja "Provjera sukladnosti pružatelja usluga s NIAAS-om".

NIAAS treba omogućiti zainteresiranim pružateljima usluga javnu ili privatnu (ovisno o potrebi) komunikacijsku grupu (na primjer: mailing list, private newsgroup ili web forum) koja će imati dvojaku uslugu komunikacije pružatelja usluga s NIAAS-om za pitanja oko implementacije i obavještavanja pružatelja usluga o stanju i promjenama u radu NIAAS-a.

Sustav autentikacije na sigurnosnim razinama 0 i 1 NIAAS-a mora biti testiran za pretpostavljena opterećenja (za performanse i stabilnost)

Tijekom rada usluge autentikacije korisnika na sigurnosnim razinama 0 i 1 NIAAS mora sakupljati i učiniti javno dostupnima na opisanom web sjedištu statističke informacije o radu usluge. Među


ovim informacijama mora biti podatak o broju izvršenih uspješnih i neuspješnih autentikacija iz sata u sat i na dnevnoj osnovi. Preporučeno vrijeme čuvanja ovih podataka je minimalno 12 mjeseci.

7.7 Komunikacija sustava pružatelja usluga s NIAAS-om

Usluga autentikacije korisnika putem NIAAS-a na sigurnosnim razinama 0 i 1 mora biti izgrađena na načelima maksimalne otvorenosti i smanjenja ukupnih troškova za implementaciju na strani pružatelja usluga i dugoročnih smanjenja troškova na strani NIAAS-a. Stoga je naglasak u pružanju usluge putem standardnih i dobro opisanih tehnologija i protokola.

Kao općenita preporuka pri implementaciji preferiraju se tehnologije i protokoli opisani u slijedećim dokumentima:

IETF Internet Official Protocol Standards (STD)

IETF Requests for comments (RFC), posebno dokumenti koji su klasificirani "best current practice", a izuzevši dokumente koji su proglašeni obsolete ili deprecated

Standards of the W3C

Za sve oblike komunikacije između sustava opisanih ovim dokumentom koristiti će se način kodiranja "UTF-8".

Za osiguranje sigurnosti pri pohrani i prijenosu podataka moraju se koristiti suvremeni, dokazani i javno dokumentirani standardni protokoli i algoritmi:

Za sigurnu komunikaciju protokolima TCP/IP: SSL verzije 3 ili više, TLS verzije 1 i više, sa pomoćnim protokolom (po potrebi): IPsec

Za simetričnu enkripciju: algoritam AES, sa pomoćnim algoritmima (po potrebi): 3DES, Camellia, Threefish, RC4. U svim slučajevima minimalna duljina ključa je 128 bita.

Za asimentričnu enkripciju: algoritam RSA, sa pomoćnim algoritmima (po potrebi): DHE, DSA. Minimalna duljina ključa u svim slučajevima treba biti ona koja složenost algoritama čini usporedivom sa RSA algoritmom sa 1024-bitnim ključem.

Za ireverzibilnu enkripciju (hash): algoritam SHA-256, sa pomoćnim algoritmima (po potrebi): SHA-512, SHA1, MD5, RIPEMD160.


Pri ovome se protokoli i algoritmi mogu kombinirati (SSL može koristiti sve popisane algoritme, na primjer: DHE-RSA-AES256-SHA), pri čemu se gore propisana pravila moraju primjenjivati na svaku komponentu.

7.7.1 Komunikacija u svrhu autentikacije korisnika

Protokoli koje opisana usluga autentikacije na sigurnosnoj razini 1 mora implementirati su:

1. Jednostavna SOAP (web service) metoda sa izravnim prijenosom korisničkog imena i ponovljive lozinke (korištenjem sigurnog protokola SSL odnosno TLS) u SOAP poruci te rezultata autentikacije u odgovoru.

2. Jednostavna HTTP "POST" metoda sa izravnim prijenosom korisničkog imena i lozinke (korištenjem SSL/TLS) u poruci te rezultata autentikacije u odgovoru.

3. OpenID 1.1 i 2.0, koji se može koristiti sa single sign-on autentikaciju web aplikacija.

Dodatni autentikacijski protokoli koji su preporučeni, ali opcionalni za implementaciju su:

- HTTP "digest" autentikacija (RFC 2617)

- RADIUS with Extension for Digest Authentication (RFC 5090)

- Security Assertion Markup Language (SAML) 2.0 za single sign-on

Implementacija u NIAAS-u može uključiti dodatne protokole, uz obrazloženja prema poglavlju "Dokumentacija implementacije i korištenja sustava."

Za slučaj korištenja jednokratne lozinke (OTP), protokoli kod kojih je to moguće mogu biti modificirani po potrebi i prema smislu tako da korisniku vraćaju informaciju o tome koja pobuda odnosno koja po redu lozinka se očekuje na autentikaciji. Pri tome je za protokole kod kojih ovo ima smisla (SOAP, HTTP) moguće implementiranje dodatnih metoda odnosno lokacija (URL) koje podržavaju ovu varijantu autentikacije.

Svi protokoli podliježu sigurnosnim zaštitama koje su opisane u poglavlju "Sustav autentikacije na sigurnosnoj razini 1." Dodatni zahtjevi na gore navedene protokole su:

Za autentikaciju protokolom SOAP:

Mora biti jamčena interoperabilnost sa širokim spektrom korisničkih biblioteka dostupnih u otvorenim i komercijalnim razvojnim okruženjima.

Za jednostavnu (POST) autentikaciju protokolom HTTP:


Ulazni podaci za autentikaciju će biti preneseni u sadržaju zahtjeva ("sadržaju POST-a"), formatirani u MIME obliku "application/x-www-form-urlencoded".

Rezultat autentikacije će se prenositi statusnim brojem HTTP poruke. Pri ovome će status "200" značiti uspješnu autentikaciju a ostali statusi će značiti neuspješnu.

Za autentikaciju protokolom OpenID:

Korisnički URL korišten u protokolu mora biti jednostavan i zapamtljivim, te kao posljednju komponentu uključivati OIB.

7.7.2 Izmjena korisničke lozinke

Za izmjenu ponovljive korisničke lozinke biti će implementirana SOAP (web service) metoda slijedećeg oblika:

ChangePassword(oib, old, new): Izmjenjuje ponovljivu korisničku lozinku na novu vrijednost uz prethodnu autentikaciju starom lozinkom.

Sustav može odbiti promjenu zaporke ako je nova zaporka identična staroj, ako je prekratka ili na neki drugi način nezadovoljavajuća.

Komunikacija podliježe sigurnosnim zaštitama koje su opisane u poglavlju "Sustav autentikacije na sigurnosnoj razini 1."

7.7.3 Komunikacija u svrhu rada sa proširenim skupom podataka centralnog imeničkog direktorija

U svrhu dodavanja i dohvaćanja informacija proširenog skupa podataka centralnog imeničkog direktorija biti će implementirana SOAP (web service) usluga koja će nuditi metode slijedećeg oblika koje se pozivaju od strane pružatelja usluga:

SetValue(username, password, oib, key, value): Upisuje zapis određen nazivom key sa vrijednošću value u informacijsku bazu za korisnički identitet određen sa podatkom oib.

GetValue(username, password, oib, key): Vraća vrijednost zapisa određenog nazivom key za korisnički identitet određen podatkom oib iz informacijske baze.

DeleteValue(username, password, oib, key): Briše zapis određen nazivom key za korisnički identitet određen podatkom oib iz informacijske baze.


ValueExists(username, password, oib, key): Vraća informaciju o postojanju zapisa određenog nazivom key za korisnički identitet određen podatkom oib u informacijskoj bazi.

Opća pravila koja vrijede za sve metode ove usluge:

Sustav ne čuva stanje između poziva (stateless).

Svaki poziv mora sadržavati korisničko ime i zaporku koja je izdana pružatelju usluge (ne osobi identificiranoj OIB-om) kako je opisano u poglavlju "Opis sigurnosnih razina 0 i 1."

Komunikacija podliježe sigurnosnim zaštitama koje su opisane u poglavlju "Sustav autentikacije na sigurnosnoj razini 1."

Ako se dohvaćaju podaci iz proširenog skupa podataka, naziv zapisa (key) uvijek mora sadržavati prefiks koji jedinstveno označava naziv prostora imena pružatelja usluga, čak i ako se podaci dohvaćaju za "lokalnog" pružatelja usluga koji je određen autentikacijom. Zahtjevi čiji naziv zapisa ne sadrži prefiks pružatelja usluga će se obraditi kao da rade sa podacima osnovnog skupa podataka.

Ovim metodama se ne može dohvaćati niti postavljati podatak "Password" niti bilo koji drugi podaci privatni za implementaciju autentikacije.

Ako se za isti naziv zapisa (key) za određenog korisnika (oib) višestruko poziva metoda SetValue, nove vrijednosti zapisa će prepisivati starije.

7.8 Dodatak A – očekivano opterećenje i performanse sustava

Koristeći moderne arhitekture aplikacija i računala, a uz potvrdu načinjenih simulacija ove vrste opterećenja očekivane performanse od sustava autentikacije opisanog u ovom dokumentu, koristeći jednostavne metode kao HTTP "POST" su minimalno 10,000 mrežnih autentikacija u sekundi po poslužitelju.

7.9 Dodatak B – veze sa drugim sustavima autentikacije

S obzirom na postojanje OIB-a koji je jedinstven i sveprisutan među krajnjim korisnicima usluge, sve druge metode autentikacije koje mogu jamčiti sigurno povezivanje osobe i elektroničkog identiteta sa OIB-om se mogu koristiti u sprezi sa opisanim sustavom.


U primjeru nadogradnje korištenjem PKI infrastrukture, korisnički certifikat i privatni ključ se mogu koristiti za dvojaku svrhu potpisivanje SSL (HTTPS) sjednica i prijenosa OIB-a kod protokola koji podržavaju Single Sign On (na primjer: OpenID, SAML).


8 PRILOG 2 – UVJETI ZA IZDAVANJE CERTIFIKATA FINA-E

8.1 Opći uvjeti za izdavanje certifikata

Način procesiranja Zahtjeva za izdavanje certifikata (u daljnjem tekstu Zahtjev) i pripadajuće dokumentacije ovisit će o vrsti traženog certifikata.

8.2 Dokumentacija

Tražitelj certifikata, fizika osoba – građanin ili poslovni subjekt za dobivanje certifikata od FINA PKI mora podnijeti slijedeću dokumentaciju:

1. Zahtjev za izdavanje certifikata

2. Potpisani ugovor o certifikatu ili izjava o prihvaćanju uvjeta

3. ID dokument za utvrđivanje identiteta fizičke osobe – građanina (fotokopija ID dokumenta fizičke osobe prilaže se uz dokumentaciju).

4. Dokumentaciju za utvrđivanje pravnog subjektiviteta / identiteta poslovnog subjekta

8.3 Korisnički računi

Otvaranje korisničkog računa je dio registracijskog procesa novog tražitelja certifikata ili subjekta u certifikatu u FINA PKI.

8.3.1 Fizičke osobe - građani

Korisnički računi

Korisnički računi koji se otvaraju fizičkim osobama – građanima sadrže slijedeće skupine podataka:

1. Opći podaci o korisničkom računu

2. ID organizacijske jedinice LRA i LRA zaposlenika

3. Podaci o korisniku

4. Način bezgotovinskog plaćanja izvršenih usluga


8.3.2 Poslovni subjekti

Korisnički računi

Korisnički računi koji se otvaraju poslovnim subjektima sadrže slijedeće skupine podataka:

1. Opći podaci o korisničkom računu

2. ID organizacijske jedinice LRA i LRA zaposlenika

3. Podaci o poslovnom subjektu

4. Način bezgotovinskog plaćanja izvršenih usluga

Korisnički podračuni

Krajnji korisnici certifikata koji se izdaju poslovnim subjektima su:

1. Zaposlenici poslovnog subjekta/pripadajuće osobe ovlašteni za potpisivanje

2. Aplikacije, poslužitelji i uređaji (VPN)

Za potrebe evidentiranja ovih subjekata otvaraju se korisnički podračuni tipa 1 i 2.

8.4 Identifikacija tražitelja certifikata

8.4.1 Fizičke osobe - građani

Državljani RH kao identifikacijski dokument mogu koristiti osobnu iskaznicu ili putovnicu. Ako je osoba strani državljanin, identifikacija se vrši putovnicom ili Europskom iskaznicom (Europskom identifikacijskom karticom). Prilikom identifikacije provjerava se sljedeće:

1. država izdavanja dokumenta,

2. broj dokumenta,

3. datum i mjesto izdavanja, i

4. rok važenja

8.4.2 Poslovni subjekti

Poslovni subjekti ovisno o zakonima i propisima u RH koje reguliraju obavljanje određenih aktivnosti prilažu slijedeću dokumentaciju za utvrđivanje pravnog subjektiviteta i identiteta:


1. Registracija poslovne djelatnost (upis u registar sukladno zakonima i propisima u RH)

2. Obavijest Državnog zavoda za statistiku o razvrstavanju po NKD radi preuzimanja šifre djelatnosti i matičnog broja

8.5 Dodatna provjera točnosti identifikacijskih podataka

FINA zadržava diskreciono pravo da dodatno provjeri točnost identifikacijskih podataka koji su prezentirani i upisani u Zahtjev. Provjera će se izvršiti temeljem rezidentnih podatka o fizičkoj osobi i/ili poslovnom subjektu koje posjeduje FINA ili neka druga organizacija.

8.6 Dokumentacija za utvrđivanje identiteta

Vjerodostojnost podataka iz Zahtjeva podnositelj zahtjeva fizička osoba – građanin dokazuje identifikacijskom ispravom. Podaci iz identifikacijske isprave moraju u potpunosti odgovarati podacima iz Zahtjeva (fotokopija ID dokumenta fizičke osobe prilaže se uz dokumentaciju).

8.7 Odbijanje Zahtjeva

Utvrdi li se da nisu ispunjeni uvjeti za izdavanje certifikata, Zahtjev s priloženom dokumentacijom vraća se podnositelju uz usmeno obrazloženje. Razlozi za odbijanje zahtjeva mogu biti:

nepotpunost ili neispravnost priložene dokumentacije

neslaganje podataka o tražitelju s podacima iz dokumentacije Zahtjeva

drugi razlozi


9 PRILOG 3 – SIMETRIČNI I ASIMETRIČNI KRIPTOSUSTAVI

9.1 Simetrični kriptosustav

Simetrični kriptosustav je najstariji oblika kriptografije, stara gotovo koliko i ljudska komunikacija. Još se naziva i kriptografijom tajnog ključa jer se podatak kriptira i dekriptira istim ključem (tajni ključ, sjednički ključ). U simetričnim kriptosustavima ključ kriptiranja KE jednak je ključu dekriptiranja KD. Prema tome zajednički ključ se može označiti jednim simbolom K, te za takav sustav vrijedi:

C = E(P, K),

P = D(C, K),

odnosno:

P = D(E(P, K), K).

Slika 21. Simetrični kriptosustav. Alice šalje poruku Bobu kriptiranu tajnim ključem K, a Bob je dekriptira tim istim ključem (KE = KD = K).

Za proces kriptiranja u simetričnom kriptosustavu potrebno je znati algoritam kriptiranja i tajni ključ. Nekad su se algoritmi držali u tajnosti, ali se pokazalo da skrivanje algoritma ne doprinosi sigurnosti. Svi suvremeni simetrični algoritmi javno su obznanjeni. Zbog toga ih je u


potpunosti moguće testirati i provjeriti njihovu otpornost na napade, odnosno moguće ih je analizirati (kriptoanaliza). Sigurnost simetričnih algoritama ovisi o sigurnosti samog algoritma i dužini ključa. Najpoznatiji simetrični algoritam je DES (Data Encryption Standard). Bio je standardni simetrični algoritam sve do 2000. godine kad ga je zamijenio AES (Advanced Encryption Standard), koji rukuje ključevima dužine 128, 192 i 256 bita. Glavni razlog zbog kojeg je DES zamijenjen AES-om je taj što DES ima dužinu ključa od 56 bita.

Osnovni nedostatak simetričnih algoritama, odnosno simetričnih kriptosustava, jest upravljanje ključevima, točnije njihova distribucija. Prije same sigurne komunikacije subjekti (sudionici komunikacije) moraju razmijeniti ključeve. Pošto se sigurnost svih zaštićenih (kriptiranih) informacija oslanja na sigurnosti ključa, sigurna razmjena ključeva može postati vrlo ozbiljan problem. On dolazi do izražaja još više što se komunikacija odvija na većoj udaljenosti, a u samoj komunikaciji sudjeluje više subjekata. Za n korisnika u komunikaciji potrebno je n(n - 1)/2 ključeva. Generiranje i upravljanje ovako velikim brojem ključeva je najčešće nepraktično, a njihova razmjena nesigurna.

Rješavanje ovog problema, problema razmjene tajnih ključeva, dovela je do pojave asimetričnih algoritama odnosno asimetrične kriptografije.

9.2 Asimetrični kriptosustav

Asimetrični kriptosustav se temelji na ideji razmjene tajnog ključa u kojoj je predočeno postojanje para ključeva: ključ za kriptiranje P i ključ za dekriptiranje S, umjesto jednog istog ključa za kriptiranje i dekriptiranje K. Jedan ključ je javno dostupan svima, naziva se javni ključ, i on služi za kriptiranje. Drugi ključ je poznat samo njegovom vlasniku, naziva se privatni ključ, i služi za dekriptiranje poruka.

Slika 22. : Razmjena tajnog ključa K između Alice i Boba asimetričnim kriptiranjem.

Razmjena tajnog ključa K između Alice i Boba asimetričnim kriptiranjem (slika 22). Alice šalje tajni ključ K kriptiran Bobovim javnim ključem PB, a Bob ga dekriptira svojim privatnim


ključem SB. Ključ K služi kao ključ kriptiranja u daljnjoj komunikaciji između Alice i Boba (taj ključ se još naziva i sjedničkim ključem).

Osnova sigurnosti asimetričnih algoritama temelji se na nemogućnosti (ili vrlo teškoj mogućnosti) izračunavanja privatnog ključa iz javnog ključa. Prema najpoznatijim algoritmima koji se koriste u asimetričnoj kriptografiji ovaj se problem svodi na težinu faktorizacije prirodnih brojeva na proste faktore. Takav algoritam je i RSA (Rivest, Shamir, Adleman). Treba istaknuti da se asimetrični algoritmi ne koriste za kriptiranje velikog broja podataka. Njihova osnovna namjena je razmjena sjedničkih ključeva prije početka sjednice odnosno komunikacije između subjekata. Razlog ovome ponajviše je taj što je asimetrično kriptiranje za nekoliko redova sporije od simetričnog kriptiranja. Iz sigurnosnih razloga trajanje (misli se na vremensko razdoblje u kojem je ključ aktivan) sjedničkog ključa je relativno kratko, a najčešće je onoliko koliko traje sjednica. Trajanje javnog i privatnog ključa kod asimetričnog kriptosustava je znatno duže, i nije ga potrebno previše često mijenjati jer je količina podataka koja se kriptira asimetričnom kriptografijom znatno manja (to su u pravilu kratke poruke poput sjedničkog ključa), a to znatno otežava neke vrste napada.

Poželjno svojstvo asimetričnih algoritama je sljedeće: ako je poruka kriptirana javnim, njezino dekriptiranje obavlja se privatnim ključem, a ako se poruka kriptira privatnim ključem, njezino dekriptiranje obavlja se javnim ključem. To je svojstvo asimetričnog algoritma u kojem je svejedno koji ćemo ključ izabrati za kriptiranje (ali tada dekriptiranje obavljamo onim drugim ključem). Ovo važno svojstvo nekih asimetričnih algoritama jednostavno omogućava digitalno potpisivanja dokumenata ili digitalni potpis, bez kojeg bi bilo nemoguće ostvariti PKI sustav.

9.3 Sažetak poruke

Sažetak poruke osigurava sigurnosni zahtjev besprijekornosti odnosno integriteta poruke. Kriptografski sažetak izrađuje se jednosmjernom funkcijom koja iz poruke proizvoljne duljine izračunava sažetak stalne duljine. Ova je funkcija jednosmjerna stoga što je izračunavanje sažetka vrlo lako dok je iz sažetka praktički nemoguće izračunati izvornu poruku.

Razlog zbog kojeg se uvodi kriptografski sažetak bit će objašnjen na primjeru. Pretpostavimo da Bob i Alice žele komunicirati i da međusobno poznaju javne ključeve. Bob želi biti siguran:

- da je neki javni tekst koji mu je Alice poslala uistinu njezina poruka i

- da neki napadač (Eve) nije tijekom komunikacije mijenjao sadržaj poruke, odnosno da je primljenoj poruci sačuvan integritet.


Najjednostavniji oblik jednosmjerne funkcije je uzastopna uporaba XOR funkcije na nizu bitova koji se dobivaju dijeljenjem izvorne poruke na dijelove jednake duljine. Najpoznatiji algoritmi koji izračunavaju sažetak su MD5, SHA-1, SHA-256. Standardne duljine sažetka se kreću od 64 bita pa do 256 bita (64, 128, 160, 256), a ovise o algoritmu sažimanja.


10 KAZALO POJMOVA

1999/93/EC – direktiva Europske komisije vezana za elektroničke potpise

95/46/EC – direktiva Europske komisije vezana za zaštitu privatnosti

ARL – (eng. Authority Revocation List); poseban oblik CRL-a; lista opozvanih certifikata izdanih CA-ovima

Autentikacija – ovjera vjerodostojnosti identifikacije (najčešće putem zaporke)

Autorizacija – davanje pristupa autenticiranim korisnicima putem pristupno-kontrolne liste

Bridge CA – povjerljiv CA koji služi umjesto međusobno bilateralnog certificiranja između različitih CA-ova prema jednoj ili više politika certificiranja

CA – (eng. Certificate Authority); certifikacijski centar

Certifikat (v. Digitalni certifikat)

CP – (eng. Certificate Policy); politika upravljanja certifikatima

CRL – (eng. Certificate Revocation List); lista opozvanih certifikata

Cross-certifikat – uspostava relacije povjerenja između dva CA

CSP - (eng. Credentials Service Provider); registrira fizički entitet te generira elektroničke vjerodajnice i međusobno ih povezuje

CTL – (eng. Certificate Trust List); struktura podataka koja sadrži listu povjerljivih CA

CWA 14890 – standard za aplikacijsko sučelje kod pametnih (smart) kartica koje se koristi za generiranje digitalnog potpisa

CWA 14171 – standard za verifikaciju elektroničkog potpisa

Digitalni certifikat - skup podataka u elektroničkom obliku koji predstavlja elektronički identitet u raznim elektroničkim interakcijama

ECC – (eng. European Citizen Card); europski standard koji definira osnovna svojstva koja eID kartice moraju imati


eID – elektronička reprezentacija subjekta u smislu specificiranih atributa koji ga identificiraju u sustavim elektroničkih usluga

ETSI QCP 101 456 – međunarodna norma za digitalne potpise

Elektronički potpis (v. Napredni elektronički potpis) – digitalni potpis u kojem se korištenjem kvalificiranih certifikata jamči neporecivost u elektroničkim komunikacijama

Host – računalni sustav na kojem se izvršavaju usluge pojedinog tijela državne ili lokalne uprave i samouprave

HSM – (eng. Hardware Security Module); sklopovski sigurnosni moduli koji služe za uspostavu sigurne okoline za pohranu ključeva/certifikata

HTML – (eng. HyperText Markup Language); prezentacijski jezik za kreiranje web stranica

HTTP – (eng. HyperText Transfer Protocol); protokol za komunikaciju između poslužitelja i klijenta

HTTPS (v. SSL)

IAA – sustav identifikacije autentikacije i autorizacije

Identifikacija – predočenje korisničkog imena

IS – informacijski sustav

ISO 19785-1 – format za standardizirane biometrijske podatke

ISO 19794-2 – format za podatkovnu reprezentaciju otisaka prstiju

ISO 27001 – standard za sustav sigurnog upravljanja informacijama

ISO 7816 – standard za kontaktne pametne kartice; specificira identifikacijske kartice sa elektroničkim kontaktima, njihove fizičke karakteristike, lokacije kontakata, prijenosne protokole za podatke na ulazu i izlazu

ISO/ITU x.509 – standard za PKI koji definira formate za javne ključeve

I&A – identifikacija i autorizacija

LDAP – imenički sustav za upravljanje identifikatorima koji su tada raspoloživi procesima koji ih trebaju

LRA – (eng. Local Registration Authority); lokalni registracijski centar


Napredni elektronički potpis (v. Elektronički potpis) – digitalni potpis koji se koristi za potrebe identifikacije u elektroničkim komunikacijama

NCARH – Nacionalno certifikacijsko tijelo Republike Hrvatske

NIAAA – Nacionalna IAA agencija

NIAAS – Nacionalni IAA sustav

Odgovornost – (eng. Accountability); nadležnost za rezultate (stanje)

OIB – osobni identifikacijski broj

OTP – (eng. One Time Password); jednokratna lozinka

PCA – (eng. Prinicipal Certificate Autority); glavni CA

PIN – (eng. Personal Identification Number); brojčana zaporka

PKI – (eng. Public Key Infrastrucrure); infrastruktura javnog ključa koja koristi certifikate zasnovane na kriptografiji javnog ključa za autentikaciju identifikatora

PMA – (eng. Policy management authority); tijelo odgovorno za certificiranje i akreditaciju

RA – (eng. Registration Authority); registracijski centar

RFC 2617 – standard za HTTP autentikaciju

Revizija – (eng. Auditing); kontrola aktivnosti

SAML – sigurnosni standard temeljen na XML-u, služi za prijenos autentikacijskih i autorizacijskih informacija

SSCD – (eng. Secure Signature-Creation Device); sklopovski uređaj za omogućavanje sigurne prijave na sustav

SOAP – (eng. Simple Object Access Protokol); komunikacijski protokol, neovisan o platformi, baziran na XML-u koji se koristi za razmjenu informacija između aplikacije preko HTTP protokola

SMTP – (eng. Simple Mail Transfer Protocol); standard za prijenos elektroničke pošte na internetu

SSL – (eng. Secure Sockets Layer); protokol razvijen za prijenos privatnih podataka putem Interneta; naziva se još i HTTPS


TCP/IP – grupa komunikacijskih protokola koja omogućuje komunikaciju preko raznih međusobno povezanih mreža

TDU – tijelo državne uprave

Token – sigurnosni sklopovski uređaj koji se koristi za identifikaciju korisnika prilikom prijave u sustav

TRC – (eng. Trust relationship Contract) uspostava relacije povjerenja između registara različitih TDU

Tripartitno povjerenje – uspostava povjerenja između tri strane

XML – standard temeljen na oznakama koji služi za razmjenu strukturiranih podataka

X.509 –standard za određivanje formata zapisa i semantike pojedinih polja digitalnih certifikata

VE – (eng. Verifying Entity); verifikacijski entitet koji utvrđuje da li korisnici transakcija imaju valjane elektroničke vjerodajnice

W3C XML validacija – validacija XML dokumenta u skladu sa W3C standardom

WS-Policy – skup specifikacija koje opisuju svojstva i ograničenja sigurnosne politike pojedinih servisa

WS-Security – skup specifikacija za osiguravanje integriteta i povjerljivosti u komunikacijskim protokolima

WS-Trust – proširenje WS-Security specifikacije u smjeru upravljanja korištenjem sigurnosnih tokena

Documents

Prijedlog koncepta integriranog središnjeg sustava ... · minimalni skup atributa koji definiraju identitet koji će se ostvariti kroz uspostavu centralnog direktorija elektroničkog