Zero Trust käytännössä: miten järjestelmät käyttäytyvät, kun jokin menee pieleen

Suurin osa tietoturvakeskustelusta keskittyy siihen, miten hyökkääjät pidetään ulkona. Paljon harvemmin kysytään, mitä tapahtuu sen jälkeen, kun jokin on jo mennyt pieleen. Zero Trust ei pyri estämään jokaista virhettä. Sen ydin on järjestelmien suunnittelussa siten, että ne pysyvät vakaina myös silloin, kun epävarmuus astuu kuvaan.

Tietoturvapuhe alkaa lähes aina perimetristä. Huomio kohdistuu hyökkäysten estämiseen, järjestelmän ulkokuoren koventamiseen ja ensimmäisen murtautumisen todennäköisyyden pienentämiseen. Palomuurit, tunnistautumismekanismit, salatut yhteydet ja käyttöoikeuksien hallinta hallitsevat keskustelua. Kaikki tämä on välttämätöntä, mutta samalla se sivuuttaa hiljaisesti epämukavamman kysymyksen: mitä tapahtuu, kun jokin epäonnistuu silti?

Kokemus osoittaa, että epäonnistuminen ei ole poikkeus. Tunnuksia vuotaa, konfiguraatiot ajautuvat, riippuvuudet muuttuvat ja järjestelmät kehittyvät nopeammin kuin niiden alkuperäiset oletukset. Todellisissa ympäristöissä kysymys ei ole siitä, meneekö jokin vikaan, vaan milloin. Ratkaisevaa ei ole itse alkuperäinen virhe, vaan se, miten järjestelmä reagoi sen tapahduttua.

Tässä kohdassa perinteisten arkkitehtuurien ja Zero Trust -ajattelun välinen ero tulee näkyväksi. Ei iskulauseena eikä yksittäisenä tuotteena, vaan perustavanlaatuisesti erilaisena tapana, jolla järjestelmä käyttäytyy epävarmuuden vallitessa.

Kaksi tapaa ajatella luottamusta

Perinteiset järjestelmät rakentuvat yleensä yksinkertaisen ajatuksen varaan: vaara on ulkona, turvallisuus sisällä. Kun pyyntö on ylittänyt rajan – esimerkiksi VPN-yhteyden, onnistuneen tunnistautumisen tai sisäverkkoon pääsyn jälkeen – sitä pidetään laajasti luotettavana. Järjestelmä olettaa, että sisäinen toiminta on pääosin harmitonta ja että ylimääräiset tarkistukset vain hidastaisivat toimintaa.

Zero Trust lähtee toisesta lähtökohdasta. Se olettaa, että sijainti ei yksinään merkitse mitään, eikä aiemmin hyväksytty pyyntö automaattisesti oikeuta seuraavaa. Luottamus ei ole pysyvä tila. Se on päätös, joka tehdään toistuvasti kontekstin, tarkoituksen ja havaitun käyttäytymisen perusteella.

Tämä ero saattaa kuulostaa abstraktilta, mutta se muuttuu hyvin konkreettiseksi heti, kun jokin menee pieleen.

Realistinen lähtötilanne: yksi kompromettoitu tunnus

Kuvitellaan teknisesti varsin tavanomainen tilanne. Hyökkääjä saa haltuunsa yhden tunnuksen. Se voi olla sovellukseen upotettu API-avain, Kubernetes-klusterin service account -token tai käyttäjätili, jolla on rajatut oikeudet. Tämä ei vaadi poikkeuksellista osaamista tai harvinaisia haavoittuvuuksia. Tunnuksia vuotaa lokien, varmuuskopioiden, virheellisten asetusten ja arkipäiväisten operatiivisten virheiden kautta.

Tässä vaiheessa tapaus on vielä pieni. Yksi sisäänkäynti, yksi identiteetti, yksi jalansija. Se, mitä seuraavaksi tapahtuu, riippuu täysin siitä, miten järjestelmä on suunniteltu reagoimaan.

Mitä tapahtuu perinteisessä arkkitehtuurissa

Tavanomaisessa ympäristössä kyseinen tunnus hyväksytään pitkälti sellaisenaan. Jos se on teknisesti kelvollinen, järjestelmä sallii siihen liitetyt toiminnot. Nämä oikeudet ovat usein laajempia kuin ehdottoman tarpeellista, myönnetty aikanaan käytön helpottamiseksi ja harvoin myöhemmin tarkistettu. Vähitellen niistä tulee osa järjestelmän oletettua normaalia tilaa.

Kun hyökkääjä on sisällä, liikkuminen on usein vaivatonta. Sisäiset palvelut keskustelevat keskenään, koska ne jakavat verkon tai klusterin. Tietokannat hyväksyvät yhteydet, koska ne luottavat sisältä tuleviin pyyntöihin. Valvontajärjestelmät kirjaavat tapahtumia, mutta itse järjestelmä jatkaa toimintaansa ikään kuin mitään poikkeavaa ei tapahtuisi.

Hyökkääjän näkökulmasta tämä on ympäristö, joka palkitsee kärsivällisyyden. On aikaa tutkia, kokeilla mitkä yhteydet toimivat ja havainnoida komponenttien vuorovaikutusta. Eteneminen ei vaadi uusien suojien murtamista, vaan olemassa olevien polkujen seuraamista. Kaikki näyttää normaalilta, koska teknisesti se on sitä.

Määrittävä piirre on luottamuksen jatkuvuus. Kun luottamus on kerran myönnetty, se yleensä säilyy.

Zero Trust alkaa ensimmäisen virheen jälkeen

Zero Trust ei lupaa estää alkuperäistä tunnusvuotoa. Se ei väitä poistavansa inhimillisiä virheitä tai konfiguraation ajautumista. Sen arvo tulee esiin vasta ensimmäisen epäonnistumisen jälkeen.

Zero Trust -lähtöisessä järjestelmässä kompromettoitu tunnus ei automaattisesti avaa laajaa pääsyä. Jokainen kyseisellä identiteetillä tehty pyyntö arvioidaan kontekstissaan. Järjestelmä kysyy paitsi kuka pyynnön tekee, myös mitä pyydetään, minne pyyntö kohdistuu ja vastaako tämä käyttäytyminen odotettua.

Jos tälle yhdistelmälle ei ole nimenomaista lupaa, pyyntö epäonnistuu. Ei siksi, että hyökkäys olisi havaittu, vaan siksi, ettei mitään perustetta ole muodostettu. Etenemisestä tulee ehdollista automaattisen sijaan.

Tällä hienovaraisella muutoksella on merkittäviä seurauksia. Hyökkääjän etenemisreitti kapenee nopeasti. Avoimen tutkimisen sijaan vastaan tulee rajoja, jotka määräytyvät tarkoituksen, ajan ja laajuuden mukaan.

Kun havainnointi muuttaa käyttäytymistä

Keskeinen ero näiden mallien välillä liittyy siihen, miten järjestelmät reagoivat poikkeamiin. Perinteisissä ympäristöissä epätavallinen toiminta kirjataan usein vain myöhempää tarkastelua varten. Lokeja syntyy, hälytyksiä saatetaan laukaista, mutta järjestelmän operatiivinen käyttäytyminen pysyy muuttumattomana.

Zero Trust kohtelee havainnointia syötteenä, ei pelkkänä todisteena. Kun valvontajärjestelmät – usein keskitetyt loki- ja tapahtumankerääjät, kuten SIEM-alustat – havaitsevat käyttäytymistä, joka poikkeaa vakiintuneista malleista, tieto syötetään takaisin sääntelyn ja rajoittamisen mekanismeihin.

IF service=backend AND
   request_rate > baseline*5 AND
   destination not in allowed_service_map
THEN
   action = "tighten_policy_for_source"

Tämä ei edellytä täydellistä varmuutta. Järjestelmän ei tarvitse leimata toimintaa pahantahtoiseksi. Riittää, että epävarmuus tunnistetaan. Kun epävarmuus kasvaa, luottamus vähenee.

Käytännössä tämä näkyy usein verkkotasolla. Odottamattomasti käyttäytyvästä lähteestä tuleva liikenne voidaan rajata suppeampaan joukkoon kohteita. Yhteydet, jotka olivat teknisesti mahdollisia, eivät ole enää sallittuja, ellei niitä erikseen tarvita. Järjestelmä mukautuu ja kiristää asentoaan ilman ihmisen väliintuloa.

Toisin kuin perinteisissä ratkaisuissa, joissa poikkeamat elävät rinnakkain muuttumattoman pääsyn kanssa, Zero Trust mahdollistaa sen, että havainnointi muokkaa järjestelmän käyttäytymistä reaaliajassa.

Missä kontit tekevät eron näkyväksi

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      automountServiceAccountToken: false
      containers:
        - name: app
          image: example/app:1.0.0
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            allowPrivilegeEscalation: false

Kubernetes-ympäristöt havainnollistavat tätä eroa erityisen selkeästi, koska luottamus on niissä koodattu suoraan konfiguraatioon. Kubernetes ei itsessään ole Zero Trust -alusta, mutta se tarjoaa mekanismit Zero Trust -periaatteiden toteuttamiseen – tai sivuuttamiseen.

Tarkastellaan, mitä tapahtuu, kun hyökkääjä saa pääsyn käynnissä olevaan konttiin.

Monissa oletusasetuksissa kontin tiedostojärjestelmä on kirjoitettavissa. Prosessit ajetaan korotetuilla oikeuksilla kontin sisällä. Podien välinen verkkoliikenne on rajoittamatonta. Service account -tunnukset antavat automaattisesti pääsyn Kubernetes-APIin. Turvallisuuden näkökulmasta tämä heijastaa samaa oletusta kuin perinteisissä järjestelmissä: kerran sisällä, ympäristöön luotetaan.

Zero Trust -lähestymistapa kohtelee tätä toisin.

Kun kontin juuritiedostojärjestelmä liitetään vain luku -tilassa, järjestelmä ei enää oleta, että prosessin tulisi pystyä muuttamaan omaa ympäristöään. Vaikka hyökkääjä saisikin koodin ajoon kontin sisällä, hän ei voi asentaa lisätyökaluja, muuttaa sovelluksen binäärejä eikä luoda pysyvyyttä. Kaikki toiminta tapahtuu vain muistissa ja katoaa, kun pod käynnistyy uudelleen.

Konttien ajaminen ei-root-käyttäjinä vahvistaa tätä rajaa entisestään. Prosessia käsitellään sovelluksena, ei käyttöjärjestelmänä. Monet yleiset hyödyntämistekniikat epäonnistuvat yksinkertaisesti siksi, että tarvittavat oikeudet puuttuvat.

Verkkopolitiikat lisäävät vielä yhden kerroksen. Sen sijaan että oletettaisiin kaikkien podien voivan keskustella keskenään, liikenne sallitaan nimenomaisesti vain siellä, missä sitä tarvitaan. Kompromettoitu pod ei muutu koko klusterin ponnahduslaudaksi. Siitä tulee eristetty päätepiste, jonka ulottuvuus on rajallinen.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-ingress-from-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Verkkopolkujen rajaaminen riittää usein estämään lateraalisen liikkumisen palveluiden välillä, mutta se ei ratkaise toista yleistä eskalaatioreittiä: pääsyä ohjaustasoon itseensä. Kubernetes-ympäristöissä tämä tarkoittaa yleensä Kubernetes-APIa. Jos kompromettoitu pod pystyy tunnistautumaan API-palvelimelle, pelkkä verkkoeristys ei enää riitä. Hyökkääjä voi alkaa listata resursseja, lukea konfiguraatioita tai yrittää luoda uusia workloadeja.

Siksi Zero Trust -ajattelu ulottuu palveluiden välisen liikenteen ulkopuolelle ja kattaa myös workload-identiteetin sekä pääsyn ohjaustasoon.

apiVersion: v1

kind: Pod
metadata:
  name: job-no-k8s-api
spec:
  automountServiceAccountToken: false
  containers:
    - name: job
      image: example/job:1.0.0
      securityContext:
        runAsNonRoot: true
        readOnlyRootFilesystem: true

Myös pääsyä Kubernetes-APIin käsitellään varovaisesti. Podit, joiden ei tarvitse olla vuorovaikutuksessa ohjaustason kanssa, eivät saa siihen tarvittavia tunnuksia. Tämä poistaa kokonaan yhden yleisimmistä eskalaatiopolkuista.

Mikään näistä toimenpiteistä ei tee hyökkäyksistä mahdottomia. Ne tekevät niistä rajattuja.

Riskin muodon muuttaminen

Zero Trustin tärkein vaikutus ei ole ennaltaehkäisy, vaan muutos. Perinteisessä arkkitehtuurissa yksi virhe voi avata laajan ja pysyvän väärinkäytön reitin. Zero Trust -lähtöisessä järjestelmässä sama virhe johtaa kapeaan, väliaikaiseen ja hauraaseen mahdollisuuteen.

Hyökkääjän näkökulmasta ympäristö muuttuu vihamieliseksi hitaalle, systemaattiselle etenemiselle. Pääsyt vanhenevat. Reitit sulkeutuvat. Toiminta, joka poikkeaa odotetusta käyttäytymisestä, kaventaa vaihtoehtoja sen sijaan että laajentaisi niitä. Se, mikä olisi voinut olla huomaamatonta tutkimista, muuttuu kilpajuoksuksi aikaa ja näkyvyyttä vastaan.

Tämä ei ole turvallisuustakuu. Se on dynamiikan muutos.

Rehellinen lopetus

Zero Trust ei poista tietomurtoja. Se ei korvaa huolellista suunnittelua eikä kurinalaista operointia. Se ei lupaa täydellistä havaitsemista eikä ehdotonta kontrollia. Se tarjoaa erilaisen oletusreaktion epäonnistumiseen.

Perinteiset järjestelmät pyrkivät säilyttämään luottamuksen, ellei niitä erikseen ohjata toimimaan toisin. Zero Trust -järjestelmät tekevät päinvastoin. Kun varmuus murenee, luottamus supistuu.

Käytännössä tämä ero ratkaisee usein sen, jääkö tapaus rajatuksi häiriöksi vai kasvaako se järjestelmätason epäonnistumiseksi. Ei siksi, että Zero Trust olisi maaginen ratkaisu, vaan siksi, että se sovittaa järjestelmän käyttäytymisen siihen todellisuuteen, että monimutkaiset järjestelmät epäonnistuvat – ja että resilienssi alkaa siitä, miten ne reagoivat silloin, kun näin tapahtuu.