SaaS-tietoturvan tilan hallinta vuoden 2026 auditointeja varten

SaaS-auditointihavainto, jota kukaan ei omistanut

Tiistaina klo 08.15 nopeasti kasvavan fintech-yhtiön tietoturvajohtaja saa viestin tietosuojavastaavalta: ”Miksi asiakasvienti on julkisesti jaettavissa yhteistyövälineestä, ja kuka hyväksyi OAuth-sovelluksen, joka voi lukea sen?”

Klo 09.00 taloushallinto vahvistaa, että työkalu maksetaan osaston maksukortilla eikä keskitetyn hankinnan kautta. Klo 10.30 IT havaitsee, että julkisen linkin luonut käyttäjä lähti yhtiöstä kolme kuukautta sitten. Puoleenpäivään mennessä lakiosasto kysyy, onko kyseessä GDPR:n mukainen henkilötietojen tietoturvaloukkaus. Klo 14.00 riskikomitea kysyy, vaikuttaako asia NIS2-kyberhygieniaan ja DORA:n mukaiseen ICT-kolmannen osapuolen riskiin. Klo 16.00 sisäinen tarkastaja pyytää peruskonfiguraatioita, ylläpitäjien käyttöoikeuskatselmointeja, pilvipalvelun omistajuustietoja, lokeja ja toimittajan due diligence -aineistoa.

Kivulias totuus on, ettei organisaatio kärsinyt perinteisestä SaaS-palvelukatkoksesta tai toimittajan virheestä. Se kärsi hallintapuutteesta.

Tällainen tilanne ei ole enää poikkeuksellinen. Markkinointitiimi yhdistää AI-alustan CRM-järjestelmään laajoilla OAuth-oikeuksilla. Henkilöstöhallinto ostaa kapeaan tarpeeseen analytiikkatyökalun hankintaprosessin ulkopuolelta. Asiakastukitiimi sallii julkiset tikettiviennit käytännön syistä. Tuotekehitys integroi selainlaajennuksen kehitystyönkulkuun. Yksittäinen päätös voi tuntua pieneltä, mutta yhdessä ne muodostavat hajautuneen kontrollipinnan, jossa on sääntelyn alaisia tietoja, etuoikeutettuja työnkulkuja ja operatiivisia riippuvuuksia.

SaaS Security Posture Management eli SSPM on toimintamalli, joka muuttaa hajanaisen SaaS-todellisuuden hallituksi, testatuksi ja auditoitavaksi kontrollikokonaisuudeksi. Hyvin toteutettuna se antaa tietoturvajohtajille, vaatimustenmukaisuudesta vastaaville, auditoijille ja liiketoimintavastuullisille yhden yhtenäisen näyttöketjun ISO/IEC 27001:2022 -standardin, NIS2-kyberhygienian, DORA:n ICT-riskien ja GDPR:n tietoturvaa koskevan osoitusvelvollisuuden tueksi.

Clarysecin kanta on selkeä: SSPM:ää ei pidä käsitellä yhtenä lisämittaristona. Se tulee sisällyttää ISMS:ään, kytkeä riskinomistajuuteen, kartoittaa lakisääteisiin velvoitteisiin, tukea politiikoilla ja testata säännöllisellä näytöllä.

Tässä Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls ja Clarysecin politiikkamallit muuttuvat käytännöllisiksi. Ne auttavat muuttamaan SaaS-hajautumisen kontrollimalliksi, jonka auditoija ymmärtää ja jota hallintoelin voi valvoa.

Miksi SaaS Security Posture Managementista tuli vaatimustenmukaisuuskysymys

SaaS:ää käsiteltiin aiemmin ”ohjelmistona, jota joku muu käyttää puolestasi”. Tätä tulkintaa ei voi enää puolustaa.

NIS2:n nojalla monet pilvi-, SaaS-, digitaalisen infrastruktuurin, hallinnoitujen palvelujen ja hallinnoidun tietoturvan palveluntarjoajat voivat kuulua säänneltyjen kyberturvallisuusodotusten piiriin sektorin, koon, roolin ja kriittisyyden mukaan. Vielä tärkeämpää on, että SaaS:ään tukeutuvien organisaatioiden on hallittava sitä osana omia riskienhallintatoimenpiteitään. NIS2 Article 20 tekee hallintoelimistä vastuullisia kyberturvallisuusriskien hallintatoimenpiteiden hyväksymisestä, toteutuksen valvonnasta ja koulutuksen saamisesta. Article 21 edellyttää käytännön teknisiä, operatiivisia ja organisatorisia toimenpiteitä, kuten riskianalyysiä, politiikkoja, poikkeamien käsittelyä, liiketoiminnan jatkuvuutta, toimitusketjun turvallisuutta, turvallista hankintaa ja ylläpitoa, vaikuttavuuden testausta, kyberhygieniaa, kryptografiaa, henkilöstöturvallisuutta, käyttöoikeuksien hallintaa, omaisuudenhallintaa ja soveltuvin osin monivaiheista todennusta.

DORA nostaa vaatimustasoa edelleen finanssialan toimijoille. DORA on soveltunut 17. tammikuuta 2025 alkaen moniin finanssisektorin organisaatioihin soveltamisalaan kuuluvien toimijoiden operatiivisen häiriönsietokyvyn sääntelykehikkona. Se edellyttää ICT-hallintaa, ICT-omaisuuserien ja tuettujen toimintojen tunnistamista ja luokittelua, suojaavia ja ennalta ehkäiseviä kontrolleja, poikkeamien hallintaa, jatkuvuutta, testausta ja ICT-kolmansien osapuolten riskienhallintaa. Kriittisiä tai tärkeitä toimintoja tukevista SaaS-palveluntarjoajista tulee osa DORA-näytön rajapintaa, mutta säännelty finanssialan toimija säilyy vastuuvelvollisena.

GDPR lisää tietosuojan todentavan aineiston kerroksen. Article 5 edellyttää eheyttä, luottamuksellisuutta ja osoitusvelvollisuutta. Article 32 edellyttää asianmukaista käsittelyn turvallisuutta. Käytännössä organisaation tulee tietää, mitä henkilötietoja on olemassa, missä niitä käsitellään, kenellä on niihin pääsy, mitkä toimittajat niitä käsittelevät ja mitkä suojatoimet suojaavat niitä. SaaS-virhekonfiguraatio muuttaa nämä kysymykset kiireellisiksi loukkausarvioinnin kysymyksiksi.

ISO/IEC 27001:2022 toimii siltana. Kohdat 4.1–4.4 edellyttävät, että organisaatio määrittää toimintaympäristön, sidosryhmien vaatimukset, soveltamisalan, rajapinnat ja riippuvuudet. Kohta 5 edellyttää johtajuutta, politiikkaa, rooleja ja osoitusvelvollisuutta. Kohdat 6.1.1–6.1.3 edellyttävät riskien arviointia, riskien käsittelyä, soveltuvuuslausuntoa ja jäännösriskiä koskevia päätöksiä. Kohdat 8.1, 8.2 ja 8.3 edellyttävät operatiivista suunnittelua, riskien arviointia ja riskien käsittelyä. Kohdat 9 ja 10 edellyttävät seurantaa, sisäistä auditointia, johdon katselmointia ja parantamista.

Jos et pysty vastaamaan, mitkä SaaS-työkalut käsittelevät sääntelyn alaisia tietoja, kuka omistaa ne, miten ne on konfiguroitu, kenellä on ylläpitäjän käyttöoikeus, mitkä integraatiot ovat aktiivisia ja mikä näyttö osoittaa kontrollin toimivan, vaatimustenmukaisuusasemasi on hauras.

Clarysecin SSPM-malli: omaisuusluettelo, omistajuus, perustaso, näyttö

Clarysec käsittelee SaaS Security Posture Managementia toistettavana kontrollisilmukkana, ei kertaluonteisena siivousprojektina.

1. Tunnista jokainen SaaS-palvelu, myös varjo-SaaS.
2. Nimeä liiketoimintavastuullinen ja tekninen omistaja.
3. Luokittele tiedot, käyttäjät, integraatiot ja operatiivinen kriittisyys.
4. Ota käyttöön turvalliset peruskonfiguraatiot.
5. Katselmoi käyttäjät, ylläpitäjät, vieraat, palvelutilit ja OAuth-soveltamisalat.
6. Ota käyttöön lokitus, hälytykset ja säilytys.
7. Valvo julkista jakamista ja tietojen altistumista.
8. Sisällytä toimittajat, sopimukset, tietojenkäsittelysopimukset ja exit-suunnittelu.
9. Kerää näyttöä määritellyllä rytmillä.
10. Syötä havainnot riskien käsittelyyn, johdon katselmointiin ja parantamiseen.

Tämä malli on tiiviisti yhdenmukainen ISO/IEC 27002:2022 ISO/IEC 27002:2022 -kontrollien kanssa, erityisesti 5.9 tieto- ja muiden niihin liittyvien omaisuuserien luettelo, 5.15 pääsynhallinta, 5.18 käyttöoikeudet, 5.19 tietoturvallisuus toimittajasuhteissa, 5.20 tietoturvallisuuden käsittely toimittajasopimuksissa, 5.21 tietoturvallisuuden hallinta ICT-toimitusketjussa, 5.23 tietoturvallisuus pilvipalvelujen käytössä, 8.2 etuoikeutetut käyttöoikeudet, 8.3 tietoon pääsyn rajoittaminen, 8.9 konfiguraationhallinta, 8.15 lokitus, 8.16 valvontatoimet ja 8.32 muutoksenhallinta.

Zenith Blueprint toteaa Controls in Action -vaiheen organisaatiokontrolleja koskevassa Step 23:ssa:

Pilvi ei ole enää määränpää, vaan oletusarvo. Tallennuksesta yhteistyöhön, infrastruktuurista koneoppimiseen organisaatiot rakentuvat yhä useammin kolmansien osapuolten, abstraktoitujen ja etähallittujen ympäristökerrosten varaan. Control 5.23 tunnistaa tämän todellisuuden ja edellyttää, että tietoturvallisuus käsitellään nimenomaisesti pilvipalvelujen valinnassa, käytössä ja hallinnassa — ei jälkikäteen lisättynä ajatuksena, vaan suunnitteluperiaatteena alusta alkaen.

Tämä on SSPM:n ydin. Kyse ei ole vain virhekonfiguraatioiden havaitsemisesta jälkikäteen. Kyse on siitä, että SaaS-valinta, käyttöönotto, käyttö, valvonta ja exit-vaihe tehdään osaksi hallintajärjestelmää.

Sama Zenith Blueprint -osio selittää jaetun vastuun todellisuuden kielellä, joka jokaisen hallituksen jäsenen tulisi kuulla:

Pilvipalveluntarjoajat suojaavat infrastruktuurin, mutta olet edelleen vastuussa tiedoistasi, konfiguraatioistasi, pääsynhallintapolitiikoistasi ja valmiudestasi reagoida poikkeamiin. Virheellisesti konfiguroitu tallennussäiliö, julkisesti altistunut hallintanäkymä tai liian laajat käyttöoikeudet pilvi-IAM-määrityksissä eivät ole pilven vikoja. Ne ovat hallinnoinnin epäonnistumisia.

Palveluntarjoaja voi operoida alustaa, mutta sinä omistat edelleen tenant-konfiguraation, identiteetit, käyttöoikeuksien hyväksynnät, altistuneet tiedot, integraatiot, poikkeamien työnkulut ja vaatimustenmukaisuusnäytön.

5.23 on ankkuri, mutta SSPM tarvitsee kontrolliperheen

Zenith Controls luokittelee ISO/IEC 27002:2022 -kontrollin 5.23, tietoturvallisuus pilvipalvelujen käytössä, ennalta ehkäiseväksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Sen kyberturvallisuuskäsite on Protect, ja operatiivinen kyvykkyys liittyy toimittajasuhteiden turvallisuuteen sekä hallinnon, ekosysteemin ja suojauksen osa-alueisiin.

Tällä on merkitystä, koska SSPM ei ole yksittäinen kontrolli. Se on useiden kontrollien läpileikkaava toimintatapa.

Zenith Controls liittää 5.23:n 5.19:n mukaisiin toimittajasuhteisiin, koska SaaS-palveluntarjoajat ovat kriittisiä toimittajia, mutta 5.23 lisää SaaS-kohtaisia huolia, kuten moniasiakkuuden, tietojen sijainnin läpinäkyvyyden ja jaetun vastuun. Se liittää 5.23:n tietojen siirtoon, koska ohjelmointirajapinnat, integraatiot ja SaaS-palvelujen väliset työnkulut siirtävät tietoa jatkuvasti. Se liittää 5.23:n omaisuusluetteloon, koska organisaatiot tarvitsevat ajantasaista näkyvyyttä pilveen tallennettuihin tietoihin ja SaaS-resursseihin. Lisäksi se liittää pilvihallinnan valvontaan, pääsyn rajoittamiseen, konfiguraationhallintaan ja toimittajien valvontaan.

Käyttöoikeuksien osalta Zenith Controls kartoittaa 5.18:n 5.15 pääsynhallintaan, 5.16 identiteetinhallintaan, 5.3 tehtävien eriyttämiseen, 5.36 tietoturvapolitiikkojen, -sääntöjen ja -standardien noudattamiseen sekä 8.2 etuoikeutettuihin käyttöoikeuksiin. SSPM:n kannalta tämä tarkoittaa, että käyttöoikeuskatselmointi ei ole pelkkä taulukkolaskentaharjoitus. Se on operatiivinen näyttö siitä, että identiteetin elinkaari, vähimpien oikeuksien periaate, tehtävien eriyttäminen ja etuoikeutetun pääsyn hallinta toimivat SaaS-sovelluksissa.

Politiikkaperusta: määritä hyvä käytäntö ennen työkalujen hankintaa

Monet SaaS-epäonnistumiset alkavat siitä, että politiikkateksti on epämääräinen. ”Käytä hyväksyttyjä työkaluja turvallisesti” ei riitä. Clarysecin politiikat määrittävät täsmälliset odotukset rekisterille, pääsylle, lokitukselle, konfiguraatiolle ja toimittajakatselmoinnille.

Pk-yrityksille Pilvipalvelujen käyttöpolitiikka-sme Pilvipalvelujen käyttöpolitiikka - pk-yritys antaa käytännöllisen lähtökohdan. Kohdasta ”Hallintavaatimukset”, politiikkalauseke 5.3:

IT-palveluntarjoajan tai toimitusjohtajan tulee ylläpitää pilvipalvelurekisteriä. Siihen tulee kirjata: 5.3.1 Kunkin hyväksytyn pilvipalvelun nimi ja käyttötarkoitus 5.3.2 Vastuuhenkilö tai -tiimi (sovellusomistaja) 5.3.3 Tallennettujen tai käsiteltävien tietojen tyypit 5.3.4 Maa tai alue, jossa tiedot tallennetaan 5.3.5 Käyttäjien käyttöoikeudet ja ylläpitäjätilit 5.3.6 Sopimustiedot, uusimispäivät ja tukiyhteyshenkilöt

Tämä lauseke on SSPM:n operatiivinen ydin. Se antaa auditoijille ensimmäisen näyttökohteen: rekisterin, joka yhdistää SaaS-käytön omistajiin, tietoihin, maantieteelliseen sijaintiin, käyttöoikeuksiin ja sopimuksiin.

Sama Pilvipalvelujen käyttöpolitiikka-sme määrittää perustason asetukset kohdassa ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.2:

Tietoturvamääritysvaatimukset 6.2.1 Seuraavat on otettava käyttöön kaikilla pilvialustoilla: 6.2.2 Monivaiheinen todennus (MFA) ylläpitäjä- ja käyttäjätileille 6.2.3 Salasanojen monimutkaisuusvaatimukset (vähintään 10 merkkiä, ei uudelleenkäyttöä) 6.2.4 Toimintalokitus kirjautumisyrityksistä ja tietojen käytöstä 6.2.5 Pääsyn rajoitukset (esim. IP-sallittujen luettelo, jos tuettu) 6.2.6 Ylläpitäjän pääsy tulee rajata nimetyille henkilöille tai valtuutetuille tukipalveluntarjoajille. 6.2.7 Julkisesti jaettua sisältöä tulee seurata säännöllisesti tietovuodon estämiseksi. 6.2.8 Kun käyttäjätilit eivät enää ole tarpeen, pääsy tulee perua välittömästi ja mahdolliset jäljelle jäävät tiedot tulee katselmoida ja arkistoida tai poistaa.

Yritysympäristöissä Pilvipalvelujen käyttöpolitiikka Pilvipalvelujen käyttöpolitiikka määrittää vahvemman keskitetyn hallinnan. Kohdasta ”Hallintavaatimukset”, politiikkalauseke 5.3:

Jokaiselle pilvipalvelulle tulee nimetä palveluomistaja, joka vastaa tieto-omaisuuden elinkaaren hallinnasta, käytön hallinnasta, budjetin seurannasta ja jatkuvasta vaatimustenmukaisuuden seurannasta.

Tämä lause sulkee yleisen auditointiaukon. Jos kukaan ei omista SaaS-palvelua, kukaan ei omista konfiguraatiopoikkeamaa, käyttöoikeuksien uudelleensertifiointia, tietojen altistumista, uusimispäätöksiä, poikkeamayhteyshenkilöä tai exit-suunnittelua.

Myös käyttöoikeuksien hallinnan tulee olla nimenomaista. Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka-sme Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka - pk-yritys toteaa kohdassa ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.4:

Käyttöoikeuskatselmoinnit ja lokitus 6.4.1 Kaikkien käyttäjätilien ja käyttöoikeuksien katselmointi tulee suorittaa kuuden kuukauden välein. 6.4.2 Katselmointien aikana IT-vastaavan tulee validoida, onko kukin tili edelleen aktiivinen, tarpeellinen ja oikeilla käyttöoikeuksilla varustettu. 6.4.3 Tilien luonnin, tilien deaktivoinnin ja käyttöoikeusmuutosten lokit tulee säilyttää turvallisesti vähintään 12 kuukauden ajan.

SaaS-ympäristössä jokainen kriittinen alusta tarvitsee määritellyn käyttöoikeuskatselmointisyklin, vaikka alustaa hallinnoisi liiketoimintatiimi eikä keskitetty IT.

Myös lokituksen tulee olla nimenomaista. Lokitus- ja valvontapolitiikka-sme Lokitus- ja valvontapolitiikka - pk-yritys toteaa kohdassa ”Hallintavaatimukset”, politiikkalauseke 5.5:

Pilvipalvelut ja kolmannen osapuolen lokitus 5.5.1 Alustoilla, joissa lokitus ei ole suoraan IT:n hallinnassa (esim. SaaS-sähköposti), sovelletaan seuraavia vaatimuksia: 5.5.1.1 Lokitus tulee ottaa käyttöön ja konfiguroida, jos se on saatavilla 5.5.1.2 Hälytykset tulee ohjata IT-tukipalveluntarjoajalle 5.5.1.3 Sopimusten tulee edellyttää, että palveluntarjoajat säilyttävät lokit vähintään 12 kuukautta ja antavat niihin pääsyn pyynnöstä

Lopuksi SaaS-toimittajien hallinta tulee dokumentoida. Kolmansien osapuolten ja toimittajien tietoturvapolitiikka-sme Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys toteaa kohdassa ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.3:

Toimittajaturvallisuuden jatkuva seuranta 6.3.1 Kriittiset tai korkean riskin toimittajat tulee katselmoida vähintään vuosittain. Katselmoinnissa tulee varmistaa: 6.3.1.1 Turvallisten pääsymenetelmien jatkuva käyttö 6.3.1.2 Voimassa olevat tietoturvasertifioinnit tai päivitetty kontrollinäyttö 6.3.1.3 Poikkeamahistoria tai raportoidut ongelmat 6.3.1.4 Sopimuksenmukaisuus tietoturvalausekkeiden kanssa 6.3.2 Nämä katselmoinnit tulee dokumentoida ja säilyttää toimittajan tiedoissa. Jatkotoimet tulee seurata selkeästi. 6.3.3 Kun toimittajat hallinnoivat IT-infrastruktuuria tai sovelluksia, seuranta voi sisältää: 6.3.3.1 Auditointilokien pyytämisen 6.3.3.2 Tilitoiminnan katselmoinnin 6.3.3.3 Vahvistuksen siitä, ettei luvatonta pääsyä ole tapahtunut

Yhdessä nämä politiikat muuttavat SSPM:n tietoturvatavoitteesta sovellettavaksi toimintamalliksi.

30 päivän SSPM-näyttösprintti

Käytännönläheinen tietoturvajohtaja tai vaatimustenmukaisuudesta vastaava voi aloittaa 30 päivän näyttösprintillä. Valitse viisi SaaS-alustaa, jotka ovat tärkeimpiä sääntelyn alaisten tietojen tai kriittisten toimintojen kannalta. Tyypillisiä kohteita ovat Microsoft 365 tai Google Workspace, CRM, tikettijärjestelmä, HRIS, talousautomaatio, asiakastuki ja analytiikka.

Viikko 1: Luo SaaS-rekisteri

Käytä Pilvipalvelujen käyttöpolitiikka-sme -politiikan lausekkeen 5.3 kenttiä vähimmäisrekisterinä. Tallenna jokaisesta SaaS-palvelusta:

• Palvelun nimi ja liiketoimintatarkoitus
• Sovellusomistaja ja tekninen omistaja
• Tietotyypit, mukaan lukien henkilötiedot ja erityisiin henkilötietoryhmiin kuuluvat tiedot soveltuvin osin
• Tietojen tallennusmaa tai -alue
• Käyttäjäryhmät ja ylläpitäjätilit
• OAuth-sovellukset ja kolmannen osapuolen integraatiot
• Sopimusomistaja, uusimispäivä ja tukiyhteyshenkilö
• Operatiivinen kriittisyys
• Sovellettavat velvoitteet, kuten NIS2, DORA, GDPR tai asiakassopimukset

Tämä tukee ISO/IEC 27001:2022 -standardin kohtien 4.2 ja 4.3 vaatimuksia, koska sääntelyyn, sopimuksiin ja kolmansiin osapuoliin liittyvien riippuvuuksien tulee muokata ISMS:n soveltamisalaa. Se tukee myös DORA Article 8 -tyyppistä ICT-tuettujen liiketoimintatoimintojen, tietovarojen, ICT-omaisuuserien ja riippuvuuksien tunnistamista ja luokittelua.

Viikko 2: Määritä turvalliset peruskonfiguraatiot

Määritä kullekin valitulle SaaS-alustalle 10–15 perustason kontrollia.

• MFA toteutetaan kaikille käyttäjille ja ylläpitäjille mahdollisuuksien mukaan tietojenkalastelua kestävällä MFA:lla
• Ulkoinen jakaminen on oletusarvoisesti pois käytöstä tai rajattu hyväksyttyihin verkkotunnuksiin
• Julkiset linkit ovat pois käytöstä tai aikarajoitettuja
• Vierastilit katselmoidaan kuukausittain
• Ylläpitäjäroolit osoitetaan nimetyille henkilöille
• Legacy-todennus poistetaan käytöstä
• OAuth-sovellusten hyväksyntätyönkulku otetaan käyttöön
• Korkean riskin OAuth-soveltamisalat estetään tai ne edellyttävät tietoturvahyväksyntää
• Auditointilokitus otetaan käyttöön
• Tietojen vientioikeuksia rajoitetaan
• Säilytysasetukset yhdenmukaistetaan lakisääteisten ja liiketoimintavaatimusten kanssa
• API-tokenit katselmoidaan ja kierrätetään
• Tietoturvahälytykset ohjataan IT:lle tai SOC:lle
• Tiedonvuodon estämisen asetukset otetaan käyttöön, jos tuettu
• Break glass -tilit dokumentoidaan ja niitä valvotaan

Zenith Blueprint selittää Controls in Action -vaiheen Step 19:ssä, kontrolli 8.9 konfiguraationhallinta, miksi tällä on merkitystä:

Monet tietomurrot eivät johdu ohjelmistovirheistä, vaan huonoista konfiguraatiopäätöksistä. Oletussalasanoja jätetään vaihtamatta, turvattomia palveluja pidetään käytössä, tarpeettomia portteja jätetään auki tai järjestelmiä altistetaan internetiin ilman perustetta. Control 8.9 varmistaa, että jokainen järjestelmä rakennetaan turvalliseen peruskonfiguraatioon ja katselmoidaan säännöllisesti konfiguraatiopoikkeamien estämiseksi ajan mittaan.

SaaS-ympäristössä konfiguraatiopoikkeama voi tarkoittaa sitä, että liiketoimintavastuullinen sallii julkisen jakamisen, ylläpitäjä hyväksyy laajan kolmannen osapuolen pääsyn tai toimittaja muuttaa oletusasetuksia ominaisuusjulkaisun jälkeen.

Viikko 3: Katselmoi käyttöoikeudet ja integraatiot

Vie käyttäjät, ryhmät, ylläpitäjät ja yhdistetyt sovellukset. Vahvista kunkin ylläpitäjätilin osalta nimetty henkilö, liiketoimintaperuste, MFA-tila, viimeisin kirjautuminen, käyttöoikeustaso, varmistusten kattavuus, tehtävien eriyttämiseen liittyvät huolenaiheet ja hyväksyntänäyttö.

Vahvista OAuth-sovellusten ja integraatioiden osalta sovellusomistaja, käytetyt tiedot, pyydetyt käyttöoikeudet, toimittajariskin tila, viimeisin käyttöpäivä, jatkuva tarve sekä se, myönnettiinkö suostumus käyttäjän vai ylläpitäjän hyväksynnällä.

Zenith Blueprint antaa Controls in Action -vaiheen Step 19:ssä, kontrolli 8.3 tietoon pääsyn rajoittaminen, operatiivisen periaatteen:

Pääsyn tietoihin tulee olla niin avointa kuin tarpeen, mutta niin rajoitettua kuin mahdollista.

Tämä koskee paitsi ihmisiä myös sovelluksia, palveluja ja ohjelmointirajapintoja. Passiivinen OAuth-integraatio voi säilyttää pääsyn pitkään sen luoneen työntekijän tai projektin poistumisen jälkeen.

Viikko 4: Tuota auditointivalmis näyttö ja riskien käsittely

Tallenna jokaisesta SaaS-alustasta rekisterimerkintä, peruskonfiguraatio, kuvakaappaukset tai viennit keskeisten asetusten todentamiseksi, käyttöoikeuskatselmoinnin hyväksyntä, ylläpitäjäkatselmoinnin näyttö, OAuth-katselmoinnin näyttö, lokitus- ja hälytysnäyttö, toimittajaturvallisuuden katselmointitallenne, avoimet havainnot ja riskien käsittelytoimet.

Laadi tämän jälkeen yhden sivun johdon yhteenveto, jossa esitetään kriittiset havainnot, myöhässä olevat omistajat, ratkaisemattomat korkean riskin konfiguraatiopuutteet, hyväksymättömät integraatiot, lokitusaukot, poikkeukset ja tarvittavat päätökset. Tämä tukee ISO/IEC 27001:2022 -standardin kohdan 9.1 seurantaa, kohdan 9.2 sisäistä auditointia ja kohdan 9.3 johdon katselmointia. Se luo myös käytännön sillan NIS2 Article 20:n mukaiseen johdon vastuuvelvollisuuteen ja DORA:n hallintoelimen valvontaan.

Vaatimustenmukaisuuden poikkikartoitus: yksi SSPM-näyttöpaketti, monta velvoitetta

SSPM:n liiketoimintahyöty ei ole vain parempi tietoturva. Se vähentää vaatimustenmukaisuustyön päällekkäisyyttä.

NIS2 Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä. SaaS-omaisuusluettelo tukee omaisuudenhallintaa. Peruskonfiguraatiot tukevat kyberhygieniaa. MFA ja käyttöoikeuskatselmoinnit tukevat käyttöoikeuksien hallintaa. Lokitus tukee poikkeamien käsittelyä. Toimittajakatselmointi tukee toimitusketjun turvallisuutta. Näytön keruurytmi tukee politiikkoja ja menettelyjä vaikuttavuuden arviointiin.

DORA edellyttää, että finanssialan toimijat tunnistavat ja luokittelevat ICT-tuetut toiminnot, tietovarat, ICT-omaisuuserät ja kolmansien osapuolten riippuvuudet. Se edellyttää myös suojaavia ja ennalta ehkäiseviä toimenpiteitä, käyttöoikeuksien hallintaa, vahvaa tunnistautumista, salausta, jatkuvuutta, testausta, poikkeamien hallintaa ja ICT-kolmansien osapuolten riskien hallintaa. SaaS-SSPM-näyttöpaketti voi tukea DORA-rekistereitä, riippuvuuksien kartoitusta, sopimusvalvontaa, auditointioikeuksia ja exit-suunnittelua.

GDPR edellyttää, että rekisterinpitäjät osoittavat vaatimustenmukaisuuden eheyden, luottamuksellisuuden ja osoitusvelvollisuuden osalta. SaaS-rekisterit tunnistavat, missä henkilötietoja käsitellään. Peruskonfiguraatiot vähentävät luvatonta paljastumista. Käyttöoikeuskatselmoinnit tukevat vähimpien oikeuksien periaatetta. Lokitus tukee loukkauksen tutkintaa. Toimittajatallenteet tukevat käsittelijöiden hallintaa ja osoitusvelvollisuutta.

NIST CSF 2.0 lisää hyödyllisen viestintäkerroksen. Sen GOVERN-toiminto edellyttää, että lakisääteiset, sääntelyyn liittyvät ja sopimusperusteiset kyberturvallisuusvaatimukset ymmärretään ja niitä hallitaan. Sen toimitusketjutulokset edellyttävät toimittajarooleja, sopimuksia, huolellisuutta, seurantaa ja suhteen päättymisen jälkeisiä toimia. Sen IDENTIFY-, PROTECT-, DETECT-, RESPOND- ja RECOVER-toiminnot yhdistyvät luontevasti SaaS-omaisuusluetteloon, käyttöoikeuksien hallintaan, tietosuojaan, lokitukseen, tietoturvapoikkeamiin reagointiin ja toipumiseen.

COBIT 2019 - ja ISACA-lähtöiset auditoijat lähestyvät SSPM:ää yleensä hallinnon, johtamistavoitteiden, riskinomistajuuden, kontrollien toiminnan ja varmennuksen kautta. He kysyvät, ovatko SaaS-päätökset yhdenmukaisia organisaation tavoitteiden kanssa, onko riskivastaukset dokumentoitu, onko vastuut osoitettu ja osoittavatko varmennustoimet kontrollien toiminnan.

Auditoinnin näkökulma: miten eri auditoijat testaavat SaaS-tietoturvan tilaa

Vahva SSPM-ohjelma kestää erilaiset auditointityylit, koska se tuottaa näyttöä oikealla tasolla.

ISO/IEC 27001:2022 -auditoija aloittaa soveltamisalasta, sidosryhmistä, riskien arvioinnista, soveltuvuuslausunnosta ja operatiivisesta näytöstä. Jos kontrolli 5.23 sisältyy soveltamisalaan, hän odottaa näyttöä pilvipalvelujen valinnasta, käytöstä, hallinnasta ja exit-vaiheesta. Jos käyttöoikeuskontrollit sisältyvät soveltamisalaan, hän ottaa käyttäjäotoksia ja kysyy, näkyvätkö aloittajien, siirtyjien ja lähtijöiden muutokset SaaS-käyttöoikeuksissa.

DORA-arvioija keskittyy kriittisiin tai tärkeisiin toimintoihin, ICT-kolmansien osapuolten riippuvuuksiin, rekisterin täydellisyyteen, sopimuksiin, poikkeamien luokitteluun, testaukseen ja exit-suunnitteluun. Jos SaaS-alusta tukee maksutoimintoja, asiakkaan perehdytystä, kaupankäyntiä, riskianalytiikkaa tai asiakasviestintää, näyttövaatimus kasvaa.

GDPR-auditoija tai tietosuojan arvioija kysyy, missä henkilötietoja säilytetään, kenellä on niihin pääsy, mitä vienti- ja jakamisasetuksia on olemassa, hallinnoidaanko käsittelijöitä, tukevatko lokit loukkausarviointia ja ovatko kontrollit oikeassa suhteessa riskiin.

Toimittajariski, jaettu vastuu ja valmius poikkeamatilanteisiin

SSPM alkaa usein konfiguraatiosta, mutta siihen se ei voi päättyä. SaaS on myös toimittajariskiin ja poikkeamatilannevalmiuteen liittyvä kysymys.

DORA edellyttää, että finanssialan toimijat ylläpitävät ICT-palvelusopimusten rekistereitä, erottavat kriittisiä tai tärkeitä toimintoja tukevat järjestelyt, arvioivat keskittymäriskiä, arvioivat palveluntarjoajan soveltuvuutta ja ylläpitävät exit-strategioita. Sopimuksissa tulisi käsitellä palvelukuvauksia, tietojen sijaintia, saatavuuden, aitouden, eheyden ja luottamuksellisuuden suojaamista, pääsyä tietoihin, palautusta ja palauttamista, poikkeamatukea, yhteistyötä viranomaisten kanssa, päättämisoikeuksia, tietoturvavaatimuksia, auditointioikeuksia ja siirtymätukea.

NIS2 Article 21 sisältää myös toimitusketjun turvallisuuden ja edellyttää, että toimijat huomioivat suoriin toimittajiin ja palveluntarjoajiin liittyvät haavoittuvuudet, tuotteiden laadun ja toimittajien kyberturvallisuuskäytännöt.

Käytännössä kriittisen SaaS-palvelun katselmoinnin tulisi yhdistää tietoturvakyselyn näyttö, sopimuskatselmointi, tietojenkäsittelysopimuksen tila, poikkeamahistoria, palvelutasositoumukset, pääsy lokeihin, auditointiraportit, konfiguraationäyttö ja exit-vaiheen toteuttamiskelpoisuus.

Jaetun vastuun aukko syntyy, kun tiimit olettavat toimittajan sertifioinnin kattavan tenant-konfiguraation. Se ei kata. Toimittaja voi operoida turvallista alustaa samalla, kun asiakas sallii julkisen jakamisen, jättää käyttämättömät ylläpitäjätilit aktiivisiksi tai myöntää liian laajoja API-soveltamisaloja. SSPM sulkee tämän aukon.

Poikkeamatilannevalmius on yhtä tärkeää. NIS2:n merkittävien poikkeamien raportointi sisältää 24 tunnin ennakkovaroituksen, 72 tunnin ilmoituksen ja loppuraportin viimeistään kuukauden kuluttua 72 tunnin ilmoituksesta. DORA edellyttää ICT:hen liittyvien poikkeamien hallintaa, joka kattaa havaitsemisen, kirjaamisen, luokittelun, eskaloinnin, viestinnän ja ilmoittamisen. GDPR:n henkilötietojen tietoturvaloukkauksen arviointi riippuu myös siitä, että ajoissa ymmärretään, mitä tapahtui, mihin tietoihin vaikutettiin ja keihin vaikutus kohdistui.

Jos epäilyttävä OAuth-sovellus käytti asiakastiedostoja, sinun tulee tietää, milloin sovellus valtuutettiin, kuka käyttäjä sen valtuutti, mitkä soveltamisalat myönnettiin, mitä tietoja käytettiin, ladattiinko tai jaettiinko tietoja, keihin käyttäjiin tai asiakkaisiin vaikutus kohdistui, onko pääsy edelleen aktiivinen ja mitä rajaamistoimia tehtiin.

Ilman lokitusta ja säilytystä organisaatio voi joutua tekemään pahimman tapauksen oletuksia. Tämä lisää oikeudellista altistusta, asiakasviestinnän painetta ja sääntelyyn liittyvää epävarmuutta. Jos SaaS-palveluntarjoaja veloittaa erikseen auditointilokeista, riskinomistajan tulee nimenomaisesti hyväksyä jäännösriski tai hyväksyä tarvittava lisenssitaso. Tämä päätös kuuluu riskienkäsittelytallenteeseen ja johdon katselmointiin.

Yleiset SSPM-epäonnistumismallit

Samat epäonnistumismallit toistuvat eri toimialoilla.

Ensinnäkin varjo-SaaS havaitaan laskuista, selainhistoriasta tai SSO-lokeista eikä hankinnasta. Korjaus ei ole pelkkä työkalujen estäminen. Tarvitaan kevyt käyttöönottoprosessi, jota liiketoimintatiimit voivat käyttää.

Toiseksi SaaS-omistajuus on epäselvä. CRM on ”myynnin omistama”, mutta kukaan myynnissä ei osaa selittää ylläpitäjärooleja, API-tokeneita, tietojen vientiä tai säilytysasetuksia. Nimeä sovellusomistajat ja tekniset omistajat erikseen.

Kolmanneksi käyttöoikeuskatselmoinnit ovat liian yleisluonteisia. Katselmoija hyväksyy ”kaikki käyttäjät” tarkistamatta korkean riskin rooleja, passiivisia käyttäjiä, vieraita, ulkoisia yhteistyökumppaneita tai palvelutilejä. SSPM-käyttöoikeuskatselmoinnin tulee olla riskiperusteinen.

Neljänneksi OAuth-sovellukset jätetään huomiotta. Monet organisaatiot katselmoivat henkilö käyttäjiä mutta eivät sovellusten välisiä käyttöoikeuksia. Modernissa SaaS-ympäristössä integraatiot voivat olla tehokkaampia kuin käyttäjät.

Viidenneksi peruskonfiguraatiot ovat olemassa vain sertifiointiprojektin kuvakaappauksina. Niitä ei seurata konfiguraatiopoikkeamien varalta. Yhdenmukaista SSPM konfiguraationhallinnan kanssa, jotta perustason tarkistuksista tulee toistuvaa näyttöä.

Kuudenneksi toimittajakatselmointi ja SaaS-tilan katselmointi ovat erillään. Hankinnalla on sopimus, IT:llä on hallintakonsoli, tietosuojalla on tietojenkäsittelysopimus ja tietoturvalla on riskirekisteri. Auditoija näkee sirpaleita. SSPM kokoaa ne yhteen.

Johdon raportointi: tee SaaS-riskistä näkyvä hallitukselle

NIS2 ja DORA tekevät ICT- ja kyberturvallisuushallinnosta johdon kysymyksen. ISO/IEC 27001:2022 edellyttää myös johtajuutta, resursseja, roolien osoittamista, seurantaa ja johdon katselmointia.

Tehokkaan SSPM-johdon raportin tulee vastata seuraaviin kysymyksiin:

• Mitkä kriittiset SaaS-palvelut kuuluvat soveltamisalaan?
• Mitkä sääntelyn alaiset prosessit riippuvat niistä?
• Mitkä sisältävät henkilötietoja tai arkaluonteista liiketoimintadataa?
• Missä on myöhässä olevia käyttöoikeuskatselmointeja?
• Missä on ratkaisemattomia korkean riskin konfiguraatiopuutteita?
• Missä on hyväksymättömiä OAuth-sovelluksia tai integraatioita?
• Miltä toimittajilta puuttuu ajantasainen tietoturvanäyttö?
• Mitkä lokitusaukot vaikuttavat poikkeamien raportointiin?
• Mitkä poikkeukset edellyttävät riskin hyväksymistä?
• Mitä investointeja tai päätöksiä tarvitaan?

Tämä muuttaa SSPM:n teknisestä siivousprojektista hallinnon syötteeksi. Se tekee myös tietoturvajohtajasta vaikuttavamman, koska riskin hyväksyminen siirtyy oikealle tasolle.

Muuta SaaS-tietoturvan tila auditointivalmiiksi näytöksi

Jos organisaatiosi käyttää SaaS-palveluja sääntelyn alaisiin tietoihin, finanssitoimintoihin, asiakastukeen, henkilöstöhallintoon, yhteistyöhön, tuotekehitykseen tai analytiikkaan, SSPM ei ole enää valinnainen. Se on osa kyberhygieniaa, ICT-riskien hallintaa, tietosuojan osoitusvelvollisuutta ja auditointivalmiutta.

Clarysec voi auttaa sinua siirtymään hajanaisista SaaS-havainnoista jäsenneltyyn, näyttöön perustuvaan ohjelmaan hyödyntämällä:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, jolla jäsennetään toteutus pilvipalvelujen käytön, pääsyn rajoittamisen ja konfiguraationhallinnan osalta.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls, jolla kartoitetaan ISO/IEC 27002:2022 -kontrollit NIS2-, DORA-, GDPR- ja NIST CSF 2.0 -vaatimuksiin sekä auditointiodotuksiin.
• Clarysecin politiikkamalleja, kuten Pilvipalvelujen käyttöpolitiikka Pilvipalvelujen käyttöpolitiikka, Pilvipalvelujen käyttöpolitiikka-sme Pilvipalvelujen käyttöpolitiikka - pk-yritys, Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka-sme Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka - pk-yritys, Lokitus- ja valvontapolitiikka-sme Lokitus- ja valvontapolitiikka - pk-yritys ja Kolmansien osapuolten ja toimittajien tietoturvapolitiikka-sme Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys, joilla luodaan sovellettavat toimintaperiaatteet.

Aloita viidestä suurimman riskin SaaS-alustasta. Nimeä omistajat. Tallenna tiedot, käyttöoikeudet, konfiguraatio, integraatiot, lokit ja toimittajanäyttö. Muuta havainnot riskien käsittelytoimiksi ja johdon päätöksiksi.

Näin SaaS Security Posture Managementista tulee enemmän kuin työkaluluokka. Siitä tulee puolustettava vaatimustenmukaisuuden toimintamalli vuodelle 2026.

Lataa Clarysecin politiikkamallit, käytä Zenith Blueprint -mallia 30 päivän SSPM-näyttösprintin suunnitteluun ja kartoita SaaS-kontrollisi Zenith Controls -oppaalla ennen kuin seuraava auditointi löytää puutteet puolestasi.