SaaS drošības stāvokļa pārvaldība 2026. gada auditiem

SaaS audita konstatējums, par kuru neviens neatbildēja

Otrdien plkst. 08:15 strauji augoša finanšu tehnoloģiju uzņēmuma informācijas drošības vadītājs saņem ziņu no datu aizsardzības speciālista: “Kāpēc klientu eksports no sadarbības rīka ir publiski koplietojams, un kurš apstiprināja OAuth lietotni, kas to var nolasīt?”

Plkst. 09:00 finanšu komanda apstiprina, ka par rīku maksā ar struktūrvienības karti, nevis caur centralizētu iepirkumu. Plkst. 10:30 IT konstatē, ka lietotājs, kurš izveidoja publisko saiti, uzņēmumu atstāja pirms trim mēnešiem. Pusdienlaikā juridiskais dienests jautā, vai tas ir GDPR personas datu aizsardzības pārkāpums. Plkst. 14:00 Risku komiteja jautā, vai problēma ietekmē NIS2 kiberdrošības higiēnu un DORA IKT trešo personu risku. Plkst. 16:00 iekšējais auditors pieprasa pamatkonfigurācijas, administratoru piekļuves tiesību pārskatīšanas pierādījumus, mākoņpakalpojuma īpašumtiesības, žurnālus un piegādātāja pienācīgu pārbaudi.

Sāpīgā patiesība ir tāda, ka organizācija nepiedzīvoja klasisku SaaS nepieejamību vai piegādātāja kļūmi. Tā piedzīvoja pārvaldības kļūmi.

Šāds scenārijs vairs nav izņēmums. Mārketinga komanda pieslēdz AI platformu CRM ar plašām OAuth piekļuves tiesībām. Personāla funkcija ārpus iepirkuma procesa iegādājas nišas analītikas rīku. Klientu atbalsta komanda ērtības labad iespējo publisku pieteikumu eksportu. Inženierijas komanda integrē pārlūkprogrammas paplašinājumu izstrādes darbplūsmā. Katrs lēmums var šķist neliels, taču kopā tie veido izkliedētu kontroles virsmu, kurā ir regulēti dati, priviliģētas darbplūsmas un darbības atkarības.

SaaS drošības stāvokļa pārvaldība jeb SSPM ir disciplīna, kas šo sadrumstaloto SaaS realitāti pārvērš pārvaldītā, pārbaudītā un auditējamā kontrolē. Ja tā ir ieviesta pareizi, tā nodrošina informācijas drošības vadītājiem, atbilstības vadītājiem, auditoriem un biznesa īpašniekiem vienotu pierādījumu ķēdi ISO/IEC 27001:2022, NIS2 kiberdrošības higiēnas, DORA IKT riska pārvaldības un GDPR drošības pārskatatbildības vajadzībām.

Clarysec nostāja ir tieša: SSPM nedrīkst uztvert kā vēl vienu informācijas paneli. Tā ir jāiekļauj IDPS, jāsasaista ar atbildību par risku, jāpielīdzina juridiskajiem pienākumiem, jāatbalsta ar politiku un jāpārbauda, izmantojot regulārus pierādījumus.

Tieši šeit Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls un Clarysec politiku veidnes kļūst praktiski izmantojamas. Tās palīdz pārvērst SaaS izplešanos kontroles modelī, ko auditors var saprast un ko vadības struktūra var pārraudzīt.

Kāpēc SaaS drošības stāvokļa pārvaldība kļuva par atbilstības jautājumu

SaaS agrāk tika uztverts kā “programmatūra, ko darbina kāds cits”. Šāds skatījums vairs nav aizstāvams.

Saskaņā ar NIS2 daudzi mākoņpakalpojumu, SaaS, digitālās infrastruktūras, pārvaldīto pakalpojumu un pārvaldītās drošības pakalpojumu sniedzēji atkarībā no nozares, lieluma, lomas un kritiskuma var nonākt regulēto kiberdrošības prasību tvērumā. Vēl svarīgāk — organizācijām, kas paļaujas uz SaaS, tas ir jāpārvalda kā daļa no saviem riska pārvaldības pasākumiem. NIS2 Article 20 nosaka vadības struktūru atbildību par kiberdrošības riska pārvaldības pasākumu apstiprināšanu, ieviešanas pārraudzību un apmācību saņemšanu. Article 21 prasa praktiskus tehniskos, operacionālos un organizatoriskos pasākumus, tostarp riska analīzi, politikas, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu iegādi un uzturēšanu, efektivitātes testēšanu, kiberdrošības higiēnu, kriptogrāfiju, personāla drošību, piekļuves kontroli, aktīvu pārvaldību un daudzfaktoru autentifikāciju, ja tas ir piemērojams.

DORA paaugstina prasības finanšu iestādēm. Kopš 2025. gada 17. janvāra DORA attiecas uz daudzām finanšu sektora organizācijām kā operacionālās noturības režīma tvērumā esošām vienībām. Tā prasa IKT pārvaldību, IKT aktīvu un atbalstīto funkciju identificēšanu un klasifikāciju, aizsardzības un preventīvos kontroles pasākumus, incidentu pārvaldību, nepārtrauktību, testēšanu un IKT trešo personu risku pārvaldību. SaaS pakalpojumu sniedzēji, kas atbalsta kritiskas vai svarīgas funkcijas, kļūst par daļu no DORA pierādījumu perimetra, bet regulētā finanšu iestāde saglabā pārskatatbildību.

GDPR pievieno privātuma pierādījumu slāni. Article 5 prasa integritāti, konfidencialitāti un pārskatatbildību. Article 32 prasa atbilstošu apstrādes drošību. Praksē organizācijai ir jāzina, kādi personas dati pastāv, kur tie tiek apstrādāti, kam tiem ir piekļuve, kuri piegādātāji tos apstrādā un kādi drošības pasākumi tos aizsargā. SaaS nepareiza konfigurācija šos jautājumus pārvērš steidzamos jautājumos pārkāpuma ietekmes izvērtēšanai.

ISO/IEC 27001:2022 ir tilts. Punkti 4.1 līdz 4.4 prasa organizācijai definēt kontekstu, ieinteresēto pušu prasības, darbības jomu, saskarnes un atkarības. 5. punkts prasa līderību, politiku, lomas un pārskatatbildību. Punkti 6.1.1 līdz 6.1.3 prasa risku izvērtēšanu, riska apstrādi, Piemērojamības paziņojumu un lēmumus par atlikušo risku. Punkti 8.1, 8.2 un 8.3 prasa darbības plānošanu, risku izvērtēšanu un riska apstrādi. 9. un 10. punkts prasa uzraudzību, iekšējo auditu, vadības pārskatīšanu un uzlabošanu.

Ja nevarat atbildēt, kuri SaaS rīki apstrādā regulētus datus, kam tie pieder, kā tie ir konfigurēti, kam ir administratora piekļuve, kuras integrācijas ir aktīvas un kādi pierādījumi apliecina, ka kontrole darbojas, jūsu atbilstības pozīcija ir trausla.

Clarysec SSPM modelis: uzskaite, īpašumtiesības, pamatkonfigurācija, pierādījumi

Clarysec SaaS drošības stāvokļa pārvaldību uztver kā atkārtojamu kontroles ciklu, nevis vienreizēju sakārtošanas projektu.

1. Atklāt katru SaaS pakalpojumu, tostarp ēnu SaaS.
2. Piešķirt biznesa īpašnieku un tehnisko īpašnieku.
3. Klasificēt datus, lietotājus, integrācijas un darbības kritiskumu.
4. Piemērot drošas pamatkonfigurācijas.
5. Pārskatīt lietotājus, administratorus, viesus, pakalpojumu kontus un OAuth tvērumus.
6. Iespējot žurnalēšanu, brīdināšanu un glabāšanu.
7. Uzraudzīt publisku koplietošanu un datu ekspozīciju.
8. Sasaistīt piegādātājus, līgumus, datu apstrādes līgumus un izstāšanās plānošanu.
9. Vākt pierādījumus noteiktā periodiskumā.
10. Iekļaut konstatējumus riska apstrādē, vadības pārskatīšanā un uzlabošanā.

Šis modelis cieši atbilst ISO/IEC 27002:2022 ISO/IEC 27002:2022 kontroles pasākumiem, īpaši 5.9 informācijas un citu saistīto aktīvu uzskaitei, 5.15 piekļuves kontrolei, 5.18 piekļuves tiesībām, 5.19 informācijas drošībai piegādātāju attiecībās, 5.20 informācijas drošības iekļaušanai piegādātāju līgumos, 5.21 informācijas drošības pārvaldībai IKT piegādes ķēdē, 5.23 informācijas drošībai mākoņpakalpojumu izmantošanā, 8.2 priviliģētām piekļuves tiesībām, 8.3 informācijas piekļuves ierobežošanai, 8.9 konfigurāciju pārvaldībai, 8.15 žurnalēšanai, 8.16 uzraudzības darbībām un 8.32 izmaiņu pārvaldībai.

Zenith Blueprint sadaļā Controls in Action, 23. solī par organizatoriskajām kontrolēm, norāda:

Mākonis vairs nav galamērķis — tas ir noklusējums. No glabāšanas līdz sadarbībai, no infrastruktūras līdz mašīnmācībai organizācijas arvien biežāk tiek veidotas uz trešo pušu, abstrahētu un attālināti pārvaldītu vides slāņu pamata. 5.23. kontroles pasākums atzīst šo realitāti un prasa, lai informācijas drošība tiktu skaidri ņemta vērā mākoņpakalpojumu izvēlē, izmantošanā un pārvaldībā — nevis kā pēcpārdomas jautājums, bet kā projektēšanas princips jau no paša sākuma.

Tā ir SSPM būtība. Runa nav tikai par nepareizas konfigurācijas atklāšanu pēc fakta. Runa ir par SaaS izvēles, sākotnējās piesaistes, ekspluatācijas, uzraudzības un izstāšanās iekļaušanu pārvaldības sistēmā.

Tā pati Zenith Blueprint sadaļa izskaidro kopīgās atbildības realitāti valodā, kas jādzird katram valdes loceklim:

Mākoņpakalpojumu sniedzēji aizsargā infrastruktūru, taču jūs joprojām esat atbildīgi par saviem datiem, konfigurācijām, piekļuves politikām un incidentu reaģēšanas gatavību. Nepareizi konfigurēta glabātuve, publiski eksponēts informācijas panelis vai pārmērīgas piekļuves tiesības mākoņa IAM konfigurācijā nav mākoņa kļūmes. Tās ir pārvaldības kļūmes.

Jūsu pakalpojumu sniedzējs var darbināt platformu, taču jūs joprojām atbildat par nomnieka konfigurāciju, identitātēm, piekļuves apstiprinājumiem, eksponētajiem datiem, integrācijām, incidentu darbplūsmām un atbilstības pierādījumiem.

5.23. kontroles pasākums ir balsts, bet SSPM vajadzīga kontroles pasākumu saime

Zenith Controls ISO/IEC 27002:2022 5.23. kontroles pasākumu — informācijas drošība mākoņpakalpojumu izmantošanā — klasificē kā preventīvu kontroles pasākumu, kas atbalsta konfidencialitāti, integritāti un pieejamību. Tā kiberdrošības koncepts ir Protect, operacionālā spēja — piegādātāju attiecību drošība, bet jomas — pārvaldība, ekosistēma un aizsardzība.

Tas ir būtiski, jo SSPM nav viens kontroles pasākums. Tā ir starpkontroļu disciplīna.

Zenith Controls sasaista 5.23 ar piegādātāju attiecībām saskaņā ar 5.19, jo SaaS pakalpojumu sniedzēji ir kritiski piegādātāji, bet 5.23 pievieno SaaS specifiskus jautājumus, piemēram, daudznomnieku vidi, datu atrašanās vietas pārredzamību un kopīgo atbildību. Tas sasaista 5.23 ar informācijas nodošanu, jo lietojumprogrammu saskarnes, integrācijas un SaaS savstarpējās darbplūsmas nepārtraukti pārvieto datus. Tas sasaista 5.23 ar aktīvu uzskaiti, jo organizācijām ir nepieciešama aktuāla redzamība pār mākoņvidē glabātiem datiem un SaaS resursiem. Tas arī sasaista mākoņpakalpojumu pārvaldību ar uzraudzību, piekļuves ierobežošanu, konfigurāciju pārvaldību un piegādātāju pārraudzību.

Attiecībā uz piekļuves tiesībām Zenith Controls sasaista 5.18 ar 5.15 piekļuves kontroli, 5.16 identitātes pārvaldību, 5.3 pienākumu nodalīšanu, 5.36 atbilstību informācijas drošības politikām, noteikumiem un standartiem un 8.2 priviliģētām piekļuves tiesībām. SSPM kontekstā tas nozīmē, ka piekļuves tiesību pārskatīšana nav tikai darbs ar izklājlapu. Tas ir operacionāls pierādījums, ka SaaS lietojumprogrammās darbojas identitātes dzīves cikls, minimāli nepieciešamās tiesības, pienākumu nodalīšana un priviliģētās piekļuves pārvaldība.

Politikas pamats: definējiet pareizu rīcību pirms rīku iegādes

Daudzas SaaS kļūmes sākas ar neskaidru politikas valodu. “Droši izmantojiet apstiprinātus rīkus” nav pietiekami. Clarysec politikas definē konkrētas prasības reģistriem, piekļuvei, žurnalēšanai, konfigurācijai un piegādātāju pārskatīšanai.

SME vajadzībām Cloud Usage Policy-sme Cloud Usage Policy - SME nodrošina praktisku sākumpunktu. No sadaļas “Pārvaldības prasības”, politikas 5.3. punkts:

IT pakalpojumu sniedzējam vai GM ir jāuztur Mākoņpakalpojumu reģistrs. Tajā jāieraksta: 5.3.1 Katra apstiprinātā mākoņpakalpojuma nosaukums un mērķis 5.3.2 Atbildīgā persona vai komanda (Lietotnes īpašnieks) 5.3.3 Glabāto vai apstrādāto datu veidi 5.3.4 Valsts vai reģions, kurā dati tiek glabāti 5.3.5 Lietotāju piekļuves tiesības un administratīvie konti 5.3.6 Līguma dati, atjaunošanas datumi un atbalsta kontaktpersonas

Šis punkts ir SSPM darbības kodols. Tas auditoriem nodrošina pirmo pierādījumu objektu — reģistru, kas sasaista SaaS izmantošanu ar īpašniekiem, datiem, ģeogrāfiju, piekļuvi un līgumiem.

Tā pati Cloud Usage Policy-sme sadaļā “Politikas ieviešanas prasības”, politikas 6.2. punkts, definē pamatlīmeņa iestatījumus:

Drošības konfigurācijas prasības 6.2.1 Visās mākoņplatformās ir jāiespējo turpmāk minētais: 6.2.2 Daudzfaktoru autentifikācija (MFA) administratīvajiem un lietotāju kontiem 6.2.3 Paroļu sarežģītības iestatījumi (vismaz 10 rakstzīmes, bez atkārtotas izmantošanas) 6.2.4 Darbību žurnalēšana pieteikšanās mēģinājumiem un datu piekļuvei 6.2.5 Piekļuves ierobežojumi (piemēram, IP iekļaušana atļauto sarakstā, ja tas tiek atbalstīts) 6.2.6 Administratīvā piekļuve jāierobežo līdz vārdiskām personām vai autorizētiem atbalsta pakalpojumu sniedzējiem. 6.2.7 Publiski koplietots saturs ir regulāri jāuzrauga, lai novērstu datu noplūdi. 6.2.8 Kad lietotāju konti vairs nav nepieciešami, piekļuve nekavējoties jāatsauc un visi atlikušie dati ir jāpārskata un jāarhivē vai jādzēš.

Uzņēmumu vidēs Cloud Usage Policy Cloud Usage Policy piešķir stingrāku centralizētu pārvaldību. No sadaļas “Pārvaldības prasības”, politikas 5.3. punkts:

Katram mākoņpakalpojumam jābūt piešķirtam pakalpojuma īpašniekam, kurš ir atbildīgs par informācijas aktīva dzīves cikla pārvaldību, lietošanas pārvaldību, budžeta izsekošanu un pastāvīgu atbilstības uzraudzību.

Šis teikums novērš bieži sastopamu audita trūkumu. Ja SaaS pakalpojumam nav īpašnieka, neviens neatbild par konfigurācijas novirzi, piekļuves atkārtotu sertificēšanu, datu ekspozīciju, atjaunošanas lēmumiem, incidenta kontaktpersonu vai izstāšanās plānošanu.

Priviliģētās piekļuves pārvaldībai arī jābūt skaidri noteiktai. User Account and Privilege Management Policy-sme User Account and Privilege Management Policy - SME sadaļā “Politikas ieviešanas prasības”, politikas 6.4. punkts, nosaka:

Piekļuves tiesību pārskatīšana un žurnalēšana 6.4.1 Visu lietotāju kontu un privilēģiju pārskatīšana jāveic reizi sešos mēnešos. 6.4.2 Pārskatīšanas laikā IT vadītājam ir jāvalidē, vai katrs konts joprojām ir aktīvs, nepieciešams un tam ir piešķirtas pareizās piekļuves tiesības. 6.4.3 Kontu izveides, kontu deaktivizēšanas un privilēģiju izmaiņu žurnāli droši jāglabā vismaz 12 mēnešus.

SaaS kontekstā katrai kritiskai platformai ir vajadzīgs definēts piekļuves tiesību pārskatīšanas cikls, pat ja platformu administrē biznesa komanda, nevis centralizēts IT.

Arī žurnalēšanai jābūt skaidri noteiktai. Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME sadaļā “Pārvaldības prasības”, politikas 5.5. punkts, nosaka:

Mākoņpakalpojumi un trešo pušu žurnalēšana 5.5.1 Platformām, kurās žurnalēšana nav tiešā IT kontrolē (piemēram, SaaS e-pasts), piemēro šādas prasības: 5.5.1.1 Žurnalēšana jāiespējo un jākonfigurē, ja tā ir pieejama 5.5.1.2 Brīdinājumi jānovirza IT atbalsta pakalpojumu sniedzējam 5.5.1.3 Līgumos jānosaka pakalpojumu sniedzējiem pienākums glabāt žurnālus vismaz 12 mēnešus un pēc pieprasījuma nodrošināt piekļuvi

Visbeidzot, SaaS piegādātāju pārvaldība ir jādokumentē. Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME sadaļā “Politikas ieviešanas prasības”, politikas 6.3. punkts, nosaka:

Pastāvīga piegādātāju drošības uzraudzība 6.3.1 Kritiski vai augsta riska piegādātāji jāpārskata vismaz reizi gadā. Pārskatīšanā jāpārbauda: 6.3.1.1 Drošu piekļuves metožu turpmāka izmantošana 6.3.1.2 Derīgas drošības sertifikācijas vai atjaunināti kontroles pierādījumi 6.3.1.3 Incidentu vēsture vai ziņotās problēmas 6.3.1.4 Līgumiskā atbilstība drošības klauzulām 6.3.2 Šīs pārskatīšanas ir jādokumentē un jāglabā kopā ar piegādātāja ierakstu. Turpmākās darbības ir skaidri jāizseko. 6.3.3 Ja piegādātāji pārvalda IT infrastruktūru vai lietojumprogrammas, uzraudzība var ietvert: 6.3.3.1 Audita žurnālu pieprasīšanu 6.3.3.2 Kontu aktivitātes pārskatīšanu 6.3.3.3 Apstiprinājumu, ka nav notikusi nesankcionēta piekļuve

Kopā šīs politikas pārvērš SSPM no drošības ieceres par piemērojamu darbības modeli.

30 dienu SSPM pierādījumu sprints

Praktisks informācijas drošības vadītājs vai atbilstības vadītājs var sākt ar 30 dienu pierādījumu sprintu. Izvēlieties piecas SaaS platformas, kas ir vissvarīgākās regulētiem datiem vai kritiskām operācijām. Tipiski kandidāti ir Microsoft 365 vai Google Workspace, CRM, pieteikumu pārvaldības rīki, HRIS, finanšu automatizācija, klientu atbalsts un analītika.

1. nedēļa: izveidojiet SaaS reģistru

Izmantojiet Cloud Usage Policy-sme 5.3. punkta laukus kā minimālo reģistru. Par katru SaaS pakalpojumu fiksējiet:

• Pakalpojuma nosaukumu un biznesa mērķi
• Lietotnes īpašnieku un tehnisko īpašnieku
• Datu veidus, tostarp personas datus un īpašu kategoriju datus, ja piemērojams
• Datu glabāšanas valsti vai reģionu
• Lietotāju grupas un administratoru kontus
• OAuth lietotnes un trešo pušu integrācijas
• Līguma īpašnieku, atjaunošanas datumu un atbalsta kontaktpersonu
• Darbības kritiskumu
• Piemērojamos pienākumus, piemēram, NIS2, DORA, GDPR vai klientu līgumus

Tas atbalsta ISO/IEC 27001:2022 punktus 4.2 un 4.3, jo regulatīvajām, līgumiskajām un trešo pušu atkarībām ir jāveido IDPS darbības joma. Tas atbalsta arī DORA Article 8 pieejai līdzīgu IKT atbalstītu biznesa funkciju, informācijas aktīvu, IKT aktīvu un atkarību identificēšanu un klasifikāciju.

2. nedēļa: definējiet drošas pamatkonfigurācijas

Katrai izvēlētajai SaaS platformai definējiet 10 līdz 15 pamatlīmeņa kontroles pasākumus.

• MFA obligāti visiem lietotājiem, un administratoriem — pret pikšķerēšanu noturīga MFA, ja iespējams
• Ārēja koplietošana pēc noklusējuma atspējota vai ierobežota līdz apstiprinātiem domēniem
• Publiskās saites atspējotas vai ar laika ierobežojumu
• Viesu konti pārskatīti katru mēnesi
• Administratoru lomas piešķirtas vārdiskām personām
• Mantotā autentifikācija atspējota
• Iespējota OAuth lietotņu apstiprināšanas darbplūsma
• Augsta riska OAuth tvērumi bloķēti vai tiem nepieciešams drošības apstiprinājums
• Iespējota audita žurnālu reģistrēšana
• Datu eksporta piekļuves tiesības ierobežotas
• Glabāšanas iestatījumi saskaņoti ar juridiskajām un biznesa prasībām
• API marķieri pārskatīti un rotēti
• Drošības brīdinājumi novirzīti IT vai SOC
• Datu zuduma novēršanas iestatījumi iespējoti, ja tie tiek atbalstīti
• Ārkārtas piekļuves konti dokumentēti un uzraudzīti

Zenith Blueprint sadaļā Controls in Action, 19. solī, 8.9. kontroles pasākumā par konfigurāciju pārvaldību, skaidro, kāpēc tas ir svarīgi:

Daudzi pārkāpumi nerodas programmatūras trūkumu dēļ — tie rodas sliktu konfigurācijas izvēļu dēļ. Nemainītas noklusējuma paroles, iespējoti nedroši pakalpojumi, atvērti nevajadzīgi porti vai internetam eksponētas sistēmas bez pamatojuma. 8.9. kontroles pasākums nodrošina, ka katra sistēma tiek veidota atbilstoši drošai pamatkonfigurācijai un regulāri pārskatīta, lai laika gaitā novērstu novirzi.

SaaS vidē konfigurācijas novirze ietver situācijas, kad biznesa īpašnieks iespējo publisku koplietošanu, administrators apstiprina plašu trešās puses piekļuvi vai piegādātājs maina noklusējuma iestatījumus pēc funkcijas laidiena.

3. nedēļa: pārskatiet piekļuvi un integrācijas

Eksportējiet lietotājus, grupas, administratorus un pieslēgtās lietojumprogrammas. Katram administratora kontam apstipriniet vārdisko personu, biznesa pamatojumu, MFA statusu, pēdējo pieteikšanos, privilēģiju līmeni, rezerves kopiju pārklājumu, pienākumu nodalīšanas apsvērumus un apstiprinājuma pierādījumus.

OAuth lietotnēm un integrācijām apstipriniet lietotnes īpašnieku, piekļūtos datus, pieprasītās piekļuves tiesības, piegādātāja riska statusu, pēdējās izmantošanas datumu, turpmāko nepieciešamību un to, vai piekrišanu piešķīris lietotājs vai apstiprinājis administrators.

Zenith Blueprint sadaļā Controls in Action, 19. solī, 8.3. kontroles pasākumā par informācijas piekļuves ierobežošanu, nosaka darbības principu:

Piekļuvei informācijai jābūt tik atvērtai, cik nepieciešams, bet tik ierobežotai, cik iespējams.

Tas attiecas ne tikai uz cilvēkiem, bet arī uz lietojumprogrammām, pakalpojumiem un lietojumprogrammu saskarnēm. Neaktīva OAuth integrācija var saglabāt piekļuvi ilgi pēc tam, kad darbinieks vai projekts, kas to izveidoja, vairs nepastāv.

4. nedēļa: sagatavojiet auditam gatavus pierādījumus un riska apstrādi

Par katru SaaS platformu saglabājiet reģistra ierakstu, pamatkonfigurāciju, ekrānuzņēmumus vai eksportus, kas apliecina galvenos iestatījumus, piekļuves tiesību pārskatīšanas apstiprinājumu, administratoru pārskatīšanas pierādījumus, OAuth pārskatīšanas pierādījumus, žurnalēšanas un brīdināšanas pierādījumus, piegādātāja drošības pārskatīšanas ierakstu, atvērtos konstatējumus un riska apstrādes darbības.

Pēc tam izveidojiet vienas lapas vadības kopsavilkumu, kurā parādīti kritiskie konstatējumi, kavētie īpašnieki, neatrisinātie augsta riska konfigurācijas trūkumi, neapstiprinātas integrācijas, žurnalēšanas trūkumi, izņēmumi un nepieciešamie lēmumi. Tas atbalsta ISO/IEC 27001:2022 9.1. punktu par uzraudzību, 9.2. punktu par iekšējo auditu un 9.3. punktu par vadības pārskatīšanu. Tas arī veido praktisku sasaisti ar NIS2 Article 20 vadības pārskatatbildību un DORA vadības struktūras pārraudzību.

Starpatbilstības kartēšana: viena SSPM pierādījumu pakotne, daudz pienākumu

SSPM biznesa vērtība nav tikai labāka drošība. Tā ir atbilstības dublēšanās samazināšana.

NIS2 Article 21 prasa atbilstošus un samērīgus tehniskos, operacionālos un organizatoriskos pasākumus. SaaS uzskaite atbalsta aktīvu pārvaldību. Pamatkonfigurācijas atbalsta kiberdrošības higiēnu. MFA un piekļuves tiesību pārskatīšana atbalsta piekļuves kontroli. Žurnalēšana atbalsta incidentu apstrādi. Piegādātāju pārskatīšana atbalsta piegādes ķēdes drošību. Pierādījumu periodiskums atbalsta politikas un procedūras efektivitātes izvērtēšanu.

DORA prasa finanšu iestādēm identificēt un klasificēt IKT atbalstītas funkcijas, informācijas aktīvus, IKT aktīvus un trešo pušu atkarības. Tā prasa arī aizsardzības un preventīvos pasākumus, piekļuves kontroles pasākumus, stipru autentifikāciju, šifrēšanu, nepārtrauktību, testēšanu, incidentu pārvaldību un IKT trešo personu risku pārvaldību. SaaS SSPM pierādījumu pakotne var atbalstīt DORA reģistrus, atkarību kartēšanu, līgumu pārraudzību, audita tiesības un izstāšanās plānošanu.

GDPR prasa pārziņiem pierādīt atbilstību integritātei, konfidencialitātei un pārskatatbildībai. SaaS reģistri identificē, kur tiek apstrādāti personas dati. Pamatkonfigurācijas samazina nesankcionētas izpaušanas risku. Piekļuves tiesību pārskatīšana atbalsta minimāli nepieciešamās tiesības. Žurnalēšana atbalsta pārkāpuma izmeklēšanu. Piegādātāju ieraksti atbalsta apstrādātāju pārvaldību un pārskatatbildību.

NIST CSF 2.0 pievieno noderīgu komunikācijas slāni. Tā GOVERN funkcija prasa izprast un pārvaldīt juridiskās, regulatīvās un līgumiskās kiberdrošības prasības. Tā piegādes ķēdes rezultāti prasa piegādātāju lomas, līgumus, sākotnējo izpēti, uzraudzību un darbības pēc attiecību beigām. Tā IDENTIFY, PROTECT, DETECT, RESPOND un RECOVER funkcijas dabiski sasaistās ar SaaS uzskaiti, piekļuves kontroli, datu aizsardzību, žurnalēšanu, incidentu reaģēšanu un atjaunošanu.

COBIT 2019 un uz ISACA orientēti auditori parasti vērtēs SSPM caur pārvaldību, vadības mērķiem, atbildību par risku, kontroles darbību un apliecinājumu. Viņi jautās, vai SaaS lēmumi ir saskaņoti ar uzņēmuma mērķiem, vai riska atbildes ir dokumentētas, vai pienākumi ir piešķirti un vai apliecinājuma darbības pierāda, ka kontroles pasākumi darbojas.

Audita skatījums: kā dažādi auditori testē SaaS stāvokli

Spēcīga SSPM programma iztur dažādus audita stilus, jo tā nodrošina pierādījumus pareizajā līmenī.

ISO/IEC 27001:2022 auditors sāks ar darbības jomu, ieinteresētajām pusēm, risku izvērtēšanu, Piemērojamības paziņojumu un operacionālajiem pierādījumiem. Ja ir iekļauts 5.23. kontroles pasākums, auditors sagaidīs pierādījumus par mākoņpakalpojumu izvēli, izmantošanu, pārvaldību un izbeigšanu. Ja ir iekļauti piekļuves tiesību kontroles pasākumi, auditors atlasīs lietotāju izlasi un jautās, vai darbinieku pieņemšanas, pārcelšanas un atbrīvošanas izmaiņas ir atspoguļotas SaaS piekļuves tiesībās.

DORA pārskatītājs koncentrēsies uz kritiskām vai svarīgām funkcijām, IKT trešo personu atkarībām, reģistra pilnīgumu, līgumiem, incidentu klasifikāciju, testēšanu un izstāšanās plānošanu. Ja SaaS platforma atbalsta maksājumu operācijas, klientu uzņemšanu, tirdzniecību, risku analītiku vai klientu komunikāciju, pierādījumu standarts paaugstinās.

GDPR auditors vai privātuma pārskatītājs jautās, kur tiek glabāti personas dati, kam tie ir pieejami, kādi eksporta un koplietošanas iestatījumi pastāv, vai apstrādātāji tiek pārvaldīti, vai žurnāli atbalsta pārkāpuma izvērtēšanu un vai kontroles pasākumi ir samērīgi ar risku.

Piegādātāju risks, kopīgā atbildība un gatavība incidentiem

SSPM bieži sākas ar konfigurāciju, bet ar to tā nedrīkst beigties. SaaS ir arī piegādātāju riska un gatavības incidentiem jautājums.

DORA prasa finanšu iestādēm uzturēt IKT pakalpojumu līgumu reģistrus, nošķirt vienošanās, kas atbalsta kritiskas vai svarīgas funkcijas, izvērtēt koncentrācijas risku, novērtēt pakalpojumu sniedzēja piemērotību un uzturēt izstāšanās stratēģijas. Līgumos jāparedz pakalpojumu apraksti, datu atrašanās vieta, pieejamības, autentiskuma, integritātes un konfidencialitātes aizsardzība, datu piekļuve, atjaunošana un atdošana, palīdzība incidentu gadījumā, sadarbība ar iestādēm, izbeigšanas tiesības, drošības prasības, audita tiesības un pārejas atbalsts.

NIS2 Article 21 ietver arī piegādes ķēdes drošību un prasa vienībām ņemt vērā ievainojamības, kas raksturīgas tiešajiem piegādātājiem un pakalpojumu sniedzējiem, produktu kvalitāti un piegādātāju kiberdrošības prakses.

Praksē kritiska SaaS pārskatīšana jāapvieno ar drošības anketas pierādījumiem, līguma pārskatīšanu, datu apstrādes līguma statusu, incidentu vēsturi, pakalpojumu līmeņa saistībām, piekļuvi žurnāliem, audita pārskatiem, konfigurācijas pierādījumiem un izstāšanās īstenojamību.

Kopīgās atbildības trūkums parādās, kad komandas pieņem, ka piegādātāja sertifikācija aptver nomnieka konfigurāciju. Tā nav. Piegādātājs var darbināt drošu platformu, kamēr klients iespējo publisku koplietošanu, atstāj aktīvus neaktīvus administratoru kontus vai piešķir pārmērīgus API tvērumus. SSPM aizver šo trūkumu.

Tikpat svarīga ir gatavība incidentiem. NIS2 ziņošana par būtiskiem incidentiem ietver 24 stundu agrīnu brīdinājumu, 72 stundu paziņojumu un galīgo ziņojumu ne vēlāk kā mēnesi pēc 72 stundu paziņojuma. DORA prasa ar IKT saistītu incidentu pārvaldību ar atklāšanu, reģistrēšanu, klasifikāciju, eskalāciju, komunikāciju un paziņošanu. GDPR personas datu aizsardzības pārkāpuma izvērtēšana arī ir atkarīga no savlaicīgas izpratnes par to, kas notika, kādi dati tika skarti un kurus tas ietekmēja.

Ja aizdomīga OAuth lietotne piekļuva klientu failiem, jums jāzina, kad lietotne tika autorizēta, kurš lietotājs to autorizēja, kādi tvērumi tika piešķirti, kādiem datiem tika piekļūts, vai dati tika lejupielādēti vai koplietoti, kuri lietotāji vai klienti tika skarti, vai piekļuve joprojām ir aktīva un kādas ierobežošanas darbības tika veiktas.

Bez žurnalēšanas un glabāšanas organizācija var būt spiesta pieņemt sliktākā scenārija pieņēmumus. Tas palielina tiesisko ietekmi, spiedienu klientu komunikācijā un regulatīvo nenoteiktību. Ja SaaS pakalpojumu sniedzējs par audita žurnāliem iekasē papildu maksu, riska īpašniekam ir skaidri jāpieņem atlikušais risks vai jāapstiprina nepieciešamais licences līmenis. Šim lēmumam jābūt riska apstrādes ierakstā un vadības pārskatīšanā.

Biežākie SSPM kļūmju modeļi

Vienādi kļūmju modeļi parādās dažādās nozarēs.

Pirmkārt, ēnu SaaS tiek atklāts pēc rēķiniem, pārlūkprogrammu vēstures vai SSO žurnāliem, nevis iepirkuma procesā. Risinājums nav tikai rīku bloķēšana. Vajadzīgs vienkāršs pieprasījumu uzņemšanas process, ko biznesa komandas var izmantot.

Otrkārt, SaaS īpašumtiesības ir neskaidras. CRM “pieder pārdošanai”, bet neviens pārdošanas komandā nevar izskaidrot administratoru lomas, API marķierus, datu eksportus vai glabāšanas iestatījumus. Lietotņu īpašnieki un tehniskie īpašnieki jāpiešķir atsevišķi.

Treškārt, piekļuves tiesību pārskatīšana ir pārāk vispārīga. Pārskatītājs apstiprina “visi lietotāji apstiprināti”, nepārbaudot augsta riska lomas, neaktīvus lietotājus, viesus, ārējos sadarbības partnerus vai pakalpojumu kontus. SSPM piekļuves tiesību pārskatīšanai jābūt uz risku balstītai.

Ceturtkārt, OAuth lietotnes tiek ignorētas. Daudzas organizācijas pārskata cilvēku lietotājus, bet ne lietotņu savstarpējās piekļuves tiesības. Mūsdienu SaaS vidē integrācijas var būt jaudīgākas nekā lietotāji.

Piektkārt, pamatkonfigurācijas pastāv tikai kā ekrānuzņēmumi no sertifikācijas projekta. Tās netiek uzraudzītas attiecībā uz novirzi. Saskaņojiet SSPM ar konfigurāciju pārvaldību, lai pamatkonfigurācijas pārbaudes kļūtu par regulāriem pierādījumiem.

Sestkārt, piegādātāju pārskatīšana un SaaS stāvokļa pārskatīšana ir nodalītas. Iepirkumam ir līgums, IT ir administratīvā konsole, privātuma funkcijai ir datu apstrādes līgums, un drošībai ir riska reģistrs. Auditors redz fragmentus. SSPM tos apvieno.

Vadības ziņošana: padariet SaaS risku redzamu valdei

NIS2 un DORA IKT un kiberdrošības pārvaldību padara par vadības jautājumu. ISO/IEC 27001:2022 arī prasa līderību, resursus, lomu piešķiršanu, uzraudzību un vadības pārskatīšanu.

Efektīvam SSPM vadības ziņojumam jāatbild uz šādiem jautājumiem:

• Kuri kritiskie SaaS pakalpojumi ir darbības jomā?
• Kuri regulētie procesi no tiem ir atkarīgi?
• Kuros ir personas dati vai sensitīvi biznesa dati?
• Kuriem ir kavētas piekļuves tiesību pārskatīšanas?
• Kuriem ir neatrisināti augsta riska konfigurācijas trūkumi?
• Kuriem ir neapstiprinātas OAuth lietotnes vai integrācijas?
• Kuriem piegādātājiem trūkst aktuālu drošības pierādījumu?
• Kuri žurnalēšanas trūkumi ietekmē incidentu ziņošanu?
• Kuriem izņēmumiem nepieciešama riska pieņemšana?
• Kādi ieguldījumi vai lēmumi ir nepieciešami?

Tas pārvērš SSPM no tehniska sakārtošanas projekta par pārvaldības ievadi. Tas arī padara informācijas drošības vadītāju efektīvāku, jo riska pieņemšana tiek pārcelta uz pareizo līmeni.

Pārvērtiet SaaS stāvokli auditam gatavos pierādījumos

Ja jūsu organizācija paļaujas uz SaaS regulētiem datiem, finanšu operācijām, klientu atbalstam, HR, sadarbībai, inženierijai vai analītikai, SSPM vairs nav izvēles jautājums. Tā ir daļa no kiberdrošības higiēnas, IKT risku pārvaldības, privātuma pārskatatbildības un gatavības auditam.

Clarysec var palīdzēt pāriet no sadrumstalotiem SaaS konstatējumiem uz strukturētu, pierādījumos balstītu programmu, izmantojot:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, lai strukturētu ieviešanu mākoņpakalpojumu izmantošanas, piekļuves ierobežošanas un konfigurāciju pārvaldības jomās.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls, lai sasaistītu ISO/IEC 27002:2022 kontroles pasākumus ar NIS2, DORA, GDPR, NIST CSF 2.0 un audita gaidām.
• Clarysec politiku veidnes, piemēram, Cloud Usage Policy Cloud Usage Policy, Cloud Usage Policy-sme Cloud Usage Policy - SME, User Account and Privilege Management Policy-sme User Account and Privilege Management Policy - SME, Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME un Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, lai izveidotu piemērojamus darbības noteikumus.

Sāciet ar piecām augstākā riska SaaS platformām. Piešķiriet īpašniekus. Fiksējiet datus, piekļuvi, konfigurāciju, integrācijas, žurnālus un piegādātāju pierādījumus. Pārvērtiet konstatējumus riska apstrādes darbībās un vadības lēmumos.

Tādējādi SaaS drošības stāvokļa pārvaldība kļūst par vairāk nekā rīku kategoriju. Tā kļūst par aizstāvamu atbilstības disciplīnu 2026. gadam.

Lejupielādējiet Clarysec politiku veidnes, izmantojiet Zenith Blueprint, lai plānotu savu 30 dienu SSPM pierādījumu sprintu, un kartējiet savus SaaS kontroles pasākumus ar Zenith Controls, pirms nākamais audits atrod trūkumus jūsu vietā.