Adatosztályozás ISO 27001, GDPR, NIS2 és DORA megfelelőséghez
A 2026-os audithelyzet: „Mutassa a bizonyítékot”
2026 februárja van, és egy gyorsan növekvő fintech SaaS-vállalat negyedéves igazgatósági ülése nem halad olyan gördülékenyen, ahogy azt az információbiztonsági vezető várta.
A vállalat nemrég megszerezte az ISO/IEC 27001:2022 tanúsítást. Van többtényezős hitelesítés, végpontvédelem, sérülékenységvizsgálat, hozzáférés-felülvizsgálat, incidenskezelési eljárás és gondosan összeállított DORA-felkészültségi jelentés. Ezután a vezérigazgató felteszi azt a kérdést, amely megváltoztatja a terem hangulatát.
„A fő befektetőnk azt kérdezi, hogyan tudjuk igazolni, hogy az ügyfelek pénzügyi adatai következetesen védettek az AWS-ben, az Azure-ban, a SaaS-alapú támogatási platformunkon és az analitikai adattárházban. Ha egy auditor kiemel egy fájlt az objektumtárolóból, egy másikat pedig egy együttműködési mappából, honnan tudjuk, hogy ugyanazok a szabályok vonatkoznak rájuk?”
Az információbiztonsági vezető megnyitja az eszköznyilvántartást. Az adatbázisokat, felhőfiókokat, alkalmazásokat, SaaS-platformokat és tárolási helyeket tartalmazza. Az osztályozási mező azonban hiányos. Néhány mappa szervezeti egységek szerint van elnevezve, nem érzékenység szerint. Az ügyfélexportok belső jelentésfájlok mellett találhatók. Egyes támogatási táblázatok ügyfélazonosítókat, fizetési hivatkozásokat és ügyjegyzeteket tartalmaznak, mégis „Internal” címkét kaptak. Vannak DLP-szabályok, de csak a nyilvánvaló mintákra aktiválódnak. A felhőhasználati szabályzat szerint az EU-s személyes adatoknak jóváhagyott régiókban kell maradniuk, de a csapat nem tudja bizonyítani, hogy az adattárolás földrajzi helyére vonatkozó szabályokat osztályozási metaadatok vezérlik.
Ekkor a megfelelőségi vezető hozzáteszi a szabályozói szempontot: „Ez megfelel majd a GDPR Article 32, a NIS2 Article 21 és a DORA szerinti IKT-kockázati bizonyítékok elvárásainak?”
Az őszinte válasz: még nem.
Ez az a 2026-os hiányosság, amellyel sok szervezet szembesül. Rendelkeznek biztonsági kontrollokkal, de nincs meg az az irányítási réteg, amely minden kontroll számára meghatározza, mit kell védeni, milyen erősséggel kell védeni, és hogyan kell ezt igazolni. Ez az irányítási réteg az adatosztályozás és az információcímkézés.
ISO/IEC 27001:2022 szempontból az osztályozás és a címkézés nem kozmetikai dokumentumkezelési gyakorlat. Gyakorlati hidat képez a kockázatértékelés, a hozzáférés-szabályozás, a titkosítás, a megőrzés, a DLP, az adattárolás földrajzi helye, a beszállítói átvilágítás, a felügyelet és az incidensjelentés között. A Clarysec bevezetési modelljében ezek az IBIR bizonyítéklánc központi elemei: a vagyonelem nyilvántartásba vétele, tulajdonos kijelölése, osztályozás, címkézés, kezelési szabályok alkalmazása, kivételek nyomon követése és a visszakövethetőség bemutatása az auditorok számára.
Miért vált az osztályozás és a címkézés igazgatósági szintű kontrollá
A szabályozó hatóságok és az ügyfelek egyre inkább elvárják, hogy a szervezetek bemutassák: a biztonsági intézkedések arányban állnak az adatok érzékenységével, a szolgáltatás kritikusságával és a hiba üzleti hatásával.
A GDPR ezt az elszámoltathatóságon keresztül kifejezetten megköveteli. Az Article 5 előírja, hogy a személyes adatokat jogszerűen, tisztességesen és átláthatóan kell kezelni, a szükséges mértékre kell korlátozni, csak a szükséges ideig szabad megőrizni, és megfelelő technikai és szervezési intézkedésekkel kell védeni. Az adatkezelőnek képesnek kell lennie a megfelelőség igazolására is. A GDPR Article 32 követelményeit nehéz bizonyítani anélkül, hogy ismert lenne, mely rendszerek kezelnek személyes adatokat, mely adatok magas kockázatúak vagy különleges kategóriájúak, hol tárolják őket, és mely védelmi intézkedések vonatkoznak rájuk.
A NIS2 magasabb szintre emeli az irányítási elvárásokat. Az Article 20 előírja, hogy az alapvető és fontos szervezetek vezető testületei hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék azok végrehajtását és képzésben részesüljenek. Az Article 21 megfelelő és arányos technikai, operatív és szervezési intézkedéseket ír elő, ideértve a kockázatelemzést, a biztonsági szabályzatokat, az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, a beszerzés és fejlesztés biztonságát, az eredményességértékelést, a kiberhigiéniát, a képzést, a kriptográfiát, a HR-biztonságot, a hozzáférés-szabályozást és az eszközkezelést. Az osztályozás nem különálló jelölőnégyzet ebben a felsorolásban. Ez az a döntési rendszer, amely arányossá teszi ezeket az intézkedéseket.
A DORA ugyanezt a logikát alkalmazza a pénzügyi szervezetekre és a fintech ökoszisztémákra. 2025. január 17. óta a DORA dokumentált IKT-kockázatkezelési keretrendszert, vezető testületi felelősséget, a bizalmasságra, sértetlenségre, rendelkezésre állásra és hitelességre vonatkozó szabályzatokat, incidensosztályozást, rezilienciatesztelést és IKT harmadik fél kockázatkezelést ír elő. A DORA hatálya alá tartozó pénzügyi szervezeteknél a DORA ágazatspecifikus uniós jogi aktusként kiválthatja az átfedő NIS2 kockázatkezelési és jelentéstételi kötelezettségeket, de a bizonyítási elvárás változatlan: be kell mutatni, hogyan azonosítják, védik, tesztelik, felügyelik és irányítják a kritikus információs és IKT-vagyonelemeket.
Az ISO/IEC 27001:2022 jól alkalmazható ennek a bizonyításnak az operációs rendszereként. A 4.1–4.4 pontok előírják, hogy a szervezet értse meg a belső és külső tényezőket, az érdekelt felek követelményeit, a szabályozási és szerződéses kötelezettségeket, valamint a más szervezetekkel fennálló interfészeket. A 6.1.1–6.1.3 pontok kockázatértékelést, kockázatkezelést, kontrollkiválasztást, alkalmazhatósági nyilatkozatot és megőrzött bizonyítékokat írnak elő. ISO/IEC 27001:2022
Ha a GDPR, a NIS2 és a DORA azt kérdezi: „Miért ezeket az intézkedéseket alkalmazták?”, az ISO/IEC 27001:2022 segít így válaszolni: „Mert ezek a vagyonelemek, adattípusok, kockázatok, kötelezettségek és kockázatkezelési döntések vezettek ide.”
Az osztályozás a kockázati döntés. A címkézés az operatív jelzés.
A Clarysec azért választja szét az osztályozást és a címkézést, mert az auditorok is így tesznek.
Az osztályozás annak eldöntése, hogy az információ mennyire érzékeny, értékes és kritikus. A címkézés ennek a döntésnek a láthatóvá, tartóssá és a napi működésben kikényszeríthetővé tétele.
A Clarysec Adatosztályozási és címkézési szabályzat – KKV egyértelműen rögzíti a célt:
Ez a szabályzat meghatározza, hogy a szervezet által kezelt valamennyi információt hogyan kell osztályozni és címkézni annak érdekében, hogy bizalmassága, sértetlensége és rendelkezésre állása az életciklusa során végig fennmaradjon.
Ugyanez az Adatosztályozási és címkézési szabályzat – KKV előírja a szervezetek számára, hogy:
Minden adatvagyont az érzékenysége szerint kell osztályozni, és ennek megfelelő címkével kell ellátni a megfelelő kezelés, tárolás és hozzáférés irányításához.
Vállalati környezetekben a Clarysec P13 Adatosztályozási és címkézési szabályzat meghatározza a minimális osztályozási modellt:
A szervezetnek egységes, egyértelműen meghatározott szintekkel rendelkező osztályozási sémát kell fenntartania. Legalább az alábbi osztályozási szinteket kell alkalmazni: 5.1.1 Public: Nyílt közzétételre és korlátozás nélküli terjesztésre szánt információ 5.1.2 Internal: Külső közzétételre nem szánt, nem nyilvános üzleti információ 5.1.3 Confidential: Szigorú hozzáférés-szabályozást igénylő érzékeny üzleti, szerződéses vagy ügyféladat 5.1.4 Restricted (or Highly Confidential): Kritikus vagy szabályozott információ, amelynek jogosulatlan közzététele jelentős kárt vagy jogi felelősséget eredményezhet
Ez a különbségtétel lényeges. A „Confidential” osztályozás titkosítást, szerepköralapú hozzáférést és szerződéses védelmi intézkedéseket tehet szükségessé. A „Restricted” osztályozás kiválthatja az MFA-t, a külső megosztás CISO általi jóváhagyását, a megerősített naplózást, a szigorúbb megőrzési irányítást, az elkülönítést és a kiemelt incidenseszkalációt.
A vállalati szabályzat egyértelmű az operatív címkézés tekintetében:
Valamennyi információs vagyonelemet olyan módon kell címkézni, amely: 6.2.1.1 Tartós: nem távolítható el vagy írható felül könnyen 6.2.1.2 Látható: a felhasználók számára a használat helyén egyértelmű 6.2.1.3 Géppel olvasható: ahol lehetséges, támogatni kell a metaadat-alapú címkézést
A géppel olvasható címkék jelentik azt a pontot, ahol a program tudatossági eszközből kikényszerítési mechanizmussá érik. Ha a címkék metaadat-alapúak, a felhőplatformok, DLP-rendszerek, e-mail átjárók, identitáskezelő eszközök, SIEM-szabályok, CASB-platformok és megőrzési motorok képesek ezek alapján intézkedni. Ha a címke csak egy dokumentumláblécben jelenik meg, segítheti a felhasználókat, de nagy léptékben nem képes megbízhatóan érvényesíteni a szabályokat.
Hol helyezkedik el az osztályozás a Clarysec ütemtervében
A Clarysec Zenith Blueprint: 30 lépéses auditori ütemterv az osztályozást a kockázatkezelési életciklus korai szakaszába helyezi, nem a technológiai bevezetés utánra. A kockázatkezelési fázis 9. lépése, „Vagyonelemek, fenyegetések és sérülékenységek azonosítása” arra irányítja a csapatokat, hogy vegyék nyilvántartásba az információs vagyonelemeket, és rögzítsék a tulajdonost, a helyet és az osztályozást.
Ez megelőz egy gyakori hibát: amikor van felhőleltár, de nincs információvagyon-leltár. Egy adatbázis, SaaS-bérlő vagy adattárház technológiai vagyonelem. A bennük található ügyfélrekordok, munkavállalói fájlok, fizetési naplók, modellképzési adatkészletek, támogatási átiratok és incidensbizonyítékok információs vagyonelemek. Az osztályozás ezen az információs szinten értelmezendő.
A Zenith Blueprint ISO/IEC 27002:2022 5.12, Az információ osztályozása kontrollra vonatkozó útmutatása így fogalmazza meg az alapelvet:
Minden valaha megírt információbiztonsági kontroll – hozzáférési korlátozás, titkosítás, biztonsági mentés, felügyelet vagy megsemmisítés – egy dolgot feltételez: a szervezet tudja, mit véd. Az 5.12 kontroll előírja, hogy az információt értéke, érzékenysége és kritikussága alapján kell osztályozni, megteremtve az IBIR valamennyi további döntésének alapját.
Az ISO/IEC 27002:2022 5.13, Az információ címkézése kontroll esetében ugyanez az ütemterv az osztályozást napi működéssé alakítja:
A címkézés az a módszer, amellyel az absztrakt szabályzat operatív valósággá válik. Ez az a pillanat, amikor a felhasználó egy dokumentumot, e-mailt, adatbázismezőt vagy nyomtatott jelentést látva azonnal meg tudja állapítani: mi ez az információ, mennyire érzékeny, és hogyan kell kezelni.
Az utolsó ütemtervi kapcsolat a 13. lépésben jelenik meg: „Kockázatkezelési tervezés és alkalmazhatósági nyilatkozat”. A Zenith Blueprint az SoA-t a kockázatok, kezelések és kontrollok közötti hídként írja le. Itt válik az osztályozás audit szempontból visszakövethetővé. Egy olyan kockázati forgatókönyv, mint az „ügyfél-pénzügyi adatok jogosulatlan közzététele megosztott felhőalapú tárolóból”, leképezhető osztályozásra, címkézésre, hozzáférés-szabályozásra, titkosításra, naplózásra, DLP-re, felhőhasználatra, beszállítói követelményekre és incidensreagálásra.
Az auditorok által elvárt kontrollkapcsolatok
A Clarysec Zenith Controls: keresztmegfelelőségi útmutató az ISO/IEC 27002:2022 5.12, Az információ osztályozása kontrollt a bizalmasságot, sértetlenséget és rendelkezésre állást támogató megelőző kontrollként térképezi fel. Az Identify kiberbiztonsági koncepcióhoz, az Információvédelem operatív képességhez, valamint a Védelem és védekezés biztonsági területeihez kapcsolja.
Az ISO/IEC 27002:2022 5.13, Az információ címkézése kontroll esetében a Zenith Controls a kontrollt megelőző jellegűként, a Protect fókuszterülethez kapcsolódóan térképezi fel, ugyanazokkal az információbiztonsági tulajdonságokkal és Információvédelem operatív képességgel.
A lényeges felismerés az, hogy az osztályozás és a címkézés nem elszigetelt kontrollok. Ezek teszik igazolhatóvá a környező kontrollokat.
| ISO/IEC 27002:2022 kontrollterület | Miért függ az osztályozástól vagy címkézéstől | Az auditor által kérhető bizonyíték |
|---|---|---|
| 5.9 Információk és kapcsolódó vagyonelemek nyilvántartása | Az osztályozási metaadatnak alapmezőnek kell lennie az eszköznyilvántartásban | Eszköznyilvántartás tulajdonossal, hellyel, életciklusállapottal és osztályozással |
| 5.12 Az információ osztályozása | Meghatározza az érzékenységet, értéket és kritikusságot | Jóváhagyott osztályozási rendszer, kritériumok, példák és felülvizsgálati bejegyzések |
| 5.13 Az információ címkézése | Láthatóvá és kikényszeríthetővé teszi az osztályozást | Címkekonfiguráció, mintaként címkézett fájlok, e-mail címkék, SaaS-címkék és felhasználói útmutató |
| 5.14 Információátadás | Meghatározza, hogy szükséges-e külső megosztás, titkosítás vagy jóváhagyás | Átadási szabályok osztályozás szerint, jóváhagyott csatornák és kivételi bejegyzések |
| 5.15 Hozzáférés-szabályozás | A hozzáférési jogosultságoknak az osztályozási határokat kell követniük | Szerepkörmátrix, hozzáférés-felülvizsgálatok, emelt jogosultságú hozzáférési szabályok és jóváhagyási előzmények |
| 5.25 Információbiztonsági események értékelése és döntés | Az incidens súlyossága részben az érintett adatok érzékenységétől függ | Incidensek előzetes értékelési szempontjai osztályozás és szolgáltatáskritikusság alapján |
| 5.34 A magánszféra és a PII védelme | A személyes adatok kategóriái adatvédelmi szempontú kezelést igényelnek | PII-nyilvántartás, jogalap-hozzárendelés, megőrzési szabályok és adatfeldolgozói kontrollok |
| 8.15 Naplózás | A Restricted adatokhoz való hozzáférés erősebb visszakövethetőséget igényel | Adathozzáférési naplók, naplómegőrzési beállítások és felülvizsgálati bizonyítékok |
| 8.16 Megfigyelési tevékenységek | A megfigyelés prioritása változik, ha Restricted adatot érintenek | SIEM használati esetek, riasztási küszöbértékek és eszkalációs bejegyzések |
A Zenith Controls az 5.12 kontrollt a GDPR Article 32 és Recital 83, a NIS2 Article 21(2)(a) és 21(2)(f), az ISO/IEC 27701 Annex B, a NIST SP 800-53 MP-3 és PM-11, a FIPS 199 és a NIST SP 800-60, valamint a COBIT 2019 DSS06.06 és APO13.01 követelményeihez térképezi. Az 5.13 kontrollt a GDPR Article 32, a NIS2 Article 21(2)(a) és 21(2)(f), a DORA Article 9(1) és 9(2), a NIST SP 800-53 MP-3 és a COBIT 2019 DSS06.06 követelményeihez rendeli.
Ez azt jelenti, hogy egyetlen bizonyítékkészlet több bizonyossági kérdésre is választ adhat.
| Megfelelési hajtóerő | Az osztályozás és címkézés hozzájárulása | Gyakorlati bizonyíték |
|---|---|---|
| GDPR Article 32 | Megmutatja, mely személyes adatok igényelnek bizalmassági, sértetlenségi, rendelkezésre állási és reziliencia-védelmi intézkedéseket | PII-osztályozás, titkosítási szabályok, hozzáférési korlátozások, megőrzési hozzárendelés és adatsértési triázs kritériumai |
| NIS2 Article 21 | Támogatja a kockázatelemzést, a biztonsági szabályzatokat, az eredményességértékelést, a hozzáférés-szabályozást, az eszközkezelést és az arányos intézkedéseket | Vezetés által jóváhagyott szabályzat, eszköznyilvántartás, képzés, felülvizsgálati mutatók és tesztelt kezelési szabályok |
| DORA IKT-kockázatkezelés | Támogatja az információs és IKT-vagyonelemek azonosítását és védelmét, az incidensosztályozást és az IKT harmadik fél kockázatot | IKT-eszköznyilvántartás, adatok kritikussága, beszállítói szerződéses követelmények, tesztelési hatókör és incidens-súlyossági kritériumok |
| NIST CSF 2.0 | Támogatja a GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND és RECOVER eredményeket | Aktuális és célprofilok osztályozási hiányosságokkal és priorizált helyesbítő intézkedésekkel |
| COBIT 2019 | Támogatja a biztonságra, adatkezelésre és kontrollműködésre vonatkozó irányítási és folyamatkontrollokat | Kontrollcélkitűzések, folyamatgazda, bizonyossági tesztelés és kivételkezelés |
Az eszköznyilvántartás az a pont, ahol az osztályozás bizonyítékká válik
Sok osztályozási program azért bukik el, mert az osztályozási rendszer csak a szabályzatban létezik. A Clarysec megközelítése az eszköznyilvántartással kezdődik.
A Clarysec P12 Eszközkezelési szabályzat előírja, hogy az eszköznyilvántartás minimális mezőként tartalmazza az osztályozási szintet:
Az eszköznyilvántartásnak legalább az alábbiakat kell tartalmaznia: 5.3.1 Eszközazonosító, kategória és típus 5.3.2 Sorozatszám vagy egyedi címke fizikai eszközök esetén 5.3.3 Szoftververzió vagy licenckulcs szoftvereszközök esetén 5.3.4 Eszközfelelős 5.3.5 Osztályozási szint (Public, Internal, Confidential, Restricted) 5.3.6 Hely (fizikai, virtuális, felhő) 5.3.7 Életciklusállapot (aktív, karbantartás alatt, kivont)
Ez közvetlenül illeszkedik az ISO/IEC 27001:2022 kockázattervezéshez. Ha nem azonosítható az információs vagyonelem, a tulajdonos, a hely és az osztályozás, akkor nem lehet következetesen értékelni a valószínűséget, a hatást, a kezelési prioritást vagy a maradványkockázatot. Az sem dönthető el magabiztosan, hogy egy beszállítói megállapodás, felhőszolgáltatás vagy SaaS-integráció érint-e szabályozott információt.
A GDPR szempontjából ez az elszámoltathatóságot támogatja. Az Article 30 szerinti adatkezelési tevékenységek nyilvántartása és az Article 32 szerinti biztonsági intézkedések hitelesebbé válnak, ha az eszköznyilvántartás azonosítja, hol kezelnek személyes adatokat és hogyan védik azokat. A DORA esetében ugyanez a nyilvántartás támogatja az IKT-vagyonelemek és szolgáltatások kritikusságát, a rezilienciatesztelés hatókörét és a harmadik fél függőségek elemzését. A NIS2 esetében a kockázatelemzést, a hozzáférés-szabályozást és az eszközkezelést támogatja.
| Mező | Példabejegyzés |
|---|---|
| Vagyonelem neve | Ügyfél-számlázási adatbázis |
| Eszközfelelős | Platformmérnökség vezetője |
| Üzleti folyamat | Előfizetéses számlázás és számlakibocsátás |
| Hely | EU-s felhőrégió, menedzselt adatbázis-szolgáltatás |
| Osztályozás | Restricted |
| Adatkategóriák | Ügyfélazonosítók, számlázási kapcsolattartási adatok, tranzakciós hivatkozások |
| GDPR-relevancia | Személyes adatok, adatkezelői és adatfeldolgozói kontextusok |
| Kritikusság | Támogatja a bevételi műveleteket és az ügyfélszolgálatot |
| Fő kontrollok | MFA, titkosítás tárolt adatok esetén, titkosítás továbbított adatok esetén, emelt jogosultságú hozzáférés jóváhagyása, auditnaplózás, biztonsági mentések tesztelése |
| Beszállítói függőség | Felhőalapú adatbázis-szolgáltató, fizetésfeldolgozó |
| Felülvizsgálati gyakoriság | Negyedéves hozzáférés-felülvizsgálat, éves osztályozási felülvizsgálat, felülvizsgálat rendszerváltozáskor |
Az ilyen bejegyzés megváltoztatja az audit hangnemét. Ahelyett, hogy a szervezet azt mondaná: „úgy véljük, az érzékeny adatok védettek”, meg tudja mutatni, mi az adat, ki a tulajdonosa, miért Restricted, mely kontrollok vonatkoznak rá, és mikor vizsgálták felül utoljára ezeket a kontrollokat.
A címkéknek kell vezérelniük a felhő- és SaaS-kezelési szabályokat
A legtöbb érzékeny adat ma felhőplatformokon, SaaS-alkalmazásokon, analitikai pipeline-okon és együttműködési eszközökön keresztül mozog. Nem elegendő egy olyan szabályzat, amely azt mondja a felhasználóknak, hogy „kezeljék körültekintően a bizalmas adatokat”.
A Clarysec P27 Felhőszolgáltatások használatára vonatkozó szabályzat közvetlenül összekapcsolja a felhőhasználatot az osztályozással és az adattárolás földrajzi helyével:
Adatosztályozás és adattárolás földrajzi helye 6.6.1 Nem vihető adat felhőplatformra a Data Classification and Labeling Policy (P13) szerinti osztályozás nélkül. 6.6.2 Az adattárolás földrajzi helyére vonatkozó követelményeket szerződésben kell érvényesíteni (pl. kizárólag EU-n belüli tárolás GDPR által szabályozott adatok esetén). 6.6.3 A határokon átnyúló adattovábbításoknak meg kell felelniük a GDPR Chapter V követelményeinek, valamint adott esetben a DORA Article 28 előírásainak.
Ez azért fontos, mert a felhőkockázat gyakran a kényelemből ered. Egy csapat adatkészletet exportál egy új analitikai eszközbe. Az értékesítés ügyféllistákat szinkronizál egy automatizálási platformra. Egy fejlesztő éles adatokat másol tesztkörnyezetbe. Osztályozás és címkézés nélkül ezek a műveletek nem feltétlenül váltanak ki jogi felülvizsgálatot, biztonsági jóváhagyást vagy beszállítói ellenőrzéseket.
Az Adatosztályozási és címkézési szabályzat – KKV egyszerű bevezetési mintát ad a kisebb szervezeteknek:
A megosztott mappáknak vagy felhőmeghajtóknak mappanevekkel vagy címkékkel kell jelezniük az osztályozást (pl. „/Clients_Confidential”).
Érettebb környezetekben a mappaneveket géppel olvasható címkékkel, feltételes hozzáférési szabályokkal, külső megosztási blokkolással, titkosítással, megőrzési címkékkel, DLP-szabályokkal és naplózással kell kiegészíteni. A cél nem pusztán az információ címkézése. A cél az, hogy a címke alapján intézkedni lehessen.
Egy „Restricted” címke kiválthat külső megosztási blokkolást, titkosítást tárolt és továbbított adatok esetén, MFA-t, letöltési korlátozásokat nem felügyelt eszközökön, auditnapló-megőrzést, SIEM-riasztásokat, megőrzési szabályokat, beszállítói helykorlátozásokat és incidens-súlyossági eszkalációt.
A P13 Adatosztályozási és címkézési szabályzat rögzíti az alapkövetelményt:
Az információk minden adatkezelésének, továbbításának, hozzáférésének, tárolásának és megsemmisítésének összhangban kell lennie az osztályozási szinttel. Legalább: 6.3.1.1 Public: Szabadon közzétehető; különleges kezelés nem szükséges 6.3.1.2 Internal: A szervezeten belül megosztható; biztonságos belső rendszerekben tárolandó 6.3.1.3 Confidential: 6.3.1.3.1 A hozzáférés kizárólag jogosult személyekre korlátozott 6.3.1.3.2 Továbbított és tárolt adatok esetén titkosítani kell 6.3.1.3.3 Külső féllel csak NDA vagy egyenértékű szerződéses védelmi intézkedések mellett osztható meg 6.3.1.4 Restricted: 6.3.1.4.1 A legmagasabb biztonsági követelmények alkalmazandók 6.3.1.4.2 Erős hozzáférés-szabályozás, többtényezős hitelesítés (MFA) és auditnaplózás szükséges 6.3.1.4.3 Fizikai és logikai elkülönítés, ahol megvalósítható 6.3.1.4.4 Külső megosztás CISO-jóváhagyás nélkül tilos
Minden címkéhez viselkedés tartozik. Minden viselkedéshez kontroll tartozik. Minden kontrollhoz bizonyíték tartozik.
Gyakorlati kikényszerítési példa
Vegyünk egy fintech elemzőt, aki létrehozza a Q3_2026_Customer_Churn_Analysis.xlsx fájlt. A táblázat ügyfélazonosítókat, tranzakciós volumeneket és prediktív lemorzsolódási pontszámokat tartalmaz.
Az elemző Confidential kategóriába sorolja, mert ügyféladatokat és stratégiai elemzést tartalmaz. A vállalat információvédelmi eszközével az elemző alkalmazza a Confidential címkét. Mivel a címke tartós, látható és géppel olvasható, a kontrollok automatikusan aktiválódnak.
A fájl titkosított a készüléken és a felhőalapú tárolásban is. Egy látható fejléc Confidential jelöléssel látja el. Amikor az elemző megpróbálja személyes felhőmeghajtóra szinkronizálni, egy DLP-szabály blokkolja a műveletet és naplózza a kísérletet. Amikor az elemző megpróbálja elküldeni egy külső, nem partner domainre, az e-mail átjáró karanténba helyezi az üzenetet és riasztja a biztonsági üzemeltetést. Ha a fájlt később Restricted kategóriába sorolják át, mert szabályozott pénzügyi tranzakciós adatokat tartalmaz, a külső megosztás letiltásra kerül, kivéve, ha az információbiztonsági vezető vagy az adatgazda jóváhagyja a kivételt.
Ez az a bizonyíték, amelyet a vezérigazgató keresett. Visszakövethető, automatizált, és igazgatóság által jóváhagyott szabályzathoz kapcsolódik. Összhangban van a P27 Felhőszolgáltatások használatára vonatkozó szabályzattal is, mert osztályozás nélkül nem engedélyezett adatmozgás a felhőbe, és a határokon átnyúló adattovábbításoknak meg kell felelniük a GDPR Chapter V követelményeinek, valamint adott esetben a DORA Article 28 előírásainak.
Osztályozás–kontroll mátrix kialakítása egy hét alatt
Egy teljes program időt igényel, de egy fókuszált sprint létrehozhatja a bizonyítékgerincet egy audit, ügyfél-felülvizsgálat vagy szabályozói értékelés előtt.
1. nap: Az osztályozási rendszer megerősítése
Induljon négy szinttel: Public, Internal, Confidential és Restricted. Alapként használja a P13 Adatosztályozási és címkézési szabályzatot. Határozza meg a kritériumokat üzleti hatás, jogi hatás, szerződéses érzékenység, személyesadat-kockázat, szolgáltatáskritikusság és pénzügyi kár alapján.
| Osztályozás | Tipikus példák | Kockázati logika |
|---|---|---|
| Public | Jóváhagyott marketingtartalom, sajtóközlemények, álláshirdetések | Korlátozás nélküli terjesztésre szánt |
| Internal | Belső eljárások, projektjegyzetek, belső közlemények | Nem nyilvános üzleti információ |
| Confidential | Ügyfélszerződések, HR-fájlok, nem nyilvános pénzügyi jelentések | Érzékeny üzleti, szerződéses vagy ügyféladat |
| Restricted | Különleges kategóriájú személyes adatok, fizetési adatok, hitelesítési titkok, éles ügyféladatbázisok | Jelentős jogi vagy üzleti hatású kritikus vagy szabályozott információ |
2. nap: Tíz kritikus információs vagyonelem kiválasztása
Használja a Zenith Blueprint 9. lépését. Vegyen fel ügyféladatbázist, támogatási jegyrendszert, HR-platformot, identitásszolgáltatót, fizetési exportot, adattárházat, objektumtároló bucketet, igazgatósági jelentési mappát, forráskód-adattárat és incidensbizonyíték-adattárat. Rögzítse a tulajdonost, a helyet, az osztályozást és a GDPR-relevanciát.
3. nap: Kezelési szabályok hozzárendelése
Határozza meg a hozzáférésre, tárolásra, továbbításra, megfigyelésre és megsemmisítésre vonatkozó kezelési követelményeket.
| Osztályozás | Hozzáférés | Tárolás | Továbbítás | Megfigyelés | Megsemmisítés |
|---|---|---|---|---|---|
| Public | Nyílt vagy jóváhagyott közzétételi szerepkörök | Jóváhagyott nyilvános csatornák | Jóváhagyás után nincs külön korlátozás | Alapszintű sértetlenségi megfigyelés | Standard törlés |
| Internal | Munkavállalók és jóváhagyott vállalkozók | Felügyelt rendszerek | Belső csatornák | Standard hozzáférési naplók | Standard megőrzési ütemterv |
| Confidential | Szükséges ismeret elve szerinti hozzáférés | Jóváhagyott biztonságos adattárak | Titkosítás és NDA vagy szerződéses védelmi intézkedések | Hozzáférési felülvizsgálat és DLP-riasztások | Biztonságos törlés |
| Restricted | Legkisebb jogosultság elve MFA-val és tulajdonosi jóváhagyással | Elkülönített vagy megerősített rendszerek | Külső megosztás jóváhagyás nélkül tilos | Megerősített auditnaplózás és SIEM-riasztás | Ellenőrzött biztonságos megsemmisítés |
4. nap: Egy technikai kikényszerítési út konfigurálása
Válasszon egy platformot, például felhőalapú dokumentumtárat, e-mail rendszert vagy objektumtároló szolgáltatást. Vezessen be látható és géppel olvasható címkéket. Konfiguráljon egy szabályt Confidential adatokra és egyet Restricted adatokra. Például írjon elő titkosítást Confidential külső e-mailek esetén, és blokkolja a Restricted fájlok külső megosztását.
5. nap: A kockázati nyilvántartás és az SoA frissítése
Használja a Zenith Blueprint 13. lépését. Adja hozzá az osztályozási és címkézési kontrollokat az alkalmazhatósági nyilatkozathoz. Kapcsolja őket olyan kockázatokhoz, mint a jogosulatlan közzététel, a felhő hibás konfigurációja, a beszállítói túlzott kitettség, az adatmegőrzési hiba és az incidensek aluljelentése.
6. nap: A kontroll tesztelése
Hozzon létre egy Restricted címkével ellátott tesztfájlt. Próbálja meg külső féllel megosztani nem felügyelt eszközről. Ellenőrizze, hogy az eszköz blokkol, figyelmeztet, naplóz vagy eszkalál-e. Rögzítsen képernyőképeket, naplóbejegyzéseket és jegybizonyítékokat. Ha a kontroll hibásan működik, rögzítse a kivételt és a helyesbítő intézkedési tervet.
7. nap: Az első védelmi vonal felhasználóinak képzése
A képzésnek szerepkör-alapúnak kell lennie. A fejlesztőknek tudniuk kell, mikor nem használható éles adat tesztkörnyezetben. A HR-nek értenie kell, miért Confidential vagy Restricted besorolásúak a munkavállalói fájlok. Az értékesítésnek tudnia kell, miért nem tölthetők fel ügyfélexportok nem engedélyezett SaaS-eszközökbe. A felsővezetőknek érteniük kell, miért igényelnek erősebb kezelést az igazgatósági anyagok, akvizíciós fájlok és befektetői adatok.
Ez a sprint nem fejezi be a teljes programot, de létrehozza a bizonyítékgerincet: szabályzat, nyilvántartás, címkék, kezelési szabályok, technikai kikényszerítés, kockázati visszakövethetőség és képzés.
Hogyan tesztelik az auditorok az osztályozást és a címkézést
Az auditorok ritkán tesztelik az osztályozást önmagában. Követik az adat útját.
Egy ISO/IEC 27001:2022 auditor az osztályozást az IBIR alkalmazási területéhez, az érdekelt felek követelményeihez, a jogi és szerződéses kötelezettségekhez, a kockázatértékeléshez és az alkalmazhatósági nyilatkozathoz kapcsolja. Bizonyítékot vár az ISO/IEC 27002:2022 5.9, 5.12, 5.13, 5.14, 5.15, 5.34 kontrollokra és a releváns technikai kontrollokra. Tipikus bizonyítékok: jóváhagyott szabályzatok, eszköznyilvántartási bejegyzések, kockázati nyilvántartási bejegyzések, címkézett minták, kezelési szabályok, hozzáférés-felülvizsgálatok, belső auditmegállapítások és helyesbítő intézkedések.
Egy GDPR-felülvizsgáló a személyes adatokra összpontosít. Azt fogja kérdezni, azonosították-e a személyes adatokat, elkülönítik-e a különleges kategóriájú adatokat, a megőrzési szabályok összhangban vannak-e a céllal, és megfelelőek-e az Article 32 szerinti biztonsági intézkedések. Az osztályozás segít elkülöníteni a hétköznapi üzleti információkat a személyes adatoktól, az érzékeny személyes adatoktól, a bizalmas ügyféladatoktól és a szabályozott nyilvántartásoktól. A címkézés segít az operatív csapatoknak elkerülni a véletlen közzétételt, a túlzott megőrzést és a jogosulatlan továbbítást.
Egy NIST CSF 2.0 értékelő várhatóan a GOVERN, IDENTIFY és PROTECT funkciók alatt fogja értelmezni az osztályozást. Kérdezheti, hogy az aktuális és célprofilok meghatározzák-e az érzékeny adatok feltárását, működik-e a címkék kikényszerítése SaaS- és felhőrendszerek között, a beszállítók osztályozás szerint kezelik-e az adatokat, és az érzékenység alapján módosulnak-e a megfigyelési prioritások.
Egy COBIT 2019 vagy ISACA jellegű auditor az irányítási célkitűzésekre, a folyamatgazdára, a kontrolltervezésre és a működési hatékonyságra helyezi a hangsúlyt. A Zenith Controls az 5.9 nyilvántartási kontrollt a COBIT 2019 BAI09.01, BAI09.02 és DSS05.04 célkitűzéseihez térképezi, és hivatkozik az ISACA ITAF 2204 és 2301 dokumentumokra. Az osztályozás esetében a Zenith Controls az 5.12 kontrollt a COBIT 2019 DSS06.06 és APO13.01 célkitűzéseihez rendeli, míg a címkézést a DSS06.06 célkitűzéshez. Az auditor azt fogja kérdezni, ki a folyamatgazda, hogyan hagyják jóvá a kivételeket, monitorozzák-e a teljesítményt, és kap-e a vezetés jelentést.
Egy DORA-központú felülvizsgáló azt fogja kérdezni, mely információs vagyonelemek támogatnak kritikus vagy fontos funkciókat, mely adatok Restricted besorolásúak, mely IKT harmadik fél szolgáltatók tárolják vagy továbbítják ezeket az adatokat, a szerződések meghatározzák-e a helyeket és a biztonsági intézkedéseket, a tesztelés hatóköre kiterjed-e a kritikus adatokra, és az incidenseket részben az adatok elvesztése alapján osztályozzák-e a rendelkezésre állás, hitelesség, sértetlenség és bizalmasság mentén.
Ha a válaszok egyetlen, osztályozásvezérelt eszköz- és beszállítói bizonyítékmodellből származnak, az auditok gyorsabbak, következetesebbek és jobban igazolhatók.
Gyakori hibaminták
Az osztályozási hibák jellemzően abból erednek, hogy a szervezetek a címkéket tudatossági eszközként kezelik, nem kontrolljelzésként.
Először dokumentumokat osztályoznak, de adatbázisokat, alkalmazásprogramozási interfészeket, naplókat, biztonsági mentéseket, exportokat vagy SaaS-nyilvántartásokat nem. Egy hibakeresési naplóban lévő érzékeny adat ugyanolyan kárt okozhat, mint egy táblázatban lévő érzékeny adat.
Másodszor címkézik az információt, de nem kapcsolják össze a címkéket a hozzáférés-szabályozással. Egy Restricted címke nyílt hozzáférés mellett azt bizonyítja, hogy a szervezet ismerte az érzékenységet, de nem érvényesítette a kezelési szabályt.
Harmadszor a felhőmigrációk az osztályozás előtt történnek. A csapatok új SaaS-eszközökbe mozgatnak adatokat anélkül, hogy megerősítenék az adattárolás földrajzi helyét, a beszállítói feltételeket, az al-adatfeldolgozói hozzáférést, a határokon átnyúló adattovábbítási követelményeket vagy a törlési jogokat. A P27 Felhőszolgáltatások használatára vonatkozó szabályzat ezt közvetlenül kezeli azzal, hogy osztályozás nélkül tiltja az adatok felhőplatformokra mozgatását.
Negyedszer az incidensreagálási tervek figyelmen kívül hagyják az osztályozást. Ha a súlyossági kritériumok nem tartalmazzák az adatok érzékenységét, az incidenskezelő csapatok válsághelyzetben időt veszítenek annak feltárásával, mi érintett. A GDPR adatsértési elemzés, a NIS2 incidenskezelés és a DORA incidensosztályozás egyaránt profitál a gyors adatkontextusból.
Ötödször az SoA nem magyarázza el, miért alkalmazhatók az osztályozási és címkézési kontrollok. Lehet, hogy a szervezet bevezetett címkéket, de az SoA nem kapcsolja azokat a GDPR Article 32, a NIS2 Article 21, a DORA IKT-kockázat, az ügyfélszerződések vagy konkrét kockázati forgatókönyvek követelményeihez.
Vezetői jelentéstétel: tegye láthatóvá az osztályozást
A NIS2 és a DORA a kiberbiztonságot vezetői elszámoltathatósági kérdéssé teszi. Az ISO/IEC 27001:2022 is vezetői elkötelezettséget, szabályzati összhangot, erőforrásokat, szerepköröket és teljesítményjelentést ír elő. Az osztályozási mutatóknak ezért el kell jutniuk a vezetőségi felülvizsgálatra.
Hasznos mutatók többek között:
- A kijelölt tulajdonossal rendelkező kritikus információs vagyonelemek százalékos aránya.
- A jóváhagyott osztályozással rendelkező vagyonelemek százalékos aránya.
- A megerősített naplózás nélküli Restricted vagyonelemek száma.
- A külső megosztással rendelkező Confidential vagy Restricted adattárak száma.
- Azon beszállítók százalékos aránya, amelyek Confidential vagy Restricted adatokat kezelnek, és aktualizált szerződéses záradékokkal rendelkeznek.
- Az osztályozási kivételek és lejárt határidejű helyesbítő intézkedések száma.
- DLP-incidensek címke szerint.
- A Restricted vagyonelemek hozzáférés-felülvizsgálatának teljesítése.
- A GDPR által szabályozott adatok felhőalapú tárolási helyei.
- Osztályozásalapú súlyossági kritériumokat használó incidensreagálási gyakorlatok.
Ezek a mutatók támogatják az ISO/IEC 27001:2022 vezetőségi felülvizsgálatot, a NIS2 vezetői felügyeletet, a DORA irányítási jelentéstételt és az ügyfélbizonyosságot. Az osztályozást a felsővezetők számára is érthetővé teszik. A vezetés gyorsabban tud intézkedni, ha látja, hogy több Restricted adattár nem rendelkezik tesztelt helyreállítással, vagy hogy kritikus beszállítók EU-s tárolás megerősítése nélkül kezelnek ügyféladatokat.
A szabályzattól a bizonyítékig
A Clarysec bevezetési mintája bizonyítékközpontú:
- Határozza meg az osztályozási rendszert a P13 Adatosztályozási és címkézési szabályzatban, vagy induljon az Adatosztályozási és címkézési szabályzat – KKV alapján.
- Adja hozzá az osztályozást az eszköznyilvántartáshoz a P12 Eszközkezelési szabályzat használatával.
- Alkalmazza a felhőkorlátozásokat és az adattárolás földrajzi helyére vonatkozó követelményeket a P27 Felhőszolgáltatások használatára vonatkozó szabályzat alapján.
- Használja a Zenith Blueprint 9. lépését az információs vagyonelemek, tulajdonosok, helyek és érzékenység azonosítására.
- Használja a Zenith Blueprint 13. lépését a kockázatok kontrollokhoz rendelésére az SoA-ban.
- Használja a Zenith Blueprint 22. lépését az ISO/IEC 27002:2022 5.12 és 5.13 kontrollok napi működésben történő bevezetésére.
- Használja a Zenith Controls útmutatót ugyanazon bizonyítékok GDPR, NIS2, DORA, NIST CSF, COBIT 2019 és támogató szabványok szerinti megfeleltetésére.
- Tesztelje a címkék kikényszerítését, a hozzáférési korlátozásokat, a naplózást, a DLP-t és az incidensek előzetes értékelését.
- Jelentse az osztályozási teljesítményt a vezetésnek.
- Vizsgálja felül az osztályozást jelentős rendszer-, folyamat-, beszállítói vagy szabályozói változás után.
Ez azért működik, mert az osztályozás közös nyelvvé válik az üzleti érték, a jogi kötelezettség, a technikai kontroll és az auditbizonyíték között.
Ha szervezete ISO/IEC 27001:2022 tanúsításra, GDPR-bizonyosságra, NIS2-felkészültségre, DORA ügyfél-átvilágításra vagy kombinált megfelelőségi auditra készül, kezdje egyetlen kérdéssel:
Meg tudja mutatni minden kritikus információs vagyonelemnél, hogy mi az, ki a tulajdonosa, hol található, hogyan van osztályozva, hogyan van címkézve, ki férhet hozzá, hogyan védett, meddig őrzik meg, mely beszállító érinti, és mi történik, ha kitettségbe kerül?
Ha a válasz még nem, a Clarysec segíthet gyorsan és igazolható módon felépíteni a bizonyítékláncot.
Használja az Adatosztályozási és címkézési szabályzat – KKV, a P13 Adatosztályozási és címkézési szabályzat, a P12 Eszközkezelési szabályzat, a P27 Felhőszolgáltatások használatára vonatkozó szabályzat, a Zenith Blueprint: 30 lépéses auditori ütemterv és a Zenith Controls: keresztmegfelelőségi útmutató anyagokat annak érdekében, hogy az osztályozás statikus szabályzatból operatív kontrollréteggé váljon a GDPR Article 32, a NIS2 kiberkockázat-kezelés és a DORA IKT-kockázati bizonyítékok támogatására.
Az adatok osztályozásának legjobb időpontja az auditkérelem érkezése előtt lett volna. A következő legjobb időpont a következő felhőmigráció, új beszállítók bevonása, ügyfélkérdőív vagy incidens előtt van.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
