Juniper ilmoitti lokakuussa 2020 ostavansa 128 Technologyn 450 miljoonalla dollarilla. Kaupan idea oli selvä: yhdistää 128 Technologyn Session Smart -reititys Juniperin Mist AI -vetoiseen kampus-, toimipiste- ja SD-WAN-ajatteluun. 128T:n kiinnostavin perintö ei ollut vain uusi SD-WAN-tuote, vaan ajatus siitä, että WAN-reititys voidaan rakentaa palvelu-, tenantti- ja istuntokohtaiseksi pääsynhallinnan osaksi.

Perinteinen WAN ja SD-WAN: reititä ensin, kontrolloi myöhemmin

Perinteisessä WAN- ja SD-WAN-mallissa toimipisteelle tarjotaan usein reititettävyys konesalin prefixeihin, sovellusverkkoihin tai hubiin. Varsinainen salliminen tai estäminen tapahtuu myöhemmin esimerkiksi konesalin NGFW:llä, ACL:llä tai muulla tietoturvakerroksella.

Tietoturva tulee usein tämän päälle erillisenä kontrollikerroksena. Palomuuri päättää, onko tietty lähde, kohde ja portti sallittu. IDS/IPS yrittää tunnistaa haitallista sisältöä tai hyökkäyskäyttäytymistä. Tämä malli voi olla tehokas, mutta se erottaa helposti kaksi asiaa toisistaan: Vanhassa arkkitehtuurissa "reititys päättää minne paketti voi mennä, palomuuri päättää saako se mennä"

Ongelma syntyy, kun verkossa on liian laajoja reittejä, liian väljiä sääntöjä tai vanhoja poikkeuksia. Silloin haittaohjelma, väärässä roolissa oleva käyttäjä tai kompromettoitu päätelaite voi usein ainakin yrittää yhteyksiä syvälle verkkoon. Palomuuri tai valvonta pysäyttää osan yrityksistä, mutta verkko on jo kuljettanut liikennettä kohti kohdetta.

SSR:n ero: palvelu ennen reittiä

Juniper SSR kääntää asetelman toiseen suuntaan. Sen ajattelussa verkon kiinnostava yksikkö ei ole pelkkä aliverkko, VLAN tai portti, vaan service: esimerkiksi SAP, DNS, identiteettipalvelu, tulostus, OT historian, admin jump host tai tietty SaaS-palvelu.

Service kuvataan verkon käyttäjälle merkitykselliseksi kohteeksi. Service voi olla laaja, kuten internet 0.0.0.0/0, tai hyvin tarkka, kuten tietty IP-osoite, protokolla ja portti. Lisäksi SSR:n service-policy määrittää, miten kyseisen palvelun liikennettä käsitellään ja mitä polkua pitkin se ohjataan.

Kun palvelu määritellään esimerkiksi näin:

  • Service: SAP-Production
  • Destination: 192.168.1.100–192.168.1.107
  • Protocol: TCP
  • Ports: SAPin hyväksytyt käyttäjäportit
  • Allowed tenant: SAP-Users
Sallittu SAP-liikenne muodostaa tenantti- ja palvelukohtaisesti rajatun istuntopolun. Tämä estää käyttäjäverkosta lähtevän satunnaisen skannauksen, sivuttaisliikkeen ja yhteydet muihin konesalipalveluihin. Jos esim haittaohjelma on laitteessa tai käyttäjäkontekstissa, joka ei ole autentikoitu SAP Users - ryhmään, se ei saa SSR:ssä SAP-palveluun tenantti-/service-polkua. Vaikka haittaohjelma olisi SAP käyttäjän PC:llä ja perinyt oikeudet, se ei silti pystyisi skannaamaan tai liikennöimään muilla protokollilla.

Tenantti ratkaisee, kenellä on reitti

SSR:n tenancy-malli on tässä keskeinen. Tenantti edustaa käyttäjä- tai laitejoukkoa, jolla on yhteinen policy. Tenantin jäsenille syntyy reitit tenantille julkaistuihin palveluihin, kun taas ei-jäsenillä ei ole näitä reittejä. Tämä on Zero Trust -verkkosegmentoinnin kannalta erittäin kiinnostavaa. Jos käyttäjä ei kuulu oikeaan tenanttiin, hänellä ei ole kyseiseen palveluun toimivaa reittiä. Tämä ei ole pelkkä “deny”-sääntö palomuurin lopussa, vaan lähtökohtaisesti kapeampi näkyvyys verkkoon.

SAP-esimerkki: älä avaa konesalia, julkaise palvelu

Perinteisessä MPLS WAN ja NGFW mallissa SAP-pyyntö kuulostaa usein tältä:

“Avataan toimiston lähde käyttäjäverkosta TCP 3200 SAP-palvelimelle.” (tai useimmiten "reititä tämä kohdeverkko konesaliin")

Zero Trust -mallissa sen pitäisi kuulostaa tältä:

“SAP-käyttäjäroolilla on pääsy SAP Production -palveluun. Muilla ei ole.”

Käytännön ketju voi olla esimerkiksi:

AD / Entra group: GG-ZTN-SAP-Users → Mist Access Assurance / NAC policy → 802.1X / EAP-TLS / käyttäjä- ja laitetunnistus → NAC role: SAP-User → access segment / VLAN → SSR tenant: T_SAP_USERS → allowed service: SVC_SAP_PRODUCTION

Tässä on tärkeä tarkennus: SSR ei ole yleensä se komponentti, joka “lukee AD-ryhmän” jokaisesta paketista. Identiteetti kannattaa ratkaista access-kerroksessa, esimerkiksi Mist Access Assurancella, RADIUSilla, NACilla, Entra/AD-integraatiolla ja laitesertifikaatilla. SSR enforceeraa lopputulosta tenantti- ja service-tasolla.

Tämän mallin hyöty on selkeä: SAPiin pääsy ei perustu siihen, että käyttäjä sattuu olemaan oikeassa toimipisteessä, oikeassa VLANissa tai “sisäverkossa”. Se perustuu siihen, että käyttäjä, laite ja rooli täyttävät ehdot ja että SSR:ssä on tälle roolille julkaistu SAP-palvelu.  SSR Tenant mallissa policy ei myöskään ole toimipistekohtainen, vaan Global policy.

“Pimeämpi” konesali

Konesalista tulee luvattomille käyttäjille ja laitteille vähemmän näkyvä. Jos tenantille ei ole julkaistu SAP-palvelua tai muuta konesalipalvelua, kyseinen liikenne ei saa SSR:n yli toimivaa palvelupolkua. Paketti ei kulje WANin yli vain siksi, että kohde-IP löytyy jostain laajasta konesaliprefixistä. Sen on vastattava julkaistua palvelua.

Tämä on iso ero verrattuna malliin, jossa käyttäjäverkolla on laaja reitti konesaliin ja vasta konesalin NGFW palomuuri päättää, mitä päästetään sisään yrittäen tunnistaa liikenteen seasta pahuudet.  SSR pienentää hyökkäyspintaa merkittävästi, koska luvattomille palveluille ei julkaista tenantti- tai service-kohtaista reittiä. Tämä on Zero Trust -ajattelun ydin: älä anna yleistä pääsyä verkkoon ja yritä myöhemmin erottaa hyvää pahasta. Anna vain se pääsy, jota oikeasti tarvitaan.

Realismi: internet, SNI ja IDS/IPS

SSR:n palvelukeskeinen malli ei poista kaikkia tietoturvatarpeita. Ensimmäinen realismikohta on Internet. Monessa yrityksessä luodaan ensimmäisenä laaja internet-palvelu, jossa lähes kaikki on sallittu.

  • Office Users --> Internet 0.0.0.0/0

Se on käytännöllistä, mutta samalla se laajentaa service-mallia. Internetistä tulee yksi suuri palvelu, jonka sisällä tarvitaan edelleen web-suojausta, URL filteringia, DNS-kontrolleja, endpoint-suojausta, käyttäjäkoulutusta ja valvontaa. Toinen realismikohta on sovellustunnistus.

SSR voi tunnistaa sovelluksia useilla tavoilla, kuten DNS/FQDN-pohjaisesti, TLS ClientHello/SNI-tiedon perusteella silloin kun se on näkyvissä, sekä module-pohjaisella application identificationilla. SNI-näkyvyyttä ei kuitenkaan pidä pitää arkkitehtuurin ainoana perustana, koska salatun liikenteen kehitys vähentää verkon passiivisesti näkemää metatietoa.

Kolmas realismikohta on IDS/IPS. Vaikka SSR:n palvelu- ja tenanttimalli pienentää hyökkäyspintaa, se ei korvaa kaikkia syväpuolustuksen kerroksia. Juniper tarjoaa SSR:ään Advanced Security Packin, johon kuuluu muun muassa IDS/IPS, URL filtering ja antivirus.

SSR alkuperäinen filosofia kuitenkin vähentää sitä liikennettä, jota IDS/IPS:n täytyy ylipäätään nähdä, koska luvattomille palveluille ei julkaista reittiä. IDS/IPS jää tärkeäksi defense-in-depth- ja compliance-kerrokseksi, mutta raskasta kaiken liikenteen seulomista ei tarvita.

Agent vs Agentless ZTN

Yksi SSR:n hyvistä argumenteista on agentless-luonne. Verkkotason segmentointi, tenantit, service-pohjainen pääsy ja session-aware forwarding eivät vaadi sitä, että jokaiseen päätelaitteeseen asennetaan erillinen SD-WAN-agentti.

Tämä on erityisen arvokasta ympäristöissä, joissa on useita käyttöjärjestelmiä, OT-laitteita, tulostimia, kameroita, jaettuja työasemia tai laitteita, joihin agenttia ei voida asentaa.

Juniper SSR:n WAN-segmentointi ja tenant-to-service-enforcement voidaan toteuttaa verkko- ja istuntotasolla ilman erillistä päätelaiteagenttia. Osa kilpailevista ZTNA-malleista taas nojaa vahvasti endpoint-agenttiin device posture-, SSO-, tunnelointi- ja näkyvyystiedon tuottamisessa. Agentless ei tarkoita, että päätelaitteen tietoturvaa ei tarvita. EDR, MDM/UEM, laitesertifikaatit ja NAC ovat edelleen tärkeitä. Agentless tarkoittaa tässä nimenomaan sitä, ettei SSR:n tenantti- ja service-pohjainen WAN-enforcement edellytä erillistä SD-WAN- tai ZTNA-agenttia jokaiseen laitteeseen

Paras käytännön malli: aloita SAPista

Hyvä ensimmäinen käyttötapaus on SAP. Älä yritä mallintaa heti kaikkia sovelluksia SSR-palveluiksi, jos verkko ei alunperin ole konfiguroitu ZTN edellä . Aloita yhdestä kriittisestä ja hyvin rajattavasta palvelusta. Testi on yksinkertainen:

  • SAP-ryhmään kuuluva käyttäjä hallitulla laitteella pääsee SAPiin.
  • Tavallinen toimistokäyttäjä ei saa SAPiin toimivaa service-reittiä.
  • Vieras, tulostin, IoT-laite tai kompromettoitu päätelaite ei peri SAP-pääsyä vain siksi, että se on samassa toimipisteessä.
  • Satunnainen skannaus konesalin muihin osoitteisiin ei liiku WANin yli, jos niitä ei ole julkaistu tenantille palveluina.

Tämä on Zero Trustia käytännössä: käyttäjä saa palvelun, ei verkkoa.

Yhteenveto

Perinteinen WAN kysyy usein ensin: “Mihin IP-osoitteeseen tämä paketti pitää reitittää?”

Zero Trust -henkinen SSR-malli kysyy ensin: “Kuka tätä palvelua pyytää, mihin tenanttiin hän kuuluu, ja onko kyseinen palvelu hänelle julkaistu?”

Tässä on Juniper SSR:n arkkitehtoninen ero. Se ei ole vain SD-WAN, joka kuljettaa paketteja eri tavalla. Se on tapa muuttaa reititys osaksi pääsynhallintaa.

Kun SAP, admin-yhteydet, OT historian, DNS, identiteettipalvelut ja muut kriittiset sovellukset määritellään palveluina eikä vain aliverkkoina, verkosta tulee vähemmän läpinäkyvä hyökkääjälle ja helpommin hallittava verkkomanagerille ja arkkitehdille.

Autan yrityksiä suunnittelemaan, valvomaan ja kehittämään verkkoarkkitehtuureja, joissa turvallisuus ei ole jälkikäteen lisätty palomuurisääntö, vaan osa itse verkon toimintalogiikkaa.

Hannu Rokka, Senior Advisor

5Feet Networks Oy