Asennusvelho ja next nappula Microsoft -varmennehierarkian suunnittelijoina
Microsoft -tuotteissa korostuu jatkuvasti varmennesuunnittelun keskeisyys. Hyviä esimerkkejä teknologioista, joissa olennaista on hallita varmenne-elinikää ja toiminnallisuutta ovat Direct Access ja Right Management Services. Näissä korostuu koko varmennesuunnittelun moninaisuus.
Keskustelin varmennesuunnittelusta tostaina 11.2.2010 Tietoturvatapahtumassa messukeskuksessa, ja huomasin että varmenteiden toiminnallisuus tunnetaan. Mikä on jäänyt merkittävästi vähemmälle keskustelulle, on mitä asioita pitää ottaa huomioon suunniteltaessa varmenteiden käyttöönottoa. Jos yritykselläsi on prosessi varmenteiden julkaisuun ja suunniteltuna sulkulistojen julkaisupaikat varmennekäyttötarkoituksen mukaan, tai varmenteita myöntävät palvelimet ovat luokiteltu myönntettyjen varmenteiden turvallisuusvaatimusten mukaan, olet selvästi paremmassa asemassa kuin suurin osa varmenteita käyttävistä yrityksistä.
Varmenteiden käyttöönotossa lähtökohta on tietoturvan kasvattaminen ja hallitseminen. Tämä asettaa suunnittelulle melkoisen vaateen. Varmenteet tulevat jatkossa muodostamaan merkittävän osan yrityksen tietoturvasta. Asiaa ei siis pidä ottaa kevyesti ja antaa asennusvelhon tehdä valintoja.
Varmennehierarkian toteutus ja suunnittelu on kuuma peruna, joka ei tunnu mukavalta paljaassa kädessä. Ratkaisukin löytyy. Patalapun sijaan suosittelen perusteiden haltuunottoa. Ainakin seuraavat peruskäsitteet tulisi olla näpeissä: varmenteiden käyttötarkoituksen kuvaaminen, hierarkiatasot varmennepalveluissa sekä sulkulistojen julkaisu. Tämän lisäksi on hyvä kuvata esimerkiksi valmiita pohjia hyödyntäen varmenteiden hallinta, ja varmenteiden myöntämisperusteet.
Hyvänä yleiskatsauksena toimii esim:
Designing a Public Key Infrastructure
Hiukan kevyempi kalvo show:
Tell me how PKI works in Plain English
Ja ei muuta kuin varmentamaan







