SaaS-i turbeseisundi haldus 2026. aasta audititeks

SaaS-i auditileid, millel ei olnud omanikku

Teisipäeval kell 08:15 saab kiiresti kasvava fintech-ettevõtte infoturbejuht sõnumi andmekaitseametnikult: „Miks on kliendiandmete eksport koostöövahendist avalikult jagatav ja kes kiitis heaks OAuth-rakenduse, mis saab seda lugeda?”

Kell 09:00 kinnitab finantsosakond, et tööriista eest makstakse osakonna maksekaardiga, mitte keskse hankemenetluse kaudu. Kell 10:30 avastab IT, et avaliku lingi loonud kasutaja lahkus ettevõttest kolm kuud tagasi. Keskpäeval küsib õigusosakond, kas tegemist on GDPR-i kohase isikuandmetega seotud rikkumisega. Kell 14:00 küsib riskikomitee, kas probleem mõjutab NIS2 küberhügieeni ja DORA IKT kolmandatest isikutest tulenevat riski. Kell 16:00 küsib siseaudiitor konfiguratsiooni lähtealuseid, administraatori juurdepääsuõiguste ülevaatusi, pilveteenuse omanikku, logisid ja tarnijate hoolsuskontrolli.

Valus tõde on see, et organisatsioon ei kogenud klassikalist SaaS-i katkestust ega tarnija tõrget. Tegemist oli juhtimistõrkega.

Selline stsenaarium ei ole enam erandlik. Turundusmeeskond ühendab AI-platvormi CRM-iga laiaulatuslike OAuth-õigustega. Personaliosakond ostab väljaspool hankemenetlust nišianalüütika tööriista. Klienditoe meeskond lubab mugavuse huvides avalikud piletiekspordid. Arendusmeeskond integreerib brauserilaienduse arendustöövoogu. Iga otsus võib tunduda väike, kuid koos loovad need hajutatud kontrollipinna, mis sisaldab reguleeritud andmeid, privilegeeritud töövooge ja operatiivseid sõltuvusi.

SaaS-i turbeseisundi haldus ehk SSPM on distsipliin, mis muudab selle killustunud SaaS-reaalsuse juhitud, testitud ja auditeeritavaks kontrolliks. Hästi rakendatuna annab see infoturbejuhtidele, vastavusjuhtidele, audiitoritele ja ärilistele omanikele ühtse tõendusjälje ISO/IEC 27001:2022, NIS2 küberhügieeni, DORA IKT-riski ja GDPR-i turbealase vastutuse jaoks.

Clarysec’i seisukoht on selge: SSPM-i ei tohi käsitleda lihtsalt järjekordse juhtpaneelina. See tuleb lõimida ISMS-i, siduda riskivastutusega, kaardistada õiguslike kohustustega, toetada poliitikatega ja kontrollida korduva tõendusmaterjali kaudu.

Just siin muutuvad praktiliseks Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls ja Clarysec’i poliitikamallid. Need aitavad teisendada SaaS-i kontrollimatu leviku kontrollimudeliks, millest audiitor saab aru ja mille üle juhtorgan saab järelevalvet teha.

Miks sai SaaS-i turbeseisundi haldusest vastavusküsimus

SaaS-i käsitleti varem kui „tarkvara, mida käitab keegi teine”. Selline käsitlus ei ole enam kaitstav.

NIS2 alusel võivad paljud pilve-, SaaS-, digitaristu-, hallatud teenuste ja hallatud turbeteenuste osutajad kuuluda reguleeritud küberturvalisuse ootuste alla sõltuvalt sektorist, suurusest, rollist ja kriitilisusest. Veel olulisem on, et organisatsioonid, mis tuginevad SaaS-ile, peavad juhtima seda osana oma riskijuhtimismeetmetest. NIS2 artikkel 20 paneb juhtorganitele vastutuse kiita heaks küberturvalisuse riskijuhtimismeetmed, teha järelevalvet nende rakendamise üle ja saada koolitust. Artikkel 21 nõuab praktilisi tehnilisi, operatiivseid ja organisatsioonilisi meetmeid, sealhulgas riskianalüüsi, poliitikaid, intsidentide käsitlemist, talitluspidevust, tarneahela turvalisust, turvalist hankimist ja hooldust, tõhususe testimist, küberhügieeni, krüptograafiat, personaliturvet, juurdepääsukontrolli, varahaldust ning asjakohasel juhul mitmefaktorilist autentimist.

DORA tõstab finantssektori üksuste jaoks nõuete taset veelgi. Alates 17. jaanuarist 2025 kohaldub DORA paljudele finantssektori organisatsioonidele kui kohaldamisalasse kuuluvate üksuste digitaalse tegevuskerksuse raamistik. See nõuab IKT juhtimist, IKT-varade ja toetatavate funktsioonide tuvastamist ja klassifitseerimist, kaitse- ja ennetusmeetmeid, intsidendihaldust, talitluspidevust, testimist ning IKT kolmandatest isikutest tuleneva riski juhtimist. Kriitilisi või olulisi funktsioone toetavad SaaS-teenusepakkujad muutuvad DORA tõendusperimeetri osaks, kuid vastutus jääb reguleeritud finantsüksusele.

GDPR lisab privaatsuse tõendusmaterjali kihi. Artikkel 5 nõuab terviklust, konfidentsiaalsust ja vastutust. Artikkel 32 nõuab töötlemise asjakohast turvalisust. Praktikas peab organisatsioon teadma, millised isikuandmed tal on, kus neid töödeldakse, kes neile ligi pääseb, millised tarnijad neid töötlevad ja millised kaitsemeetmed neid kaitsevad. SaaS-i väärkonfiguratsioon muudab need küsimused kiiresti rikkumise hindamise küsimusteks.

ISO/IEC 27001:2022 on sild. Punktid 4.1 kuni 4.4 nõuavad, et organisatsioon määratleks konteksti, huvitatud osapoolte nõuded, kohaldamisala, liidesed ja sõltuvused. Punkt 5 nõuab eestvedamist, poliitikat, rolle ja vastutust. Punktid 6.1.1 kuni 6.1.3 nõuavad riskihindamist, riskikäsitlust, kohaldatavusdeklaratsiooni ja jääkriski otsuseid. Punktid 8.1, 8.2 ja 8.3 nõuavad tegevuste planeerimist, riskihindamist ja riskikäsitlust. Punktid 9 ja 10 nõuavad seiret, siseauditit, juhtkonnapoolset läbivaatamist ja täiustamist.

Kui te ei suuda vastata, millised SaaS-tööriistad töötlevad reguleeritud andmeid, kes neid omab, kuidas need on konfigureeritud, kellel on administraatoriõigustega juurdepääs, millised integratsioonid on aktiivsed ja milline tõendusmaterjal kinnitab kontrollimeetmete toimimist, on teie vastavuspositsioon habras.

Clarysec’i SSPM-mudel: register, omanik, lähtealus, tõendusmaterjal

Clarysec käsitleb SaaS-i turbeseisundi haldust korduva kontrollitsüklina, mitte ühekordse korrastusprojektina.

1. Tuvasta iga SaaS-teenus, sealhulgas varju-SaaS.
2. Määra äriomanik ja tehniline omanik.
3. Klassifitseeri andmed, kasutajad, integratsioonid ja operatiivne kriitilisus.
4. Rakenda turvalised konfiguratsiooni lähtealused.
5. Vaata üle kasutajad, administraatorid, külalised, teenusekontod ja OAuth-ulatused.
6. Lülita sisse logimine, teavitamine ja säilitamine.
7. Seira avalikku jagamist ja andmete kokkupuudet.
8. Seo omavahel tarnijad, lepingud, andmetöötluslepingud ja väljumisplaanid.
9. Kogu tõendusmaterjali kindlaksmääratud rütmis.
10. Suuna leiud riskikäsitlusse, juhtkonnapoolsesse läbivaatamisse ja täiustamisse.

See mudel on tihedalt kooskõlas ISO/IEC 27002:2022 ISO/IEC 27002:2022 kontrollimeetmetega, eriti 5.9 teabe ja muude seotud varade register, 5.15 juurdepääsukontroll, 5.18 juurdepääsuõigused, 5.19 infoturve tarnijasuhetes, 5.20 infoturbe käsitlemine tarnijalepingutes, 5.21 infoturbe haldamine IKT tarneahelas, 5.23 infoturve pilveteenuste kasutamisel, 8.2 privilegeeritud juurdepääsuõigused, 8.3 teabele juurdepääsu piiramine, 8.9 konfiguratsioonihaldus, 8.15 logimine, 8.16 seiretegevused ja 8.32 muudatuste juhtimine.

Zenith Blueprint ütleb kontrollimeetmete rakendamise etapis organisatsiooniliste kontrollimeetmete sammus 23:

Pilv ei ole enam sihtkoht, vaid vaikeseisund. Salvestusest koostööni, taristust masinõppeni – organisatsioonid on üha enam üles ehitatud kolmandate isikute, abstraheeritud ja kaughallatavate keskkondade kihtidele. Kontroll 5.23 tunnistab seda tegelikkust ja nõuab, et infoturvet käsitletaks pilveteenuste valikul, kasutamisel ja haldamisel sõnaselgelt – mitte järelmõttena, vaid algusest peale disainipõhimõttena.

See on SSPM-i tuum. See ei tähenda ainult väärkonfiguratsiooni avastamist tagantjärele. See tähendab SaaS-i valiku, kasutuselevõtu, käitamise, seire ja väljumise muutmist juhtimissüsteemi osaks.

Sama Zenith Blueprint jaotis selgitab jagatud vastutuse tegelikkust keeles, mida peaks kuulma iga juhatuse liige:

Pilveteenuse osutajad turvavad taristu, kuid teie vastutate endiselt oma andmete, konfiguratsioonide, juurdepääsupoliitikate ja intsidentidele reageerimise valmiduse eest. Väärkonfigureeritud salvestuskonteiner, avalikult eksponeeritud juhtpaneel või liigsed õigused pilve IAM-i seadistuses ei ole pilve tõrked. Need on juhtimistõrked.

Teenusepakkuja võib platvormi käitada, kuid rentniku konfiguratsiooni, identiteetide, juurdepääsu kinnituste, eksponeeritud andmete, integratsioonide, intsidendi töövoogude ja vastavuse tõendusmaterjali eest vastutate endiselt teie.

Kontroll 5.23 on ankur, kuid SSPM vajab kontrollimeetmete perekonda

Zenith Controls liigitab ISO/IEC 27002:2022 kontrolli 5.23, infoturve pilveteenuste kasutamisel, ennetavaks kontrollimeetmeks, mis toetab konfidentsiaalsust, terviklust ja käideldavust. Selle küberturvalisuse kontseptsioon on Protect ning operatiivne võimekus paikneb tarnijasuhete turbes ja valdkondades, mis hõlmavad juhtimist, ökosüsteemi ja kaitset.

See on oluline, sest SSPM ei ole üksik kontrollimeede. See on kontrollimeetmeteülene distsipliin.

Zenith Controls seob 5.23 tarnijasuhetega kontrolli 5.19 all, sest SaaS-teenusepakkujad on kriitilised tarnijad, kuid 5.23 lisab SaaS-spetsiifilised küsimused, nagu mitme rentniku mudel, andmete asukoha läbipaistvus ja jagatud vastutus. See seob 5.23 teabe edastamisega, sest rakendusliidesed, integratsioonid ja SaaS-ide vahelised töövood liigutavad andmeid pidevalt. See seob 5.23 varade registriga, sest organisatsioonid vajavad ajakohast nähtavust pilves salvestatud andmete ja SaaS-ressursside üle. Samuti seob see pilvejuhtimise seire, juurdepääsupiirangute, konfiguratsioonihalduse ja tarnijate järelevalvega.

Juurdepääsuõiguste puhul kaardistab Zenith Controls 5.18 kontrollidega 5.15 juurdepääsukontroll, 5.16 identiteedihaldus, 5.3 ülesannete lahusus, 5.36 vastavus infoturbe poliitikatele, reeglitele ja standarditele ning 8.2 privilegeeritud juurdepääsuõigused. SSPM-i puhul tähendab see, et juurdepääsuõiguste läbivaatamine ei ole pelgalt tabeliharjutus. See on operatiivne tõend, et identiteedi elutsükkel, vähima privileegi põhimõte, ülesannete lahusus ja privilegeeritud juurdepääsu haldus toimivad SaaS-rakendustes.

Poliitikapõhi: määratle hea tase enne tööriistade ostmist

Paljud SaaS-i tõrked algavad sellest, et poliitikakeel on ebamäärane. „Kasuta heakskiidetud tööriistu turvaliselt” ei ole piisav. Clarysec’i poliitikad määratlevad konkreetsed ootused registrile, juurdepääsule, logimisele, konfiguratsioonile ja tarnijate ülevaatamisele.

VKE-dele annab Cloud Usage Policy-sme Pilveteenuste kasutamise poliitika - VKE praktilise lähtekoha. Jaotisest „Juhtimisnõuded”, poliitika punkt 5.3:

IT-teenusepakkuja või tegevjuht peab pidama pilveteenuste registrit. See peab sisaldama järgmist: 5.3.1 iga heakskiidetud pilveteenuse nimi ja eesmärk 5.3.2 vastutav isik või meeskond (rakenduse omanik) 5.3.3 säilitatavate või töödeldavate andmete liigid 5.3.4 riik või piirkond, kus andmeid säilitatakse 5.3.5 kasutajate juurdepääsuõigused ja halduskontod 5.3.6 lepingu üksikasjad, uuendamiskuupäevad ja tugikontaktid

See punkt on SSPM-i operatiivne tuum. See annab audiitoritele esimese tõendusobjekti: registri, mis seob SaaS-i kasutuse omanike, andmete, geograafia, juurdepääsu ja lepingutega.

Sama Cloud Usage Policy-sme määratleb jaotises „Poliitika rakendamise nõuded”, poliitika punktis 6.2 lähteolukorra seaded:

Turbekonfiguratsiooni nõuded 6.2.1 Kõigil pilveplatvormidel tuleb lubada järgmine: 6.2.2 mitmefaktoriline autentimine (MFA) haldus- ja kasutajakontodele 6.2.3 paroolide keerukuse seaded (vähemalt 10 märki, korduskasutus keelatud) 6.2.4 tegevuslogimine sisselogimiskatsete ja andmetele juurdepääsu kohta 6.2.5 juurdepääsupiirangud (nt IP-de lubatud loend, kui toetatud) 6.2.6 haldusjuurdepääs peab piirduma nimeliste isikute või volitatud tugiteenuse osutajatega. 6.2.7 avalikult jagatud sisu tuleb regulaarselt seirata, et vältida andmeleket. 6.2.8 Kui kasutajakontosid enam ei vajata, tuleb juurdepääs viivitamata tühistada ning kõik jääkandmed üle vaadata ja arhiveerida või kustutada.

Ettevõtte tasandi keskkondades määrab Cloud Usage Policy Pilveteenuste kasutamise poliitika tugevama keskse juhtimise. Jaotisest „Juhtimisnõuded”, poliitika punkt 5.3:

Igal pilveteenusel peab olema määratud teenuseomanik, kes vastutab teabevara elutsükli halduse, kasutuse juhtimise, eelarve jälgimise ja pideva vastavuse seire eest.

See lause sulgeb levinud auditilünga. Kui SaaS-teenusel ei ole omanikku, ei oma keegi ka konfiguratsiooni triivi, juurdepääsu kordussertifitseerimist, andmete kokkupuudet, uuendamisotsuseid, intsidendikontakti ega väljumisplaani.

Ka õiguste juhtimine peab olema sõnaselge. User Account and Privilege Management Policy-sme Kasutajakontode ja õiguste haldamise poliitika - VKE, jaotisest „Poliitika rakendamise nõuded”, poliitika punkt 6.4, sätestab:

Juurdepääsuõiguste ülevaatamine ja logimine 6.4.1 Kõik kasutajakontod ja õigused tuleb üle vaadata iga kuue kuu järel. 6.4.2 Ülevaatuste käigus peab IT-valdkonna juht valideerima, kas iga konto on endiselt aktiivne, vajalik ja õigete õigustega määratud. 6.4.3 Konto loomise, konto deaktiveerimise ja õiguste muutmise logid tuleb turvaliselt säilitada vähemalt 12 kuud.

SaaS-i puhul vajab iga kriitiline platvorm määratletud juurdepääsuõiguste ülevaatamise tsüklit, isegi kui platvormi haldab keskse IT asemel ärimeeskond.

Ka logimine peab olema sõnaselge. Logging and Monitoring Policy-sme Logimis- ja seirepoliitika - VKE, jaotisest „Juhtimisnõuded”, poliitika punkt 5.5, sätestab:

Pilveteenused ja kolmandate osapoolte logimine 5.5.1 Platvormide puhul, kus logimine ei ole otsese IT-kontrolli all (nt SaaS-põhine e-post), kohaldatakse järgmisi nõudeid: 5.5.1.1 logimine tuleb lubada ja konfigureerida, kui see on saadaval 5.5.1.2 teavitused tuleb suunata IT-tugiteenuse osutajale 5.5.1.3 lepingud peavad nõudma, et teenusepakkujad säilitaksid logisid vähemalt 12 kuud ja annaksid neile taotluse korral juurdepääsu

Lõpuks tuleb dokumenteerida SaaS-i tarnijate haldus. Third-Party and Supplier Security Policy-sme Kolmandate osapoolte ja tarnijate turbepoliitika - VKE, jaotisest „Poliitika rakendamise nõuded”, poliitika punkt 6.3, sätestab:

Tarnijate turvalisuse pidev seire 6.3.1 Kriitilised või kõrge riskiga tarnijad tuleb üle vaadata vähemalt kord aastas. Läbivaatamine peab kontrollima järgmist: 6.3.1.1 turvaliste juurdepääsumeetodite jätkuv kasutamine 6.3.1.2 kehtivad turvasertifitseeringud või ajakohastatud kontrollimeetmete tõendusmaterjal 6.3.1.3 intsidendiajalugu või teatatud probleemid 6.3.1.4 lepinguline vastavus turvaklauslitele 6.3.2 Need läbivaatamised tuleb dokumenteerida ja säilitada tarnija kirje juures. Järeltegevused peavad olema selgelt jälgitavad. 6.3.3 Kui tarnijad haldavad IT-taristut või rakendusi, võib seire hõlmata järgmist: 6.3.3.1 auditilogide taotlemine 6.3.3.2 kontotegevuse ülevaatamine 6.3.3.3 kinnitamine, et loata juurdepääsu ei ole toimunud

Koos muudavad need poliitikad SSPM-i turbeambitsioonist rakendatavaks tegevusmudeliks.

30-päevane SSPM-i tõendusmaterjali sprint

Praktiline infoturbejuht või vastavusjuht saab alustada 30-päevase tõendusmaterjali sprindiga. Valige viis SaaS-platvormi, mis on reguleeritud andmete või kriitiliste tegevuste seisukohast kõige olulisemad. Tüüpilised kandidaadid on Microsoft 365 või Google Workspace, CRM, piletihaldus, HRIS, finantsautomaatika, klienditugi ja analüütika.

1. nädal: loo SaaS-i register

Kasuta miinimumregistrina Cloud Usage Policy-sme punkti 5.3 välju. Iga SaaS-teenuse kohta talleta:

• teenuse nimi ja äriline eesmärk
• rakenduse omanik ja tehniline omanik
• andmeliigid, sealhulgas isikuandmed ja eriliigilised isikuandmed, kui kohaldatav
• andmete säilitamise riik või piirkond
• kasutajarühmad ja administraatorikontod
• OAuth-rakendused ja kolmandate osapoolte integratsioonid
• lepinguomanik, uuendamiskuupäev ja tugikontakt
• operatiivne kriitilisus
• kohaldatavad kohustused, näiteks NIS2, DORA, GDPR või kliendilepingud

See toetab ISO/IEC 27001:2022 punkte 4.2 ja 4.3, sest regulatiivsed, lepingulised ja kolmandate osapoolte sõltuvused peavad kujundama ISMS-i kohaldamisala. Samuti toetab see DORA artikli 8 laadset IKT-toega ärifunktsioonide, teabevarade, IKT-varade ja sõltuvuste tuvastamist ja klassifitseerimist.

2. nädal: määratle turvalised konfiguratsiooni lähtealused

Määratle iga valitud SaaS-platvormi jaoks 10 kuni 15 baastaseme kontrollimeedet.

• MFA on jõustatud kõigile kasutajatele, administraatoritele võimaluse korral andmepüügikindla MFA-ga
• väline jagamine on vaikimisi keelatud või piiratud heakskiidetud domeenidega
• avalikud lingid on keelatud või ajaliselt piiratud
• külaliskontod vaadatakse üle kord kuus
• administraatorirollid määratakse nimelistele isikutele
• pärandautentimine on keelatud
• OAuth-rakenduste kinnitamise töövoog on lubatud
• kõrge riskiga OAuth-ulatused on blokeeritud või nõuavad turbe heakskiitu
• auditilogimine on lubatud
• andmeekspordi õigused on piiratud
• säilitamise seaded on kooskõlas õiguslike ja äriliste nõuetega
• API-tokenid vaadatakse üle ja roteeritakse
• turbehoiatused suunatakse IT-le või SOC-ile
• andmekao vältimise seaded on lubatud, kui toetatud
• break-glass kontod on dokumenteeritud ja seiratud

Zenith Blueprint, kontrollimeetmete rakendamise etapp, samm 19, kontroll 8.9 konfiguratsioonihaldus, selgitab, miks see on oluline:

Paljud rikkumised ei tulene tarkvaravigadest, vaid halbadest konfiguratsioonivalikutest. Vaikeparoolid jäetakse muutmata, ebaturvalised teenused lubatakse, mittevajalikud pordid jäetakse avatuks või süsteemid eksponeeritakse internetile ilma põhjenduseta. Kontroll 8.9 tagab, et iga süsteem ehitatakse turvalise konfiguratsiooni lähtealusele ja vaadatakse regulaarselt üle, et vältida aja jooksul triivi.

SaaS-i puhul hõlmab konfiguratsiooni triiv olukordi, kus äriomanik lubab avaliku jagamise, administraator kiidab heaks laiaulatusliku kolmanda osapoole juurdepääsu või tarnija muudab pärast funktsiooniväljalaset vaikeseadeid.

3. nädal: vaata üle juurdepääs ja integratsioonid

Ekspordi kasutajad, rühmad, administraatorid ja ühendatud rakendused. Iga administraatorikonto puhul kinnita nimeline isik, äriline põhjendus, MFA staatus, viimane sisselogimine, õiguste tase, varundamise katvus, ülesannete lahususe probleemid ja kinnitamise tõendusmaterjal.

OAuth-rakenduste ja integratsioonide puhul kinnita rakenduse omanik, ligipääsetavad andmed, taotletud õigused, tarnijariski staatus, viimase kasutamise kuupäev, jätkuv vajadus ning kas nõusoleku andis kasutaja või kiitis selle heaks administraator.

Zenith Blueprint, kontrollimeetmete rakendamise etapp, samm 19, kontroll 8.3 teabele juurdepääsu piiramine, annab tegevuspõhimõtte:

Juurdepääs teabele peaks olema nii avatud kui vajalik, kuid nii piiratud kui võimalik.

See kehtib mitte ainult inimeste, vaid ka rakenduste, teenuste ja rakendusliideste kohta. Mitteaktiivne OAuth-integratsioon võib säilitada juurdepääsu kaua pärast seda, kui selle loonud töötaja või projekt on kadunud.

4. nädal: koosta auditivalmis tõendusmaterjal ja riskikäsitlus

Iga SaaS-platvormi kohta säilita registrikanne, konfiguratsiooni lähtealus, võtmesätteid tõendavad kuvatõmmised või ekspordid, juurdepääsuõiguste ülevaatuse kinnitus, administraatori ülevaatuse tõendusmaterjal, OAuth-ülevaatuse tõendusmaterjal, logimise ja teavitamise tõendusmaterjal, tarnija turbeülevaatuse kirje, avatud leiud ja riskikäsitluse tegevused.

Seejärel loo üheleheküljeline juhtkonna kokkuvõte, mis näitab kriitilisi leide, tähtaja ületanud omanikke, lahendamata kõrge riskiga konfiguratsioonilünki, heakskiitmata integratsioone, logimislünki, erandeid ja vajalikke otsuseid. See toetab ISO/IEC 27001:2022 punkti 9.1 seire, punkti 9.2 siseaudit ja punkti 9.3 juhtkonnapoolne läbivaatamine. Samuti loob see praktilise silla NIS2 artikli 20 juhtkonna vastutuse ja DORA juhtorgani järelevalvega.

Vastavuseülene kaardistus: üks SSPM-i tõenduspakett, mitu kohustust

SSPM-i äriväärtus ei seisne ainult paremas turvalisuses. See vähendab nõuetele vastavuse töö dubleerimist.

NIS2 artikkel 21 nõuab asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja organisatsioonilisi meetmeid. SaaS-i register toetab varahaldust. Konfiguratsiooni lähtealused toetavad küberhügieeni. MFA ja juurdepääsuõiguste ülevaatused toetavad juurdepääsukontrolli. Logimine toetab intsidentide käsitlemist. Tarnijate ülevaatus toetab tarneahela turvalisust. Tõendusmaterjali kogumise rütm toetab poliitikaid ja protseduure tõhususe hindamiseks.

DORA nõuab, et finantsüksused tuvastaksid ja klassifitseeriksid IKT-toega funktsioonid, teabevarad, IKT-varad ja kolmandatest isikutest tulenevad sõltuvused. Samuti nõuab see kaitse- ja ennetusmeetmeid, juurdepääsukontrolle, tugevat autentimist, krüptimist, talitluspidevust, testimist, intsidendihaldust ning IKT kolmandatest isikutest tuleneva riski juhtimist. SaaS-i SSPM-i tõenduspakett saab toetada DORA registreid, sõltuvuste kaardistamist, lepingute järelevalvet, auditeerimisõigusi ja väljumisplaane.

GDPR nõuab, et vastutavad töötlejad tõendaksid vastavust tervikluse, konfidentsiaalsuse ja vastutuse nõuetele. SaaS-registrid tuvastavad, kus isikuandmeid töödeldakse. Konfiguratsiooni lähtealused vähendavad loata avalikustamist. Juurdepääsuõiguste ülevaatused toetavad vähima privileegi põhimõtet. Logimine toetab rikkumise uurimist. Tarnijate kirjed toetavad volitatud töötlejate juhtimist ja vastutust.

NIST CSF 2.0 lisab kasuliku kommunikatsioonikihi. Selle GOVERN-funktsioon nõuab, et õiguslikud, regulatiivsed ja lepingulised küberturvalisuse nõuded oleksid mõistetud ja juhitud. Selle tarneahela tulemused nõuavad tarnijate rolle, lepinguid, hoolsuskontrolli, seiret ja suhtejärgseid tegevusi. Selle IDENTIFY, PROTECT, DETECT, RESPOND ja RECOVER funktsioonid kaardistuvad loomulikult SaaS-i registri, juurdepääsukontrolli, andmekaitse, logimise, intsidentidele reageerimise ja taastega.

COBIT 2019 ja ISACA-suunitlusega audiitorid lähenevad SSPM-ile tavaliselt valitsemise, juhtimiseesmärkide, riskivastutuse, kontrollimeetmete toimimise ja kindluse andmise kaudu. Nad küsivad, kas SaaS-i otsused on kooskõlas ettevõtte eesmärkidega, kas riskivastused on dokumenteeritud, kas vastutused on määratud ja kas kindlustandvad tegevused tõendavad kontrollimeetmete toimimist.

Auditi vaade: kuidas eri audiitorid SaaS-i turbeseisundit testivad

Tugev SSPM-programm peab vastu eri auditistiilidele, sest see toodab tõendusmaterjali õigel tasemel.

ISO/IEC 27001:2022 audiitor alustab kohaldamisalast, huvitatud osapooltest, riskihindamisest, kohaldatavusdeklaratsioonist ja operatiivsest tõendusmaterjalist. Kui kontroll 5.23 on kaasatud, ootab ta tõendusmaterjali pilveteenuste valiku, kasutamise, haldamise ja väljumise kohta. Kui juurdepääsuõiguste kontrollid on kaasatud, võtab ta kasutajatest valimi ja küsib, kas tööleasujate, ametikoha vahetajate ja lahkujate muudatused kajastuvad SaaS-i õigustes.

DORA ülevaataja keskendub kriitilistele või olulistele funktsioonidele, IKT kolmandatest isikutest tulenevatele sõltuvustele, registri täielikkusele, lepingutele, intsidendi klassifitseerimisele, testimisele ja väljumisplaanile. Kui SaaS-platvorm toetab maksetoiminguid, klientide sisseelamist, kauplemist, riskianalüütikat või kliendisuhtlust, tõuseb tõendusmaterjali standard.

GDPR-i audiitor või privaatsuse ülevaataja küsib, kus isikuandmeid säilitatakse, kes neile ligi pääseb, millised ekspordi- ja jagamisseaded on olemas, kas volitatud töötlejad on juhitud, kas logid toetavad rikkumise hindamist ja kas kontrollimeetmed on riskiga proportsionaalsed.

Tarnijarisk, jagatud vastutus ja intsidendivalmidus

SSPM algab sageli konfiguratsioonist, kuid ei tohi sellega piirduda. SaaS on ka tarnijariski ja intsidendivalmiduse küsimus.

DORA nõuab, et finantsüksused peaksid IKT-teenuselepingute registreid, eristaksid kriitilisi või olulisi funktsioone toetavaid kokkuleppeid, hindaksid kontsentratsiooniriski, hindaksid teenuseosutaja sobivust ja hoiaksid väljumisstrateegiaid. Lepingud peaksid käsitlema teenuste kirjeldusi, andmete asukohta, käideldavuse, autentsuse, tervikluse ja konfidentsiaalsuse kaitset, andmetele juurdepääsu, taastamist ja tagastamist, intsidendiabi, koostööd ametiasutustega, lõpetamisõigusi, turbenõudeid, auditeerimisõigusi ja üleminekutuge.

NIS2 artikkel 21 hõlmab ka tarneahela turvalisust ning nõuab, et üksused arvestaksid otsestele tarnijatele ja teenuseosutajatele omaseid haavatavusi, toodete kvaliteeti ja tarnijate küberturvalisuse praktikaid.

Praktikas peaks kriitilise SaaS-i ülevaatus ühendama turbeküsimustiku tõendusmaterjali, lepingu ülevaatuse, andmetöötluslepingu staatuse, intsidendiajaloo, teenustaseme kohustused, logidele juurdepääsu, auditiaruanded, konfiguratsiooni tõendusmaterjali ja väljumise teostatavuse.

Jagatud vastutuse lünk ilmneb siis, kui meeskonnad eeldavad, et tarnija sertifitseering katab rentniku konfiguratsiooni. Ei kata. Tarnija võib käitada turvalist platvormi, samal ajal kui klient lubab avaliku jagamise, jätab kasutuseta administraatorikontod aktiivseks või annab liigsed API-ulatused. SSPM sulgeb selle lünga.

Intsidentideks valmisolek on sama oluline. NIS2 olulise intsidendi teavitamine hõlmab 24 tunni jooksul varajast hoiatust, 72 tunni jooksul teavitust ja lõpparuannet hiljemalt ühe kuu jooksul pärast 72-tunnist teavitust. DORA nõuab IKT-ga seotud intsidendihaldust koos tuvastamise, registreerimise, klassifitseerimise, eskaleerimise, kommunikatsiooni ja teavitamisega. GDPR-i isikuandmetega seotud rikkumise hindamine sõltub samuti õigeaegsest arusaamast, mis juhtus, milliseid andmeid see mõjutas ja keda see puudutas.

Kui kahtlane OAuth-rakendus pääses ligi kliendifailidele, peate teadma, millal rakendus autoriseeriti, milline kasutaja selle autoriseeris, millised ulatused anti, millistele andmetele ligi pääseti, kas andmeid laaditi alla või jagati, milliseid kasutajaid või kliente see mõjutas, kas juurdepääs on endiselt aktiivne ja milliseid ohjemeetmeid rakendati.

Ilma logimise ja säilitamiseta võib organisatsioon olla sunnitud lähtuma halvima stsenaariumi eeldustest. See suurendab õiguslikku kokkupuudet, survet klientidega suhtlemisel ja regulatiivset ebakindlust. Kui SaaS-teenusepakkuja küsib auditilogide eest lisatasu, peab riskiomanik jääkriski sõnaselgelt aktsepteerima või kinnitama nõutava litsentsitaseme. See otsus kuulub riskikäsitluse kirjete ja juhtkonnapoolse läbivaatamise juurde.

Levinud SSPM-i tõrkemustrid

Samad tõrkemustrid korduvad sektorite lõikes.

Esiteks avastatakse varju-SaaS arvetelt, brauseriajaloost või SSO-logidest, mitte hankemenetluse kaudu. Parandus ei ole ainult tööriistade blokeerimine. Vaja on lihtsustatud vastuvõtuprotsessi, mida ärimeeskonnad saavad kasutada.

Teiseks on SaaS-i omandi määramine ebaselge. CRM on „müügi oma”, kuid keegi müügiosakonnas ei oska selgitada administraatorirolle, API-tokeneid, andmeeksporte ega säilitamise seadeid. Määra rakenduse omanikud ja tehnilised omanikud eraldi.

Kolmandaks on juurdepääsuõiguste ülevaatused liiga üldised. Läbivaataja kinnitab „kõik kasutajad heaks kiidetud”, kontrollimata kõrge riskiga rolle, mitteaktiivseid kasutajaid, külalisi, väliseid koostööpartnereid või teenusekontosid. SSPM-i juurdepääsuõiguste ülevaatus peab olema riskipõhiselt järjestatud.

Neljandaks eiratakse OAuth-rakendusi. Paljud organisatsioonid vaatavad üle inimkasutajad, kuid mitte rakendustevahelisi õigusi. Tänapäevases SaaS-is võivad integratsioonid olla kasutajatest võimsamad.

Viiendaks eksisteerivad konfiguratsiooni lähtealused ainult sertifitseerimisprojekti kuvatõmmistena. Neid ei seirata triivi suhtes. Joonda SSPM konfiguratsioonihaldusega, et lähtealuse kontrollid muutuksid korduvaks tõendusmaterjaliks.

Kuuendaks on tarnijate ülevaatus ja SaaS-i turbeseisundi ülevaatus eraldatud. Hankeüksusel on leping, IT-l halduskonsool, privaatsusfunktsioonil andmetöötlusleping ja turbefunktsioonil riskiregister. Audiitor näeb fragmente. SSPM toob need kokku.

Juhtkonna aruandlus: tee SaaS-risk juhtorganile nähtavaks

NIS2 ja DORA muudavad mõlemad IKT ja küberturvalisuse juhtimise juhtkonna küsimuseks. ISO/IEC 27001:2022 nõuab samuti eestvedamist, ressursse, rollide määramist, seiret ja juhtkonnapoolset läbivaatamist.

Tõhus SSPM-i juhtkonna aruanne peab vastama järgmistele küsimustele:

• Millised kriitilised SaaS-teenused on kohaldamisalas?
• Millised reguleeritud protsessid neist sõltuvad?
• Millised sisaldavad isikuandmeid või tundlikke äriandmeid?
• Millistel on tähtaja ületanud juurdepääsuõiguste ülevaatused?
• Millistel on lahendamata kõrge riskiga konfiguratsioonilüngad?
• Millistel on heakskiitmata OAuth-rakendused või integratsioonid?
• Millistel tarnijatel puudub ajakohane turbe tõendusmaterjal?
• Millised logimislüngad mõjutavad intsidendist teavitamist?
• Millised erandid nõuavad riski aktsepteerimist?
• Milliseid investeeringuid või otsuseid on vaja?

See muudab SSPM-i tehnilisest korrastusprojektist juhtimissisendiks. Samuti muudab see infoturbejuhi tõhusamaks, sest riski aktsepteerimine liigub õigele tasandile.

Muuda SaaS-i turbeseisund auditivalmis tõendusmaterjaliks

Kui teie organisatsioon tugineb SaaS-ile reguleeritud andmete, finantstegevuste, klienditoe, personali, koostöö, arenduse või analüütika jaoks, ei ole SSPM enam vabatahtlik. See on osa küberhügieenist, IKT-riski juhtimisest, privaatsuse vastutusest ja auditivalmidusest.

Clarysec aitab liikuda killustunud SaaS-leidudelt struktureeritud ja tõenduspõhisele programmile, kasutades:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, et struktureerida rakendamine pilveteenuste kasutuse, juurdepääsupiirangute ja konfiguratsioonihalduse lõikes.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls, et kaardistada ISO/IEC 27002:2022 kontrollimeetmed NIS2, DORA, GDPR, NIST CSF 2.0 ja auditi ootustega.
• Clarysec’i poliitikamalle, nagu Cloud Usage Policy Pilveteenuste kasutamise poliitika, Cloud Usage Policy-sme Pilveteenuste kasutamise poliitika - VKE, User Account and Privilege Management Policy-sme Kasutajakontode ja õiguste haldamise poliitika - VKE, Logging and Monitoring Policy-sme Logimis- ja seirepoliitika - VKE ning Third-Party and Supplier Security Policy-sme Kolmandate osapoolte ja tarnijate turbepoliitika - VKE, et luua rakendatavad tegevusreeglid.

Alusta oma viiest kõrgeima riskiga SaaS-platvormist. Määra omanikud. Kogu andmete, juurdepääsu, konfiguratsiooni, integratsioonide, logide ja tarnijate tõendusmaterjal. Muuda leiud riskikäsitluse tegevusteks ja juhtkonna otsusteks.

Nii saab SaaS-i turbeseisundi haldusest rohkem kui tööriistakategooria. Sellest saab 2026. aastaks kaitstav vastavusdistsipliin.

Laadi alla Clarysec’i poliitikamallid, kasuta Zenith Blueprint-i oma 30-päevase SSPM-i tõendusmaterjali sprindi planeerimiseks ning kaardista oma SaaS-i kontrollimeetmed Zenith Controls-iga enne, kui järgmine audit lüngad sinu eest üles leiab.