Pilvipalvelujen jaetun vastuun matriisi ISO-, NIS2- ja DORA-vaatimuksiin

Fintech-yhtiön operatiivinen johtaja soittaa tietoturvajohtajalle maanantaina klo 07.15.

Eurooppalainen pankkiasiakas pyytää todentavaa aineistoa siitä, että yhtiön SaaS-alusta pystyy täyttämään DORA:n kolmansien osapuolten ICT-riskejä koskevat vaatimukset. Myyntitiimi on jo lähettänyt tutun toimittajaturvallisuuden paketin: ISO-sertifikaatin, penetraatiotestin johdon yhteenvedon, kybervakuutustodistuksen, tietosuojaselosteen ja pilvipalveluntarjoajan varmennusraportin.

Pankki palaa asiaan täsmällisemmällä kysymyksellä:

“Osoittakaa, kuka omistaa kunkin kontrollin pilviympäristössänne: te, pilvipalveluntarjoajanne, hallinnoidun tietokannan tarjoajanne, identiteetintarjoajanne, lokitustoimittajanne ja mahdolliset alikäsittelijät. Esittäkää sen jälkeen todentava aineisto.”

Myöhemmin samana aamuna tietoturvajohtajalla on hallituksen kokous. Toimitusjohtaja kysyy saman asian liiketoiminnan kielellä: “Olemmeko varmoja, että tämä alusta on turvallinen, ja kuka on vastuussa, jos jokin menee vikaan?”

Tässä kohtaa moni pilvipalvelujen vaatimustenmukaisuusohjelma pysähtyy.

Organisaatiolla voi olla vahva pilvipalveluntarjoaja, hyvät työkalut, kohtuulliset politiikat ja riskirekisteri. Kun vastuurajoja pyydetään osoittamaan, todentava aineisto on kuitenkin hajallaan. Hankinnalla on sopimukset. Lakiasioilla on tietojenkäsittelysopimus (DPA). Suunnittelutiimillä on arkkitehtuurikaaviot. Tietoturvalla on lokit ja pilvikonfiguraatiot. Tietosuojalla on alikäsittelijäluettelo. Vaatimustenmukaisuudella on soveltuvuuslausunto. Kenelläkään ei ole yhtä hallittua dokumentoitua tietoa, joka kertoisi kontrolli kerrallaan, mitä palveluntarjoaja tekee, mitä asiakkaan on määritettävä, mikä alikäsittelijä on mukana, mikä lauseke tekee velvoitteen täytäntöönpanokelpoiseksi ja mitä todentavaa aineistoa auditoijan tulee odottaa.

Tämä dokumentoitu tieto on pilvipalvelujen jaetun vastuun matriisi.

Ei yleinen suurten pilvipalveluntarjoajien kalvo, jossa todetaan, että palveluntarjoaja turvaa pilven ja asiakas turvaa pilvessä olevan sisällön. Todellinen pilvipalvelujen jaetun vastuun matriisi ISO/IEC 27001:2022-, NIS2-, DORA- ja GDPR-vaatimuksiin on hallintajärjestelmän tallenne. Se kestää asiakkaan due diligence -arvioinnin, ISO-auditoinnin, DORA-tarkastelun, GDPR:n osoitusvelvollisuuteen liittyvän haasteen ja poikkeamatutkinnan.

Miksi pilvipalvelujen jaetusta vastuusta tulee auditointiongelma

Jaetun vastuun malli opetetaan yleensä teknisenä rajapintana. IaaS-mallissa palveluntarjoaja hallitsee fyysisiä toimitiloja, laitteistoa, virtualisointia ja keskeistä infrastruktuuria. Asiakas hallitsee identiteettejä, dataa, työkuormia, verkkosääntöjä, salausvalintoja ja konfiguraatioita. SaaS-mallissa palveluntarjoaja ottaa enemmän operatiivista vastuuta, mutta asiakas omistaa edelleen käyttäjäpääsyn, tiedonhallintamallin, oikeusperusteen, konfiguraation, seurantaan liittyvät odotukset ja poikkeamien eskaloinnin.

Tämä selitys on hyödyllinen, mutta riittämätön.

Auditoijat, viranomaiset ja yritysasiakkaat kysyvät muutakin kuin “kuka operoi kontrollia?” He haluavat tietää:

• Kuka on vastuussa riskistä?
• Mikä sopimuslauseke tekee tästä vastuusta täytäntöönpanokelpoisen?
• Mikä politiikka edellyttää kontrollia?
• Mikä pilvipalvelu, SaaS-alusta tai alikäsittelijä kuuluu soveltamisalaan?
• Mikä todentava aineisto osoittaa, että kontrolli toimi katselmointijakson aikana?
• Minkä viitekehyksen vaatimuksen todentava aineisto täyttää?
• Mitä tapahtuu, jos palveluntarjoaja muuttaa palveluaan, sijaintiaan, alihankkijaansa tai kontrolliensa tilaa?

ISO/IEC 27001:2022 ISO/IEC 27001:2022 tekee tästä johtamisjärjestelmäkysymyksen. Kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää sisäiset ja ulkoiset tekijät, sidosryhmät, lakisääteiset ja sopimusperusteiset velvoitteet, ISMS:n soveltamisalan, rajapinnat ja riippuvuudet. Kohdat 6.1.1–6.1.3 edellyttävät riskien arviointia, riskien käsittelyä, riskinomistajan hyväksyntää, jäännösriskin hyväksyntää ja soveltuvuuslausuntoa. Kohta 8.1 edellyttää operatiivista suunnittelua ja ohjausta, mukaan lukien ISMS:n kannalta merkityksellisten ulkoisesti tuotettujen prosessien, tuotteiden ja palvelujen hallinta.

Käytännössä tämä tarkoittaa, että jos pilvipalveluntarjoaja, SaaS-toimittaja tai alikäsittelijä tukee soveltamisalaan kuuluvaa liiketoimintaprosessia, se ei voi jäädä ISMS:n ulkopuolelle. Sen on näyttävä soveltamisalassa, riskissä, käsittelyssä, sopimusperusteisessa kontrollissa ja todentavassa aineistossa.

NIS2 nostaa vaatimustasoa. Article 21 edellyttää, että keskeiset ja tärkeät toimijat toteuttavat asianmukaiset ja oikeasuhtaiset tekniset, operatiiviset ja organisatoriset toimenpiteet, mukaan lukien riskianalyysi, poikkeamien käsittely, jatkuvuus, toimitusketjun turvallisuus, turvallinen hankinta, turvallinen kehittäminen, haavoittuvuuksien käsittely, vaikuttavuuden arviointi, kyberhygienia, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta sekä monivaiheinen todennus tai jatkuva todennus silloin, kun se on tarkoituksenmukaista. Article 20 asettaa hallinnointivastuun johtoelimille.

DORA on finanssialan toimijoiden osalta vielä täsmällisempi. Sitä sovelletaan 17. tammikuuta 2025 alkaen, ja se edellyttää, että finanssialan toimijat hallitsevat ICT-riskiä, merkittävien ICT:hen liittyvien poikkeamien raportointia, digitaalisen operatiivisen häiriönsietokyvyn testausta ja kolmansien osapuolten ICT-riskiä. Articles 28 to 30 edellyttävät kolmansien osapuolten ICT-riskien hallintaa, alustavaa keskittymäriskin arviointia, sopimusperusteisia suojatoimia, tarkastus- ja pääsyoikeuksia, alihankinnan läpinäkyvyyttä, irtisanomisoikeuksia ja irtautumisstrategioita.

GDPR lisää osoitusvelvollisuuden testin. Article 5 edellyttää, että henkilötietoja käsitellään eheästi ja luottamuksellisesti, ja Article 5(2) edellyttää, että rekisterinpitäjän on pystyttävä osoittamaan vaatimustenmukaisuus. Article 28 säätelee henkilötietojen käsittelijöiden sopimuksia ja alikäsittelijöitä. Article 32 edellyttää käsittelyn turvallisuutta. Articles 33 and 34 edellyttävät soveltuvin osin henkilötietojen tietoturvaloukkauksesta ilmoittamista.

Pilvipalvelujen jaetun vastuun matriisi toimii siltana näiden velvoitteiden välillä.

Clarysecin määritelmä: hallintajärjestelmän tallenne, ei kaavio

Clarysec-toimeksiannoissa pilvipalvelujen jaetun vastuun matriisi on hallittu ISMS-tallenne, joka yhdistää pilvipalvelut, toimittajat, alikäsittelijät, kontrollit, politiikat, sopimusvelvoitteet, todentavan aineiston ja auditointiodotukset.

Vahvin kuvaus löytyy Zenith Blueprint Zenith Blueprint -mallista, Controls in Action -vaiheen vaiheesta 23:

“Pilvipalveluntarjoajat turvaavat infrastruktuurin, mutta te olette edelleen vastuussa datastanne, konfiguraatioistanne, pääsynhallintakäytännöistänne ja valmiudestanne tietoturvapoikkeamiin reagointiin.”

Sama vaihe selittää, että pilvipalvelujen käyttöä on käsiteltävä osana ISMS:ää, mukaan lukien pilvipalvelujen luokittelu, käsiteltävän tai tallennettavan datan ymmärtäminen, palveluntarjoajan arviointi, sopimuslausekkeet ja palvelumuutosten hallinta. Tämä muuttaa jaetun vastuun käsitteen jäljitettäväksi kontrollirakenteeksi.

Zenith Controls Zenith Controls käsittelee ISO/IEC 27001:2022 liite A:n kontrolleja ja ISO/IEC 27002:2022 -ohjeistuksen kohtia 5.20, 5.21 ja 5.23 keskeisinä ankkureina:

• 5.20, tietoturvan käsittely toimittajasopimuksissa.
• 5.21, tietoturvan hallinta ICT-toimitusketjussa.
• 5.23, tietoturva pilvipalvelujen käytössä.

Nämä eivät ole irrallisia tarkistuslistakohtia. Ne muodostavat matriisin selkärangan.

Tukistandardit voivat vahvistaa matriisia. ISO/IEC 27017 auttaa pilvikohtaisissa tietoturvakäytännöissä. ISO/IEC 27018 ja ISO/IEC 27701 tukevat henkilötietojen ja tietosuojan hallintaa. ISO/IEC 27005 tukee riskien arviointia. ISO 22301 tukee jatkuvuutta ja häiriönsietokykyä. ISO/IEC 27035 tukee poikkeamien hallintaa. ISO/IEC 20000-1 voi auttaa tilanteissa, joissa pilvipalvelut ovat osa hallittua palveluntuotantoa.

Pienin toimiva jaetun vastuun matriisi

Kypsä matriisi ei ala 200 rivillä. Se alkaa tärkeimmistä pilvipalveluista.

SaaS-, fintech- tai säännellyssä pk-yritysympäristössä Clarysec aloittaa yleensä seuraavista:

1. Asiakasrajapinnan tuotannon pilviympäristö.
2. Identiteetintarjoaja.
3. Hallittu tietokanta- tai tallennuspalvelu.
4. Lokitus-, seuranta- ja SIEM-alusta.
5. Maksu-, KYC-, analytiikka- tai asiakastuen SaaS-palvelu.
6. Varmuuskopiointi- ja katastrofipalautuspalvelu.
7. Hallinnoitu palveluntarjoaja tai hallinnoitu tietoturvapalveluntarjoaja.
8. Alikäsittelijät, joilla on pääsy asiakasdataan tai jotka tallentavat tai käsittelevät sitä.

Ensimmäisen matriisin tulisi sisältää seuraavat sarakkeet.

Käytännön lokitusrivi voi näyttää tältä.

Tämä rivi ei ole pelkkää dokumentaatiota. Se kertoo tietoturvalle, mitä määrittää, hankinnalle, mitä sopimuskieltä tarkistaa, tietosuojalle, mikä tietovirta kirjata, ja auditoijille, mitä todentavaa aineistoa pyytää.

Politiikkaperusta: matriisista täytäntöönpanokelpoinen vaatimus

Pilvipalvelujen jaetun vastuun matriisi ilman politiikkatukea on vain taulukkolaskenta. Clarysecin politiikat tekevät siitä täytäntöönpanokelpoisen.

Pk-yrityksille Pilvipalvelujen käyttöpolitiikka - pk-yritys Pilvipalvelujen käyttöpolitiikka - pk-yritys, osio “Hallinnointivaatimukset”, lauseke 5.3 edellyttää:

“IT-palveluntarjoajan tai toimitusjohtajan on ylläpidettävä pilvipalvelurekisteriä. Siihen on kirjattava:”

Sama pk-yrityspolitiikka, lauseke 5.2.3, yhdistää pilvipalvelujen hallinnan tietosuojaan ja sijaintiriskiin:

“Tietojen sijainnin ja tietosuojakäytäntöjen on oltava sovellettavien lakisääteisten vaatimusten mukaisia (esim. GDPR)”

Yritysympäristöissä Pilvipalvelujen käyttöpolitiikka Pilvipalvelujen käyttöpolitiikka, osio “Hallinnointivaatimukset”, lauseke 5.1 toteaa:

“Organisaation tulee ylläpitää keskitettyä pilvipalvelurekisteriä, jonka omistaa tietoturvajohtaja ja joka sisältää:”

Lauseke 5.4 tekee pilvivastuista sopimusperusteisesti täytäntöönpanokelpoisia:

“Kaikkien CSP-sopimusten (Cloud Service Provider) tulee sisältää täytäntöönpanokelpoiset määräykset seuraavista:”

Toimittajahallinta laajentaa matriisin välitöntä palveluntarjoajaa pidemmälle. Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys, osio “Hallinnointivaatimukset”, lauseke 5.3.5 edellyttää:

“Rajoitukset jatkoalihankinnalle ilman hyväksyntää”

Sama pk-yrityksen toimittajapolitiikka lisää osiossa “Politiikan toteutusvaatimukset”, lausekkeessa 6.3.1 säännöllisen katselmoinnin:

“Kriittiset tai korkean riskin toimittajat tulee katselmoida vähintään vuosittain. Katselmoinnissa on tarkistettava:”

Yritystasolla Kolmansien osapuolten ja toimittajien tietoturvapolitiikka Kolmansien osapuolten ja toimittajien tietoturvapolitiikka, osio “Hallinnointivaatimukset”, lauseke 5.3 toteaa:

“Toimittajien kanssa tehtyjen sopimusten tulee sisältää:”

Henkilötietojen osalta Tietosuoja- ja yksityisyydensuojapolitiikka Tietosuoja- ja yksityisyydensuojapolitiikka, osio “Soveltaminen ja vaatimustenmukaisuus”, lauseke 8.5.1 edellyttää:

“Henkilötietojen käsittelijöiden kanssa tehtävien sopimusten tulee sisältää:”

Riippuvuusnäkyvyyttä varten Toimittajariippuvuuksien riskienhallintapolitiikka Toimittajariippuvuuksien riskienhallintapolitiikka, lauseke 6.5.4 edellyttää:

“Toimittajasuhdetta hyödynnetään alihankkijoita tai toimitusketjun riippuvuuksia koskevien päivitysten saamiseksi yhden tason verran alaspäin silloin, kun ne voivat vaikuttaa meihin (esimerkiksi jos kriittinen ohjelmistotoimittaja tukeutuu merkittävästi kolmannen osapuolen kirjastoon, tämä on kirjattava).”

Lokien osalta Lokitus- ja valvontapolitiikka - pk-yritys Lokitus- ja valvontapolitiikka - pk-yritys, osio “Hallinnointivaatimukset”, lauseke 5.5.1.3 antaa konkreettisen sopimusvaatimuksen:

“Sopimusten tulee edellyttää, että palveluntarjoajat säilyttävät lokit vähintään 12 kuukauden ajan ja antavat pääsyn niihin pyynnöstä”

Yhdessä nämä politiikat tekevät matriisista pakollisen hallintajärjestelmän tallenteen, joka tukee toimittajan hyväksyntää, pilvipalvelun käyttöönottoa, tietosuojan osoitusvelvollisuutta, vuosittaista katselmointia ja auditointinäyttöä.

Matriisin kartoitus ISO/IEC 27001:2022-, NIS2-, DORA- ja GDPR-vaatimuksiin

Klassinen virhe on luoda neljä erillistä vaatimustenmukaisuustyökirjaa. Yksi kontrolli voi täyttää useita velvoitteita, jos vastuu ja todentava aineisto ovat jäljitettävissä.

ISO/IEC 27001:2022 tarjoaa ISMS:n moottorin: toimintaympäristön, sidosryhmät, soveltamisalan, johtajuuden, riskien käsittelyn, tavoitteet, operatiivisen ohjauksen, suorituskyvyn arvioinnin ja parantamisen. Liite A tarjoaa käytännön kontrollirakenteen.

NIS2 Article 21 kytkeytyy luontevasti samaan matriisiin toimitusketjun turvallisuuden, poikkeamien käsittelyn, jatkuvuuden, pääsynhallinnan, omaisuudenhallinnan ja turvallisen hankinnan kautta. Article 20 tekee matriisista hallitukselle merkityksellisen, koska johtoelinten on hyväksyttävä kyberturvallisuuden riskienhallintatoimenpiteet ja valvottava niitä.

DORA muuttaa matriisin kolmansien osapuolten ICT-riskien työkaluksi. Articles 5, 6 and 8 edellyttävät hallinnointia, dokumentoitua ICT-riskien hallintaa sekä omaisuuserien, toimintojen ja riippuvuuksien tunnistamista. Articles 17 to 19 edellyttävät poikkeamien havaitsemista, luokittelua, eskalointia, viestintää ja raportointia. Articles 28 to 30 edellyttävät kolmansien osapuolten riskien hallintaa, keskittymäriskianalyysiä, sopimuslausekkeita, alihankinnan kontrolleja, auditointioikeuksia, irtisanomisoikeuksia ja irtautumisstrategioita.

GDPR tuo henkilötietonäkökulman. Jokaisen pilvipalvelurivin tulisi tunnistaa, käsitelläänkö henkilötietoja, onko palveluntarjoaja henkilötietojen käsittelijä vai alikäsittelijä, onko tietojen sijainnilla merkitystä ja mitä sopimus- tai DPA-todentavaa aineistoa on olemassa.

NIST CSF 2.0 auttaa viestimään saman matriisin tuloskielellä. GOVERN-toiminto käsittelee organisaation toimintaympäristöä, lakisääteisiä ja sääntelyvaatimuksia, riippuvuuksia, riskienhallintaa, rooleja, politiikkoja ja valvontaa. GV.SC-tulokset ovat erityisen hyödyllisiä toimittajien kyberriskien kannalta, mukaan lukien toimittajien roolit, kriittisyys, sopimusvaatimukset, due diligence, seuranta, poikkeamien koordinointi ja päättämissuunnittelu.

COBIT 2019 lisää varmennuksen ja hallinnoinnin näkökulman. Se kysyy, ovatko osoitusvelvollisuus, johtamiskäytännöt, omistajuus, seuranta ja havaintojen korjaaminen toistettavia ja todennettavissa.

Matriisin rakentaminen rekisteristä todentavaan aineistoon

Kuvitellaan SaaS-yhtiö, joka käyttää hyperscale-IaaS-alustaa, hallittua tietokantaa, kolmannen osapuolen identiteetintarjoajaa, asiakastuen SaaS-alustaa ja ulkoista SIEM-ratkaisua. Toteutuspolku on suoraviivainen.

Vaihe 1: Aloita pilvipalvelurekisteristä

Käytä Pilvipalvelujen käyttöpolitiikkaa tai Pilvipalvelujen käyttöpolitiikkaa - pk-yritys käynnistävänä vaatimuksena. Kirjaa jokainen pilvipalvelu, omistaja, käyttötarkoitus, tietoluokat, sijainti, liiketoimintatoiminto, toimittajataso, sopimusomistaja ja katselmointipäivä.

Jos palvelu tallentaa asiakastietueita, todennuslokeja tai tukitikettejä, merkitse se tietosuojan kannalta merkitykselliseksi. Jos se tukee tuotannon saatavuutta, merkitse se operatiivisesti kriittiseksi. Jos se tukee finanssiasiakkaan kriittistä tai tärkeää toimintoa, merkitse se DORA-relevantiksi.

Vaihe 2: Lisää jaetun vastuun osa-alueet

Määritä kullekin palvelulle vastuut keskeisillä osa-alueilla.

Vaihe 3: Yhdistä kontrollit riskiin ja soveltuvuuslausuntoon

Zenith Blueprint, Risk Management -vaiheen vaihe 13, selittää jäljitettävyysvaatimuksen:

“Ristiinviittaa sääntelyyn: jos tiettyjä kontrolleja toteutetaan nimenomaisesti GDPR-, NIS2- tai DORA-vaatimusten täyttämiseksi, voit kirjata tämän joko riskirekisteriin osana riskivaikutuksen perustelua tai SoA-huomautuksiin.”

Esimerkiksi riski “luvaton pääsy asiakkaan tuotantodataan pilvikonfiguraatiovirheen kautta” voi kytkeytyä pääsynhallintaan, pilvipalvelujen käyttöön, lokitukseen, kryptografiaan, haavoittuvuuksien hallintaan ja toimittajasopimuksiin. SoA voi viitata ISO/IEC 27001:2022 liite A:n kohtiin 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 ja 8.24 sekä huomautuksiin GDPR Article 32:sta, NIS2 Article 21:stä ja DORA:n ICT-riskien hallinnasta soveltuvin osin.

Vaihe 4: Liitä todentava aineisto ennen auditointikautta

Todentava aineisto tulee suunnitella osaksi matriisia, ei kerätä paniikissa.

Todentavan aineiston luettelo muuttaa vastuun näytöksi. Se auttaa myös kaupallisia tiimejä vastaamaan yritysasiakkaiden due diligence -arviointeihin nopeammin, koska ne voivat esittää sertifiointien lisäksi kontrollien omistajuuden ja toiminnan todentavan aineiston.

Alikäsittelijät: useimpien matriisien sokea piste

Alikäsittelijät ovat kohta, jossa jaetusta vastuusta tulee todellinen toimitusketjuriski.

SaaS-palveluntarjoaja voi olla GDPR:n mukainen henkilötietojen käsittelijänne. Kyseinen palveluntarjoaja voi tukeutua pilvipalvelun hosting-tarjoajaan, CDN-palveluun, analytiikkapalveluun, tukialustaan, sähköpostin toimituspalveluun, hallittuun tietokantaan, havainnointipalvelun tarjoajaan ja maksupalveluntarjoajaan. Osa niistä voi käyttää henkilötietoja. Osa voi tukea kriittistä palveluntuotantoa näkemättä dataa suoraan. Osa voi sijaita EU:n ulkopuolella. Osa voi olla korvattavissa. Toiset voivat aiheuttaa keskittymäriskiä.

DORA Article 29 edellyttää keskittymäriskin arviointia kriittisten tai tärkeiden ICT-palvelujen osalta, mukaan lukien korvattavuus, useat järjestelyt saman tai toisiinsa kytkeytyneiden palveluntarjoajien kanssa, alihankintaketjut, kolmansien maiden alihankkijat, maksukyvyttömyyslainsäädäntö, tietojen palautusrajoitteet ja unionin tietosuojavaatimusten täytäntöönpanokelpoisuus. DORA Article 30 edellyttää sopimusmääräyksiä alihankinnan ehdoista, sijainneista, tietojen käsittelystä ja säilytyksestä, pääsystä ja palautuksesta, poikkeama-avusta, viranomaisten kanssa tehtävästä yhteistyöstä, auditointioikeuksista, päättämisestä ja irtautumisesta.

NIS2 Article 21 edellyttää vastaavasti toimitusketjun turvallisuutta suorien toimittajien ja palveluntarjoajien osalta sekä toimittajakohtaisten haavoittuvuuksien, toimittajien kyberturvallisuuskäytäntöjen ja turvallisen kehityksen menettelyjen huomioon ottamista.

Siksi Clarysec käsittelee alikäsittelijöiden kartoitusta toimittajahallinnan pakollisena laajennuksena, ei pelkkänä tietosuojaluettelona. Alikäsittelijärekisterin tulee osoittaa, mikä toimittaja käyttää alikäsittelijää, mistä palvelusta se riippuu, käsitelläänkö henkilötietoja, tukeeko se kriittistä toimintoa, käsittelyalue soveltuvin osin, sopimusvelvoitteiden ketjutus, hyväksyntä- tai vastustamisoikeudet, saatavilla oleva varmennusaineisto, seurantamenetelmä ja irtautumisvaihtoehto.

Zenith Blueprint, Controls in Action -vaiheen vaihe 23 toteaa:

“Tunnista jokaisen kriittisen toimittajan osalta, käyttääkö se alihankkijoita (alikäsittelijöitä), joilla voi olla pääsy dataanne tai järjestelmiinne. Dokumentoi, miten tietoturvavaatimuksenne ketjutetaan näille osapuolille joko toimittajan sopimusehtojen tai omien suorien lausekkeidenne kautta.”

Tätä näyttötasoa auditoijat odottavat, kun he kysyvät, hallitaanko pilvivastuita myös ketjuuntuvien toimijoiden osalta.

Miten auditoijat testaavat samaa matriisia

Vahva pilvipalvelujen jaetun vastuun matriisi kestää useita auditointityylejä, koska se rakentuu omistajuuden, täytäntöönpanokelpoisuuden ja todentavan aineiston ympärille.

Matriisi ei ole päämäärä. Se on kartta, jonka avulla auditoijat testaavat, onko hallintajärjestelmä todellinen.

ISO-auditoija voi valita vaikutuksiltaan merkittävän pilvipääsyn riskin ja jäljittää sen riskirekisteristä SoA:han sekä edelleen käyttöoikeuskatselmointeihin, MFA-näyttöön ja seurantahälytyksiin. DORA-arvioija voi valita kriittisen ICT-palveluntarjoajan ja pyytää irtautumistestin, alihankinta-analyysin ja sopimusperusteiset auditointioikeudet. GDPR-tarkastelija voi keskittyä poistamiseen, tietojen sijaintiin, tietoturvaloukkauksen ilmoittamiseen ja alikäsittelijöiden läpinäkyvyyteen.

Yleiset epäonnistumismallit

Yleisimmät jaetun vastuun epäonnistumiset eivät ole eksoottisia.

Ensinnäkin organisaatiot tukeutuvat palveluntarjoajan varmennusraportteihin kartoittamatta niitä asiakkaan vastuisiin. Pilvipalveluntarjoaja voi osoittaa fyysisen turvallisuuden, infrastruktuurin häiriönsietokyvyn ja alustakontrollit, mutta ei sitä, oliko tallennussäiliönne yksityinen, olivatko IAM-roolit vähimmän oikeuden periaatteen mukaisia tai oliko lokit otettu käyttöön.

Toiseksi sopimuksissa on yleistä tietoturvakieltä, mutta ei poikkeamien aikarajoja, lokien käyttöoikeuksia, auditointioikeuksia, alihankinnan rajoituksia, tietojen palauttamista koskevia määräyksiä tai irtautumistukea. Zenith Blueprint, Controls in Action -vaiheen vaihe 23 korostaa tyypillisiä toimittajasopimusten alueita, kuten luottamuksellisuus, pääsynhallinta, tekniset ja organisatoriset toimenpiteet, poikkeamien aikarajat, auditointioikeus, alihankkijakontrollit ja sopimuksen päättymiseen liittyvät ehdot.

Kolmanneksi alikäsittelijät luetellaan tietosuojatarkoituksiin, mutta niitä ei yhdistetä turvallisuuteen, jatkuvuuteen tai keskittymäriskiin. Ketjuuntuva havainnointi- tai tukipalveluntarjoaja ei välttämättä näy riskirekisterissä lainkaan, vaikka sen katkos tai tietoturvaloukkaus voisi vaikuttaa asiakaspalvelun tuottamiseen.

Neljänneksi SoA toteaa kontrollin soveltuvaksi, mutta kukaan ei pysty tuottamaan operatiivista todentavaa aineistoa. Pilvilokitus voidaan merkitä toteutetuksi, mutta organisaatio ei pysty osoittamaan säilytysasetuksia, käyttöoikeuskatselmointeja, hälytysten käsittelyä tai palveluntarjoajan lokien käyttöoikeussitoumuksia.

Viidenneksi tietoturvapoikkeamiin reagointisuunnitelmat eivät huomioi palveluntarjoajariippuvuutta. Jos palveluntarjoaja ilmoittaa alustapoikkeamasta, kuka arvioi asiakasvaikutuksen? Kuka määrittää, onko NIS2-, DORA- tai GDPR-ilmoitus tarpeen? Kuka kontaktoi vaikutuksen kohteena olevia asiakkaita? Entä jos juurisyy on alikäsittelijällä?

Johdon osoitusvelvollisuus: miksi hallituksen tulisi välittää

NIS2 Article 20 edellyttää, että johtoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet, valvovat niiden toteutusta ja saavat koulutusta. DORA Article 5 edellyttää, että johtoelin määrittelee, hyväksyy ja valvoo ICT-riskienhallintajärjestelyjä sekä vastaa niistä, mukaan lukien kolmansien osapuolten ICT-politiikat, jatkuvuus- ja palautussuunnitelmat, auditointisuunnitelmat, koulutus ja raportointikanavat.

Tämä muuttaa matriisin tarkoitusta. Se ei ole enää vain tietoturvan työtaulukko. Siitä tulee todentava aineisto siitä, että johto tietää:

• Mitkä pilvipalvelut tukevat kriittisiä operaatioita.
• Mitkä kolmannet osapuolet ja alikäsittelijät ovat olennaisia.
• Mitkä velvoitteet soveltuvat asiakassopimusten, GDPR:n, NIS2:n ja DORA:n perusteella.
• Mitkä vastuut säilyvät organisaatiolla.
• Mitkä palveluntarjoajan sitoumukset ovat sopimusperusteisesti täytäntöönpanokelpoisia.
• Mitkä puutteet edellyttävät rahoitusta, korjaavia toimenpiteitä tai riskin hyväksymistä.

Pk-yrityksissä oikeasuhtaisuus on tärkeää. Pienempi toimija ei tarvitse raskasta byrokratiaa, mutta se tarvitsee silti dokumentaation, seurannan, häiriönsietokykyiset järjestelmät, ICT-riskilähteiden havaitsemisen, keskeisten kolmansien osapuolten riippuvuuksien tunnistamisen, jatkuvuustoimenpiteet, testauksen, opit ja säännöllisen katselmoinnin silloin, kun ne kuuluvat soveltamisalaan.

Matriisi on yksi tehokkaimmista oikeasuhtaisista työkaluista, koska se kokoaa velvoitteet yhteen sen sijaan, että se moninkertaistaisi ne.

30 päivän sprintti pilvimallin saattamiseksi auditointivalmiiksi

Jos ette pysty vastaamaan siihen, kuka omistaa kunkin pilvikontrollin, mikä todentava aineisto osoittaa sen ja mikä alikäsittelijä voisi vaikuttaa siihen, jaetun vastuun mallinne on edelleen kaavio, ei hallintajärjestelmän tallenne.

Käytännön 30 päivän sprintti näyttää tältä:

1. Luo tai päivitä pilvipalvelurekisteri Pilvipalvelujen käyttöpolitiikan tai Pilvipalvelujen käyttöpolitiikan - pk-yritys perusteella.
2. Tunnista kriittiset palvelut, henkilötietojen käsittely, asiakasrajapinnan järjestelmät sekä DORA- tai NIS2-relevanssi.
3. Rakenna ensimmäinen matriisi ISO/IEC 27001:2022 liite A:n kontrollien 5.20, 5.21 ja 5.23 ympärille Zenith Controls -mallin avulla.
4. Yhdistä jokainen rivi riskirekisteriin ja soveltuvuuslausuntoon Zenith Blueprint -mallin vaiheen 13 avulla.
5. Validoi toimittaja- ja henkilötietojen käsittelijälausekkeet käyttämällä Kolmansien osapuolten ja toimittajien tietoturvapolitiikkaa, Kolmansien osapuolten ja toimittajien tietoturvapolitiikkaa - pk-yritys ja Tietosuoja- ja yksityisyydensuojapolitiikkaa.
6. Lisää lokien säilytys, poikkeamien eskalointi, alikäsittelijöiden hyväksyntä, auditointioikeudet ja irtautumisnäyttö.
7. Katselmoi kriittiset toimittajat vuosittain sekä merkittävien muutosten, poikkeamien, uusien alikäsittelijöiden tai auditointihavaintojen jälkeen.

Tavoite on yksinkertainen. Kun asiakas, auditoija, viranomainen tai hallitus kysyy “kuka omistaa tämän kontrollin?”, ette etsi vastausta sopimuksista, tiketeistä ja kansioista. Avaatte matriisin, näytätte omistajan, näytätte lausekkeen, näytätte todentavan aineiston ja näytätte jäljen ketjuuntuville toimijoille.

Clarysec voi auttaa muuttamaan pilvipalveluntarjoajien varmennuspaketit integroiduksi jaetun vastuun matriisiksi ISO/IEC 27001:2022 -auditointeihin, NIS2-valmiuteen, DORA:n kolmansien osapuolten ICT-riskiin, GDPR:n osoitusvelvollisuuteen ja yritysasiakkaiden due diligence -arviointeihin.

Aloita rekisteristä. Rakenna matriisi. Liitä todentava aineisto. Käytä sitä sen jälkeen hallitukselle valmiina näyttönä siitä, että pilviriskiä ei ole ulkoistettu vaan sitä hallitaan.