Cloud SASE, SSE ja ZeroTrust ratkaisut ovat kymmenen vuoden aikana modernisoineet tuhansia yritysverkkojen on-premise ratkaisuja. Trendiä voidaan pitää jatkumona pilvisiirtymälle kuten Microsoft Exchange™ siirtymiselle Microsoft O365™ aikanaan. Pilvessä on paljon hyvää, mutta analysoidaanpa, onko seuraava markkinointimateriaalin argumentti totta?  Traditional VPN fail to provide crucial capabilities for a zero-trust deployment, since they allow traffic to the whole network. Väite tulee esille lähes jokaisessa alan webinaarissa ja asiakaspalaverissa. Onko se totta vai myytti riippuu, kuinka perinteinen määritellään? Cloud Zero Trust – Myths or Facts paneutuu aiheeseen.

Mikä on traditional?

IPsec VPN Client (verkkotason yhteys) muodostui etäyhteyksien standardiksi 90-luvun puolivälissä. Ratkaisussa sallittiin määritellyt IP-aliverkot tai yksittäiset IP-kohdeosoitteet. Asteittain toteutusta laajennettiin palomuurisäännöillä, vahvalla tunnistautumisella sekä NAC-ratkaisuilla. Tämän osalta väite laajan verkkoyhteyden ja hyökkäyspinta-alan osalta pitää vain osin paikkansa, jos lainkaan.

Yksi IPsec VPN Client haasteista oli kumppanien, ulkoistettujen ylläpitäjien, konsulttien yms. pääsy yrityksen sovelluksiin sekä usean IPsec client-ohjelmiston jakelu työasemiin. Tähän spesifiseen tarpeeseen etsimme teknologiaa vuonna 2002 ja aloitimme yhteistyön Neoteris™ startup kanssa 2003. Heidän markkinaviestinsä oli ”Client-Less VPN” ja sovellustason tietoturva.

Neoteris™ (myöhemmin NetScreen Technologies™, Juniper Secure Access, Pulse Secure™, Ivanti Secure Access™) teknologia saavutti lopulta markkinajohtajan ja Gartner™ leading vendor aseman SSL-VPN markkinassa. Tämän VPN etäyhteysratkaisun osalta väite verkkotason yhteydestä pitää vain osin paikkansa, jos lainkaan.

Client-Less SSL-VPN ja Zero-Trust Access määritelmä

Client-Less VPN pääsy määriteltiin sovellustasolla (Layer 7 ja/tai proxy), ei verkkotasolla. Profiilit sekä Active Directory™ integraatio helpottivat hallintaa. Päätelaitteiden ja käyttäjien tunnistaminen ja valtuuttaminen eri tilanteissa olivat perusominaisuuksia. Väitän, että Client-Less SSL-VPN ratkaisussa Zero-Trust Access määritelmä oli toteutettavissa ja toteutettiin.

Eurot voittivat tietoturvan

Eräs keskeisimmistä SSL-VPN haasteista oli suuryritysten access profiilien luominen ja ylläpitäminen. Verkostoituneessa ja jatkuvasti muuttuvassa liiketoiminnassa sovellustason access-profiilien muutoshallinta on haastavaa. Se edellyttää asiakkaalta kristallinkirkasta näkemystä, mitä-kenelle-mistä-milloin-vaatimukset. Ratkaisun toimittajan asiantuntijalla kyseistä tietoa ei ole käyttöönottovaiheessa. Cloud SASE ja SSE ei muuta asiaa.

Haasteena olivat myös lukuisat hyvin erilaiset sovellusarkkitehtuurit, kuten client/server ja Java™ toteutukset.  SSL-VPN (OSI layer 7 access tai proxy-tekniikka) toimi hyvin yleisillä http-sovelluksilla ja VDI-ratkaisuilla, mutta suuryrityksillä oli satoja muitakin sovelluksia. Konfiguraation määrittely ja testaaminen oli kallista asiantutijatyötä. Sovelluksen muuttuessa versiopäivityksen yhteydessä työ jouduttiin tekemään uudestaan vikaprosessina.

Yllä mainittujen haasteiden ratkaisemiseksi oli hyvin houkuttelevaa toteuttaa L3 verkkotason yhteys koko verkkoon ja siten laaja hyökkäyspinta-ala. Sellaisen konfigurointi kestää tunnin, eivätkä sovellukset tai sovellusarkkitehtuurin muutokset vaikuta ratkaisun toimintaan. Päätös verkkoyhteyden toteutuksesta siten saattoi olla myös kaupallinen (tunnin asiantuntijatyö vs. viikkojen vaativa asiantuntijatyö ja jatkuva muutoshallinta). Vaihtoehtoisesti ratkaisumyynti ei yksinkertaisesti osannut selittää ja perustella huomattavaa hintaeroa palvelun käyttöönotolle ja ylläpitokustannukselle.

Hintakilpailu tappaa erillisjärjestelmät

Microsoft Windows Server 2008R2™ Direct Access ja sen Always-On VPN oli perinteinen verkkoyhteys, johon Cloud SASE & SSE toimijat mahdollisesti viittaavat?  Työasemaan integroitu etäyhteysratkaisu osana Microsoft™ lisensointia korvasi monesti lukuisat kalliit erillisjärjestelmät. Tietoturvan kontrolli siirtyi samalla Windows™-palveluista vastaavalle toimittajalle verkko- ja tietoturvatoimittajan sijasta. Samanaikaisesti palomuurivalmistajat kehittivät SSL-VPN ratkaisuja (käytännön toteutukset verkkoyhteyksiä) osaksi palomuuria. Hinta ja helppokäyttöisyys voittivat tietoturvan.

Zero-Trust Access teknologia

Väitän, että Cloud SASE & SSE ja sen ZeroTrust ei merkittävästi poikkea SSL-VPN ”Client-Less” (proxy ja Layer 7) toteutuksesta tietoturva teknologian osalta. Suurempi vaikutus ja mahdollisuudet toteuttaa se käytännössä tulee sovellusarkkitehtuurien päivityksistä viimeisen 20 vuoden aikana. Client/Server, vanhat Java sovellukset yms. ovat päivittyneet ja markkinoilla on enemmän natiivi Web-sovelluksia. Onnistumisen mahdollisuudet välttää ”perinteinen” verkkotason yhteys on nyt parempi. Se ei kuitenkaan tarkoita, että sovellustason access-ratkaisuja ei olisi toteutettu jo vuosikymmeniä. Se ei myöskään tarkoita, että pilviratkaisu olisi käyttöönoton osalta ”plug and play” tunnin työ. Voidaan myös kysyä, olemmeko tulleet 90-luvun alkupuoliskon Application Proxy palomuuriarkkitehtuuriin?

Cloud SASE & SSE liiketoimintahyödyt

Tietoturva siirtymisen perusteluna on mielestäni epäammattimainen, ellei 100 % varmasti tunne asiakkaan nykyistä ratkaisua ja toteutusta. Se on markkinan ja kilpailijoiden aliarvioimista tai myynnin kokemattomuutta yritysverkkoratkaisuista. Sen sijaan Cloud SSE, SASE ja NaaS tuovat merkittäviä liiketoiminnallisia hyötyjä mm. yritysjärjestelyissä ja liiketoiminnan skaalautumisessa verrattuna on-premise ratkaisuihin. Huolimatta turvallisuusympäristön muutoksesta, kokonaiskustannus määrittää edelleen paljon ratkaisujen valintaa. Autamme näissä ja monessa muussa.

 

Hannu Rokka, Senior Advisor

5Feet Networks Oy