Zero Trust -arkkitehtuuri 2026: auditointikelpoinen todentava aineisto

Maanantaiaamun Zero Trust -auditointi, jota kukaan ei suunnitellut

Maanantaina kello 08.12 eurooppalaisen SaaS-fintechin tietoturvajohtaja saa viiden minuutin sisällä kolme viestiä.

Ensimmäinen tulee pankkiasiakkaalta: ”Toimittakaa Zero Trust -arkkitehtuurianne koskeva todentavan aineiston paketti vuosittaista ICT-kolmannen osapuolen katselmointiamme varten.”

Toinen tulee lakiosastolta: ”Meidät saatetaan luokitella tärkeäksi toimijaksi NIS2:n mukaisesti yhdessä jäsenvaltiossa, ja osa asiakkaista kysyy, ulottuvatko DORA-velvoitteet meihin ICT-palveluntarjoajana.”

Kolmas tulee tuotekehitysjohtajalta: ”Meillä on MFA, SSO, EDR, Kubernetes-verkkopolitiikat ja SIEM-hälytykset. Onko se Zero Trust?”

Tähän moni organisaatio pysähtyy. Niillä on tietoturvatyökaluja, mutta ei Zero Trust -vaatimustenmukaisuuden toimintamallia. Ne voivat näyttää MFA-kuvakaappauksia, mutta eivät pysty selittämään, miten identiteetti, laitteen tietoturvatila, vähimmän oikeuden periaate, segmentointi, seuranta, poikkeamien ilmoittaminen, tietosuojan suojatoimet ja toimittajariippuvuudet liittyvät toisiinsa. Ne voivat näyttää kontrolleja, mutta eivät jäljitettävyyttä.

Vuonna 2026 NIST SP 800-207 -julkaisuun perustuvan Zero Trust -arkkitehtuurin on oltava enemmän kuin ”älä koskaan luota, varmista aina”. Tietoturvajohtajille, vaatimustenmukaisuuspäälliköille, auditoijille ja liiketoimintavastaaville käytännön kysymys on täsmällisempi:

Miten muutamme Zero Trustin todentavaksi aineistoksi, joka täyttää ISO/IEC 27001:2022 -vaatimukset, NIS2:n kyberhygieniaodotukset, DORA:n ICT-riskien hallinnan, GDPR Article 32:n käsittelyn turvallisuutta koskevat vaatimukset, asiakkaiden huolellisuusarvioinnit ja hallituksen valvontatarpeet?

Vastaus ei ole uusi työkalu. Vastaus on riskiperusteinen todentavan aineiston malli, joka yhdistää politiikat, kontrollit, teknisen toteutuksen, seurannan ja johdon vastuun.

Zero Trust vuonna 2026: tietoturvastrategiasta vaatimustenmukaisuuden todentavaan aineistoon

NIST SP 800-207 määrittelee Zero Trustin periaatejoukoksi turvallisten järjestelmien suunnitteluun ja käyttöön tilanteessa, jossa luottamus ei ole koskaan implisiittistä. Pääsy myönnetään identiteetin, kontekstin, politiikan, omaisuuserän tietoturvatilan ja jatkuvan arvioinnin perusteella.

NISTin seitsemän Zero Trust -periaatetta ovat erityisen hyödyllisiä, koska ne muuttavat epämääräisen tietoturvasloganin asiaksi, joka voidaan kartoittaa, testata ja auditoida:

1. Kaikki tietolähteet ja laskentapalvelut katsotaan resursseiksi.
2. Kaikki viestintä suojataan verkkosijainnista riippumatta.
3. Pääsy yksittäisiin organisaation resursseihin myönnetään istuntokohtaisesti.
4. Pääsy resursseihin määräytyy dynaamisen politiikan perusteella, mukaan lukien identiteetti-, laite-, sovellus- ja käyttäytymisattribuutit.
5. Organisaatio seuraa ja mittaa kaikkien omistamiensa ja niihin liittyvien omaisuuserien eheyttä ja tietoturvatilaa.
6. Kaikkien resurssien todennus ja valtuutus ovat dynaamisia, ja ne toteutetaan tiukasti ennen pääsyn sallimista.
7. Organisaatio kerää tietoa omaisuuseristä, infrastruktuurista ja viestinnästä ja hyödyntää sitä tietoturvatilansa parantamiseen.

Nykyaikaiselle SaaS-palveluntarjoajalle, digitaaliselle pankille, hallinnoidulle palveluntarjoajalle tai pilvinatiiville alustalle nämä periaatteet tarkoittavat käytännössä seuraavia kontrollialueita:

• Identiteetti todennetaan ja sitä hallinnoidaan.
• Laitteet arvioidaan ennen pääsyn myöntämistä.
• Etuoikeutettu pääsy minimoidaan ja katselmoidaan.
• Verkkopolut segmentoidaan ja niitä hallitaan.
• Sovellukset, ohjelmointirajapinnat ja tietovarastot toteuttavat valtuutuksen.
• Lokit ja telemetriatiedot tukevat jatkuvaa seurantaa.
• Poikkeamat käynnistävät rajaamisen, raportoinnin ja palautumisen.
• Todentava aineisto osoittaa, että kontrollit toimivat, eivät ainoastaan ole suunniteltuja.

Viimeinen kohta on se, jossa vaatimustenmukaisuus tulee mukaan.

ISO/IEC 27001:2022 edellyttää, että organisaatiot määrittelevät toimintaympäristönsä, sidosryhmänsä, sovellettavat lakisääteiset ja sopimusperusteiset vaatimukset, soveltamisalan, rajapinnat ja riippuvuudet. Se edellyttää myös riskien arviointia, riskien käsittelyä, soveltuvuuslausuntoa, johdon vastuun osoittamista, sisäistä auditointia, johdon katselmointia ja jatkuvaa parantamista.

Zero Trust sopii tähän rakenteeseen luontevasti, kun sitä käsitellään kontrollijärjestelmänä. Sen ei tule olla ISMS:n ulkopuolinen tekninen hanke. Sen tulee olla osa riskien arviointia, kontrollien valintaa, politiikkojen hallinnointia, toimittajahallintaa, tietosuojan suojaamista, tietoturvapoikkeamiin reagointia ja hallitusraportointia.

Zero Trust -todentavan aineiston taustalla oleva sääntelypaine

Zero Trust -todentavaa aineistoa koskeva paine syntyy yleensä päällekkäisistä velvoitteista, ei yhdestä yksittäisestä standardista.

NIS2 voi koskea julkisia tai yksityisiä toimijoita liitteen I tai liitteen II sektoreilla, jos ne täyttävät koko- ja toimintakynnykset, ja se voi koskea myös tiettyjä pienempiä mutta kriittisiä toimijoita. Liite I sisältää pilvipalveluntarjoajat, datakeskuspalveluntarjoajat, sisällönjakeluverkkopalveluntarjoajat, luottamuspalveluntarjoajat, hallinnoidut palveluntarjoajat, hallinnoidut tietoturvapalveluntarjoajat sekä pankki- ja rahoitusmarkkinainfrastruktuuritoimijat. Liite II sisältää digitaalisia palveluntarjoajia, kuten verkkomarkkinapaikkoja, hakukoneita ja sosiaalisen verkostoitumisen alustoja.

NIS2 Article 20 tekee kyberturvallisuudesta johdon vastuualueen. Hallituksen on hyväksyttävä kyberturvallisuusriskien hallintatoimenpiteet, valvottava niiden toteutusta ja saatava kyberturvallisuuskoulutusta. Article 21 edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, jotka kattavat riskianalyysin, poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, toimitusketjun turvallisuuden, turvallisen kehittämisen, haavoittuvuuksien käsittelyn, vaikuttavuuden arvioinnin, kyberhygienian, koulutuksen, kryptografian, henkilöstöturvallisuuden, pääsynhallinnan, omaisuudenhallinnan ja tarvittaessa MFA:n tai jatkuvan todennuksen. Article 23 ottaa käyttöön merkittävien poikkeamien vaiheittaisen raportoinnin, mukaan lukien 24 tunnin ennakkovaroituksen, 72 tunnin ilmoituksen ja loppuraportoinnin.

DORA-asetusta sovelletaan 17. tammikuuta 2025 alkaen, ja se luo yhtenäisen digitaalisen operatiivisen häiriönsietokyvyn järjestelmän rahoitusalan toimijoille. Se kattaa ICT-riskien hallinnan, merkittävien ICT-poikkeamien raportoinnin, operatiivisen häiriönsietokyvyn testauksen, uhkatietojen jakamisen ja ICT-kolmansien osapuolten riskit. DORA Articles 5 ja 6 edellyttävät hallinnointia ja dokumentoitua ICT-riskienhallinnan viitekehystä. Article 9 käsittelee suojausta ja ennaltaehkäisyä, mukaan lukien politiikat, menettelyt, protokollat ja työkalut ICT-järjestelmien suojaamiseksi. Article 17 edellyttää ICT-poikkeamien hallintaprosessia.

GDPR soveltuu käsittelyyn EU:ssa sijaitsevan toimipaikan yhteydessä sekä myös EU:n ulkopuolisiin rekisterinpitäjiin tai käsittelijöihin, jotka tarjoavat tavaroita tai palveluja EU:ssa oleville henkilöille tai seuraavat heidän käyttäytymistään. GDPR Article 5 edellyttää osoitusvelvollisuutta. Article 32 edellyttää asianmukaisia teknisiä ja organisatorisia toimenpiteitä riskitasoon nähden asianmukaisen turvallisuustason varmistamiseksi. Article 33 edellyttää henkilötietojen tietoturvaloukkauksesta ilmoittamista valvontaviranomaiselle ilman aiheetonta viivytystä ja mahdollisuuksien mukaan 72 tunnin kuluessa loukkauksen havaitsemisesta.

Zero Trust -todentavan aineiston malli auttaa, koska sama kontrolli voi tukea useita viitekehyksiä. MFA voi tukea ISO/IEC 27001:2022:n pääsynhallintaa, NIS2:n todennustoimenpiteitä, DORA:n suojausvaatimuksia ja GDPR:n käsittelyn turvallisuutta. Tämä kuitenkin edellyttää, että organisaatio pystyy osoittamaan soveltamisalan, omistajuuden, toteutuksen, seurannan ja katselmoinnin.

NIST Zero Trust -periaatteiden kytkeminen ISO/IEC 27001:2022 -kontrolleihin

ISO/IEC 27001:2022:n liitteen A kontrollit, joita ISO/IEC 27002:2022:n toteutusohjeet tukevat, tarjoavat auditointikielen, jota useimmat organisaatiot tarvitsevat. Alla oleva taulukko muuntaa NIST Zero Trust -periaatteet ISO-kontrollialueiksi, jotka auditoijat tunnistavat.

Tämä kartoitus ei ole pelkkä tekninen suunnitteluharjoitus. Siitä muodostuu riskirekisterin, soveltuvuuslausunnon, todentavan aineiston paketin ja johdon katselmoinnin asialistan rakenne.

Esimerkiksi riskiskenaario ”vaarantunut kehittäjätili muuttaa tuotantokoodia ja käyttää asiakastietoja” tulee kytkeä identiteetinhallintaan, MFA:han, etuoikeutettuun pääsyyn, verkkojen eriyttämiseen, lokitukseen, seurantaan, turvalliseen kehittämiseen, muutoksenhallintaan ja tietoturvapoikkeamiin reagointiin. Sama yksittäinen skenaario voi tukea ISO/IEC 27001:2022 -vaatimuksia, NIS2 Article 21:tä, DORA:n ICT-riskien hallintaa ja GDPR Article 32:ta.

Clarysecin Zero Trust -kontrollipino

Clarysec rakentaa Zero Trustin viiden todentavan aineiston osa-alueen ympärille: identiteetti, laite, verkko, sovellus ja data. Seuranta ja hallinnointi kattavat nämä kaikki viisi osa-aluetta.

Perustana ovat pääsynhallinta ja identiteetinhallinta. Zenith Controls: The Cross-Compliance Guide -oppaassa ISO/IEC 27002:2022 -kontrolli 5.15, Pääsynhallinta, luokitellaan ennaltaehkäiseväksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta, ja se kohdistuu Protect-kyberturvallisuuskonseptiin sekä identiteetin- ja pääsynhallintakyvykkyyteen. Kontrolli 5.16, Identiteetinhallinta, on myös ennaltaehkäisevä, ja se liittyy samoihin CIA-ominaisuuksiin ja IAM-kyvykkyyteen. Kontrolli 8.16, Seurantatoimet, luokitellaan havaitsevaksi ja korjaavaksi, ja se tukee Detect- ja Respond-toimintoja tietoturvatapahtumien hallinnan kautta.

Tällä yhdistelmällä on merkitystä. Zero Trust ei ole pelkkää pääsynhallintaa. Se on pääsynhallintaa sekä identiteetin elinkaarta, laitteen tietoturvatilaa, verkkojen eriyttämistä, seurantaa ja reagointia.

Clarysecin politiikan lausekkeet muuttavat tämän mallin toimeenpantavaksi hallinnoinniksi.

Enterprise Access Control Policy -politiikan Objectives-osiossa, lausekkeessa 3.4, todetaan:

Tukea Zero Trust -periaatteita estämällä pääsy oletusarvoisesti, ellei sitä ole nimenomaisesti hyväksytty ja perusteltu.

Enterprise User Account and Privilege Management Policy -politiikan Policy Implementation Requirements -osiossa, lausekkeessa 6.2.1, todetaan:

Kaikille käyttäjille on annettava vain vähimmäistasoinen pääsy, joka on tarpeen heidän työtehtäviensä suorittamiseksi.

Enterprise Network Security Policy -politiikan Governance Requirements -osiossa, lausekkeessa 5.2, todetaan:

Kaikkea vyöhykkeiden välistä liikennettä on hallittava palomuureilla tai ohjelmistomääritellyillä suojauskehäratkaisuilla, ja käytössä on oltava nimenomaiset oletusarvoisen eston konfiguraatiot.

Enterprise Logging and Monitoring Policy -politiikan Objectives-osiossa, lausekkeessa 3.4, todetaan:

Perustetaan keskitetyt lokitus- ja hälytysjärjestelmät (esim. SIEM), jotka kokoavat, korreloivat ja eskaloivat epäilyttävää toimintaa lähes reaaliaikaisesti.

Enterprise Information Security Policy -politiikan Policy Implementation Requirements -osiossa, lausekkeessa 6.6.1, todetaan:

Kaikkien toteutettujen kontrollien tulee olla auditoitavissa, dokumentoitujen menettelyjen tukemia ja toiminnan todentavan säilytetyn aineiston osoittamia.

Pk-yrityksissä sama hallinnointitarkoitus voidaan toteuttaa kevyemmällä politiikkadokumentaatiolla. User Account and Privilege Management Policy - SME -politiikan Objectives-osiossa, lausekkeessa 3.2, todetaan:

Toteutetaan vähimmän oikeuden periaate varmistamalla, että käyttäjille myönnetään vain heidän tehtäviensä suorittamiseen tarvittava vähimmäistasoinen pääsy.

Access Control Policy - SME -politiikan Governance Requirements -osiossa, lausekkeessa 5.4.3, lisätään:

Etuoikeutettujen tilien on käytettävä monivaiheista todennusta (MFA), kun se on tuettuna.

Network Security Policy - SME -politiikan Policy Implementation Requirements -osiossa, lausekkeessa 6.2.3, todetaan:

Segmenttien välinen liikenne on suodatettava, ja segmenttien välisen pääsyn on noudatettava vähimmän oikeuden periaatetta.

Logging and Monitoring Policy - SME -politiikan Purpose-osiossa, lausekkeessa 1.3, selitetään:

Lokitus ja seuranta tukevat uhkien havaitsemista, sääntelyvaatimusten noudattamista, poikkeamien ilmoittamista ja hallintaa sekä forensista analyysiä.

Tietosuojavetoisessa Zero Trustissa Data Protection and Privacy Policy - SME -politiikan Governance Requirements -osiossa, lausekkeessa 5.3.2, todetaan:

Käyttäjien pääsy henkilötietoihin on rajoitettava rooleihin, joilla on dokumentoitu liiketoimintatarve.

Nämä lausekkeet luovat auditoinnin ankkurit. Auditoija voi testata, estetäänkö pääsy oletusarvoisesti, minimoidaanko käyttöoikeudet, hallitaanko vyöhykkeiden välistä liikennettä, keskitetäänkö lokit ja säilytetäänkö todentava aineisto.

Zero Trust -todentavan aineiston kartta eri viitekehyksiin

Vahvan Zero Trust -todentavan aineiston mallin tulee välttää irrallisia kuvakaappauksia. Todentavan aineiston tulee osoittaa hallinnointi, suunnittelu, toteutus, seuranta ja katselmointi.

Tämä taulukko on hallituskelpoisen Zero Trust -ohjelman ydin. Se osoittaa, miten yksi kontrolliympäristö voi tukea useita varmentamistarpeita ilman erillisiä todentavan aineiston paketteja jokaiselle viitekehykselle.

Jäljitettävyyden rakentaminen Zenith Blueprintin avulla

Clarysecin Zenith Blueprint: An Auditor’s 30-Step Roadmap on suunniteltu estämään Zero Trustin muuttuminen dokumentoimattomaksi tekniseksi filosofiaksi. Riskienhallintavaiheen vaiheessa 13, Risk Treatment Planning and Statement of Applicability, siinä todetaan:

SoA on käytännössä siltadokumentti: se yhdistää riskien arvioinnin ja käsittelyn niihin
todellisiin kontrolleihin, jotka teillä on käytössä. Kun täytät sen, tarkistat samalla, onko jokin kontrolli jäänyt huomaamatta.

Sama vaihe suosittelee kontrollien kytkemistä riskeihin, liitteen A kontrolliviitteiden lisäämistä riskienkäsittelykirjauksiin ja sääntelyn, kuten GDPR:n, NIS2:n tai DORA:n, ristiviittaamista silloin, kun kontrollit on toteutettu näiden velvoitteiden täyttämiseksi.

Zero Trustissa tämä on puuttuva silta. Jos auditoija kysyy, miksi ehdollinen pääsy on toteutettu, vastauksen ei tule olla ”koska Zero Trust edellyttää sitä”. Parempi vastaus on:

• Riskiskenaario on luvaton pääsy asiakastietoihin vaarantuneiden tunnistetietojen kautta.
• Riskinomistaja on CTO tai tuotekehitysjohtaja.
• Käsittely sisältää SSO:n, MFA:n, ehdollisen pääsyn, päätelaitteen tilan validoinnin, vähimmän oikeuden periaatteen, segmentoinnin ja seurannan.
• SoA kytkee käsittelyn pääsynhallintaan, identiteetinhallintaan, lokitukseen, seurantaan, kryptografiaan, haavoittuvuuksien hallintaan ja pilvipalvelujen hallintaan.
• Sama käsittely tukee NIS2 Article 21:tä, DORA:n ICT-riskien hallintaa ja GDPR Article 32:ta.
• Todentava aineisto sisältää politiikan lausekkeet, käyttöoikeuskatselmoinnit, SIEM-hälytykset, EDR-tilaraportit, palomuurisäännöt, IAM-viennit, poikkeamaharjoitukset ja johdon katselmointipöytäkirjat.

Näin Zero Trust -arkkitehtuuri muuttuu auditointivalmiiksi.

Päätelaiteluottamus, ohjelmointirajapinnat ja verkkojen eriyttäminen käytännössä

Zero Trust epäonnistuu usein, koska organisaatiot keskittyvät identiteettiin ja sivuuttavat laitteen, työkuorman, datan ja verkon kontekstin.

Zenith Blueprint -oppaan vaihe 19, Technological Controls I, selittää päätelaitteen tilaa koskevan vaatimuksen selkeästi:

Pääsyn tietoihin päätelaitteiden kautta on oltava kontekstitietoista. Esimerkiksi: täyttääkö laite
vähimmäistietoturvavaatimukset ennen yrityksen resurssien käyttöä? Onko sille hiljattain tehty
haittaohjelmatarkistus? Yhdistetäänkö siihen epätavallisesta sijainnista tai verkosta? Kun Zero
Trust -periaatteet integroidaan, päätelaitteen tila voi syöttää tietoa ehdolliseen pääsyyn ja estää pääsyn, kunnes
laite osoittaa olevansa turvallinen.

Tämä tekee laitteesta osan valtuutuspäätöstä. Hallitsemattomalta kannettavalta tulevaa kelvollista salasanaa ei tule käsitellä samalla tavalla kuin vaatimustenmukaiselta, salatulta ja valvotulta yrityspäätelaitteelta tulevaa kelvollista kirjautumista.

Sama vaihe korostaa, että pääsyn rajoitukset koskevat sovelluksia, palveluja ja ohjelmointirajapintoja, eivät vain käyttäjiä:

Pääsyn rajoituksia tulee soveltaa myös sovelluksiin, palveluihin ja ohjelmointirajapintoihin, ei vain henkilöihin.
Esimerkiksi mikropalvelu voi tarvita vain lukuoikeuden tietokantatauluun, ei täysiä CRUD-
oikeuksia. Varmuuskopiointityökalu voi tarvita pääsyn vain tiettyihin tallennussäiliöihin, ei kaikkiin vuokraajan resursseihin.

Tämä ohjeistus on kriittistä pilvinatiiveissa ympäristöissä. Ohjelmointirajapintojen laajuuksien, palvelutilien, työkuormaidentiteettien, Kubernetes-roolien ja pilviympäristön IAM-politiikkojen on kaikkien noudatettava vähimmän oikeuden periaatetta. Ihmiskäyttäjien pääsy on vain yksi osa kontrollipintaa.

Zenith Blueprint -oppaan vaihe 20 käsittelee verkkojen eriyttämistä:

Eriyttäminen on yksi kyberturvallisuuden vanhimmista ja tehokkaimmista periaatteista: rajoita
leviämistä, vähennä riskiä ja rajaa vahinko. Kontrolli 8.22 keskittyy verkon
eriyttämiseen eli käytäntöön, jossa järjestelmät, palvelut ja käyttäjät erotetaan eri loogisiin tai
fyysisiin vyöhykkeisiin luvattoman pääsyn estämiseksi ja lateraalisen liikkumisen rajoittamiseksi
vaarantumistilanteessa.

Tämä on kriittistä DORA:n ja NIS2:n häiriönsietokyvyn kannalta. Zero Trust -verkon tulee olettaa, että yksi tili, työkuorma tai päätelaite voi vaarantua. Segmentointi estää paikallista tapahtumaa muuttumasta järjestelmätason poikkeamaksi.

10 päivän Zero Trust -todentavan aineiston paketti

Kuvitellaan SaaS-fintech, joka tuottaa petosanalytiikkaa pankeille. Se käsittelee henkilötietoja, käyttää pilvi-infrastruktuuria, tukeutuu hallittuun Kubernetes-palveluun, integroituu asiakkaiden ohjelmointirajapintoihin ja käyttää kolmannen osapuolen identiteetintarjoajaa. Asiakas pyytää Zero Trust -todentavaa aineistoa, ja yrityksellä on kymmenen työpäivää.

Käytännöllinen Clarysecin todentavan aineiston sprintti näyttäisi tältä.

Tavoitteena ei ole teeskennellä, että organisaatio olisi saavuttanut täydellisen Zero Trustin kymmenessä päivässä. Tavoitteena on luoda puolustettava todentavan aineiston ketju tärkeimmille riskeille ja osoittaa, että ohjelma on hallinnoitu, mitattava ja kehittyvä.

Miten eri auditoijat testaavat Zero Trustia

Yleinen virhe on valmistella yksi tekninen tarina ja olettaa, että kaikki auditoijat kysyvät samat kysymykset. He eivät kysy.

ISO/IEC 27001:2022 -auditoija tarkastelee hallintajärjestelmää. Hän kysyy, sisältyvätkö Zero Trust -riskit riskien arviointiin, onko käsittelyt hyväksytty, onko SoA täydellinen, ovatko politiikat hallittuja asiakirjoja, tehdäänkö käyttöoikeuskatselmointeja, testaavatko sisäiset auditoinnit kontrolleja ja seuraavatko johdon katselmoinnit suorituskykyä.

DORA-arvioija kysyy, ovatko Zero Trust -kontrollit osa dokumentoitua ICT-riskienhallinnan viitekehystä. Hän odottaa omaisuus- ja riippuvuusluetteloita, kriittisten tai tärkeiden toimintojen kartoitusta, poikkeamien luokittelua, hallitukselle eskalointia, testausta, kolmannen osapuolen sopimusvaatimuksia, auditointioikeuksia, exit-strategioita ja korjaavien toimenpiteiden seurantaa.

NIS2-arvioija keskittyy johdon vastuun osoittamiseen, Article 21:n kyberturvallisuusriskien hallintatoimenpiteisiin ja Article 23:n poikkeamien raportointivalmiuteen. Hän odottaa myös todentavaa aineistoa siitä, että toimitusketjun turvallisuutta, liiketoiminnan jatkuvuutta, haavoittuvuuksien käsittelyä, pääsynhallintaa ja kyberhygieniaa hallitaan.

GDPR-arvioija tai tietosuojan auditoija kysyy, onko pääsy henkilötietoihin tarpeellista, dokumentoitua, rajoitettua, seurattua ja käsittelyn tarkoituksiin yhdenmukaistettua. Hän tarkastelee rekisterinpitäjän ja käsittelijän rooleja, henkilötietojen tietoturvaloukkauksen havaitsemista, roolipohjaista pääsyä, salausta, pseudonymisointia tarvittaessa, säilytystä ja osoitusvelvollisuutta.

Sama kontrolli voi vastata useisiin kysymyksiin, mutta vain jos todentava aineisto on järjestetty.

Toimittaja-, pilvi- ja ICT-kolmansien osapuolten riskit

Zero Trust ei pääty palomuuriin, ja pilviympäristöissä perinteistä palomuurirajaa ei välttämättä ole lainkaan. Identiteetintarjoajat, pilvialustat, CI/CD-työkalut, hallitut havainnointipalveluntarjoajat, maksunkäsittelijät, API-yhdyskäytävät ja ulkoistetut kehitystiimit ovat kaikki osa luottamusrakennetta.

NIS2 Article 21 sisältää nimenomaisesti toimitusketjun turvallisuuden suorille toimittajille ja palveluntarjoajille, mukaan lukien toimittajien haavoittuvuudet, tuotteiden ja palvelujen häiriönsietokyky, toimittajien kyberturvallisuuskäytännöt ja turvallisen kehittämisen menettelyt.

DORA edellyttää, että ICT-kolmansien osapuolten riskiä hallitaan osana ICT-riskienhallinnan viitekehystä. Tähän sisältyvät ICT-palvelusopimusten rekisteri, sopimusta edeltävä huolellisuus, kriittisyyden arviointi, keskittymäriski, sopimusperusteiset tietoturvavaatimukset, poikkeama-avustus, viranomaisyhteistyö, auditointioikeudet, irtisanomisoikeudet, exit-strategiat ja siirtymäsuunnitelmat.

Zero Trustin käytännön sääntö on yksinkertainen: älä luota toimittajayhteyteen vain siksi, että se perustuu sopimukseen. Edellytä teknisiä kontrolleja ja todentavaa aineistoa.

Asiakas-API-integraatiossa tulee olla rajatut tokenit, nopeusrajoitukset, seuranta, kierto, omistajuus ja peruutusmahdollisuus. Hallinnoidun palveluntarjoajan tulee käyttää MFA:ta, nimettyjä käyttäjätilejä, vähimmän oikeuden periaatetta, istuntolokitusta ja aikarajoitettua käyttöoikeutta. Pilvipalveluntarjoajasuhteessa tulee olla jaetun vastuun kartoitus, salausmääritykset, lokien säilytys, varmuuskopioiden testaus ja exit-suunnittelu.

Siksi toimittaja- ja pilvitodentava aineisto kuuluu Zero Trust -mallin sisälle, ei erilliseen hankintakansioon.

Mittarit, jotka osoittavat Zero Trustin toimivan

Hallitukset ja auditoijat eivät halua pelkkiä arkkitehtuurikaavioita. He haluavat toiminnan todentavaa aineistoa ja parantumistrendejä.

Hyödyllisiä Zero Trust -mittareita ovat:

• MFA:lla suojattujen etuoikeutettujen tilien osuus.
• Ehdollisen pääsyn piirissä olevien käyttäjien osuus.
• Pysyvien etuoikeutettujen tilien määrä verrattuna just-in-time-tileihin.
• Myöhässä olevien käyttöoikeuskatselmointien määrä.
• Päätelaitteiden osuus, joka täyttää tietoturvatilaa koskevat vaatimukset.
• EDR-kattavuus kriittisissä omaisuuserissä.
• Evättyjen pääsyyritysten määrä laitteen tai sijainnin riskin vuoksi.
• Keskimääräinen aika epäilyttävän etuoikeutetun toiminnan havaitsemiseen.
• Keskimääräinen aika käyttöoikeuden peruuttamiseen työsuhteen päättämisen jälkeen.
• Viimeisen vuosineljänneksen aikana katselmoitujen vyöhykkeiden välisten palomuurisääntöjen osuus.
• Kriittisten toimittajien määrä, joilla on ajantasainen tietoturvanäyttö.
• Zero Trust -poikkeusten määrä, joiden korjauspäivä on ylittynyt.
• SIEM:iin lokeja lähettävien kriittisten sovellusten osuus.
• Tunnistetietojen vaarantumista koskevien poikkeamasimulaatioiden tulokset.

Nämä mittarit tukevat ISO/IEC 27001:2022:n jatkuvaa parantamista, NIS2:n vaikuttavuuden arviointia, DORA:n testaus- ja korjausodotuksia sekä GDPR:n osoitusvelvollisuutta.

Yleiset Zero Trust -todentavan aineiston puutteet

Yleisimmät puutteet eivät johdu työkalujen puutteesta. Ne johtuvat heikosta jäljitettävyydestä.

Ensinnäkin organisaatiot toteuttavat MFA:n, mutta eivät pysty osoittamaan, että etuoikeutetut tilit ovat täysin sen piirissä. Palvelutilit, break glass -tilit ja paikalliset ylläpitäjätilit jäävät usein kontrollin ulkopuolelle.

Toiseksi käyttöoikeuskatselmoinnit tehdään manuaalisesti, mutta niitä ei kytketä liiketoiminnallisiin rooleihin, tietojen arkaluonteisuuteen tai riskinomistajiin. Todentava aineisto osoittaa, että joku klikkasi ”katselmoitu”, ei sitä, että tarpeeton pääsy poistettiin.

Kolmanneksi verkon segmentointi on olemassa kaavioissa, mutta ei testatuissa säännöissä. Auditoijat kysyvät, estetäänkö segmenttien välinen pääsy oletusarvoisesti ja ovatko poikkeukset hyväksyttyjä.

Neljänneksi lokit kerätään, mutta ne eivät johda toimenpiteisiin. SIEM ilman määriteltyjä käyttötapauksia, hälytysten luokittelua ja reagointimenettelyjä ei osoita jatkuvaa seurantaa.

Viidenneksi toimittajien pääsy on hallitsematonta. Toimittajat voivat käyttää jaettuja tunnuksia, pysyvää VPN-pääsyä tai laajoja pilvirooleja ilman istuntojen valvontaa.

Kuudenneksi tietosuojan todentava aineisto on erotettu tietoturvan todentavasta aineistosta. GDPR edellyttää henkilötietojen suojan osoittamista, joten identiteetti- ja pääsynhallintakontrollit on kytkettävä tietoluokkiin ja käsittelytarkoituksiin.

Lopuksi poikkeuksia ei dokumentoida. Zero Trust voi sallia poikkeuksia, jos ne on riskinarvioitu, hyväksytty, aikarajoitettu ja seurattu. Se ei voi sallia näkymättömiä poikkeuksia.

Rakenna Zero Trust -todentavan aineiston paketti Clarysecin avulla

Zero Trust -arkkitehtuuri vuonna 2026 ei ole slogan. Se on vaatimustenmukaisuuden toimintamalli, joka yhdistää identiteetin, laitteet, sovellukset, verkon segmentoinnin, vähimmän oikeuden periaatteen, jatkuvan seurannan, toimittajakontrollin ja tietosuojan suojatoimet yhdeksi auditoitavaksi järjestelmäksi.

Jos valmistaudut ISO/IEC 27001:2022 -sertifiointiin, vastaat NIS2-asiakaskyselyihin, yhdenmukaistat toimintaasi DORA:n ICT-riskien hallinnan kanssa tai osoitat GDPR Article 32:n mukaisen käsittelyn turvallisuuden, aloita jäljitettävyydestä.

Käytä Zenith Blueprint: An Auditor’s 30-Step Roadmap -opasta Zero Trust -riskien kytkemiseen riskirekisteriin, riskienkäsittelysuunnitelmaan ja SoA:han. Käytä Zenith Controls: The Cross-Compliance Guide -opasta pääsynhallinnan, identiteetinhallinnan ja seurannan yhdenmukaistamiseen useiden viitekehysten odotusten kanssa. Käytä Clarysecin politiikkakirjastoa, mukaan lukien Enterprise Access Control Policy, Enterprise User Account and Privilege Management Policy, Enterprise Network Security Policy, Enterprise Logging and Monitoring Policy, Enterprise Information Security Policy ja Data Protection and Privacy Policy - SME, muuttaaksesi arkkitehtuurin toimeenpantavaksi hallinnoinniksi.

Seuraava käytännön askel on valita yksi korkean riskin skenaario, kuten etuoikeutetun pääsyn vaarantuminen asiakastietoihin, ja rakentaa sen ympärille täydellinen Zero Trust -todentavan aineiston ketju. Jos pystyt osoittamaan kyseisen skenaarion alusta loppuun, sinulla on perusta skaalautuvalle, auditoitavalle ja sääntelyvalmiille Zero Trust -ohjelmalle.

Lataa Clarysecin politiikkapaketit tai varaa strategiakeskustelu nähdäksesi, miten Zenith Blueprint ja Zenith Controls voivat muuttaa Zero Trustin auditointiriskistä vaatimustenmukaisuuseduksi.