PII-hozzáférés-irányítás ISO 27701:2025 és GDPR szerint

A külső auditor kérdése a levegőben maradt, megtévesztően egyszerűen.

„Meg tudja mutatni az elmúlt negyedévre vonatkozó hozzáférés-felülvizsgálati naplót a támogatási csapat éles környezetben kezelt PII-hez való hozzáféréséről?”

Anya, a Medtelligence információbiztonsági vezetője számára ez volt az igazság pillanata. A Medtelligence gyorsan növekvő egészségtechnológiai SaaS-szolgáltató, amely kórházak PII-adatfeldolgozójaként működik, és érzékeny betegadatokat kezel felhőplatformon. A vállalat erős hitelesítéssel, meghatározott szerepkörökkel és érett mérnöki csapattal rendelkezett. Az auditor azonban nem azt kérdezte, hogy létezik-e bejelentkezési oldal. Azt kérte bizonyítani, hogy a személyes adatokhoz való hozzáférés időben folyamatos irányítás alatt állt.

Azt akarta látni, ki férhetett hozzá az éles környezetben kezelt PII-hez, miért volt hozzáférése, mikor hagyták jóvá, szükség volt-e még rá, naplózták-e a támogatási tevékenységet, és eltávolították-e a szükségtelen jogosultságokat.

Anya megnyitotta az IAM-konzolt. Voltak benne támogatási mérnökök, adatbázis-adminisztrátorok, egy integrációs szolgáltatásfiók, egy menedzselt szolgáltató, két vészhelyzeti (break-glass) szerepkör, valamint egy volt alvállalkozó, aki még mindig szerepelt egy csoportban, mert a kiléptetési jegyet lezárták, mielőtt a jogosultságot eltávolították volna. A HR adatai szerint az érintett hat hete távozott. A hozzáférés-felülvizsgálati táblázatban ez állt: „Függőben”. A SIEM-ben voltak naplók, de senki sem térképezte fel, mely események bizonyítják a PII-hez való hozzáférést.

Itt válik valósággá az adatvédelmi irányítás.

A GDPR szerint a személyes adatokat sértetlenséggel és bizalmassággal kell kezelni, és megfelelő technikai és szervezési intézkedésekkel kell védeni a jogosulatlan vagy jogellenes adatkezeléssel, a véletlen elvesztéssel, megsemmisüléssel vagy károsodással szemben. A GDPR az elszámoltathatóságot is egyértelművé teszi: az adatkezelőnek képesnek kell lennie a megfelelés igazolására. Az ISO/IEC 27701:2025 ezt az elszámoltathatóságot adatvédelmi információkezelési rendszerré, azaz PIMS-vé alakítja, ahol a PII-hez való hozzáférés már nem technikai utógondolat. Irányított életciklussá válik szerepkörök, adatfeldolgozók, felhőplatformok, munkavállalók, emelt jogosultságú rendszergazdák, naplók, felülvizsgálatok, szerződések és bizonyítékok mentén.

Sok szervezetnél nem az a hiányosság, hogy nincs hozzáférés-szabályozás. A hiányosság az, hogy nem tudják következetesen bizonyítani a PII-hozzáférés irányítását ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 és COBIT 2019 szerint.

A PII-hozzáférés-irányítás nem csupán IAM

Egy hagyományos IAM-program azt kérdezi: „A megfelelő felhasználók férnek hozzá a megfelelő rendszerekhez?”

Egy érett, ISO/IEC 27701:2025 szerinti PIMS nehezebb kérdéseket tesz fel:

• Mely rendszerek kezelnek PII-t?
• Mely szerepköröknek kell hozzáférniük a PII mely kategóriáihoz?
• A szervezet PII-adatkezelőként, adatfeldolgozóként, közös adatkezelőként vagy al-adatfeldolgozóként jár el?
• A hozzáférés célhoz, dokumentált üzleti igényhez és a legkisebb jogosultság elvéhez kötött?
• Az emelt jogosultságú műveleteket naplózzák és felülvizsgálják?
• A szervezet bizonyítani tudja, hogy az adatfeldolgozói és al-adatfeldolgozói hozzáférést szerződés szabályozza?
• A felhőalapú támogatási útvonalak, a bérlői elkülönítés, az exportok és az adminisztratív műveletek szerepelnek a bizonyítékok között?
• A hozzáférési döntéseket felülvizsgálják beléptetés, szerepkörváltozás, incidens, kiléptetés és lényeges rendszerváltozás után?

Ezért a PII-biztonság és a hozzáférés-szabályozás irányítása természetes híd az ISO/IEC 27701:2025 és a GDPR között. A GDPR adja a jogi elszámoltathatósági keretet. Az ISO/IEC 27701:2025 működési gyakorlattá alakítja az adatvédelmi irányítást az adatkezelők és az adatfeldolgozók számára. Az ISO/IEC 27001:2022 biztosítja az ISMS kockázatkezelési motorját. Az ISO/IEC 27002:2022 adja a kontrollarchitektúrát, beleértve a PII adatvédelmét és védelmét, a hozzáférés-szabályozást, a hozzáférési jogosultságokat, a naplózást, a felhőszolgáltatásokat, a beszállítói kapcsolatokat, az osztályozást, a törlést, a maszkolást és a kriptográfiát.

A Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap ezt a Controls in Action szakaszba helyezi. A 23. lépésben, amely az 5.19–5.37 szervezeti kontrollokat fedi le, az ISO/IEC 27002:2022 5.34 kontrollját, a PII adatvédelmét és védelmét bizalmi kérdésként írja le, nem pusztán adatkezelési kérdésként:

a személyazonosításra alkalmas információ nem csupán egy újabb adattípus, hanem a bizalom rendkívül érzékeny megjelenése. Nevek, címek, azonosítók, egészségügyi nyilvántartások, pénzügyi adatok – ezek az adatok valódi emberekről mesélnek történetet.

Ugyanez a rész adja a gyakorlati alapot: az adatvédelem az adatok ismeretével kezdődik. A szervezetnek tudnia kell, milyen PII-t gyűjt, hol található, miért kezeli, és ki férhet hozzá.

A PII-hozzáférés-szabályozás mögötti megfelelési nyomás

A PII-hozzáférés-irányítás már nem egyetlen keretrendszer kérdése. A Medtelligence-hez hasonló szervezetek az adatvédelmi szabályozás, a kiberbiztonsági jogszabályok, az operatív reziliencia, az ügyfélbizonyosság és a biztonsági tanúsítás metszéspontjában működnek.

A GDPR Article 5 előírja, hogy a személyes adatokat jogszerűen, tisztességesen, átláthatóan, célhoz kötötten, adattakarékosan, pontosan, korlátozott ideig, sértetlenséggel és bizalmassággal kell kezelni. Az Article 5(2) bevezeti az elszámoltathatóságot: az adatkezelő felelős a megfelelésért, és képesnek kell lennie annak igazolására. Az Article 32 megfelelő technikai és szervezési intézkedéseket ír elő az adatkezelés biztonságához.

A NIS2 Article 21 előírja, hogy az alapvető és fontos szervezetek megfelelő és arányos technikai, operatív és szervezési kiberbiztonsági kockázatkezelési intézkedéseket tegyenek. Minimális területei közé tartozik a kockázatelemzés, a biztonsági szabályzatok, az incidenskezelés, az üzletmenet-folytonosság, az ellátási lánc biztonsága, a biztonságos beszerzés és fejlesztés, az eredményesség értékelése, a kiberhigiénia és képzés, a kriptográfia, a HR-biztonság, a hozzáférés-szabályozás, az eszközkezelés, valamint adott esetben a többtényezős vagy folyamatos hitelesítés és a biztonságos kommunikáció. Az Article 20 a vezető testületekre telepíti a kiberbiztonsági kockázatkezelési intézkedések jóváhagyásának és felügyeletének felelősségét.

A DORA 2025. január 17-től a pénzügyi szervezetek széles körére alkalmazandó, és ágazatspecifikus operatívreziliencia-rendszert hoz létre. Lefedi az IKT-kockázatkezelést, a jelentős IKT-val kapcsolatos incidensek bejelentését, a digitális működési reziliencia tesztelését, az információmegosztást, az IKT harmadik fél kockázatot, valamint az IKT harmadik fél szolgáltatókkal kötött szerződéses megállapodásokat. A pénzügyi szervezetek és az őket támogató IKT-szolgáltatók számára a hozzáférés-szabályozás nem kizárólag adatvédelmi kérdés. Az operatív reziliencia része.

Az ISO/IEC 27001:2022 ezeket a kötelezettségeket kockázatalapú irányítási rendszerbe kapcsolja. A 6.1.1–6.1.3 pontok előírják, hogy a szervezetek kezeljék a kockázatokat és lehetőségeket, határozzanak meg információbiztonsági kockázatértékelési folyamatot, azonosítsák a bizalmasságot, sértetlenséget és rendelkezésre állást érintő kockázatokat, értékeljék a kockázatokat, válasszanak kezelési opciókat, határozzanak meg kontrollokat, vessék össze a kiválasztott kontrollokat az A melléklettel, dokumentálják az alkalmazhatósági nyilatkozatot, szerezzék be a kockázatgazda jóváhagyását, és fogadtassák el a maradványkockázatokat. A 8.2 és 8.3 pontok kockázatértékeléseket írnak elő tervezett időközönként vagy jelentős változást követően, valamint a kockázatkezelési terv végrehajtását dokumentált eredményekkel.

A PII-irányítás szempontjából ez azt jelenti, hogy a hozzáférés-szabályozás nem elszigetelt IAM-beállítás. Kockázatkezelési döntés. A bérnyilvántartások, betegadatok, fizetési adatok, személyazonosító okmányok, helyadatok vagy ügyféltámogatási átiratok exportálására képes szerepkört indokolni kell a kockázati nyilvántartásban, tükrözni kell az alkalmazhatósági nyilatkozatban, érvényesíteni kell az IAM-ben, naplózni kell éles környezetben, időszakosan felül kell vizsgálni, és el kell távolítani, ha már nem szükséges.

A Clarysec kontrollmodellje: adatvédelmi ígérettől bizonyítékig

A Clarysec a PII-hozzáférés-irányítást bizonyítékláncként kezeli. A lánc az adatnyilvántartással és a szerepkörök meghatározásával kezdődik, a hozzáférések jóváhagyásán és kikényszerítésén át halad, majd a felügyelettel, felülvizsgálattal, hozzáférés-visszavonással és auditálló nyilvántartásokkal zárul.

A Zenith Controls: The Cross-Compliance Guide szerint a téma elsősorban három ISO/IEC 27002:2022 kontroll köré szerveződik:

Az auditorok ritkán fogadják el bizonyítékként azt, hogy „IAM-et használunk”. Azt várják, hogy lássák, miként kapcsolódnak az IAM-döntések az adatvédelmi kötelezettségekhez, a rendszertulajdonosi felelősséghez, az adatosztályozáshoz, az üzleti igényhez, a kockázatkezeléshez, a hozzáférés-felülvizsgálat gyakoriságához, a naplózási hatókörhöz és a beszállítói szerződésekhez.

A Clarysec PII Security and Access Control Policy PIMS-nyelven határozza meg az alapkövetelményt:

[Both] A rendszertulajdonosnak / alkalmazástulajdonosnak a PII-hez való hozzáférést jóváhagyott szerepkörökre és engedélyezett felhasználókra KELL korlátoznia, akiket a hozzáférés engedélyezése előtt a REG02-ben vagy REG12-ben rögzítettek, vagy azokban visszakövethetők.

A „4.2 Access control baseline” szakasz 4.2.1 szabályzati pontjából.

A „[Both]” címke azt jelenti, hogy a kontroll akkor is alkalmazandó, ha a szervezet PII-adatkezelőként, és akkor is, ha PII-adatfeldolgozóként jár el. Ez a különbségtétel lényeges. Az adatkezelők gyakran elmulasztják a célhoz kötött hozzáférési szabályok meghatározását. Az adatfeldolgozók gyakran nem tudják bizonyítani, hogy a hozzáférés ügyfélutasításokra, jóváhagyott támogatási útvonalakra és szerződésben engedélyezett személyekre korlátozódik.

Ugyanez a szabályzat magasabb követelményt támaszt az érzékeny vagy nagy hatású PII-re:

[Both] A rendszertulajdonosnak / alkalmazástulajdonosnak legalább negyedévente felül KELL vizsgálnia a nagy hatású vagy érzékeny PII-t kezelő rendszerekhez való felhasználói hozzáférést, és a felülvizsgálat eredményét a REG12-ben KELL rögzítenie.

A „4.2 Access control baseline” szakasz 4.2.3 szabályzati pontjából.

Ettől válik a PIMS auditálhatóvá. A hozzáférés-felülvizsgálat nem pusztán vezetői e-mail. A REG12-ben rögzített bejegyzés, amely rendszerhez, adatkategóriához, szerepkörhöz, tulajdonoshoz, felülvizsgálati eredményhez és helyesbítő intézkedéshez kapcsolódik.

Szabályzati alap: legkisebb jogosultság, üzleti igény és alapértelmezett tiltás

A hatékony irányítás kikényszeríthető szabályokkal kezdődik. Mielőtt Anya meg tudta volna mutatni az auditornak a hozzáférés-felülvizsgálati naplót, igazolnia kellett, hogy a hozzáférés-felülvizsgálatok követelménye formálisan létrejött.

A Clarysec KKV Hozzáférés-szabályozási szabályzat - SME meghatározza az alapelvet:

Ez a szabályzat érvényesíti a legkisebb jogosultság elvét, és előírja, hogy a hozzáférést a munkaköri feladatok ellátásához minimálisan szükséges mértékre kell korlátozni.

A „Purpose” szakasz 1.3 szabályzati pontjából.

A KKV Adatvédelmi és magánélet-védelmi szabályzat - SME a hozzáférést az üzleti igényhez köti:

A személyes adatokhoz való felhasználói hozzáférést dokumentált üzleti igénnyel rendelkező szerepkörökre kell korlátozni.

A „Governance Requirements” szakasz 5.3.2 szabályzati pontjából.

Nagyobb szervezetek esetében a vállalati Adatvédelmi és magánélet-védelmi szabályzat rendszerkövetelményként fogalmazza meg a kontroll elvárását:

Minden rendszernek alapértelmezés szerint érvényesítenie kell a legkisebb jogosultság elvét.

A „Policy Implementation Requirements” szakasz 6.3.1 szabályzati pontjából.

A különbség fontos. Egy kisebb vállalatnak könnyű, de kifejezett üzletiigény-nyilvántartásra lehet szüksége. Egy nagyvállalatnak rendszerszintű kikényszerítésre, időszakos felülvizsgálatra, a feladatkörök szétválasztására, emelt jogosultságú hozzáférések irányítására, valamint belső audit, ügyfélbizonyosság, szabályozó hatósági megkeresések és adatsértési vizsgálat céljára megőrzött bizonyítékokra van szüksége.

A PII-hozzáférés életciklusa: jóváhagyás, használat, felülvizsgálat, visszavonás

A leggyakoribb PII-hozzáférési hiba nem a kezdeti jóváhagyás. Hanem a hozzáférés fennmaradása.

A Zenith Blueprint a Controls in Action szakasz 22. lépésében így magyarázza az ISO/IEC 27002:2022 5.18 kontrollját, a hozzáférési jogosultságokat:

Az 5.18 kontroll biztosítja, hogy a hozzáférési jogosultságokat ne csak megfelelően adják meg, hanem szabályozott és visszakövethető módon felül is vizsgálják, módosítsák és visszavonják.

Ezután ismerős forgatókönyveket ír le: egy új munkavállaló hozzáférést kap, szerepkört vált, és megtartja régi jogosultságait; egy korábbi adminisztrátor távozik, de egy token aktív marad; egy alvállalkozói fiók papíron lejár, de az IAM-ben nem. Pontosan ezek a gyengeségek válnak GDPR szerinti biztonsági incidensekké, ha PII érintett.

A Clarysec KKV Felhasználói fiók- és jogosultságkezelési szabályzat - SME alapfelülvizsgálati gyakoriságot határoz meg:

Minden felhasználói fiók és jogosultság felülvizsgálatát hathavonta el kell végezni.

A „Policy Implementation Requirements” szakasz 6.4.1 szabályzati pontjából.

Vállalati környezetben a Felhasználói fiók- és jogosultságkezelési szabályzat szigorítja a működési ütemet:

Az információbiztonsági csapat a szervezeti egységek vezetőivel együttműködve köteles negyedévente felülvizsgálni az összes felhasználói fiókot és kapcsolódó jogosultságot.

A „Policy Implementation Requirements” szakasz 6.5.1 szabályzati pontjából.

Egy gyakorlati PII-hozzáférési életciklusnak tartalmaznia kell:

1. A rendszer és a PII-kategóriák osztályozását.
2. A jóváhagyott szerepkörök és a dokumentált üzleti igény meghatározását.
3. A szerepkörök adatkezelési célokhoz rendelését.
4. A hozzáférés jóváhagyását az engedélyezés előtt.
5. A legkisebb jogosultság elvének, a feladatkörök szétválasztásának és az erős hitelesítésnek az érvényesítését.
6. A hitelesítés, a hozzáférés, az export, a konfiguráció és az emelt jogosultságú műveletek naplózását.
7. A hozzáférés felülvizsgálatát kockázatalapú gyakoriság szerint.
8. A hozzáférés eltávolítását szerepkörváltozás, megszüntetés, projektlezárás, szerződés lejárata vagy ügyfélutasítás esetén.
9. A bizonyítékok megőrzését a PIMS-nyilvántartásban és az auditnyomban.

Ez nem bürokrácia. Így bizonyítja a szervezet, hogy a PII-hozzáférés tervezés szerint, alapértelmezés szerint és bizonyítékokkal alátámasztva szabályozott.

Gyakorlati példa: negyedéves PII-hozzáférés-felülvizsgálat

Anya auditja akkor lett sikeres, amikor a beszélgetést a szabályzati állításokról a bizonyítékokra helyezte át.

Először hivatkozott a PII Security and Access Control Policy 4.2.3 pontjára, amely előírta a nagy hatású vagy érzékeny PII-hez való hozzáférés negyedéves felülvizsgálatát és a felülvizsgálati eredmény REG12-ben történő rögzítését.

Ezután végigvezette az auditort az előző negyedéven:

• Az IT listát készített a betegadatokat tartalmazó éles adatbázishoz kapcsolódó összes felhasználóról, csoportról, emelt jogosultságú szerepkörről, szolgáltatásfiókról, beszállítói fiókról, vészhelyzeti szerepkörről és támogatási jogosultságról.
• A listát elküldték az alkalmazástulajdonosnak, az ügyfélsikerért felelős vezetőnek, aki a támogatási csapat operatív igényéért felelt.
• Az alkalmazástulajdonos soronként felülvizsgálta a listát az aktuális szerepkör, az ügyféltámogatási felelősség és az adatkezelési cél alapján.
• Két támogatási munkatársat, akik más csapatba kerültek, hozzáférés-visszavonásra jelöltek.
• Jegyet hoztak létre az IT-szolgáltatásmenedzsment rendszerben, összekapcsolták a hozzáférés-felülvizsgálattal, SLA-t rendeltek hozzá, majd a hozzáférés visszavonása után lezárták.
• A REG12-t frissítették a felülvizsgálati bejegyzéssel, jóváhagyóval, kivételekkel, helyesbítő intézkedési jeggyel, lezárást igazoló bizonyítékkal és a következő felülvizsgálat dátumával.

Az eredmény zárt bizonyítéklánc volt. Anya nem pusztán azt állította, hogy a Medtelligence a legkisebb jogosultság elvét alkalmazza. Megmutatta a szabályzati követelményt, a felelős tulajdonost, a hozzáférési listát, a felülvizsgálati döntést, a helyesbítő intézkedést és a végrehajtott hozzáférés-visszavonást.

Ez a különbség a hozzáférés-szabályozás és a hozzáférés-irányítás között.

Beszállítói és adatfeldolgozói hozzáférés: vakfolt a PIMS-auditokban

Számos jogosulatlan hozzáférési kockázat támogatáson, kiszervezésen, integrációs partnereken, menedzselt szolgáltatókon és al-adatfeldolgozókon keresztül jelenik meg. Egy adatfeldolgozónak távoli hozzáférése lehet az ügyfél éles adataihoz. Egy felhőszolgáltató támogatási hozzáférési útvonalakat biztosíthat. Egy al-adatfeldolgozó fenntarthat ügyfélazonosítókat tartalmazó keresési indexet. Egy menedzselt biztonsági szolgáltató hozzáférhet személyes adatokat tartalmazó naplókhoz.

A GDPR szerint az adatkezelőknek olyan adatfeldolgozókat kell igénybe venniük, amelyek megfelelő garanciákat nyújtanak. Az ISO/IEC 27701:2025 szerint az adatfeldolgozói és al-adatfeldolgozói irányítást dokumentált utasításokkal, szerződéses kontrollokkal, bizonyossággal és nyomon követéssel kell működtetni. Az ISO/IEC 27002:2022 ezt beszállítói kapcsolatokra vonatkozó kontrollokkal támogatja, beleértve az 5.19 Információbiztonság a beszállítói kapcsolatokban, az 5.20 Információbiztonság kezelése beszállítói megállapodásokban és az 5.21 Információbiztonság kezelése az IKT-ellátási láncban kontrollokat.

A Zenith Blueprint a Controls in Action szakasz 23. lépésében összefoglalja a beszállítói megállapodások bizonyítékterületeit, többek között:

✓ hozzáférés-szabályozási felelősségek, például ki férhet hozzá az adatokhoz, hogyan kezelik a hitelesítő adatokat, és milyen felügyelet működik;

Ide tartoznak továbbá a titoktartási kötelezettségek, a technikai és szervezési intézkedések, az incidensbejelentési határidők, az auditálási jog, az alvállalkozói kontrollok és a szerződés végén végrehajtandó fiókdeaktiválás.

A Clarysec Processor, Subprocessor and Third-Party Privacy Management Policy ezt adatkezelői oldali PIMS-bizonyítékká alakítja:

[Controller] Az adatvédelmi vezetőnek / PIMS-menedzsernek jóváhagyás előtt ellenőriznie KELL, hogy a REG08 adatfeldolgozói szerződéses kontrollmezői lefedik-e az adatkezelés hatókörét, időtartamát, célját, a PII-kategóriákat, a PII-alany kategóriáit, a bizalmasságot, a biztonságot, az al-adatfeldolgozói engedélyezést, a segítségnyújtást, az auditot vagy bizonyosságot, a visszaszolgáltatást, a törlést és a megszüntetést.

A „4.3 Contract and documented instruction controls” szakasz 4.3.2 szabályzati pontjából.

A beszállítói hozzáférést a Clarysec KKV és vállalati beszállítói szabályzatai közvetlenül is szabályozzák. A KKV Third-Party and Supplier Security Policy - SME kimondja:

A beszállítók csak a feladatuk ellátásához szükséges minimális rendszerekhez és adatokhoz kaphatnak hozzáférést.

A „Policy Implementation Requirements” szakasz 6.2.1 szabályzati pontjából.

A vállalati Third party and supplier security policy kiegészíti ezt RBAC-kal, felülvizsgálattal és a legkisebb jogosultság elvével:

A beszállítói személyzetre szerepköralapú hozzáférés-szabályozást (RBAC), időszakos hozzáférés-felülvizsgálatokat és a legkisebb jogosultság elvének érvényesítését kell alkalmazni.

A „Policy Implementation Requirements” szakasz 6.3.1 szabályzati pontjából.

Ha a beszállítói hozzáférés elérheti a PII-t, annak a PIMS részét kell képeznie. Meg kell jelennie a szerződéses kontrollokban, hozzáférés-jóváhagyásokban, IAM-csoportokban, naplózási hatókörben, felülvizsgálati bejegyzésekben, kiléptetési bejegyzésekben, incidenskezelési forgatókönyvekben és auditbizonyítékokban.

Felhőalapú PII-hozzáférés: a megosztott felelősség nem megosztott elszámoltathatóság

A felhőalapú PII-hozzáférés irányítása olyan terület, ahol a szervezetek gyakran túlbecsülik a szolgáltató szerepét, és alábecsülik saját felelősségeiket. A felhőszolgáltató biztosíthatja az infrastruktúrát, de az ügyfél továbbra is irányítja az identitásokat, szerepköröket, bérlői konfigurációt, támogatási hozzáférést, naplókat, titkosítási beállításokat, exportjogosultságokat és az incidensreagálási felkészültséget.

A Zenith Blueprint a Controls in Action szakasz 23. lépésének felhőszolgáltatási útmutatójában egyértelműen fogalmaz:

A felhőszolgáltatók biztosítják az infrastruktúrát, de az adatokért, a konfigurációkért, a hozzáférési szabályzatokért és az incidensreagálási felkészültségért továbbra is Ön felel.

Figyelmeztet továbbá:

A felhőben a láthatóság csak akkor teljes körű, ha azt szándékosan megtervezik. Be kell állítani a naplózást, érvényesíteni kell a titkosítást, meg kell határozni az identitásszerepköröket, és natív eszközökkel vagy harmadik fél integrációkkal figyelni kell a tevékenységet. Ez nem infrastruktúra-feladat, hanem ISMS-követelmény.

A Clarysec Felhőszolgáltatások használatára vonatkozó szabályzat ezt vállalati hozzáférési követelménnyé alakítja:

Minden felhőszolgáltatásnak a legkisebb jogosultság elvével összhangban álló, identitásalapú hozzáférés-szabályozást kell érvényesítenie.

A „Policy Implementation Requirements” szakasz 6.2.1 szabályzati pontjából.

Felhőkörnyezetben adatfeldolgozóként működő szervezetek számára a Clarysec Cloud PII Processor Policy pontosabb PIMS-felülvizsgálati kötelezettséget határoz meg:

[Processor] Az információbiztonsági vezetőnek legalább negyedévente felül KELL vizsgálnia a REG12-ben az emelt jogosultságú felhőhozzáférést, a támogatási hozzáférést, az ügyfél-PII-hez való hozzáférést és a naplózási lefedettséget.

A „4.2 Cloud Configuration, Tenant Isolation, Access and Logging” szakasz 4.2.4 szabályzati pontjából.

Ez a pont különösen releváns SaaS-vállalatok, felhőben üzemeltetett platformok, menedzselt adatszolgáltatások és B2B adatfeldolgozók számára.

A felhőalapú PII-hozzáférés irányítása nem teljes, ha a felhőnatív naplókat, IAM-szabályzatokat, szolgáltatásfiókokat, emelt jogosultságú szerepköröket, ügyféltámogatási eszközöket, API-kulcsokat és adatexport-funkciókat nem együtt vizsgálják felül.

Naplózás és felügyelet: a PII-irányítás memóriája

Naplók nélkül a PIMS hozzáférés-szabályozási programja emlékezet nélküli ígéret.

A PII Security and Access Control Policy éles használat vagy lényeges változás előtt előírja a naplózási hatókört:

[Both] A rendszertulajdonosnak / alkalmazástulajdonosnak éles használat vagy lényeges változás előtt meg KELL határoznia a REG12-ben a PII naplózási hatókörét a hitelesítési eseményekre, hozzáférési eseményekre, emelt jogosultságú műveletekre, PII-export tevékenységre és lényeges konfigurációs változásokra.

A „4.6 Logging and monitoring” szakasz 4.6.1 szabályzati pontjából.

A KKV Naplózási és felügyeleti szabályzat - SME egyértelművé teszi a hozzáférési naplók tartalmát:

Hozzáférési naplók: fájlhozzáférés — különösen érzékeny vagy személyes adatok esetén —, jogosultságmódosítások, megosztott erőforrások használata

A „Governance Requirements” szakasz 5.4.3 szabályzati pontjából.

A vállalati Naplózási és felügyeleti szabályzat az auditcélú használhatóságra összpontosít:

Az ISMS Audit Trail Registerben rögzíteni kell a naplóadatok rendelkezésre állását auditokhoz, vizsgálatokhoz és szabályozási felülvizsgálatokhoz.

A „Governance Requirements” szakasz 5.4 szabályzati pontjából.

Ez kritikus, mert az adatvédelmi bizonyítékoknak gyakran eseményalapú kérdésekre kell választ adniuk:

• Ki fért hozzá a PII-hez?
• Engedélyezett volt a hozzáférés?
• A hozzáférés támogatási jegyhez, jogi megkereséshez, operatív feladathoz vagy ügyfélutasításhoz kapcsolódott?
• Exportálták, másolták, módosították vagy törölték az adatokat?
• Használtak emelt jogosultságú hozzáférést?
• Módosultak a jogosultságok a hozzáférés előtt vagy után?
• A tevékenység biztonsági incidensre vagy személyesadat-sértésre utalt?

A naplók nem csak a SOC számára fontosak. PIMS-bizonyítékok, ügyfélbizonyossági bizonyítékok, adatfeldolgozói bizonyossági bizonyítékok és incidensreagálási bizonyítékok.

Megfelelőségi keretrendszerek közötti megfeleltetés: egy hozzáférési modell, több nézőpont

A PII-hozzáférés-felülvizsgálatok gyengesége soha nem pusztán egy megállapítás. Lehet belőle GDPR szerinti elszámoltathatósági probléma, ISO/IEC 27701:2025 szerinti PIMS-gyengeség, ISO/IEC 27001:2022 szerinti meg nem felelés, NIS2 szerinti irányítási hiba, DORA szerinti reziliencia-kockázat, NIST CSF 2.0 szerinti irányítási hiányosság vagy COBIT 2019 szerinti folyamatérettségi probléma.

Egy részletesebb kontroll-kereszttérkép megmutatja, hogyan támogat egyetlen PII-hozzáférés-irányítási folyamat több követelményt:

A Zenith Controls értéke abban áll, hogy a csapatok ezeket a nézőpontokat ugyanahhoz a kontrollbizonyítékhoz tudják visszatérképezni, ahelyett hogy külön megfelelőségi silókat tartanának fenn.

45 perces PII-hozzáférési bizonyítéksprint végrehajtása

A felkészültség tesztelésének hasznos módja, ha kiválasztanak egy nagy hatású rendszert — például ügyféltámogatási platformot, HR-rendszert, fizetési portált, betegportált, adattavat vagy SaaS éles adatbázist —, és célzott bizonyítéksprintet hajtanak végre.

1. lépés: A PII-adatkezelési kontextus meghatározása

Rögzítse a REG12-ben:

• Rendszernév és tulajdonos
• PII-kategóriák
• PII-alany kategóriái
• Adatkezelői vagy adatfeldolgozói szerepkör
• Adatkezelési cél
• Nagy hatású vagy érzékeny PII jelölése
• Felhő-, beszállítói és al-adatfeldolgozói függőségek

Ha a rendszer adatfeldolgozót érint, ellenőrizze a REG08 szerződéses kontrollmezőit a Processor, Subprocessor and Third-Party Privacy Management Policy alapján. A jóváhagyásnak ki kell terjednie az adatkezelés hatókörére, időtartamára, céljára, a PII-kategóriákra, a PII-alany kategóriáira, a bizalmasságra, a biztonságra, az al-adatfeldolgozói engedélyezésre, a segítségnyújtásra, az auditra vagy bizonyosságra, a visszaszolgáltatásra, a törlésre és a megszüntetésre.

2. lépés: A hozzáférési lista lekérése

Exportálja az összes felhasználót, csoportot, emelt jogosultságú szerepkört, szolgáltatásfiókot, támogatási szerepkört, vészhelyzeti fiókot, API-kulcsot és beszállítói fiókot. Hasonlítsa össze az egyes jogosultságokat a jóváhagyott szerepkörökkel.

3. lépés: A legkisebb jogosultság és a célhoz kötött összhang megerősítése

Alkalmazza a PII Security and Access Control Policy alapkövetelményét: a hozzáférést a jóváhagyott szerepkörökre és az engedélyezett felhasználókra kell korlátozni, akiket az engedélyezés előtt a REG02-ben vagy REG12-ben rögzítettek, vagy azokban visszakövethetők. Ha egy felhasználó nem vezethető vissza szerepkörhöz, célhoz és jóváhagyáshoz, a megállapítás nem „hiányzó dokumentáció”. A megállapítás: „a PII-hozzáférés igazolhatóan nem engedélyezett”.

4. lépés: A naplózási hatókör ellenőrzése

Erősítse meg, hogy a naplók rögzítik a hitelesítést, a hozzáférési eseményeket, az emelt jogosultságú műveleteket, a PII-export tevékenységet és a lényeges konfigurációs változásokat. Ezután erősítse meg, hol tárolják a naplókat, mennyi ideig őrzik meg őket, ki férhet hozzájuk, és rögzítették-e őket az ISMS Audit Trail Registerben auditok, vizsgálatok és szabályozási felülvizsgálatok céljára.

5. lépés: A folyamat lezárása

Minden kivételhez rögzítse a kockázatgazdát, az azonnali elszigetelési intézkedést, a végleges helyesbítő intézkedést, a tervezett határidőt, a szükséges bizonyítékot, a maradványkockázati döntést, valamint azt, hogy szükséges-e adatsértési értékelés.

Ez az egy gyakorlat általában feltárja a PII-hozzáférés irányításának valós érettségét. Az erős szervezetek gyorsan tudnak válaszolni. A gyenge szervezetek ekkor szembesülnek azzal, hogy az adatvédelmi szabályzat, az IAM-konfiguráció, az adatfeldolgozói szerződések, a felhőalapú naplózás és az auditbizonyítékok nincsenek összekapcsolva.

Gyakori auditmegállapítások a PII-hozzáférés irányításában

A legtöbb megállapítás előre látható. Akkor keletkeznek, amikor az adatvédelem, a biztonság, a jogi terület, az IT és a beszállítók mind a történet egy részét kezelik, de senki sem felel a teljes PII-hozzáférési életciklusért.

Gyakori megállapítások:

• A PII-t kezelő rendszerek nem szerepelnek teljes körűen a PIMS-leltárban.
• A hozzáférési szerepköröket technikailag meghatározták, de nem rendelték hozzá adatkezelési célokhoz.
• Az érzékeny PII széles operatív csoportokon keresztül hozzáférhető.
• A negyedéves felülvizsgálatok lefedik a munkavállalókat, de nem fedik le a szolgáltatásfiókokat, API-kulcsokat vagy beszállítói felhasználókat.
• A felhőalapú támogatási hozzáférés lehetséges, de nem vizsgálják felül PII-hozzáférésként.
• Vannak naplók, de nem bizonyítják a PII-hozzáférést, exportot vagy emelt jogosultságú tevékenységet.
• Az adatfeldolgozói szerződések általános titoktartási záradékokat tartalmaznak, de nem tartalmaznak konkrét hozzáférés-szabályozási, audit-, al-adatfeldolgozói, visszaszolgáltatási, törlési vagy megszüntetési kontrollokat.
• Volt munkavállalók vagy alvállalkozók megosztott csoportokon vagy nem felügyelt tokeneken keresztül megtartják hozzáférésüket.
• Az adattárházhoz való hozzáférés szélesebb, mint a forrásalkalmazáshoz való hozzáférés.
• Vészhelyzeti fiókok léteznek használat utáni felülvizsgálat nélkül.
• Az ügyféltámogatási megszemélyesítést nem naplózzák jegykörnyezettel együtt.
• Az alkalmazhatósági nyilatkozat tartalmaz hozzáférés-szabályozási kontrollokat, de a bizonyítékok nem mutatják a PII-specifikus megvalósítást.

E megállapítások mindegyike válhat GDPR szerinti elszámoltathatósági problémává, ügyfélbizonyossági kérdéssé, NIS2 vagy DORA szerinti irányítási gyengeséggé, illetve ISO/IEC 27001:2022 szerinti meg nem feleléssé, a hatókörtől függően.

Hogyan néz ki a jó működés

Az érett működési modell nem hősies negyedéves rendrakásokra épít. A PII-hozzáférés-irányítást a mindennapi működésbe építi be.

Először: a szervezet rendelkezik adatáttekintéssel. Tudja, hol található PII, miért kezeli, mely PIMS-szerepkör alkalmazandó, és mely rendszerek, beszállítók, felhőszolgáltatások, naplók, biztonsági mentések és exportok tartoznak a hatókörbe.

Másodszor: a hozzáférés szerepköralapú és célhoz kötött. A jogosultságokat jóváhagyott szerepkörök, dokumentált üzleti igény, adatkezelési cél és a legkisebb jogosultság elve alapján határozzák meg.

Harmadszor: a kontrollokat technikailag érvényesítik. Az IAM, az RBAC, az emelt jogosultságú hozzáférések kezelése, az MFA, a feltételes hozzáférés, a bérlői kontrollok, a titkosítás és a környezetek elkülönítése érvényesíti a szabályzati elvárásokat.

Negyedszer: a felügyelet tudatosan kialakított. A szervezet rekonstruálni tudja a PII-t érintő hitelesítést, hozzáférést, exportot, emelt jogosultságú műveletet, támogatási hozzáférést és konfigurációs változásokat.

Ötödször: a felülvizsgálatok kockázatalapúak és dokumentáltak. A nagy hatású PII legalább negyedéves felülvizsgálatot kap. A beszállítói és felhőalapú támogatási hozzáférések is szerepelnek benne. A kivételeket lezárásig követik.

Hatodszor: a bizonyítékok újrahasznosíthatók. Ugyanazok a nyilvántartások támogatják a GDPR szerinti elszámoltathatóságot, az ISO/IEC 27701:2025 PIMS működését, az ISO/IEC 27001:2022 kockázatkezelést, a NIS2 kockázatkezelési intézkedéseit, a DORA IKT-kockázatirányítást, a NIST CSF 2.0 GOVERN eredményeit és a COBIT 2019 irányítási bizonyosságát.

Ez a különbség a beállításként kezelt hozzáférés-szabályozás és a rendszerként működő hozzáférés-irányítás között.

A PII-hozzáférés átalakítása auditálló bizonyítékká

Ha a következő audit, ügyfélfelülvizsgálat vagy szabályozó hatósági megkeresés holnap azzal kezdődne, hogy „mutassák meg, ki férhet hozzá a PII-hez”, a csapata percek alatt bizonyítékot adna, vagy táblázatokat kezdene egyeztetni?

A Clarysec segíthet e hiányosság lezárásában.

Kezdje a PII Security and Access Control Policy alkalmazásával, hangolja össze az adatfeldolgozói és felhőkötelezettségeket a Processor, Subprocessor and Third-Party Privacy Management Policy és a Cloud PII Processor Policy segítségével, majd használja a Zenith Blueprint: An Auditor’s 30-Step Roadmap útmutatót a kontrollok megfelelő sorrendű bevezetéséhez. Végül használja a Zenith Controls: The Cross-Compliance Guide útmutatót a PII-hozzáférési bizonyítékok megfeleltetéséhez ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 és COBIT 2019 szerint.

A leggyorsabb gyakorlati következő lépés egyszerű: válasszon ki egy nagy hatású PII-rendszert, töltse ki a REG12-t, exportálja a hozzáférési listát, ellenőrizze a naplózási hatókört, és hajtson végre egy negyedéves jellegű felülvizsgálatot. Egyetlen alkalom alatt kiderül, hogy a PII-hozzáférés irányítása auditálló-e, vagy csak szabályzati szinten létezik.