SADRAJ

1. UVOD ........................................................................................................4 2. OSNOVE....5 3. TERMINOLOGIJA5 4. PKI HIJERARHIJA..6 5. POTREBE ZA PKI..,.7 6. INSTALIRANJE SERTIFIKAT SERVISA..8 7. SERTIFIKAT OBRASCI.....17 8. IZDAVANJE SERTIFIKATA.22 9. ZAHTEVANJE SERTIFIKATA PREKO WEB PRETRAIVAA..23 10. POVLAENJE SERTIFIKATA..26 11. INFRASTRUKTURA..27 12. POLITIKE I TEHNOLOGIJA.27 13. ZAKLJUAK...29 14. LITERATURA.30

2

UVOD

Pronalaenje naina za autentifikovanje, enkripciju i verifikovanje integriteta informacije u preduzeu je bio stalan izazov tokom decenija. Biti u stanju osigurati da podaci ne budu modifikovani u prenosu, biti u stanju osigurati da podatke ne vidi neko kome oni nisu namenjeni, ili imati siguran nain autentifikovanja je bio teak zadatak tokom dugog niza godina. Nain na koji se Microsoft pozabavio sa ovom problematikom jeste implementacija sertifikata i prateih servisa to je poznato kao Infrastruktura sa javnim kljuem PKI (Public Key Infrastructure). Uvoenjem PKI u nae okuenje moemo obezbediti poverljivost, integritet kao i autentifikaciju kroz itavo preduzee.

Verujem da je najjednostavniji nain objanjavanja MS PKI kroz konkretan primer. Cilj mi je objanjavanje MS CA servisa jezikom i primerima koji e biti razumljivi i itaocu koji nije uopte upuen u PKI tehnologiju. Poto Windows Server2000 lagano gazi vreme a Longhorn je tek na horizontu naredne pasuse u posvetiti trenutno najzastupljenijem Microsoft-ovom operativnom sistemu koji ima implementiran Certificate Authorities a to je Windows Server2003.

3

OSNOVE Prvo to trebamo razumeti jeste ta je to PKI?. PKI je skup servisa, servera i administratora zaduenih za distribuciju i upravljanje javnim i privatnim kljuevima u okruenju. Kada priamo o PKI ne priamo o samo jednoj komponenti nego, priamo o tome kako svi servisi, serveri i administratori rade zajedno kako bi obezbedili privatne i javne kljueve za enkripciju, autentifikaciju i obezbeivanje integriteta u naem okruenju. Neke od ovih entiteta moeno kontrolisati pomou softvera, dok druge kontroliemo pomou politika. Naprimer, moda imamo politiku koja e definisati kako administratori rade sa PKI servisima i serverima. U mnogim situacijama je nemogue softverom tano definisati kako bi se administratori trebali ponaati, tako da je deo pravila rada sa servisima i serverima definisan softverom a deo politikama. PKI (Public Key Infrastructure)

o Servisi o Serveri o Administratori

- Odgovorni za distribuciju i upravljanje javnim i privatnim kljuevima u okruenju TERMINOLOGIJA Certificate predstavlja digitalni fajl koji sadri kljueve za korisnika koji mu omoguuju korienje enkripcije, autentifikacije i usluga vezanih za proveru integriteta. Certificate templates predstavlja predefinisani skup podeavanja koji definiu kako sertifikat treba funkcionisati Certificate authorities (CA) predstavalj server ili servis kome se veruje prilikom izdavanja sertifikata. Microsoft sertifikat servisi u Windows 2003 Serveru su primer CA koji je obezbeen putem softvera. Postoje i drugi dobavljai ove usluge kao to su VerSign, Thawte..., koji e dostaviti sertifikate klijentima i njima se javno veruje. Drugim reima, veb pretraivai imaju lokalno bazu sertifikata na osnovu koje mogu ustanoviti da je sertifikat izdat od strane VerSigna, sertifikat kojem se moe verovati. Certificate life cicle predstavlja period u kojem e sertifikat biti validan. Vano je primetiti da period trajanja sertifikata diktiraju svi CA u lancu. On to elim rei jeste da ukoliko Root CA izda sertifikat nekom x_CA na dve godine, a x_CA izda korisniku sertifikat na 10 godina, validnost tog sertifikata e biti dve godine. Certificate revocation list (CRL) predstavlja listu sertifikata koji vie nisu validni. Raunari moraju bitu u stanju da provere CRL

malidexterHighlight

malidexterHighlight

malidexterHighlight

malidexterHighlight

malidexterHighlight

4

Certificate enrollment predstavlja potranju sertifikata. U nekim sluajevima emo dobiti automatski sertifikat, dok je u nekim sluajevima potrebno odobrenje od strane administratora za distribuciju. Certificate distribution predstavlja distribuciju sertifikata Certificate revocation predstavlja povlaenje sertivikata, tj. stavljanje istog na CRL Key archival and recovery predstavlja uvanje validne kopije kljueva i mogunost njihovog oporavka u sluaju vanrednih situacija. Naprimer, predefinisani nain na koji sistem za enkripciju fajlova (EFS) u Windows Serveru 2003 radi jeste taj da se kljuevi za enkripciju uvaju u korisnikom profilu. Ukoliko se taj profil sluajno obrie, oteti ili uniti korisnik e ostati bez kljueva. Postavlja se pitanje kako pristupiti podacima koji su enkriptovani tim kljuevima. Ukoliko smo arhivirali kljueve, neemo imati problema. PKI HIJERARHIJA Kada priamo o PKI arhitekturi mislimo na logiku strukturu CA. Ukoliko pogledate sliku 1.1 videete da imamo Root CA koji predstavlja centar nae PKI arhitekture. Izvor na osnovu kojeg svi ostali CA dobijaju validnost. Takoe imamo intermediateCA koji su podreeni Root CA. Zatim imamo JapanCA, US CA, India CA koji su zadueni za konkretno izdavanje sertifikata. India CA, JapanCA i US CA dobijaju pravo izdavanja sertifikata na osnovu intermediateCA, dok intermediateCA dobija pravo izdavanja na osnovu Root CA. Samom Root CA se veruje jer je to jednostavno tako, kao to se veruje MUP-u neke drave.

slika 1.1 Ono to treba imati na umu jeste to da ukoliko se Root CA kompromituje na bilo koji nain, kompletna PKI arhitektura je kompromitovana i svi izdati sertifikati moraju biti smeteni na CRL. U ovom najgorem moguem scenariju je potrebno doslovce instalirati nove CA od samog Root CA da onog krajnjeg, koji izdaje sertifikate. Takoe je potrebno generisati ili tanije izdati nove sertifkate za sve organizacije, a organizacije zatim moraju izdati nove sertifikate svim klijentima. Pria je identina ukoliko je intermediateCA kompromitovan. Svi podreeni CA moraju biti ponovo instalirani, i novi sertifikati moraju biti izdati. Ova proces je veoma vremenski zahtevan i

malidexterHighlight

malidexterHighlight

malidexterHighlight

malidexterHighlight

malidexterHighlight

malidexterHighlight

malidexterHighlight

malidexterHighlight

malidexterHighlight

malidexterHighlight

5

iz tog razloga je potrebno obezbediti veoma visok nivo bezbednosti za Root CA, visok nivo bezbednosti za intermediateCA, i dobar nino bezbednosti za CA koji izdaje sertifikate. POTREBE ZA PKI Takoe trebamo obratiti panju na razloge iz kojih uopte implementiramo PKI. Koje su potrebe? Postoje mnogi naini upotrebe sertifikata. Moda ete hteti obezbediti komunikaciju izmeu klijenta i vaeg servera implementacijom SSL-a... Potrebno je uoiti razliku izmeu internet web servera i vaeg intranet web servera. Ukoliko je u pitanju internet web server koristiete javno izdat sertifikat koji e vam obezbediti npr. VerSign. Ukoliko je u pitanju intranet tj. vaa lokalna mrea u preduzeu, koristiete sertifikat servise koji e vam omoguiti izdavanje sertifikata web serveru na osnovu kojeg ete implementirati SSL Sertifikate takoe moemo koristiti za sigurnu komunikaciju elektronskom potom. Postoji vie naina na koji je to mogue postii. Jedan je enkripcija pote na jednom kraju a dekripcija na drugom kraju. Ukoliko elim poslati e-pismo nekome, mogu enkriptovati poiljku javnim kljuem te osobe koji sam dobio preko sertifikat servisa. Poto jedino osoba kojoj je namenjeno pismo ima tajni klju koji odgovara poruci, pismo moe dekriptovati samo ta osoba. Drugi nain obezbeivanja pote jeste enkripcija same komunikacije pomou TLS-a ili SSL-a. Sertifikate takoe moemo koristiti za digitalne potpise. U ovom sluaju nije nam od znaaja enkripcija podataka. U cilju nam je verifikacija izvora podataka (u IT svetu poznato pod nazivom neporecivost nonrepudiation). Drugim reima, osoba koja je poslala podatke ne moe rei da je to uradio neko drugi, jer je poiljka potpisana tajnim kljuem koji ima samo ta osoba. To i jeste princip po kojem funkcionie digitalni potpis. Ukoliko poaljem podatke a zatim ih potpiem svojim tajnim kljuem, injenica da je mogue izvriti proveru mojim javnim kljuem daje do znanja primaocu da je poruka zaista stigla od mene. Jo jedan od naina korienja sertifikata su Smart Cards (pametne kartice). Smart kartice su kartice koje na sebi uvaju podatke o sertifikatu. Moemo ih nositi u novaniku, kao bed ili na neki slian nain. Istu tu karticu ubacujemo u ita nakon ega smo autentifikovani. Sledei mogunost korienja sertifikata je sa IPSec-om to nam daje visoki nivo bezbednosti u naim TCP/IP komunikacijama. I na kraju sertifikati mogu biti korieni kao sredstvo za autentifikaciju. Moemo autentifikovati nae RRAS dial-in korisnike, VPN korisnike kao i WAN korisnike. Sertifikat servisi i PKI mogu postati veoma kompleksni, meutim njihova implementacija nam daje za uzvrat veliku kontrolu i mnogo vei nivo bezbednosti.

malidexterHighlight

malidexterHighlight

malidexterHighlight

6

INSTALIRANJE SERTIFIKAT SERVISA Preporuuje se inplementacija PKI hijerarhije kada instalirate sertifikat servise. To znai da je preporuljivo instalirati Root CA, intermediateCA a zatim i CA koji izdaje sertifikate. Za ovakav savet postoje razlozi, a najuoljiviji je taj da se optereenje sa jednog CA prenosi na distribuirano okruenje. To nije obavezni scenario, ali nam obezbeuje rastereenje kao i vei nivo bezbednosti. Ono to sledi kao demonstracija jeste instaliranje samostalnog sertifikat servera kako bih mogao preciznije objasniti Certificate templates... Bitno je napomenuti da je Microsoft-ova preporuka za instalaciju CA ba ova gore navedena. Root CA, Srednji CA a zatim i CA za izdavanje sertifikata. Kada instaliramo PKI dobro je imati ve instaliran IIS (internet informatino services) ukoliko planiramo koristiti Certificate enrollment baziran na web-u. Takoe se trebamo postarati da je ASP (Active Server Pages) aktiviratn, poto Certificate enrollment preko web-a koristi ASP.

slika 1.2 instalacija IIS komponenti

7

slika 1.3 provera stanja ASP-a

8

slika 1.4 Trea stavka po redu u Windows Components prozoru jeste Certificate Services. Pre nego to pokrenemo arobnjaka za instalaciju, dobiemo upozorenje da posle instalacije sertifikat servisa neemo moi menjati ime maine, niti je islaniti ili ulaniti u domen. U mom konkretnom sluaju ovu mainu neu udaljiti iz domena u skorije vreme poto je ova maina DC mog okruenja. Meutim ukoliko instaliram sertifikat servise na nekoj samostalnoj maini, potrebno je veoma dobro obratiti panju na ovo upozorenje jer kasnije mogu nastati veliki problemi. Pre svega je potrebno dobro isplanirati inplementaciju PKI, da ne bi smo doiveli neprijatne situacije. Ukoliko pogledamo detalje vezane za sertifikat servise videemo ta e tano biti instalirano.

slika 1.5

U sledeem koraku trebamo napraviti izbor izmeu:

Enterprise root CA Enterprise subordinate CA Stand-alone root CA Stand-alone subordinate CA

Po Microsoft-ovim preporukama za CA arhitekturu prvo bi trebao biti instaliran Stand-alone root CA, to znai da e to biti root CA koji nije integrisatn sa AD. Sledei srednji CA i CA za izdavanje sertifikata e biti Enterprise subordinate CA. Poto u naem sluaju instaliramo samostalni CA, na izbor e biti Enterprise Root CA, koji e biti integrisan sa AD-om. Takoe emo tiklirati opciju za dodatna podeavanja za generisanje kljueva CA sertifikata.

9

Slika 1.6 U prozoru Public and Private Kay Pair moemo izabrati duinu kljua, hash algoritam, CSP (cryptographic service provider) kao i mogunost korienja ve postojeeg kljua. Mislim da je nepotrebno objanjavati potrebu za veom duinom kljua, a to se tie hash algoritama pametno je izabrati SHA-1. MD4 je pre izvesnog vremena razbijen od strane jedne Kineske grupe entuzijasta. Sistem za razbijanje je bio veom vremenski zahtevan, ali je u prihvatljivom vremenu davao rezultate. Isti taj sistem je unapredila jedna eka grupa, tako da je do razbijanja dolazilo uz pomo mnogo slabijih raunara i to u mnogo kraem vremenski perijodu. Kao odgovor na novu pretnju pojavio se MD5, koji je takoe razbijen od strane Kineza.

10

slika 1.7

Zatim emo dati ime naem CA. Takoe emo izabrati period vaenja sertifikata ovog sertifikacionog tela. To znai da je potrebno obnoviti period vaenja pre 03. Okt. 2017 god. Izabran je period od 10god. to moe biti razuman izbor uzimajui u obzir duinu generisanog kljua.

slika 1.8

11

Zatim sledi generisanje kljua koji e biti inplementiran u CA. To je u stvari privatni klju Singidunum_CA. Ovaj klju e biti korien za validaciju svih sertifikata koje ovaj CA izda. Poto je ovo jedini CA koji imamo u naem okruenju, klju koji smo generisali e biti korien za validaciju EFS sertifikata, IPSec sertifikata, SSL sertifikata i bilo kojih drugih sertifikata koje generiemo za nae okruenje. Ostalo je jo nekoliko koraka koji se odnose na podeavanja baze sertifikata, u naem sluaju baza e ostati na istom HDD-u, to ne bi bilo toliko pametno u radnom okruenju zbog performansi. Posle nekoliko upozorenja vezanih za IIS instalacija naeg CA je gotova. U start meniu pod administratoriskim alatima emo pokrenuti Certification Authority a zatim emo izabrati properties naeg CA.

slika 1.9

Odavde je mogue izvriti mnoga podeavanja vezana za Singidunum_CA. Ako izaberemo Policy Module, a zatim properties mogue je definisati kako e se rukovati sa zahtevima.

12

slika 1.10

Mogue je podesiti automatsko izdavanje zahteva to je novina u Windows Serveru 2003. Ukoliko potvrdimo prvu opciju, administrator e morati runo potvrditi izdavanje svakog pojedinanog sertifikata.

Sledei tab koji emo razmotriti u Singidunum_CA/properties jeste Exit Module koji definie ta e se desiti kada je sertifikat odobren.

slika .1.11

13

Potvrivanjem opcije u prozoru Publication Settings dozvoljavamo publikaciju u fajl sistemu. To znai da e sertifikat biti smeten u fajl sistem kao i u aktivini direktorijum. Takoe moemo podesiti i Storage properties.

slika 1.12

Moemo odrediti da se sertifikati uvaju u aktivnom direktorijumu. U naem sluaju to je podrazumevano jer smo Singidunum_CA konfigurisali kao Enterprise root CA, a svi Enterprise CA uvaju sertifikate u aktivnom direktorijumu i ne postoji nain da se konfigurie drugaije.

14

Ovde moemo takoe konfigurisati i Auditing.

slika 1.13

Praenje i nadgledanje nije automatski aktivirano, potrebno je potvrditi opcije da bi ono bilo startovano. Moda elite nadgledati ko je povukao sertifikat, ili ko je menjao sigurnosne opcije vezane za CA. Poto Auditing koristi deo resursa vaeg servera, potrebno je dobro razmisliti ta elite kontrolisati.

I naizad sigurnost.

slka 1.14

15

Na ovom tabu moete definisati prava. Moete definisati ko ima pravo upravljanja sertifikatima, upravljanej Singidunum_CA Dobra je praksa bekapovati server nakon instalacije sertifikat servisa. Kada smo ve kod bekapovanja, poeleete da ga bekapujete i pre instalacije CA, jer nakon instalacije ne moete ulainiti ili islaniti va server iz domena. A moe veoma lako da se desi da neko iz rukovodstva kae da bi taj server trebao postati lan ili biti islanjen. U tom sluaju neete imati velikih problema, jer je vaa maina bekapovana i moete je vratiti u stanje pre instalacije CA, a zatim moete ponovo instalirati sertifikat servise. Nakon ega moete normalno nastaviti sa radom. SERTIFIKAT TAMPLATES

Sertifikat templejti pojednostavljuju proces pravljenja sertifikata. Umesto da kreemo od nule u definisanju pravila, moemo koristiti predefinisane templejte. To nas ne spreava da menjamo same templejte i njihovu funkcionalnost. Windows Server 2003 po prvi put predstavlja templejte verzije 2. Verzija 2 uvodi novinu kombinovanja funkcionalnosti iz razliitih templejta u jedan. To znai da jedan sertifikat moemo izdati korisniku za IPSec, enkripciju, potpisivanje pote... Verzija 2 takoe po prvi put predstavlja mogunost autoenrollment-a. Bitno je napomenuti da je ova opcija podrana samo u Datacenter i Enterprise Windows Server2003 izdanjima. Ovo nema veze sa Enterprise CA opcijom koja je ranije bila razmatrana, nego iskljuivo sa verzijom Windows Servera2003. Templejti verzije 1 su i dalje podrani u Windows Server 2003 operativnom sistemu. Windows Server 2003 dolazi u etiri razliita izdanja a to su: Standard, Enterprise, Web i Datacenter. Standardna edicija ima ogranienje u skalabilnosti, nemogue ju je pokrenuti na hardveru sa vie od 4 CPU a maksimalna koliina rama je 4GB. Enterprise dolazi u dve verzije a to su 32 bit i 64 bit verzija do 32GB RAM-a (32bit verzija) . Podrava menjanje memorije na ivo. Moete ubaciti memoriju bez iskljuivanja maine ukoliko to va hardver podrava. Datacenter izdanje podrava do 64 CPU u 64bit-noj verziji. Web edicija je osiromana Standard edicija na kojoj nije dozvoljenjo instaliranje bilo kakvog softvera koji nije namenjen Web Hostingu. Datacenter i Web edicije dolaze u OEM poiljkama ili ih moete traiti direktno od Microsofta. Za Datacenter Microsoft garantuje rad od 99.999% vremena godinje, to znai da va server u najgoru ruku moe biti ofline svega 6 min godinje. DEFAULT USER TEMPLATES

16

Postoje razliite vrste podrazumevanih templejta:

Administrator koji nudi mogunosti o User authentication o EFS encryption o Secure e-mail o Certificate turst list signing

Authenticated session Basic EFS Code Signing

o Used to digitally sign software

EFS Recovery Agent Enrollment Agent Exchange Enrollment Agent Exchange Signature Only Exchange User Smart Card Logon Smart Card User Trust List Signing User User Signature Only

Pored podrazumevanih korisnikih templejta postoje i podrazumevani Computer Templates, kao i Default Service Templates. UPRAVLJANJE TEMPLEJTIMA Templejtima se upravlja sa istog mesta odakle upravljamo sa naim CA, a to je Start/Administrative Tools/Certification Authority

slika 1.15

Izabraemo opciju Manage za Certificate Tamplates, kako bi smo mogli dodati templejt koji nama treba. Sa desne strane moete videti templejte koji su trenutno aktivni i na osnovu kojih je mogue izdavati sertifikate, takoe moete primetiti da ne postoji IPSec templejt trenutno.

17

Opcijom menage smo pokrenuli konzolu za upravljanje sertifikatima.

Svi templejti koje Windows Server 2003 ima predefinisano ugraene se nalaze sa desne strane. Moete primetiti zasenene ikone, kao i aktivne ikone. Ikone koje su u boji, predstavljaju templejte koji su u upotrebi.

Ukoliko poelimo koristiti neki neaktivni templejt, izabraemo opciju Duplicate Template posle korienja desnog kljika nad odreenim templejtom. Poto nas interesuje IPSec, kliknuemo destnim tasterom mia nad IPSec templejtom a zatim emo ga duplirati.

slika 1.17

Otvara nam se prozor gde je mogue vriti razna podeavanja vezana za templejt koji elimo aktivirati. Na tabu General je mogue definisati ime pod kojim e biti prikazan ovaj templejt, period

18

vaenja kao i period obnavaljanja. Takoe je mogue u ostalim tabovima podesiti duinu korienog kljua, pravila vezana za izdavanje i potranju sertifikata...

slika 1.18

Zatim emo izabrati opciju za izdavanje novog templejta za sertifikate i iz liste emo izabrati koji templejt elimo aktivirati. U naem sluaju e to biti templejt za IPSec sertifikat. Ovim smo zavrili implementaciju novog templejta ime smo omoguili izdavanje novog sertifikata.

slika 1.19 IZDAVANJE SERTIFIKATA

19

Ono to nam preostaje jeste da proverimo da li je na osnovu ovog templejta mogue izdati sertifikat. Tanije, da li je sve inplementirano kako treba i da li to uopte funkcionie. Pokrenumo MMC Microsoft Menegmant Consol a zatim dodati snap-in za sertifikate.

slika 1.20

U okviru konzole emo zatraiti novi sertifikat. Nakon selektovanja ove opcije pokrenue se arobnjak u kojem moete izabrati razliite opcije, a na samom kraju pre potvrde zahteva, dobiete pregled svih opcija koje ste izabrali.

slika 2.1

Time smo zavrili proces izdavanja sertifikata.

20

slika 2.2

Kao to vidimo namena ovog sertifikata je dozvoljavanje sigurne komunikacije preko interneta, to je i logino jer je ovaj sertifikat namenjen za IPSec. Moemo videti i ko je izdao kome ovaj sertifikat i koliko je njegovo trajanje. Takoe je mogue videti i detaljnije podatke vezane za ovaj sertifikat.

slika 2.3

ZAHTEVANJE SERTIFIKATA PREKO WEB PRETRAIVAA

21

Jedan od naina zahtevanja sertifikata jeste odlazak na web lokaciju CA. Poto se Singidunum_CA nalazi na lokalnoj maini, kao adresu u navesti ime ovog raunara, a zatim folder u kojem se nalazi sertifikat server. Podrazumevana lokacija je http://imeRacunara/certsrv. Otvorie nam se stranica dobrodolice na CA serveru, gde moemo izabrati izmeu ostalog Request a certificate.

slika 2.4

Zahtevaemo sertifikat, a kasnije emo izabrati napredne opcije, to e nas dovesti do seldeeg prozora.

22

slika 2.5 Nas interesuje zahtev za novim sertifikatom. Moete primetiti da je mogue traiti i sertifikat koji e biti pohranjen na smart karticu.

23

slika 2.6

Nakon izabiranja odgovarajuih opcija, podneemo zahtev. Nakon podnoenja zahteva, ukoliko sertifikat bude odobren, ostaje nam samo da ga instaliramo klikom na link. Templejti za sertifikate nam obezbeuju jednostavnost vezanu za upravljanje sertifikatima u naem okruenju. Kao to smo videli, potrebno je duplirati jedan od unapred definisanih Microsoft-ovih templejta. Nakon dupliranja, mogue ga je uiniti dostupnim, tanije na osnovu njega je mogue izdavati nove sertifikate. Nakon toga je mogue zahtevati sertifikat na razliite naine. Mogue je zahtevati sertifikat automatski (to ine brojne aplikacije), preko web-a, preko CMM-a...

24

POVLAENJE SERTIFIKATA to se tie povlaenja sertifikata, sva podeavanja se izvode u Certification Authority-u. Mogue je videti kada su sertifikati povueni, definisati gde e sve biti smetena CRL, i na koji nain je mogue pristupiti toj listi. Da li e to biti pomou LDAP-a, HTTP-a ili FTP-a. Takoe je mogue definisati na koji nain e biti autirana CRL lista.

slika 2.7 Ukratko sam demonstrirao instalaciju CA kao i deo administratorskog posla vezan za PKI. Ono na ta bi takoe trebalo obratiti panju jeste bekap kljueva, kao i bekap samog CA. Nikada ne znate kada e operativni sistem otkazati, ili moda sistemski hard disk na serveru koji nema ni jedan vid redundanse. Postoji mnogo naina da ostanete bez kljueva, a ukoliko nemate bekap, moete se nai u velikim problemima!

INFRASTRUKTURA

25

Koa to smo videli u radu, implementacija CA i izdavanje sertifikata je prilino jednostavan proces. Meutim PKI u celosti nije toliko jednostavna tehnologija. Na samom kraju rada malo u razmotriti slovo I (Infrstructure). esto se u predavanjima i polemikama o PKI govori samo o tehnolokim komponentama (korienje kriptografije sa javnim kljuem i prateim mehanizmima za omoguavanje digitalnog potpisa, jaka autentifikacija, integritet podataka, neporecivosti, poverljivosti). PKI zahteva infrastrukturu a ona je mnogo vie od kriptografije i protokola. Ona obuhvata politike koje definiu korienje PKI, kontrole upravljanja rizikom i biznis procese. POLITIKE I TEHNOLOGIJA Trenutno ne postoji jedinstveni PKI model. Umesto toga postoji veliki broj nezavisnih arhitektura sa razliitim stepenom koegzistencije i interoperabilnosti. Razliita vladina, industriska i standardizaciona tela ulau napore da standardizuju jedan globalni PKI model. Meutim, mnogo je vea verovatnoa da e rezultat tog truda biti vie razliitih PKI modela sa poveanom koegzistencijom i interoperabilnosti. Postoje predvianja da e u narednih nekoliko godina nastati globalni root CA. Moje lino miljenje je da do toga nee doi, i to iz politikih razloga. Ustanovljeno je da je vlasnitvo nad root domenom donelo veu politiku mo dravi u kojoj se on nalazi. Pretpostavka je da se vie niti jedan put nee ponoviti tehnologija koja e imati svoj root u nekoj dravi. I jedini razlog zbog postojanja jedne takve tehnologije (DNS) jeste taj to ininjeri koji su vremenom doli do tog rezultata nisu imali nikakve politike interese. Poto niko nije bio svestan moi posedovanja root-a, jedan takav root je i napravljen. Iako tehnologija igra veliku ulogu u PKI, PKI je zasnovana na politikama, pre svega. Po istraivanjima (firme METASeS) 75% sredstava koja se uloe u PKI ode na razvoj politika. Pisanje jedne takve politke zahteva rad menadera, IT profesionalaca, pravnika..., koji e definisati za ta su namenjeni sertifikati, ko ih moe dobiti i pod kojim uslovima, koliko esto se aurira CRL i tome slino. Implementacija i planiranje politika je od vitalnog znaaja za postizanje funkcionalnih potreba preduzea. Koliko je potrebno ozbiljno pristupiti projektovanju jedne PKI politike govori i podatak da je Kanadska vlada uloila 1.5 ovek-godina u razvoj njihove politike. Ustanovili smo da je za razvoj i odravanje politika potrebno znanje eksperata iz razliitih oblasti. Grupa koju oformljavaju ti eksperi se naziva Policy Management Authority (PMA). U nekim sluavjevima PMA je podeljen u dve grupe: Policy Approval Authority (PAA) i Policy Creation Authority (PCA). PAA je zaduen za razvoj politika koje upravljaju sa PKI, dok PCA ima zadatak ugradnje politika u PKI kroz implementaciju jednog ili vie CA. U sutini podela definie ko donosi odluke, a ko je zaduen za interakciju sa samom tehnologijom. Postoje dve osnovne politike vezane za PKI, a to su Certificate Policy (CP) i Certification Practice Statemant (CPS). CP je lako i javno dostupan dokument koji objanjava sa operativne take gledita ta se deava i koja su tehnika i poslovna reenja vaeg PKI. CSP je unutranji dokument koji detaljno opisuje funkcije PKI. Tanije CP je dokument koji definie ta vae PKI okruenje radi, dok CPS definie kako je to izvedeno. Kao primer CP moe definisti da je sitem potrebno bekapovati dva puta dnevno, dok CPS moe precizirati da se to radi u 6h i 18h (procedure bi definisale kako se to radi, korak po korak). Poto je CP javni dokument, poslovni partneri bi se mogli uveriti da se bekapovanje odvija dva puta dnevno, to moda zadovoljava njihove zahteve.Znajui da je CPS interni dokument, vreme kada se to radi bi ostala tajna.

26

Kod odreenih autora sam imao priliku proitati da je CPS takoe javno dostupan dokument. Lino mislim da to nije toliko sjajna idea i da bi to mogao biti izvor pretnje. Prvi od pet koraka hakerskog napada se zove Reconnaissance u prevodu izvianje. U ovoj fazi napada, napada vri prikupljanje informacija o meti. Obilazi odreene sajtove koji daju informacije o osobama koje su zakupile domen. Trai informacije koje bi mogao upotrebiti pri Social Engineering-u (nain prikupljanje informacija lanim predstavljanjem preko telefona, glumom, laganjem...). ita oglase za zapoljavanje sa sajta firme, to napadau moe dati veoma dobru sliku o tehnologijama koje firma koristi, potreban Java programer, MCSA sertifikovani administrator, CISCO... sasvim dovoljno govori napadau o potencialnim slabostima firme. Takoe je mogue preko odreenih servisa i servera doi do informacie kada ste poslednji put restartovali odreeni server, to moe u nekim situacijama znaiti da ste, ili niste skinuli i instalirali poslednju sigurnosnu zakrpu. Ukoliko to niste uradili, imate ranjivosti kojih niste ni svesni. Ni jedna mrena barijera, IDS... vam nee u tom sluaju pomoi. Napada bi takoe mogao iskoristiti i CPS za dolazak do jo, njemu vanih informacija, te iz tog razloga mislim da bi CPS trebao ostati tajni dokument. Nije redak sluaj da politika zatite neke firme detaljo objanjava, korak po korak ta i kako se radi u firmi (procedure napisane u politici zastite, to je nedopustivo). To je kao da ste napadau ostavili detaljan plan i putokaz do vaih dobara koje pokuavate sa mnotvo mrenih barijera..., zatititi.

Takoe postoji jo jedan dokument koji treba spomenuti, a to je Subscriber Agreement.

Tipino ovaj dokument je dostupan na sajtu firme koja obezbeuje PKI uslugu. Ovaj dokument slue kao pravna osnova za saradnju. U njemu su definisane obaveze korisnika kao i odgovornosti onoga ko prua usluge

Zakljuak

27

Kao to smo videli instalacija MS CA je veoma jednostavna, postupak koji je mogue zavriti za desetak minuta. A zatim nam preostaje izdavanje sertifikata... Meutim da bi sve to bilo tako jednostavno, potrebno je uloiti mnogo vremena, truda i novca u projektovanje same PKI i dokumentacije na osnovu koje e PKI biti inplementirana. Ono to je est propust, ne samo pri implementaciji PKI, nego u projektovanju uopte, jeste nedostatak planiranja i detaljnog shvatanja namene i potreba sistema.

Literatura:

1. Managing and Maintaining Windows Server 2003 Environment MCSE Exam 70-290.pdf

28

2. Windows 2003 Security Design MCSA MCSE Exam 70-298.pdf 3. Windows 2003 Security Implementation MCSA MCSE Exam 70-299.pdf 4. Windows Server 2003 Security Guide.pdf 5. Ethical Hacking Student Guide.pdf 6. Penetration Testing.pdf 7. PKI Policy White Paper: March 2001- PKI Forum 8. Network Computing extended article: In PKI We Trust 9. http://www.metases.com