Pilven avaimet omaan haltuun

Julkisten pilvipalveluiden (esim. AWS, Azure, GCP) käyttö on voimakkaasti yleistynyt ja yhä useammin yritykset siirtyvät omassa konesalissaan pyörivien palveluiden sijaan käyttämään joko täysin tai osittain näitä pilvipalveluita. Pilvisiirtymässä on hyvä huomioida tiedon suojaamiseen liittyvät kysymykset niin tietosuojan, huoltovarmuuden, lainsäädännön ja vaatimustenmukaisuuden näkökulmasta. Tiedon salaaminen tarjoaa kontrollimekanismin näihin haasteisiin, mutta salausavainten hallinta on syytä suunnitella huolellisesti heti alusta alkaen.

Pilven avaintenhallintapalvelut (KMS)

Julkiset pilvipalvelut tarjoavat avaintenhallintaan oman ratkaisunsa, joka mahdollistaa sitä käyttävien sovellusten avaintenhallinnan jo varsin hyvällä tasolla. Käyttämällä pilvipalvelun omaa KMS:ää (Key Management Service) saadaan pääsyoikeudet, audit-lokitus ja avainmateriaalin säilytys toteutettua yhdenmukaisesti näiden sovellusten osalta. Avainmateriaalin säilytykseen on tarjolla myös yksinkertaista ohjelmistopohjaista salausta tukevampia ratkaisuja, esimerkiksi Azuren Managed HSM -palvelu, joka tarjoaa jo FIPS 140-2 Level 3 tasolle ulottuvaa suojausta.

Onko sitten riittävää luottaa pilven avaintenhallintaratkaisuihin henkilötiedon tai yrityksen kriittisen liiketoimintatiedon suojauksessa? Lähtökohtana on, että vastuu pilvipalveluun vietävistä tiedoista on aina asiakkaalla. Henkilötietojen osalta on huomioitava asiaan liittyvä lainsäädäntö, esimerkiksi GDPR. Lainsäädäntö, muun muassa henkilötietojen käsittelyyn pilvipalveluissa, on myös ollut muutosten kohteena, ja on vaikea tietää, mitä tasoa jatkossa tullaan pitämään riittävänä – todennäköisestä on, että muutoksia jatkossakin tulee. Kestävämmän ratkaisun tähän ongelmaan saa ottamalla avaimet omaan haltuun, eivätkä kriittisen tiedon perässä olevat krakkerit muutenkaan lakikirjaan pysähdy.

Edellä mainittujen pilven omien avaintenhallintapalveluiden keskeinen ongelma on, että niissä data sekä sen suojaukseen käytettävät avaimet sijaitsevat samassa pilviympäristössä. Mikäli käytetään pilvipalveluiden laitteistosalattuja ratkaisuja (HSM) ei avaimia ole välttämättä helppoa saada niistä ulos. Tämä voi aiheuttaa ongelmia esimerkiksi tilanteessa, jossa pilvialustaa on syystä tai toisesta tarkoitus vaihtaa toiseen tai kotiuttaa palvelut vaikkapa omaan konesaliin, mikä esimerkiksi finanssialalla on erityisesti huomioitava huoltovarmuuden näkökulmasta.

Ulkoisen avaintenhallintapalvelun tuomat mahdollisuudet

Pilvipalveluiden ulkopuolinen avaintenhallinta on vaihtoehto, jolla pilvipalveluihin vietävä tieto saadaan paremmin omaan kontrolliin. Periaatteena on, että suojattava tieto ja suojaukseen käytettävät avaimet erotetaan toisistaan riippumattomiin, erillisiin palveluihin. Tällainen ulkoinen avaintenhallintapalvelu mahdollistaa myös helpomman siirtymän pilvialustojen ja oman konesalin palvelujen välillä, jos avaintenhallinta on toteutettu yhtenäisellä alustariippumattomalla tavalla.

Bring Your Own Key (BYOK) on malli, jossa pilven avaintenhallintapalveluun tuodaan ulkoisessa palvelussa luotu oma avain. Tällöin avaimen luontiprosessi saadaan eriytettyä pilvipalvelusta, ja avaimesta saadaan myös varmuuskopio ulkoiseen palveluun mahdollistaen ongelmista toipumisen ja helpomman alustan vaihdon, tuoden tätä kautta kontrollia avaintenhallintaan, vaikka paljolti joudutaan edelleen luottamaan pilvipalvelun avaintenhallintaan (KMS). Etuna on, että pilvinatiivit sovellukset eivät vaadi muutoksia, vaan voivat käyttää BYOK-avainta aivan kuten pilven KMS:ssä luotua avainta, ja BYOK-avaimen käyttöönotto on yksinkertaista. BYOK-malli on tuettu mm. AWS, Azure ja Google -pilvipalveluissa.

Hold Your Own Key (HYOK) tuo lisää kontrollia avainten käyttöön. Tässä mallissa avain sijaitsee aidosti vain ulkoisessa avaintenhallintapalvelussa, ja avaimen käyttö vaatii yhteyden ulkoiseen pilvipalveluun. Tässä mallissa avaimet ja suojattava tieto on siis kokonaan erotettu toisistaan. Etuna on myös, että ulkoista pilvipalvelua voidaan käyttää avaimen käytön lokitukseen ja pääsyoikeuksien hallintaan. HYOK-toteutuksessa on huomioitava, että sovellukset vaativat luotettavan yhteyden ja ulkoisen palvelun aiheuttama latenssi saattaa vaikuttaa sovelluksen toimintaan, mikäli avaimia käytetään paljon. HYOK-malli on tuettu mm. AWS ja Google -pilvipalveluissa.

Sovelluskohtainen salaus on joustavin ja parhaan kontrollin tarjoava salausvaihtoehto sekä oman konesalin palveluihin että pilvipalveluihin. Tällöin salaus toteutetaan sovellustasolla, esimerkiksi tietokantaa salattaessa käyttäen tietokantamoottorin tarjoamaa salaustoimintoa ulkoisella avaimella tai sovelluksen omalla rajapinnalla. Toteutus ei käytä pilvipalveluiden avaintenhallintaa, joten se ei myöskään ole mitenkään siitä riippuvainen. Avainmateriaali on täysin omassa hallussa, ja ulkoista pilvipalvelua voidaan käyttää avaimen käytön lokitukseen ja pääsyoikeuksien hallintaan. Sovelluskohtaisesti tieto voidaan salata myös osittain esimerkiksi tokenisointia hyödyntäen.

Hyvästäkään salauksesta ei saada lisäarvoa, jos siihen käytettävät avaimet ovat joko hukassa tai liian laajalti saatavissa, tai niiden käyttöä ei voida todentaa. Avaintenhallinnan on siis syytä pystyä vastaamaan näihin tarpeisiin. On myös hyvin mahdollista, että suojaustarpeet ja tekniset mahdollisuudet tarkoittavat sitä, että ei ole yhtä jokakäyttöön parasta mallia. Instan avaintenhallinnan, PKI:n ja tietosuojan asiantuntijat voivat auttaa näiden haasteiden kanssa, joten ota yhteyttä ja etsitään tarpeisiin parhaiten soveltuva ratkaisu.