Microsoft Sentinel, säästövinkit

Alunperin julkaistu Not Bad Securityn sivuilla nimellä “Sentinel laihialaisittain”. Uudelleenjulkaisen täällä, jotta kaikki voisivat säästää – ja ymmärtäisivät Sentinel ylittämättömän kustannustehokkuuden (kunhan SINÄ et pilaa sitä!).

Sentinel on erinomainen työkalu. Markkinoille puskiessaan silloin vielä Azure Sentinel nimellä kutsuttu SIEM-SOAR -työkalu oli melkoinen paukku, markkinahäiriö. Pilvestä itse käyttöönotettava tehokas työkalu ilman kiinteitä sopimusaikoja. Ja kuinka helppo ja näppärä käyttöönottaa! Meikäläisen tapaan traditionaalisia SIEM-järjestelmiä asentanut taatusti äimistyi. Päivässä Sentinel kukkui ja pureskeli iloisesti dataa. 

Ei ihme, että Microsoft teki Sentinelillä hattutemput ja kipusi esimerkiksi Gartnerin maagisessa kvadrantissa kahdessa vuodessa mitättömyydestä johtajaksi. Tästä lisää MS:n sivuilta.

Entä kustannukset?

Joka kolikolla on kuitenkin kääntöpuolensa ja pilvellä hopeareunuksensa.

Sentinelin tapauksessa helppoutta ja tehokkuutta seuraa se klassisin pilvikrapulan aiheuttaja. Kustannukset siis. Kun rakentaminen on nopeaa, talo nousee hetkessä. Monesti vain unohtuu, ettei talon rakentaminen ikinä ole ilmaista. Eikä tietenkään hienon ja tehokkaan analyysimoottorin rakentaminen pilveenkään ilmaista ole. Toki huomattavasti kustannustehokkaampaa kuin perinteinen tapa niitä rakennella, mutta kyllä kustannuksia yhtä kaikki saa syntymään. Ja jälleen niin tehokkaasti, ikävä kyllä. 

Tässä kynäelmässä olisi tarkoitus jakaa kokemuksia ja oppeja Sentinelin synnyttämien kustannusten hallintaan ja minimointiin. 

Aloitetaan siitä helpoimmasta ja ilmiselvästä, eli hienosti ilmaistuna ostomallista. Sillä tarkoitetaan siis sitä, että Sentinelin kuten useimpien muidenkin Azure-palveluiden ostaminen voi pohjautua moneen eri tapaan. Sentineliin purevat lähinnä sitoutumistasot. Jos Sentinel on tietoturvanne keskiössä ja tärkeä työkalunne, lienee turvallista olettaa sen säilyvän käytössä tovin, jos toisenkin. Valitsemalla nk. sitoumustason (engl. Commitment Tier) päästään alennuksiin, jotka voivat olla melkein 50% maksimissaan.

Toinen erittäin toimiva tapa on arvioida säilytysajan pituutta kriittisesti. Sentinel tarjoaa 90 päivää tietoturvalokien säilytystä ilmaiseksi. Sen jälkeen Sentinelin pohjana oleva Log Analytics tallennustila alkaa tikittää kustannuksia. Perusteltu kysymys on, tarvitaanko Sentinelissä säilyttää dataa yli tuon kolmen kuukauden.

Kas kun vaihtoehtoja on! Log Analytics ei ole säilytystilana niitä halvimpia. Microsoft itse tarjoaa valmista pelikirjaa lokitiedon siirtämiseen edulliseen Blob storageen. Usea asiakas on myös hyödyntänyt muutakin tärkeää tietoa varten järjestettyä arkistointiratkaisua tietoturvalokeille. Forensiikan mahdolliset tulevat tarpeet huomioiva haluaa toki säilyttää tiedot tallessa. Samoin regulaatiot tai sisäisen auditin vaatimukset saattavat pakottaa tarjoamaan hyvin pitkiäkin säilytysaikoja. Vuosien tietoturvadatan hilloaminen Log Analyticsin puolella ei juuri koskaan ole perusteltua.

Kolmas tärkeä peliliike on datanielun huolellinen suunnittelu. Tavallisesti tämä on käytännössä lokivirran kriittistä arviointia. Antaako se mitään lisäarvoa? Esimerkiksi tarkastelu viimeisen 3-6 kk aikajänteen osalta on usein silmiä avaavaa. Jos et kyseisestä datalähteestä ole saanut yhden yhtään hälytystä, on perusteltua kyseenalaistaa sen tärkeys. Ei silti mitään tarvitse menettää! Helppo ja halpa ratkaisu on siirtää verkkolaitteiden tuottaman lokidatan virtaus Log Analyticsin sijaan vaikkapa Basic Logsin puolelle. Näin saavutetaan aivan järkyttäviä kustannussäästöjä. Tuo Basic Logs kun kustantaa vain 1,5% (kyllä, alle kaksi prosenttia!) Log Analyticsin analyysihinnoista. Toki kyselyt ovat rajatumpia ja hälytystukea ei samassa määrin ole.

Vaativampi toteutus on esiprosessoida dataa ennen Sentineliin vientiä. Etenkin 80- tai 90-luvuilta peräisin olevien tietoturvalokitusmuotojen suhteen olen havainnut, että varsinaisen arvokkaan tietoturvatiedon mukana tulee hurja määrä kaikkea silsaa ja täysin irrelevanttia dataa. Tähän törmätään tyypillisesti verkkolaitteiden CEF- ja Syslog-muotoisten datavirtojen kanssa toimiessa. Vastuullinen SIEM-hallinta valitsee suurivolyymisille datalähteille – jotka pääsääntöisesti ovat vielä tuottamaltaan arvolta niitä vähäisimpiä – kustannustehokkaimman tavan käsitellä ja säilöä niitä. Helppoudesta pitävälle Basic Logs ja datan käpistelyn mestari ehkä valitsee esiprosessoinnin tien. Kaikkein helpoin kustannustarkastus on kuitenkin sen palomuurin tai yhteyslaitteen lokitusasetusten läpikäynti. Haluatko todellakin jokaisen session avaamisen menevän Sentinelin kummasteltavaksi. Mitä edes teoriassa sieltä voisi löytyä?

Neljäs tärkeä muistettava asia on Microsoft-näkyvyyden osalta holistinen kustannusarviointi huomioiden eri lisensoinnit ja palvelukokonaisuudet. Esimerkiksi E5-paketointi sisältää myös ”Sentinel-analytiikkaa” jokaisen käyttäjän osalta. Eli Sentinelin kyvykkyyksiä paljon käyttävän organisaation osalta ei ero E3- ja E5-lisenssien kustannuksissa olekaan niin yksinkertaisesti laskettavissa. Ja mikäli liität vaikkapa 100 palvelinta Sentinel-näkyvyyteen, vaihtoehtoja on monia. Vanhojen SIEM-järjestelmien tyyli, jossa virtautetaan eventtitiedot ja tietoturvalokit joka palvelimelta tulee useita kymmeniä kertoja kalliimmaksi kuin modernimpi lähestyminen, jossa ”hubitetaan” palvelimet esimerkiksi Azure Arcin ja Defenderin kautta.

Ja lopuksi

Raskaan käyttölinjan Sentinel-toteutuksille on sitten omat erikoisuutensa, kuten esimerkiksi dedikoitujen Log Analytics klustereiden käyttö. Samoin suuremman organisaation kannattaa jaotella Sentinelinsä maanosittain ja rakentaa näiden välille näkyvyys. En keskity järeimmän luokan kustannusten optimointiin tässä kirjoituksessa. Mikäli Sentinel-kulusi ylittävät vaikkapa satatuhatta vuodessa, ota ihmeessä yhteyttä. Otetaan erillinen sessio kustannustesi leikkaamisesta. Voimme hoitaa homman vaikka nk. success fee -pohjaisesti!

Lopuksi muistutan vielä ”ilmaisannoksista”. Sentinelin saa käyttöön 31 päivän ajaksi ilmaiseksi. Tuon ajan sisällä on hyvä kytkeä kaikki himoitsemasi näkyvyysalueet eli lokilähteet ja arvioida kustannuksia turvallisesti, euroakaan polttamatta.

 PS. Älä IKINÄ anna ”ysäritietoturvaajan” suunnitella Sentineliäsi. Jos siis secujätkäsi horisee vaikka EPSeistä tai verkon turvallisuudesta, ennuste on TODELLA huono. 😉

Tiedon luokittelun ja vaatimuksenmukaisuuden hallinnan tulevaisuus on täällä

Usein on todettu, että itse datan suojaus ja sen integriteetin valvonta on tietoturvan puuttuva rengas. Organisaatioiden hallitsema tietomassa paisuu kuin pullataikina. Tietokantojen ja tiedostojen luokittelu ja governance, niiden vaatimuksenmukaisuudesta puhumattakaan, on perinteisesti toteutettuna aivan valtava urakka.

Isossa maailmassa datan suojaus on ollut pinnalla jo vuosia, mutta täällä pohjolassa siitä on puhuttu jopa hävyttömän vähän. Ilman AI:n tuomaa automaatiota valtavien datamassojen käsittely hirvittää vahvempaakin tahoa eikä ole ihme, että monet välttelevät toimeen tarttumista. Miten onnistuu kaiken tietomassan luokittelu ja vaikkapa GDPR:n alaisten tiedostojen ja tietueiden luokittelu luottamukselliseksi?

Kattavia työkaluja kehitetään kuorman helpottamiseksi koko ajan, ja vaikka työkalut yksinään eivät pysty haastetta ratkaisemaan, on niistä tekijälle valtaisa apu. Tällä kertaa esittelen yhden työkalun tai oikeastaan kokonaisen työkalupakin Microsoftilta, kun se sattuu juuri nyt olemaan erityisen ajankohtainen. Seuraavalla kerralla kurkataan seuraavaan markkinoilta löytyvään teknologiaan ja puhutaan vähän enemmän myös toimintatavoista ja siitä, miksi jokaisen pitäisi viimeistään nyt tarttua toimeen.

Microsoft Purview

Microsoft Purview julkistettiin 19.4. Kyseessä on pilvipohjainen datanhallintaratkaisu, joka yhdistää aiemman Azure Purviewin ja Microsoft 365 -palvelun tiedon suojaus- ja luokittelutyökalujen kanssa. Lopputulos on ainutlaatuinen kokonaisuus koko organisaation kaiken tietomassan luokitteluun hallintaan, suojaukseen ja vaatimuksenmukaisuuden varmistamiseen.

Viime syyskuussa Microsoft toi virallisesti saataville pitkään esikatselussa olleen datan luokittelun ja vaatimuksenmukaisuuden hallintatyökalun, Azure Purviewin. Tämä oli osittain päällekkäinen M365-palvelun kalleimpaan pakettiin (E5 / A5) tarjotun Compliance-portfolion kanssa, mutta myös täydensi sitä mainiosti tuoden luokittelu- ja hallintatyökalut myös M365-palvelun ulkopuolisiin tietomassoihin. Nyt päällekkäisyydet on poistettu ja lisensointia sekä ostomallia selkiytetty. Samalla M365-palvelusta siirretty Compliance ja entinen Azure Purview on yhdistetty ja brändätty uudelleen Microsoft Purviewiksi.

Mitä ja kenelle?

Kokoelma Microsoftin työkaluja tiedon eli datasisällön hallintaan, luokitteluun, suojaukseen ja vaatimuksenmukaisuuden valvontaan. Purview puree oman konesalin (tai siivouskomeron) palvelimiin, eri pilvipalveluihin sekä tietovarastoihin. Datakuraattorin tai tiedon luokittelusta vastaavan on helppo luoda säätöjä ja toteuttaa isoihinkin datamassoihin automaattisesti jalkautuvia politiikkoja. Purview yhdistää Microsoftin datahallinnan, AI:n sekä Microsoftin tietoturvaratkaisujen riskien- ja vaatimuksenmukaisuuden hallinnan.

Kuva 1. Microsoft Purviewin toiminnallisuuden kaksi ulottuvuutta korkealla tasolla

Microsoftin mukaan Purview auttaa etenkin tiimejä, jotka työskentelevät CDO: (Chief Data Officer), CISO:n (Chief Information and Security Officer), CRO:n (Chief Risk Officer) tai CCO:n (Chief Compliance Officer) alaisuudessa. Arvolupauksessa mainitaan kokonaisvaltainen näkyvyys läpi kaiken organisaation pirstoutuneen ja hajautuneen datamassan. Toki regulaatiot, kuten GDPR, näkyvät isona ajurina argumentaatiossa.

Mitä kaikkea Purview korvaa?

Microsoft Purview -tuoteperheeseen on ympätty M365-palveluiden datan ja tietosisällön suojaus-, hallinta- ja luokittelutyökalut sekä mm. kahden suojausavaimen käyttö (Double Key Encryption), sisäpiiririskityökalut ja datan katoamisen suojaustyökalusto.

Taulukko 1. Jälleen kerran siis tuotepaketointi ja -nimeäminen on Microsoftille tuttuun tapaan räväytetty täysin uusiksi

Microsoft Purview tukee jo nyt varsin runsasta määrää eri tietolähteitä. Mukana ovat niin on-prem-palvelimet (virtuaaliset ja fyysiset) kuin pilvipalvelut ja -tallennustilat. Tietenkin tietokantapalvelimet ja muut strukturoidut datasisällöt ovat nekin sekä omassa konesalissa että eri pilvissä. SaaS-palveluidenkin tuki on jo varsin mittava.

Kuva 2. Tietomassojen hallinnointimahdollisuuksia

Entäpä yhteensopivuus?

Tavallaan Purview yhdistää Microsoftin kaksi tarjoama-aluetta: tietoturvapinon ja dataplatformin. Microsoftin pyrkii integroimaan Purviewin kiinteäksi osaksi sekä M365-palveluiden sisältämän tiedon turvaamista että koko tietoturvapinoaan. Esimerkiksi Defender for Cloud Apps (Microsoftin CASB-työkalu) integroituu jo Purviewin kanssa tarjoten kiehtovia mahdollisuuksia näkyvyyteen siitä, missä organisaatiosta lähtöisin olevaa dataa kaikkialta pilvistä löytyy. Ja toisaalta se rajoittaa datan vientiä muihin kuin organisaation hyväksymiin pilvipalveluihin.

Purview tukee alusta alkaen Windowsin lisäksi myös esimerkiksi Mac-käyttäjiä (macOS) ja mobiilipuolella sekä iOS- että Android-ympäristöjä.

Lähteet:

Purviewin viralliset tuotesivut
Uutinen Microsoft Purviewin julkistuksesta

Tämä on “uudelleenlämmitetty” juttu jälleen. Alkuperäisen kynäilin jo keväällä 2022, Purviewin julkistuksen jälkeen, Loihde Trustille. Löydät originaalin täältä:
https://web.archive.org/web/20220428123309/https://www.loihdetrust.com/blogi/tiedon-luokittelun-ja-vaatimuksenmukaisuuden-hallinnan-tulevaisuus-on-taalla/

Ovatko regulaatiot pilvelle liian raskas taakka?

Pilvipalveluiden käyttö on yleistynyt kiivaassa tahdissa eikä vauhdin hidastumisesta näy merkkejä. Pilveen on nyt menossa myös moni sellainen organisaatio, joka ei aiemmin ole kokenut siirtymää mahdolliseksi. Pilveen ei myöskään tarvitse rynnätä pää edellä isosti ja kerralla, vaan pilvisiirtymän voi toteuttaa vakain ja harkituin siirroin.

Monet organisaatiot ovat hylänneet tai ainakin lykänneet pilvihaaveita joko omista tai viranomaismääräyksistä tai kenties jopa kirjavien ohjeistusten aiheuttamasta hämmennyksestä johtuen. Ennen siirtymää halutaan varmistua siitä, että kaikki tapahtuu määräysten mukaisesti ja parhaita tietoturvakäytäntöjä noudattaen. Yllätyksiin ei ole varaa silloinkaan, kun data sijoitetaan oman konesalin sijasta ulkoistustoimijan ympäristöihin.

Esimerkiksi Microsoftin 365-palvelun käyttö (sähköposti, Teams, SharePoint ja OneDrive) säännellyssä toiminnassa on ollut mahdollista, mutta se on vaatinut paljon aikaa ja asiaan perehtymistä. Omaan toimintaan liittyvät vaatimukset ja määräykset on pitänyt täyttää ja välillä työlään selvitystyön sijasta onkin ollut helpompi tyrmätä käyttäjien haaveet pilvipalvelussa tarjolla olevista työkaluista.

Tässä tekstissä viittaan pilvipalvelut-termillä julkipilviin ja niin sanotun privaattipilven (eli esim. automatisoitu konesalipalvelu) jätän käsittelyn ulkopuolelle. Trenditermi hybridipilvi taasen tarkoittaa sitä, että yhdistetään julkipilven ja oman konesalin palvelutuotantoa.

Liikkeelle ei-sensitiivisellä datalla?

Osa organisaatioista on ratkaissut haasteen niin, että pilvipalveluun viedään data, johon ei kohdistu erityisiä vaatimuksia. Arkaluontoinen tieto on edelleen jätetty omiin paikallisiin ympäristöihin. Näin on saatu käyttöön modernin tuottavuuden työkaluja aiheuttamatta kuitenkaan ongelmia regulaatioiden noudattamiselle. Haasteena tällaisessa mallissa on ollut käyttäjien koulutus, sillä käyttäjille on saatava selväksi, mitä dataa pilveen voi viedä ja mitä ei.

Todellisuudessa käyttäjien ymmärryksen tai muistamisen varaan ei regulaatioiden noudattamista voi uskoa. Ihminen on erehtyväinen, pätevinkin meistä. Mikäli pilvipalveluiden käyttö halutaan oikeuttaa datasegregaation kautta, täytyy asian varmistamiseen käyttää jotain tietojärjestelmää. Kun hyödynnetään vielä AI-teknologiaa, voidaan varsin luotettavasti todentaa, ettei arkaluontoista dataa pääse mitenkään valumaan vähemmän kovennettuihin ympäristöihin.

Luottamuksellisuuden varmistaminen

Tiedon lokaatiolla ei oikeasti ole mitään väliä. Oleellista on luottamuksellisuuden varmistaminen. Esimerkiksi Suomessa sijaitseva korkean tietoturvatason konesali ei sinänsä takaa vielä mitään, mikäli palveluiden tekninen operointi on ulkoistettu taholle, joka käyttää edullisen työvoiman maissa olevia tiimejä palvelutuotannossaan. Vanha viisaus kuuluu, että tietoturva on tasan niin vahva kuin sen heikoin lenkki. Julkipilviä rakennettaessa budjetit ovat olleet satakertaisia suomalaisiin parhaisiinkaan konesaleihin ja niiden operointibudjetteihin verrattuna, joten pilvet ovat onnistuneet vähentämään heikoimpia lenkkejä merkittävästi.

Julkisen hallinnon pilvipalvelulinjaukset (VM julkaisu 35/2018) ohjeistaa fiksusti:

  • Pilvipalveluita tulee käsitellä kuin mitä tahansa muutakin ICT-palvelun hankintaa tai muutosta.
  • Pilvipalveluissa on kiinnitettävä erityistä huomiota sopimuksiin, palvelun jatkuvuuden turvaamiseen ja tiedon saatavuuteen.
  • Pilvipalvelun tulee täyttää hankkivan osapuolen palveluhyöty ja -takuuvaatimukset.
  • Mikäli pilvipalvelu tai pilvipalveluteknologia tarjoavat parhaan palveluhyödyn ja -takuun, eikä muita esteitä ole, tulisi se ensisijaisesti valita.

Ja tiedon käsittelyyn liittyen linjaus ilmaisee selkeästi:

  • Julkisen tiedon käsittelyä ei rajoiteta.
  • Ei-julkista tietoa voi käsitellä julkisessa pilvipalvelussa, kun tietoturva ja -suoja on asianmukaisesti toteutettu ja todennettu.

Regulaatioiden näkökulmasta siis estettä pilvipalveluiden käyttämiseen ei ole, kunhan tietoturvan ja -suojan tasosta on huolehdittu.

Suojaako pilvipalvelun tuottaja?

Kyllä ja ei. Julkipilvistä puhuttaessa törmätään väistämättä käsitteeseen ”jaetun vastuun malli”. Asian voisi selittää siten, että pilvipalvelun tuottaja vastaa tärkeistä perusasioista kuten vaikkapa fyysisestä turvallisuudesta ja verkkojen turvallisuudesta. Ja sen julkipilvet tekevät paremmin kuin yksikään superkorkean tietoturvatason konesali Suomessa, kiitos satakertaisten budjettiensa.

Tämä artikkeli ei käsittele laajemmin jaetun vastuun mallia, mutta mikäli konsepti ei ole sinulle kristallin kirkas suosittelen lukemaan blogikirjoituksemme siitä. Julkipilven tietoturva pohjaa vahvasti siihen, että palveluiden käyttäjä eli ostaja tietää mitä tekee.

Tekninen suojaaminen pilvessä

Lisämausteen soppaan tuo tiedon suojaamisen vaade. Ikävä kyllä siihenkään ei löydy täysin yksiselitteistä patenttivastausta. Valtiovarainministeriö edellyttää linjauksessaan tietoturvan ja -suojan asianmukaista toteutusta ja todennusta. Teknisesti tämä taas riippuu merkittävästi työkuorman tyypistä. Pilvipalveluissa puhutaan tyypillisesti IaaS-, PaaS- ja SaaS-työkuormista. Näissä pilvipalvelun tuottajan vastuualueet eroavat merkittävästi. Karkeasti ottaen IaaS-työkuormissa asiakas joutuu vastuuseen suurimmasta osasta ja SaaS-työkuormissa taas pilvipalvelun tuottaja vastaa enimmästä osasta.

Teknisen suojaamisen kannalta juuri IaaS-työkuormat ovat kovennettavissa ja salattavissa julkipilvessä täysin Suomessa sijaitsevaa konesalia vastaavalle tasolle. PaaS- ja SaaS-työkuormien kovennus ja salausmahdollisuudet, esimerkiksi omilla salausavaimilla, riippuvat paljon palvelusta ja toteutustavasta.

Lähteet

Julkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta
Microsoftin dokumentaatio pilvipalveluiden tiedonsuojasta ja vaatimuksenmukaisuudesta

Tämän blogahduksen kynäilin alunperin Loihde Trustille, alkuperäisen löydät täältä:
https://web.archive.org/web/20240620054533/https://www.loihdetrust.com/blogi/ovatko-regulaatiot-pilvelle-liian-raskas-taakka/

Suomalaista pilveä Microsoftilta

Microsoft julkisti yhdessä Fortumin kanssa suunnitelmansa rakentaa Suomeen kaksi datakeskusta. Kyseessä on nimenomaan Azure-datakeskushanke. Aiemminhan Microsoftilla on Suomessa ollut kiihdytyspisteeksi luonnehdittava pieni konesalipresenssi, joka on palvellut M365-palvelun paikallista nopeuttamista. Uusi investointi tuo myös Azure-pilvipalvelut paikallisesti saataville.

Meille syntyy siis toinen täysimittainen ”suomalainen pilvi”. Googlehan ehti ensimmäisenä Haminan datakeskuksellaan. Viime joulukuussa AWS ennätti kertomaan tuovansa nk. Local Zonen Suomeen. Nämä Local Zonet eivät kuitenkaan ole täysimittaisia AWS:n datakeskuksia vaan nk. pilvenreunaa. Niistä voidaan ajaa rajoitettua määrää nk. IaaS-työkuormia. Olen käsitellyt lähipilvi-ilmiötä aiemmassa blogikirjoituksessani. Niin tai näin, kaikki kolme isoa ovat kiinnostuneet Suomesta. Ja kahdella näistä on kotimainen täysi datakeskuskin!

Suomessa Googlen pilven eli GCP:n markkinaosuus on kuitenkin varsin pieni. Azure on maailmalla ja etenkin Suomessa yritysten valinta, Google taasen on pärjännyt oppilaitoksissa ja harrasteorganisaatioissa. Suomessa Azure on ehdoton markkinajohtaja julkipilvistä. Siksi Azuren saapuminen Suomen kamaralle onkin merkittävä asia. Viimeisetkin vasta-argumentit siitä, että datan tulisi sijaita fyysisesti Suomen rajojen sisäpuolella olevilla palvelimilla ja siksi julkipilvi ei olisi hyväksyttävä, ovat nyt häviämässä.

Ympäristö- ja ilmastoasiat ovat pinnalla tämän uusimman datakeskuslaajennuksen toteutuksessa. Palvelinten jäähdytyksessä syntyvä hukkalämpö kierrätetään kaukolämpöverkkoon ja arvioiden mukaan se tulee kattamaan noin 40 % Espoon, Kauniaisten ja Kirkkonummen alueilla asuvan neljännesmiljoonan käyttäjän lämmöntarpeesta. Kyseessä on maailman suurin datakeskusten hukkalämmön talteenottoprojekti.

Merkittävä investointi Suomen mittakaavassa

Sekä Microsoftin että alaa seuraavien medioiden mukaan puhutaan yhdestä Suomen historian suurimmista yksittäisistä ICT-investoinneista. Microsoftin Suomen maajohtajan Pekka Horon mukaan Microsoft päätyi rakentamaan datakeskuksen Suomeen, koska Suomi on yksi johtavista tietoyhteiskunnista maailmassa.

Datakeskuksen sijainti Suomessa lienee lähinnä valtionhallinnon näkökulmasta tärkeä seikka, joka mahdollistaa aiemmin omissa konesaleissa ajettujen työkuormien siirtämisen Azureen, Suomen datakeskukseen. Valtiovarainministeriön ICT-johtaja Jarkko Levasman totesikin aiheeseen liittyen, että myös julkishallinto voi jatkossakin käyttää Microsoftin pilvipalveluja.

Microsoft nimesi lisäksi tiedotteessaan suuria asiakkaitaan nimeltä listaten Nokian, Elisan, Fortumin, S-Pankin, Tietoevryn, HUSin, Verohallinnon ja Valtorin kiinnostuneina asiakkaina. Suomen datakeskuksessa sijaitsevat työkuormat tarjoavat verkkoviiveen eli lantenssin kannalta parasta palvelua suomalaisille käyttäjille. Etenkin julkisen internet-verkon yli käytettävät Azure-palvelut tai SD-WAN -toteutukset hyötyvät lyhyestä etäisyydestä ja Suomen nopeista ja varmatoimisista internet-yhteyksistä. Microsoft on ollut Ficix-jäsen jo pitkään.

Lisätietoa ja artikkelit mediassa:

Microsoftin tiedote
YLEn uutinen
Tivin uutinen
Aiempi blogini “lähipilvitrendistä”

#Azure #suomalainenpilvi #Finnishcloud #Suomendatakeskus #AzureFinland

Alkuperäinen blogahdukseni kirjoittelin Loihteelle. Wayback Machine sen vielä löytää:
https://web.archive.org/web/20240529033441/https://www.loihdetrust.com/blogi/microsoftin-pilvi-on-nyt-myos-suomalainen-pilvi/

Tietoturvan itsepuolustuskurssi pilveen uskaltautuvalle

Tällä blogitekstillä opastan yli pilven turbulenssien ja karttamaan yleisimmät virheet. Lisäksi kerron huonoista käytännöistä, joita helposti tulee valittua, jos pilven rajoitukset ja mahdollisuudet eivät ole kirkkaina mielessä.

Pilvipalveluiden tietoturvan rakennus eroaa perinteisestä tietoturva-ajattelusta etenkin suhteessa luottamukseen. Omassa hallinnassasi olevan verkkokytkimen voit nollata halutessasi, jolloin edelliset konfiguraatiot lähtevät. Samoin voit vaikka purra jokaisen verkkokaapelin poikki varmistaen näin, ettei siellä bitti viuhu eikä data sihise.

Pilvipalveluissa taas joudut luottamaan pilvipalvelun tuottajan tietoturvaan. Et pääse katsomaan (tai puremaan) verkkokaapelia. Luottamus on sekä pilvipalvelun vahvuus että kompastuskivi. Sinä joko joudut tai saat luottaa siihen, että pilvipalvelun tuottaja on hoitanut asiansa kunnolla. Mahdollisuutta auditointiin ei ole. Oikeiden pilvipalveluiden tuottajat eli Amazon, Microsoft ja Google ovat hoitaneet tietoturvansa paremmin kuin sinä pystyt ikinä edes kuvittelemaan hoitavasi – vaikka datakeskuksesi sijaitsisi Tikkakoskella. Todisteena vaatimuksenmukaisuudesta ja tietoturvan korkeasta tasosta on hurja sertifikaattipino.

Mutta tässäpä piileekin sitten myös se miina:

Pilvipalvelun tuottaja hoitaa kyllä oman osansa hyvin. Oleellista on, että sinä ymmärrät selkeästi sen, mikä on sinun vastuullasi. Juuri tämä aiheuttaa suurimman tietoturvariskin.

Jaetun vastuun mallin tulisi olla tietoturva-ajattelusi ydin.

Kuva: Jaetun vastuun malli Microsoftia mukaillen. 

Huomaatko, että jaettu vastuu on liikkuva käsite? Se riippuu työkuorman tai palvelun tyypistä. On-prem tarkoittaa omaa konesalia – tai siivouskomeroa (itse säilytän omia servereitäni lämminvesivaraajan päällä sekä maantieteellisen hajautuksen vuoksi autotallissani). IaaS taas tarkoittaa virtuaalikoneita ja kontteja, joita voisi ajaa omassa virtuaali-infrassakin. PaaS on pilvipalvelun tuottajan alustapalveluita, joiden varaan voi rakentaa omia kokonaisuuksia (esimerkkinä vaikka hallittu tietokantapalvelu). SaaS on ikään kuin ravintoketjun huipulla, ohjelmisto palveluna (kuten M365-palvelut tai Salesforce).

Riippuen jalostusarvosta pilvipalvelun toimittaja vastaa enemmästä tai vähemmästä määrästä. Silti sinulla on aina vähintään aineiston luokittelun ja pääsynhallinnan vastuu sekä vastuu siitä, millaisilla välineillä käyttäjäsi pilven dataa käpistelevät. Ei paljoa auta, vaikka pilvessä oleva potilastietokantasi olisi sotilastasolla kovennettu ja käyttäisi tuplakryptausta omista salausavaimista puhumattakaan, jos niissä koneissa, joilla käyttäjäsi potilastietoja käsittelevät, riehuvat ikävimmät malwaret ja troijalaiset.

Kolme tärkeää askelta turvalliseen pilveen

Absoluuttisesti suurin tietoturvariski pilvipalveluissa on käyttäjä. Jos voit rakentaa pilvipalvelun, johon yksikään ihminen ei koske tai käytä sitä, saavutat verrattain helposti erittäin korkeankin tietoturvatason.

Lähtökohtaisesti kuitenkin IT-palvelut rakennetaan ulkoisille tai sisäisille käyttäjille. Tämä muodostaa keskeisimmän ongelmamme. Erittäinkin turvallisen palvelun tietoturva voi vaarantua käyttäjän antaessa vaikkapa pääsyoikeutensa jollekin toiselle. Tämä voi tapahtua tahallisesti (sisäpiiriuhka), virheen takia (luulin huijaria yrityksen IT-jantteriksi) tai epähuomiossa (sähköpostitin vahingossa tärkeän raportin toimittajalle).

Teknisesti tämä käyttäjän muodostaman riskin mitigointi osuu luvitusten alueelle, ei laajemmin identiteetin ja pääsynhallintaan. Ensimmäinen ohjeeni onkin:

Varmista identiteetti ja logita käyttäjien toiminta.

Käytännössä tämä tapahtuu parhaiten siten, että käytät kaikessa keskitettyä identiteetinhallintaa (esim. Azure AD). Et ikinä erillisiä käyttäjätunnuksia ja salasanoja. Omat, erilliset käyttäjätunnukset ja sanasanat yhdessäkin palvelussa ovat tietoturvaharakiri.

Toinen askel on pakottaa monivaiheinen tunnistus (Microsoft-termein MFA ) käyttöön. Microsoftin tutkimuksen mukaan se ehkäisee yli 99 % identiteettivarkauksista eli käyttäjätilien korkkauksista.

Kolmas askel on älykäs uhkatorjunta. Identiteetin- ja pääsynhallinnan osalta se on helpoimmin toteutettavissa AI-pohjaisilla työkaluilla. Itse tunnen parhaimmin Microsoftin teknologiat, joten nostan ne esimerkiksi. Käyttämällä Azure AD -identiteetin suojausta Microsoftin algoritmit ja koneäly tarkkailevat pääsynhallintaan liittyviä toimia ja tapahtumia läpi käytettyjen palveluiden. Suojausta vahvistaa UEBA (User Entity Behavior Analytics), joka mallintaa koneoppimisen avulla käyttäjän toimintaa. Poikkeavia toimia verrataan esimerkiksi siihen, mitä kollegat normaalisti tekisivät.

Jos jatkat vielä Zero Trust -mallin jalkautukseen, olet suojannut käyttäjiesi identiteetit jo erinomaisen mallikelpoisesti. Mikä parasta, Zero Trust ei ole kallis ohjelmisto tai uusi hieno laite verkkoosi. Se on tapa toteuttaa tietoturva ja muodostaa kontrollit.

#tietoturva #tietoturvaopas #kyberturva #kyberitsepuolustus #pilviturva

Alkuperäinen blogahdukseni kirjailin Loihteen sivuille Tässä linkki historiaan:
https://web.archive.org/web/20240421081222/https://www.loihdetrust.com/blogi/tietoturvan-itsepuolustuskurssi-pilveen-uskaltautuvalle/

Uuden sukupolven SOC

Perinteisesti SOC on ollut lähinnä palomuurin ja mahdollisesti reitittimien sekä muiden verkon aktiivilaitteiden valvontaa. Tämä toi varmastikin 90-luvulla paljonkin lisäarvoa, mutta miten se vastaa vuoden 2022 tietoturvatarpeisiin? Ei mitenkään. On aika ”ladata” SOC 2.0.

Perinteinen tietoturva-ajattelu pohjautui turvallisen verkon ja turvattoman verkon (julkiset verkot, internet) jaotteluun. Näiden puolivälistä löytyy nk. DMZ-vyöhyke, joka yhdistää turvalliseksi ajatellun turvattomampaan. Etenkin OT-verkkojen turvallisuus rakennetaan palomuuraamalla kaikki liikenne ja yhteydet. Näin saavutettiin luotettu verkko, jonka turvallisuus oli taattu. Tätähän voisi pilke silmäkulmassa kutsua vaikka ”full trust”-ajatteluksi.

Puhutaan kehäturvallisuusajattelusta (perimeter security), jossa palomuuri on keskeisin tietoturvaelementti. Firewall suojaa verkon ja rakentaa näin turvallisuuden kehän luotetun verkon ympärille. Palomuurisääntöihin suhtaudutaan ankarasti ja kaikki yhteydet pahasta ulkomaailmasta (etäyhteydet ja sen sellaiset) toteutetaan tiukoilla VPN-yhteyksillä. Tämän aikakauden tarpeiden pohjalta rakennetut SOC-palvelut keskittyvät tietenkin turvaamaan verkkoa.

Vuoden 2022 uhkakuvat

Nykyään krakkeri harvoin tunkeutuu oveluudella ja taidolla palomuurien läpi, vaikka leffoissa tätä vielä viljelläänkin dramaattisin äänitehostein ja punaisin vilkkuvin valoin. Koko sinä aikana, kun olen Loihdetta saanut palvella, en ole nähnyt yhden yhtään palomuurin korkkausta.

Hyökkäykset kohdistuvat tänään tietoturvan heikoimpaan lenkkiin eli käyttäjään. Käyttäjä houkutellaan tai huijataan antamaan hyökkääjälle pääsy sinne turvattuun verkkoon. ”Full trust”-ajattelun heikkous on siinä, että kun kerran voittamaton kehäsuojaus on murrettu, peli on puolustautujan kannalta pelattu. Olet varmastikin kuullut vanhan hokeman epätasaisesta pelistä, jossa puolustautujan täytyy torjua joka hyökkäys, mutta hyökkääjän onnistua vain kerran. Ja näinhän se onkin, jos et päivitä tietoturva-ajatteluasi 2000-luvulle.

Sipuli on tätä päivää

Moderni tietoturva-ajattelu pohjautuu nk. sipulimalliin kehämallin sijaan ja jatkuvaan tarkastamiseen. Tästä kaiken tarkastamisesta käytetään hieman hämäävää termiä ”Zero Trust”, joka usein käännetään nollaluottamukseksi. Kysehän on vain siitä, että automaatio tarkastaa kaiken eikä uskota mihinkään tarkastamatta. ”Varmista aina” olisi parempi käännös.

Sipulipuolustuksen ja Zero Trustin etuna on se, että yksittäinen virhe tai unohdus ei ole fataali. Ovela hyökkääjä, joka onnistui pahuuksissaan nerokkaasti tekemättä virheitä, kuori vain sipulin ensimmäisen kerroksen. Mitä sitten? Sata jäljellä. Yksikin virhe johtaa hälytykseen, jonka SOC huomaa. Peli on jälleen epätasainen – mutta nyt hyökkääjän tappioksi. Puolustautuja voi tehdä virheitä virheiden perään, mutta hyökkääjän täytyy onnistua erehtymättä ja virheettä kymmeniä kertoja peräkkäin.

SOC-näkyvyys tällä vuosituhannella

Suuret ajattelijat ja tutkimusyhtiöt ovat jo vuosia puhuneet SOC-näkyvyyden kasvattamisesta. Modernin SOC-palvelun täytyy ensisijaisesti keskittää valvontansa ja ennakoiva analyysi niihin uhkiin, jotka 2000-luvulla ovat todellisia ja todennäköisiä.

Sananlaskuja mukaillen: ”Yli kaiken varottavan varjele identiteettisi, sillä sieltä elämä lähtee”. Tämän tulee olla uuden sukupolven SOC-palvelunkin lähtökohta.

Jatkuva tarkkailu tulisi suunnata heikoimpaan lenkkiin eli käyttäjien identiteetteihin. Tässä kehittyneet AI-työkalut ovat kullan arvoisia.

Samoin modernin SOCin tulee tarkkailla käyttämiänne pilvipalveluita. Etenkin sähköposti ja muut viestintäjärjestelmät ovat ehdottomasti suurin uhkavektorinne. Sinne tietenkin SOCin kotkansilmät siis suuntaavat.

Ei unohdeta myöskään vanhaa ”follow the money”-viisautta. Mikä ja missä on tärkein tietonne? Toimialasta riippuen kallisarvoisinta voivat olla patenttitiedot, lähdekoodit, asiakastiedot tai muut liikesalaisuudet. Ja varmastikin rahaliikenne. Olethan varmistanut, että SOCilla on varmasti hyvä näkyvyys näihin?

#soc #securityoperationscenter #kyberturva #tietoturvavalvomo

Alkuperäinen blogahdukseni löytyy työnantajani, Loihde Trustin sivuilta. Tässä suora linkki: https://www.loihdetrust.com/blogi/tietoturva/kauan-elakoon-soc-2-0/

What is that… the Cloud?

Once again, I found myself pondering the age-old question: “Is the Cloud simply other people’s computers?” It’s amusing, really, and I must confess, I rather enjoy that notion. In fact, I even have a T-shirt adorned with that very statement. Its charm lies in its apparent simplicity – yet, there’s an underlying truth to it.

However, the crux of the matter lies in the misconception about the Cloud being merely a rental service for computers. In reality, the Cloud transcends the traditional concept of computing resources. While it does offer computing power, shared computers have been around since the 1960s, and hosting services have existed since the ’90s. Remember those days? ISPs rented out pieces of computing power, whether in the form of shared web servers or dedicated machines. Yet, that wasn’t the Cloud.

The very first cloud?

So, when did the Cloud truly emerge? The term “the cloud” was coined – or at least popularized – by Mr. Eric Schmidt, the CEO of Google. The media latched onto the term, and it quickly became a viral sensation. Let’s pay homage to him with a picture:

The guy behing “the Cloud” term

But what about the Cloud itself? Amazon AWS, the web hosting service of the online bookstore giant, ventured into “cloud computing business” in 2006.

However, something akin to the Cloud had been brewing for quite some time. Shared computing resources, groundbreaking services, and the promise of virtually limitless data storage – all of these were facilitated by data centers, rendering it virtually impossible to operate solely from on-premises infrastructure.

There’s a tale of a true visionary who once proclaimed that there’s a global market for only five clouds. For years, he was misunderstood and even ridiculed. His foresight surpassed that of ordinary minds, envisioning a future akin to that of Mr. Watson.

One could argue that the shared IT services market has been evolving since the 1960s to its current state. The market has expanded exponentially, and technological advancements have been nothing short of remarkable. Notably, the level of automation has surged to unprecedented levels, almost beyond belief.

The advent of industrially manufactured computing systems in the 1960s marked a significant milestone. Virtualization, pioneered by a company named VMware in 2001, proved to be a pivotal moment, revolutionizing the automation of IT environments. Subsequently, distributed computing and automation ushered in the era of the Cloud. The diagram below illustrates this transformative journey:

Virtualization enabled an unprecedented degree of automation. A single administrator could now manage over a hundred servers, a monumental leap in enhancing the efficiency of IT operations. Naturally, the demand for data processing power and storage skyrocketed exponentially.

Let’s delve briefly into virtualization technology. It facilitated the automation of tedious and routine tasks, while also optimizing space and reducing energy consumption.

Perhaps the most significant advantage lies in simplified installations (cloning) and significantly reduced downtime (thanks to features like High Availability and snapshots). Software robotics and automation have further empowered us to accomplish complex tasks with a mere click.

Virtualization, very quick intro

Virtualization abstracts the BIOS, operating system, and applications from physical hardware, enabling multiple virtual machines to share the same physical infrastructure, thus saving costs, space, and energy. Moreover, virtualization standardizes hardware across multiple generations and vendors, eliminating the need for frequent OS re-installations or driver changes.

In essence, the Cloud transcends the realm of mere computer rentals.

As we’ve come to understand, the journey from shared computer systems in the 1960s to today’s Cloud environments has been nothing short of remarkable.

It’s crucial to acknowledge the myriad services offered within the Cloud. Virtualization was merely the starting point, transitioning servers into virtual machines through shared layers of virtualization hardware (CPU, memory, network, and storage). Subsequent advancements occurred at an exponential pace, culminating in Infrastructure as Code (IaaS), where computing power, memory, storage, network, and software solutions seamlessly integrate into a cohesive entity. Platform as a Service (PaaS) and Software as a Service (SaaS) naturally followed suit.

The classic Pizza as a Service analogy beautifully encapsulates the essence of IaaS, PaaS, and SaaS.

You see the idea when comparing that to the cloud services schema:

By the way – do you need ready made slides for a training or cloud history introduction? Just ping me, done multiple slide shows to cover that topic. And I am willing to share all. “PowerPoint Open Source Spirit”, or something. 😉

Featured

Microsoft Ignite 2021 – the first day

Microsoft Ignite is here again. Did I write ‘here’? That was not the best way to formulate. ‘It’s now streaming’ is much better. Ignite – like many other gigaevents – is transferred to virtual format. For a geek like me this is just fine. No need to fly and travel. Just sitting down to my sofa and enjoying the content!

Anycase, Microsoft has a long tradition for launching new products, services and updates on Ignite. That’s the one key reason for all working with MS ecosystem to participant Ignite. And this practice seems to continue even during the times of virtual Ignite. The announcements and news of the first day were breathtaking. It almost felt like my brain was swollen. Or maybe it was because of I was listening Ignite sessions to very late night (I am located EET time zone) and after 4 h of sleep I feel a little fuzzy. One way or another, it was worth of it. Yesterday’s jetlag is today’s “streaming-lag”. 🙂

Ok, enough chit-chat. Let’s move to the topic. New launches and announcements. Here comes some of those that enchanted me:

Extended network for Azure – directly to GA. This awesome service gives you possibility to stretch an on-premises subnet into Azure! Think about! When migrating to Azure on-premises virtual machines can keep their original on-premises private IP addresses.

SMB over QUIC – now GA. As short described “the SMB VPN”. That’s something really awesome for telecommuters like me and mobile device use case. Anywhere when high security for stretched filesystem is needed without traditional VPN tunneling.

Custom configuration for Windows Server and Linux VM’s and support for Azure Arc-enabled server VM’s – now in preview.

New virtual machine types (yeah, again – noe Dv5 and Dasv5 with AMD CPU’s. Ev5 and Easv5 with AMD CPU’s) – interesting! Microsoft+Intel has been so long kind of standard set.

On-demand disk bursting – now GA. Excellent functionality to improve startup times and take care of traffic spikes cost efficient way.

Couple of new networking tools are launched for preview. Azure GW Load Balancer and Azure Virtual Network Manager, both long waited and wanted functionalities. Been using own hack for VNet management? Mee too. Finally this is over.

Trusted Launch of VM’s – now GA. Like you see, Microsoft is focusing strong on security. This is improving security of gen 2 VM’s. And no additional price!

And Azure Bastion has finally moved to GA.

AVS aka Azure VMware Solution had a lot of visibility in Ignite. That’s good because the solution is great – but unfortunately came to market quite hopelessly late (and I don’t even mention the miscarriage when Google grabbed the subcontractor).

AKS aka Azure Kubernetes Service gained impressive new functions and many sessions.

Interesting was strong co-operation with wider coverage of “bare metal almost cloud” kind of vendor partners. VMware, Cray and NetApp had stayed strong options for “cloud like” hosting. SAP and Oracle have moved forward, deeper offering on Azure together with Microsoft. And then there are new players: Teradata and SAS. After seen multiple very painfull migration projects from Teradata to Azure I really understand the need for that. Still, it’s a strange marriage.

Elämää palomuurien jälkeen

Palomuurit, nuo bittiteiden tukkeet, ovat ilahduttaneet tietoturvakauppiaiden budjetteja jo hyvän aikaa kolmatta vuosikymmentä. Mutta mikä on firewallin rooli vuonna 2021? Reititin hoitaa NAT-osoitemuunnoksen, isoveli nimeltä pilvi kyttää tietoturvaa rajattomin resurssein ja käyttäjätkin ovat kotosalla, kaukana palomuuriparasta.

Palomuurikeskeinen tietoturva-arkkitehtuuri pohjaa mitä vahvimmin luottamukseen. Luotamme siihen, että verkko palomuurin takana on hyvä ja turvattu. Iso, vahva palomuuri suojaa meidät pahalta maailmalta. Mutta entäpä sitten Zero Trust? Nollaluottamukseen uskoi jo Stalin aikoinaan, murjaistessaan ”luottamus hyvä, kontrolli parempi”.

”Luottamus hyvä, kontrolli parempi”

Ajatus palomuureista tietoturvan varmistajana vanheni jo reilun vuosikymmenen sitten. Google kun korkattiin vihamielisen, valtiollisen toimijan operaatiossa vuonna 2009, he uusivat tietoturva-ajatteluaan. Syntyi ”Beyond Corp”-julkaisu. Tämän saman Zero Trust -nimityksen alle lokeroituvan uuden tietoturva-ajattelun ovat sittemmin omaksuneet Microsoftista lähtien kaikki kentän suuret pelurit.

Lisää pöhinää ja hypeä heitti Gartner tähän soppaan lanseeraamalla SASE-terminsä (Secure Access Service Edge), jonka filosofia ponnisti vahvasti beyondcorp-tyyppisestä ajattelusta. Toki SASE laajensi aihetta tietoturvasta kattamaan myös yritysverkkoyhteydet (WAN). Tuo ei sinänsä aivan uusi ajatus edes ollut. Esimerkiksi Microsoft oli jo aiemmin julistanut, että ”internet is a new corporate network”. Niin tai näin, vanha pizza oli lämmitetty ja todensi osaltaan asian tärkeyden.

Miksi palomuurit ovat vanhentunutta tietoturva-ajattelua?

Googlen ajatushan ei varsinaisesti ollut se, ettäkö muurit olisivat vanhentunutta teknologiaa vaan se, että jaottelu suojattuun ja suojaamattomaan maailmaan ei oikeasti koskaan toimi. ”What if walls never worked?” noin sanatarkasti lainattuna. Eli mitäpä jos ne muurit eivät koskaan ole olleetkaan riittävä vastine uhille – mutta ajattelu pääsi jämähtämään siihen internetin nopean voittokulun äimistyttämänä.

”What if walls never worked?”

Beyond Corp -periaatteet ovat selkeät ja kiistämättömät:
1. Se, missä verkossa laite sattuu sijaitsemaan, ei saa määrittää, mitä palveluita saa käyttää.
2. Pääsy palveluihin myönnetään sen pohjalta, mitä käyttäjästä ja laitteesta tiedetään.
3. Kaikkien palveluiden käyttöoikeuksien on oltava todennettuja, valtuutettuja ja salattuja.

Mikäli organisaatiosi tietoturva-ajattelu pohjautuu vielä ajatukseen, että toimistoverkkosi on ”turvallinen” eli siis luotettu, et Zero Trust -arkkitehtuuria ole saavuttanut. Ja suojauksesi on puutteellinen. Eli odota vain sitä, että teidätkin korkataan. Kyllä se sieltä vielä tulee. Toisaalta, odottaessasi väistämättömän tapahtumista, ehdit vielä vaikuttaa tulevaisuuteen – muuttaen sitä.

Moderni tietoturva nojaa vahvasti kahteen tärkeään seikkaan. Ensinnäkin jokaisen organisaation tulee tuntea käyttäjänsä. Kyllä, IAM on keskiössä Zero Trustissa ja 2000-luvun tietoturva-arkkitehtuurissa. Pelkkä teknologiahan ei tietenkään yksin ole ratkaisu käyttäjien tuntemisessa. Ja toiseksi pitäisi tuntea ja tietää laitteet, joilla käyttäjät töitään tekevät. Tämähän tuo samalla valokeilaan myös omien laitteiden käytön (BYOD). Mahdollisesti vielä seuraatte Microsoftia ja luovutte joko salasanoista tai ainakin lakkaatte kiusaamasta turhaan käyttäjiä salasanojen vaihtohässäköillä.

Miten toteuttaa aidosti tietoturvallinen arkkitehtuuri?

Zero Trust lähtee ajatuksesta, ettei tietoturvamielessä uskota tai luoteta mihinkään vaan kaikki varmistetaan. Oikein implementoituna se tuo tietoturvan muurien jälkeiseen aikaan ja mahdollistaa aidosti turvallisen arkkitehtuurin. Olipa käyttäjä koneineen yrityksen verkossa pääkonttorilla tai tehtaan tiloissa, kahvilassa, lentoaseman loungessa tai kotosalla, tietoturva on aina samalla tasolla. Tämä paitsi tuo tasalaatuisen tietoturvan kaikille käyttäjille riippumatta työskentelypaikasta, myös estää tehokkaasti jostain reiästä sinne ”sisäverkkoon” tunkeutuneen hyökkääjän toimia. Kas kun hyökkääjäparan kannalta sinisilmäisen luottamuksen poistuminen johtaa tilanteeseen, jossa edes sillanpää lähiverkossa (tai OT-verkossa) ei juuri edistä hyökkäystä.

Tietoturva-arkkitehtuurinsa modernisoineen yrityksen palvelut ja järjestelmät tarkistavat ja varmistavat kaikki aivan yhtä pedantisti, tulivatpa pyynnöt sitten ”omasta lähiverkosta” tai internetistä tai vaikka OT-verkosta. Siinä missä ennen riitti palomuurin kiertäminen tai ohittaminen jotenkin antamaan vapaat kädet vakoilla ja ottaa sivuttaisaskelia, nykyään se ei krakkeriressulle oikeastaan tuo mitään etua.

Luotetut laitteet ovat kovennettuja ja EDR-teknologioiden suojaamia, olivat ne missä verkossa hyvänsä. Ja BYOD-laitteiden pääsy resursseihin on rajattu ja aina vahvennetun autentifikaation suojaamaa. Tekoälyyn pohjautuvat teknologiat (esim. UEBA) hälyttävät jopa täysin varmennetun ja kovennetun laitteen käyttäjän vaihtuessa – jos esimerkiksi kollegat testaavat vaihtaa koneitaan päittäin hetkeksi.

Vanha viisaus siitä, että hyökkääjän täytyisi onnistua vain kerran ja puolustautujan kyetä torjumaan jokainen hyökkäysyritys kääntyy päälaelleen: puolustautujan sipulin kuorimiseksi hyökkääjän pitäisi kyetä kymmenien tai satojen onnistumisten sarjaan liki reaaliaikaisesti. Ja välttää AI:n kaikennäkevä silmä. Kyllä siinä pahiksella kyyneleet alkavat virrata.

#zerotrust #nollaluottamus #beyondcorp

Alkuperäinen blogahdukseni löytyy työnantajani, Loihde Trustin sivuilta. Tässä suora linkki: https://www.loihdetrust.com/blogi/elamaa-palomuurien-jalkeen/

Onko pilveen vain menolippuja?

Pilveen mennään usein rytinällä pelkkä menolippu taskussa. Koska kaikki sinne pyrkivät, miksi ihmeessä miettiä jo etukäteen exit-strategiaa? Mutta tarpeen se on silti ja minäpä kerron miksi.

Oikeastaan paluukaistan unohtaminen jopa hämmästyttää. Kuvittelisi ainakin riskinhallintajamppojen haluavan undo-toiminnallisuuden jokaiseen projektiin. Myönnettäköön, että itse näen julkipilven tehokkaimpana tapana tuottaa IT-palveluita. En usko näkeväni montaakaan tapausta, joissa aidosti tekniset tai liiketaloudelliset syyt pakottaisivat pilvipoistumaan. Voi kuitenkin tulla esimerkiksi tarve päästä pois entisestä pilvestä voidakseen rynniä uuteen ja uljaaseen. Olenpa itsekin ollut muutamassa exit-projektissa mukana, joskin näissä ajureina olikin juuri vaihto toisen merkkiseen pilveen. Tästäkin syystä voisi poistumistien viitoittamisen sisällyttämistä jo pilveen siirtymisvaiheessa pitää järkevänä ideana.

Miten pilvestä sitten pääsee pois?

Lähtökohtaisesti kyse on pilvimigraatioprojektin toteuttamisesta käänteisenä. Landing Zone on siis poistumistie pilvestä eli joko hosting-yrityksen tai omissa tiloissa sijaitseva virtuaali-infra tai toinen julkipilvi. Ikävä kyllä julkipilvitoimijoiden kivat ja edulliset migraatiotyökalut ja ohjeistot eivät tue pilvestä poistumista. Julkipilvestä toiseen tietenkin tarjotaan työkalut kohdepilven taholta. Omaan konesaliin siirtyjän taas täytyy haalia työkalut kaupallisten toimijoiden kilkkeistä.

Eroa siinä, onko migraatio konesalilta pilveen, pilvestä toiseen tai pilvestä konesaliin, ei juuritaan tekemisessä ole. Vähän vaivaa, mutta ei mitään rakettitiedettä. Kontitettujen työkuormien suhteen – siis tuo välivaihe virtuaalikonepohjaisten työkuormien ja aidosti serverittömän prosessoinnin välillä – siirtely on vieläkin helpompaa.

Mutta sitten kun tuomme kuvaan mukaan ”modernisoidut työkuormat”, haasteellisuusaste kasvaakin melkoisesti. Toki aivan sama kompleksisuus meillä oli silloinkin, kun työkuormia julkipilveen siirtelimme. Modernisoinnilla tarkoitetaan yleisesti sitä, että hyödynnetään julkipilven palveluita laajemmin kuin pelkkien virtuaalikoneiden ajoympäristönä. Käytettäessä PaaS-tyyppisiä palveluita on jouduttu rakentamaan palvelut julkipilveen kertaalleen uusiksi. Käänteisessä migraatiossa koodaat ja rakennat samat palvelut jälleen kerran uudelleen. Tuskallisinta tämä on silloin, kun tietyt palvelut on rakennettu ”suoraan pilveen”, eli käytännössä softakumppanisi on rakentanut teille myydyn ratkaisun julkipilvitoimittajan teknologian varaan. Näiden osalta pilvi-exit edellyttää koko rakennelman toteutusta uudelleen, toisen teknologiapinon varaan.

Pilvitoimijoiden PaaS-palvelut ovat aina nk. vendor lock. Eli rakennettu hässäkkä toimii ja pyörii vain ja ainoastaan sen julkipilven teknologioiden varassa, johon se alun perin on rakennettu.

Tärkeä kysymys onkin, miksi ihmeessä menisit edes siirtämään PaaS-palveluiden tai vastaavien toimittajalukittujen teknologioiden varaan rakennettuja palveluita. Organisaatiossanne on todennäköisesti käytössä jo vaikka mitä verkko- ja pilvipalveluita. Olette jo hyväksyneet sen, että SaaS-palvelut (esim. M365, Salesforce, Monday jne.) ovat missä ovat ja maksatte vain palvelusta vaihtoehtona ohjelmistolisenssien ostolle.

PaaS- ja SaaS-palvelut ovat siis oma kokonaisuutensa. Niiden migraatiossa pelkän toimittajavaihdoksen tai vastaavan takia ei ole järkeä. Vaikka siirtäisitkin kaikki IaaS-työkuormasi (virtuaalikoneet + kontit) esimerkiksi Azuresta Googleen, voit aivan hyvin jättää PaaS-palveluiden varaan rakennetut elementit Azureen. Toisaalta joku käyttämäsi SaaS-palvelu on taatusti tuotettu AWS:n laskentavoiman varassa. Molempien yhdistäminen GCP:n IaaS-työkuormiin on yhtä helppoa tai vaikeaa kuin samaisten palveluiden yhdistäminen Azuren IaaS-palveluihin. Yleisesti ottaen erilaiset PaaS-palvelut edustavat varsin marginaalista osaa kokonaiskuluista, joita julkipilvi organisaatiolle tuottaa. Sekin puolustaa näkemystä, että PaaS- ja SaaS-palvelut kannattaa käsitellä erikseen.

Entäpä huoltovarmuus?

Haastavin tilanne on huoltovarmuus-tyyppisissä käyttötapauksissa, joissa täytyisi varmistaa palveluiden saatavuus myös mahdollisessa äärimmäisessä yhteiskunnallisessa poikkeustilanteessa. Yhteydet julkipilviin ovat varsin haavoittuvia. IaaS-palveluista on helppoa ja jopa verrattain kustannustehokastakin rakentaa DR-saitti konesaliin. Nämä PaaS-palvelut ovat siksi todella hankala ja arvokas pähkinä purtavaksi. Pilvitoimittajien omat nk. edge-teknologiat ovat ainoa vähääkään suoraviivainen tai kustannustehokas tapa. Pilvistä maan päällä olen pitänyt webinaarin , josta saat lisätietoa pilvenreunateknologioista. Vaikka webinaarin varsinainen kärki ei olekaan huoltovarmuusajattelussa, aihealue ja teknologiat ovat tähänkin sopivat. Tästä ”lähipilvi”-kehityssuunnasta kannattaa lukaista myös blogi.

SaaS-palvelut joudut ikävä kyllä unohtamaan huoltovarmuuden kannalta. Niitä et pysty peilaamaan maan päälle mitenkään, ellei nyt kyseinen SaaS-palvelu sitten tarjoa jotain hybridiratkaisua. Tämä kannattaa ottaa huomioon huoltovarmuuslain koskettamilla toimialoilla tietojärjestelmävalintoja tehtäessä. Riittäisikö ehkä se, että SaaS-palvelun sisältämä data olisi käytettävissä vaikkei palveluun päästäisi?

Vaikka uutisia isojen SaaS-palveluiden kadottamista tiedoista ei olekaan näkynyt (mikä kertoo jo jotain näiden palveluiden tekniikan laadusta), tutkimusten mukaan 40 % organisaatioista on menettänyt tietoa SaaS-palveluissa. Toki 2/3 menetyksistä on aiheutunut käyttäjien turauksista. Mutta menetettyä tietoa ne silti ovat. Jos varmistat CRM:n omassa konesalissasi, kannattaisiko ehkä harkita pilvessä olevan CRM:nkin tietojen suojaamista?

Menikö ohi ajatuksen ja kaarsi kaukaa jakauksesta? Eipä hätää. Klikkaa itsesi pilvi–suomi-sanakirjaan, josta löydät blogissa käytetyn terminologian kattavasti selitettynä.

Alkuperäinen blogahdus löytyy työnantajani, Loihde Trustin, sivuilta. Suora linkki tässä: https://www.loihdetrust.com/blogi/onko-pilveen-vain-menolippuja/