Riadenie bezpečnostného stavu SaaS pre audity v roku 2026

Auditné zistenie v SaaS, ku ktorému sa nikto nehlásil

V utorok o 08:15 dostane CISO rýchlo rastúcej fintech spoločnosti správu od zodpovednej osoby pre ochranu osobných údajov: „Prečo je export zákazníckych údajov verejne zdieľateľný z nástroja na spoluprácu a kto schválil aplikáciu OAuth, ktorá ho dokáže čítať?“

O 09:00 finančné oddelenie potvrdí, že nástroj sa platí kartou oddelenia, nie cez centrálne obstarávanie. O 10:30 IT zistí, že používateľ, ktorý vytvoril verejný odkaz, odišiel zo spoločnosti pred tromi mesiacmi. Na poludnie sa právne oddelenie pýta, či ide o porušenie ochrany osobných údajov podľa GDPR. O 14:00 sa výbor pre riziká pýta, či problém ovplyvňuje kybernetickú hygienu podľa NIS2 a riziko tretej strany v oblasti IKT podľa DORA. O 16:00 interný audítor požiada o referenčné konfigurácie, revízie administrátorských prístupových práv, vlastníctvo cloudovej služby, logy a due diligence dodávateľa.

Nepríjemná pravda je, že organizácia neutrpela klasický výpadok SaaS ani zlyhanie dodávateľa. Utrpela zlyhanie správy a riadenia.

Takýto scenár už nie je výnimočný. Marketingový tím pripojí AI platformu k CRM so širokými oprávneniami OAuth. HR kúpi špecializovaný analytický nástroj mimo obstarávania. Tím zákazníckej podpory z pohodlnosti povolí verejné exporty tiketov. Engineering integruje rozšírenie prehliadača do vývojového pracovného toku. Každé rozhodnutie sa môže zdať malé, ale spolu vytvárajú distribuované kontrolné prostredie plné regulovaných údajov, privilegovaných pracovných tokov a prevádzkových závislostí.

Riadenie bezpečnostného stavu SaaS, teda SSPM, je disciplína, ktorá premieňa rozptýlenú realitu SaaS na riadené, testované a auditovateľné kontrolné prostredie. Ak je vykonané správne, poskytuje CISO, manažérom súladu, audítorom a vlastníkom biznis procesov jednotnú auditnú stopu pre ISO/IEC 27001:2022, kybernetickú hygienu podľa NIS2, riziká IKT podľa DORA a bezpečnostnú zodpovednosť podľa GDPR.

Postoj Clarysec je priamy: SSPM sa nemá považovať za ďalší dashboard. Má byť začlenené do ISMS, prepojené s vlastníctvom rizík, mapované na zákonné povinnosti, podporené politikami a testované prostredníctvom opakovaných dôkazov.

Práve tu sú prakticky použiteľné Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls a šablóny politík Clarysec. Pomáhajú previesť nekontrolovane rozšírené používanie SaaS do modelu kontrol, ktorému audítor rozumie a nad ktorým môže riadiaci orgán vykonávať dohľad.

Prečo sa riadenie bezpečnostného stavu SaaS stalo otázkou súladu

SaaS sa kedysi vnímalo ako „softvér, ktorý prevádzkuje niekto iný“. Takéto vymedzenie už nie je obhájiteľné.

Podľa NIS2 môžu mnohí poskytovatelia cloudových služieb, SaaS, digitálnej infraštruktúry, riadených služieb a riadených bezpečnostných služieb patriť do rozsahu regulovaných očakávaní v oblasti kybernetickej bezpečnosti v závislosti od sektora, veľkosti, roly a kritickosti. Ešte dôležitejšie je, že organizácie, ktoré sa spoliehajú na SaaS, ho musia riadiť ako súčasť vlastných opatrení na riadenie rizík. NIS2 Article 20 ukladá riadiacim orgánom zodpovednosť za schvaľovanie opatrení na riadenie kybernetických rizík, dohľad nad ich implementáciou a absolvovanie školení. Article 21 vyžaduje praktické technické, prevádzkové a organizačné opatrenia vrátane analýzy rizík, politík, riadenia incidentov, kontinuity činností, bezpečnosti dodávateľského reťazca, bezpečného obstarávania a údržby, testovania účinnosti, kybernetickej hygieny, kryptografie, bezpečnosti ľudských zdrojov, riadenia prístupu, správy aktív a viacfaktorovej autentifikácie tam, kde je to primerané.

DORA zvyšuje nároky pre finančné subjekty ešte viac. Od 17. januára 2025 sa DORA uplatňuje na mnohé organizácie finančného sektora ako režim digitálnej prevádzkovej odolnosti pre subjekty v rozsahu pôsobnosti. Vyžaduje správu a riadenie IKT, identifikáciu a klasifikáciu aktív IKT a podporovaných funkcií, ochranné a preventívne kontroly, riadenie incidentov, kontinuitu, testovanie a riadenie rizík tretích strán v oblasti IKT. Poskytovatelia SaaS, ktorí podporujú kritické alebo dôležité funkcie, sa stávajú súčasťou dôkazového perimetra DORA, pričom regulovaný finančný subjekt zostáva zodpovedný.

GDPR pridáva vrstvu dôkazov v oblasti ochrany súkromia. Article 5 vyžaduje integritu, dôvernosť a preukázateľnú zodpovednosť. Article 32 vyžaduje primeranú bezpečnosť spracúvania. V praxi musí organizácia vedieť, aké osobné údaje existujú, kde sa spracúvajú, kto k nim má prístup, ktorí dodávatelia ich spracúvajú a aké ochranné opatrenia ich chránia. Chybná konfigurácia SaaS mení tieto otázky na urgentné otázky posúdenia porušenia ochrany osobných údajov.

ISO/IEC 27001:2022 je premostením. Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia definovala kontext, požiadavky zainteresovaných strán, rozsah, rozhrania a závislosti. Kapitola 5 vyžaduje vedenie, politiku, roly a zodpovednosti. Kapitoly 6.1.1 až 6.1.3 vyžadujú posúdenie rizík, ošetrenie rizík, vyhlásenie o uplatniteľnosti a rozhodnutia o reziduálnom riziku. Kapitoly 8.1, 8.2 a 8.3 vyžadujú prevádzkové plánovanie a riadenie, posúdenie rizík a ošetrenie rizík. Kapitoly 9 a 10 vyžadujú monitorovanie, interný audit, preskúmanie manažmentom a zlepšovanie.

Ak neviete odpovedať, ktoré nástroje SaaS spracúvajú regulované údaje, kto ich vlastní, ako sú nakonfigurované, kto má administrátorský prístup, ktoré integrácie sú aktívne a aké dôkazy preukazujú, že kontrola funguje, vaša pozícia v oblasti súladu je krehká.

Model SSPM spoločnosti Clarysec: evidencia, vlastníctvo, referenčná konfigurácia, dôkazy

Clarysec pristupuje k riadeniu bezpečnostného stavu SaaS ako k opakovateľnej kontrolnej slučke, nie ako k jednorazovému projektu upratovania.

1. Objavte každú službu SaaS vrátane shadow SaaS.
2. Priraďte vecného vlastníka a technického vlastníka.
3. Klasifikujte údaje, používateľov, integrácie a prevádzkovú kritickosť.
4. Uplatnite bezpečné referenčné konfigurácie.
5. Preskúmajte používateľov, administrátorov, hostí, servisné účty a rozsahy OAuth.
6. Povoľte logovanie, upozorňovanie a uchovávanie.
7. Monitorujte verejné zdieľanie a expozíciu údajov.
8. Prepojte dodávateľov, zmluvy, zmluvy o spracúvaní osobných údajov a plánovanie ukončenia.
9. Zhromažďujte dôkazy v definovanej periodicite.
10. Premietnite zistenia do ošetrenia rizík, preskúmania manažmentom a zlepšovania.

Tento model je úzko zosúladený s kontrolami ISO/IEC 27002:2022 ISO/IEC 27002:2022, najmä 5.9 evidencia informácií a ďalších súvisiacich aktív, 5.15 riadenie prístupu, 5.18 prístupové práva, 5.19 informačná bezpečnosť vo vzťahoch s dodávateľmi, 5.20 riešenie informačnej bezpečnosti v dodávateľských zmluvách, 5.21 riadenie informačnej bezpečnosti v dodávateľskom reťazci IKT, 5.23 informačná bezpečnosť pri používaní cloudových služieb, 8.2 privilegované prístupové práva, 8.3 obmedzenie prístupu k informáciám, 8.9 riadenie konfigurácie, 8.15 logovanie, 8.16 monitorovanie aktivít a 8.32 riadenie zmien.

Zenith Blueprint vo fáze Kontroly v praxi, v kroku 23 pre organizačné opatrenia, uvádza:

Cloud už nie je cieľom, ale predvoleným stavom. Od úložísk po spoluprácu, od infraštruktúry po strojové učenie sú organizácie čoraz viac postavené na vrstvách prostredí tretích strán, abstrahovaných a spravovaných na diaľku. Kontrola 5.23 túto realitu uznáva a vyžaduje, aby sa informačná bezpečnosť výslovne riešila pri výbere, používaní a riadení cloudových služieb, nie dodatočne, ale ako návrhový princíp od samého začiatku.

To je podstata SSPM. Nejde len o dodatočnú detekciu chybných konfigurácií. Ide o to, aby sa výber, onboarding, prevádzka, monitorovanie a ukončenie SaaS stali súčasťou systému manažérstva.

Tá istá časť Zenith Blueprint vysvetľuje realitu zdieľanej zodpovednosti jazykom, ktorý by mal počuť každý člen predstavenstva:

Poskytovatelia cloudu zabezpečujú infraštruktúru, ale vy stále zodpovedáte za svoje údaje, svoje konfigurácie, svoje politiky prístupu a svoju pripravenosť na reakciu na incidenty. Chybne nakonfigurovaný bucket cloudového úložiska, verejne vystavený dashboard alebo nadmerné oprávnenia v nastavení cloudového IAM nie sú zlyhaniami cloudu. Sú to zlyhania správy a riadenia.

Váš poskytovateľ môže prevádzkovať platformu, ale konfigurácia tenantov, identity, schvaľovanie prístupov, exponované údaje, integrácie, incidentné pracovné toky a dôkazy súladu zostávajú vo vašom vlastníctve.

Kontrola 5.23 je kotva, ale SSPM potrebuje rodinu kontrol

V Zenith Controls je kontrola ISO/IEC 27002:2022 5.23, informačná bezpečnosť pri používaní cloudových služieb, kategorizovaná ako preventívna kontrola podporujúca dôvernosť, integritu a dostupnosť. Jej koncept kybernetickej bezpečnosti je Protect, s prevádzkovou spôsobilosťou v oblasti bezpečnosti dodávateľských vzťahov a s doménami naprieč správou a riadením, ekosystémom a ochranou.

Je to dôležité, pretože SSPM nie je jedna kontrola. Je to disciplína naprieč kontrolami.

Zenith Controls prepája 5.23 s dodávateľskými vzťahmi podľa 5.19, pretože poskytovatelia SaaS sú kritickí dodávatelia, ale 5.23 pridáva špecifické otázky SaaS, ako sú multitenantnosť, transparentnosť umiestnenia údajov a zdieľaná zodpovednosť. Prepája 5.23 s prenosom informácií, pretože rozhrania API, integrácie a pracovné toky medzi SaaS neustále presúvajú údaje. Prepája 5.23 s evidenciou aktív, pretože organizácie potrebujú aktuálny prehľad o údajoch uložených v cloude a zdrojoch SaaS. Zároveň prepája cloudovú správu a riadenie s monitorovaním, obmedzením prístupu, riadením konfigurácie a dohľadom nad dodávateľmi.

Pri prístupových právach Zenith Controls mapuje 5.18 na 5.15 riadenie prístupu, 5.16 správu identít, 5.3 oddelenie povinností, 5.36 súlad s politikami, pravidlami a normami informačnej bezpečnosti a 8.2 privilegované prístupové práva. Pre SSPM to znamená, že revízia prístupových práv nie je len cvičenie v tabuľkovom prehľade. Je to prevádzkový dôkaz, že životný cyklus identity, zásada minimálnych oprávnení, oddelenie povinností a správa privilegovaných prístupov fungujú aj v aplikáciách SaaS.

Základ v politikách: definujte správny stav skôr, než kúpite nástroje

Mnohé zlyhania SaaS sa začínajú tým, že jazyk politiky je vágnny. „Používajte schválené nástroje bezpečne“ nestačí. Politiky Clarysec definujú konkrétne očakávania týkajúce sa registra, prístupu, logovania, konfigurácie a preskúmania dodávateľov.

Pre MSP poskytuje Politika používania cloudových služieb pre MSP Politika používania cloudových služieb – MSP praktický východiskový bod. Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.3:

Register cloudových služieb musí udržiavať poskytovateľ IT služieb alebo generálny manažér. Musí zaznamenávať: 5.3.1 názov a účel každej schválenej cloudovej služby 5.3.2 zodpovednú osobu alebo tím (vlastník aplikácie) 5.3.3 typy uložených alebo spracúvaných údajov 5.3.4 krajinu alebo región, kde sú údaje uložené 5.3.5 oprávnenia používateľského prístupu a administrátorské účty 5.3.6 zmluvné údaje, dátumy obnovy a kontakty podpory

Toto ustanovenie je prevádzkovým jadrom SSPM. Audítorom poskytuje prvý dôkazový objekt: register, ktorý prepája používanie SaaS s vlastníkmi, údajmi, geografickou lokalizáciou, prístupom a zmluvami.

Tá istá Politika používania cloudových služieb pre MSP, zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.2, definuje referenčné nastavenia:

Požiadavky na bezpečnostnú konfiguráciu 6.2.1 Na všetkých cloudových platformách musí byť povolené nasledovné: 6.2.2 viacfaktorová autentifikácia (MFA) pre administrátorské a používateľské účty 6.2.3 nastavenia zložitosti hesla (minimálne 10 znakov, bez opätovného použitia) 6.2.4 logovanie aktivít pri pokusoch o prihlásenie a prístupe k údajom 6.2.5 obmedzenia prístupu (napr. zoznam povolených IP adries, ak je podporovaný) 6.2.6 Administratívny prístup musí byť obmedzený na pomenované osoby alebo autorizovaných poskytovateľov podpory. 6.2.7 Verejne zdieľaný obsah sa musí pravidelne monitorovať, aby sa zabránilo únikom údajov. 6.2.8 Keď používateľské účty už nie sú potrebné, prístup sa musí okamžite zrušiť a všetky reziduálne údaje sa musia preskúmať a archivovať alebo vymazať.

Pre podnikové prostredia priraďuje Politika používania cloudových služieb Politika používania cloudových služieb silnejšie centralizované riadenie. Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.3:

Každá cloudová služba musí mať priradeného vlastníka služby zodpovedného za riadenie životného cyklu informačných aktív, správu používania, sledovanie rozpočtu a priebežné monitorovanie súladu.

Táto veta uzatvára bežnú auditnú medzeru. Ak nikto nevlastní službu SaaS, nikto nevlastní odchýlky konfigurácie, recertifikáciu prístupov, expozíciu údajov, rozhodnutia o obnove, incidentný kontakt ani plánovanie ukončenia.

Správa privilegovaných oprávnení musí byť tiež explicitná. Politika správy používateľských účtov a oprávnení pre MSP Politika správy používateľských účtov a oprávnení – MSP, zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.4, uvádza:

Revízie prístupových práv a logovanie 6.4.1 Preskúmanie všetkých používateľských účtov a oprávnení sa musí vykonať každých šesť mesiacov. 6.4.2 Počas preskúmaní musí vedúci IT overiť, či každý účet zostáva aktívny, potrebný a má priradené správne oprávnenia. 6.4.3 Logy vytvorenia účtu, deaktivácie účtu a zmien oprávnení sa musia bezpečne uchovávať najmenej 12 mesiacov.

Pre SaaS potrebuje každá kritická platforma definovaný cyklus revízie prístupových práv, aj keď platformu spravuje obchodný tím, a nie centrálne IT.

Explicitné musí byť aj logovanie. Politika logovania a monitorovania pre MSP Politika logovania a monitorovania – MSP, zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.5, uvádza:

Cloudové služby a logovanie tretích strán 5.5.1 Pre platformy, pri ktorých logovanie nie je pod priamou kontrolou IT (napr. e-mail v SaaS), platia tieto požiadavky: 5.5.1.1 logovanie musí byť povolené a nakonfigurované tam, kde je dostupné 5.5.1.2 upozornenia musia byť smerované na poskytovateľa IT podpory 5.5.1.3 zmluvy musia vyžadovať, aby poskytovatelia uchovávali logy najmenej 12 mesiacov a na požiadanie poskytli prístup

Napokon musí byť zdokumentovaná správa a riadenie dodávateľov SaaS. Politika bezpečnosti tretích strán a dodávateľov pre MSP Politika bezpečnosti tretích strán a dodávateľov – MSP, zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.3, uvádza:

Priebežné monitorovanie bezpečnosti dodávateľov 6.3.1 Kritickí alebo vysoko rizikoví dodávatelia musia byť preskúmaní najmenej raz ročne. Preskúmanie musí overiť: 6.3.1.1 pokračujúce používanie bezpečných metód prístupu 6.3.1.2 platné bezpečnostné certifikácie alebo aktualizované dôkazy o kontrolách 6.3.1.3 históriu incidentov alebo nahlásené problémy 6.3.1.4 zmluvný súlad s bezpečnostnými doložkami 6.3.2 Tieto preskúmania musia byť zdokumentované a uchovávané so záznamom dodávateľa. Následné opatrenia musia byť jasne sledované. 6.3.3 Ak dodávatelia spravujú IT infraštruktúru alebo aplikácie, monitorovanie môže zahŕňať: 6.3.3.1 vyžiadanie auditných logov 6.3.3.2 preskúmanie aktivity účtov 6.3.3.3 potvrdenie, že nedošlo k neoprávnenému prístupu

Spoločne tieto politiky premieňajú SSPM z bezpečnostnej ambície na vynútiteľný prevádzkový model.

Tridsaťdňový dôkazový sprint SSPM

Praktický CISO alebo manažér súladu môže začať 30-dňovým dôkazovým sprintom. Vyberte päť platforiem SaaS, ktoré sú najdôležitejšie pre regulované údaje alebo kritické činnosti. Typickými kandidátmi sú Microsoft 365 alebo Google Workspace, CRM, tiketovací systém, HRIS, automatizácia financií, zákaznícka podpora a analytika.

1. týždeň: Vytvorte register SaaS

Použite polia ustanovenia 5.3 z Politiky používania cloudových služieb pre MSP ako minimálny register. Pri každej službe SaaS zachyťte:

• názov služby a účel použitia v organizácii,
• vlastníka aplikácie a technického vlastníka,
• typy údajov vrátane osobných údajov a osobitných kategórií údajov, ak je to relevantné,
• krajinu alebo región uloženia údajov,
• používateľské skupiny a administrátorské účty,
• aplikácie OAuth a integrácie tretích strán,
• vlastníka zmluvy, dátum obnovy a kontakt podpory,
• kritickosť pre činnosti organizácie,
• uplatniteľné povinnosti, napríklad NIS2, DORA, GDPR alebo zákaznícke zmluvy.

Tým sa podporujú kapitoly ISO/IEC 27001:2022 4.2 a 4.3, pretože regulačné, zmluvné a dodávateľské závislosti musia formovať rozsah ISMS. Zároveň to podporuje identifikáciu a klasifikáciu obchodných funkcií podporovaných IKT, informačných aktív, aktív IKT a závislostí v štýle DORA Article 8.

2. týždeň: Definujte bezpečné referenčné konfigurácie

Pre každú vybranú platformu SaaS definujte 10 až 15 referenčných kontrol.

• MFA vynútené pre všetkých používateľov, s MFA odolným voči phishingu pre administrátorov, kde je to možné
• Externé zdieľanie predvolene zakázané alebo obmedzené na schválené domény
• Verejné odkazy zakázané alebo časovo obmedzené
• Hosťovské účty preskúmavané mesačne
• Administrátorské roly priradené pomenovaným osobám
• Legacy autentifikácia zakázaná
• Schvaľovací pracovný tok aplikácií OAuth povolený
• Vysoko rizikové rozsahy OAuth blokované alebo vyžadujúce bezpečnostné schválenie
• Auditné logovanie povolené
• Oprávnenia na export údajov obmedzené
• Nastavenia uchovávania zosúladené so zákonnými a organizačnými požiadavkami
• API tokeny preskúmavané a rotované
• Bezpečnostné upozornenia smerované na IT alebo SOC
• Nastavenia prevencie straty údajov povolené tam, kde sú podporované
• Účty „break glass“ zdokumentované a monitorované

Zenith Blueprint, fáza Kontroly v praxi, krok 19, kontrola 8.9 riadenie konfigurácie, vysvetľuje, prečo je to dôležité:

Mnohé porušenia nevznikajú zo softvérových chýb, ale zo zlých konfiguračných rozhodnutí. Nezmenené predvolené heslá, povolené nezabezpečené služby, zbytočne otvorené porty alebo systémy vystavené internetu bez odôvodnenia. Kontrola 8.9 zabezpečuje, aby bol každý systém vybudovaný podľa bezpečnej referenčnej konfigurácie a pravidelne preskúmavaný na prevenciu odchýlok v čase.

Pri SaaS zahŕňajú odchýlky konfigurácie situácie, keď vecný vlastník povolí verejné zdieľanie, administrátor schváli široký prístup tretej strany alebo dodávateľ zmení predvolené nastavenia po vydaní novej funkcie.

3. týždeň: Preskúmajte prístup a integrácie

Exportujte používateľov, skupiny, administrátorov a pripojené aplikácie. Pri každom administrátorskom účte potvrďte pomenovanú osobu, obchodné odôvodnenie, stav MFA, posledné prihlásenie, úroveň oprávnení, pokrytie zálohovaním, otázky oddelenia povinností a dôkaz o schválení.

Pri aplikáciách OAuth a integráciách potvrďte vlastníka aplikácie, sprístupnené údaje, požadované oprávnenia, stav rizika dodávateľa, dátum posledného použitia, pretrvávajúcu potrebu a či bol súhlas udelený používateľom alebo schválený administrátorom.

Zenith Blueprint, fáza Kontroly v praxi, krok 19, kontrola 8.3 obmedzenie prístupu k informáciám, uvádza prevádzkový princíp:

Prístup k informáciám má byť taký otvorený, ako je potrebné, ale taký obmedzený, ako je možné.

Platí to nielen pre ľudí, ale aj pre aplikácie, služby a rozhrania API. Neaktívna integrácia OAuth si môže ponechať prístup dlho po tom, čo zamestnanec alebo projekt, ktorý ju vytvoril, zanikol.

4. týždeň: Vytvorte dôkazy pripravené na audit a ošetrenie rizík

Pre každú platformu SaaS uložte záznam v registri, referenčnú konfiguráciu, snímky obrazovky alebo exporty preukazujúce kľúčové nastavenia, potvrdenie revízie prístupových práv, dôkaz o preskúmaní administrátorov, dôkaz o preskúmaní OAuth, dôkazy o logovaní a upozorňovaní, záznam o preskúmaní bezpečnosti dodávateľa, otvorené zistenia a opatrenia na ošetrenie rizík.

Následne vytvorte jednostranový súhrn pre manažment, ktorý ukáže kritické zistenia, vlastníkov po lehote, nevyriešené vysoko rizikové medzery v konfigurácii, neschválené integrácie, medzery v logovaní, výnimky a požadované rozhodnutia. Podporuje to ISO/IEC 27001:2022 kapitolu 9.1 monitorovanie, kapitolu 9.2 interný audit a kapitolu 9.3 preskúmanie manažmentom. Zároveň vytvára praktické premostenie na zodpovednosť manažmentu podľa NIS2 Article 20 a dohľad riadiaceho orgánu podľa DORA.

Mapovanie naprieč rámcami súladu: jeden dôkazový balík SSPM, viacero povinností

Hodnota SSPM pre organizáciu nespočíva len v lepšej bezpečnosti. Spočíva aj v znížení duplicity pri preukazovaní súladu.

NIS2 Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia. Evidencia SaaS podporuje správu aktív. Referenčné konfigurácie podporujú kybernetickú hygienu. MFA a revízie prístupových práv podporujú riadenie prístupu. Logovanie podporuje riadenie incidentov. Preskúmanie dodávateľov podporuje bezpečnosť dodávateľského reťazca. Periodicita dôkazov podporuje politiky a postupy na posudzovanie účinnosti.

DORA vyžaduje, aby finančné subjekty identifikovali a klasifikovali funkcie podporované IKT, informačné aktíva, aktíva IKT a závislosti od tretích strán. Vyžaduje tiež ochranné a preventívne opatrenia, riadenie prístupu, silnú autentifikáciu, šifrovanie, kontinuitu, testovanie, riadenie incidentov a správu a riadenie rizík tretích strán v oblasti IKT. Dôkazový balík SaaS SSPM môže podporiť registre DORA, mapovanie závislostí, dohľad nad zmluvami, práva na audit a plánovanie ukončenia.

GDPR vyžaduje, aby prevádzkovatelia preukázali súlad s integritou, dôvernosťou a preukázateľnou zodpovednosťou. Registre SaaS identifikujú, kde sa spracúvajú osobné údaje. Referenčné konfigurácie znižujú neoprávnené zverejnenie. Revízie prístupových práv podporujú zásadu minimálnych oprávnení. Logovanie podporuje vyšetrovanie porušení. Záznamy dodávateľov podporujú správu sprostredkovateľov a preukázateľnú zodpovednosť.

NIST CSF 2.0 pridáva užitočnú komunikačnú vrstvu. Jeho funkcia GOVERN vyžaduje, aby boli zákonné, regulačné a zmluvné požiadavky na kybernetickú bezpečnosť pochopené a riadené. Výstupy pre dodávateľský reťazec vyžadujú roly dodávateľov, zmluvy, due diligence, monitorovanie a činnosti po ukončení vzťahu. Funkcie IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER sa prirodzene mapujú na evidenciu SaaS, riadenie prístupu, ochranu údajov, logovanie, reakciu na incidenty a obnovu.

Audítori orientovaní na COBIT 2019 a ISACA zvyčajne pristupujú k SSPM cez správu a riadenie, ciele manažmentu, vlastníctvo rizík, fungovanie kontrol a uistenie. Budú sa pýtať, či sú rozhodnutia o SaaS zosúladené s podnikovými cieľmi, či sú reakcie na riziká zdokumentované, či sú priradené zodpovednosti a či uisťovacie činnosti dokazujú, že kontroly fungujú.

Pohľad audítora: ako rôzni audítori testujú stav SaaS

Silný program SSPM obstojí pri rôznych auditných štýloch, pretože vytvára dôkazy na správnej úrovni.

Audítor ISO/IEC 27001:2022 začne rozsahom, zainteresovanými stranami, posúdením rizík, vyhlásením o uplatniteľnosti a prevádzkovými dôkazmi. Ak je zahrnutá kontrola 5.23, bude očakávať dôkazy o výbere, používaní, riadení a ukončení cloudových služieb. Ak sú zahrnuté kontroly prístupových práv, vyberie vzorku používateľov a opýta sa, či sa zmeny pri nástupoch, presunoch a odchodoch odrážajú v oprávneniach v SaaS.

Posudzovateľ podľa DORA sa zameria na kritické alebo dôležité funkcie, závislosť od tretích strán v oblasti IKT, úplnosť registra, zmluvy, klasifikáciu incidentov, testovanie a plánovanie ukončenia. Ak platforma SaaS podporuje platobné operácie, onboarding zákazníkov, obchodovanie, rizikovú analytiku alebo komunikáciu s klientmi, dôkazový štandard sa zvyšuje.

Audítor GDPR alebo posudzovateľ ochrany súkromia sa bude pýtať, kde sú osobné údaje uložené, kto k nim má prístup, aké exporty a nastavenia zdieľania existujú, či sú sprostredkovatelia riadení, či logy podporujú posúdenie porušenia a či sú kontroly primerané riziku.

Dodávateľské riziko, zdieľaná zodpovednosť a pripravenosť na incidenty

SSPM často začína konfiguráciou, ale nemôže sa pri nej zastaviť. SaaS je aj otázkou dodávateľského rizika a pripravenosti na incidenty.

DORA vyžaduje, aby finančné subjekty udržiavali registre zmlúv o službách IKT, rozlišovali dohody podporujúce kritické alebo dôležité funkcie, posudzovali riziko koncentrácie, hodnotili spôsobilosť poskytovateľa a udržiavali stratégie ukončenia. Zmluvy majú riešiť opis služieb, lokalizáciu údajov, ochranu dostupnosti, autentickosti, integrity a dôvernosti, prístup k údajom, obnovu a vrátenie, pomoc pri incidentoch, spoluprácu s orgánmi, práva na ukončenie, bezpečnostné požiadavky, práva na audit a podporu pri prechode.

NIS2 Article 21 zahŕňa aj bezpečnosť dodávateľského reťazca a vyžaduje, aby subjekty zohľadňovali zraniteľnosti špecifické pre priamych dodávateľov a poskytovateľov služieb, kvalitu produktov a postupy dodávateľov v oblasti kybernetickej bezpečnosti.

V praxi má preskúmanie kritického SaaS kombinovať dôkazy z bezpečnostného dotazníka, preskúmanie zmluvy, stav zmluvy o spracúvaní osobných údajov, históriu incidentov, záväzky úrovne služieb, prístup k logom, auditné správy, dôkazy o konfigurácii a realizovateľnosť ukončenia.

Medzera v zdieľanej zodpovednosti vzniká vtedy, keď tímy predpokladajú, že certifikácia dodávateľa pokrýva konfiguráciu tenanta. Nepokrýva. Dodávateľ môže prevádzkovať bezpečnú platformu, zatiaľ čo zákazník povolí verejné zdieľanie, ponechá neaktívne administrátorské účty aktívne alebo udelí nadmerné rozsahy API. SSPM túto medzeru uzatvára.

Rovnako dôležitá je pripravenosť na incidenty. Oznamovanie významných incidentov podľa NIS2 zahŕňa 24-hodinové včasné varovanie, 72-hodinové oznámenie a záverečnú správu najneskôr jeden mesiac po 72-hodinovom oznámení. DORA vyžaduje riadenie incidentov súvisiacich s IKT s detekciou, zaznamenávaním, klasifikáciou, eskaláciou, komunikáciou a oznámením. Posúdenie porušenia ochrany osobných údajov podľa GDPR tiež závisí od včasného pochopenia toho, čo sa stalo, aké údaje boli dotknuté a koho sa to týkalo.

Ak podozrivá aplikácia OAuth pristúpila k zákazníckym súborom, potrebujete vedieť, kedy bola aplikácia autorizovaná, ktorý používateľ ju autorizoval, aké rozsahy boli udelené, ku ktorým údajom bol získaný prístup, či boli údaje stiahnuté alebo zdieľané, ktorých používateľov alebo zákazníkov sa to týkalo, či prístup zostáva aktívny a aké kroky na zamedzenie šírenia boli prijaté.

Bez logovania a uchovávania môže byť organizácia nútená predpokladať najhorší scenár. To zvyšuje právnu alebo regulačnú expozíciu, tlak na komunikáciu so zákazníkmi a regulačnú neistotu. Ak poskytovateľ SaaS účtuje auditné logy osobitne, vlastník rizika má výslovne akceptovať reziduálne riziko alebo schváliť požadovanú licenčnú úroveň. Toto rozhodnutie patrí do záznamu o ošetrení rizika a preskúmania manažmentom.

Bežné vzorce zlyhaní SSPM

Rovnaké vzorce zlyhaní sa objavujú naprieč sektormi.

Po prvé, shadow SaaS sa objaví cez faktúry, históriu prehliadača alebo logy SSO, nie cez obstarávanie. Nápravou nie je len blokovanie nástrojov. Je ňou jednoduchý vstupný proces, ktorý môžu používať obchodné tímy.

Po druhé, vlastníctvo SaaS je nejasné. CRM „vlastní obchodné oddelenie“, ale nikto v obchodnom oddelení nevie vysvetliť administrátorské roly, API tokeny, exporty údajov ani nastavenia uchovávania. Priraďte vlastníkov aplikácií a technických vlastníkov samostatne.

Po tretie, revízie prístupových práv sú príliš všeobecné. Preskúmavateľ podpíše „všetci používatelia schválení“ bez kontroly vysoko rizikových rolí, neaktívnych používateľov, hostí, externých spolupracovníkov alebo servisných účtov. Revízia prístupových práv v SSPM musí byť zoradená podľa rizika.

Po štvrté, aplikácie OAuth sa ignorujú. Mnohé organizácie preskúmavajú ľudských používateľov, ale nie oprávnenia aplikácia-aplikácia. V modernom SaaS môžu byť integrácie výkonnejšie než používatelia.

Po piate, referenčné konfigurácie existujú iba ako snímky obrazovky z certifikačného projektu. Nie sú monitorované na odchýlky. Zosúlaďte SSPM s riadením konfigurácie tak, aby sa kontroly referenčných konfigurácií stali opakujúcim sa dôkazom.

Po šieste, preskúmanie dodávateľov a preskúmanie stavu SaaS sú oddelené. Obstarávanie má zmluvu, IT má administrátorskú konzolu, ochrana súkromia má zmluvu o spracúvaní osobných údajov a bezpečnosť má register rizík. Audítor vidí fragmenty. SSPM ich spája.

Reporting manažmentu: zviditeľnite riziká SaaS pre riadiaci orgán

NIS2 aj DORA robia zo správy a riadenia IKT a kybernetickej bezpečnosti otázku manažmentu. ISO/IEC 27001:2022 tiež vyžaduje vedenie, zdroje, priradenie rolí, monitorovanie a preskúmanie manažmentom.

Účinná správa SSPM pre manažment má odpovedať na tieto otázky:

• Ktoré kritické služby SaaS sú v rozsahu?
• Ktoré regulované procesy od nich závisia?
• Ktoré obsahujú osobné údaje alebo citlivé interné informácie?
• Ktoré majú revízie prístupových práv po lehote?
• Ktoré majú nevyriešené vysoko rizikové medzery v konfigurácii?
• Ktoré majú neschválené aplikácie OAuth alebo integrácie?
• Ktorým dodávateľom chýbajú aktuálne bezpečnostné dôkazy?
• Ktoré medzery v logovaní ovplyvňujú oznamovanie incidentov?
• Ktoré výnimky vyžadujú akceptáciu rizika?
• Ktoré investície alebo rozhodnutia sú potrebné?

Tým sa SSPM mení z technického projektu upratovania na vstup pre správu a riadenie. Zároveň zvyšuje účinnosť CISO, pretože akceptácia rizika sa presúva na správnu úroveň.

Premeňte stav SaaS na dôkazy pripravené na audit

Ak sa vaša organizácia spolieha na SaaS pri regulovaných údajoch, finančných operáciách, zákazníckej podpore, HR, spolupráci, engineeringu alebo analytike, SSPM už nie je voliteľné. Je súčasťou kybernetickej hygieny, riadenia rizík IKT, zodpovednosti za ochranu súkromia a pripravenosti na audit.

Clarysec vám môže pomôcť prejsť od rozptýlených zistení v SaaS k štruktúrovanému programu riadenému dôkazmi pomocou:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint na štruktúrovanie implementácie naprieč používaním cloudu, obmedzením prístupu a riadením konfigurácie.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls na mapovanie kontrol ISO/IEC 27002:2022 na NIS2, DORA, GDPR, NIST CSF 2.0 a auditné očakávania.
• šablón politík Clarysec, ako sú Politika používania cloudových služieb Politika používania cloudových služieb, Politika používania cloudových služieb pre MSP Politika používania cloudových služieb – MSP, Politika správy používateľských účtov a oprávnení pre MSP Politika správy používateľských účtov a oprávnení – MSP, Politika logovania a monitorovania pre MSP Politika logovania a monitorovania – MSP a Politika bezpečnosti tretích strán a dodávateľov pre MSP Politika bezpečnosti tretích strán a dodávateľov – MSP na vytvorenie vynútiteľných prevádzkových pravidiel.

Začnite so svojimi piatimi najrizikovejšími platformami SaaS. Priraďte vlastníkov. Zachyťte údaje, prístup, konfiguráciu, integrácie, logy a dôkazy dodávateľov. Premeňte zistenia na opatrenia na ošetrenie rizík a rozhodnutia manažmentu.

Tak sa riadenie bezpečnostného stavu SaaS stáva viac než kategóriou nástrojov. Stáva sa obhájiteľnou disciplínou súladu pre rok 2026.

Stiahnite si šablóny politík Clarysec, použite Zenith Blueprint na naplánovanie svojho 30-dňového dôkazového sprintu SSPM a zmapujte svoje kontroly SaaS pomocou Zenith Controls skôr, než ďalší audit nájde medzery za vás.