SaaS saugumo būklės valdymas 2026 m. auditams

SaaS audito išvada, už kurią niekas nebuvo atsakingas

Antradienį 08:15 sparčiai augančios finansinių technologijų įmonės CISO gauna žinutę iš duomenų apsaugos pareigūno (DAP): „Kodėl klientų eksportas iš bendradarbiavimo priemonės gali būti viešai bendrinamas ir kas patvirtino OAuth taikomąją programą, galinčią jį nuskaityti?“

Iki 09:00 finansų skyrius patvirtina, kad už priemonę mokama padalinio kortele, o ne per centralizuotą pirkimų procesą. Iki 10:30 IT nustato, kad viešą nuorodą sukūręs naudotojas darbo santykius nutraukė prieš tris mėnesius. Vidurdienį Teisės skyrius klausia, ar tai yra GDPR asmens duomenų saugumo pažeidimas. 14:00 Rizikos komitetas klausia, ar problema turi įtakos NIS2 kibernetinei higienai ir DORA IRT trečiųjų šalių rizikai. 16:00 vidaus auditorius paprašo bazinių konfigūracijų, administratorių prieigos peržiūrų, debesijos paslaugos savininko, žurnalų ir tiekėjų deramo patikrinimo įrodymų.

Skaudi tiesa ta, kad organizacija nepatyrė klasikinio SaaS paslaugos nepasiekiamumo ar tiekėjo gedimo. Ji patyrė valdysenos nesėkmę.

Toks scenarijus nebėra išimtis. Rinkodaros komanda prijungia AI platformą prie CRM su plačiais OAuth leidimais. Žmogiškųjų išteklių komanda įsigyja nišinę analitikos priemonę apeidama pirkimų procesą. Klientų aptarnavimo komanda patogumo sumetimais įgalina viešą užklausų eksportą. Inžinerijos komanda į kūrimo darbo eigą integruoja naršyklės plėtinį. Kiekvienas sprendimas gali atrodyti nedidelis, tačiau kartu jie sukuria paskirstytą kontrolės paviršių, kuriame yra reglamentuojami duomenys, privilegijuotos darbo eigos ir veiklos priklausomybės.

SaaS saugumo būklės valdymas, arba SSPM, yra disciplina, kuri suskaidytą SaaS realybę paverčia valdomomis, testuojamomis ir audituojamomis kontrolės priemonėmis. Tinkamai įgyvendintas SSPM CISO, atitikties vadovams, auditoriams ir verslo savininkams suteikia bendrą įrodymų grandinę ISO/IEC 27001:2022, NIS2 kibernetinei higienai, DORA IRT rizikai ir GDPR saugumo atskaitomybei.

Clarysec pozicija aiški: SSPM neturi būti vertinamas kaip dar vienas valdymo skydas. Jis turi būti integruotas į ISVS, susietas su rizikos savininkais ir teisinėmis prievolėmis, pagrįstas politika ir periodiškai tikrinamas renkamais įrodymais.

Būtent čia Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls ir Clarysec politikų šablonai tampa praktiški. Jie padeda SaaS išplitimą paversti kontrolės modeliu, kurį auditorius gali suprasti, o valdymo organas — prižiūrėti.

Kodėl SaaS saugumo būklės valdymas tapo atitikties klausimu

Anksčiau SaaS buvo traktuojama kaip „programinė įranga, kurią valdo kažkas kitas“. Toks požiūris nebėra pagrįstas.

Pagal NIS2 daugelis debesijos, SaaS, skaitmeninės infrastruktūros, valdomų paslaugų ir valdomo saugumo paslaugų teikėjų gali patekti į reglamentuojamų kibernetinio saugumo lūkesčių taikymo sritį, priklausomai nuo sektoriaus, dydžio, vaidmens ir kritiškumo. Dar svarbiau tai, kad SaaS naudojančios organizacijos privalo ją valdyti kaip savo rizikos valdymo priemonių dalį. NIS2 Article 20 valdymo organams nustato atsakomybę tvirtinti kibernetinio saugumo rizikos valdymo priemones, prižiūrėti jų įgyvendinimą ir dalyvauti mokymuose. Article 21 reikalauja praktinių techninių, operacinių ir organizacinių priemonių, įskaitant rizikos analizę, politikas, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą ir priežiūrą, veiksmingumo testavimą, kibernetinę higieną, kriptografiją, žmogiškųjų išteklių saugumą, prieigos kontrolę, turto valdymą ir, kai tinkama, kelių veiksnių autentifikavimą.

DORA finansų subjektams kartelę pakelia dar aukščiau. Nuo 2025 m. sausio 17 d. DORA daugeliui finansų sektoriaus organizacijų taikomas kaip veiklos atsparumo režimas į taikymo sritį patenkantiems subjektams. Jis reikalauja IRT valdysenos, IRT turto ir palaikomų funkcijų identifikavimo bei klasifikavimo, apsaugos ir prevencijos kontrolės priemonių, incidentų valdymo, tęstinumo, testavimo ir IRT trečiųjų šalių rizikos valdymo. SaaS teikėjai, palaikantys kritines ar svarbias funkcijas, tampa DORA įrodymų perimetro dalimi, o reglamentuojamas finansų subjektas išlieka atsakingas.

GDPR prideda privatumo įrodymų sluoksnį. Article 5 reikalauja vientisumo, konfidencialumo ir atskaitomybės. Article 32 reikalauja tinkamo tvarkymo saugumo. Praktikoje organizacija turi žinoti, kokie asmens duomenys egzistuoja, kur jie tvarkomi, kas gali juos pasiekti, kokie tiekėjai juos tvarko ir kokios apsaugos priemonės juos saugo. Neteisinga SaaS konfigūracija šiuos klausimus paverčia skubiais pažeidimo vertinimo klausimais.

ISO/IEC 27001:2022 yra jungiamoji grandis. 4.1–4.4 punktai reikalauja, kad organizacija apibrėžtų kontekstą, suinteresuotųjų šalių reikalavimus, taikymo sritį, sąsajas ir priklausomybes. 5 punktas reikalauja lyderystės, politikos, vaidmenų ir atskaitomybės. 6.1.1–6.1.3 punktai reikalauja rizikos vertinimo, rizikos tvarkymo, Taikytinumo pareiškimo ir sprendimų dėl liekamosios rizikos. 8.1, 8.2 ir 8.3 punktai reikalauja operacinio planavimo, rizikos vertinimo ir rizikos tvarkymo. 9 ir 10 punktai reikalauja stebėsenos, vidaus audito, vadovybės peržiūros ir tobulinimo.

Jei negalite atsakyti, kurios SaaS priemonės tvarko reglamentuojamus duomenis, kam jos priklauso, kaip jos sukonfigūruotos, kas turi administratoriaus lygmens prieigą, kokios integracijos aktyvios ir kokie įrodymai patvirtina, kad kontrolės priemonės veikia, jūsų atitikties pozicija yra trapi.

Clarysec SSPM modelis: registras, savininkai, bazinė konfigūracija, įrodymai

Clarysec SaaS saugumo būklės valdymą traktuoja kaip kartotinį kontrolės ciklą, o ne kaip vienkartinį sutvarkymo projektą.

1. Aptikti kiekvieną SaaS paslaugą, įskaitant šešėlinį SaaS.
2. Priskirti verslo savininką ir techninį savininką.
3. Klasifikuoti duomenis, naudotojus, integracijas ir operacinį kritiškumą.
4. Taikyti saugias bazines konfigūracijas.
5. Peržiūrėti naudotojus, administratorius, svečius, paslaugų paskyras ir OAuth taikymo sritis.
6. Įgalinti žurnalavimą, įspėjimus ir saugojimo terminus.
7. Stebėti viešą bendrinimą ir duomenų atskleidimą.
8. Susieti tiekėjus, sutartis, duomenų tvarkymo sutartis ir išėjimo planavimą.
9. Rinkti įrodymus nustatytu periodiškumu.
10. Perduoti išvadas į rizikos tvarkymą, vadovybės peržiūrą ir tobulinimą.

Šis modelis glaudžiai dera su ISO/IEC 27002:2022 ISO/IEC 27002:2022 kontrolės priemonėmis, ypač 5.9 informacijos ir kito susijusio turto inventorizacija, 5.15 prieigos kontrolė, 5.18 prieigos teisės, 5.19 informacijos saugumas santykiuose su tiekėjais, 5.20 informacijos saugumo reglamentavimas tiekėjų sutartyse, 5.21 informacijos saugumo valdymas IRT tiekimo grandinėje, 5.23 informacijos saugumas naudojant debesijos paslaugas, 8.2 privilegijuotos prieigos teisės, 8.3 prieigos prie informacijos ribojimas, 8.9 konfigūracijų valdymas, 8.15 žurnalavimas, 8.16 stebėsenos veikla ir 8.32 pakeitimų valdymas.

Zenith Blueprint, etape „Controls in Action“, 23 žingsnyje dėl organizacinių kontrolės priemonių, nurodoma:

Debesija nebėra paskirties vieta — ji tapo numatytuoju veikimo būdu. Nuo saugyklų iki bendradarbiavimo, nuo infrastruktūros iki mašininio mokymosi — organizacijos vis dažniau kuriamos ant trečiųjų šalių, abstrahuotų ir nuotoliniu būdu valdomų aplinkų sluoksnių. Kontrolės priemonė 5.23 pripažįsta šią realybę ir reikalauja, kad informacijos saugumas būtų aiškiai įtrauktas į debesijos paslaugų pasirinkimą, naudojimą ir valdymą ne kaip papildomas svarstymas, o kaip projektavimo principas nuo pat pradžių.

Tai yra SSPM esmė. Tai nėra vien neteisingos konfigūracijos aptikimas po fakto. Tai SaaS pasirinkimo, įvedimo į eksploatavimą, naudojimo, stebėsenos ir išėjimo įtraukimas į valdymo sistemą.

Ta pati Zenith Blueprint dalis paaiškina bendros atsakomybės realybę taip, kaip turėtų išgirsti kiekvienas valdybos narys:

Debesijos paslaugų teikėjai saugo infrastruktūrą, tačiau jūs vis tiek esate atsakingi už savo duomenis, savo konfigūracijas, savo prieigos politikas ir savo pasirengimą reagavimui į incidentus. Neteisingai sukonfigūruotas saugyklos konteineris, viešai pasiekiamas valdymo skydas ar pertekliniai leidimai debesijos IAM sąrankoje nėra debesijos gedimai. Tai yra valdysenos nesėkmės.

Jūsų paslaugų teikėjas gali eksploatuoti platformą, tačiau jūs vis tiek valdote nuomininko konfigūraciją, tapatybes, prieigos patvirtinimus, atskleistus duomenis, integracijas, incidentų darbo eigas ir atitikties įrodymus.

Kontrolės priemonė 5.23 yra atrama, tačiau SSPM reikia kontrolės priemonių šeimos

Zenith Controls ISO/IEC 27002:2022 kontrolės priemonė 5.23, informacijos saugumas naudojant debesijos paslaugas, priskiriama prevencinei kontrolės priemonei, palaikančiai konfidencialumą, vientisumą ir prieinamumą. Jos kibernetinio saugumo koncepcija yra Protect, o operacinis gebėjimas — tiekėjų santykių saugumas, apimantis valdysenos, ekosistemos ir apsaugos sritis.

Tai svarbu, nes SSPM nėra viena kontrolės priemonė. Tai tarpdisciplininė kontrolės praktika.

Zenith Controls susieja 5.23 su tiekėjų santykiais pagal 5.19, nes SaaS teikėjai yra kritiniai tiekėjai, tačiau 5.23 papildo šią sritį specifiniais SaaS klausimais, tokiais kaip kelių nuomininkų architektūra, duomenų vietos skaidrumas ir bendra atsakomybė. Ji susieja 5.23 su informacijos perdavimu, nes taikomųjų programų sąsajos, integracijos ir tarp-SaaS darbo eigos nuolat perkelia duomenis. Ji susieja 5.23 su turto inventorizacija, nes organizacijoms reikia aktualaus matomumo apie debesijoje saugomus duomenis ir SaaS išteklius. Ji taip pat susieja debesijos valdyseną su stebėsena, prieigos ribojimu, konfigūracijų valdymu ir tiekėjų priežiūra.

Dėl prieigos teisių Zenith Controls susieja 5.18 su 5.15 prieigos kontrole, 5.16 tapatybių valdymu, 5.3 pareigų atskyrimu, 5.36 informacijos saugumo politikų, taisyklių ir standartų laikymusi ir 8.2 privilegijuotos prieigos teisėmis. SSPM kontekste tai reiškia, kad prieigos peržiūra nėra vien skaičiuoklės užduotis. Tai operacinis įrodymas, kad tapatybės gyvavimo ciklas, mažiausių privilegijų principas, pareigų atskyrimas ir privilegijuotos prieigos valdysena veikia SaaS taikomosiose programose.

Politikos pagrindas: apibrėžkite tinkamą praktiką prieš pirkdami įrankius

Daugelis SaaS nesėkmių prasideda dėl neaiškios politikos kalbos. „Saugiai naudokite patvirtintas priemones“ nepakanka. Clarysec politikos apibrėžia konkrečius registro, prieigos, žurnalavimo, konfigūracijos ir tiekėjų peržiūros lūkesčius.

MVĮ atveju Cloud Usage Policy-sme Debesijos paslaugų naudojimo politika - MVĮ suteikia praktišką pradžios tašką. Iš skyriaus „Valdysenos reikalavimai“, politikos sąlyga 5.3:

Debesijos paslaugų registrą turi tvarkyti IT paslaugų teikėjas arba generalinis direktorius. Jame turi būti įrašyta: 5.3.1 Kiekvienos patvirtintos debesijos paslaugos pavadinimas ir paskirtis 5.3.2 Atsakingas asmuo arba komanda (taikomosios programos savininkas) 5.3.3 Saugomų arba tvarkomų duomenų tipai 5.3.4 Šalis arba regionas, kuriame saugomi duomenys 5.3.5 Naudotojų prieigos leidimai ir administracinės paskyros 5.3.6 Sutarties duomenys, atnaujinimo datos ir pagalbos kontaktai

Ši sąlyga yra operacinė SSPM šerdis. Ji auditoriams pateikia pirmąjį įrodymų objektą: registrą, kuris susieja SaaS naudojimą su savininkais, duomenimis, geografija, prieiga ir sutartimis.

Toje pačioje Cloud Usage Policy-sme, skyriaus „Politikos įgyvendinimo reikalavimai“ politikos sąlyga 6.2 apibrėžia bazinius nustatymus:

Saugumo konfigūracijos reikalavimai 6.2.1 Visose debesijos platformose turi būti įgalinta: 6.2.2 Kelių veiksnių autentifikavimas (MFA) administracinėms ir naudotojų paskyroms 6.2.3 Slaptažodžio sudėtingumo nustatymai (mažiausiai 10 simbolių, be pakartotinio naudojimo) 6.2.4 Veiklos registravimas prisijungimo bandymams ir prieigai prie duomenų 6.2.5 Prieigos apribojimai (pvz., IP įtraukimas į leidžiamąjį sąrašą, kai palaikoma) 6.2.6 Administracinė prieiga turi būti ribojama vardiniams asmenims arba autorizuotiems pagalbos teikėjams. 6.2.7 Viešai bendrinamas turinys turi būti reguliariai stebimas siekiant išvengti duomenų nutekėjimo. 6.2.8 Kai naudotojų paskyros nebereikalingos, prieiga turi būti nedelsiant atšaukta, o visi likutiniai duomenys turi būti peržiūrėti ir archyvuoti arba ištrinti.

Įmonių aplinkose Cloud Usage Policy Debesijos paslaugų naudojimo politika nustato stipresnę centralizuotą valdyseną. Iš skyriaus „Valdysenos reikalavimai“, politikos sąlyga 5.3:

Kiekviena debesijos paslauga turi turėti priskirtą paslaugos savininką, atsakingą už informacinio turto gyvavimo ciklo valdymą, naudojimo valdyseną, biudžeto stebėseną ir nuolatinę atitikties stebėseną.

Šis sakinys uždaro dažną audito spragą. Jei niekas nėra SaaS paslaugos savininkas, niekas nėra atsakingas už konfigūracijos nukrypimą, prieigos pakartotinį patvirtinimą, duomenų atskleidimą, atnaujinimo sprendimus, incidento kontaktą ar išėjimo planavimą.

Privilegijų valdysena taip pat turi būti aiškiai apibrėžta. User Account and Privilege Management Policy-sme Naudotojų paskyrų ir privilegijų valdymo politika - MVĮ, skyriaus „Politikos įgyvendinimo reikalavimai“ politikos sąlyga 6.4, nurodo:

Prieigos peržiūros ir žurnalavimas 6.4.1 Visų naudotojų paskyrų ir privilegijų peržiūra turi būti atliekama kas šešis mėnesius. 6.4.2 Peržiūrų metu IT vadovas turi patikrinti, ar kiekviena paskyra tebėra aktyvi, būtina ir jai priskirti tinkami leidimai. 6.4.3 Paskyrų sukūrimo, paskyrų deaktyvavimo ir privilegijų pakeitimų žurnalai turi būti saugiai saugomi ne trumpiau kaip 12 mėnesių.

SaaS atveju kiekvienai kritinei platformai reikia apibrėžto prieigos peržiūros ciklo, net jei platformą administruoja verslo komanda, o ne centrinis IT.

Žurnalavimas taip pat turi būti aiškiai apibrėžtas. Logging and Monitoring Policy-sme Žurnalų tvarkymo ir stebėsenos politika - MVĮ, skyriaus „Valdysenos reikalavimai“ politikos sąlyga 5.5, nurodo:

Debesijos paslaugų ir trečiųjų šalių žurnalavimas 5.5.1 Platformoms, kuriose žurnalavimo IT tiesiogiai nekontroliuoja (pvz., SaaS el. paštas), taikomi šie reikalavimai: 5.5.1.1 Žurnalavimas turi būti įgalintas ir sukonfigūruotas, kai tai prieinama 5.5.1.2 Įspėjimai turi būti nukreipiami IT pagalbos teikėjui 5.5.1.3 Sutartyse turi būti reikalaujama, kad teikėjai saugotų žurnalus ne trumpiau kaip 12 mėnesių ir suteiktų prieigą gavus prašymą

Galiausiai SaaS tiekėjų valdysena turi būti dokumentuota. Third-Party and Supplier Security Policy-sme Trečiųjų šalių ir tiekėjų saugumo politika - MVĮ, skyriaus „Politikos įgyvendinimo reikalavimai“ politikos sąlyga 6.3, nurodo:

Nuolatinė tiekėjų saugumo stebėsena 6.3.1 Kritiniai arba didelės rizikos tiekėjai turi būti peržiūrimi bent kartą per metus. Peržiūra turi patikrinti: 6.3.1.1 Tęstinį saugių prieigos metodų naudojimą 6.3.1.2 Galiojančius saugumo sertifikatus arba atnaujintus kontrolės įrodymus 6.3.1.3 Incidentų istoriją arba praneštas problemas 6.3.1.4 Sutartinę atitiktį saugumo nuostatoms 6.3.2 Šios peržiūros turi būti dokumentuojamos ir saugomos kartu su tiekėjo įrašu. Tolesni veiksmai turi būti aiškiai sekami. 6.3.3 Kai tiekėjai valdo IT infrastruktūrą arba taikomąsias programas, stebėsena gali apimti: 6.3.3.1 Audito žurnalų prašymą 6.3.3.2 Paskyrų veiklos peržiūrą 6.3.3.3 Patvirtinimą, kad nebuvo neteisėtos prieigos

Kartu šios politikos SSPM paverčia iš saugumo siekiamybės į įgyvendinamą veiklos modelį.

30 dienų SSPM įrodymų sprintas

Praktiškai veikiantis CISO arba atitikties vadovas gali pradėti nuo 30 dienų įrodymų sprinto. Pasirinkite penkias SaaS platformas, svarbiausias reglamentuojamiems duomenims arba kritinėms operacijoms. Tipiniai kandidatai yra Microsoft 365 arba Google Workspace, CRM, užklausų valdymas, HRIS, finansų automatizavimas, klientų aptarnavimas ir analitika.

1 savaitė: sukurkite SaaS registrą

Naudokite Cloud Usage Policy-sme sąlygos 5.3 laukus kaip minimalų registrą. Kiekvienai SaaS paslaugai užfiksuokite:

• Paslaugos pavadinimą ir verslo paskirtį
• Taikomosios programos savininką ir techninį savininką
• Duomenų tipus, įskaitant asmens duomenis ir specialių kategorijų duomenis, kai taikoma
• Duomenų saugojimo šalį arba regioną
• Naudotojų grupes ir administratoriaus paskyras
• OAuth taikomąsias programas ir trečiųjų šalių integracijas
• Sutarties savininką, atnaujinimo datą ir pagalbos kontaktą
• Operacijų kritiškumą
• Taikomas prievoles, pavyzdžiui, NIS2, DORA, GDPR arba klientų sutartis

Tai palaiko ISO/IEC 27001:2022 4.2 ir 4.3 punktus, nes reglamentavimo, sutartinės ir trečiųjų šalių priklausomybės turi formuoti ISVS taikymo sritį. Tai taip pat palaiko DORA Article 8 tipo IRT palaikomų verslo funkcijų, informacijos išteklių, IRT turto ir priklausomybių identifikavimą bei klasifikavimą.

2 savaitė: apibrėžkite saugias bazines konfigūracijas

Kiekvienai pasirinktai SaaS platformai apibrėžkite 10–15 bazinių kontrolės priemonių.

• MFA taikomas visiems naudotojams, o administratoriams, kai įmanoma, taikomas fišingui atsparus MFA
• Išorinis bendrinimas pagal numatytuosius nustatymus išjungtas arba ribojamas patvirtintais domenais
• Viešos nuorodos išjungtos arba ribotos trukmės
• Svečių paskyros peržiūrimos kas mėnesį
• Administratoriaus vaidmenys priskirti vardiniams asmenims
• Senasis autentifikavimas išjungtas
• OAuth taikomųjų programų tvirtinimo darbo eiga įgalinta
• Didelės rizikos OAuth taikymo sritys blokuojamos arba reikalauja saugumo patvirtinimo
• Audito žurnalavimas įgalintas
• Duomenų eksporto leidimai apriboti
• Saugojimo nustatymai suderinti su teisiniais ir verslo reikalavimais
• API prieigos raktai peržiūrimi ir rotuojami
• Saugumo įspėjimai nukreipiami IT arba SOC
• Duomenų praradimo prevencijos nustatymai įgalinti, kai palaikoma
• „Break-glass“ paskyros dokumentuotos ir stebimos

Zenith Blueprint, etape „Controls in Action“, 19 žingsnyje, kontrolės priemonė 8.9 konfigūracijų valdymas, paaiškina, kodėl tai svarbu:

Daugelis pažeidimų kyla ne dėl programinės įrangos trūkumų, o dėl prastų konfigūracijos pasirinkimų. Nepakeisti numatytieji slaptažodžiai, įjungtos nesaugios paslaugos, atviri nereikalingi prievadai arba sistemos, be pagrindimo pasiekiamos internetu. Kontrolės priemonė 8.9 užtikrina, kad kiekviena sistema būtų sukurta pagal saugią bazinę konfigūraciją ir reguliariai peržiūrima, kad ilgainiui būtų išvengta nukrypimų.

SaaS aplinkoje konfigūracijos nukrypimas apima verslo savininko įgalintą viešą bendrinimą, administratoriaus patvirtintą plačią trečiųjų šalių prieigą arba tiekėjo pakeistus numatytuosius nustatymus po funkcijos išleidimo.

3 savaitė: peržiūrėkite prieigą ir integracijas

Eksportuokite naudotojus, grupes, administratorius ir prijungtas taikomąsias programas. Kiekvienai administratoriaus paskyrai patvirtinkite vardinį asmenį, verslo pagrindimą, MFA būseną, paskutinį prisijungimą, privilegijų lygį, atsarginės prieigos aprėptį, pareigų atskyrimo klausimus ir patvirtinimo įrodymus.

OAuth taikomosioms programoms ir integracijoms patvirtinkite taikomosios programos savininką, pasiekiamus duomenis, prašomus leidimus, tiekėjo rizikos būseną, paskutinio naudojimo datą, tęstinį poreikį ir tai, ar sutikimą suteikė naudotojas, ar patvirtino administratorius.

Zenith Blueprint, etape „Controls in Action“, 19 žingsnyje, kontrolės priemonė 8.3 prieigos prie informacijos ribojimas, pateikia veiklos principą:

Prieiga prie informacijos turi būti tokia atvira, kiek būtina, ir tokia ribota, kiek įmanoma.

Tai taikoma ne tik žmonėms, bet ir taikomosioms programoms, paslaugoms bei taikomųjų programų sąsajoms. Neaktyvi OAuth integracija gali išlaikyti prieigą dar ilgai po to, kai ją sukūręs darbuotojas ar projektas išnyko.

4 savaitė: parenkite auditui tinkamus įrodymus ir rizikos tvarkymą

Kiekvienai SaaS platformai saugokite registro įrašą, bazinę konfigūraciją, ekrano kopijas arba eksportus, patvirtinančius pagrindinius nustatymus, prieigos peržiūros patvirtinimą, administratoriaus peržiūros įrodymus, OAuth peržiūros įrodymus, žurnalavimo ir įspėjimų įrodymus, tiekėjo saugumo peržiūros įrašą, atviras išvadas ir rizikos tvarkymo veiksmus.

Tada parenkite vieno puslapio vadovybei skirtą santrauką, kurioje būtų nurodytos kritinės išvados, vėluojantys savininkai, neišspręstos didelės rizikos konfigūracijos spragos, nepatvirtintos integracijos, žurnalavimo spragos, išimtys ir reikalingi sprendimai. Tai palaiko ISO/IEC 27001:2022 9.1 punkto stebėseną, 9.2 punkto vidaus auditą ir 9.3 punkto vadovybės peržiūrą. Tai taip pat sukuria praktinę jungtį su NIS2 Article 20 vadovybės atskaitomybe ir DORA valdymo organo priežiūra.

Kryžminės atitikties susiejimas: vienas SSPM įrodymų paketas, daug prievolių

SSPM verslo vertė yra ne tik geresnis saugumas. Tai ir mažesnis atitikties dubliavimas.

NIS2 Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių. SaaS registras palaiko turto valdymą. Bazinės konfigūracijos palaiko kibernetinę higieną. MFA ir prieigos peržiūros palaiko prieigos kontrolę. Žurnalavimas palaiko incidentų valdymą. Tiekėjų peržiūra palaiko tiekimo grandinės saugumą. Įrodymų periodiškumas palaiko politikas ir procedūras veiksmingumui vertinti.

DORA reikalauja, kad finansų subjektai identifikuotų ir klasifikuotų IRT palaikomas funkcijas, informacijos išteklius, IRT turtą ir trečiųjų šalių priklausomybes. Taip pat reikalaujama apsaugos ir prevencijos priemonių, prieigos kontrolės priemonių, stipraus autentifikavimo, šifravimo, tęstinumo, testavimo, incidentų valdymo ir IRT trečiųjų šalių rizikos valdysenos. SaaS SSPM įrodymų paketas gali palaikyti DORA registrus, priklausomybių atvaizdavimą, sutarčių priežiūrą, audito teises ir išėjimo planavimą.

GDPR reikalauja, kad duomenų valdytojai galėtų įrodyti atitiktį vientisumo, konfidencialumo ir atskaitomybės reikalavimams. SaaS registrai nustato, kur tvarkomi asmens duomenys. Bazinės konfigūracijos mažina neteisėto atskleidimo riziką. Prieigos peržiūros palaiko mažiausių privilegijų principą. Žurnalavimas palaiko pažeidimo tyrimą. Tiekėjų įrašai palaiko duomenų tvarkytojų valdyseną ir atskaitomybę.

NIST CSF 2.0 prideda naudingą komunikacijos sluoksnį. Jo GOVERN funkcija reikalauja suprasti ir valdyti teisinius, reglamentavimo ir sutartinius kibernetinio saugumo reikalavimus. Jo tiekimo grandinės rezultatai reikalauja tiekėjų vaidmenų, sutarčių, deramo rūpestingumo, stebėsenos ir veiklos po santykių pabaigos. Jo IDENTIFY, PROTECT, DETECT, RESPOND ir RECOVER funkcijos natūraliai siejasi su SaaS registru, prieigos kontrole, duomenų apsauga, žurnalavimu, reagavimu į incidentus ir atkūrimu.

COBIT 2019 ir ISACA orientuoti auditoriai paprastai vertins SSPM per valdyseną, valdymo tikslus, rizikos savininkus, kontrolės veikimą ir patikinimą. Jie klaus, ar SaaS sprendimai suderinti su įmonės tikslais, ar rizikos atsakai dokumentuoti, ar atsakomybės priskirtos ir ar patikinimo veiklos įrodo, kad kontrolės priemonės veikia.

Audito požiūris: kaip skirtingi auditoriai tikrina SaaS būklę

Stipri SSPM programa atlaiko skirtingus audito stilius, nes pateikia tinkamo lygmens įrodymus.

ISO/IEC 27001:2022 auditorius pradės nuo taikymo srities, suinteresuotųjų šalių, rizikos vertinimo, Taikytinumo pareiškimo ir operacinių įrodymų. Jei įtraukta kontrolės priemonė 5.23, jis tikėsis debesijos paslaugų pasirinkimo, naudojimo, valdymo ir išėjimo įrodymų. Jei įtrauktos prieigos teisių kontrolės priemonės, jis atrinks naudotojų imtį ir klaus, ar priimamų, perkeliamų ir išeinančių darbuotojų pakeitimai atsispindi SaaS leidimuose.

DORA vertintojas sutelks dėmesį į kritines ar svarbias funkcijas, IRT trečiųjų šalių priklausomybes, registro išsamumą, sutartis, incidentų klasifikavimą, testavimą ir išėjimo planavimą. Jei SaaS platforma palaiko mokėjimų operacijas, klientų įtraukimą, prekybą, rizikos analitiką ar klientų komunikaciją, įrodymų standartas kyla.

GDPR auditorius arba privatumo vertintojas klaus, kur saugomi asmens duomenys, kas gali juos pasiekti, kokie eksportai ir bendrinimo nustatymai egzistuoja, ar duomenų tvarkytojai valdomi, ar žurnalai palaiko pažeidimo vertinimą ir ar kontrolės priemonės proporcingos rizikai.

Tiekėjų rizika, bendra atsakomybė ir pasirengimas incidentams

SSPM dažnai prasideda nuo konfigūracijos, tačiau tuo negali baigtis. SaaS taip pat yra tiekėjų rizikos ir pasirengimo incidentams klausimas.

DORA reikalauja, kad finansų subjektai tvarkytų IRT paslaugų sutarčių registrus, atskirtų susitarimus, palaikančius kritines ar svarbias funkcijas, vertintų koncentracijos riziką, įvertintų paslaugų teikėjo tinkamumą ir palaikytų išėjimo strategijas. Sutartyse turėtų būti aptarti paslaugų aprašymai, duomenų vieta, prieinamumo, autentiškumo, vientisumo ir konfidencialumo apsauga, prieiga prie duomenų, atkūrimas ir grąžinimas, pagalba incidentų atveju, bendradarbiavimas su institucijomis, nutraukimo teisės, saugumo reikalavimai, audito teisės ir perėjimo pagalba.

NIS2 Article 21 taip pat apima tiekimo grandinės saugumą ir reikalauja, kad subjektai atsižvelgtų į pažeidžiamumus, būdingus tiesioginiams tiekėjams ir paslaugų teikėjams, produktų kokybę ir tiekėjų kibernetinio saugumo praktikas.

Praktikoje kritinės SaaS peržiūra turėtų apjungti saugumo klausimyno įrodymus, sutarties peržiūrą, duomenų tvarkymo sutarties būseną, incidentų istoriją, paslaugų lygio įsipareigojimus, prieigą prie žurnalų, audito ataskaitas, konfigūracijos įrodymus ir išėjimo įgyvendinamumą.

Bendros atsakomybės spraga atsiranda tada, kai komandos daro prielaidą, kad tiekėjo sertifikavimas apima nuomininko konfigūraciją. Taip nėra. Tiekėjas gali eksploatuoti saugią platformą, o klientas tuo pat metu įgalinti viešą bendrinimą, palikti aktyvias neaktyvias administratoriaus paskyras arba suteikti perteklines API taikymo sritis. SSPM uždaro šią spragą.

Pasirengimas incidentams yra ne mažiau svarbus. NIS2 reikšmingų incidentų pranešimai apima 24 valandų ankstyvąjį įspėjimą, 72 valandų pranešimą ir galutinę ataskaitą ne vėliau kaip per vieną mėnesį po 72 valandų pranešimo. DORA reikalauja su IRT susijusių incidentų valdymo, įskaitant aptikimą, registravimą, klasifikavimą, eskalavimą, komunikaciją ir pranešimą. GDPR asmens duomenų saugumo pažeidimo vertinimas taip pat priklauso nuo savalaikio supratimo, kas įvyko, kokie duomenys buvo paveikti ir kas patyrė poveikį.

Jei įtartina OAuth taikomoji programa pasiekė klientų failus, turite žinoti, kada programa buvo autorizuota, kuris naudotojas ją autorizavo, kokios taikymo sritys buvo suteiktos, kokie duomenys buvo pasiekti, ar duomenys buvo atsisiųsti arba bendrinti, kurie naudotojai ar klientai buvo paveikti, ar prieiga vis dar aktyvi ir kokie lokalizavimo veiksmai buvo atlikti.

Be žurnalavimo ir saugojimo terminų organizacija gali būti priversta daryti blogiausio scenarijaus prielaidas. Tai didina teisinę rizikos ekspoziciją, klientų komunikacijos spaudimą ir reglamentavimo neapibrėžtumą. Kai SaaS teikėjas taiko papildomą mokestį už audito žurnalus, rizikos savininkas turi aiškiai priimti liekamąją riziką arba patvirtinti reikiamą licencijos lygį. Šis sprendimas turi būti rizikos tvarkymo įraše ir vadovybės peržiūroje.

Dažni SSPM nesėkmių modeliai

Tie patys nesėkmių modeliai kartojasi visuose sektoriuose.

Pirma, šešėlinis SaaS aptinkamas per sąskaitas faktūras, naršyklės istoriją arba SSO žurnalus, o ne per pirkimų procesą. Sprendimas nėra vien priemonių blokavimas. Reikalingas lengvas įtraukimo procesas, kuriuo galėtų naudotis verslo komandos.

Antra, SaaS savininkai neaiškūs. CRM „priklauso pardavimams“, tačiau niekas pardavimų komandoje negali paaiškinti administratoriaus vaidmenų, API prieigos raktų, duomenų eksportų ar saugojimo nustatymų. Taikomosios programos savininkai ir techniniai savininkai turi būti priskiriami atskirai.

Trečia, prieigos peržiūros yra pernelyg bendros. Peržiūrą atliekantis asmuo patvirtina „visi naudotojai patvirtinti“, nepatikrinęs didelės rizikos vaidmenų, neaktyvių naudotojų, svečių, išorinių bendradarbių ar paslaugų paskyrų. SSPM prieigos peržiūra turi būti reitinguojama pagal riziką.

Ketvirta, OAuth taikomosios programos ignoruojamos. Daugelis organizacijų peržiūri žmones naudotojus, bet ne taikomąsias programas ir jų leidimus. Šiuolaikinėje SaaS aplinkoje integracijos gali būti galingesnės už naudotojus.

Penkta, bazinės konfigūracijos egzistuoja tik kaip ekrano kopijos iš sertifikavimo projekto. Jos nestebimos dėl nukrypimų. Suderinkite SSPM su konfigūracijų valdymu, kad bazinės patikros taptų pasikartojančiais įrodymais.

Šešta, tiekėjų peržiūra ir SaaS būklės peržiūra yra atskirtos. Pirkimai turi sutartį, IT turi administravimo konsolę, Privatumo funkcija turi duomenų tvarkymo sutartį, o Saugumas turi rizikų registrą. Auditorius mato fragmentus. SSPM juos sujungia.

Vadovybei teikiamos ataskaitos: padarykite SaaS riziką matomą valdybai

NIS2 ir DORA IRT bei kibernetinio saugumo valdyseną paverčia vadovybės klausimu. ISO/IEC 27001:2022 taip pat reikalauja lyderystės, išteklių, vaidmenų priskyrimo, stebėsenos ir vadovybės peržiūros.

Veiksminga SSPM vadovybės ataskaita turi atsakyti:

• Kurios kritinės SaaS paslaugos patenka į taikymo sritį?
• Kokie reglamentuojami procesai nuo jų priklauso?
• Kurios iš jų turi asmens duomenų arba jautrių verslo duomenų?
• Kurios turi pradelstas prieigos peržiūras?
• Kurios turi neišspręstų didelės rizikos konfigūracijos spragų?
• Kurios turi nepatvirtintų OAuth taikomųjų programų arba integracijų?
• Kuriems tiekėjams trūksta aktualių saugumo įrodymų?
• Kokios žurnalavimo spragos turi įtakos pranešimui apie incidentus?
• Kokioms išimtims reikia rizikos priėmimo?
• Kokių investicijų arba sprendimų reikia?

Tai paverčia SSPM iš techninio sutvarkymo projekto į valdysenos įvestį. Tai taip pat padaro CISO veiksmingesnį, nes rizikos priėmimas perkeliamas į tinkamą lygmenį.

Paverskite SaaS būklę auditui tinkamais įrodymais

Jei jūsų organizacija remiasi SaaS reglamentuojamiems duomenims, finansinėms operacijoms, klientų aptarnavimui, žmogiškiesiems ištekliams, bendradarbiavimui, inžinerijai ar analitikai, SSPM nebėra pasirenkamas. Tai yra kibernetinės higienos, IRT rizikos valdymo, privatumo atskaitomybės ir pasirengimo auditui dalis.

Clarysec gali padėti pereiti nuo išskaidytų SaaS išvadų prie struktūruotos, įrodymais grindžiamos programos naudojant:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, kad struktūruotumėte įgyvendinimą debesijos naudojimo, prieigos ribojimo ir konfigūracijų valdymo srityse.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls, kad susietumėte ISO/IEC 27002:2022 kontrolės priemones su NIS2, DORA, GDPR, NIST CSF 2.0 ir audito lūkesčiais.
• Clarysec politikų šablonus, tokius kaip Cloud Usage Policy Debesijos paslaugų naudojimo politika, Cloud Usage Policy-sme Debesijos paslaugų naudojimo politika - MVĮ, User Account and Privilege Management Policy-sme Naudotojų paskyrų ir privilegijų valdymo politika - MVĮ, Logging and Monitoring Policy-sme Žurnalų tvarkymo ir stebėsenos politika - MVĮ ir Third-Party and Supplier Security Policy-sme Trečiųjų šalių ir tiekėjų saugumo politika - MVĮ, kad sukurtumėte įgyvendinamas veiklos taisykles.

Pradėkite nuo penkių didžiausios rizikos SaaS platformų. Priskirkite savininkus. Užfiksuokite duomenis, prieigą, konfigūraciją, integracijas, žurnalus ir tiekėjų įrodymus. Paverskite išvadas rizikos tvarkymo veiksmais ir vadovybės sprendimais.

Taip SaaS saugumo būklės valdymas tampa daugiau nei įrankių kategorija. Jis tampa pagrindžiama atitikties disciplina 2026 metams.

Atsisiųskite Clarysec politikų šablonus, naudokite Zenith Blueprint savo 30 dienų SSPM įrodymų sprintui suplanuoti ir susiekite savo SaaS kontrolės priemones su Zenith Controls, kol kitas auditas dar neaptiko spragų už jus.