Řízení bezpečnostního stavu SaaS pro audity v roce 2026

Auditní zjištění v SaaS, ke kterému se nikdo nehlásil

V úterý v 08:15 obdrží CISO rychle rostoucí fintech společnosti zprávu od pověřence pro ochranu osobních údajů: „Proč je export zákaznických údajů z nástroje pro spolupráci veřejně sdílitelný a kdo schválil aplikaci OAuth, která jej může číst?“

V 09:00 finance potvrzují, že nástroj je hrazen z karty oddělení, nikoli prostřednictvím centrálního nákupu. V 10:30 IT zjišťuje, že uživatel, který veřejný odkaz vytvořil, odešel ze společnosti před třemi měsíci. V poledne se právní oddělení ptá, zda jde o porušení zabezpečení osobních údajů podle GDPR. Ve 14:00 se výbor pro rizika ptá, zda problém ovlivňuje kybernetickou hygienu podle NIS2 a riziko třetích stran v oblasti ICT podle DORA. V 16:00 interní auditor požaduje výchozí konfigurace, přezkum přístupových práv administrátorů, vlastnictví cloudové služby, logy a prověrku dodavatele.

Nepříjemná pravda je, že organizace neutrpěla klasický výpadek SaaS ani selhání dodavatele. Utrpěla selhání správy a řízení.

Tento scénář již není výjimečný. Marketingový tým připojí platformu AI k CRM se širokými oprávněními OAuth. HR zakoupí specializovaný analytický nástroj mimo nákupní proces. Tým zákaznické podpory z praktických důvodů povolí veřejné exporty tiketů. Engineering začlení rozšíření prohlížeče do vývojového pracovního postupu. Každé rozhodnutí může působit jako drobnost, ale společně vytvářejí distribuovanou kontrolní plochu plnou regulovaných dat, privilegovaných pracovních postupů a provozních závislostí.

SaaS Security Posture Management, tedy SSPM, je disciplína, která tuto roztříštěnou realitu SaaS převádí na řízenou, testovanou a auditovatelnou kontrolu. Při správném zavedení poskytuje CISO, manažerům compliance, auditorům a vlastníkům podnikových procesů jednotnou důkazní stopu pro ISO/IEC 27001:2022, kybernetickou hygienu podle NIS2, riziko ICT podle DORA a odpovědnost za zabezpečení podle GDPR.

Postoj Clarysec je jednoznačný: SSPM nemá být považováno za další řídicí panel. Má být začleněno do ISMS, propojeno s vlastnictvím rizik, namapováno na právní povinnosti, podloženo politikami a testováno prostřednictvím opakovaně shromažďovaných důkazů.

Právě zde se Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls a šablony politik Clarysec stávají praktickými nástroji. Pomáhají převést rozrůstání SaaS do modelu kontrol, kterému auditor porozumí a nad kterým může řídicí orgán vykonávat dohled.

Proč se řízení bezpečnostního stavu SaaS stalo otázkou compliance

SaaS se dříve chápal jako „software, který provozuje někdo jiný“. Takové vymezení již nelze obhájit.

Podle NIS2 může mnoho poskytovatelů cloudu, SaaS, digitální infrastruktury, řízených služeb a řízených bezpečnostních služeb spadat do regulovaných požadavků na kybernetickou bezpečnost v závislosti na sektoru, velikosti, roli a kritičnosti. Ještě důležitější je, že organizace spoléhající na SaaS jej musí řídit jako součást vlastních opatření pro řízení rizik. NIS2 Article 20 ukládá řídicím orgánům odpovědnost za schvalování opatření k řízení kybernetických rizik, dohled nad jejich implementací a absolvování školení. Article 21 vyžaduje praktická technická, provozní a organizační opatření, včetně analýzy rizik, politik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného pořizování a údržby, testování účinnosti, kybernetické hygieny, kryptografie, bezpečnosti v oblasti lidských zdrojů, řízení přístupu, správy aktiv a vícefaktorové autentizace tam, kde je to vhodné.

DORA posouvá požadavky na finanční subjekty ještě výše. Od 17. ledna 2025 se DORA vztahuje na řadu organizací ve finančním sektoru jako režim digitální provozní odolnosti pro subjekty v rozsahu působnosti. Vyžaduje správu a řízení ICT, identifikaci a klasifikaci ICT aktiv a podporovaných funkcí, ochranná a preventivní opatření, řízení incidentů, kontinuitu, testování a řízení rizik třetích stran v oblasti ICT. Poskytovatelé SaaS podporující kritické nebo důležité funkce se stávají součástí důkazního perimetru DORA, zatímco regulovaný finanční subjekt zůstává odpovědný.

GDPR přidává vrstvu důkazů v oblasti ochrany soukromí. Article 5 vyžaduje integritu, důvěrnost a odpovědnost. Article 32 vyžaduje odpovídající zabezpečení zpracování. V praxi musí organizace vědět, jaké osobní údaje existují, kde se zpracovávají, kdo k nim má přístup, kteří dodavatelé je zpracovávají a jaká ochranná opatření je chrání. Chybná konfigurace SaaS mění tyto otázky v urgentní posouzení porušení zabezpečení.

ISO/IEC 27001:2022 je spojovacím prvkem. Kapitoly 4.1 až 4.4 vyžadují, aby organizace definovala kontext, požadavky zainteresovaných stran, rozsah, rozhraní a závislosti. Kapitola 5 vyžaduje vedení, politiku, role a odpovědnosti. Kapitoly 6.1.1 až 6.1.3 vyžadují posouzení rizik, ošetření rizik, Prohlášení o použitelnosti a rozhodnutí o zbytkových rizicích. Kapitoly 8.1, 8.2 a 8.3 vyžadují provozní plánování a řízení, posouzení rizik a ošetření rizik. Kapitoly 9 a 10 vyžadují monitorování, interní audit, přezkoumání vedením a zlepšování.

Pokud nedokážete odpovědět, které nástroje SaaS zpracovávají regulovaná data, kdo je vlastní, jak jsou nakonfigurovány, kdo má administrátorský přístup, které integrace jsou aktivní a jaké důkazy prokazují fungování kontrol, je vaše compliance pozice křehká.

Model SSPM podle Clarysec: registr, vlastnictví, výchozí nastavení, důkazy

Clarysec chápe SaaS Security Posture Management jako opakovatelnou kontrolní smyčku, nikoli jako jednorázový úklidový projekt.

1. Zjistit každou službu SaaS, včetně stínových SaaS služeb.
2. Přiřadit věcného vlastníka a technického vlastníka.
3. Klasifikovat data, uživatele, integrace a provozní kritičnost.
4. Uplatnit bezpečné výchozí konfigurace.
5. Přezkoumat uživatele, administrátory, hosty, servisní účty a rozsahy OAuth.
6. Povolit protokolování, upozorňování a uchovávání logů.
7. Monitorovat veřejné sdílení a expozici dat.
8. Propojit dodavatele, smlouvy, smlouvy o zpracování osobních údajů a plánování ukončení služby.
9. Shromažďovat důkazy v definované periodicitě.
10. Předávat zjištění do ošetření rizik, přezkoumání vedením a zlepšování.

Tento model úzce odpovídá opatřením ISO/IEC 27002:2022 ISO/IEC 27002:2022, zejména 5.9 evidence informací a dalších souvisejících aktiv, 5.15 řízení přístupu, 5.18 přístupová práva, 5.19 bezpečnost informací ve vztazích s dodavateli, 5.20 řešení bezpečnosti informací ve smlouvách s dodavateli, 5.21 řízení bezpečnosti informací v dodavatelském řetězci ICT, 5.23 bezpečnost informací při využívání cloudových služeb, 8.2 privilegovaná přístupová práva, 8.3 omezení přístupu k informacím, 8.9 řízení konfigurace, 8.15 protokolování, 8.16 monitorovací činnosti a 8.32 řízení změn.

Zenith Blueprint ve fázi Controls in Action, krok 23 pro organizační opatření, uvádí:

Cloud již není cílovým místem, je výchozím stavem. Od úložišť po spolupráci, od infrastruktury po strojové učení jsou organizace stále častěji postaveny na vrstvách prostředí třetích stran, abstrahovaných a spravovaných na dálku. Opatření 5.23 tuto realitu uznává a vyžaduje, aby bezpečnost informací byla výslovně řešena při výběru, používání a správě cloudových služeb, nikoli dodatečně, ale jako návrhový princip od samého začátku.

To je podstata SSPM. Nejde jen o dodatečnou detekci chybných konfigurací. Jde o to, aby výběr SaaS, onboarding, provoz, monitorování a ukončení byly součástí systému řízení.

Stejná část Zenith Blueprint vysvětluje realitu sdílené odpovědnosti jazykem, který by měl slyšet každý člen řídicích orgánů:

Poskytovatelé cloudu zabezpečují infrastrukturu, ale vy nadále odpovídáte za svá data, své konfigurace, své politiky přístupu a svou připravenost na reakci na incidenty. Chybně nakonfigurované cloudové úložiště, veřejně vystavený řídicí panel nebo nadměrná oprávnění v nastavení cloudového IAM nejsou selháním cloudu. Jsou to selhání správy a řízení.

Poskytovatel může provozovat platformu, ale konfigurace tenantu, identity, schválení přístupů, exponovaná data, integrace, incidentní pracovní postupy a důkazy o souladu zůstávají vaší odpovědností.

Opatření 5.23 je kotva, ale SSPM potřebuje rodinu kontrol

V Zenith Controls je opatření ISO/IEC 27002:2022 5.23, bezpečnost informací při využívání cloudových služeb, klasifikováno jako preventivní kontrola podporující důvěrnost, integritu a dostupnost. Jeho koncept kybernetické bezpečnosti je Protect, s provozní způsobilostí v oblasti bezpečnosti vztahů s dodavateli a doménami napříč správou a řízením, ekosystémem a ochranou.

Je to důležité, protože SSPM není jedna samostatná kontrola. Je to průřezová disciplína napříč kontrolami.

Zenith Controls propojuje 5.23 se vztahy s dodavateli podle 5.19, protože poskytovatelé SaaS jsou kritičtí dodavatelé, ale 5.23 přidává specifické otázky SaaS, jako je multi-tenancy, transparentnost umístění dat a sdílená odpovědnost. Propojuje 5.23 s přenosem informací, protože rozhraní API, integrace a pracovní postupy mezi SaaS neustále přesouvají data. Propojuje 5.23 s evidencí aktiv, protože organizace potřebují aktuální přehled o datech uložených v cloudu a o zdrojích SaaS. Zároveň propojuje správu cloudu s monitorováním, omezením přístupu, řízením konfigurace a dohledem nad dodavateli.

U přístupových práv Zenith Controls mapuje 5.18 na 5.15 řízení přístupu, 5.16 správu identit, 5.3 oddělení povinností, 5.36 soulad s politikami, pravidly a standardy bezpečnosti informací a 8.2 privilegovaná přístupová práva. Pro SSPM to znamená, že přezkum přístupových práv není jen cvičení v tabulce. Je to provozní důkaz, že životní cyklus identit, zásada nejnižších oprávnění, oddělení povinností a správa privilegovaných přístupů fungují uvnitř aplikací SaaS.

Základ v politikách: definujte správný stav před nákupem nástrojů

Mnoho selhání SaaS začíná nejasným zněním politik. „Používejte schválené nástroje bezpečně“ nestačí. Politiky Clarysec definují konkrétní očekávání pro registry, přístup, protokolování, konfiguraci a přezkum dodavatelů.

Pro malé a střední podniky poskytuje Politika používání cloudových služeb pro SME Politika používání cloudových služeb – SME praktický výchozí bod. Z části „Požadavky na správu a řízení“, ustanovení politiky 5.3:

Registr cloudových služeb musí udržovat poskytovatel IT služeb nebo generální manažer (GM). Musí zaznamenávat: 5.3.1 Název a účel každé schválené cloudové služby 5.3.2 Odpovědnou osobu nebo tým (vlastník aplikace) 5.3.3 Typy ukládaných nebo zpracovávaných dat 5.3.4 Zemi nebo region, kde jsou data uložena 5.3.5 Přístupová oprávnění uživatelů a administrátorské účty 5.3.6 Smluvní údaje, data obnovení a kontakty podpory

Toto ustanovení je provozním jádrem SSPM. Poskytuje auditorům první důkazní objekt: registr, který propojuje používání SaaS s vlastníky, daty, geografií, přístupem a smlouvami.

Stejná Politika používání cloudových služeb pro SME, z části „Požadavky na implementaci politiky“, ustanovení politiky 6.2, definuje výchozí nastavení:

Požadavky na bezpečnostní konfiguraci 6.2.1 Na všech cloudových platformách musí být povoleno následující: 6.2.2 Vícefaktorová autentizace (MFA) pro administrátorské a uživatelské účty 6.2.3 Nastavení složitosti hesla (minimálně 10 znaků, bez opakovaného použití) 6.2.4 Protokolování aktivit pro pokusy o přihlášení a přístup k datům 6.2.5 Omezení přístupu (např. seznam povolených IP adres, je-li podporován) 6.2.6 Administrátorský přístup musí být omezen na jmenovitě určené osoby nebo autorizované poskytovatele podpory. 6.2.7 Veřejně sdílený obsah musí být pravidelně monitorován, aby se zabránilo úniku dat. 6.2.8 Pokud uživatelské účty již nejsou potřebné, přístup musí být okamžitě odebrán a veškerá zbytková data musí být přezkoumána a archivována nebo smazána.

Pro podniková prostředí přiřazuje Politika používání cloudových služeb Politika používání cloudových služeb silnější centralizovanou správu. Z části „Požadavky na správu a řízení“, ustanovení politiky 5.3:

Každá cloudová služba musí mít přiřazeného vlastníka služby odpovědného za řízení životního cyklu informačního aktiva, správu používání, sledování rozpočtu a průběžné monitorování souladu.

Tato věta uzavírá běžnou auditní mezeru. Pokud službu SaaS nikdo nevlastní, nikdo nevlastní ani odchylky konfigurace, recertifikaci přístupu, expozici dat, rozhodnutí o obnovení, incidentní kontakt ani plánování ukončení.

Správa oprávnění musí být rovněž výslovná. Politika správy uživatelských účtů a oprávnění pro SME Politika správy uživatelských účtů a oprávnění – SME, z části „Požadavky na implementaci politiky“, ustanovení politiky 6.4, uvádí:

Přezkum přístupových práv a protokolování 6.4.1 Přezkum všech uživatelských účtů a oprávnění musí být prováděn každých šest měsíců. 6.4.2 Během přezkumů musí vedoucí IT ověřit, zda každý účet zůstává aktivní, nezbytný a má přiřazena správná oprávnění. 6.4.3 Logy vytvoření účtu, deaktivace účtu a změn oprávnění musí být bezpečně uchovávány alespoň 12 měsíců.

U SaaS potřebuje každá kritická platforma definovaný cyklus přezkumu přístupových práv, i když je platforma spravována obchodním týmem, nikoli centrálním IT.

Výslovné musí být také protokolování. Politika protokolování a monitorování pro SME Politika protokolování a monitorování – SME, z části „Požadavky na správu a řízení“, ustanovení politiky 5.5, uvádí:

Cloudové služby a protokolování třetích stran 5.5.1 Pro platformy, u nichž protokolování není pod přímou kontrolou IT (např. e-mail v SaaS), platí následující požadavky: 5.5.1.1 Protokolování musí být povoleno a nakonfigurováno tam, kde je dostupné 5.5.1.2 Upozornění musí být směrována na poskytovatele IT podpory 5.5.1.3 Smlouvy musí vyžadovat, aby poskytovatelé uchovávali logy alespoň 12 měsíců a poskytli k nim přístup na vyžádání

Nakonec musí být dokumentována správa dodavatelů SaaS. Bezpečnostní politika pro dodavatele a poskytovatele služeb třetích stran pro SME Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran – SME, z části „Požadavky na implementaci politiky“, ustanovení politiky 6.3, uvádí:

Průběžné monitorování bezpečnosti dodavatelů 6.3.1 Kritičtí nebo vysoce rizikoví dodavatelé musí být přezkoumáni alespoň jednou ročně. Přezkum musí ověřit: 6.3.1.1 Pokračující používání bezpečných metod přístupu 6.3.1.2 Platné bezpečnostní certifikace nebo aktualizované důkazy o kontrolách 6.3.1.3 Historii incidentů nebo hlášené problémy 6.3.1.4 Smluvní soulad s bezpečnostními doložkami 6.3.2 Tyto přezkumy musí být dokumentovány a uchovávány se záznamem dodavatele. Navazující opatření musí být jasně sledována. 6.3.3 Pokud dodavatelé spravují IT infrastrukturu nebo aplikace, monitorování může zahrnovat: 6.3.3.1 Vyžádání auditních logů 6.3.3.2 Přezkum aktivity účtů 6.3.3.3 Potvrzení, že nedošlo k neoprávněnému přístupu

Společně tyto politiky mění SSPM z bezpečnostní ambice na vymahatelný provozní model.

30denní sprint důkazů SSPM

Prakticky orientovaný CISO nebo manažer compliance může začít 30denním sprintem důkazů. Vyberte pět platforem SaaS, které jsou nejdůležitější pro regulovaná data nebo kritické provozní činnosti. Typickými kandidáty jsou Microsoft 365 nebo Google Workspace, CRM, ticketovací systém, HRIS, automatizace financí, zákaznická podpora a analytika.

1. týden: Vytvořte registr SaaS

Použijte pole z ustanovení 5.3 Politiky používání cloudových služeb pro SME jako minimální registr. U každé služby SaaS zaznamenejte:

• Název služby a obchodní účel
• Vlastníka aplikace a technického vlastníka
• Typy dat, včetně osobních údajů a zvláštních kategorií údajů, kde je to relevantní
• Zemi nebo region uložení dat
• Skupiny uživatelů a administrátorské účty
• Aplikace OAuth a integrace třetích stran
• Vlastníka smlouvy, datum obnovení a kontakt podpory
• Kritičnost pro provoz
• Příslušné povinnosti, například NIS2, DORA, GDPR nebo zákaznické smlouvy

To podporuje kapitoly ISO/IEC 27001:2022 4.2 a 4.3, protože regulační, smluvní a třetími stranami podmíněné závislosti musí utvářet rozsah ISMS. Podporuje to také identifikaci a klasifikaci podnikových funkcí podporovaných ICT, informačních aktiv, ICT aktiv a závislostí ve stylu DORA Article 8.

2. týden: Definujte bezpečné výchozí konfigurace

Pro každou vybranou platformu SaaS definujte 10 až 15 výchozích kontrol.

• MFA vynucená pro všechny uživatele, s MFA odolnou vůči phishingu pro administrátory tam, kde je to možné
• Externí sdílení ve výchozím nastavení vypnuté nebo omezené na schválené domény
• Veřejné odkazy vypnuté nebo časově omezené
• Hostovské účty přezkoumávané měsíčně
• Administrátorské role přiřazené jmenovitě určeným osobám
• Starší autentizace zakázaná
• Schvalovací workflow aplikací OAuth povolené
• Vysoce rizikové rozsahy OAuth blokované nebo vyžadující bezpečnostní schválení
• Auditní protokolování povolené
• Oprávnění k exportu dat omezená
• Nastavení uchovávání sladěná s právními a obchodními požadavky
• API tokeny přezkoumávané a rotované
• Bezpečnostní upozornění směrovaná na IT nebo SOC
• Nastavení prevence ztráty dat povolená tam, kde jsou podporována
• Účty nouzového přístupu „break-glass“ dokumentované a monitorované

Zenith Blueprint, fáze Controls in Action, krok 19, opatření 8.9 řízení konfigurace, vysvětluje, proč na tom záleží:

Mnoho porušení zabezpečení nevzniká kvůli chybám softwaru, ale kvůli špatným rozhodnutím v konfiguraci. Výchozí hesla ponechaná beze změny, povolené nezabezpečené služby, zbytečně otevřené porty nebo systémy vystavené internetu bez odůvodnění. Opatření 8.9 zajišťuje, že každý systém je postaven na bezpečné výchozí konfiguraci a pravidelně přezkoumáván, aby se v čase zabránilo odchylkám konfigurace.

U SaaS zahrnují odchylky konfigurace například situaci, kdy věcný vlastník povolí veřejné sdílení, administrátor schválí široký přístup třetí strany nebo dodavatel po vydání nové funkce změní výchozí nastavení.

3. týden: Přezkoumejte přístup a integrace

Exportujte uživatele, skupiny, administrátory a připojené aplikace. U každého administrátorského účtu potvrďte jmenovitě určenou osobu, obchodní odůvodnění, stav MFA, poslední přihlášení, úroveň oprávnění, pokrytí zálohováním, případné otázky oddělení povinností a důkazy o schválení.

U aplikací OAuth a integrací potvrďte vlastníka aplikace, zpřístupněná data, požadovaná oprávnění, stav dodavatelského rizika, datum posledního použití, trvající potřebu a to, zda byl souhlas udělen uživatelem nebo schválen administrátorem.

Zenith Blueprint, fáze Controls in Action, krok 19, opatření 8.3 omezení přístupu k informacím, uvádí provozní princip:

Přístup k informacím má být tak otevřený, jak je nezbytné, ale tak omezený, jak je možné.

To platí nejen pro osoby, ale také pro aplikace, služby a rozhraní API. Neaktivní integrace OAuth si může ponechat přístup dlouho poté, co zaměstnanec nebo projekt, který ji vytvořil, zmizel.

4. týden: Připravte důkazy pro audit a ošetření rizik

U každé platformy SaaS uložte záznam v registru, výchozí konfiguraci, snímky obrazovky nebo exporty prokazující klíčová nastavení, schválení přezkumu přístupových práv, důkazy z přezkumu administrátorů, důkazy z přezkumu OAuth, důkazy o protokolování a upozorňování, záznam o bezpečnostním přezkumu dodavatele, otevřená zjištění a opatření k ošetření rizik.

Poté vytvořte jednostránkové shrnutí pro vedení s kritickými zjištěními, vlastníky po termínu, nevyřešenými vysoce rizikovými konfiguračními mezerami, neschválenými integracemi, mezerami v protokolování, výjimkami a požadovanými rozhodnutími. To podporuje kapitolu ISO/IEC 27001:2022 9.1 monitorování, kapitolu 9.2 interní audit a kapitolu 9.3 přezkoumání vedením. Zároveň vytváří praktický most k odpovědnosti vedení podle NIS2 Article 20 a dohledu řídicího orgánu podle DORA.

Mapování napříč požadavky: jedna důkazní sada SSPM, mnoho povinností

Obchodní hodnota SSPM nespočívá jen ve vyšší bezpečnosti. Spočívá také ve snížení duplicit v oblasti compliance.

NIS2 Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření. Registr SaaS podporuje správu aktiv. Výchozí konfigurace podporují kybernetickou hygienu. MFA a přezkum přístupových práv podporují řízení přístupu. Protokolování podporuje zvládání incidentů. Přezkum dodavatelů podporuje zabezpečení dodavatelského řetězce. Periodicita důkazů podporuje politiky a postupy pro posouzení účinnosti.

DORA vyžaduje, aby finanční subjekty identifikovaly a klasifikovaly funkce podporované ICT, informační aktiva, ICT aktiva a závislosti na třetích stranách. Vyžaduje také ochranná a preventivní opatření, řízení přístupu, silnou autentizaci, šifrování, kontinuitu, testování, řízení incidentů a správu rizik třetích stran v oblasti ICT. Důkazní sada SSPM pro SaaS může podpořit registry DORA, mapování závislostí, dohled nad smlouvami, práva na audit a plánování ukončení.

GDPR vyžaduje, aby správci prokázali soulad s integritou, důvěrností a odpovědností. Registry SaaS identifikují, kde se zpracovávají osobní údaje. Výchozí konfigurace snižují neoprávněné zpřístupnění. Přezkum přístupových práv podporuje zásadu nejnižších oprávnění. Protokolování podporuje vyšetřování porušení zabezpečení. Záznamy o dodavatelích podporují správu zpracovatelů a odpovědnost.

NIST CSF 2.0 přidává užitečnou komunikační vrstvu. Jeho funkce GOVERN vyžaduje, aby právní, regulační a smluvní požadavky na kybernetickou bezpečnost byly pochopeny a řízeny. Výstupy pro dodavatelský řetězec vyžadují role dodavatelů, smlouvy, náležitou péči, monitorování a činnosti po ukončení vztahu. Funkce IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER se přirozeně mapují na registr SaaS, řízení přístupu, ochranu údajů, protokolování, reakci na incidenty a obnovu.

Auditoři orientovaní na COBIT 2019 a ISACA budou k SSPM obvykle přistupovat přes správu a řízení, manažerské cíle, vlastnictví rizik, fungování kontrol a zajištění. Budou se ptát, zda jsou rozhodnutí o SaaS sladěna s cíli podniku, zda jsou reakce na rizika dokumentovány, zda jsou přiřazeny odpovědnosti a zda činnosti zajištění prokazují fungování kontrol.

Auditní pohled: jak různí auditoři testují stav SaaS

Silný program SSPM obstojí při různých auditních stylech, protože vytváří důkazy na správné úrovni.

Auditor ISO/IEC 27001:2022 začne rozsahem, zainteresovanými stranami, posouzením rizik, Prohlášením o použitelnosti a provozními důkazy. Pokud je zahrnuto opatření 5.23, bude očekávat důkazy pro výběr, používání, správu a ukončení cloudových služeb. Pokud jsou zahrnuta opatření přístupových práv, vybere vzorek uživatelů a bude se ptát, zda se změny při nástupu, přesunu a odchodu promítají do oprávnění v SaaS.

Přezkoumávající osoba podle DORA se zaměří na kritické nebo důležité funkce, závislosti na třetích stranách v oblasti ICT, úplnost registru, smlouvy, klasifikaci incidentů, testování a plánování ukončení. Pokud platforma SaaS podporuje platební operace, onboarding zákazníků, obchodování, analýzu rizik nebo klientskou komunikaci, standard důkazů se zvyšuje.

Auditor GDPR nebo přezkoumávající osoba v oblasti ochrany soukromí se zeptá, kde jsou osobní údaje uloženy, kdo k nim má přístup, jaké existují exporty a nastavení sdílení, zda jsou zpracovatelé řízeni, zda logy podporují posouzení porušení zabezpečení a zda jsou kontroly přiměřené riziku.

Dodavatelské riziko, sdílená odpovědnost a připravenost na incidenty

SSPM často začíná konfigurací, ale u ní nesmí skončit. SaaS je také otázkou dodavatelského rizika a připravenosti na incidenty.

DORA vyžaduje, aby finanční subjekty vedly registry smluv o službách ICT, rozlišovaly ujednání podporující kritické nebo důležité funkce, posuzovaly riziko koncentrace, hodnotily vhodnost poskytovatele a udržovaly strategie ukončení. Smlouvy by měly řešit popis služeb, umístění dat, ochranu dostupnosti, autenticity, integrity a důvěrnosti, přístup k datům, obnovu a vrácení, podporu při incidentech, spolupráci s orgány, práva na ukončení, bezpečnostní požadavky, práva na audit a podporu přechodu.

NIS2 Article 21 zahrnuje také zabezpečení dodavatelského řetězce a vyžaduje, aby subjekty zohledňovaly zranitelnosti specifické pro přímé dodavatele a poskytovatele služeb, kvalitu produktů a postupy dodavatelů v oblasti kybernetické bezpečnosti.

V praxi by měl přezkum kritického SaaS spojovat důkazy z bezpečnostního dotazníku, přezkum smlouvy, stav smlouvy o zpracování osobních údajů, historii incidentů, závazky úrovně služeb, přístup k logům, auditní zprávy, důkazy o konfiguraci a proveditelnost ukončení.

Mezera ve sdílené odpovědnosti vzniká tehdy, když týmy předpokládají, že certifikace dodavatele pokrývá konfiguraci tenantu. Nepokrývá. Dodavatel může provozovat bezpečnou platformu, zatímco zákazník povolí veřejné sdílení, ponechá aktivní neaktivní administrátorské účty nebo udělí nadměrné rozsahy API. SSPM tuto mezeru uzavírá.

Stejně důležitá je připravenost na incidenty. Hlášení významných incidentů podle NIS2 zahrnuje včasné varování do 24 hodin, oznámení do 72 hodin a závěrečnou zprávu nejpozději do jednoho měsíce po oznámení v 72hodinové lhůtě. DORA vyžaduje řízení incidentů souvisejících s ICT s detekcí, zaznamenáním, klasifikací, eskalací, komunikací a oznamováním. Posouzení porušení zabezpečení osobních údajů podle GDPR závisí také na včasném pochopení toho, co se stalo, jaká data byla dotčena a kdo byl zasažen.

Pokud podezřelá aplikace OAuth přistoupila k zákaznickým souborům, musíte vědět, kdy byla aplikace autorizována, který uživatel ji autorizoval, jaké rozsahy byly uděleny, k jakým datům bylo přistoupeno, zda byla data stažena nebo sdílena, kterých uživatelů nebo zákazníků se to týkalo, zda přístup zůstává aktivní a jaká opatření k zamezení šíření byla přijata.

Bez protokolování a uchovávání logů může být organizace nucena vycházet z nejhoršího možného scénáře. To zvyšuje právní expozici, tlak na komunikaci se zákazníky a regulační nejistotu. Pokud si poskytovatel SaaS účtuje auditní logy zvlášť, vlastník rizika musí výslovně přijmout zbytkové riziko nebo schválit požadovanou licenční úroveň. Toto rozhodnutí patří do záznamu o ošetření rizik a do přezkoumání vedením.

Běžné vzorce selhání SSPM

Stejné vzorce selhání se objevují napříč sektory.

Za prvé, stínové SaaS služby jsou zjištěny prostřednictvím faktur, historie prohlížeče nebo logů SSO, nikoli přes nákupní proces. Řešením není pouze blokování nástrojů. Je jím lehký proces příjmu požadavků, který mohou obchodní týmy používat.

Za druhé, vlastnictví SaaS je nejasné. CRM je „vlastněno obchodem“, ale nikdo v obchodním týmu nedokáže vysvětlit administrátorské role, API tokeny, exporty dat ani nastavení uchovávání. Přiřaďte vlastníky aplikací a technické vlastníky samostatně.

Za třetí, přezkum přístupových práv je příliš obecný. Přezkoumávající osoba schválí „všichni uživatelé schváleni“, aniž by prověřila role s vysokým rizikem, neaktivní uživatele, hosty, externí spolupracovníky nebo servisní účty. Přezkum přístupových práv v SSPM musí být odstupňován podle rizika.

Za čtvrté, aplikace OAuth jsou ignorovány. Mnoho organizací přezkoumává lidské uživatele, ale nikoli oprávnění mezi aplikacemi. V moderním SaaS mohou být integrace výkonnější než uživatelé.

Za páté, výchozí konfigurace existují pouze jako snímky obrazovky z certifikačního projektu. Nejsou monitorovány z hlediska odchylek konfigurace. Slaďte SSPM s řízením konfigurace tak, aby se kontroly výchozího stavu staly opakovaným důkazem.

Za šesté, přezkum dodavatelů a přezkum stavu SaaS jsou oddělené. Procurement má smlouvu, IT má administrátorskou konzoli, Privacy má smlouvu o zpracování osobních údajů a Security má registr rizik. Auditor vidí fragmenty. SSPM je spojuje.

Reporting vedení: zviditelněte riziko SaaS pro řídicí orgány

NIS2 i DORA činí ze správy a řízení ICT a kybernetické bezpečnosti téma pro vedení. ISO/IEC 27001:2022 rovněž vyžaduje vedení, zdroje, přiřazení rolí, monitorování a přezkoumání vedením.

Účinný report vedení k SSPM by měl odpovědět na otázky:

• Které kritické služby SaaS jsou v rozsahu?
• Které regulované procesy na nich závisejí?
• Které obsahují osobní údaje nebo citlivá obchodní data?
• Které mají přezkum přístupových práv po termínu?
• Které mají nevyřešené vysoce rizikové konfigurační mezery?
• Které mají neschválené aplikace OAuth nebo integrace?
• Kterým dodavatelům chybí aktuální bezpečnostní důkazy?
• Které mezery v protokolování ovlivňují hlášení incidentů?
• Které výjimky vyžadují přijetí rizika?
• Jaké investice nebo rozhodnutí jsou potřeba?

Tím se SSPM mění z technického úklidového projektu na vstup pro správu a řízení. Zároveň zvyšuje účinnost CISO, protože přijetí rizika se přesouvá na správnou úroveň.

Přeměňte stav SaaS na důkazy připravené pro audit

Pokud vaše organizace spoléhá na SaaS pro regulovaná data, finanční operace, zákaznickou podporu, HR, spolupráci, engineering nebo analytiku, SSPM již není volitelné. Je součástí kybernetické hygieny, řízení rizik ICT, odpovědnosti za ochranu soukromí a připravenosti na audit.

Clarysec vám může pomoci přejít od roztříštěných zjištění v SaaS ke strukturovanému programu řízenému důkazy pomocí:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pro strukturování implementace napříč používáním cloudu, omezením přístupu a řízením konfigurace.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls pro mapování opatření ISO/IEC 27002:2022 na NIS2, DORA, GDPR, NIST CSF 2.0 a auditní očekávání.
• Šablon politik Clarysec, jako jsou Politika používání cloudových služeb Politika používání cloudových služeb, Politika používání cloudových služeb pro SME Politika používání cloudových služeb – SME, Politika správy uživatelských účtů a oprávnění pro SME Politika správy uživatelských účtů a oprávnění – SME, Politika protokolování a monitorování pro SME Politika protokolování a monitorování – SME a Bezpečnostní politika pro dodavatele a poskytovatele služeb třetích stran pro SME Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran – SME, které pomáhají vytvořit vymahatelná provozní pravidla.

Začněte pěti nejrizikovějšími platformami SaaS. Přiřaďte vlastníky. Zachyťte data, přístup, konfiguraci, integrace, logy a důkazy o dodavatelích. Převeďte zjištění na opatření k ošetření rizik a rozhodnutí vedení.

Tak se SaaS Security Posture Management stává něčím víc než kategorií nástrojů. Stává se obhajitelnou disciplínou compliance pro rok 2026.

Stáhněte si šablony politik Clarysec, použijte Zenith Blueprint k naplánování svého 30denního sprintu důkazů SSPM a namapujte své kontroly SaaS pomocí Zenith Controls dříve, než mezery odhalí váš příští audit.