Voiko se oikeasti olla totta
1960 rakennetaan ensimmäiset laskenta-aikaa jakavat sovellukset 1969 Internetin esi-isä, ARPANET, näkee päivänvalon 1990 mainframe teknologia tekee vahvasti tuloaan 1999 Salesforce.com julkaisee ensimmäisen pilvipalvelun 2002 Amazon julkaisee Mechanical Turk palvelun 2006 Amazon julkaisee EC2 pilvipalvelun 2007 Facebook julkaisee yksityishenkilöille tarkoitetun palvelun 2009 Google julkaisee selainpohjaiset palvelut yrityksille 2
Yksityinen pilvi Fyysinen ja looginen ympäristö yrityksen omassa hallinnassa. Helppo mukauttaa yrityksen tietoturvapolitiikkaan. Yrityksen tietovarannot pysyvät yrityksen palomuurin sisäpuolella. Yritys vastaa kaikista kustannuksista itse. 3
Hybridi Yksityinen ja julkinen pilvipalvelu yhdistettynä toisiinsa. Mahdollisuus käyttää yksityistä pilveä kriittisten järjestelmien ajoon sekä arkaluonteisen datan säilyttämiseen ja palveluntarjoajan pilveä vähemmän kriittisten järjestelmien pyörittämiseen kustannusten alentamiseksi. Palveluntarjoajan pilvipalvelun pitää olla linjassa yrityksen tietoturvapolitiikan kanssa. Kustannukset vaihtelevat tietoturva- ja kapasiteettivaatimusten muuttuessa. 4
Julkinen pilvi Sopii yrityksen julkisten palveluiden pyörittämiseen, kunhan ne eivät sisällä yrityksen luottamuksellista tai arkaluonteista tietoa. Taipuu hyvin harvoin yrityksen tietoturvapolitiikkaan. Ei mahdollista hallita tietoturvaominaisuuksia. Kustannukset vaihtelevat käytetyn kapasiteetin mukaan. 5
Arkaluonteinen tieto Yksityinen Luottamuksellinen tieto Yksityinen & Hybridi Julkinen tieto Yksityinen, Hybridi & Julkinen 6
Hallinnan menetys Vastuu ympäristöstä hajallaan (ei vastuuta) Jaetun ympäristön tietoturva Jumittuminen yhteen palveluntarjoajaan Tietoturvavaatimukset ei täyty Juridiset esteet Turvauhkien ja tapahtumien käsittely Käyttöliittymien ja rajapintojen turvallisuus Tiedon suojaaminen, varmistus ja tuhoaminen Palvelun tavoitettavuus 7
Palveluiden taustalla pyörivät ratkaisut ovat ohjelmallisesti toteutettuja, joka nostaa ohjelmallisen virheen riskiä. Virtuaalisointikerroksen virheet Ohjelmistojen tietoturva-aukot Rajapintojen haavoittuvuudet Ohjelmistojen yhteensopivuusongelmat 8
Tiedon hallinta Tiedon sijainti tuli yhä tärkeämmäksi. Tiedon tuhoaminen oli varmistettava pilven sijainnista huolimatta. Tiedon suojaaminen palveluntarjoajan hybridi-pilvessä oli varmistettava. Tiedon varmistamisen oli toimittava pilvestä tai sen sijainnista riippumatta. Tiedon saatavuuden varmistaminen vikatilanteissa pilvimallista riippumatta. 9
Ympäristön hallinta ja vastuut ovat hajaantuneet usean toimitsijan kesken Vastuu fyysisestä kerroksesta voi jakaantua usealle tarjoajalle Vastuu loogisesta kerroksesta voi jakaantua usealle tarjoajalle. Yhden tarjoajan ongelmat voi aiheuttaa isojakin ongelmia koko ketjulle. Yrityksellä usein yksi palvelurajapinta, jonka takana olevia toimitsijoita ei ole aina mahdollista tunnistaa. 10
Tietoturva-ajattelun mukauduttava uusiin haasteisiin Perinteinen tietoturva-ajattelu ei toimi pilvipalveluissa. Lisääntyneet vaatimukset kasvattaneet railoa tietoturvan ja liiketoiminnan välillä. Fyysisen tietoturvan ajattelumalli ei toimi, koska tieto voi olla missä tahansa pilven sisällä. Uusien tietoturvakäytäntöjen kehittely jatkuu edelleen. 11
Vuosina 2014 2016 pilvipalveluiden myynti hiipuu Arvioitu asiakaskato noin 10% - 20% luokkaa Rahallinen menetys noin 35 miljardin luokkaa Peruuttamaton vahinko pilvipalveluiden tarjoajille Amazon, Microsoft, Google ja Yahoo menettävät eurooppalaiset asiakkaansa. 12
Yritykset huomaavat, miten vähän heillä on valtaa omaan tietoonsa Zero-trust malli yleistyy Tiedon salakirjoitus otetaan laajempaan käyttöön Avainhallintaan kiinnitetään enemmän huomiota Alueellisia palveluntarjoajia suositaan Hallituksia painostetaan avoimempaan toimintaan Vain pieni osa yrityksistä siirtää järjestelmiään takaisin oman IT:n alle 13
Microsoft ja Google ilmoittivat salakirjoittavansa kaiken tiedon, mitä heidän pilvipalveluidensa levyille tallennetaan. Muut palveluntarjoajat, kuten Dropbox ja SipderOak, ilmoittivat ottavansa samankaltaisen salauksen käyttöönsä. Jos avainhallinnasta vastaa palveluntarjoaja, joka on velvoitettu luovuttamaan avaimen pyydettäessä ja hallitsee itse salaamaansa tietoa, niin salausta ei voida pitää luotettavana. 14
Arvioi ja suunnittele Mieti, mikä pilvimalli sopii liiketoiminnan tarpeisiin parhaiten. Luokittele olemassa oleva tieto ja määrittele, minne sitä voidaan tallentaa. Arvio mahdollisen tietovuodon vaikutukset yrityksesi toimintaan ja imagoon. Laske pilvipalvelun tuoma säästö vastaan mahdollinen infran hallinnan ja näkyvyyden menettäminen. Määrittele yrityksen minimivaatimukset tietoturvalle. 15
Käy kattava keskustelu ja sovi asiat etukäteen tarjoajan kanssa. Pyydä ympäristöstä kuvaukset ja kysy tarkennuksia, mikäli kuvaukset eivät anna riittävästi vastauksia. Käytä sekä omia, että palveluntarjoajan resursseja suunnitteluun. Kysy mahdollisista alihankkijoista. Käy siirrettävät järjestelmät läpi ja määrittele projektin laajuus. Määrittele vastuut ja velvollisuudet ennen projektin aloittamista. 16
Varmista minimissään Riskien hallinta Tietoturvapolitiikat ja miten ne sopii omaan yritykseesi Valvonta, varmistukset ja palautus. Ongelmatilanteiden hallinta ja niistä toipuminen Jatkuvuussuunnitelma Tiedottaminen ja dokumentointi. 17
Älä liikuta luottamuksellista tai arkaluonteista tietoa salaamattomana. Salakirjoitetaan ennen levylle kirjoittamista. Salaus puretaan vain omissa järjestelmissä. Siirretään vain salakirjoitettuna. Salaus on juuri yhtä vahva, kuin sen avainhallinta. Huolehdi avainhallinnasta oman yrityksesi sisällä tai käytä toista palveluntarjoajaa. 18
Pidä tietohallinto ja tietoturvan hallinta yrityksen sisällä. 19
Ei, ellei se ole linjassa yrityksen oman tietoturvapolitiikan kanssa. On, mikäli tietoturvavaatimukset täyttyvät ja pilvipalvelun malli tarjoaa yritykselle haetun joustavuuden ja kustannustehokkuuden. Kiireellä ja ilman huolellista suunnittelua rakennettu pilvipalvelu ei ole koskaan turvallinen. 20
Pilvi ei tee poikkeusta perusajatteluun 1. Riskien hallinta 2. Tiedon turvaaminen 4. Jatkuvuuden suunnittelu 3. Tapahtumien hallinta 21
Paras hetki poistaa tieto pilvipalvelusta on juuri ennen kuin tallennat sen sinne tapaus Nirvanix Syyskuussa 2014 pilvipalveluiden tarjoaja, Nirvanix, ajautui konkurssiin ja asiakkaiden oli saatava tietonsa siirrettyä palveluntarjoajan järjestelmistä nopeasti. Jotkut ehtivät, jotkut eivät. Saman kohtalon koki Megacloud, joka ei ehtinyt antaa edes varoitusta, vaan palvelu pysähtyi johdot seinästä tyyliin. Kaikki käyttäjät menettivät tietonsa. 22
Kotimainen ulkoistustarina, jossa yritys menetti myös tietonsa Yritys Oy Oy Pilvi & Palvelu Ab Levy Oy Rauta Oy Käyttis Oy Tallennus siellä jossain 23
mika.viitaniemi@elisa.fi 24
25