Az Európai Digitális Személyazonossági Tárca megfelelőségi bizonyítéktérképe 2026-ra

Egy fintech termékcsapat két héttel a tárcaalapú ügyfél-regisztráció éles indulása előtt áll. Az új folyamat lehetővé teszi, hogy az EU-s ügyfelek kiválasztott személyazonossági attribútumokat igazoljanak az Európai Digitális Személyazonossági Tárca segítségével, a személyazonosító okmányok manuális feltöltése helyett. A CISO látja a biztonsági előnyt. A DPO értékeli az adattakarékosság ígéretét. A megfelelési vezető kevesebb félbehagyott regisztrációs folyamatot és letisztultabb ügyfélélményt vár.

Ekkor az auditbizottság felteszi a kérdést, amely megváltoztatja a helyzetet:

„Ha egy szabályozó hatóság, banki partner, ügyfélauditor vagy felügyeleti hatóság megkérdezi, hogyan irányítjuk ezt a tárcaintegrációt, milyen bizonyítékokat mutatunk be?”

Ez a valódi 2026-os probléma.

Az Európai Digitális Személyazonossági Tárca, gyakran röviden EUDI Wallet, nem csupán egy újabb termékfunkció. Szabályozott digitális szolgáltatásoknál, fizetési szolgáltatóknál, bizalmi szolgáltatási ökoszisztémákban, közszférabeli interfészeknél és magas biztonsági szintű ügyfél-regisztrációs folyamatoknál a szervezet személyazonossági bizonyossági láncának részévé válik. Érinti a személyes adatokat, a hitelesítési eseményeket, a beszállítói függőségeket, a hozzáférés-irányítást, a naplózást, a kriptográfiát, az incidensjelentést és az igazgatósági elszámoltathatóságot.

A csapda az, ha az eIDAS2-t és az EUDI Walletet önálló jogi bevezetésként kezeljük. A gyakorlati válasz más: a tárcát elfogadó félként történő alkalmazást ugyanabba a bizonyítékrendszerbe kell beépíteni, amelyet az ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST CSF 2.0 és COBIT 2019 követelményekhez használunk.

Ebben a legerősebb a Clarysec megközelítése. Nem alakítunk minden új jogszabályt újabb táblázattá. A kötelezettségeket szabályzatokhoz, kontrollokhoz, felelősökhöz, auditnyomokhoz és ismételhető bizonyítékokhoz rendeljük.

Ez a cikk bemutatja, hogyan építhető fel ez a bizonyítéki gerinc a Clarysec Zenith Blueprint: 30 lépéses auditori ütemterv, Zenith Controls: keresztmegfelelési útmutató, valamint a Clarysec adatvédelmi, identitáskezelési, naplózási, beszállítói irányítási és jogszabályi megfelelési szabályzatsablonjai segítségével.

A 2026-os tárcabizonyítéki probléma nagyobb, mint az eIDAS2

Az Európai Digitális Személyazonossági Tárcáról szóló legtöbb vita a bizalomra, az interoperabilitásra és a felhasználói élményre összpontosít. Ezek fontosak. Egy CISO, megfelelési vezető, DPO vagy auditor számára azonban a kérdés működési jellegű: mely kontrollok bizonyítják, hogy a tárcából származó személyazonossági attribútumokat biztonságosan, jogszerűen és arányosan használják?

Egy tárcából származó állításokat elfogadó félnek meg kell tudnia válaszolni a következő kérdéseket:

• Mely tárcaattribútumokat kérjük be, és miért?
• Mely jogalap támasztja alá az adatkezelést?
• A felhasználók, rendszergazdák és szolgáltatásfiókok egyedileg azonosíthatók-e?
• A tárcaellenőrzési szolgáltatások, identitásbrókerek, API-átjárók és felhőkomponensek szerepelnek-e a beszállítói nyilvántartásban?
• A hitelesítési és ellenőrzési eseményeket úgy naplózzuk-e, hogy azok támogassák a vizsgálatot, miközben nem történik túlzott személyesadat-gyűjtés?
• Van-e incidenskezelési folyamat arra az esetre, ha a tárcaalapú ügyfél-regisztrációval visszaélnek, az nem érhető el vagy kompromittálódik?
• Pénzügyi szervezetek esetében a tárcaintegráció lefedett-e a DORA szerinti IKT-kockázatkezelésben, harmadik fél kockázatkezelésében és incidensosztályozásában?
• NIS2 hatálya alá tartozó szervezeteknél a tárcára támaszkodás érinti-e az alapvető vagy fontos szolgáltatásnyújtást, a hozzáférés-szabályozást, az üzletmenet-folytonosságot vagy az ügyfélkommunikációt?

A NIS2 különösen releváns, mert hatálya számos digitális infrastruktúra-szolgáltatóra, felhőszolgáltatásra, menedzselt szolgáltatókra, menedzselt biztonsági szolgáltatókra és bizalmi szolgáltatókra kiterjed. Az irányelv emellett meghatározott körülmények között alapvető szervezetként sorolja be a minősített bizalmi szolgáltatókat, a DNS-szolgáltatókat, a TLD-nyilvántartókat és több más szervezetet. 2026-ra sok szervezet már nem azt fogja kérdezni, hogy közeledik-e a jogszabály. A felügyeleti, ügyfél- és belső auditkérdésekre kell majd válaszolnia a végrehajtásról.

A pénzügyi szolgáltatásoknál a DORA további réteget ad. 2025. január 17-től alkalmazandó, és egységes IKT-kockázati, incidenskezelési, tesztelési és harmadik fél kockázatkezelési keretrendszert hoz létre a pénzügyi szervezetek számára. A NIS2 a DORA-t ágazatspecifikus uniós jogi aktusként ismeri el számos átfedő pénzügyi ágazati kiberbiztonsági kötelezettség esetében. A gyakorlatban ez azt jelenti, hogy egy fizetési intézménynél, kriptoeszköz-szolgáltatónál, befektetési vállalkozásnál vagy számlainformációs szolgáltatónál a tárcaalapú ügyfél-regisztrációs funkciót DORA-szintű IKT-kockázatirányítással kell bizonyítani, még akkor is, ha a NIS2 továbbra is releváns a koordináció és az ökoszisztéma-függőségek miatt.

A hibás válasz az, ha külön bizonyítékcsomagot hozunk létre az eIDAS2-re, külön a GDPR-ra, külön a NIS2-re, külön a DORA-ra és külön az ISO tanúsításra. A helyes válasz az, hogy az IBIR legyen a bizonyítékok működési modellje.

Használjuk az ISO 27001-et bizonyítéki gerincként

Az ISO/IEC 27001:2022 azért hasznos, mert nem korlátozódik technológiai ellenőrzőlistára. Megköveteli, hogy a szervezetek meghatározzák a kontextust, az érdekelt feleket, a jogi és szerződéses kötelezettségeket, a hatályt, az interfészeket, a függőségeket, a vezetői felelősségeket, a kockázatértékelést, a kockázatkezelést, az alkalmazhatósági nyilatkozatot és a folyamatos fejlesztést.

Ez a tárcaalkalmazásnál azért fontos, mert a kockázat nem csupán egy API-hívásban jelenik meg. A kockázat a teljes, végponttól végpontig tartó üzleti folyamatban van.

A tárcát elfogadó félként történő bevezetés érinti:

• az ügyfél-regisztrációt és a fiókhozzáférést;
• az adatvédelmi tájékoztatókat, RoPA-bejegyzéseket és jogalap-nyilvántartásokat;
• a személyazonosság-igazolási és hitelesítési modelleket;
• a beszállítói szerződéseket és bizonyosságot;
• a naplózást, a felügyeletet és a bizonyítékok megőrzését;
• az incidensosztályozást és jelentéstételt;
• az adatmegőrzést, törlést és helyesbítést;
• az auditot és a megfelelés nyomon követését;
• az igazgatósági szintű kockázati jelentéstételt.

A Clarysec vállalati megfelelési szabályzata egyértelművé teszi ezt a működési modellt:

„Minden jogi és szabályozási kötelezettséget konkrét szabályzatokhoz, kontrollokhoz és felelősökhöz kell rendelni az információbiztonsági irányítási rendszerben (ISMS).”
Forrás: Jogi és szabályozói megfelelési szabályzat, „A szabályzat végrehajtásának követelményei” szakasz, 6.2.1 szabályzati pont.

KKV-k esetében ugyanez az elv gyakorlati megfelelési nyilvántartássá skálázódik:

„Ha egy jogszabály több területre is alkalmazandó (pl. a GDPR a megőrzésre, a biztonságra és az adatvédelemre), ezt egyértelműen le kell képezni a megfelelési nyilvántartásban és a képzési anyagokban.”
Forrás: Jogi és szabályozói megfelelési szabályzat – KKV, „Irányítási követelmények” szakasz, 5.2.2 szabályzati pont.

A szervezetnek nem azt kell kérdeznie: „Melyik részleg felel az eIDAS2-ért?” A helyes kérdés: „Mely IBIR-kockázatokat, kontrollokat, szabályzatokat, felelősöket és bizonyítéknyilvántartásokat érinti a tárcára támaszkodás?”

A Zenith Blueprint Kockázatkezelés szakaszának 14. lépése így fogalmaz:

„Minden jogszabályhoz, ha alkalmazandó, létrehozható egy egyszerű megfeleltetési táblázat (akár egy jelentés mellékleteként), amely felsorolja a jogszabály fő biztonsági követelményeit és az IBIR-ben szereplő megfelelő kontrollokat/szabályzatokat. Ez az ISO 27001 szerint nem kötelező, de hasznos belső gyakorlat annak biztosítására, hogy semmi ne essen ki a rendszerből. Az auditorokra/értékelőkre is jó benyomást tesz, mert látszik, hogy a biztonságot nem vákuumban kezelik, hanem tisztában vannak a jogi kontextussal.”

Ez az alap: egyetlen megfeleltetési táblát kell építeni, amely összekapcsolja a tárcát elfogadó fél kötelezettségeit a GDPR, NIS2, DORA, ISO/IEC 27001:2022 Annex A kontrollokkal, Clarysec szabályzatokkal és bizonyítéknyilvántartásokkal.

Gyakorlati bizonyítéktérkép az Európai Digitális Személyazonossági Tárcát elfogadó felek számára

Az EUDI Wallet akkor válik kezelhetővé, ha az IBIR-en belül meghatározott üzleti folyamatként kezeljük, hozzárendelt adatokkal, identitásokkal, beszállítókkal, naplókkal, incidensekkel és felelősökkel.

Ez a táblázat nem jogi vélemény. Kontroll- és bizonyítékmodell, amelyet CISO-k, megfelelési csapatok és auditorok használhatnak a bizonyítás strukturálására.

Az identitáskezeléssel kezdik az auditorok

A tárcát elfogadó fél számára az identitás a nyilvánvaló kontrollcsalád. Az identitáskezelés azonban nem azonos a hitelesítéssel. Az identitáskezelés arra válaszol, hogy „ki létezik a rendszerben, és hogyan irányítjuk az identitását?” A hitelesítés arra válaszol, hogy „hogyan ellenőrizzük a megadott identitást a hozzáférés időpontjában?”

A Zenith Controls az ISO/IEC 27002:2022 5.16 Identitáskezelés kontrollját megelőző kontrollként kezeli, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást. Közvetlenül kapcsolódik a hozzáférés-szabályozáshoz, a hitelesítési információkhoz, a hozzáférési jogosultságokhoz, a beszállítói kapcsolatokhoz, a megfelelés nyomon követéséhez és az emelt jogosultságú hozzáféréshez. A keresztmegfelelési leképezés ezt a területet a GDPR szerinti biztonsághoz és elszámoltathatósághoz, a NIS2 szerinti hozzáférés-szabályozáshoz és eszközkezeléshez, a DORA identitás- és hozzáférés-irányításához, a NIST SP 800-53 azonosítókezeléséhez és a COBIT 2019 identitáséletciklus-irányításához kapcsolja.

A tárcabizonyítékoknál a szervezetnek igazolnia kell, hogy:

• az ügyfél- és munkavállalói identitások nem keverednek;
• az adminisztratív identitások egyediek és visszakövethetők;
• a beszállítói identitásokat ugyanolyan fegyelemmel irányítják, mint a munkavállalókét;
• a nem emberi identitásoknak, például API-klienseknek és szolgáltatásfiókoknak, van felelősük;
• az identitásokat megszüntetik, amikor már nincs rájuk szükség;
• a kivételek, break-glass fiókok és emelt jogosultságú identitások kontrolláltak.

A Clarysec KKV-fiókszabályzata közérthetően rögzíti az elvet:

„Minden fióknak egyedinek, konkrét személyhez visszakövethetőnek és üzleti szerepkörhöz kapcsoltnak kell lennie.”
Forrás: Felhasználói fiók- és jogosultságkezelési szabályzat – KKV, „A szabályzat végrehajtásának követelményei” szakasz, 6.1.2 szabályzati pont.

Vállalati környezetben a megosztott fiókokra vonatkozó követelmény szigorúbb:

„Minden felhasználói identitást egyedi azonosítóhoz kell rendelni. A megosztott vagy generikus fiókok használata tilos, kivéve a jóváhagyott, szigorú kontrollok alá vont break-glass vagy vészhelyzeti fiókokat.”
Forrás: Felhasználói fiók- és jogosultságkezelési szabályzat, „Irányítási követelmények” szakasz, 5.3 szabályzati pont.

A támogató szabványok ugyanezt a bizonyítéki logikát erősítik. Az ISO/IEC 24760-1:2019 identitáséletciklus-fogalmakat ad, például regisztrációt, hozzárendelést, használatot és nyilvántartásból való törlést. Az ISO/IEC 29115:2013 a kockázatalapú személyazonossági bizonyosságot támogatja. Az ISO/IEC 27005:2024 az identitás- és hozzáférési gyengeségeket kockázatkezelési témaként kezeli. Az ISO/IEC 27018:2020 kiterjeszti az identitáskezelési elvárásokat a nyilvános felhőben történő PII-adatkezelésre. Az ISO/IEC 29100:2011 adatvédelmi nézőpontot ad azáltal, hogy az azonosíthatóságot a személyes információk kezeléséhez kapcsolja.

Az EUDI Wallet alkalmazásánál az auditkérdés egyszerű: minden emelt jogosultságú művelet, konfigurációváltozás, tárcaellenőrzési integrációváltozás és beszállítói hozzáférési esemény visszakövethető-e egyedi identitáshoz és jóváhagyott szerepkörhöz?

Ha a válasz nem, a tárcaprojekt nem áll készen auditra.

Biztonságos hitelesítés: a tárcába vetett bizalom nem szünteti meg a kontrollkötelezettségeket

Gyakori tévhit, hogy a tárcaalapú személyazonosság-igazolás megszünteti az elfogadó fél hitelesítési kötelezettségeit. Javíthatja bizonyos személyazonossági attribútumok bizonyosságát, de nem szünteti meg a rendszerek, munkamenetek, alkalmazásprogramozási interfészek, adminisztratív interfészek és ügyfélutak védelmének kötelezettségét.

A Zenith Blueprint Kontrollok működésben szakaszának 19. lépésében a Clarysec így fogalmaz:

„A hitelesítés az első és legkritikusabb védelmi vonal egy fenyegető szereplő és az Ön rendszerei, adatai és szolgáltatásai között. Ha a hitelesítés gyenge, minden más – titkosítás, felügyelet, szegmentálás – megkerülhető.”

Ugyanez a lépés kifejti, hogy a modern hitelesítésnek kockázatalapúnak kell lennie, magasabb értékű célpontoknál erősebb védelmet kell alkalmaznia, és többtényezős hitelesítéssel, biztonságos hitelesítőadat-tárolással, TLS-sel, tokenvédelemmel, titokkezeléssel, biztonságos munkamenet-kezeléssel és hitelesítési naplók felülvizsgálatával kell támogatni.

A Zenith Controls az ISO/IEC 27002:2022 8.5 Biztonságos hitelesítés kontrollját megelőző kontrollként képezi le az identitás- és hozzáférés-kezelési képességben. Kapcsolódik az identitáskezeléshez, a hitelesítési információkhoz, az emelt jogosultságú hozzáféréshez, az információhozzáférés korlátozásához, a megfigyelési tevékenységekhez, az incidenskezeléshez és a PII adatvédelmi védelméhez. Keresztmegfeleltetése kiterjed a GDPR szerinti biztonságra és beépített adatvédelemre, a NIS2 szerinti kiberbiztonsági kockázatkezelésre és – ahol megfelelő – többtényezős hitelesítésre vagy folyamatos hitelesítésre, a DORA IKT-kockázatirányítására, a NIST SP 800-53 IA és AC családokra, valamint a COBIT 2019 logikai hozzáférés-irányítására.

Egy tárcát elfogadó fél esetében a biztonságos hitelesítés bizonyítékainak tartalmazniuk kell:

• a tárcaellenőrzési végpont hitelesítését és engedélyezését;
• rendszergazdai MFA-t a tárcakonfigurációs panelekhez;
• biztonságos API-hitelesítést az ügyfél-regisztrációs szolgáltatások között;
• titoktáras kezelést a tárcaintegrációs kulcsokhoz vagy tanúsítványokhoz;
• munkamenet-időtúllépéseket és tokenvédelmet, ahol megfelelő;
• sikertelen hitelesítési riasztásokat és brute-force védelmet;
• külön kontrollokat ügyfélbejelentkezéshez, munkavállalói hozzáféréshez és gép–gép közötti hozzáféréshez.

A Clarysec KKV-kra vonatkozó naplózási szabályzata gyakorlati bizonyítékkövetelményt ad:

„Hitelesítési naplók: sikeres és sikertelen bejelentkezési kísérletek, munkamenet-időtartam, MFA-használat”
Forrás: Naplózási és felügyeleti szabályzat – KKV, „Irányítási követelmények” szakasz, 5.4.2 szabályzati pont.

Vállalati környezetben az auditmegbízhatóság központi jelentőségűvé válik:

„A naplófájloknak módosíthatatlannak vagy verziókezeltnek kell lenniük, és hozzáférést csak jogosult személyek kaphatnak.”
Forrás: Naplózási és felügyeleti szabályzat, „A szabályzat végrehajtásának követelményei” szakasz, 6.5.1 szabályzati pont.

Ez a híd a személyazonossági bizonyosság és az incidensreagálás között. Ha a tárcaalapú ügyfél-regisztrációt credential stuffing, token-visszajátszás, adminisztratív kompromittálódás vagy beszállítói visszaélés éri, a hitelesítési naplók válnak bizonyítéki nyomvonallá.

GDPR: a tárca ígérete az adattakarékosság, de ezt bizonyítani kell

Az Európai Digitális Személyazonossági Tárca támogathatja a magánszféra védelmét erősítő ügyfél-regisztrációt, mert az elfogadó fél teljes személyazonosító okmányok gyűjtése helyett konkrét attribútumokat kérhet be. A GDPR szerinti elszámoltathatóság azonban nem jó szándékokon alapul. Igazolható megfelelést követel meg.

A tárcából származó attribútumok személyes adatok, ha azonosított vagy azonosítható személyhez kapcsolódnak. Egyes használati esetek biometrikus adatokat, személyazonosság-ellenőrzési adatokat, szankciószűrést, csalási kockázatot vagy más érzékeny adatkezelési kontextust is érinthetnek.

A GDPR alapelvei jogszerű, tisztességes és átlátható adatkezelést, meghatározott célokat, adattakarékosságot, pontosságot, tárolási korlátozást, sértetlenséget és bizalmasságot, valamint elszámoltathatóságot követelnek meg. Az elfogadó félnek bizonyítania kell tudnia, miért kér be minden egyes tárcaattribútumot, meddig őrzi meg, ki férhet hozzá, hogyan védi, és hogyan kontrollálja az újrafelhasználást.

A Clarysec vállalati adatvédelmi szabályzata kimondja:

„Csak konkrét, jogszerű üzleti célhoz szükséges adatok gyűjthetők és kezelhetők.”
Forrás: Adatvédelmi és magánszféra-védelmi szabályzat, „A szabályzat végrehajtásának követelményei” szakasz, 6.2.1 szabályzati pont.

A KKV-változat szándékosan tömör:

„Csak a szükséges minimális személyes adat gyűjthető és őrizhető meg”
Forrás: Adatvédelmi és magánszféra-védelmi szabályzat – KKV, „A szabályzat végrehajtásának követelményei” szakasz, 6.2.1 szabályzati pont.

A Zenith Controls az ISO/IEC 27002:2022 5.34 A magánszféra védelme és a PII védelme kontrollt az eszköznyilvántartáshoz, az adatmaszkoláshoz, a felhőszolgáltatások irányításához, az információosztályozáshoz, a biztonságos továbbításhoz, a hozzáférés-szabályozáshoz, az identitáskezeléshez és a projektváltozások felülvizsgálatához rendeli. Kapcsolódik továbbá az ISO/IEC 27701:2021 adatvédelmi irányításhoz, az ISO/IEC 27018 felhőben történő PII-adatkezeléshez és az ISO/IEC 29100 adatvédelmi alapelveihez.

Tárcaalkalmazás esetén az adatvédelmi bizonyítékcsomagnak tartalmaznia kell:

• adatáramlási diagramot a tárcaattribútumokhoz;
• jogalap-nyilvántartási bejegyzést;
• attribútumminimalizálási döntési bejegyzést;
• megőrzési ütemtervet a tárcából származó adatokra;
• adatvédelmi tájékoztató frissítését;
• DPIA-t vagy adatvédelmi kockázatértékelést, ha a használati eset magas kockázatú;
• hozzáférés-szabályozási mátrixot a tárcaadatokhoz;
• adattörlési és helyesbítési folyamatot;
• felügyeleti bizonyítékot arról, hogy a tárcából származó PII-hoz való hozzáférés kontrollált.

Sok szervezet túl sok adatot gyűjt, mert a tárca megkönnyíti az ellenőrzött adatok beszerzését. Ez fordított logika. A biztonsági és adatvédelmi előny abból származik, hogy kevesebbet kérünk be, nem abból, hogy a szükségesnél több ellenőrzött személyazonossági adatot tárolunk.

NIS2 és DORA: igazgatósági elszámoltathatóság és tárcareziliencia

A NIS2 és a DORA egyaránt irányítási szintre emeli a kiberbiztonságot. Előírják, hogy a vezető testületek hagyják jóvá, felügyeljék és vállaljanak felelősséget a kockázatkezelési intézkedésekért. Arányos technikai, működési és szervezeti kontrollokat is elvárnak.

A NIS2 Article 21 kockázatkezelési intézkedéseket ír elő, amelyek kiterjednek a szabályzatokra, incidenskezelésre, üzletmenet-folytonosságra, ellátási lánc biztonságára, biztonságos beszerzésre és fejlesztésre, sérülékenységkezelésre, kontrollhatékonyságra, kiberhigiéniára, képzésre, kriptográfiára, HR-biztonságra, hozzáférés-szabályozásra, eszközkezelésre, valamint – ahol megfelelő – többtényezős hitelesítésre vagy folyamatos hitelesítésre. A NIS2 ágazatokban működő tárcaelfogadó feleknél a tárcaintegrációnak meg kell jelennie a kockázatértékelésben, az eszköznyilvántartásban, a beszállítói nyilvántartásban, az incidenskezelési tervben és a hozzáférés-szabályozási keretrendszerben.

A NIS2 Article 23 szakaszos jelentéstételt ír elő jelentős incidensekre. Az alapvető és fontos szervezeteknek 24 órán belül korai figyelmeztetést, 72 órán belül bejelentést, egy hónapon belül pedig záró jelentést kell benyújtaniuk, adott esetben a szolgáltatást igénybe vevőknek szóló kommunikációval együtt. Ha egy tárcaintegrációs hiba működési zavart, pénzügyi veszteséget vagy lényeges vagy nem vagyoni kárt okozhat a szolgáltatást igénybe vevőknek, szerepelnie kell az incidensosztályozási logikában.

A DORA a pénzügyi szervezetek számára részletesebb. Belső irányítási és kontrollkeretrendszert követel meg az IKT-kockázatokra, igazgatóság által jóváhagyott rezilienciastratégiát, IKT-szabályzatokat, üzletmenet-folytonossági és reagálási terveket, auditterveket, harmadik felekre vonatkozó szabályzatokat, incidensbejelentési csatornákat és dokumentált IKT-kockázatkezelési keretrendszert. Előírja továbbá az IKT-hoz kapcsolódó incidensek kezelését, olyan szempontok szerinti osztályozását, mint az érintett ügyfelek száma, a kiesési idő, a földrajzi kiterjedés, az adatvesztés, a kritikusság és a gazdasági hatás, valamint a jelentős IKT-hoz kapcsolódó incidensek bejelentését.

Pénzügyi szolgáltatásokban a tárcaalapú ügyfél-regisztráció bizonyítékainak azt kell mutatniuk, hogy:

• a tárcaintegráció szerepel az IKT-eszköz- és folyamatnyilvántartásban;
• a kockázatokat értékelték, és a megfelelő felelős elfogadta;
• az ügyfél-regisztráció vagy fiókhozzáférés kritikusságát értékelték;
• léteznek reziliencia- és tartalékmegoldások;
• az incidensek DORA-kritériumok szerint osztályozhatók;
• ügyfélértesítések elő vannak készítve, ahol a pénzügyi érdekek érintettek;
• a kiszervezett jelentéstétel, ha alkalmazzák, nem szünteti meg az elszámoltathatóságot.

A kulcs az arányosság. Egy kis fintech és egy nagy bank nem ugyanakkora bizonyítékmennyiséget fog előállítani, de mindkettőnek visszakövethető irányításra van szüksége.

Beszállítói és felhőfüggőségek: a tárcafolyamat csak annyira erős, mint a lánc

A tárcát elfogadó felek legtöbb bevezetése külső szolgáltatásokat érint: felhőben történő hosztolást, API-átjárókat, ellenőrzési könyvtárakat, identitásbrókereket, KYC-beszállítókat, csalásfelderítő motorokat, naplózási platformokat, menedzselt észlelési és reagálási szolgáltatókat vagy ügyféltámogatási eszközöket. Ez központi jelentőségűvé teszi a beszállítói irányítást.

A NIS2 előírja, hogy a szervezetek vegyék figyelembe a beszállítóspecifikus sérülékenységeket, valamint a beszállítók és szolgáltatók általános minőségét és kiberbiztonsági gyakorlatait. A DORA ennél tovább megy a pénzügyi szervezetek esetében: nyilvántartást követel meg az IKT-szolgáltatások szerződéses megállapodásairól, szerződéskötést megelőző értékeléseket, koncentrációs kockázatelemzést, kellő gondosságot, audit- és ellenőrzési megközelítéseket, felmondási jogokat és tesztelt kilépési stratégiákat az olyan IKT-szolgáltatásokhoz, amelyek kritikus vagy fontos funkciókat támogatnak.

A Zenith Blueprint Kontrollok működésben szakaszának 23. lépésében a Clarysec arra utasítja a csapatokat, hogy állítsanak össze teljes beszállítói listát, osztályozzák a szolgáltatókat rendszerekhez, adatokhoz vagy operatív kontrollhoz való hozzáférés szerint, építsék be az elvárásokat a szerződésekbe, azonosítsák az alvállalkozókat, határozzák meg a változásokat kiváltó feltételeket, és alakítsanak ki felhőszolgáltatás-értékelési folyamatot. Ugyanez a lépés javasolja az adathely, a hozzáférési modell, a naplózás és a titkosítás értékelését a jövőbeli felhőszolgáltatások jóváhagyása előtt.

A Clarysec KKV-beszállítói szabályzata egyértelmű minimumhozzáférési szabályt ad:

„A beszállítóknak csak azokhoz a minimálisan szükséges rendszerekhez és adatokhoz adható hozzáférés, amelyek a feladatuk ellátásához szükségesek.”
Forrás: Harmadik fél és beszállítói biztonsági szabályzat – KKV, „A szabályzat végrehajtásának követelményei” szakasz, 6.2.1 szabályzati pont.

A NIST CSF 2.0 támogatja ezt az integrált nézetet. GOVERN funkciója magában foglalja a jogi, szabályozási, szerződéses és adatvédelmi kötelezettségeket, a kockázatvállalási hajlandóságot, az elszámoltathatóságot, a szabályzatokat, az erőforrásokat és a felügyeletet. Ellátási láncra vonatkozó eredményei beszállítói szerepköröket, kritikussági priorizálást, szerződéses kiberbiztonsági követelményeket, kellő gondosságot, felügyeletet, incidens-tervezést és kapcsolat megszűnése utáni rendelkezéseket írnak elő.

A COBIT 2019 auditorai az irányítási érettséget fogják keresni. Azt kérdezik majd, hogy a beszállítói felelősségek, az identitáséletciklus, az adatvédelmi kontrollok és a felügyelet beépültek-e az üzleti folyamatokba, nem csupán a biztonsági csapat ellenőrzőlistáiba. Az identitás és a logikai hozzáférés esetében a COBIT 2019 DSS05.04, Manage user identity and logical access, különösen releváns annak értékeléséhez, hogy a fióktulajdon, a jóváhagyások, a jogosultság-hozzárendelés és a jogosultság-visszavonás kontrollált-e.

Építsünk tárcát elfogadó félre vonatkozó bizonyítékcsomagot egy délután alatt

A gyakorlati, Clarysec-stílusú gyakorlat egy konkrét használati esettel kezdődik, nem átfogó programnyilatkozattal. Első bejegyzésként használható például: „ügyfél-regisztráció tárcából származó hivatalos név, születési dátum és cím alapján”. Adjuk hozzá az üzleti felelőst, a rendszerfelelőst, az adatgazdát és a kockázatgazdát.

Rögzítsük:

• az adatkezelés célját;
• a kért tárcaattribútumokat;
• hogy az attribútumokat tároljuk, gyorsítótárazzuk vagy csak ellenőrizzük;
• az érintett rendszereket és API-kat;
• a beszállítókat és al-adatfeldolgozókat;
• az érintett országokat vagy felhőrégiókat;
• a tartalékfolyamatot, ha a tárcaellenőrzés meghiúsul;
• az ügyfélkommunikációs érintkezési pontokat.

Ezután adjuk hozzá a használati esetet a megfelelési nyilvántartáshoz.

Ezután vizsgáljuk felül az alkalmazhatósági nyilatkozatot és a kockázatkezelési tervet. EUDI Wallet használati eseteknél az alábbi ISO/IEC 27002:2022 kontrollterületek jellemzően relevánsak.

Végül futtassunk le egy miniauditot. Válasszunk ki egy tárcaalapú ügyfél-regisztrációs tranzakciót, és kövessük végig:

1. az attribútumkérés indoklását;
2. az átláthatósági lépést vagy hozzájárulási nyilvántartást, ahol alkalmazandó;
3. a rendszer eseménynaplóját;
4. az API-hitelesítési bizonyítékot;
5. az ügyfél-regisztrációs eredményt megtekintő munkatársak hozzáférés-szabályozási bejegyzését;
6. az érintett beszállítót;
7. a megőrzési szabályt;
8. az incidensosztályozási útvonalat arra az esetre, ha a tranzakció csalárd lenne vagy kitettségbe kerülne.

Ha az útvonal nem követhető végig, a folyamat még nem áll készen bizonyítékként.

Hogyan tesztelik különböző auditorok ugyanazt a tárcafolyamatot

A különböző auditorok eltérő szakmai nézőpontból közelítik meg az Európai Digitális Személyazonossági Tárcát. Ugyanaz a bizonyíték több kérdést is kielégíthet, ha megfelelően strukturált.

A Zenith Controls hasznos auditmódszertani részleteket ad ezekhez a területekhez. Identitáskezelésnél az auditorok jellemzően végigkövetik a felhasználói identitásokat a beléptetésen, módosításon és kiléptetésen keresztül, egyeztetik a HR-nyilvántartásokat a fióklistákkal, vizsgálják a nem munkavállalói és szolgáltatásfiókokat, valamint keresik a megosztott rendszergazdai használatot. Biztonságos hitelesítésnél összevetik a szabályzatokat a technikai konfigurációkkal, felülvizsgálják az MFA-lefedettséget, vizsgálják a jelszó- és munkamenet-kontrollokat, és ellenőrzik a sikeres és sikertelen bejelentkezési naplókat. A magánszféra és a PII védelménél mintát vesznek DPIA-kból, érintetti kérelmek folyamataiból, adatvédelmi képzésből, PII-nyilvántartásokból, titkosításból, hozzáférési naplókból és megőrzési kontrollokból.

A Clarysec Audit- és megfelelésfelügyeleti szabályzata egyértelműen megfogalmazza a bizonyítéki célt:

„Igazolható bizonyítékok és auditnyom előállítása szabályozó hatósági megkeresések, jogi eljárások vagy ügyfélbizonyossági igények támogatására.”
Forrás: Audit- és megfelelésfelügyeleti szabályzat, „Célkitűzések” szakasz, 3.4 szabályzati pont.

Ez a kifejezés – igazolható bizonyíték – jelenti a különbséget egy szabályzattár és egy auditra felkészült megfelelési rendszer között.

Gyakori hibák a tárcára való felkészülési projektekben

Az első hiba a túlzott adatgyűjtés. A tárcák megkönnyíthetik az ellenőrzött attribútumok megszerzését, de a GDPR ezzel ellentétes magatartást követel: csak a szükséges adatokat kell gyűjteni és megőrizni. Ha a termékcsapat teljes személyazonossági információt kér be akkor is, amikor csak életkor-megerősítés szükséges, az adatvédelmi kontrollterv már hibás.

A második hiba a nem emberi identitások figyelmen kívül hagyása. A tárcaintegrációk gyakran API-kliensekre, tanúsítványokra, szolgáltatásfiókokra, automatizálási szkriptekre és titkos adatokra támaszkodnak. Ha ezeknek az identitásoknak nincs felelősük, nem rotálják, nem figyelik és nem vonják ki őket, az elfogadó fél környezete gyenge akkor is, ha maga a tárcaökoszisztéma erős.

A harmadik hiba, ha a beszállítókat puszta beszerzési papírmunkaként kezelik. A NIS2 és a DORA szerint a beszállítói biztonság működési kérdés. Kellő gondosságra, szerződéses záradékokra, felügyeletre, incidens-együttműködésre, auditálási jogra és kilépési tervekre van szükség. DORA hatálya alá tartozó szervezeteknél az IKT harmadik fél nyilvántartás alapvető megfelelési bizonyíték.

A negyedik hiba a naplózás irányítás nélkül. A túlnaplózás adatvédelmi kockázatot hozhat létre. Az alulnaplózás megsemmisíti a vizsgálati képességet. Meg kell határozni a hitelesítési, ellenőrzési, adminisztratív és incidens szempontjából releváns eseményeket, védeni kell a naplókat a módosítástól, korlátozni kell a hozzáférést, és a megőrzést össze kell hangolni a jogi és üzleti igényekkel.

Az ötödik hiba a jelentéstétel begyakorlásának elmulasztása. A NIS2 jelentős incidenseknél 24 órás, 72 órás és egy hónapos jelentéstételi elvárásokat tartalmaz. A DORA jelentős IKT-hoz kapcsolódó incidenseknél kezdeti, közbenső és záró jelentést ír elő. Ha a szervezet először egy tényleges esemény során rendeli hozzá a tárcával kapcsolatos incidenst ezekhez az idővonalakhoz, az irányítás kudarcot vallott.

Az EUDI Wallet alkalmazását auditra kész bizonyítékokká kell alakítani

Az Európai Digitális Személyazonossági Tárca megváltoztatja az ügyfél-regisztrációt és a digitális bizalmat Európában. A CISO-k, DPO-k, megfelelési vezetők, auditorok és üzleti felelősök számára azonban a nyerő lépés nem egy újabb elszigetelt megfelelési program létrehozása. A nyerő lépés az, hogy a tárcaalkalmazást beépítik az IBIR-be, és leképezik az adatvédelemre, identitásra, hitelesítésre, beszállítókra, naplózásra, rezilienciára és incidensreagálásra.

A Clarysec ebben strukturáltan tud segíteni:

1. Használja a Zenith Blueprintet, hogy a tárcaalkalmazást a Kockázatkezelés szakaszba helyezze: a 14. lépésben a szabályozási kereszthivatkozásokhoz, a 19. lépésben a biztonságos hitelesítéshez, a 23. lépésben pedig a beszállítói, adatvédelmi és jogi kontrollok végrehajtásához.
2. Használja a Zenith Controls útmutatót az ISO/IEC 27002:2022 identitáskezelési, biztonságos hitelesítési és adatvédelmi kontrolljainak GDPR, NIS2, DORA, NIST és COBIT 2019 bizonyítékokra történő leképezéséhez.
3. Használja a Clarysec szabályzatsablonjait, például a Jogi és szabályozói megfelelési szabályzatot, az Adatvédelmi és magánszféra-védelmi szabályzatot, a Felhasználói fiók- és jogosultságkezelési szabályzatot, a Naplózási és felügyeleti szabályzatot, a Harmadik fél és beszállítói biztonsági szabályzat – KKV és az Audit- és megfelelésfelügyeleti szabályzatot, hogy a kötelezettségeket felelősökkel rendelkező, tesztelhető gyakorlatokká alakítsa.
4. Építse fel a tárcát elfogadó fél bizonyítékcsomagját az éles indulás előtt, ne az első auditkérés után.

Ha szervezete 2026-ban az Európai Digitális Személyazonossági Tárcára kíván támaszkodni, most kell feltenni egy kérdést: tudjuk-e igazolható bizonyítékokkal bizonyítani, hogy ez a személyazonossági folyamat biztonságos, jogszerű, reziliens és irányított?

A Clarysec válasza gyakorlati: képezze le, rendeljen hozzá felelőst, tesztelje, és tartsa készen a bizonyítékokat.