Felhőrégiók irányítása GDPR, NIS2 és DORA megfeleléshez

Kedd reggel 08:17-kor Maria, egy gyorsan növekvő európai fintech információbiztonsági vezetője megkapja azt az üzenetet, amelytől előbb-utóbb minden szabályozott felhőügyfél tart.

A beszerzési csapat továbbít egy rövid beszállítói értesítést:

“Felhőalapú analitikai szolgáltatónk teljesítményokokból új régióba helyezi át az EU-s ügyféltelemetriát. A szolgáltató szerint ennek nincs biztonsági hatása. Jóváhagyhatjuk?”

Mielőtt Maria válaszolhatna, újabb értesítés érkezik az elsődleges felhőszolgáltatótól. A szolgáltató 90 nap múlva „optimalizálja globális támogatási modelljét”, és a Tier 2 támogatási jegyeket egy új további adatfeldolgozón keresztül kezeli. Egy gyors felülvizsgálat kimutatja, hogy a további adatfeldolgozó székhelye olyan országban található, amelyre nem vonatkozik GDPR szerinti megfelelőségi határozat.

09:00-ra a jogi, adatvédelmi, reziliencia-, beszerzési, felhőmérnöki és pénzügyi megfelelési területek is bekapcsolódnak az egyeztetésbe. Az adatvédelmi tisztviselő (DPO) azt kérdezi, szükséges-e adattovábbítási hatásvizsgálat. A rezilienciáért felelős vezető azt vizsgálja, hogy az új régió érinti-e egy kritikus szolgáltatás helyreállítási tervét. A pénzügyi megfelelési vezető azt kérdezi, szerepel-e a szolgáltató a DORA szerinti, IKT-szolgáltatást nyújtó harmadik felekre vonatkozó nyilvántartásban. A felhőcsapat ellenőrzi az éles adatkezelési réteget, és felismeri, hogy a probléma jóval túlmutat az analitikán. A biztonsági mentések, operatív naplók, támogatási jegyek, adattó-exportok, vészhelyzeti (break-glass) hozzáférés és alvállalkozói hozzáférés mind hatály alá tartozhatnak.

Ez a 2026-os felhőirányítás valódi problémája.

A legtöbb szervezetnek van felhőszabályzata. Soknak van beszállítói nyilvántartása. Néhánynak van GDPR szerinti adattovábbítási értékelése. Kevesen tudnak azonban bizonyítékokkal válaszolni a nehezebb auditkérdésre:

Pontosan hol találhatók a szabályozott adatok és a kritikus IKT-feldolgozás, ki honnan férhet hozzájuk, mi történik átkapcsoláskor, és milyen szerződéses kontroll akadályozza meg, hogy a szolgáltató jóváhagyás nélkül megváltoztassa a választ?

Ez a felhőrégiók irányítása. Nem egyetlen jogi jelölőnégyzet. Élő kontrollrendszer az ISO/IEC 27001:2022, az ISO/IEC 27002:2022 felhő- és beszállítói kontrolljai, a GDPR szerinti elszámoltathatóság, a NIS2 szerinti szolgáltatási reziliencia és a DORA szerinti, IKT-szolgáltatást nyújtó harmadik felek felügyelete között.

Az adatrezidencia ma már operatív kontroll

Éveken át az „EU-only hosting” követelményt az adatfeldolgozási szerződés egyik záradékaként kezelték. Ez már nem elég. Egy korszerű felhőalapú adatrezidencia- és régióirányítási programnak legalább hat operatív réteget kell lefednie:

1. Elsődleges éles tárolási és számítási régiók.
2. Biztonsági mentési, archiválási és katasztrófa utáni helyreállítási régiók.
3. Naplózási, monitorozási, SIEM- és megfigyelhetőségi adathelyek.
4. Támogatási hozzáférés, beleértve a távoli adminisztrációt és a vészhelyzeti hozzáférést.
5. További adatfeldolgozók és alvállalkozók, beleértve a menedzselt szolgáltatásokat és a marketplace-komponenseket.
6. Adattovábbítási útvonalak környezetek, alkalmazásprogramozási interfészek, analitikai platformok és ügyféltámogatási eszközök között.

A GDPR ezt elkerülhetetlenné teszi, mert a személyes adatok közé tartozhatnak online azonosítók, IP-címek, ügyfélfiók-azonosítók, felhasználói nyilvántartások, eszközazonosítók, operatív metaadatok és támogatási bejegyzések. Az adatkezelés fogalma is tág, és magában foglalja a tárolást, hozzáférést, felhasználást, közlést, törlést és megsemmisítést. A „csak naplókat küldünk” nem biztonságos kivétel, ha ezek a naplók azonosítókat tartalmaznak.

A GDPR Article 5 az elszámoltathatóság elvét is tartalmazza. Az adatkezelőknek nemcsak meg kell felelniük a jogszerűség, tisztességesség, átláthatóság, célhoz kötöttség, adattakarékosság, tárolási korlátozás, sértetlenség és bizalmasság elveinek. A megfelelést igazolniuk is tudniuk kell. A felhőrégiók irányítása az egyik módja annak, hogy ez az igazolhatóság a gyakorlatban is működjön.

A NIS2 az adatvédelmi kérdést rezilienciakérdéssé szélesíti. Az Article 21 alapján az alapvető és fontos szervezeteknek megfelelő technikai, operatív és szervezeti intézkedéseket kell végrehajtaniuk a működésükhöz vagy szolgáltatásnyújtásukhoz használt hálózati és információs rendszerek kockázatainak kezelésére. A felsorolt intézkedések közé tartozik az ellátási lánc biztonsága, az üzletmenet-folytonosság, a biztonsági mentések kezelése, a katasztrófa utáni helyreállítás, a válságkezelés, a hozzáférés-szabályozás, az eszközkezelés, a titkosítás és az eredményesség értékelése. Ha egy felhőrégióra vonatkozó döntés érinti egy hatály alá tartozó szolgáltatás rendelkezésre állását vagy helyreállítását, az nem pusztán adatvédelmi ügy. Rezüilienciaügy.

Pénzügyi szervezetek esetén a DORA még magasabb elvárást állít. A DORA 2025. január 17-től alkalmazandó, és követelményeket határoz meg az IKT-kockázatkezelésre, az incidensjelentésre, a digitális működési reziliencia tesztelésére, az IKT-harmadikfél-kockázatkezelésre és a szerződéses megállapodásokra. Az Article 28 előírja, hogy a pénzügyi szervezetek az IKT-harmadikfél-kockázatot az IKT-kockázatkezelési keretrendszer szerves részeként kezeljék, tartsanak fenn nyilvántartást a szerződéses megállapodásokról, értékeljék a koncentrációs kockázatot, és tervezzék meg a kilépést a kritikus vagy fontos funkciók esetén. Az Article 30 szerződéses egyértelműséget vár el a szolgáltatás és adatkezelés helyeire, az auditálási és hozzáférési jogokra, az incidensek támogatására, az alvállalkozásba adásra, a helyreállításra, az adatok visszaadására és a kilépési átmenetre vonatkozóan.

A DORA a pénzügyi szervezetek ágazatspecifikus rendszereként működik, miközben a NIS2 továbbra is releváns a tágabb ellátási láncban, különösen a felhőszolgáltatók, adatközpont-szolgáltatók és menedzselt szolgáltatók esetében. Egyetlen előzetesen nem ellenőrzött további adatfeldolgozó ezért dominóhatást idézhet elő a pénzügyi reziliencia, az ellátási lánc biztonsága és az adatvédelmi kötelezettségek területén.

Egyszerűen fogalmazva: ha egy szabályozott vállalkozás nem tudja irányítani, hol történik a felhőalapú adatkezelése, akkor nem tudja hitelesen irányítani az IKT-harmadikfél-kockázatot sem.

Az ISO 27001 legyen az irányítási rendszer horgonya

Az ISO/IEC 27001:2022 biztosítja azt a struktúrát, amellyel az adatrezidenciával kapcsolatos bizonytalanság szabályozott irányítási rendszerré alakítható.

A 4.1–4.4 pontok megkövetelik, hogy a szervezet a saját kontextusában határozza meg az IBIR-t, beleértve a belső és külső tényezőket, az érdekelt felek követelményeit, a jogi, szabályozási és szerződéses kötelezettségeket, valamint a más szervezetekkel fennálló interfészeket és függőségeket. A felhőrégiók irányítása esetén az IBIR alkalmazási területének kifejezetten tartalmaznia kell a felhőszolgáltatásokat, a kiszervezett IKT-feldolgozást, a kritikus szolgáltatásfüggőségeket és a szabályozott adatáramlásokat.

Az 5.1–5.3 pontok a vezetést teszik elszámoltathatóvá. A felső vezetésnek az információbiztonsági szabályzatot és célkitűzéseket össze kell hangolnia a stratégiai iránnyal, erőforrásokat kell biztosítania, felelősségeket kell kijelölnie, és gondoskodnia kell az IBIR teljesítményének jelentéséről. Itt válik a felhőalapú adatrezidencia vezetőségi és igazgatósági témává, különösen NIS2 szervezeteknél, ahol a vezető testületeknek jóvá kell hagyniuk és felügyelniük kell a kiberbiztonsági kockázatkezelési intézkedéseket, valamint DORA hatálya alá tartozó pénzügyi szervezeteknél, ahol a vezető testület felelős az IKT-kockázatirányításért.

A 6.1.1–6.1.3 pontok adják a kockázatkezelési motort. A szervezetnek ismételhető kockázatértékelési folyamatra, kockázattulajdonosokra, hatás- és valószínűségi kritériumokra, kezelési lehetőségekre, kiválasztott kontrollokra, alkalmazhatósági nyilatkozatra és maradványkockázat-elfogadásra van szüksége. Egy felhőrégió-változást nem szabad informális e-mailben jóváhagyni. Kockázatértékelést vagy változás-felülvizsgálatot kell kiváltania, ha szabályozott adatokat, kritikus funkciókat, beszállítókat vagy folytonossági feltételezéseket érint.

A 8.1 pont a tervezést operatív kontrollá alakítja. A folyamatokat be kell vezetni, kontrollálni kell, dokumentálni kell, szabályozott módon kell módosítani, és ki kell terjeszteni az IBIR szempontjából releváns, külsőleg biztosított termékekre és szolgáltatásokra. A 8.2 és 8.3 pontok előírják az újraértékelést és kockázatkezelést tervezett időközönként vagy jelentős változások esetén. A felhőrégió-migráció, a biztonsági mentések replikációja, egy új naplózási platform vagy egy támogatási célú további adatfeldolgozó változása mind újraértékelést igényelhet.

Az ISO/IEC 27002:2022 kontrollkészlet ezután biztosítja a gyakorlati kontrollcsaládot. A legrelevánsabb kontrollok:

• 5.9 Információk és egyéb kapcsolódó vagyonelemek nyilvántartása.
• 5.14 Információátadás.
• 5.15 Hozzáférés-szabályozás.
• 5.19 Információbiztonság a beszállítói kapcsolatokban.
• 5.20 Információbiztonság kezelése beszállítói megállapodásokban.
• 5.22 Beszállítói szolgáltatások monitorozása, felülvizsgálata és változáskezelése.
• 5.23 Információbiztonság felhőszolgáltatások használatakor.
• 5.29 Információbiztonság zavar esetén.
• 5.30 IKT-felkészültség az üzletmenet-folytonosságra.
• 5.31 Jogi, törvényi, szabályozási és szerződéses követelmények.
• 5.34 A magánszféra védelme és a személyazonosításra alkalmas információk (PII) védelme.
• 5.36 Megfelelés az információbiztonsági szabályzatoknak, szabályoknak és szabványoknak.
• 8.11 Adatmaszkolás.
• 8.12 Adatszivárgás megelőzése.
• 8.13 Információk biztonsági mentése.
• 8.15 Naplózás.
• 8.16 Monitorozási tevékenységek.
• 8.20 Hálózatok biztonsága.
• 8.24 Kriptográfia használata.
• 8.25 Biztonságos fejlesztési életciklus.
• 8.27 Biztonságos rendszerarchitektúra és mérnöki alapelvek.
• 8.32 Változáskezelés.

A Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls az ISO/IEC 27002:2022 5.23 kontrollját, az Információbiztonság felhőszolgáltatások használatakor kontrollt megelőző kontrollként kezeli, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást, operatív képességet biztosít a beszállítói kapcsolatok biztonságában, valamint biztonsági kontrollterületeket fed le az irányítás, az ökoszisztéma és a védelem területén. Az útmutató az 5.23 kontrollt összekapcsolja az 5.19 beszállítói kapcsolatokkal, az 5.14 információátadással, az 5.9 eszköznyilvántartással, a 8.11 és 8.12 adatmaszkolással és adatszivárgás-megelőzéssel, a 8.20 hálózatbiztonsággal és a 8.25 biztonságos fejlesztési életciklussal.

A Zenith Controls egyik kulcsmegállapítása:

“A felhőszolgáltatók (CSP-k) kritikus beszállítóként működnek, ezért az 5.19 szerinti beszállítóválasztásra, szerződéskötésre és kockázatkezelésre vonatkozó valamennyi kontroll alkalmazandó rájuk. Az 5.23 azonban továbbmegy, és felhőspecifikus kockázatokat kezel, 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égi modelleket.”

Ez a mondat ragadja meg az irányítási fordulatot. A felhőszolgáltató nem csupán egy újabb beszállító. Gyakran maga az a hely, ahol a szabályozott adatkezelés történik.

Rejtett adatrezidencia-csapdák: biztonsági mentések, naplók, támogatás és további adatfeldolgozók

A legtöbb adatrezidencia-hiba nem az éles adatbázissal kezdődik. Olyan támogató rendszerekben jelenik meg, amelyeket soha nem vontak be megfelelően az adatáramlási felülvizsgálatba.

A biztonsági mentések klasszikus példák. Egy SaaS platform futhat Frankfurtban vagy Dublinban, miközben az automatizált biztonsági mentések reziliencia- vagy költségokokból máshová replikálódnak. Ha a biztonsági mentés személyes adatokat, ügyfélnyilvántartásokat, hitelesítési naplókat vagy szabályozott tranzakciótörténetet tartalmaz, a biztonsági mentési régió számít. A NIS2 Article 21 alapján a biztonsági mentések kezelése és a katasztrófa utáni helyreállítás a biztonsági alapkövetelmények része. A DORA alatt a kritikus vagy fontos funkciók folytonossága és a tesztelt kilépési stratégiák megkövetelik a helyreállítási helyek és helyreállítási függőségek ismeretét.

A naplók szintén gyenge pontot jelentenek. A biztonsági csapatok a telemetriát SIEM-, megfigyelhetőségi és adattó-szolgáltatásokba központosítják. Ezek a naplók IP-címeket, felhasználói azonosítókat, rendszergazdai műveleteket, fizetési metaadatokat, sikertelen hitelesítési kísérleteket, ügyfélfiók-azonosítókat vagy támogatási nyomkövetési adatokat tartalmazhatnak. Ha a naplók globális monitorozási szolgáltatásba kerülnek, a szervezet a tudta nélkül határokon átnyúló adattovábbítást hozhatott létre.

A Clarysec Naplózási és felügyeleti szabályzat – KKV Naplózási és felügyeleti szabályzat – KKV közvetlenül foglalkozik a beszállítói bizonyítékokkal:

“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 hozzájuk”

Ez az idézet az „Irányítási követelmények” szakasz 5.5.1.3 szabályzati pontjából származik. Az adatrezidencia irányítása során ugyanannak a szerződés-felülvizsgálatnak meg kell erősítenie, hol őrzik ezeket a naplókat, ki férhet hozzájuk, és rendelkezésre áll-e naplózási bizonyíték incidensvizsgálat vagy szabályozó hatósági megkeresés során.

A támogatási hozzáférés ennél árnyaltabb. A szolgáltató tárolhatja az adatokat az EU-ban, miközben az EU-n kívüli támogatási mérnökök hozzáférhetnek ügyfélkörnyezetekhez, adatbázis-pillanatképekhez, diagnosztikai csomagokhoz vagy jegymellékletekhez. Ennek elfogadhatósága az érintett adatoktól, az adattovábbítási mechanizmustól, a szerepkörtől, a szerződéses garanciáktól, a hozzáférési kontrolloktól és a naplózástól függ. Az architektúra lehet regionális, miközben az emberi hozzáférési modell globális.

A további adatfeldolgozók jelentik a végső vakfoltot. A közvetlen beszállító támaszkodhat felhőinfrastruktúrára, tartalomkézbesítő hálózatokra, menedzselt adatbázisokra, jegykezelő rendszerekre, analitikai szolgáltatásokra, offshore támogatási csapatokra vagy biztonsági beszállítókra. A DORA Article 29 előírja az alvállalkozásba adási kockázatok, harmadik országbeli szolgáltatók, adat-helyreállítási korlátok, adatvédelmi megfelelés és összetett alvállalkozói láncok értékelését. A NIS2 Article 21 megköveteli, hogy a szervezetek figyelembe vegyék közvetlen beszállítóik és szolgáltatóik kiberbiztonsági gyakorlatát. A GDPR előírja, hogy az adatfeldolgozók a további adatfeldolgozókat úgy kezeljék, hogy az megőrizze az adatkezelő megfelelési képességét.

A Clarysec Third-Party and Supplier Security Policy-sme Harmadik felekre és beszállítókra vonatkozó biztonsági szabályzat – KKV ezt gyakorlati követelménnyé alakítja:

“Ha a beszállítóknak telephelyen kívül kell adatot tárolniuk, a vállalatnak bizonyosságot kell szereznie az adatvédelemről, a fizikai biztonságról és a földrajzi tárolási helyről (pl. GDPR által megkövetelt EU-only hosting esetén).”

Ez a „Szabályzat végrehajtásának követelményei” szakasz 6.2.4 szabályzati pontjából származik. Ugyanez a szabályzat előírja továbbá:

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

Ez az idézet az „Irányítási követelmények” szakasz 5.3.5 szabályzati pontjából származik. Ezek a záradékok együtt az adatrezidenciát beszállítókezelési munkafolyamattá alakítják, nem beszerzési preferenciává.

A szabályzatot végrehajtható felhőrégió-irányítássá kell alakítani

A felhőrégiók irányításának végrehajthatónak, felülvizsgálhatónak és auditálhatónak kell lennie.

KKV-k számára a Felhőszolgáltatások használatára vonatkozó szabályzat – KKV Felhőszolgáltatások használatára vonatkozó szabályzat – KKV határozza meg az alapot:

“Az adatrezidencia és adatvédelmi gyakorlatok megfelelnek az alkalmazandó jogi követelményeknek (pl. GDPR)”

Ez az „Irányítási követelmények” szakasz 5.2.3 szabályzati pontjából származik. Ugyanez a szabályzat előírja, hogy a felhőirányítási nyilvántartások tartalmazzák:

“Azt az országot vagy régiót, ahol az adatokat tárolják”

Ez az idézet az „Irányítási követelmények” szakasz 5.3.4 szabályzati pontjából származik.

Nagyobb szervezetek esetén a Felhőszolgáltatások használatára vonatkozó szabályzat Felhőszolgáltatások használatára vonatkozó szabályzat kifejezettebb a szerződéses érvényesítésről:

“Az adatrezidencia-követelményeket szerződésesen kell érvényesíteni (pl. kizárólag EU-n belüli tárolás GDPR hatálya alá tartozó adatok esetén).”

Ez a „Szabályzat végrehajtásának követelményei” szakasz 6.6.2 szabályzati pontjából származik. A szabályzat azt is kimondja:

“A határokon átnyúló adattovábbításoknak meg kell felelniük a GDPR V. fejezetének és adott esetben a DORA Article 28 követelményeinek.”

Ez a „Szabályzat végrehajtásának követelményei” szakasz 6.6.3 szabályzati pontjából származik.

A vállalati változat külön figyelmet rendel a következőhöz is:

“Adatrezidencia- és adattulajdonosi garanciák”

Ez az idézet a „Szerepkörök és felelősségek” szakasz 4.5.1.2 szabályzati pontjából származik.

A Harmadik felekre és beszállítókra vonatkozó biztonsági szabályzat Harmadik felekre és beszállítókra vonatkozó biztonsági szabályzat a szerződéses réteget adja hozzá azzal, hogy előírja:

“Adatkezelési követelmények, beleértve a tárolási helyet, hozzáférési kontrollokat, valamint visszaadási vagy megsemmisítési záradékokat”

Ez az idézet az „Irányítási követelmények” szakasz 5.3.2 szabályzati pontjából származik.

Végül a Jogi és szabályozói megfelelési szabályzat Jogi és szabályozói megfelelési szabályzat azonosítja azokat a változásokat, amelyeknek megfelelőségi felülvizsgálatot kell kiváltaniuk, többek között:

“Az adattovábbítási mechanizmusok, további adatfeldolgozók vagy határokon átnyúló adatáramlások változásai”

Ez az „Irányítási követelmények” szakasz 5.3.1.1 szabályzati pontjából származik.

Ezek a dokumentumok nem működhetnek különálló fájlokként. Egy érett IBIR-ben egyetlen működési modellé állnak össze: felhőnyilvántartás, adatáramlási nyilvántartás, beszállítói nyilvántartás, szerződésmátrix, kockázatértékelés, adattovábbítási felülvizsgálat, változás-jóváhagyás és auditbizonyíték-csomag.

Felhőrégió-irányítási nyilvántartás létrehozása

Egy gyakorlati nyilvántartás az adatrezidenciát feltételezésből bizonyítékká alakítja. Kezdjen egy kritikus, ügyféloldali szolgáltatással, különösen olyannal, amely valószínűleg NIS2, DORA ügyfélátvilágítás vagy GDPR vizsgálat hatálya alá tartozik.

Most kapcsolja össze a nyilvántartást a végrehajtással.

A Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint útmutatóban a Controls in Action fázis 23. lépése az 5.19–5.37 szervezeti kontrollokra összpontosít, beleértve a beszállítói megállapodásokat és a felhőszolgáltatás-irányítást. A Blueprint figyelmeztet, hogy a beszállítói megállapodásoknak túl kell mutatniuk az általános bizalmasságon:

“Sok iparágban a beszállítói megállapodások az adattulajdonlást és joghatóságot is meghatározzák. Hol kezelik az adatokat? Ki tartja meg az ellenőrzést? Vannak-e adattovábbítási korlátozások? Vannak-e felhőspecifikus kontrollok (például adatszegmentálás, kulcstulajdonlás vagy földrajzi korlátozások)? Ezek az elemek nem csupán jogi kérdések, hanem operatív biztonsági ügyek, különösen szabályozott ágazatokban.”

Ugyanez a fázis és lépés foglalkozik a beszállítói változáskezeléssel:

“A legtöbb beszállítói kapcsolat jó szándékkal indul. Alapos felülvizsgálat, egyértelmű elvárások, aláírt megállapodások (lásd 5.20), talán még egy biztonsági ellenőrzőlista is. De mi történik egy évvel később, amikor a beszállító azt javasolja, hogy az Ön adatait új felhőrégióba helyezze át?”

Ez Maria kedd reggeli problémája. A nyilvántartás módot ad az információbiztonsági vezetőnek arra, hogy a költözés jóváhagyása előtt válaszolni tudjon.

A Zenith Blueprint a felhőkontroll 5.23 irányítási jelentését is tisztázza:

“Egy hibásan konfigurált tároló bucket, egy nyilvánosan kitett irányítópult vagy túlzott jogosultságok egy felhő IAM-beállításban nem felhőhibák. Ezek irányítási hibák.”

A Controls in Action fázis 22. lépésében a Blueprint az információátadással foglalkozik, és kimondja:

“Ha személyes adatokat továbbítanak határokon át, a módszernek meg kell felelnie az adatvédelmi és jogi kötelezettségeknek, nem csupán a belső preferenciáknak.”

Ez a mondat fontos a felhőcsapatok számára. A titkosítás, a biztonságos alkalmazásprogramozási interfészek és a privát kapcsolatok szükségesek, de nem helyettesítik a jogi és szabályozási adattovábbítási irányítást.

Az első 90 perces bizonyíték-workshop lebonyolítása

Ne a teljes vállalat feltérképezésével kezdjen. Válasszon egy kritikus szolgáltatást, és tartson fókuszált workshopot a felhőmérnökség, a beszerzés, a jogi, az adatvédelmi, a reziliencia- és a biztonsági üzemeltetési területek részvételével.

Először soroljon fel minden felhő- vagy beszállítói komponenst, amely a szolgáltatást tárolja, kezeli, továbbítja, menti, monitorozza vagy támogatja. Vegye fel a kisebb rendszereket is, például a rendelkezésreállás-monitorozást, a jegymellékleteket, a hibakövetést, a támogatási képernyőmegosztó eszközöket és a diagnosztikai exportokat.

Másodszor jelölje meg az egyes adatkategóriákat. Ha a csapat azt mondja, „csak metaadat”, kérdőjelezze meg a feltételezést. A metaadat is lehet személyes adat vagy bizalmas ügyféladat.

Harmadszor bizonyíték alapján ellenőrizze a régiót. Használjon felhőkonzol-konfigurációt, biztonsági mentési szabályzatokat, SIEM tenancy beállításokat, DPA mellékleteket, további adatfeldolgozói listákat, szerződéses feltételeket, támogatási hozzáférési dokumentációt és CSP auditjelentéseket. Ne támaszkodjon kizárólag értékesítési ígéretekre.

Negyedszer rögzítse a hiányosságokat az IBIR kockázati nyilvántartásban. Példák: „a biztonsági mentés replikációs régiója nincs szerződésesen korlátozva”, „harmadik országból történő támogatási hozzáféréshez nincs dokumentált jóváhagyási munkafolyamat”, „a SIEM-naplókat globálisan őrzik meg”, „a további adatfeldolgozói lista nem azonosítja a tárhelyrégiót”, vagy „a DORA-nyilvántartás nem különbözteti meg a kritikus vagy fontos funkciótól való függőséget”.

Ötödször döntsön a kockázatkezelésről. A kezelések közé tartozhat szerződésmódosítás, régiózár, ügyfélértesítés, ügyfél által kezelt kulcsokkal végzett titkosítás, tokenizáció, naplóminimalizálás, új beszállítói jóváhagyás, kilépési stratégia frissítése vagy a maradványkockázat kockázattulajdonos általi elfogadása.

Hatodszor őrizze meg a bizonyítékokat. Az auditorok nemcsak azt fogják kérdezni, mit döntött. Azt is kérdezni fogják, honnan tudja, hogy a döntést végrehajtották.

Egy bizonyítékkészlet megfeleltetése ISO, GDPR, NIS2, DORA és NIST CSF 2.0 keretrendszereknek

Egy erős felhőrégió-irányítási program elkerüli a párhuzamos megfelelési munkát. Ugyanaz a bizonyíték több kötelezettséget is támogathat, ha megfelelően strukturált.

A NIST CSF 2.0 hasznos integráló réteg. GOVERN funkciója összhangot teremt a jogi, szabályozási, szerződéses és adatvédelmi kötelezettségekkel, a kockázatvállalási hajlandósággal, az elszámoltathatósággal, a szabályzatokkal és a felügyelettel. GV.SC ellátási lánc kategóriája jól megfeleltethető a DORA IKT-harmadikfél-elvárásoknak, a NIS2 ellátási lánc követelményeinek és az ISO beszállítói kontrolloknak.

A COBIT 2019 és az ISACA auditori nézőpont gyakran ugyanazokat a tényeket vizsgálja irányítási célkitűzéseken keresztül: tulajdonosi felelősség, döntési jogok, kockázatoptimalizálás, beszállítói teljesítmény, előnyök realizálása és bizonyosság. Egy COBIT-stílusú felülvizsgáló nem feltétlenül azzal kezdi, hogy „melyik felhőrégió van konfigurálva?”. Lehet, hogy így kérdez: „kinek van jogosultsága jóváhagyni egy régióváltozást, hogyan eszkalálják a kockázatot, és honnan tudja a vezetés, hogy a felhőszolgáltatók a tűréshatáron belül maradnak?”

Ezért rögzíti a Clarysec-modell a tulajdonosokat, jóváhagyási pontokat, szerződéses bizonyítékokat és vezetői jelentéstételt, nem csak a technikai beállításokat.

Felkészülés az auditori kérdésekre

A felhőrégiók irányítása tökéletes példa arra, hogyan vizsgálják különböző auditorok ugyanazt a kontrollt eltérő nézőpontból.

Egy ISO/IEC 27001:2022 auditor az alkalmazási területtel, az érdekelt felek követelményeivel, a kockázatértékeléssel és az alkalmazhatósági nyilatkozattal kezdi. Megkérdezi, azonosították-e a jogi, szabályozási és szerződéses követelményeket, szerepelnek-e a felhő- és beszállítói kontrollok, értékelték-e a kockázatokat, bevezették-e a kontrollokat, és megőrzik-e a bizonyítékokat. Mintavételezhet egy felhőszolgáltatást, és kérheti a beléptetési felülvizsgálatot, a szerződéses záradékokat, a régiókonfigurációt, a monitorozási felülvizsgálatot és a változás-jóváhagyást.

Egy adatvédelmi hatóság vagy GDPR-felülvizsgáló a személyes adatokra összpontosít. Megkérdezi, milyen személyes adatokat kezelnek, hol tárolják azokat, honnan férnek hozzájuk, mely adatfeldolgozók és további adatfeldolgozók vesznek részt, dokumentálták-e az adattovábbítási mechanizmusokat, szükséges-e adattovábbítási hatásvizsgálat, és megfelelő technikai és szervezési intézkedések vannak-e érvényben. A naplók, támogatási adatok és biztonsági mentések gyakran figyelmet kapnak, mert a szervezetek alulbecsülik őket.

Egy NIS2 auditor vagy illetékes hatóság a hatály alá tartozó szolgáltatásokra összpontosít. Vizsgálja az Article 20 szerinti vezetői elszámoltathatóságot, az Article 21 szerinti kockázatkezelési intézkedéseket, a folytonosságot, a biztonsági mentések kezelését, a katasztrófa utáni helyreállítást, az incidenskezelést, az ellátási lánc biztonságát, a hozzáférés-szabályozást, az eszközkezelést és az eredményesség értékelését.

Egy DORA felügyeleti szerv vagy belső auditcsoport az IKT-kockázatirányítást, a vezető testületi felügyeletet, az IKT-harmadikfél-megállapodások információs nyilvántartását, a kritikus vagy fontos funkciók leképezését, a koncentrációs kockázatot, az alvállalkozási kockázatot, az adatkezelési helyeket, az auditálási jogokat, az incidensjelentés támogatását, a folytonossági tesztelést és a kilépési terveket keresi. A DORA egyértelmű: a kiszervezés nem ruházza át az elszámoltathatóságot.

A Zenith Controls segít a biztonsági vezetőknek felkészülni ezekre az auditstílusokra, mert kereszthivatkozásokat ad a kontrollkapcsolatokhoz. Az ISO/IEC 27002:2022 5.20 kontrollja, az Információbiztonság kezelése beszállítói megállapodásokban esetén a Zenith Controls összekapcsolja azt az 5.19 beszállítói kapcsolatokkal, az 5.14 információátadással, az 5.22 beszállítói monitorozással, az 5.11 eszközök visszaszolgáltatásával és az 5.36 szabályzatoknak, szabályoknak és szabványoknak való megfeleléssel. Az 5.22 kontroll, a Beszállítói szolgáltatások monitorozása, felülvizsgálata és változáskezelése esetén a folyamatos beszállítói felügyeletet összekapcsolja az 5.29 zavar alatti biztonsággal, a 8.8 technikai sérülékenységek kezelésével, az 5.15 hozzáférés-szabályozással, a 8.27 biztonságos rendszerarchitektúra és mérnöki alapelvekkel, valamint az 5.36 megfeleléssel.

Ez a kontrollok közötti nézet azért fontos, mert egy régióváltozás soha nem csak régióváltozás. Megváltoztathatja a beszállítói kockázatot, az adattovábbítási kockázatot, a hozzáférési kockázatot, a folytonossági kockázatot, az incidensreagálási bizonyítékot és a szerződéses megfelelést.

Használja ezt a 2026-os CISO ellenőrzőlistát felhőváltozás jóváhagyása előtt

Használja ezt az ellenőrzőlistát bármely új felhőrégió, határokon átnyúló adatkezelési útvonal, biztonsági mentési hely, naplózási platform, támogatási modell vagy kritikus IKT-beszállítói változás jóváhagyása előtt.

Ha bármely kérdésre az a válasz, hogy „feltételezzük”, a kontroll még nem elég érett szabályozott működéshez.

Helyesbítési ütemterv

A helyesbítési út gyakorlatias, ha az IBIR-re épül.

1. Erősítse meg, hogy az IBIR alkalmazási területe tartalmazza a felhőszolgáltatásokat, a kritikus IKT-függőségeket és a szabályozott adatkezelést.
2. Hozza létre a Felhőrégió-irányítási nyilvántartást a prioritást élvező szolgáltatásokhoz.
3. Képezze le az egyes szolgáltatásokat adatkategóriákra, régiókra, biztonsági mentési helyekre, támogatási hozzáférésre és további adatfeldolgozókra.
4. Vizsgálja felül a beszállítói megállapodásokat a tárolási helyre, adattovábbításra, auditra, incidensre, alvállalkozásba adásra, visszaadásra és megsemmisítésre vonatkozó záradékok szempontjából.
5. Frissítse a kockázati nyilvántartást hiányosságokkal, koncentrációs kockázatokkal és dokumentálatlan adattovábbításokkal.
6. Hangolja össze a DORA szerinti IKT-harmadikfél-nyilvántartást és a NIS2 szolgáltatásfüggőségi leképezést, ahol alkalmazandó.
7. Ellenőrizze a technikai érvényesítést, beleértve a régiózárakat, biztonsági mentési szabályzatokat, naplózási beállításokat, titkosítást, hozzáférési kontrollokat és kulcskezelést.
8. Készítsen auditbizonyíték-csomagot képernyőképekkel, szerződésekkel, kockázati bejegyzésekkel, jóváhagyásokkal, felülvizsgálati jegyzőkönyvekkel és teszteredményekkel.
9. Hozzon létre változásindító mechanizmust új régiók, további adatfeldolgozók, adattovábbítási mechanizmusok vagy kritikus beszállítói szolgáltatásváltozások esetére.
10. Jelentse a vezetésnek a felhőalapú adatrezidencia-kockázatot, a kivételeket és a maradványkockázati döntéseket.

Ez nem elméleti megfelelés. Ez a különbség egy auditvizsgálatot kiálló felhőkörnyezet és egy szóbeli ígéretekre támaszkodó környezet között.

Üzleti indok: szuverenitás, reziliencia és bizalom

A felsővezetők időnként úgy tekintenek az adatrezidencia irányítására, mint a felhőagilitás korlátjára. A gyakorlatban az érett régióirányítás javítja az agilitást, mert a csapatok már beszerzés, fejlesztés vagy migráció előtt ismerik a szabályokat.

A termékcsapat gyorsabban indíthat, ha a jóváhagyott régiók egyértelműek. A beszerzés gyorsabban tárgyalhat, ha a kötelező záradékok már meghatározottak. A jogi terület gyorsabban értékelheti az adattovábbításokat, ha az adatáramlások dokumentáltak. A biztonsági üzemeltetés gyorsabban vizsgálódhat, ha a naplóhelyek és hozzáférési jogosultságok ismertek. Az igazgatóság gyorsabban hozhat kockázati döntéseket, ha a koncentrációs kockázat, a folytonossági hatás és a maradványkockázat elfogadása látható.

Az ügyfelek, különösen a szabályozott ügyfelek számára ez bizalmi jelzéssé válik. Az a SaaS-szolgáltató, amely el tudja magyarázni, hol találhatók az adatok, hogyan irányítják a biztonsági mentéseket, hogyan kontrollálják a támogatási hozzáférést, hogyan hagyják jóvá a további adatfeldolgozókat, és hogyan vizsgálják felül a régióváltozásokat, versenyelőnyben lesz azzal a szolgáltatóval szemben, amely csak annyit mond: „vezető felhőszolgáltatót használunk”.

2026-ban ez a különbség számít. A NIS2 a kiberbiztonsági irányítást az EU-s alapvető és fontos szervezetekhez vitte. A DORA az IKT-harmadikfél-felügyeletet formális pénzügyi ágazati fegyelemmé tette. A GDPR szerinti elszámoltathatóság továbbra is központi elem. Az ISO/IEC 27001:2022 adja azt az irányítási rendszert, amely mindezt összefogja.

Következő lépések a Clarysec segítségével

Ha szervezete nem tudja megválaszolni, hol találhatók a szabályozott adatok és a kritikus IKT-feldolgozás az éles működésben, a biztonsági mentésekben, a naplókban, a támogatási hozzáférésben és az alvállalkozóknál, most kell lezárni a hiányosságot.

A Clarysec segíthet felhőrégió-irányítási bizonyítékcsomagot készíteni az alábbiak használatával:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint a szakaszos ISO bevezetéshez és az auditra való felkészültséghez.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls az ISO/IEC 27002:2022 felhő- és beszállítói kontrolljainak operatív bizonyítékokra és több keretrendszert átfogó elvárásokra történő leképezéséhez.
• Felhőszolgáltatások használatára vonatkozó szabályzat Felhőszolgáltatások használatára vonatkozó szabályzat és Felhőszolgáltatások használatára vonatkozó szabályzat – KKV Felhőszolgáltatások használatára vonatkozó szabályzat – KKV a felhőalapú adatrezidencia-követelményekhez.
• Harmadik felekre és beszállítókra vonatkozó biztonsági szabályzat Harmadik felekre és beszállítókra vonatkozó biztonsági szabályzat és Third-Party and Supplier Security Policy-sme Harmadik felekre és beszállítókra vonatkozó biztonsági szabályzat – KKV a beszállítói szerződésekhez, az alvállalkozásba adáshoz és a földrajzi tárolási bizonyossághoz.
• Naplózási és felügyeleti szabályzat – KKV Naplózási és felügyeleti szabályzat – KKV a naplómegőrzéshez és szolgáltatói bizonyítékokhoz.
• Jogi és szabályozói megfelelési szabályzat Jogi és szabályozói megfelelési szabályzat az adattovábbítási mechanizmusokkal, további adatfeldolgozókkal és határokon átnyúló adatáramlásokkal kapcsolatos megfelelőségi felülvizsgálati kiváltó okokhoz.

Kezdje egy kritikus szolgáltatással, egy felhőszolgáltatóval és egy nyilvántartással. Néhány workshop alatt a feltételezésektől eljuthat a bizonyítékokig, a széttagolt megfeleléstől pedig az irányított felhőrezilienciáig.

Töltse le a Clarysec eszközkészletet, kérjen demót, vagy foglaljon felhőrégió-irányítási értékelést, hogy felhőalapú adatrezidencia-vállalásait auditra való felkészültséget biztosító bizonyítékká alakítsa.