Osa1: Toteuttamaton pilvenhallintamalli on HUIJAUS!
Mihin tarvitaan pilvenhallintamallia?
Pilvenhallintamallilla varmistetaan, että järjestelmien kehityksessä ja operoinnissa otetaan huomioon tietoturva, jatkuvuus, kustannukset ja niiden optimointi. Tämän avulla voidaan ohjata ja osittain myös pakottaa kaikki organisaation pilvialustaa hyödyntävät sidosryhmät toimimaan oikein. Tällaisia sidosryhmiä ovat mm. erilaiset sovellustoimittajat ja kehityskumppanit, jotka rakentavat erilaisia kokonaisuuksia asiakkaan hallussa olevaan pilveen. Hyvänä esimerkkinä hallintamallin tarpeesta on useat erilaiset tapaukset, joissa mm. tietoa on päässyt vuotamaan asiakkaan hallussa olevasta ympäristöstä ulos.
Tässä esimerkissä finanssialan toimijalla on ollut avoin AWS S3 bucket, josta on löytynyt 425G kanta vapaasti luettavissa.
Tapahtumasta voit lukea lisää täältä
Viimeisin uutiskynnyksen ylittänyt selkeä governance -puutos ilmeni hetki sitten, kun Ciscon entinen työntekijä pystyi ajamaan alas WebEx alustan 5 kuukautta työsuhteensa päättymisen jälkeen.
Linkki uutiseen tästä.
Tässä kohtaa herää kysymys siitä, että voiko tosiaan olla niin, ettei Ciscon kokoisessa yrityksessä olisi määritelty miten pilvialustaa hallitaan ja millaista tietoturvan tasoa sen tulisi toteuttaa? En millään jaksa uskoa, etteikö heiltäkin löydy jostain nurkasta isolla rahalla tehtyä paperinippua, jonka päällä lukee “Cisco Cloud Governance”
Pilvenhallintamallin avulla pitäisi rakentaa tekninen implementaatio tehdystä määrittelystä kohde pilveen. Tämä tekninen toteutus tuppaa vaan jäämään toteutettavaksi, sitten joskus tai sitä aletaan pitkästä puusta värkkäämään, koska “nää hommat tässä matkan varrella varmaan vielä tarkentuu”.
Vuosien varrella erilaisissa pilven vaatimustenmukaisuutta käsittelevissä työpajoissa on tullut harvinaisen selväksi, kuinka monimutkaisesta asiasta tässä on kysymys ja kuinka valitettavan “pihalla” yritysten oma IT tai muu johto on siitä mitä pilvenhallinta merkitsee ja vaatii. Parhaimmillaan neukkarissa on 15 ihmistä organisaation eri osastoilta ja kukaan ei oikein tiedä miksi ollaan kokoonnuttu. Näitä kokoontumisia järjestetään sitten se 4-7. Kokouksessa konsultin tehtäväksi jää aika usein yksinpuhelu lasittuneille katseille, joista muutama aiheesta kiinnostunut sentään välillä innostuu johonkin jotain kommentoimaan. Määritelmät jäävät ehkä vajavaisiksi tai pelkiksi esimerkeiksi ja vain sinne lapulle. Tässä yhteydessä täytyy myös sanoa, että ei palveluntarjoajatkaan ole olleet ihan kartalla siitä miten tämä hoidetaan.
Syntyy siis harha siitä, että nyt olemme tämän työn tehneet, kun asiat on kirjattu dokumenttiin ja huokaistaan helpotuksesta. Valitettavasti tämä lappu ei itsessään takaa vielä mitään.
Olen koittanut miettiä syitä siihen mistä tällainen epäjatkumo johtuu. Yksi syy voi olla, että pilvenhallintamallia on tehty konsulttitalon kanssa, joka tekee vain asioiden määrittelyjä, ottamatta kantaa siihen miten tämä määrittely tulisi teknisesti toteuttaa. Palveluntarjoajilla taas Cloud Advisor porukka voi olla liian irtautunut todellisuudesta, että linkki tekniseen toteutukseen on jo kauan aikaa sitten katkennut.
Määrittelytyö on myös varsin iso rypistys ja eurot vaihtavat omistajaa siinä määrin, ettei tekniseen toteutukseen ole osattu varautua. Olen myös huomannut, että aika usein taitavat ja kokeneet pilvikonsultit eivät ole kiinnostuneet pilven perustan rakentamisesta, vaan intohimot suuntautuvat sen päälle rakennettaviin innovatiivisiin ratkaisuihin. Jos määrittelyä ei viedä teknisen toteutuksen vaatimalle tasolle, on pilvikonsultin vaikea muuntaa abstrakteja vaatimuksia oikeanlaiseksi konfiguraatioksi ja luoda pilvenhallintamallin tekninen implementaatio eli LandingZone. Tästä syystä toteutus monimutkaistuu, kestää kauan ja maksaa paljon. Myös tilanteissa, joissa on jo pitkään kehitetty järjestelmiä pilveen ilman hallintamallia, voi paketin haltuunotto ja mahdollisten aukkojen ja puutteiden paikkaaminen jälkikäteen, olla todella haasteellista.
Seuraavassa osassa kerron, miten näihin haasteisiin meidän mielestä pitäisi suhtautua.
