Felhőszolgáltatások megosztott felelősségi mátrixa ISO, NIS2 és DORA megfeleléshez

Egy fintech operatív igazgató hétfőn 07:15-kor felhívja az információbiztonsági vezetőt.

Egy európai banki ügyfél bizonyítékot kér arra, hogy a vállalat SaaS platformja képes megfelelni a DORA IKT harmadik fél kockázati követelményeinek. Az értékesítési csapat már elküldte a szokásos beszállítói biztonsági csomagot: ISO-tanúsítványt, a penetrációs teszt vezetői összefoglalóját, kiberbiztosítási igazolást, adatvédelmi tájékoztatót és a felhőszolgáltató bizonyossági jelentését.

A bank ennél pontosabb kérdéssel tér vissza:

„Mutassák be, hogy a felhőkörnyezetükben ki felel az egyes kontrollokért. Önök, a felhőszolgáltatójuk, a menedzselt adatbázis-szolgáltatójuk, az identitásszolgáltatójuk, a naplózási beszállítójuk és minden további adatfeldolgozó. Ezután mutassák be a bizonyítékokat is.”

Később aznap délelőtt az információbiztonsági vezetőnek igazgatósági ülése van. A vezérigazgató ugyanezt üzleti nyelven fogja megkérdezni: „Biztosak vagyunk abban, hogy ez a platform biztonságos, és ki a felelős, ha valami elromlik?”

Itt akad el sok felhőmegfelelési program.

A szervezetnek lehet erős felhőszolgáltatója, jó eszközkészlete, megfelelő szabályzatai és kockázati nyilvántartása. Amikor azonban a felelősségi határok igazolását kérik, a bizonyítékok szétszórtan találhatók. A beszerzésnél vannak a szerződések. A jogi területnél van az adatfeldolgozási szerződés (DPA). A mérnöki csapatnál vannak az architektúraábrák. A biztonsági csapatnál vannak a naplók és a felhőkonfigurációk. Az adatvédelmi területnél van a további adatfeldolgozók listája. A megfelelőségi területnél van az alkalmazhatósági nyilatkozat. Senkinél nincs egyetlen szabályozott dokumentum, amely kontrollonként rögzíti, mit végez a szolgáltató, mit kell az ügyfélnek konfigurálnia, melyik további adatfeldolgozó érintett, melyik záradék teszi kikényszeríthetővé a kötelezettséget, és milyen bizonyítékot várhat el az auditor.

Ez a dokumentum a felhőszolgáltatási megosztott felelősségi mátrix.

Nem az az általános hiperskálázó felhőszolgáltatói dia, amely szerint a szolgáltató biztosítja a felhőt, az ügyfél pedig azt, ami a felhőben van. Egy valódi, ISO/IEC 27001:2022, NIS2, DORA és GDPR szerinti felhőszolgáltatási megosztott felelősségi mátrix irányítási nyilvántartás. Kiállja az ügyféloldali átvilágítást, az ISO-auditot, a DORA-felülvizsgálatot, a GDPR szerinti elszámoltathatósági vizsgálatot és az incidensvizsgálatot.

Miért válik auditproblémává a felhőszolgáltatási megosztott felelősség?

A megosztott felelősségi modellt általában technikai határvonalként tanítják. IaaS esetén a szolgáltató kezeli a fizikai létesítményeket, a hardvert, a virtualizációt és az alapinfrastruktúrát. Az ügyfél kezeli az identitásokat, az adatokat, a munkaterheléseket, a hálózati szabályokat, a titkosítási döntéseket és a konfigurációkat. SaaS esetén a szolgáltató több operatív felelősséget vállal, de a felhasználói hozzáférés, az adatok irányítása, a jogalap, a konfiguráció, a monitorozási elvárások és az incidenseszkaláció továbbra is az ügyfél felelőssége.

Ez a magyarázat hasznos, de nem teljes.

Az auditorok, szabályozó hatóságok és nagyvállalati ügyfelek nemcsak azt kérdezik, hogy „ki működteti a kontrollt?”. Azt akarják tudni:

• Ki elszámoltatható a kockázatért?
• Melyik szerződéses záradék teszi kikényszeríthetővé ezt az elszámoltathatóságot?
• Melyik szabályzat írja elő a kontrollt?
• Melyik felhőszolgáltatás, SaaS platform vagy további adatfeldolgozó tartozik a hatályba?
• Melyik bizonyíték igazolja, hogy a kontroll működött a felülvizsgálati időszakban?
• Melyik keretrendszer-követelménynek felel meg a bizonyíték?
• Mi történik, ha a szolgáltató módosítja a szolgáltatását, helyszínét, alvállalkozóját vagy kontrollkörnyezetét?

Az ISO/IEC 27001:2022 ISO/IEC 27001:2022 ezt irányítási rendszer kérdésévé teszi. A 4.1–4.4 pontok előírják, hogy a szervezet értse a belső és külső tényezőket, az érdekelt feleket, a jogi és szerződéses kötelezettségeket, az IBIR alkalmazási területét, valamint az interfészeket és függőségeket. A 6.1.1–6.1.3 pontok kockázatértékelést, kockázatkezelést, a kockázatgazdai jóváhagyást, a maradványkockázat elfogadását és alkalmazhatósági nyilatkozatot írnak elő. A 8.1 pont működéstervezést és -szabályozást követel meg, ideértve az IBIR szempontjából releváns, külső fél által biztosított folyamatok, termékek és szolgáltatások szabályozását.

Egyszerűen fogalmazva: ha egy felhőszolgáltató, SaaS-beszállító vagy további adatfeldolgozó hatályba tartozó üzleti folyamatot támogat, nem maradhat az IBIR-en kívül. Láthatónak kell lennie az alkalmazási területben, a kockázatokban, a kockázatkezelésben, a szerződéses kontrollokban és a bizonyítékokban.

A NIS2 emeli a tétet. Az Article 21 előírja, hogy az alapvető és fontos szervezetek megfelelő és arányos technikai, operatív és szervezeti intézkedéseket vezessenek be, ideértve a kockázatelemzést, az incidenskezelést, a folytonosságot, az ellátási lánc biztonságát, a biztonságos beszerzést, a biztonságos fejlesztést, a sérülékenységek kezelését, az eredményesség értékelését, 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 adott esetben a többtényezős hitelesítést vagy a folyamatos hitelesítést. Az Article 20 az irányítási felelősséget a vezető testületekre telepíti.

A DORA a pénzügyi szervezetek esetében még egyértelműbb. 2025. január 17-től alkalmazandó, és előírja, hogy a pénzügyi szervezetek kezeljék az IKT-kockázatot, a súlyos IKT-vonatkozású incidensek jelentését, a digitális működési reziliencia tesztelését és az IKT harmadik fél kockázatot. Az Article 28–30 előírja az IKT harmadik fél kockázatkezelést, az előzetes koncentrációs kockázatértékelést, a szerződéses védelmi intézkedéseket, az auditálási és hozzáférési jogokat, az alvállalkozói lánc átláthatóságát, a felmondási jogokat és a kilépési stratégiákat.

A GDPR hozzáadja az elszámoltathatósági tesztet. Az Article 5 előírja, hogy a személyes adatok kezelése sértetlenség és bizalmasság mellett történjen, az Article 5(2) pedig előírja, hogy az adatkezelőnek képesnek kell lennie a megfelelés igazolására. Az Article 28 az adatfeldolgozói szerződéseket és a további adatfeldolgozókat szabályozza. Az Article 32 az adatkezelés biztonságát írja elő. Az Article 33 és 34 adott esetben személyesadat-sértés bejelentését követeli meg.

A felhőszolgáltatási megosztott felelősségi mátrix hidat képez e kötelezettségek között.

A Clarysec definíciója: irányítási dokumentum, nem diagram

A Clarysec megbízásaiban a felhőszolgáltatási megosztott felelősségi mátrix olyan szabályozott IBIR-nyilvántartás, amely összekapcsolja a felhőszolgáltatásokat, beszállítókat, további adatfeldolgozókat, kontrollokat, szabályzatokat, szerződéses kötelezettségeket, bizonyítékokat és auditelvárásokat.

A legerősebb magyarázat a Zenith Blueprint Zenith Blueprint Controls in Action szakaszának 23. lépésében található:

„A felhőszolgáltatók biztosítják az infrastruktúrát, de az adataiért, konfigurációiért, hozzáférési szabályzataiért és incidensreagálási felkészültségéért továbbra is Ön elszámoltatható.”

Ugyanez a lépés kifejti, hogy a felhőhasználatot az IBIR részeként kell kezelni, beleértve a felhőszolgáltatások osztályozását, a kezelt vagy tárolt adatok megértését, a szolgáltató értékelését, a szerződéses záradékokat és a szolgáltatásváltozások kezelését. Ez a megosztott felelősséget fogalomból visszakövethető kontrollstruktúrává alakítja.

A Zenith Controls Zenith Controls az ISO/IEC 27001:2022 Annex A kontrollokat és az ISO/IEC 27002:2022 5.20, 5.21 és 5.23 útmutatásait központi hivatkozási pontként kezeli:

• 5.20, Információbiztonság a beszállítói megállapodásokban.
• 5.21, Információbiztonság kezelése az IKT ellátási láncban.
• 5.23, Információbiztonság felhőszolgáltatások használata esetén.

Ezek nem elszigetelt ellenőrzőlista-elemek. Ezek adják a mátrix gerincét.

A támogató szabványok erősíthetik a mátrixot. Az ISO/IEC 27017 a felhőspecifikus biztonsági gyakorlatokban segít. Az ISO/IEC 27018 és az ISO/IEC 27701 a PII és az adatvédelmi irányítás támogatására szolgál. Az ISO/IEC 27005 a kockázatértékelést támogatja. Az ISO 22301 a folytonosságot és a rezilienciát támogatja. Az ISO/IEC 27035 az incidenskezelést támogatja. Az ISO/IEC 20000-1 ott lehet hasznos, ahol a felhőszolgáltatások a menedzselt szolgáltatásnyújtás részét képezik.

A minimálisan működőképes megosztott felelősségi mátrix

Egy érett mátrix nem 200 sorral indul. Azokkal a felhőszolgáltatásokkal indul, amelyek a legfontosabbak.

SaaS, fintech vagy szabályozott KKV esetén a Clarysec általában ezekkel kezdi:

1. Ügyféloldali éles felhőkörnyezet.
2. Identitásszolgáltató.
3. Menedzselt adatbázis- vagy tárolási szolgáltatás.
4. Naplózási, monitorozási és SIEM-platform.
5. Fizetési, KYC-, analitikai vagy ügyféltámogatási SaaS.
6. Biztonsági mentési és katasztrófa utáni helyreállítási szolgáltatás.
7. Menedzselt szolgáltató vagy menedzselt biztonsági szolgáltató.
8. Olyan további adatfeldolgozók, amelyek hozzáférnek az ügyféladatokhoz, tárolják vagy kezelik azokat.

Az első mátrixnak a következő oszlopokat kell tartalmaznia.

Egy gyakorlati naplózási sor például így nézhet ki.

Ez a sor nem puszta dokumentáció. Megmondja a biztonsági csapatnak, mit kell konfigurálnia, a beszerzésnek, milyen szerződéses nyelvezetet kell ellenőriznie, az adatvédelmi területnek, milyen adatáramlást kell rögzítenie, az auditoroknak pedig, milyen bizonyítékot kérjenek.

Szabályzati alap: a mátrix kikényszeríthető követelménnyé alakítása

Szabályzati háttér nélkül a felhőszolgáltatási megosztott felelősségi mátrix csak egy táblázat. A Clarysec szabályzatai kikényszeríthetővé teszik.

KKV-k esetében a Felhőszolgáltatások használatára vonatkozó szabályzat - KKV Felhőszolgáltatások használatára vonatkozó szabályzat - KKV „Irányítási követelmények” szakaszának 5.3 pontja előírja:

„Az IT-szolgáltatónak vagy az ügyvezetőnek Felhőszolgáltatási Nyilvántartást kell fenntartania. Ennek rögzítenie kell:”

Ugyanezen KKV-szabályzat 5.2.3 pontja a felhőirányítást az adatvédelmi és helyszínkockázathoz köti:

„Az adatok földrajzi helye és az adatvédelmi gyakorlatok megfelelnek az alkalmazandó jogi követelményeknek (pl. GDPR)”

Nagyvállalati környezetekben a Felhőszolgáltatások használatára vonatkozó szabályzat Felhőszolgáltatások használatára vonatkozó szabályzat „Irányítási követelmények” szakaszának 5.1 pontja kimondja:

„A szervezetnek központi Felhőszolgáltatási Nyilvántartást kell fenntartania, amelynek tulajdonosa az információbiztonsági vezető, és amely tartalmazza:”

Az 5.4 pont ezután szerződésesen kikényszeríthetővé teszi a felhővel kapcsolatos felelősségeket:

„Minden CSP-vel (Cloud Service Provider) kötött szerződésnek kikényszeríthető rendelkezéseket kell tartalmaznia az alábbiakra:”

A beszállítói irányítás kiterjeszti a mátrixot a közvetlen szolgáltatón túlra. A Harmadik fél és beszállítói biztonsági szabályzat - KKV Harmadik fél és beszállítói biztonsági szabályzat - KKV „Irányítási követelmények” szakaszának 5.3.5 pontja előírja:

„A további alvállalkozásba adás korlátozása jóváhagyás nélkül”

Ugyanezen KKV beszállítói szabályzat „A szabályzat végrehajtásának követelményei” szakaszának 6.3.1 pontja időszakos felülvizsgálatot ír elő:

„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:”

Nagyvállalati szinten a Harmadik fél és beszállítói biztonsági szabályzat Harmadik fél és beszállítói biztonsági szabályzat „Irányítási követelmények” szakaszának 5.3 pontja kimondja:

„A beszállítókkal kötött szerződéseknek tartalmazniuk kell:”

Személyes adatok esetén az Adatvédelmi és magánszféra-védelmi szabályzat Adatvédelmi és magánszféra-védelmi szabályzat „Betartatás és megfelelés” szakaszának 8.5.1 pontja előírja:

„Az adatfeldolgozókkal kötött szerződéseknek tartalmazniuk kell:”

A függőségek átláthatóságához a Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat 6.5.4 pontja előírja:

„A beszállítói kapcsolat felhasználása az alvállalkozókról vagy az ellátási lánc eggyel lejjebb található függőségeiről szóló frissítések beszerzésére, ahol ezek hatással lehetnek ránk (például ha egy kritikus szoftverbeszállító nagymértékben támaszkodik egy harmadik féltől származó könyvtárra, ezt rögzíteni kell).”

Naplók esetén a Naplózási és felügyeleti szabályzat - KKV Naplózási és felügyeleti szabályzat - KKV „Irányítási követelmények” szakaszának 5.5.1.3 pontja konkrét szerződéses követelményt ad:

„A szerződéseknek elő kell írniuk, hogy a szolgáltatók legalább 12 hónapig őrizzék meg a naplókat, és kérésre biztosítsanak hozzáférést”

Ezek a szabályzatok együtt a mátrixot kötelező irányítási nyilvántartássá teszik, amely támogatja a beszállítói jóváhagyást, a felhőszolgáltatások beléptetését, az adatvédelmi elszámoltathatóságot, az éves felülvizsgálatot és az auditbizonyítékokat.

A mátrix leképezése ISO/IEC 27001:2022, NIS2, DORA és GDPR szerint

A klasszikus hiba négy külön megfelelési munkafüzet létrehozása. Egy kontroll több kötelezettséget is teljesíthet, ha a felelősség és a bizonyíték visszakövethető.

Az ISO/IEC 27001:2022 biztosítja az IBIR motorját: kontextus, érdekelt felek, alkalmazási terület, vezetés, kockázatkezelés, célkitűzések, működési kontroll, teljesítményértékelés és fejlesztés. Az Annex A adja a gyakorlati kontrollstruktúrát.

A NIS2 Article 21 természetesen illeszkedik ugyanahhoz a mátrixhoz az ellátási lánc biztonságán, incidenskezelésen, folytonosságon, hozzáférés-szabályozáson, eszközkezelésen és biztonságos beszerzésen keresztül. Az Article 20 igazgatósági szinten relevánssá teszi a mátrixot, mert a vezető testületeknek jóvá kell hagyniuk és felügyelniük kell a kiberbiztonsági kockázatkezelési intézkedéseket.

A DORA a mátrixot IKT harmadik fél kockázati eszközzé alakítja. Az Article 5, 6 és 8 irányítást, dokumentált IKT-kockázatkezelést, valamint eszközök, funkciók és függőségek azonosítását írja elő. Az Article 17–19 incidensészlelést, osztályozást, eszkalációt, kommunikációt és jelentéstételt ír elő. Az Article 28–30 harmadik fél kockázatkezelést, koncentrációs kockázatelemzést, szerződéses záradékokat, alvállalkozói kontrollokat, auditálási jogot, felmondási jogokat és kilépési stratégiákat ír elő.

A GDPR a személyes adatok nézőpontját adja hozzá. Minden felhőszolgáltatási sornak azonosítania kell, hogy történik-e személyesadat-kezelés, a szolgáltató adatfeldolgozó vagy további adatfeldolgozó-e, számít-e az adat helye, és milyen szerződéses vagy DPA-bizonyíték áll rendelkezésre.

A NIST CSF 2.0 segít ugyanazt a mátrixot eredményalapú nyelven kommunikálni. A GOVERN funkció a szervezeti kontextust, jogi és szabályozási követelményeket, függőségeket, kockázatkezelést, szerepköröket, szabályzatokat és felügyeletet kezeli. A GV.SC eredmények különösen hasznosak a beszállítói kiberkockázat szempontjából, ideértve a beszállítói szerepköröket, kritikusságot, szerződéses követelményeket, kellő gondosságot, monitorozást, incidenskoordinációt és megszüntetési tervezést.

A COBIT 2019 bizonyossági és irányítási nézőpontot ad. Azt vizsgálja, hogy az elszámoltathatóság, az irányítási gyakorlatok, a tulajdonosi felelősség, a monitorozás és a problémák helyesbítése megismételhető-e és bizonyítékokkal alátámasztott-e.

A mátrix felépítése a nyilvántartástól a bizonyítékig

Képzeljünk el egy SaaS-vállalatot, amely hiperskálázó IaaS-platformot, menedzselt adatbázist, harmadik fél identitásszolgáltatót, ügyféltámogatási SaaS-platformot és külső SIEM-et használ. A bevezetési folyamat egyértelmű.

1. lépés: Induljon a Felhőszolgáltatási Nyilvántartásból

Kiindulási pontként használja a Felhőszolgáltatások használatára vonatkozó szabályzatot vagy a Felhőszolgáltatások használatára vonatkozó szabályzat - KKV szabályzatot. Rögzítsen minden felhőszolgáltatást, tulajdonost, célt, adatkategóriát, helyszínt, üzleti funkciót, beszállítói szintet, szerződéstulajdonost és felülvizsgálati dátumot.

Ha a szolgáltatás ügyfél-nyilvántartásokat, hitelesítési naplókat vagy támogatási jegyeket tárol, jelölje adatvédelmi szempontból relevánsnak. Ha az éles rendelkezésre állást támogatja, jelölje működéskritikusnak. Ha pénzügyi ügyfél kritikus vagy fontos funkcióját támogatja, jelölje DORA szempontból relevánsnak.

2. lépés: Adja hozzá a megosztott felelősségi területeket

Minden szolgáltatásnál határozza meg a felelősségeket a fő területeken.

3. lépés: Kapcsolja a kontrollokat a kockázathoz és az alkalmazhatósági nyilatkozathoz

A Zenith Blueprint kockázatkezelési szakaszának 13. lépése így magyarázza a visszakövethetőségi követelményt:

„Kereszthivatkozás a jogszabályokra: Ha bizonyos kontrollokat kifejezetten a GDPR, NIS2 vagy DORA megfelelés érdekében vezettek be, ezt rögzítheti akár a kockázati nyilvántartásban (a kockázati hatás indoklásának részeként), akár az SoA megjegyzéseiben.”

Például az „ügyfél éles adatainak jogosulatlan hozzáférése felhőhibás konfiguráció miatt” kockázat kapcsolódhat a hozzáférés-szabályozáshoz, felhőhasználathoz, naplózáshoz, kriptográfiához, sérülékenységkezeléshez és beszállítói megállapodásokhoz. Az SoA hivatkozhat az ISO/IEC 27001:2022 Annex A 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 és 8.24 kontrollokra, kiegészítő megjegyzésekkel a GDPR Article 32, a NIS2 Article 21 és adott esetben a DORA IKT-kockázatkezelés tekintetében.

4. lépés: Csatolja a bizonyítékokat még az auditszezon előtt

A bizonyítékokat a mátrixba kell tervezni, nem pánikszerűen összegyűjteni.

A bizonyítéklista a felelősséget igazolássá alakítja. Az üzleti csapatoknak is segít gyorsabban válaszolni a nagyvállalati átvilágításokra, mert nemcsak tanúsítványokat, hanem kontrolltulajdonlást és működési bizonyítékokat is be tudnak mutatni.

További adatfeldolgozók: a legtöbb mátrix vakfoltja

A további adatfeldolgozóknál válik a megosztott felelősség valódi ellátási lánc kockázattá.

Egy SaaS-szolgáltató a GDPR szerint az Ön adatfeldolgozója lehet. Ez a szolgáltató támaszkodhat felhő tárhelyszolgáltatóra, CDN-re, analitikai szolgáltatásra, támogatási platformra, e-mail kézbesítési szolgáltatásra, menedzselt adatbázisra, megfigyelhetőségi szolgáltatóra és fizetési szolgáltatóra. Egyesek hozzáférhetnek személyes adatokhoz. Mások kritikus szolgáltatásnyújtást támogathatnak anélkül, hogy közvetlenül látnák az adatokat. Egyesek az EU-n kívül lehetnek. Egyesek helyettesíthetők. Mások koncentrációs kockázatot hozhatnak létre.

A DORA Article 29 koncentrációs kockázatértékelést ír elő a kritikus vagy fontos IKT-szolgáltatásokra, ideértve a helyettesíthetőséget, az ugyanazon vagy kapcsolt szolgáltatókkal fennálló többes megállapodásokat, az alvállalkozói láncokat, a harmadik országbeli alvállalkozókat, a fizetésképtelenségi jogot, az adat-helyreállítási korlátokat és az uniós adatvédelmi kikényszeríthetőséget. A DORA Article 30 szerződéses rendelkezéseket ír elő az alvállalkozásba adási feltételekre, helyszínekre, adatkezelésre és tárolásra, hozzáférésre és helyreállításra, incidenshez nyújtott segítségre, hatóságokkal való együttműködésre, auditálási jogokra, megszüntetésre és kilépésre.

A NIS2 Article 21 hasonlóképpen ellátási lánc biztonságot ír elő a közvetlen beszállítókra és szolgáltatókra, továbbá a beszállítóspecifikus sérülékenységek, a beszállítói kiberbiztonsági gyakorlatok és a biztonságos fejlesztési eljárások figyelembevételét.

Ezért a Clarysec a további adatfeldolgozók leképezését a beszállítói irányítás kötelező kiterjesztéseként kezeli, nem pusztán adatvédelmi listaként. A további adatfeldolgozói nyilvántartásnak meg kell mutatnia, mely beszállító használja a további adatfeldolgozót, mely szolgáltatás függ tőle, történik-e személyesadat-kezelés, támogat-e kritikus funkciót, adott esetben melyik adatkezelési régió érintett, milyen szerződéses továbbadott követelmények vannak, milyen jóváhagyási vagy tiltakozási jogok állnak fenn, milyen bizonyosság érhető el, mi a monitorozási módszer és milyen kilépési lehetőség van.

A Zenith Blueprint Controls in Action szakaszának 23. lépése kimondja:

„Minden kritikus beszállító esetében azonosítsa, használ-e olyan alvállalkozókat (al-adatfeldolgozókat), amelyek hozzáférhetnek az Ön adataihoz vagy rendszereihez. Dokumentálja, hogyan kerülnek továbbadásra az Ön információbiztonsági követelményei ezekre a felekre, akár a beszállító szerződéses feltételein, akár az Ön saját közvetlen záradékain keresztül.”

Ez az a bizonyítási szint, amelyet az auditorok elvárnak, amikor azt kérdezik, hogy a felhővel kapcsolatos felelősségek downstream szinten is kontrolláltak-e.

Hogyan tesztelik az auditorok ugyanazt a mátrixot?

Egy erős felhőszolgáltatási megosztott felelősségi mátrix több auditálási megközelítést is kiáll, mert tulajdonosi felelősségre, kikényszeríthetőségre és bizonyítékokra épül.

A mátrix nem a végcél. Ez az a térkép, amely alapján az auditorok ellenőrzik, hogy az irányítási rendszer valódi-e.

Egy ISO-auditor kiválaszthat egy nagy hatású felhőhozzáférési kockázatot, és végigkövetheti a kockázati nyilvántartástól az SoA-ig, majd a hozzáférés-felülvizsgálatokig, az MFA-bizonyítékokig és a monitorozási riasztásokig. Egy DORA-értékelő kiválaszthat egy kritikus IKT-szolgáltatót, és kérheti a kilépési tesztet, az alvállalkozói elemzést és a szerződéses auditálási jogokat. Egy GDPR-felülvizsgáló a törlésre, az adatok földrajzi helyére, az adatsértés-bejelentésre és a további adatfeldolgozói átláthatóságra fókuszálhat.

Gyakori hibaminták

A leggyakoribb megosztott felelősségi hibák nem különlegesek.

Először: a szervezetek a szolgáltatói bizonyossági jelentésekre támaszkodnak anélkül, hogy azokat ügyféloldali felelősségekre képeznék le. Egy felhőszolgáltató bizonyíthatja a fizikai biztonságot, az infrastruktúra-rezilienciát és a platformkontrollokat, de azt nem, hogy az Ön tároló-bucketje privát volt-e, az IAM-szerepkörök a legkisebb jogosultság elvét követték-e, vagy a naplók engedélyezve voltak-e.

Másodszor: a szerződések általános biztonsági nyelvezetet tartalmaznak, de nem tartalmaznak incidens-idővonalakat, naplóhozzáférési jogokat, auditálási jogokat, alvállalkozásba adási korlátokat, adat-visszaadási rendelkezéseket vagy kilépési támogatást. A Zenith Blueprint Controls in Action szakaszának 23. lépése tipikus beszállítói megállapodási területeket emel ki, például a bizalmasságot, hozzáférés-szabályozást, technikai és szervezési intézkedéseket, incidens-idővonalakat, auditálási jogot, alvállalkozói kontrollokat és a szerződés lezárására vonatkozó rendelkezéseket.

Harmadszor: a további adatfeldolgozók adatvédelmi célból szerepelnek listán, de nincsenek összekapcsolva biztonsági, folytonossági vagy koncentrációs kockázattal. Egy downstream megfigyelhetőségi vagy támogatási szolgáltató soha nem jelenik meg a kockázati nyilvántartásban, jóllehet kiesése vagy adatsértése hatással lehet az ügyfélnek nyújtott szolgáltatásra.

Negyedszer: az SoA szerint egy kontroll alkalmazandó, de senki sem tud működési bizonyítékot bemutatni. A felhőnaplózás megvalósítottként szerepelhet, de a szervezet nem tudja igazolni a megőrzési beállításokat, hozzáférés-felülvizsgálatokat, riasztáskezelést vagy a szolgáltatói naplóhozzáférési vállalásokat.

Ötödször: az incidensreagálási tervek nem tükrözik a szolgáltatói függőséget. Ha a szolgáltató platformincidensről értesít, ki értékeli az ügyfélhatást? Ki dönti el, hogy szükséges-e NIS2, DORA vagy GDPR szerinti bejelentés? Ki veszi fel a kapcsolatot az érintett ügyfelekkel? Mi történik, ha a gyökérok egy további adatfeldolgozónál van?

Vezetői elszámoltathatóság: miért kell ezzel foglalkoznia az igazgatóságnak?

A NIS2 Article 20 előírja, hogy a vezető testületek hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék a végrehajtást és képzésben részesüljenek. A DORA Article 5 előírja, hogy a vezető testület határozza meg, hagyja jóvá, felügyelje és viselje a felelősséget az IKT-kockázatkezelési megállapodásokért, ideértve az IKT harmadik fél szabályzatokat, a folytonossági és helyreállítási terveket, az auditterveket, a képzést és a jelentési csatornákat.

Ez megváltoztatja a mátrix célját. Már nem csupán biztonsági munkalap. Bizonyítékká válik arra, hogy a vezetés tudja:

• Mely felhőszolgáltatások támogatják a kritikus működést.
• Mely harmadik felek és további adatfeldolgozók lényegesek.
• Mely kötelezettségek alkalmazandók az ügyfélszerződések, a GDPR, a NIS2 és a DORA alapján.
• Mely felelősségek maradnak a szervezetnél.
• Mely szolgáltatói vállalások kikényszeríthetők szerződésben.
• Mely hiányosságok igényelnek finanszírozást, helyesbítő intézkedést vagy kockázatelfogadást.

KKV-k esetében az arányosság számít. Egy kisebb szervezetnek nincs szüksége nehézkes bürokráciára, de továbbra is szüksége van dokumentációra, monitorozásra, reziliens rendszerekre, IKT-kockázati források észlelésére, kulcsfontosságú harmadik fél függőségek azonosítására, folytonossági intézkedésekre, tesztelésre, tanulságokra és hatály esetén időszakos felülvizsgálatra.

A mátrix az egyik leghatékonyabb arányos eszköz, mert a kötelezettségeket konszolidálja, nem pedig megsokszorozza.

30 napos sprint a felhőmodell auditkész állapotba hozásához

Ha nem tudja megválaszolni, ki felel az egyes felhőkontrollokért, milyen bizonyíték igazolja azt, és melyik további adatfeldolgozó lehet rá hatással, akkor a megosztott felelősségi modellje továbbra is diagram, nem irányítási dokumentum.

Egy gyakorlati 30 napos sprint így néz ki:

1. Hozza létre vagy frissítse a Felhőszolgáltatási Nyilvántartást a Felhőszolgáltatások használatára vonatkozó szabályzat vagy a Felhőszolgáltatások használatára vonatkozó szabályzat - KKV alapján.
2. Azonosítsa a kritikus szolgáltatásokat, a személyesadat-kezelést, az ügyféloldali rendszereket és a DORA vagy NIS2 relevanciát.
3. Építse fel az első mátrixot az ISO/IEC 27001:2022 Annex A 5.20, 5.21 és 5.23 kontrolljai köré a Zenith Controls használatával.
4. Kapcsoljon minden sort a kockázati nyilvántartáshoz és az alkalmazhatósági nyilatkozathoz a Zenith Blueprint 13. lépése alapján.
5. Ellenőrizze a beszállítói és adatfeldolgozói záradékokat a Harmadik fél és beszállítói biztonsági szabályzat, a Harmadik fél és beszállítói biztonsági szabályzat - KKV és az Adatvédelmi és magánszféra-védelmi szabályzat használatával.
6. Adja hozzá a naplómegőrzést, incidenseszkalációt, további adatfeldolgozói jóváhagyást, auditálási jogokat és kilépési bizonyítékokat.
7. Évente, valamint jelentős változások, incidensek, új további adatfeldolgozók vagy auditmegállapítások után vizsgálja felül a kritikus beszállítókat.

A cél egyszerű. Amikor az ügyfél, auditor, szabályozó hatóság vagy igazgatóság azt kérdezi: „ki felel ezért a kontrollért?”, nem szerződések, jegyek és mappák között kell keresgélnie. Megnyitja a mátrixot, megmutatja a felelőst, megmutatja a záradékot, megmutatja a bizonyítékot, és megmutatja a downstream nyomvonalat.

A Clarysec segít a felhőszolgáltatói bizonyossági csomagokat integrált megosztott felelősségi mátrixszá alakítani ISO/IEC 27001:2022 auditokhoz, NIS2 felkészültséghez, DORA IKT harmadik fél kockázathoz, GDPR szerinti elszámoltathatósághoz és nagyvállalati ügyfélátvilágításhoz.

Induljon a nyilvántartással. Építse fel a mátrixot. Csatolja a bizonyítékokat. Ezután használja igazgatóság elé vihető bizonyítékként arra, hogy a felhőkockázat nincs kiszervezve: irányított.