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/

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/

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/

Naapuripilvi, pilvinaapuri, lähipilvi, kaupunkipilvi. Pilven reunasta puhuvat nyt niin IT-ihmiset kuin pilviekspertitkin. Pilvi ei enää pysy taivaalla, vaan laskeutuu alas valtavista konesaleista pienempiin datakeskuksiin. Tätä kutsutaan “reunalaskennaksi” (eli edge computing). 

Reilun kymmenen vuotta pilvi oli kuin jokin abstrakti elementti, kaukana sijaitseva kaikkien konesalien äiti, johon kannatti kaikki palvelut työntää. Kun se oli halvinta siten. Ja palveluiden laatu vain parani, mitä ”pilvemmässä” ne olivat.
Nyt sitten ”lähiruokavillitys” on tullut pilviboomiinkin. Ei selvittykään muutamalla kymmenellä konesalilla maailmassa, vaan datakeskuksia tulee olemaan tuhansia. Siihen sinun entisen konesalisi paikalle kolahtaa kohta pilvitoimittajan pikkupilvi.
Ja se tapahtuu juuri nyt, parhaillaan.

Microsoft ilmoittaa avaavansa 100 uutta datakeskusta joka vuosi

Pilvijätti Microsoft on ilmoittanut käyttävänsä miljardeja uusien datakeskusten rakentamiseen. Suunnitelmissa on rakentaa 50–100 datakeskusta vuodessa. Jo vuoden 2021 loppuun mennessä Azure laajentuu kymmeneen uuteen maahan.
Pilvi- ja ohjelmistojätti ilmoitti aggressiivisen datakeskusten lanseeraussuunnitelman aloittaessaan uuden Azure-datakeskusten virtuaalikierroskokemuksen. Kannattaa muuten tutustua! Harva pääsee enää fyysiselle kierrokselle Azure-datakeskuksiin, mutta nyt jokainen voi kokea serverihuuman online-kiertueella. Tuossa simuloidussa kokemuksessa myös kerrotaan yksityiskohtaisesti Microsoftin investoinneista tietoturvaan, luotettavuuteen ja korkeaan käytettävyyteen.
Microsoft on ollut uranuurtaja innovatiivisissa ratkaisuissa datakeskusten suhteen. Erittäin kiehtova – suorastaan scifiä lähestyvä – oli Microsoftin onnistunut merenalaisten datakeskusten pilotointi. Lisäksi Microsoft on ilmoittanut, että vuoteen 2025 mennessä datakeskusten nielemä energia on 100% peräisin uusiutuvista energialähteistä.

Linkkejä:
Microsoftin virtuaalikierros Azure-datakeskuksessa
Microsoftin julkaisu datakeskusten uusista tuulista
Uutinen vedenalaisten datakeskusten pilotista
Microsoft sitoutuu olemaan hiilinegatiivinen vuoteen 2030 mennessä

Eikä Mikkis ole ainoa!

Microsoft ei ole suunnitelmiensa kanssa yksin. Amazon on jo aiemmin lanseerannut nk. local zonet. Kuten Mikkiskin, Amazon on huomannut, ettei pilvi pure läheskään kaikkiin tarpeisiin. Latenssi-intensiiviset sovellukset, kuten mediatuotanto, reaaliaikaiset moninpelit, videostreaming, AR/VR, koneäly ja simulaatiot – ikivanhoista client-server-sovelluksista puhumattakaan – toimivat parhaimmin mitä lähempänä käyttäjää ne sijaitsevatkaan.
Ja pilvihän on perinteisesti ollut kaukana. No, eipä ole kohta enää! Ala-Perniön Amazon AWS Local Zonea odotellessa.
Googlella taas on rajallisen datakeskusverkostonsa (24) lisäksi ollut jo pitkään huomattava määrä pilven reunasaitteja (142). Tämän ymmärtää hyvin hakukoneen, YouTuben ja muiden kuluttajapalveluiden tarpeiden pohjalta. Ilmeisesti hakujätti hyppää mukaan skabaan ja kohta meillä on pikku-Googleja joka kaupungissa.

Linkkejä:
AWS:n Local Zonet tuovat pilven lähelle käyttäjää
Amazonilla jo 3 Local Zonea 2020 ja vuonna 2021 vielä 12 lisää

Alkuperäinen blogahdus löytyy työnantajani, Loihde Trustin, sivustolta. Tässä suora linkki kynäelmääni: https://www.loihdetrust.com/blogi/laskeutuvatko-pilvet-vai-putoaako-taivas-pilvi-on-muutoksessa/

#reunalaskenta #lähipilvi #cloudedge #pilvenreunat #localzone

Ja jos aihe kiinnostaa enemmän, mikset kuuntelisi aiheesta pitämäni webinaaria?

Se, mikä toimi loistavasti vuosikymmeniä sitten, ei välttämättä istu enää nykypäivän tarpeisiin. Näin on käynyt myös MPLS:lle.

MPLS eli Multiprotocol Label Switching on 1990-luvun lopulla kehitetty teknologia, jolla WAN-verkkojen kompleksisuutta pyrittiin vähentämään. MPLS suunniteltiin ATM:n korvaajaksi. OSI-mallin mukaan MPLS operoi kerrosten 2 ja 3 välillä (puhutaan ”layer 2,5” -teknologiasta). MPLS-runkoverkossa kuljetetaan verkkoliikennettä (esim. IP-paketti) ennalta määriteltyjen yhteyksien ylitse runkoverkon solmujen kautta ilman, että solmujen tarvitsee tehdä reititystä.
Vaikka useimmat MPLS-tekniikalla alun perin haetuista tavoitteista ovatkin menettäneet merkitystään tieto- ja verkkotekniikan kehittyessä, ovat MPLS-yhteydet säilyttäneet paikkansa teleoperaattoreiden paraskatteisien palveluiden joukossa. Ja tietenkin parasta bisnestä on pyritty boostaamaan. MPLS-pohjaiset yhteydet ovatkin sitten hallinneet vuosikymmeniä yritysverkkoyhteyksien markkinaa. Yritysverkoilla tarkoitan WAN-verkkojen (Wide Are Networking, laaja-alueverkko) eli organisaation eri lähiverkkojen yhdistämisestä syntyvää yritysverkkokokonaisuutta.
Ja mikäpä kuninkaan olisikaan ollessa! MPLS-teknologiahan sopii hyvin ennalta määritettyihin reitteihin ja kokonaisuuksiin, jotka kerran suunnitellaan ja sitten rakennetaan ja tämän jälkeen ne säilyvät muuttumattomina. Tyypillinen vanhan kuninkaan aikainen topologia on perinteinen tähtimuoto, jossa keskiössä on pääkonttori tai sittemmin datakeskus. Tähden reunat ovat haarakonttoreita, joista liikennöidään pääkonttorille. Ja pääkonttorilta tarjotaan koko yrityksen kaikille käyttäjille keskitetyt palvelut, kuten vaikkapa sähköpostit, levypalvelut ja organisaation käyttämät sovellukset.

Onko se enää tätä päivää?

Herran vuonna 2021 maailma on kovin eri näköinen kuin 90-luvulla. Tuskin kukaan kiistää tietotekniikan huimia loikkia eteenpäin. Siinä kun vielä 2000-luvun alussa MPLS-verkoissa kiisi yli 80% nk. liiketoimintasovellusten datavuota ja pieni marginaali internet-liikennettä, on tänään MPLS-verkoissa viuhuvista biteistä yli 80% pelkkää internet-liikennettä. Siis sellaista liikennettä, jonka bittihinta on parin vuosikymmenen aikana pudonnut alle sadasosaan. Kas kun internet-yhteyksien hinnat kaistaan suhteutettuina ovat romahtaneet. MPLS-bitti maksaa karkeasti arvioiden noin kymmenkertaisesti sen mitä edullisin internet-bitti. Siispä on aivan relevantti kysymys, miksi ihmeessä ajamme MPLS-yhteyksissä tätä järjettömästi halvempaa internet-liikennettä.

Jos lähikauppa tekee sinulle erikoistarjouksen (”only for you, my friend”) ja saat sisäfileen hinnalla sika-nautajauhelihaa, oletko otettu. Mikäli et (en siis lähde olettamaan taloudellisen ajattelusi preferenssejä), esittäisin kysymyksen, miksi sitten tietoliikennekapasiteetistasi maksat sisäfileen hintaa sika-nautajauhelihasta.

Miksi MPLS ei sovi vuoteen 2021?

Tähtiverkko on 90-lukua. Suurimmat yritykset – ja parhaat ja fiksuimmat pienimmistä – ovat monoliittisista rakenteista jo luopuneet. Esimerkiksi Microsoft julistaa, että ”internet on uusi yritysverkko” (”internet is the new corporate network”). Samoin merkittävimmät tietoliikenne- ja tietoturvayritykset ovat joukolla lähteneet intoilemaan Gartnerin lanseeraamasta SASE-arkkitehtuurista, jonka keskiössä on yritysverkkojen (WAN) ja tietoturvan konvergenssi ja yritysverkkojen organisoituminen koodilla hallittaviksi.
Juuei. MPLS:n alkuperäiset edut ja argumentit ovat hävinneet. Vanhakantainen hinnoittelu teleoperaattoreiden taholta entisestään pelaa MPLS:n valintojen ulkopuolelle. Vai oletko nähnyt MPLS-tarjousta, jossa sinulle ehdotetaan 10 Gbps:n kapasiteettia , josta maksat vain käytön mukaan (esim. keskiarvototeuman mukaan kuukausitason kaistan käytöstä). Ja sopimusrakenne on mallia toistaiseksi. Ei tietenkään, sillä datanetit ja lanlinkit ja mitä noita onkaan, pohjautuvat vuosien sopimusrakenteisiin.
Mutta mitä ihmettä? Sinähän tuotat it-palvelusikin pilvestä ja maksat juuri ja vain käytön mukaan. Sopimusaika on toistaiseksi. Miksi et hankkisi tietoliikennettäsi samalla mallilla? Kun konttorit tyhjenevät väestä Covid-19:n seurauksena, kiinteät piuhakulut ovat täyttä rahan haaskausta.

MPLS tuo huonon palvelun loppukäyttäjille

Jos kuitenkin päätät pidättäytyä vanhassa (eikä siinä mitään, onhan nk. suurkoneitakin vielä rouskuttamassa), luovu nyt ainakin ihmeessä tähtiverkkotopologiasta. MPLS-verkot aiheuttavat vuonna 2021 huonon käyttäjäkokemuksen pilvipalveluille. Siis jos änkeät sen internet-liikenteen MPLS-putkeen ja ammut ulos jostain keskitetystä internet-reiästä keskitetyn palomuurin läpi.
Esimerkiksi Teams, Zoom, Meet ja muut veikeät uudet työnteon tavat toimivat parhaimmin, jos internet-reikä on lähimpänä käyttäjää. Ja näin sinun ei tarvitse ostaa sika-nautaa sillä sisäfileediilillä, kun saat nettibitin tuhottoman monta kertaa halvemmalla kuin mitä maksaisit MPLS-rööriesi turvottamisesta.

Alkuperäinen blogahdukseni löytyy työnantajani, Loihde Trustin, sivuilta. Suora linkki tässä: https://www.loihdetrust.com/blogi/aika-sanoa-heipat-mpls/

Kirjoitin aiheesta jo yhden vanhemman blogahduksen, jossa kuvasin hieman IoT-aihealuetta noin yleisesti sekä sen aiheuttamia tietoturvahaasteita. Ehkä olet sen jo lukaissut? Niin tai näin, pääset varmasti kärryille.

Siirrytäänpä siis esimerkin avulla käytännön haasteita perkaamaan:
Kuvitteellinen yritys, Airiv Oy, työllistää noin sata henkeä. Sillä on hallinnassaan maksimissaan parisen sataa työasemaa (jos laskemme, että osalla käyttäjistä on sekä läppäri että tabletti tai pöytäkone sekä jokunen vara- ja vieraskone) ja ehkä noin sata mobiilipäätelaitetta. IT-osastolla lienee yksi tai maksimissaan muutama henkilö. Nämä pystyvät hyvin hoivaamaan sen pari-kolmesataa päätelaitetta sekä muutaman yrityksen palvelinlaitteen. Airivin konemäärä ei mitenkään voi satakertaistua vuodessa. IT ei millään ilveellä skaalautuisi moiseen kasvuun muusta organisaatiosta puhumattakaan. Jo väkimäärän tuplaantuminen tuottaisi taatusti suuria prosessi- ja organisaatiohaasteita.
Airiv pystyisi kuitenkin käyttöönottamaan tuhansia tai jopa kymmeniä tuhansia tiedonkeräimiä, IoT-laitteita. Jos Airiv olisi kotihoitoyritys, asiakkaita olisi tuhansia. Jokaisen kotona voisi olla lukuisia sensoreita ja antureita ja älylaitteita, joiden ylläpidosta Airiv vastaisi; ultraäänitutka vanhuksen kaatumisen tunnistukseen, kameravalvontaa, sähkölukkoja, puettavia sensoreita, lääkeannostelija noin alkuun. Tai kiinteistönhuollossa laitemäärä voisi olla vielä edellistä esimerkkiä paljon suurempi.
Miten Airiv Oy:n IT pystyisi suojaamaan kaikki IoT-laitteet, kun he eivät pystyisi skaalautumaan tuhansien läppäreiden hoivaan ja suojaukseen? Oleellista on tajuta, että eivät pystykään. Laitteet ovat ainakin osin tiloissa, joiden turvallisuutta ei voida taata. IoT-laitteet on valmistettu paljon halvemmalla ja kehitetty nopeammalla syklillä kuin monin verroin arvokkaammat henkilökohtaiset tietojenkäsittelylaitteet. Niiden suojausmahdollisuudet ovat rajalliset ja kovennus onnetonta suhteessa vaikkapa kännykkään.

Suhtaudu IoT-laitteeseen kuin ventovieraaseen

Kaikki lähtee siitä, että hyväksyt sen, etteivät IoT-laitteet ole sinun ja ettet mitenkään pysty turvaamaan niitä. Suhtaudu niihin kuin vierailulle tulleeseen anoppiin tai kahvilan ventovieraisiin muihin asiakkaisiin.
Oleellista on haarukoida ja ymmärtää, mikä muodostaa riskin. Itse jakaisin sen lyhyesti seuraaviin osa-alueisiin:

1. IoT-laitteiden sisältämä tieto
2. Tietoliikenne IoT-laitteiden ja sinun tietojärjestelmäsi välillä
3. Oman tietojärjestelmäsi keräyspiste, hubi tai connection point.

Ensimmäinen on vaikea. Jos IoT-laite sisältää sinun kannaltasi kriittistä tietoa, joudumme reivaamaan strategiaa ja isosti. Silloin itse laite on suojattava samalla pieteetillä kuin vaikkapa avainhenkilön älypuhelin. Toisaalta, jos laite sisältää kriittistä tietoa, siihen voitaneen investoida samoilla budjeteilla kuin muihinkin oikeisiin työvälineisiin. Ja tämä tietenkin asettaa rajat skaalautumiselle. Tonnin kännyköitä ei Airiv osta jokaiselle, eikä tonnin hintaisia hienoja sensoreita kylvetä aivan minne sattuu. Vähintään ne pyritään suojaamaan varkaudelta. Ehkäpä ne voivat sijaita palomuurin suojaamassa verkossakin ja sisältää jopa laitehallintaakin.
Kalliit laitteet voidaan ja kannattaa suojata. Mutta Airivin haastehan syntyykin isosta massasta verkkoon huutelevia vehkeitä, joiden yksikköarvo on talousrealiteettien pohjalta väistämättä melko vähäinen. Pelkkä päätelaitesuojauksen vuosilisenssi – jota simppeliin sensoriin kyllä ei saa edes asennettua – olisi kalliimpi kuin koko vekotin.
Suurimmassa osassa käyttötapauksia sensoreiden ja laitteiden itsensä sisältämä tieto on sinänsä merkityksetöntä. Vain pidempään kerättyä tietoa, jonka voi liittää kontekstiin, pystyy hyödyntämään. Kahvikoneen yksittäinen tilatieto tai vikailmoitus ei ole salattavaa. Eikä kosteusanturin tai liiketunnistimen. Jopa kameravalvontalaitteen hetken itse laitteessa puskuroima kuvavuo on sinänsä merkityksetön – siis sen hetkinen 5 sekuntia. Loputhan on jo siirtynyt pilveen.
Suurin osa tietoliikenteestä IoT-laitteista lähetetään keräyspisteeseen täysin salaamattomana (ks. Palo Alton raportti). Ja TÄMÄ on suuri tietoturvariski. Se valvontakamerasi sisältämä 5 sekuntia puskuridataa ei ole ongelma. Mutta mikäli jokin vihamielinen taho kaappaa koko videofeedin ja saa näin reaaliaikaisen näköyhteyden kohteeseesi, saattaa kyseessä jo olla aivan eri luokan uhkakuva.

Dell-EMC:n Global Data Protection Index paljastaa, että 5G-verkon ja IoT-laitteiden tietoturva on vielä heikoilla.

Keräyspiste on erityisen kriittinen osio

Jo pelkästään IoT-laitteesi tarvitsema tietoliikenneyhteyden toteutus saattaa muodostaa haavoittuvuuden. Ja datavuon pitäisi vielä kulkea julkisen internet-verkon yli. Eli ainakin jonkinlaista luottamuksellisuutta sisältävän kuva- tai sensoridatan tulisi olla salattua. Mutta tukeeko IoT-laitteesi salausta? Useimmat eivät, joten joudut rakentamaan salauksen IoT-laitteita palvelevan reitittimen tai edge-pisteen ja keräyspisteesi välille.
Keräyspiste taas on kriittinen osio IoT-tietoturvasi kannalta. Se on ensimmäinen portti sinun todelliseen tietojärjestelmääsi, missä kaikki yrityssalaisuutesi ovat. Jotta kerätyllä datalla olisi jotain arvoa, se pitää pystyä säilömään ja sitä pitää pystyä käsittelemään. Eli sinun on hallittava dataa ja pystyttävä jakamaan ja muokkaamaan sitä.

Alkuperäinen blogahdukseni, samoin kuin tässä viittaamani aikaisempi IoT-märinä, löytyvät Loihde Trustin sivuilta. Suorat linkit tässä: https://www.loihdetrust.com/blogi/iotn-tietoturvatarpit-tee-nain-ja-valta-karikot/ ja https://www.loihdetrust.com/blogi/ihmeellinen-ihana-iot-vaiko-sittenkin-tietoturvaajan-kauhistus/.

Jos aihe kiinnostaa, mikset kuuntelisi webinaarijaksoa aiheesta? Tai englanniksi aiheesta pitämäni märinän Nordic IoT 2020 -tapahtumassa.