SaaS biztonsági állapotkezelés a 2026-os auditokhoz

A SaaS-auditmegállapítás, amelynek nem volt gazdája

Kedden 08:15-kor egy gyorsan növekvő fintech vállalat CISO-ja üzenetet kap az adatvédelmi tisztviselőtől: „Miért osztható meg nyilvánosan egy együttműködési eszközből származó ügyfélexport, és ki hagyta jóvá azt az OAuth-alkalmazást, amely olvasási jogosultsággal rendelkezik?”

09:00-ra a pénzügy megerősíti, hogy az eszközért egy részlegi bankkártyával fizetnek, nem központi beszerzésen keresztül. 10:30-ra az IT kideríti, hogy a nyilvános hivatkozást létrehozó felhasználó három hónapja elhagyta a vállalatot. Délben a jogi terület azt kérdezi, hogy ez GDPR szerinti személyesadat-sértésnek minősül-e. 14:00-kor a kockázati bizottság arra kérdez rá, hogy az ügy érinti-e a NIS2 szerinti kiberhigiéniát és a DORA szerinti IKT harmadik féllel kapcsolatos kockázatot. 16:00-kor a belső auditor konfigurációs alapbeállításokat, adminisztrátori hozzáférés-felülvizsgálatokat, felhőszolgáltatási tulajdonosi felelősséget, naplókat és beszállítói átvilágítást kér.

A fájdalmas igazság az, hogy a szervezetet nem klasszikus SaaS-kiesés vagy beszállítói hiba érte. Irányítási hiba történt.

Ez a forgatókönyv már nem kivételes. Egy marketingcsapat széles OAuth-jogosultságokkal csatlakoztat egy AI-platformot egy CRM-hez. A HR a beszerzést megkerülve vásárol egy réspiaci analitikai eszközt. Egy ügyféltámogatási csapat kényelmi okból engedélyezi a nyilvános jegyexportokat. A fejlesztés böngészőbővítményt integrál egy fejlesztési munkafolyamatba. Egy-egy döntés jelentéktelennek tűnhet, de együtt olyan elosztott kontrollfelületet hoznak létre, amely szabályozott adatokkal, emelt jogosultságú munkafolyamatokkal és működési függőségekkel van tele.

A SaaS biztonsági állapotkezelés, röviden SSPM, az a szakterület, amely ezt a szétszórt SaaS-valóságot irányított, tesztelt és auditálható kontrollrendszerré alakítja. Jól megvalósítva egységes bizonyítékláncot ad a CISO-k, megfelelési vezetők, auditorok és üzleti tulajdonosok kezébe az ISO/IEC 27001:2022, a NIS2 szerinti kiberhigiénia, a DORA szerinti IKT-kockázat és a GDPR szerinti biztonsági elszámoltathatóság támogatására.

A Clarysec álláspontja egyértelmű: az SSPM-et nem szabad újabb irányítópultként kezelni. Be kell építeni az IBIR-be, össze kell kapcsolni a kockázattulajdonosi felelősséggel, meg kell feleltetni a jogi kötelezettségeknek, szabályzatokkal kell alátámasztani, és ismétlődő bizonyítékokkal kell tesztelni.

Itt válik gyakorlati eszközzé a Zenith Blueprint: Az auditor 30 lépéses ütemterve Zenith Blueprint, a Zenith Controls: A keresztmegfelelési útmutató Zenith Controls és a Clarysec szabályzatsablonjai. Segítenek a SaaS-szétterjedést olyan kontrollmodellé alakítani, amelyet az auditor értelmezni, a vezető testület pedig felügyelni tud.

Miért vált a SaaS biztonsági állapotkezelés megfelelési kérdéssé

A SaaS-t korábban úgy kezelték, mint „szoftvert, amelyet valaki más üzemeltet”. Ez a megközelítés ma már nem tartható.

A NIS2 alapján számos felhő-, SaaS-, digitális infrastruktúra-, menedzselt szolgáltatói és menedzselt biztonsági szolgáltatói szervezet ágazattól, mérettől, szereptől és kritikusságtól függően szabályozott kiberbiztonsági elvárások hatálya alá eshet. Ami még fontosabb: a SaaS-ra támaszkodó szervezeteknek azt saját kockázatkezelési intézkedéseik részeként kell irányítaniuk. A NIS2 Article 20 a vezető testületeket teszi felelőssé a kiberbiztonsági kockázatkezelési intézkedések jóváhagyásáért, végrehajtásuk felügyeletéért és a képzésben való részvételért. Az Article 21 gyakorlati technikai, működési és szervezeti intézkedéseket ír elő, beleértve a kockázatelemzést, a szabályzatokat, az incidenskezelést, az üzletmenet-folytonosságot, az ellátásilánc-biztonságot, a biztonságos beszerzést és karbantartást, az eredményességi tesztelést, a kiberhigiéniát, a kriptográfiát, a HR-biztonságot, a hozzáférés-szabályozást, az eszközkezelést és szükség esetén a többtényezős hitelesítést.

A DORA tovább emeli a mércét a pénzügyi szervezetek számára. 2025. január 17. óta a DORA számos pénzügyi ágazati szervezetre alkalmazandó, mint a hatálya alá tartozó szervezetek digitális működési reziliencia-keretrendszere. IKT-irányítást, az IKT-eszközök és a támogatott funkciók azonosítását és osztályozását, védelmi és megelőző kontrollokat, incidenskezelést, folytonosságot, tesztelést és IKT harmadik fél kockázatkezelést ír elő. A kritikus vagy fontos funkciókat támogató SaaS-szolgáltatók a DORA bizonyítási körének részévé válnak, miközben az elszámoltathatóság továbbra is a szabályozott pénzügyi szervezetnél marad.

A GDPR adatvédelmi bizonyítékréteget ad hozzá. Az Article 5 sértetlenséget, bizalmasságot és elszámoltathatóságot követel meg. Az Article 32 megfelelő adatkezelési biztonságot ír elő. A gyakorlatban a szervezetnek tudnia kell, milyen személyes adatok léteznek, hol kezelik azokat, ki férhet hozzájuk, mely beszállítók kezelik őket, és milyen védelmi intézkedések védik az adatokat. Egy SaaS-hibás konfiguráció ezeket a kérdéseket sürgős incidenshatás-vizsgálati kérdésekké alakítja.

Az ISO/IEC 27001:2022 jelenti a hidat. A 4.1–4.4 pontok megkövetelik, hogy a szervezet meghatározza a kontextust, az érdekelt felek követelményeit, a hatályt, az interfészeket és a függőségeket. Az 5. pont vezetést, szabályzatot, szerepköröket és elszámoltathatóságot követel meg. A 6.1.1–6.1.3 pontok kockázatértékelést, kockázatkezelést, alkalmazhatósági nyilatkozatot és maradványkockázati döntéseket írnak elő. A 8.1, 8.2 és 8.3 pontok működéstervezést, kockázatértékelést és kockázatkezelést követelnek meg. A 9. és 10. pontok felügyeletet, belső auditot, vezetőségi felülvizsgálatot és fejlesztést írnak elő.

Ha nem tudja megválaszolni, mely SaaS-eszközök kezelnek szabályozott adatokat, kik a tulajdonosaik, hogyan vannak konfigurálva, kinek van adminisztrátori hozzáférése, mely integrációk aktívak, és milyen bizonyíték igazolja a kontrollok működését, akkor a megfelelési helyzete sérülékeny.

A Clarysec SSPM-modellje: nyilvántartás, tulajdonosi felelősség, alapbeállítás, bizonyíték

A Clarysec a SaaS biztonsági állapotkezelést ismételhető kontrollciklusként kezeli, nem egyszeri rendbetételi projektként.

1. Fel kell deríteni minden SaaS-szolgáltatást, beleértve az árnyék-SaaS-t is.
2. Ki kell jelölni az üzleti tulajdonost és a technikai tulajdonost.
3. Osztályozni kell az adatokat, felhasználókat, integrációkat és a működési kritikusságot.
4. Alkalmazni kell a biztonságos konfigurációs alapbeállításokat.
5. Felül kell vizsgálni a felhasználókat, adminisztrátorokat, vendégeket, szolgáltatásfiókokat és OAuth-hatóköröket.
6. Engedélyezni kell a naplózást, a riasztásokat és a megőrzést.
7. Nyomon kell követni a nyilvános megosztást és az adatkitettséget.
8. Össze kell kapcsolni a beszállítókat, szerződéseket, adatfeldolgozási szerződéseket és kilépési tervezést.
9. Meghatározott gyakorisággal bizonyítékokat kell gyűjteni.
10. A megállapításokat be kell vezetni a kockázatkezelésbe, a vezetőségi felülvizsgálatba és a fejlesztésbe.

Ez a modell szorosan illeszkedik az ISO/IEC 27002:2022 ISO/IEC 27002:2022 kontrolljaihoz, különösen az 5.9 információk és egyéb kapcsolódó eszközök nyilvántartása, az 5.15 hozzáférés-szabályozás, az 5.18 hozzáférési jogosultságok, az 5.19 információbiztonság a beszállítói kapcsolatokban, az 5.20 információbiztonság kezelése beszállítói megállapodásokban, az 5.21 információbiztonság kezelése az IKT-ellátási láncban, az 5.23 információbiztonság felhőszolgáltatások használata esetén, a 8.2 emelt jogosultságú hozzáférési jogosultságok, a 8.3 információhozzáférés korlátozása, a 8.9 konfigurációkezelés, a 8.15 naplózás, a 8.16 tevékenységek felügyelete és a 8.32 változáskezelés kontrollokhoz.

A Zenith Blueprint a Controls in Action szakaszban, a szervezeti kontrollok 23. lépésénél így fogalmaz:

A felhő már nem célállomás, hanem alapértelmezett működési modell. A tárolástól az együttműködésig, az infrastruktúrától a gépi tanulásig a szervezetek egyre inkább harmadik felek által biztosított, absztrahált, távolról menedzselt környezetek rétegeire épülnek. Az 5.23 kontroll ezt a valóságot ismeri el, és megköveteli, hogy az információbiztonságot kifejezetten kezeljék a felhőszolgáltatások kiválasztása, használata és kezelése során – nem utólagos szempontként, hanem már a kezdetektől tervezési alapelvként.

Ez az SSPM lényege. Nem csupán a hibás konfiguráció utólagos észleléséről szól. Arról szól, hogy a SaaS kiválasztása, bevezetése, működtetése, felügyelete és kivezetése az irányítási rendszer részévé váljon.

Ugyanez a Zenith Blueprint szakasz minden igazgatósági tag számára érthető nyelven magyarázza el a megosztott felelősség valóságát:

A felhőszolgáltatók védik az infrastruktúrát, de Ön továbbra is elszámoltatható az adataiért, konfigurációiért, hozzáférési szabályaiért és incidenskezelésre való felkészültségéért. Egy hibásan konfigurált tároló, egy nyilvánosan elérhető irányítópult vagy túlzott jogosultságok egy felhőalapú IAM-beállításban nem felhőhibák. Ezek irányítási hibák.

A szolgáltató üzemeltetheti a platformot, de a bérlői konfiguráció, az identitások, a hozzáférés-jóváhagyások, a kitett adatok, az integrációk, az incidenskezelési munkafolyamatok és a megfelelési bizonyítékok továbbra is az Ön felelősségi körébe tartoznak.

Az 5.23 kontroll a horgony, de az SSPM-hez kontrollcsalád kell

A Zenith Controls az ISO/IEC 27002:2022 5.23 kontrollját, a felhőszolgáltatások használatára vonatkozó információbiztonságot, megelőző kontrollként kategorizálja, amely a bizalmasságot, sértetlenséget és rendelkezésre állást támogatja. Kiberbiztonsági koncepciója a Protect, működési képessége a beszállítói kapcsolatok biztonságához kapcsolódik, területei pedig az irányítás, az ökoszisztéma és a védelem.

Ez azért fontos, mert az SSPM nem egyetlen kontroll. Keresztkontroll-szakterület.

A Zenith Controls az 5.23-at az 5.19 alatti beszállítói kapcsolatokhoz köti, mert a SaaS-szolgáltatók kritikus beszállítók, de az 5.23 SaaS-specifikus szempontokat is hozzáad, például a több-bérlős működést, az adathely átláthatóságát és a megosztott felelősséget. Az 5.23-at az információátadáshoz is kapcsolja, mert az API-k, integrációk és SaaS-ok közötti munkafolyamatok folyamatosan mozgatják az adatokat. Az eszköznyilvántartáshoz is kapcsolja, mert a szervezeteknek naprakész rálátásra van szükségük a felhőben tárolt adatokra és SaaS-erőforrásokra. Emellett a felhőirányítást összeköti a felügyelettel, a hozzáféréskorlátozással, a konfigurációkezeléssel és a beszállítói felügyelettel.

A hozzáférési jogosultságok esetében a Zenith Controls az 5.18-at az 5.15 hozzáférés-szabályozáshoz, az 5.16 identitáskezeléshez, az 5.3 feladatkörök szétválasztásához, az 5.36 információbiztonsági szabályzatoknak, szabályoknak és szabványoknak való megfeleléshez, valamint a 8.2 emelt jogosultságú hozzáférési jogosultságokhoz rendeli. Az SSPM-ben ez azt jelenti, hogy a hozzáférés-felülvizsgálat nem puszta táblázatkitöltés. Működési bizonyíték arra, hogy az identitáséletciklus, a legkisebb jogosultság elve, a feladatkörök szétválasztása és az emelt jogosultságok irányítása működik a SaaS-alkalmazásokban.

Szabályzati alap: előbb határozza meg a megfelelőt, csak utána vásároljon eszközt

Sok SaaS-hiba azért kezdődik, mert a szabályzati megfogalmazás homályos. Az, hogy „az engedélyezett eszközöket biztonságosan kell használni”, nem elég. A Clarysec szabályzatai konkrét elvárásokat határoznak meg a nyilvántartásra, a hozzáférésre, a naplózásra, a konfigurációra és a beszállítói felülvizsgálatra.

KKV-k számára a Cloud Usage Policy-sme Cloud Usage Policy - SME gyakorlati kiindulópontot ad. Az „Irányítási követelmények” szakasz 5.3 szabályzati pontja szerint:

Felhőszolgáltatási nyilvántartást kell fenntartania az IT-szolgáltatónak vagy az ügyvezetőnek. A nyilvántartásnak rögzítenie kell: 5.3.1 Minden jóváhagyott felhőszolgáltatás nevét és célját 5.3.2 A felelős személyt vagy csapatot (alkalmazásgazda) 5.3.3 A tárolt vagy kezelt adatok típusait 5.3.4 Az országot vagy régiót, ahol az adatokat tárolják 5.3.5 A felhasználói hozzáférési jogosultságokat és az adminisztratív fiókokat 5.3.6 A szerződéses adatokat, megújítási dátumokat és támogatási kapcsolattartókat

Ez a pont az SSPM működési magja. Az auditorok számára az első bizonyítékobjektumot adja: olyan nyilvántartást, amely a SaaS-használatot tulajdonosokhoz, adatokhoz, földrajzi helyhez, hozzáférésekhez és szerződésekhez kapcsolja.

Ugyanez a Cloud Usage Policy-sme „A szabályzat végrehajtásának követelményei” szakasz 6.2 szabályzati pontjában meghatározza az alapbeállításokat:

Biztonsági konfigurációs követelmények 6.2.1 Az alábbiakat minden felhőplatformon engedélyezni kell: 6.2.2 Többtényezős hitelesítés (MFA) az adminisztratív és felhasználói fiókokhoz 6.2.3 Jelszókomplexitási beállítások (legalább 10 karakter, újrafelhasználás nélkül) 6.2.4 Tevékenységnaplózás a bejelentkezési kísérletekhez és adathozzáféréshez 6.2.5 Hozzáférési korlátozások (pl. IP-engedélyezési lista, ahol támogatott) 6.2.6 Az adminisztratív hozzáférést névre szóló személyekre vagy engedélyezett támogatási szolgáltatókra kell korlátozni. 6.2.7 A nyilvánosan megosztott tartalmat rendszeresen felügyelni kell az adatszivárgás megelőzése érdekében. 6.2.8 Ha a felhasználói fiókokra már nincs szükség, a hozzáférést azonnal vissza kell vonni, és minden fennmaradó adatot felül kell vizsgálni, majd archiválni vagy törölni kell.

Vállalati környezetekben a Cloud Usage Policy Cloud Usage Policy erősebb központi irányítást rendel hozzá. Az „Irányítási követelmények” szakasz 5.3 szabályzati pontja szerint:

Minden felhőszolgáltatáshoz ki kell jelölni egy szolgáltatásgazdát, aki elszámoltatható az információs vagyonelem életciklus-kezeléséért, a használat irányításáért, a költségvetés nyomon követéséért és a folyamatos megfelelés-monitorozásért.

Ez a mondat lezár egy gyakori auditrést. Ha senki sem gazdája egy SaaS-szolgáltatásnak, akkor senki sem felel a konfigurációs sodródásért, a hozzáférések újratanúsításáért, az adatkitettségért, a megújítási döntésekért, az incidenskapcsolattartásért vagy a kilépési tervezésért.

Az emelt jogosultságok irányításának is egyértelműnek kell lennie. A User Account and Privilege Management Policy-sme User Account and Privilege Management Policy - SME „A szabályzat végrehajtásának követelményei” szakasz 6.4 szabályzati pontjában kimondja:

Hozzáférés-felülvizsgálatok és naplózás 6.4.1 Minden felhasználói fiókot és jogosultságot hathavonta felül kell vizsgálni. 6.4.2 A felülvizsgálatok során az informatikai vezetőnek ellenőriznie kell, hogy az egyes fiókok továbbra is aktívak, szükségesek és a megfelelő jogosultságokkal vannak-e ellátva. 6.4.3 A fióklétrehozás, fiókdeaktiválás és jogosultságmódosítás naplóit legalább 12 hónapig biztonságosan meg kell őrizni.

SaaS esetén minden kritikus platformhoz meghatározott hozzáférés-felülvizsgálati ciklus szükséges, még akkor is, ha a platformot üzleti csapat adminisztrálja, nem a központi IT.

A naplózásnak is kifejezettnek kell lennie. A Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME az „Irányítási követelmények” szakasz 5.5 szabályzati pontjában kimondja:

Felhőszolgáltatások és harmadik felek naplózása 5.5.1 Azokon a platformokon, ahol a naplózás nem áll közvetlen IT-kontroll alatt (pl. SaaS e-mail), az alábbi követelmények alkalmazandók: 5.5.1.1 A naplózást engedélyezni és konfigurálni kell, ahol elérhető 5.5.1.2 A riasztásokat az IT-támogatási szolgáltatóhoz kell irányítani 5.5.1.3 A szerződéseknek elő kell írniuk, hogy a szolgáltatók legalább 12 hónapig megőrizzék a naplókat, és kérésre hozzáférést biztosítsanak

Végül a SaaS-beszállítói irányítást dokumentálni kell. A Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME „A szabályzat végrehajtásának követelményei” szakasz 6.3 szabályzati pontjában kimondja:

A beszállítói biztonság folyamatos nyomon követése 6.3.1 A kritikus vagy magas kockázatú beszállítókat legalább évente felül kell vizsgálni. A felülvizsgálatnak ellenőriznie kell: 6.3.1.1 A biztonságos hozzáférési módszerek további használatát 6.3.1.2 Az érvényes biztonsági tanúsítványokat vagy frissített kontrollbizonyítékokat 6.3.1.3 Az incidenselőzményeket vagy bejelentett problémákat 6.3.1.4 A biztonsági záradékokkal kapcsolatos szerződéses megfelelést 6.3.2 Ezeket a felülvizsgálatokat dokumentálni kell, és a beszállító nyilvántartásával együtt meg kell őrizni. A követő intézkedéseket egyértelműen nyomon kell követni. 6.3.3 Ahol a beszállítók informatikai infrastruktúrát vagy alkalmazásokat kezelnek, a felügyelet magában foglalhatja: 6.3.3.1 Auditnaplók bekérését 6.3.3.2 Fióktevékenység felülvizsgálatát 6.3.3.3 Annak megerősítését, hogy nem történt jogosulatlan hozzáférés

Ezek a szabályzatok együtt az SSPM-et biztonsági törekvésből kikényszeríthető működési modellé alakítják.

30 napos SSPM-bizonyítéksprint

Egy gyakorlati CISO vagy megfelelési vezető 30 napos bizonyítéksprinttel kezdhet. Válassza ki azt az öt SaaS-platformot, amely a szabályozott adatok vagy kritikus működés szempontjából a legfontosabb. Tipikus jelöltek a Microsoft 365 vagy a Google Workspace, a CRM, a jegykezelés, a HRIS, a pénzügyi automatizáció, az ügyféltámogatás és az analitika.

1. hét: SaaS-nyilvántartás létrehozása

Használja a Cloud Usage Policy-sme 5.3 pontjának mezőit minimális nyilvántartásként. Minden SaaS-szolgáltatásnál rögzítse:

• A szolgáltatás nevét és üzleti célját
• Az alkalmazásgazdát és a technikai tulajdonost
• Az adattípusokat, beleértve a személyes adatokat és adott esetben a különleges kategóriájú adatokat
• Az adattárolás országát vagy régióját
• A felhasználói csoportokat és adminisztrátori fiókokat
• Az OAuth-alkalmazásokat és harmadik fél integrációkat
• A szerződésgazdát, a megújítási dátumot és a támogatási kapcsolattartót
• A működés szempontjából fennálló kritikusságot
• Az alkalmazandó kötelezettségeket, például NIS2, DORA, GDPR vagy ügyfélszerződések

Ez támogatja az ISO/IEC 27001:2022 4.2 és 4.3 pontjait, mert a szabályozási, szerződéses és harmadik fél függőségeknek alakítaniuk kell az IBIR alkalmazási területét. Támogatja továbbá a DORA Article 8 szerinti megközelítéshez hasonlóan az IKT által támogatott üzleti funkciók, információs vagyon, IKT-eszközök és függőségek azonosítását és osztályozását.

2. hét: Biztonságos konfigurációs alapbeállítások meghatározása

Minden kiválasztott SaaS-platformhoz határozzon meg 10–15 alapkontrollt.

• MFA kikényszerítése minden felhasználónál, ahol lehetséges, adathalászattal szemben ellenálló MFA az adminisztrátoroknál
• Külső megosztás alapértelmezetten letiltva vagy jóváhagyott domainekre korlátozva
• Nyilvános hivatkozások letiltva vagy időkorlátosak
• Vendégfiókok havi felülvizsgálata
• Adminisztrátori szerepkörök névre szóló személyekhez rendelve
• Örökölt hitelesítés letiltva
• OAuth-alkalmazás jóváhagyási munkafolyamat engedélyezve
• Magas kockázatú OAuth-hatókörök blokkolva vagy biztonsági jóváhagyáshoz kötve
• Auditnaplózás engedélyezve
• Adat-exportálási jogosultságok korlátozva
• Megőrzési beállítások jogi és üzleti követelményekhez igazítva
• API-tokenek felülvizsgálva és rotálva
• Biztonsági riasztások IT-hez vagy SOC-hoz irányítva
• Adatvesztés-megelőzési beállítások engedélyezve, ahol támogatott
• Vészhelyzeti hozzáférési fiókok dokumentálva és felügyelve

A Zenith Blueprint Controls in Action szakaszának 19. lépése, a 8.9 konfigurációkezelés kontroll, elmagyarázza, miért fontos ez:

Sok adatsértés nem szoftverhibából ered, hanem rossz konfigurációs döntésekből. Változatlanul hagyott alapértelmezett jelszavak, engedélyezett nem biztonságos szolgáltatások, szükségtelenül nyitott portok vagy indokolás nélkül internet felől elérhető rendszerek. A 8.9 kontroll biztosítja, hogy minden rendszer biztonságos konfigurációs alapbeállítás szerint épüljön fel, és rendszeresen felülvizsgálják a sodródás megelőzése érdekében.

SaaS esetén a konfigurációs sodródás magában foglalja, amikor egy üzleti tulajdonos engedélyezi a nyilvános megosztást, egy adminisztrátor széles körű harmadik fél hozzáférést hagy jóvá, vagy egy beszállító egy funkciókiadás után módosítja az alapértelmezett beállításokat.

3. hét: Hozzáférések és integrációk felülvizsgálata

Exportálja a felhasználókat, csoportokat, adminisztrátorokat és csatlakoztatott alkalmazásokat. Minden adminisztrátori fióknál erősítse meg a névre szóló személyt, az üzleti indoklást, az MFA-státuszt, az utolsó bejelentkezést, a jogosultsági szintet, a helyettesítési lefedettséget, a feladatkörök szétválasztásával kapcsolatos aggályokat és a jóváhagyási bizonyítékot.

Az OAuth-alkalmazások és integrációk esetében erősítse meg az alkalmazásgazdát, az elért adatokat, a kért jogosultságokat, a beszállítói kockázati státuszt, az utolsó használat dátumát, a fennálló szükségességet, valamint azt, hogy a hozzájárulást felhasználó adta-e meg vagy adminisztrátor hagyta jóvá.

A Zenith Blueprint Controls in Action szakaszának 19. lépése, a 8.3 információhozzáférés korlátozása kontroll, megadja a működési alapelvet:

Az információhoz való hozzáférésnek annyira nyitottnak kell lennie, amennyire szükséges, de annyira korlátozottnak, amennyire lehetséges.

Ez nemcsak személyekre, hanem alkalmazásokra, szolgáltatásokra és API-kra is vonatkozik. Egy inaktív OAuth-integráció jóval azután is megtarthatja a hozzáférést, hogy az azt létrehozó munkavállaló vagy projekt eltűnt.

4. hét: Auditra alkalmas bizonyítékok és kockázatkezelés előállítása

Minden SaaS-platformnál tárolja a nyilvántartási bejegyzést, a konfigurációs alapbeállítást, a kulcsbeállításokat igazoló képernyőképeket vagy exportokat, a hozzáférés-felülvizsgálat jóváhagyását, az adminisztrátori felülvizsgálat bizonyítékát, az OAuth-felülvizsgálat bizonyítékát, a naplózási és riasztási bizonyítékokat, a beszállítói biztonsági felülvizsgálat nyilvántartását, a nyitott megállapításokat és a kockázatkezelési intézkedéseket.

Ezután készítsen egyoldalas vezetői összefoglalót a kritikus megállapításokról, lejárt tulajdonosi feladatokról, megoldatlan magas kockázatú konfigurációs hiányosságokról, nem jóváhagyott integrációkról, naplózási hiányosságokról, kivételekről és a szükséges döntésekről. Ez támogatja az ISO/IEC 27001:2022 9.1 pont szerinti felügyeletet, a 9.2 pont szerinti belső auditot és a 9.3 pont szerinti vezetőségi felülvizsgálatot. Gyakorlati hidat teremt a NIS2 Article 20 szerinti vezetői elszámoltathatósághoz és a DORA szerinti vezető testületi felügyelethez is.

Keresztmegfelelési megfeleltetés: egy SSPM-bizonyítékcsomag, több kötelezettség

Az SSPM üzleti értéke nemcsak a jobb biztonság. Csökkenti a megfelelési duplikációt is.

A NIS2 Article 21 megfelelő és arányos technikai, működési és szervezeti intézkedéseket ír elő. A SaaS-nyilvántartás támogatja az eszközkezelést. A konfigurációs alapbeállítások támogatják a kiberhigiéniát. Az MFA és a hozzáférés-felülvizsgálatok támogatják a hozzáférés-szabályozást. A naplózás támogatja az incidenskezelést. A beszállítói felülvizsgálat támogatja az ellátásilánc-biztonságot. A bizonyítékszolgáltatási gyakoriság támogatja az eredményesség értékelésére szolgáló szabályzatokat és eljárásokat.

A DORA megköveteli a pénzügyi szervezetektől az IKT által támogatott funkciók, információs vagyon, IKT-eszközök és harmadik fél függőségek azonosítását és osztályozását. Védelmi és megelőző intézkedéseket, hozzáférés-szabályozásokat, erős hitelesítést, titkosítást, folytonosságot, tesztelést, incidenskezelést és IKT harmadik fél kockázatkezelést is előír. Egy SaaS SSPM-bizonyítékcsomag támogathatja a DORA-nyilvántartásokat, a függőségek feltérképezését, a szerződéses felügyeletet, az auditálási jogokat és a kilépési tervezést.

A GDPR megköveteli az adatkezelőktől, hogy igazolni tudják a sértetlenségnek, bizalmasságnak és elszámoltathatóságnak való megfelelést. A SaaS-nyilvántartások azonosítják, hol kezelnek személyes adatokat. A konfigurációs alapbeállítások csökkentik a jogosulatlan közzététel kockázatát. A hozzáférés-felülvizsgálatok támogatják a legkisebb jogosultság elvét. A naplózás támogatja az incidens kivizsgálását. A beszállítói nyilvántartások támogatják az adatfeldolgozói irányítást és az elszámoltathatóságot.

A NIST CSF 2.0 hasznos kommunikációs réteget ad hozzá. GOVERN funkciója megköveteli a jogi, szabályozási és szerződéses kiberbiztonsági követelmények megértését és kezelését. Ellátási lánccal kapcsolatos eredményei beszállítói szerepköröket, szerződéseket, kellő gondosságot, felügyeletet és a kapcsolat megszűnését követő tevékenységeket követelnek meg. IDENTIFY, PROTECT, DETECT, RESPOND és RECOVER funkciói természetesen megfeleltethetők a SaaS-nyilvántartásnak, a hozzáférés-szabályozásnak, az adatvédelemnek, a naplózásnak, az incidensreagálásnak és a helyreállításnak.

A COBIT 2019 és ISACA-orientált auditorok az SSPM-et jellemzően irányítás, menedzsmentcélok, kockázattulajdonosi felelősség, kontrollműködés és bizonyosság felől közelítik meg. Azt kérdezik majd, hogy a SaaS-döntések összhangban vannak-e a vállalati célkitűzésekkel, a kockázati válaszok dokumentáltak-e, a felelősségek ki vannak-e jelölve, és a bizonyossági tevékenységek igazolják-e a kontrollok működését.

Az audit nézőpontja: hogyan tesztelik a különböző auditorok a SaaS-helyzetet

Egy erős SSPM-program túléli a különböző auditstílusokat, mert megfelelő szintű bizonyítékot állít elő.

Egy ISO/IEC 27001:2022 auditor az alkalmazási területtel, az érdekelt felekkel, a kockázatértékeléssel, az alkalmazhatósági nyilatkozattal és a működési bizonyítékokkal kezdi. Ha az 5.23 kontroll szerepel, bizonyítékot vár a felhőszolgáltatások kiválasztására, használatára, kezelésére és kivezetésére. Ha a hozzáférési jogosultságokra vonatkozó kontrollok szerepelnek, mintát vesz a felhasználókból, és megkérdezi, hogy a belépési, áthelyezési és kilépési változások megjelennek-e a SaaS-jogosultságokban.

Egy DORA-felülvizsgáló a kritikus vagy fontos funkciókra, az IKT harmadik fél függőségekre, a nyilvántartás teljességére, a szerződésekre, az incidensbesorolásra, a tesztelésre és a kilépési tervezésre összpontosít. Ha egy SaaS-platform fizetési műveleteket, ügyfélbeléptetést, kereskedést, kockázati analitikát vagy ügyfélkommunikációt támogat, a bizonyítási elvárás magasabb.

Egy GDPR-auditor vagy adatvédelmi felülvizsgáló azt kérdezi, hol tárolják a személyes adatokat, ki férhet hozzájuk, milyen export- és megosztási beállítások léteznek, irányítottak-e az adatfeldolgozók, támogatják-e a naplók az incidenshatás-vizsgálatot, és a kontrollok arányosak-e a kockázattal.

Beszállítói kockázat, megosztott felelősség és incidenskezelésre való felkészültség

Az SSPM gyakran konfigurációval indul, de nem állhat meg ott. A SaaS beszállítói kockázati és incidenskezelésre való felkészültségi kérdés is.

A DORA előírja a pénzügyi szervezeteknek az IKT-szolgáltatási szerződések nyilvántartásainak fenntartását, a kritikus vagy fontos funkciókat támogató megállapodások megkülönböztetését, a koncentrációs kockázat értékelését, a szolgáltatói alkalmasság vizsgálatát és a kilépési stratégiák fenntartását. A szerződéseknek ki kell térniük a szolgáltatásleírásokra, az adathelyre, a rendelkezésre állás, hitelesség, sértetlenség és bizalmasság védelmére, az adathozzáférésre, helyreállításra és visszaszolgáltatásra, incidenssegítségre, hatóságokkal való együttműködésre, felmondási jogokra, biztonsági követelményekre, auditálási jogokra és átállási támogatásra.

A NIS2 Article 21 az ellátásilánc-biztonságot is magában foglalja, és megköveteli, hogy az érintett szervezetek figyelembe vegyék a közvetlen beszállítókra és szolgáltatókra jellemző sérülékenységeket, a termékek minőségét és a beszállítói kiberbiztonsági gyakorlatokat.

A gyakorlatban egy kritikus SaaS-felülvizsgálatnak egyesítenie kell a biztonsági kérdőíves bizonyítékokat, a szerződésfelülvizsgálatot, az adatfeldolgozási szerződés státuszát, az incidenselőzményeket, a szolgáltatási szintvállalásokat, a naplóhozzáférést, az auditjelentéseket, a konfigurációs bizonyítékokat és a kilépés megvalósíthatóságát.

A megosztott felelősségi rés akkor jelenik meg, amikor a csapatok azt feltételezik, hogy a beszállító tanúsítása lefedi a bérlői konfigurációt. Nem fedi le. Egy beszállító üzemeltethet biztonságos platformot, miközben az ügyfél engedélyezi a nyilvános megosztást, aktívan hagy inaktív adminisztrátori fiókokat, vagy túlzott API-hatóköröket ad. Az SSPM ezt a rést zárja le.

Az incidenskezelésre való felkészültség ugyanilyen fontos. A NIS2 jelentős incidensek bejelentésére vonatkozó rendszere 24 órán belüli korai figyelmeztetést, 72 órán belüli bejelentést és a 72 órás bejelentést követően legkésőbb egy hónapon belüli zárójelentést foglal magában. A DORA IKT-val kapcsolatos incidenskezelést ír elő észleléssel, rögzítéssel, besorolással, eszkalációval, kommunikációval és bejelentéssel. A GDPR szerinti személyesadat-sértés értékelése is attól függ, hogy időben megértjük-e, mi történt, milyen adatok érintettek és kikre volt hatással.

Ha egy gyanús OAuth-alkalmazás ügyfélfájlokhoz fért hozzá, tudni kell, mikor engedélyezték az alkalmazást, melyik felhasználó engedélyezte, milyen hatóköröket kapott, milyen adatokhoz fért hozzá, történt-e letöltés vagy megosztás, mely felhasználók vagy ügyfelek érintettek, aktív maradt-e a hozzáférés, és milyen elszigetelési intézkedések történtek.

Naplózás és megőrzés nélkül a szervezet kényszerülhet a legrosszabb eset feltételezésére. Ez növeli a jogi kitettséget, az ügyfélkommunikációs nyomást és a szabályozási bizonytalanságot. Ha egy SaaS-szolgáltató külön díjat számít fel az auditnaplókért, a kockázatgazdának kifejezetten el kell fogadnia a maradványkockázatot, vagy jóvá kell hagynia a szükséges licenccsomagot. Ennek a döntésnek a kockázatkezelési nyilvántartásban és a vezetőségi felülvizsgálatban kell szerepelnie.

Gyakori SSPM-hibaminták

Ugyanazok a hibaminták jelennek meg az ágazatok között.

Először: az árnyék-SaaS-t számlákból, böngészési előzményekből vagy SSO-naplókból fedezik fel, nem a beszerzésen keresztül. A megoldás nem csak az eszközök blokkolása. Könnyen használható igénybejelentési folyamat kell, amelyet az üzleti csapatok is tudnak használni.

Másodszor: a SaaS tulajdonosi felelőssége nem egyértelmű. A CRM „az értékesítésé”, de az értékesítésben senki sem tudja elmagyarázni az adminisztrátori szerepköröket, API-tokeneket, adatexportokat vagy megőrzési beállításokat. Az alkalmazásgazdákat és a technikai tulajdonosokat külön kell kijelölni.

Harmadszor: a hozzáférés-felülvizsgálatok túl általánosak. A felülvizsgáló aláírja, hogy „minden felhasználó jóváhagyva”, anélkül hogy ellenőrizné a magas kockázatú szerepköröket, inaktív felhasználókat, vendégeket, külső együttműködőket vagy szolgáltatásfiókokat. Az SSPM hozzáférés-felülvizsgálatnak kockázati rangsoroláson kell alapulnia.

Negyedszer: az OAuth-alkalmazásokat figyelmen kívül hagyják. Sok szervezet felülvizsgálja az emberi felhasználókat, de az alkalmazások közötti jogosultságokat nem. Modern SaaS-környezetben az integrációk erősebbek lehetnek a felhasználóknál.

Ötödször: a konfigurációs alapbeállítások csak a tanúsítási projektből származó képernyőképekként léteznek. Nem felügyelik őket sodródás szempontjából. Az SSPM-et össze kell hangolni a konfigurációkezeléssel, hogy az alapbeállítás-ellenőrzések ismétlődő bizonyítékká váljanak.

Hatodszor: a beszállítói felülvizsgálat és a SaaS-helyzet felülvizsgálata elkülönül. A beszerzésnél van a szerződés, az IT-nál az adminisztrációs konzol, az adatvédelemnél az adatfeldolgozási szerződés, a biztonságnál a kockázati nyilvántartás. Az auditor töredékeket lát. Az SSPM ezeket összekapcsolja.

Vezetői jelentéstétel: tegye láthatóvá a SaaS-kockázatot az igazgatóság számára

A NIS2 és a DORA egyaránt vezetői kérdéssé teszi az IKT- és kiberbiztonsági irányítást. Az ISO/IEC 27001:2022 szintén megköveteli a vezetői szerepvállalást, az erőforrásokat, a szerepkör-hozzárendelést, a felügyeletet és a vezetőségi felülvizsgálatot.

Egy hatékony SSPM vezetői jelentésnek meg kell válaszolnia:

• Mely kritikus SaaS-szolgáltatások tartoznak a hatályba?
• Mely szabályozott folyamatok függnek tőlük?
• Melyek tartalmaznak személyes adatokat vagy érzékeny üzleti adatokat?
• Melyeknél lejártak a hozzáférés-felülvizsgálatok?
• Melyeknél vannak megoldatlan magas kockázatú konfigurációs hiányosságok?
• Melyeknél vannak nem jóváhagyott OAuth-alkalmazások vagy integrációk?
• Mely beszállítóknál hiányzik a naprakész biztonsági bizonyíték?
• Mely naplózási hiányosságok érintik az incidensjelentést?
• Mely kivételek igényelnek kockázatelfogadást?
• Milyen beruházásokra vagy döntésekre van szükség?

Ez az SSPM-et technikai rendbetételi projektből irányítási bemenetté alakítja. A CISO-t is hatékonyabbá teszi, mert a kockázatelfogadás a megfelelő szintre kerül.

Alakítsa a SaaS-helyzetet auditra alkalmas bizonyítékká

Ha szervezete SaaS-ra támaszkodik szabályozott adatok, pénzügyi műveletek, ügyféltámogatás, HR, együttműködés, fejlesztés vagy analitika területén, az SSPM már nem opcionális. A kiberhigiénia, az IKT-kockázatkezelés, az adatvédelmi elszámoltathatóság és az auditfelkészültség része.

A Clarysec segíthet abban, hogy a szétszórt SaaS-megállapításokból strukturált, bizonyítékalapú programot építsen az alábbiak használatával:

• Zenith Blueprint: Az auditor 30 lépéses ütemterve Zenith Blueprint, amely segít strukturálni a megvalósítást a felhőhasználat, hozzáféréskorlátozás és konfigurációkezelés területén.
• Zenith Controls: A keresztmegfelelési útmutató Zenith Controls, amely az ISO/IEC 27002:2022 kontrollokat megfelelteti a NIS2, DORA, GDPR, NIST CSF 2.0 és audit elvárásainak.
• Clarysec szabályzatsablonok, például Cloud Usage Policy Cloud Usage Policy, Cloud Usage Policy-sme Cloud Usage Policy - SME, User Account and Privilege Management Policy-sme User Account and Privilege Management Policy - SME, Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME és Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, amelyekkel kikényszeríthető működési szabályok hozhatók létre.

Kezdje az öt legmagasabb kockázatú SaaS-platformmal. Jelöljön ki tulajdonosokat. Rögzítse az adatokat, a hozzáféréseket, a konfigurációt, az integrációkat, a naplókat és a beszállítói bizonyítékokat. Alakítsa a megállapításokat kockázatkezelési intézkedésekké és vezetői döntésekké.

Így válik a SaaS biztonsági állapotkezelés többé, mint eszközkategória. Igazolható megfelelési szakterületté válik 2026-ra.

Töltse le a Clarysec szabályzatsablonjait, használja a Zenith Blueprint-et a 30 napos SSPM-bizonyítéksprint megtervezéséhez, és térképezze fel SaaS-kontrolljait a Zenith Controls segítségével, mielőtt a következő audit találja meg Ön helyett a hiányosságokat.