Kuulostaako tutulta: Työntekijä saa kertakäyttöisen pääsykoodin, jonka naputtelee järjestelmän kirjautumisikkunaan. Tai sitten järjestelmän kehittäjän on päästävä käsiksi tietokannan salasanoihin, ja hänen on otettava käyttöön integraatiossa hyödynnettävä uusi API-avain. Molemmat ovat tekemisissä salaisuuksien kanssa.
Osa järjestelmistä on suojattava niin tarkasti, että salaisuuksien hallintaa pitää kiristää tiukalle tasolle. Tämä artikkeli pureutuu niihin tilanteisiin, joissa tietoturvavaatimukset ovat poikkeuksellisen korkealla.
Yhteenveto: Salaisuuksien hallinta pilvipohjaisissa ohjelmistoratkaisuissa
|
Jokaisessa tietojärjestelmässä on salaisuuksia, ja ne täytyy säilyttää jossakin. Salaisuuksilla tarkoitetaan tässä yhteydessä esimerkiksi salasanoja, varmenteita tai API-avaimia. Erilaisia salaisuuksia yhdistää portinvartijan rooli, eli ne mahdollistavat luvallisen pääsyn dataan tai avaavat kahdelle eri sovellukselle ikkunan toistensa tietoihin.
Yhä useammin liiketoimintakriittiset järjestelmät rakennetaan siten, että käyttäjä voi kirjautua niihin mistä päin maailmaa tahansa. Integraatioiden määrä kasvaa, ja tiedon pitää virrata pilven reunalta toisen pilven reunalle turvallisesti.
Osa korkean tietoturvan järjestelmistä on ns. hybridiratkaisuja, joissa osa järjestelmän toiminnoista ja datan käsittelystä tapahtuu julkipilvessä, osa on-premises -ympäristössä. Tiedon luvallisen virtaamisen lisäksi pitää pystyä estämään tiedon luvaton, julkisuusluokkaan pohjautuva, näkyminen järjestelmien osien välillä.
Julkipilviympäristöissä, jos missä, portinvartijoiden merkitys on suuri, muistuttaa Software Architect Sakari Hassi Cinialta.
“Salaisuuksia ja yleisestikin tietoja hallittaessa täytyy aina lopulta luottaa johonkin instanssiin. Pilvipalveluissa monen organisaation liiketoiminta nojaa AWS:n tai Azuren luotettavaan salaisuuksien hallintaan. Jos niissä olisi teknisiä tai tietoturvaan liittyviä ongelmia, haittavaikutukset pilvipalveluntarjoajille itselleen olisivat massiivisia. Kehitystiimeille onkin tarjolla julkipilvessä kosolti valmiita ratkaisuja, joilla salaisuuksien hallinnan voi viedä osaksi palveluita.”
Valmiit hallintapalvelut pitävät pääsyavaimet ja varmenteet turvassa jatkuvasti ylläpidetyn työkalun sisällä. Valmiit integraatioratkaisut toimittavat salaisuuden hallitusti palvelulta toiselle. Audit-lokituksia ei tarvitse rakentaa alusta asti itse, vaan riittää että ne ottaa käyttöön.
Lue myös: Haasta pilvikumppanisi kysymällä näistä tietoturvan kompastuskivistä
“Jos salaisuuksien hallintaan ei tietoisesti kiinnitetä huomiota, kehitystiimi voi päätyä säilömään salaisuudet osaksi järjestelmän muuta konfiguraatiota”, Hassi varoittaa. Tapa voi tuntua houkuttavalta oikotieltä, mutta jättää tilaa inhimillisille virheille ja unohduksille.
“Järjestelmän versionhallinnassa historia säilyy loputtomiin. Kun salaisuuden sinne kerran laittaa, se ei periaatteessa ikinä poistu.”
Infrastructure as Code -työkalut, kuten Terraform, Pulumi tai AWS CloudFormation, auttavat automatisoimaan ja integroimaan salaisuuksia. Huomio kannattaa kiinnittää state file -tiedostoihin, joihin työkalut saattavat tallentaa käsittelemiään salaisuuksia. Vaikka tiedostot ovat suojattuja, ne ovat silti potentiaalisia välivarastoja salaisuuksille, ja ilman oikeaoppista suojaamista potentiaalinen tietoturvariski.
Organisaation tulee punnita järjestelmän tietoturvavaatimuksia vasten, millä tasolla IaC -työkalut voidaan valjastaa osaksi salaisuuksien hallintaa automaation lisäämiseksi, ja mitä on parempi hoitaa muiden ylläpitomenetelmien kautta.
“Usein salaisuuksien hallinnalla viitataan vain työkaluun tai palveluun, jossa salaisuuksia säilötään ja josta käsin niitä päivitetään tai haetaan”, Hassi sanoo. “Mutta pelkkä työkalu ei vielä ole se kriittisin asia. Eihän mikään palvelu hoida automaattisesti hommaa itsekseen. Salaisuuksien hallinta vaatii siihen rinnalle aina sovitun prosessin.”
Ilman selkeitä toimintaperiaatteita käyttäjä tai järjestelmän kehittäjä saattaa tallentaa salasanan esimerkiksi selaimeen tai työaseman Notepad-sovellukseen. Se voi johtaa vakaviin tietomurtoihin.
“Tietoturvan kerroksia kannattaa toki aina vahvistaa, ja tässä tilanteessa auttaisi kaksivaiheinen tunnistautuminen. Salaisuuksien hallinnan kerros kannattaa kuitenkin ottaa vakavaan tarkasteluun, kun tehdään sovelluksia vaativaan ammattikäyttöön.”
Vaarallinen tapa on siirtää salaisuuksia suojaamattomia kanavia pitkin, kuten chatissa tai sähköpostilla. Epävarmoja “välisäilöjä” tulisi välttää, sillä jokainen paikka, johon salaisuus on tallennettu, on uusi riski. Optimaalisessa tilanteessa salaisuus generoidaan suoraan hallintajärjestelmän toimesta. Jos tämä ei ole mahdollista, tulisi salaisuus pyrkiä siirtämään lopulliseen säilytyspaikkaansa mahdollisimman suoraan generoinnin jälkeen.
Kuten missä tahansa tietoturvan osa-alueessa, myös salaisuuksien hallinnassa järjestelmän kriittisyys määrää tahdin. Mitä tiukemmin suojeltavaa data on, sitä enemmän prosesseihin ja arkkitehtuuriin pitää kiinnittää huomiota, vaikka se vaatisi enemmän rajoituksia päivittäisiin tapoihin toimia.
Hassi vetää periaatteita yhteen ja antaa vielä vielä muutaman neuvon organisaatioille, jotka haluavat vartioida sovellustensa portteja erityisen huolellisesti:
“Yksi hyvä tavoitetila on, että kukaan ei ikinä näe salaisuutta, eli sen luominen, päivittäminen ja jalkauttaminen tapahtuu kaikki salaisuuksienhallintatyökalussa automaattisesti. Ihminen määrittää vain käyttöoikeudet tietyille palveluille. Toinen hyvä periaate on kryptata salaisuudet, jos niitä siirretään järjestelmien välillä. Ja kolmanneksi: ei epävirallisia välisäilöjä salaisuuksille. Kehittäjien omia paikallisia säilöjä tai viestintäkanavien keskusteluketjuja olisi hyvä välttää”, Hassi päättää.
Tunnetko parhaat ratkaisut oman järjestelmäsi salaisuuksienhallintaan? Ota yhteyttä ja kysy lisää!