Hei,

Käesolevas Blogipostituses võtaksin ma luubi alla erinevad teemad, mis puudutavad PKI´d ja selle juurutamist asutuses. Peamiselt tuleb juttu Two-tier lahenduse ülesse ehitusest ning selle lahendusega kaasnevatest headest ja halbadest külgedest. PKI on oma olemuselt niivõrd lai valdkond, et kõigest rääkida ei jõua, kuid võtame kokku mõned põhi komponendid ning seda lühidalt. Loodan, et antud kirjatükist on kasu administraatoritel, kes sisenevad alles PKI maailma ning soovivad antud valdkonnas kodukeeles täiendavalt lugeda.  PKI puhul ei ole kivisse raiutud reegleid, kuidas lahendus disainida, mistõttu leiab igaüks endale parima lahenduse ise. Omalt poolt püüan natukene rääkida võimalikest ohtudest ja eelistest, mis võivad anda mõtteid oma lahenduse väljatöötamisel. Kui kellelgi on omapoolseid täiendusi või ideid, kuidas midagi paremini teha, siis kindlasti kommenteerige. Elav tagasiside on parim, mis ühte blogipostitust saab saata!

Ülevaade sertifikaatidest ja SSL turvalisusest

Püüame võtta paari lausega kokku sertifikaatide vajaduse ja nende olemuse. Lisaks räägime lühidalt ka SSL protokollist.

SSL (Secure Socket Layer) protokoll loodi Netscape poolt aastal 1994 selleks, et tagada turvaline andmevahetus veebiserverite ja veebilehitsejate vahel. SSL´i eksisteerimisel on kaks väga head põhjust: krüpteerimine ning identifitseerimine. Krüpteerimise eesmärk on varjata kahe arvuti vahelises suhtluses vahetatavaid andmeid. Identifitseerimise eesmärk on veenduda, et arvuti, millega sa suhtled on ikka see, mis sa eeldad, et ta on.

Väga lühidalt toimib see siis järgmiselt:

1. Veebilehitseja taotleb turvatud veebilehte ning palub veebiserveril ennast identifitseerida (enamasti https://).
2. Veebiserver edastab oma sertifikaadi, mis sisaldab ka veebiserveri avalikku võtit (Public Key), veebilehitsejale.
3. Veebilehitseja kontrollib, et sertifikaat oleks:
   1. Väljastatud usaldatud CA serveri poolt (Trusted Root CA)
   2. Oleks kehtiv (Valid)
   3. Sertifikaat oleks seotud soovitud turvatud veebilehega (URL)
4. Järgnevalt kasutab veebilehitseja saadetud avalikku võtit, et luua krüpteeritud sessiooni võti ning edastab selle veebiserverile.
5. Veebiserver dekrüpteerib saadetud võtme oma privaatse võtmega ning avab sellepeale turvalise krüpteeritud kanali.

Sertifikaatidest

Sertifikaadid on laias laastus elektroonilised failid, mis sisaldavad endas andmevälju. Selleks, et  sertifikaatidest paremini aru saada on mõistlik tõmmata paralleel tavamaailmaga. Kui vaadata harilikku inimesele või teenusele väljastatud sertifikaati, siis märkame seal sarnasusi arvutites kasutuses olevate sertifikaatidega – elektrooniliste sertifikaatidega. Näiteks on mõlemale sertifikaadile märgitud:

1. Sertifikaadi väljastaja (Issuer). Meie näites „ITFreeTraining“. Siinkohal peaks tekkima küsimus, et kas sa usaldad seda väljastajat? Internetis on mitmeid kohti, kust on võimalik erinevaid sertifikaate raha eest soetada, kuid kas need tagavad usaldatavuse? Kui ülikooli lõputunnistuse on väljastanud näiteks Tartu Ülikool, siis ei teki kahtlust, kas sertifikaati usaldada või mitte – seega TÜ puhul on tegu usaldatud sertifikaadi väljastajaga (arvutis samaväärne Trusted Root CA´dega). Sama kehtib ka arvutites – Kui sertifikaat on väljastatud näiteks Microsofti poolt, siis selle usutavus on üpris tõenäoline. Kui aga sertifikaat on väljastatud suvalise veebiserveri poolt, siis kas ka sellisel juhul on mõistlik usaldada selle väljastajat!?
2. Kellele sertifikaat väljastati (Issued to). Meie näites „John Doe“. Elektrooniline sertifikaat võib olla väljastatud erinevatele asjadele: kasutajale, arvutile, erinevatele seadmetele või näiteks veebilehele.
3. Kehtivuskuupäev (Valid to). Tavamaailmas võivad sertifikaadid olla igavesed (näiteks: ülikooli lõputunnistus) aga võivad olla ka kehtivuskuupäevaga, mis nõuavad kõrvale näiteks täiendavate lisaeksamite sooritamist iga mingi aja tagant. Sama on ka elektrooniliste sertifikaatidega – need kaotavad ette määratud ajal kehtivuse, peale mida sertifikaadi lakkab toimimast ning valideerimine ebaõnnestub.

Elektroonilise sertifikaadi kõhus peitub veel nii mõndagi põnevat, mida tavamaailma sertifikaatides pole. Näiteks avalik võti (Publik Key). Avaliku võtme abil on võimalik andmeid krüpteerida, kuid andmete dekrüpteerimiseks on vajalik privaatne võti (Private Key). Näiteks kui sa kasutad andmete krüpteerimiseks Microsofti sertifikaati ja avalikku võtit, siis andmeid saab dekrüpteerida ainult Microsoft, kes omab kasutatud sertifikaadi privaatset võtit. Samuti on elektroonilises sertifikaadis kirjeldatud veel algoritm, mida krüpteerimiseks kasutatakse, võtme suurus ning palju muud.

Jätame siinkohal sertifikaadid ning vaatame laiemat pilti.

PKI (Public Key Infrastructure)

PKI e. „avaliku võtme infrastruktuur“ võtab kokku erinevad turvaaspektid, mis on seotud sõnumite turvalise ülekandmisega. PKI leiab kasutust e-äri rakendustes, turvalises andmete ülekandmises ja informatsiooni salastatuse tagamisel. PKI on asümmeetriline krüptograafiline süsteem, milles on esindatud järgmised komponendid:

1. Sertifitseerimisasutus (CA) väljastab, tühistab ja haldab sertifikaate. CA võib olla avalik (üldtunnustatud kolmas osapool) või privaatne (ettevõtte sisene sertifitseerimisteenus).
2. Krüpteerimisalgoritm (näiteks RSA) avaliku ja salajase võtmepaari väljastamiseks
3. Digitaalsed sertifikaadid on mehhanismid, mis seovad asümmeetrilise võtmepaari konkreetse isiku/seadmega. Igal kasutajal/seadmel on PKI süsteemis sertifikaat, mida saab kasutada tema identifitseerimiseks. Kõige enam levinud sertifikaadi standard on X.509. See standard spetsifitseerib info, mida sertifikaat sisaldab (versiooni, seerianumbri, algoritmi, väljastava asutuse, kehtivusaja, isiku, kellele sertifikaat väljastati, kasutusotstarbe, võtmed, jne). Sertifikaatide valideerimiseks on kasutusel sertifikaaditühistusnimistu (CRL – Certificate revocation list), mis peab olema kättesaadav kõikidele, kuna sealt kontrollitakse sertifikaatide kehtivust.

Lühidalt öeldes on tegu keskkonnaga, kus kehtivad kindlad reeglid ning kus on esindatud kindlad teenused.

Tüüpilisemad PKI lahendused (PKI topoloogia).

Olenevalt asutuse suurusest, rahakoti suurusest, turvalisuse tähtsusest ning paljudest muudest parameetritest on võimalik juurutada erineva disainiga PKI lahendusi. See kõik tuleks paika panna enne esimese serveri installi. Vaadata läbi oma vajadused ning teenused, mis PKI´d kasutama hakkavad (VPN, 802.1x, veebiserverid, SCCM, Direct Access jne) ja alles siis alustada reaalse tööga. Mõistlik oleks ka plaanitud lahendus laboris läbi mängida, et „live“ keskkonnas tekkivaid probleeme ja küsimusi ennetada. Pea meeles, et PKI võtmes on hiljem muudatusi väga keeruline teostada ning ajas muutub see kõik aina ärikriitilisemaks.

1. Väiksemates asutustes piisab ühest Juur CA serverist (peene nimega „one-tier hierarchy“). Antud lahenduse eeliseks on väiksem litsentsikulu (vähem masinaid), väiksem riistvaraline kulu ning lihtsam seadistamine. Murekohtadeks on aga veakindlus ning turvalisus. Sellest lahendusest ma oma käesolevas blogi sõnavõtus ei räägi.
2. Paljud asutused aga järeleandmisi turvalisuses endale lubada ei saa, seega tuleb mõelda lahendusele, mis on märksa veakindlam ning turvalisem. Vaatame lahendust, mis on täna kõige laialdasemalt kasutuses (variatsioonidega): Two-tier hierarchy. Selles lahenduses on kasutuses kaks CA serverit: Offline Root CA ning Subordinate/Intermediate CA. Omapoolses manuaalis paigaldame me veel ka OCSP serveri, mille pihta primaarselt sertifikaate kontrollitakse, kuid vajadusel võib CRL´id publitseerida ka Subordinate/Intermediate CA serverisse ja/või Active Directory. Tihti soovitakse OCSP ka välja (internetti) paistma panna. Sellega kaasnevatest küsimustest kirjutan lühidalt allpool.

NB! Vaikimisi ma AD´sse CRL´e ei publitseeriks. Põhjus lihtne – Sertifikaatide valideerimist alustatakse sertifikaadis kirjeldatud URL´ide järjekorra algusest. Kui URL ei vasta, siis oodatakse Time out (ca. 15 sek) ning võetakse järgmine kirjeldatud URL. Vaikesättena on LDAP URL sertifikaatides esimene ning see toimib kõikidel domeeni masinatel kenasti. Kui nüüd aga sertifikaati kasutatakse masinatel, mis pole domeenis (Linux, Mac) või kasutada teenustel, mis asuvad väljaspool domeeni (VPN vms), siis nendel klientidel toimub sertifikaadi valideerimine tüütult kaua. Seega oleks mõistlik alati esimeseks CDP ja AIA URL´iks määrata kõikjalt kätte saadav HTTP URL. Seda ka juhul kui kliendid on vaid domeenisisesed kasutajad. See tagab märksa suurema veakindluse toimivas lahenduses.

Allolev pilt kuvab CDP vaikimisi sätted, mis ei ole kõige parem lahendus ning tuleks oma vajadustele vastavalt ära muuta.

Lühidalt saab minu poolt kirjeldatud hierarhia olema alljärgnev (Ma loen ennast Microsoft Visios väga kehvaks, seega kõik kuvapaugul tekkinud vead palun andestada):

Võib-olla tekib osadel küsimus, et huvitav miks Revocation server on domeenis? Iseenesest on küsimus põhjendatud ja oli see küsimus ka minul endal kui ma seda esimesel korral paigaldasin. Peaks teine ju ühte otsapidi õue paistma! Kaine mõistus nagu ei lubaks domeeni masinat otsapidi internetti panna. Seda muidugi juhul kui soovitakse CRL´e väljapoole publitseerida. Kui ei, siis siin probleemi ei ole ning serveri domeenis olekut ei pea põhjendama. CRL´i väljapoole publitseerimisel on põhjus muidu iseenesest lihtne – Revocation server uuendab oma OCSP Response Signing sertifikaati vaikimisi iga kahe nädala tagant. Seda on võimalik muuta, kuid pole soovitatav seda väga pikaks ajada! Isegi kui panna see kuu või kahe peale tuleks juurde väga palju ebamugavat käsitööd. Seda põhjusel, et domeeniväline masin ei saa automaatselt endale enrollida OCSP Response Signing sertifikaati ning sellisel juhul tuleb see taotleda ja paigaldada OCSP serverisse käsitsi või siis kehtivusperiood viia ebamõistlikult pikaks. See aga on väga tüütu lahendus ning piisab sellest kui see ükskord ununeb ja väljastatud sertifikaate ei ole võimalik enam valideerida kuniks viga on parandatud. Minupoolne soovitus siinkohal on paigaldada välisesse otsa Linuxi Proxy ja lubada OCSP serverisse ainult vajalikud päringud (Antud juhul siis ainult HTTP GET päringud), et väljastpoolt ei oleks võimalik tekitada ebasobilikku liiklust antud serveri pihta.

Sellega võtaksin oma tänase postituse kokku ning järgmine kord vaatame lähedamalt juba mida põnevat annab veel teha!