PKI for Dummies :)

PKI yleisesti

Aika usein kysytään, että mitä se PKI oikein tarkoittaa ja mitä sillä tehdään, joten avataanpa salaisuuksien arkkua ja yritetään purkaa taas yksi kolmikirjaiminen akronyymi ymmärrettävämpään muotoon.

Aloitetaan siis itse lyhenteestä PKI eli Public Key Infrastructure, joka tarkoittaa siis palvelimia ja palveluita joiden avulla hallitaan sertifikaatteja. Kokonaisuuden kannalta joudumme ymmärrettävyyden vuoksi aloittamaan vähän kauempaa eli sertifikaateista.

 

Sertifikaatit

PKI-ympäristö siis tarvitaan sertifikaattien hallintaan, mutta mitä ne sertifikaatit oikein ovat? Kaikki olemme näihin veijareihin tavalla tai toisella joskus törmänneet. Jos ei muuten niin verkkopankkia käytettäessä. Monesti ajatellaan että itse sertifikaatti takaa yhteyden turvallisuuden. Näin asia ei kuitenkaan ole.

pki-ymparistoSertifikaatti itsessään ei lisää tietoturvaa lainkaan. Sertifikaatti on vain standardimuotoinen tiedostorakenne, jonka tarkoituksena on tallentaa sertifikaatin tietoja. Kuka tahansa voi luoda sertifikaatteja, jonka vuoksi sertifikaatti itsessään ei lisää tietoturvaa. Tiedot joita sertifikaattiin on tallennettu, niiden varmistamisen mahdollisuus ja sertfikaatti tekevät vasta kokonaisuudesta sellaisen joka lisää tietoturvaa.

 

Tärkeimpiä sertifikaatin sisältämiä ja vaadittuja tietoja:

  • Sertifikaatin myöntäjä
  • Allekirjoitus
  • Julkinen avain
  • Kenelle sertifikaatti on myönnetty
  • Kauanko sertifikaatti on voimassa
  • Tieto mistä voidaan tarkastaa, onko sertifikaatti ennenaikaisesti poistettu käytöstä

Jos katsoo tuota listaa, ja miettii jotain muuta missä on tallennettuna saman tyyppisiä tietoja, tulee mieleen ainakin allekirjoittaneelle passi. Tämä on ehkä paras vertaus, kun kaikki kuitenkin tietävät miten passi toimii: miten sen saa, mitä tietoja passi sisältää ja miten passia käytetään. Palataan tähän, kun käydään läpi sertifikaatin tiedot hieman tarkemmin.

 

Sertifikaatin myöntäjä

Tämä tieto kertoo mitä ylemmäntason sertifikaattia on käytetty, kun sertifikaatti on myönnetty. Mikäli myöntäjä on sama kuin se, kenelle se on myönnetty, puhutaan silloin juurisertifikaateista. Sertifikaatin käytettävyyden kannalta tämä tieto on erittäin tärkeä. Ennen kaikkea se että luottaako ympäristö, missä sertifikaattia tullaan käyttämään, sertifikaatin myöntäjään. Kyse on siis luottamuksesta – luotanko minä tai työasemani sertifikaattiin, jonka on myöntänyt jokin organisaatio.

Sertifikaatteja myöntävistä palvelimista voidaan rakentaa hierarkia jossa ylimpänä on juuritason palvelin ja sen alla yksi tai useampia sertifikaatteja myöntäviä palvelimia. Juuritason sertifikaatteja on kahta eri tyyppiä: julkisia ja sisäisiä. Julkisiin juuritason sertifikaatteihin pitää luottaa, jotta niiden myöntämiin sertifikaatteihin voidaan luottaa.

Käyttöjärjestelmien, selainten, tietoturvapäivitysten yms. mukana tulee koneelle tietoa julkisista luotetuista juuritason sertifikaateista. Näistä käytetään termiä ”Trusted Root Certification Authorities”. Esimerkki tällaisesta juuritason sertifikaatista on vaikkapa VeriSign:n palvelimen sertifikaatti.

Julkisen juurisertifikaatin avulla myönnettyjä sertifikaatteja pitää ostaa juurisertifikaatin omistajalta. Syy miksi näistä pitää maksaa, liittyy siihen, että näiden toimijoiden on varmistettava, että sertifikaatin ostaja on oikeasti se kuka kertoo olevansa ja/tai edustaa kertomaansa organisaatiota. Se kuinka laadukkaasti varmistus tehdään, kulkee yleensä käsi kädessä sertifikaatin hinnan kanssa.

Sertifikaatteja joita ostetaan julkisilta sertifikaattien myöntäjiltä (tahot jotka omistavat näitä yleisesti luotettuja julkisia juurisertifikaatteja), sanotaan yleensä julkisiksi sertifikaateiksi. Näitä käytetään paikoissa, joissa emme pysty vaikuttamaan käyttäjän tai työaseman luottamiin myöntäjiin. Yleisin esimerkki tällaisesta sertifikaatista on varmasti Internet sivustojen suojaamiseen käytetty sertifikaatti, vaikkapa siis se verkkopankin ostama ja käyttämä sertifikaatti.

Koska julkisten sertifikaattien hankkiminen isolle määrälle käyttäjiä tai koneita on kallista, hidasta ja manuaalista toimintaa, käytetään organisaation sisäisissä toiminnoissa sisäisiä sertifikaatteja. Tällöin organisaatio asentaa omaan ympäristöönsä PKI-palvelut ja alkaa jakaa sieltä sertifikaatteja käyttäjilleen ja koneilleen.

Ongelma sisäisissä sertifikaateissa on se, että niihin ei luota kukaan muu kuin kyseinen organisaatio. Jos tällaisia sertifikaatteja käytettäisiin esim. organisaation julkisen www-sivuston suojaamiseen, saisivat kaikki organisaation ulkopuoliset käyttäjät virheilmoituksia ei-luotetun sertifikaatin käytöstä.

Kun summataan asioita yhteen, tärkeintä on, luotetaanko sertifikaatin myöntäjään. Julkiset sertifikaatit ovat helpompia, koska käyttöjärjestelmät, selaimet jne. sisältävät jo tiedon näistä myöntäjistä, ja luottavat automaattisesti näiden myöntämiin sertifikaatteihin. Sisäiset toimivat organisaation sisällä, mutta eivät taas ulkopuolelle. Luottamusta eri myöntäjiin voidaan hallita Active Directory GPO:den, scriptien jne. avulla, mutta nämäkin toimivat vain organisaation sisällä.

Jos palataan aiemmin mainittuun analogiaan passista, niin passiin on aina merkitty sen myöntäneen organisaation nimi. Kun minulla on EU-passi, jonka on myöntänyt Jyväskylän poliisiviranomainen, on hyvin todennäköistä, että passintarkastaja luottaa siihen, että Jyväskylän poliisi on tarkastanut henkilöllisyyteni EU:n säännöstöjen mukaan. Jos taas teen itselleni passin, ei passintarkastaja todennäköisesti luota itse tekemääni passiin samalla tavalla, vaikka muut tiedot molemmissa ”passeissa” olisivatkin identtiset. Luottamus on sertifikaateissa kaiken A ja O. Jos sitä ei ole niin sertifikaatti on oletuksena käyttökelvoton.

 

Allekirjoitus

Jotta voidaan varmistua, että sertifikaatin on oikeasti myöntänyt palvelin joka on mainittu sertifikaatin tiedoissa, luodaan sertifikaattiin allekirjoitus palvelimen sertifikaattia vastaavalla salaisella avaimella. Salaisen avaimen tietää vain palvelin, ja jos joku muu sen saa tietoonsa on kyseisen sertifikaatin ja kaikkien sen avulla myönnettyjen sertifikaattien tietoturva menetetty.

Salaista avainta ei siis koskaan tallenneta itse sertifikaattiin, vaan sitä pyritään pitämään mahdollisimman turvallisessa paikassa. Tämän takia toimikortteja käytetään joissain ympäristöissä, koska sinne voidaan tallentaa salainen avain ja sitä voi käyttää vain jos saa kortin käsiinsä ja vieläpä tietää kortin PIN-koodin.

Ja takaisin allekirjoitukseen: Koska sertifikaatissa on palvelimen salaisella avaimella tehty allekirjoitus kaikista sertifikaatin tiedoista, voidaan palvelimen julkisen avaimen avulla tarkastaa, onko tietoja muutettu, ja onko sertifikaatti oikeasti luotu ko. palvelimessa. No mistä tuo palvelimen julkinen avain sitten löytyy? Se kerrotaan sertifikaatin tiedoissa, eli siellä on mainittuna osoite mistä saadaan noudettua palvelimen sertifikaatti ja sen sisältä julkinen avain. Tätä yleensä ei edes tarvitse tehdä, koska luotettujen sertifikaattimyöntäjien sertifikaatit jo löytyvät koneelta, eli sieltä yleisimmin se julkinen avain löytyy.

 

Julkinen avain

Allekirjoitus-kohdassa jo tätä hieman avattiin, joten keskitytään tässä salaisen ja julkisen avaimen väliseen suhteeseen. Nämä avaimet ovat pareja, eli jokaisella sertifikaatilla (, jossa siis tallennettuna vain julkinen avain), on olemassa jossain salainen avain. Kenellä se salainen avain sitten on?

Se on – tai ainakin pitäisi olla – vain sillä käyttäjällä, koneella tai palvelulla, jolle sertifikaatti on myönnetty. Julkisen avaimen perusteella ei koskaan voida saada selville suoraan salaista avainta, mutta avaimen pituus vaikuttaa siihen, kuinka nopeasti sen saa murrettua. Avaimen pituus kerrotaan bitteinä ja yleisin avaimen pituus on nykyään kilo eli 1024 bittiä. Sitä heikompia, eli lyhyempiä, avaimia ei kannatta käyttää, koska nykyiset superkoneet pystyvät ratkaisemaan ne ns. brute force -menetelmällä alle vuodessa.

Vaikka siis julkisen avaimen avulla ei saa tietää salaista avainta, on tämän avainparin välillä suhde, joka mahdollistaa sen, että salaisella avaimella allekirjoitetun datan voi varmistaa julkisella avaimella. Allekirjoitus ei salaa mitään, se vain takaa sen, että tieto ei ole muuttunut, ja myöntäjä on varmasti se joka kerrotaan sertifikaatissa. Jos taas halutaan salata tietoa, niin salaus tehdään julkisella avaimella, ja salauksen purkaminen onnistuu vain kyseisen avainparin salaisella avaimella. Yleensä tosin varsinainen salaus tehdään symmetrisellä avaimella, joka salataan sertifikaatin avainparin avulla, mutta tähän meidän ei tällä kertaa tarvitse syventyä =).

Julkinen avain nimensäkin mukaisesti on sellainen, jota saa ja kannattaa levittää julkisesti. Sitä vastaava salainen avain on se, mitä meidän pitää suojella. Passivertauksessa sertifikaatin allekirjoitus ei vastaa passin omistajan allekirjoitusta, se vastaa myöntäjän tunnistamiseen käytettyä tietoa kuten hologrammia tai vastaavaa. Siis jotain tietoa millä voidaan varmistaa että passin on myöntänyt ja tehnyt passissa mainittu viranomainen.

 

Muut tiedot sertifikaatissa

Tieto kenelle sertifikaatti on myönnetty, on aika yksiselitteinen. Sertifikaatti voi olla myönnetty käyttäjälle, koneelle, palvelulle tms.. Tämä tieto kuitenkin kertoo sen, keneltä löytyy vastaava salainen avain. Kuten passissa, on myös sertifikaatissa voimassaoloaika.

Tällä rajoitetaan sitä kuinka kauan ko. sertifikaattia voidaan käyttää, ennen kuin se on uusittava. Mikäli sertifikaatti pitää poistaa käytöstä ennen sen voimassaoloajan päättymistä, puhutaan sertifikaatin revokoinnista. Tämä käytännössä tarkoittaa sitä, että sertifikaatin myöntäneellä palvelimella lisätään sertifikaatti revokaatiolistalle (CRL eli Certificate Revocation List).

Mitä hyötyä siitä on, että serverin revokaatiolistalle lisätään jokin sertifikaatti? Sertifikaateissa on myös tieto siitä mistä löytyy palvelimen revokaatiolista. Se voi olla AD:ssa, tiedostopalvelimella tai HTTP-palvelimella. Tärkeintä tässä jälleen on se, että käyttäjillä ja koneilla on aina tarvittaessa pääsy johonkin revokaatiolistaan, mikä on sertifikaatissa listattu. Mikäli pääsyä ei ole yhteenkään revokaatiolistaan, ei pystytä tarkastamaan, onko kyseinen sertifikaatti enää validi. Tällöin yleensä sertifikaattia ei voida käyttää, koska ei voida olla täysin varmoja siitä, onko sertifikaatti enää validi.

Tästä syystä julkisissa sertifikaateissa pitää myöntäneen palvelimen julkaista revokaatiolista myös Internettiin. Sama pitää toteutua, jos sisäisiä sertifikaatteja käytetään siten, että tarkastus pitää pystyä tekemään ilman yhteyttä organisaation sisäverkkoon. Esimerkki tällaisesta voisi olla vaikkapa sertifikaatein suojattu VPN-yhteys.

Passivertauksessa revokaatiolista voisi olla viranomaisen ylläpitämä lista passeista, jotka ovat ilmoitettu varastetuiksi tai hävinneiksi. Samat syyt ovat usein myös syynä siihen, miksi sertifikaatti päätyy revokaatiolistalle.

 

Takaisin PKI:hin

Nyt ymmärretään ehkä paremmin, mitä sertifikaatit ovat, joten voimme nyt lähteä katsastamaan mitä PKI-ympäristöön kuuluu. Jotta sertifikaatteja voidaan myöntää hallitusti, pitää meillä olla palvelin tai mielellään palvelimia jotka pystyvät luomaan ja hallitsemaan sertifikaatteja.

Sertifikaattien hallinta tarvitsee useita eri palveluita ja tärkeimmät onkin edellä jo vähintään terminä mainittu. Tärkeimmät palvelut ovat sertifikaattien myöntäminen ja revokaatiolistan hallinta.

PKI-ympäristö siis koostuu yhdestä tai useammasta sertifikaatteja hallitsevasta palvelimista, joita kutsutaan CA eli Certification Authority -palvelimiksi. Se kuinka monta CA-palvelinta kussakin PKI-ympäristössä tarvitaan, riippuu aina sen organisaation koosta, mihin sertifikaatteja käytetään, ja toisaalta siitä kuinka korkea tietoturvataso halutaan saavuttaa.

Nyrkkisääntönä on, että CA-palvelimia tulisi olla vähintään kaksi: Yksi juuritason CA-palvelin ja yksi sertifikaatteja jakava CA-palvelin. Windows-maailmassa juuritason CA-palvelin rakennetaan ns. ”Offline Root CA -palvelimeksi”. Tämä tarkoittaa, että palvelinta ei liitetä Active Directory -palveluun ja palvelin pidetään oletuksena virrattomana tai irti verkosta. Tämä tehdään sen takia, että juuritason sertifikaatti ja sen salainen avain ovat kaikkein kriittisimpiä komponentteja PKI-infrassa.

Siksi halutaan minimoida sen joutuminen vääriin käsiin. Jos näin kuitenkin käy, niin koko PKI-ympäristön tietoturva on ainakin teoriassa menetetty ja joudutaan rakentamaan kokonaan uusi ympäristö. Puhumattakaan siitä, että joudutaan jakamaan uudestaan sertifikaatit.

Offline Root CA -palvelimen ainut tehtävä on luoda sertifikaatteja alemman tason CA-palvelimille, joista käytetään nimitystä Subordinate CA. Toki revokaatiolista pitää tietyin väliajoin uudistaa, mutta muutoin palvelin voi olla hyvin virrattomana ja se on myös tarkoituksenmukaista.

Subordinate CA -palvelimen tehtävä on sitten jakaa sertifikaatteja, ja tästä syystä se halutaan kytkeä Active Directory -palveluun mikäli mahdollista. AD tarjoaa huomattavia helpotuksia revokaatiolistan julkaisuun, sertifikaattien automaattiseen jakeluun, luotettujen myöntäjien hallintaan jne.. Siksi AD on tärkeä komponentti ja Windows 2008 -serveristä alkaen PKI-palveluiden nimi onkin ollut Active Directory Certification Services (ADCS). Mikäli sertifikaatteja halutaan jakaa automaattisesti, pitää subordinate CA -palvelinten olla varustettu Enterprise-tasoisella käyttöjärjestelmällä.

 

Yhteenvedon paikka

PKI siis muodostuu CA-palvelimista, jotka hoitavat sertifikaattien hallintaa, mutta se ei missään nimessä pelkästään riitä. PKI tarjoaa vain alustan, jolla sertifikaatteja voidaan hallita, mutta suurin haaste on prosessien haltuunotto joita tarvitaan PKI-ympäristön pyörittämiseen. Esimerkiksi sertifikaattien uusiminen ja revokaatiolistojen julkaisu pitää tehdä tietyn syklin mukaisesti, jos sen unohtaa niin pahimmassa tapauksessa joutuu jakamaan sertifikaatit uudelleen. Hankalampi osuus prosessissa on poikkeusten hallinta ja mitä pitää tehdä, kun revokoidaan tietyn tyyppinen sertifikaatti, miten saadaan julkaistua nopeasti uusi versio revokaatiolistasta ja moni muu PKI-ympäristön hallintaan liittyvä asia.

Loppujen lopuksi voi todeta että PKI on yksinkertainen, mutta laaja alue, joka tulevaisuudessa koskettaa yhä useampaa organisaatiota. Siksi siihen kannattaa panostaa ja tehdä pohjatyöt huolella, jotta säästyy raskailta uudelleen konfiguroinneilta. Ja se on varmaa että PKI:n käyttö tulee yleistymään ja sertifikaatteja käytetään yhä enempi tietoturvan parantamiseen.

Usein ensimmäinen tarve sertifikaateille on langattomien verkkojen autentikointi, mutta usein tarpeet lisääntyvät, kun järjestelmät yhä enemmän vaativat sertifikaatteja kuten esim. Microsoft Exchange, Lync, SCCM, etäyhteydet jne..

PKI-ympäristön rakentaminen ei ole hankalaa, kun tietää mitä tekee. Mistä sitten tietää miten PKI pitää toteuttaa? Luetaan PKI käyttöönottosuunnitelmasta miten ympäristö halutaan rakentaa ja opetellaan CA-palveluiden asennus ja konfigurointi. Sitten opiskellaan, miten prosessia pitää pyörittää ja mitä tehtäviä siihen kuuluu. No vielä pitäisi troubleshoot-asioitakin käydä läpi ja etsiä vastauksia Googlen syövereistä.

Tämäkin blogi on pintaraapaisu PKI:sta ja siihen liittyvistä asioista, mutta jätetään tulevaisuuden blogeihin sitten noita muita asioita.

Vaikka PKI onkin suhteellisen yksinkertainen asia, se on hyvin laaja kokonaisuus, jonka omaksuminen vaatii paljon kokemusta, aiheeseen tutustumista, opiskelua, googlea jne.. Alusta asti ei siis omatoimisesti välttämättä kannata lähteä toteuttamaan PKI-ympäristöjä, jos ei sitten välttämättä halua uhrata omaa aikaa ja resursseja PKI:n salojen opiskeluun.

Centerolla on tähänkin tarjota tuotteistettu käyttöönotto, jossa syntyy suunnitelma, asennusdokumentaatio, PKI-ympäristö sekä prosessit viidessä työpäivässä, mikäli kyseessä ei sitten ole todella massiivinen PKI-ympäristö. Unohtamatta meidän kykyä auttaa PKI-ongelmissa myös käyttöönoton jälkeen!

Lue Centero PKI-käyttöönottopalvelun palvelukuvaus: Centero PKI-kayttöönotto.

Kysy lisää!

Laske säästösi

Automatisoi sovelluspäivitykset ja lopeta pikkusoftien kanssa painiminen. Centero Software Manager säästää aikaa, rahaa ja hermojasi.

« Edellinen artikkeli: Kirotut Admin-oikeudet
» Seuraava artikkeli: Pääsynhallintaa ryhmillä ja sen automatisointi