Kriptográfiai kulcskezelés ISO 27001, NIS2 és DORA követelményekhez

Hétfő reggel 08:17-kor egy európai SaaS-vállalat CISO-ja üzenetet kap a mérnöki vezetőtől: „A hétvégén végrehajtottuk az adatbázis titkosítási kulcsának rotációját, de az egyik integráció nem tudta visszafejteni a bejegyzéseket. Visszaálltunk a titoktárban lévő régi kulcsra.”

Tíz perccel később a DPO azt kérdezi, hogy az érintett bejegyzések tartalmaznak-e uniós személyes adatokat. A pénzügy azt kérdezi, hogy ez bejelentésköteles működési incidenssé válhat-e egy szabályozott ügyfél számára. A beszerzés azt kérdezi, hogy a felhőszolgáltató vagy a vállalat birtokolja-e az ügyfél által kezelt kulcsot. A CEO pedig azt az egyetlen kérdést teszi fel, amely az igazgatósági teremben számít: „Tudjuk bizonyítani, hogy ezt megfelelően kezeltük?”

Ez az a pillanat, amikor a „használunk titkosítást” megnyugtató állításból bizonyítási problémává válik.

2026-ban a kriptográfiai kulcskezelés az ISO/IEC 27001:2022 kontrollok, a NIS2 szerinti kiberhigiénia, a DORA szerinti IKT-kockázatkezelés, a GDPR Article 32 szerinti adatkezelés-biztonsági bizonyítékok, a felhőben alkalmazott megosztott felelősségi modell és a posztkvantum kriptoagilitási tervezés metszéspontjában áll. A valódi kérdés nem az, hogy van-e titkosítás. A valódi kérdés az, hogy a szervezet nyilvántartásokkal igazolni tudja-e: a kulcsokat biztonságosan generálják, tulajdonosokhoz rendelik, jóváhagyott KMS- vagy HSM-környezetben tárolják, ütemezetten rotálják, biztonságosan helyreállítják, kompromittálódás esetén visszavonják, és üzleti kockázathoz rendelik.

A Clarysec a felkészültségi munkák során újra és újra ugyanazt a mintázatot látja. A titkosítás rendszerenként megvalósul, de a kulcsok irányítása széttagolt. A tanúsítványok táblázatokban élnek. A felhőalapú KMS-jogosultságok régi projektekből öröklődnek. A fejlesztők tudják, mely titkok számítanak, de az IBIR nem. Az auditorok életciklus-bizonyítékok helyett képernyőképeket kapnak. A NIS2- és DORA-csapatok rezilienciáról beszélnek, az adatvédelmi csapatok GDPR szerinti titkosításról és álnevesítésről, de senki sem felel végponttól végpontig a kriptográfiai kontrollsíkért.

Az érett válasz nem önmagában a több kriptográfia. Az érett válasz az irányított kriptográfiai kulcskezelés, amely kapcsolódik a kockázatkezeléshez, a felhőarchitektúrához, a beszállítói felügyelethez, a hozzáférés-szabályozáshoz, a naplózáshoz, az incidensreagáláshoz és a szabályozói bizonyítékokhoz.

Miért vált a kulcskezelés irányítási kérdéssé

A NIS2 a kriptográfiára és titkosításra vonatkozó szabályzatokat az alapvető és fontos szervezetek minimális kiberbiztonsági kockázatkezelési intézkedéseinek részévé teszi. Az Article 21 megfelelő és arányos technikai, működési és szervezeti intézkedéseket ír elő, beleértve a kockázatelemzést, az incidenskezelést, a folytonosságot, az ellátási lánc biztonságát, a biztonságos fejlesztést, a kiberhigiéniát, a hozzáférés-szabályozást, az eszközkezelést, valamint a kriptográfiai és titkosítási szabályzatokat. Az irányító testületeknek jóvá kell hagyniuk és felügyelniük kell a kiberbiztonsági kockázatkezelési intézkedéseket.

SaaS-, felhő-, menedzselt szolgáltatási és kiberbiztonsági szolgáltatók esetében az alkalmazhatóság szélesebb lehet, mint azt sok csapat feltételezi. A NIS2 olyan ágazatokat fed le, mint a digitális infrastruktúra, felhőszolgáltatók, adatközpont-szolgáltatók, DNS-szolgáltatók, bizalmi szolgáltatók, menedzselt szolgáltatók, menedzselt biztonsági szolgáltatók, online piacterek, keresőmotorok és közösségimédia-platformok, amennyiben a méretre vagy kritikusságra vonatkozó küszöbértékek teljesülnek.

A DORA magasabb elvárásokat támaszt a pénzügyi szervezetekkel szemben. 2025. január 17-től a DORA dokumentált IKT-kockázatkezelési keretrendszert, igazgatósági elszámoltathatóságot, IKT-üzletmenet-folytonossági, reagálási és helyreállítási terveket, digitális működési rezilienciatesztelést, IKT harmadik féllel kapcsolatos kockázatkezelést és incidensjelentést ír elő. A NIS2 nemzeti szabályai alapján azonosított pénzügyi szervezetek esetében a DORA az egyenértékű NIS2-kötelezettségek ágazatspecifikus uniós jogi aktusaként működik. Egy fintechnek nem külön kriptográfiai irányítást kell működtetnie NIS2, DORA és ISO célokra. Egyetlen, igazolható kontrollmodellre van szüksége.

A GDPR hozzáadja az adatvédelmi bizonyítékok dimenzióját. A GDPR Article 32 az a pont, ahol a titkosítást gyakran az adatkezelés biztonságát szolgáló védelmi intézkedésként értékelik, de az, hogy „az adatok titkosítva vannak”, nem teljes válasz. A szabályozó hatóságok és az auditorok azt kérdezik, ki kontrollálja a kulcsokat, hogyan korlátozzák a hozzáférést, hogyan észlelik a kompromittálódást, hogyan működik a helyreállítás, és hogy a kialakítás megfelel-e az érintetteket fenyegető kockázatnak.

Az ISO/IEC 27001:2022 biztosítja azt az irányítási rendszert, amely ezeket a kötelezettségeket összekapcsolja. A 4.1–4.4 pontok kontextust, érdekelt felek követelményeit, IBIR alkalmazási területet és egymással kölcsönhatásban lévő folyamatokat írnak elő. Az 5.1–5.3 pontok vezetést, szabályzatot, erőforrásokat és kijelölt felelősségeket követelnek meg. A 6.1.1–6.1.3 pontok kockázatértékelést, kockázatkezelést, kontrollkiválasztást, alkalmazhatósági nyilatkozatot és kockázatgazdai jóváhagyást írnak elő. A 8.1–8.3 pontok szabályozott működést, változások esetén kockázat-újraértékelést, kockázatkezelési tervek végrehajtását és a dokumentált eredmények megőrzését követelik meg.

A kriptográfiai kulcskezelés tekintetében az IBIR-nek öt kérdésre kell választ adnia:

1. Mely információs vagyon, adatáramlások és szolgáltatások igényelnek kriptográfiai védelmet?
2. Mely kulcsok, tanúsítványok, titkok és kriptográfiai szolgáltatások védik ezeket?
3. Ki a kriptográfiai eszközök tulajdonosa, adminisztrátora, jóváhagyója és felügyelője?
4. Hogyan kontrollált a generálás, tárolás, használat, kulcsrotáció, letétbe helyezés, helyreállítás, visszavonás és megsemmisítés?
5. Milyen bizonyítékok igazolják, hogy a kontrollok a tervezett módon működtek?

Az ISO 27001 kontrollgerince a kriptográfiai kulcskezeléshez

A Clarysec a kriptográfiai kulcskezelést kontroll-láncként kezeli, nem egyetlen kontrollként. A Zenith Controls: The Cross-Compliance Guide Zenith Controls keretében a téma elsősorban az ISO/IEC 27002:2022 8.24, Use of cryptography kontrollhoz kapcsolódik, fontos támogató kapcsolatokkal az 5.17, Authentication information és az 5.23, Information security for use of cloud services területekhez.

Ez a kapcsolat lényeges. A kulcskezelési hiba ritkán pusztán „rossz titkosítás”. Gyakran hitelesítési probléma, felhőirányítási probléma, beszállítói probléma, naplózási hiányosság vagy változáskezelési hiba.

A Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint ezt működőképessé teszi a Kockázatkezelési fázis 14. lépésében, a Kockázatkezelési szabályzatok és szabályozói kereszthivatkozások alatt. A kriptográfiai szabályzatmintája szerint a szervezetnek meg kell határoznia, hol szükséges kriptográfia, jóvá kell hagynia az algoritmusokat és protokollokat, meg kell határoznia a kulcskezelést, le kell fednie olyan felhasználási eseteket, mint a teljes lemeztitkosítás és a biztonságos kommunikáció, valamint össze kell kapcsolnia a szabályzatot a GDPR Article 32 követelményeivel.

„A titkosítási kulcsokat biztonságosan kell tárolni (pl. kulcstárban/HSM-ben), és a hozzáférést jogosult személyekre kell korlátozni.”
Hivatkozás: Zenith Blueprint, Kockázatkezelési fázis, 14. lépés, Kockázatkezelési szabályzatok és szabályozói kereszthivatkozások Zenith Blueprint

A Kontrollok működésben fázis 20. lépésében a Zenith Blueprint mélyebbre megy. A kriptográfia nem a „titkosítás bekapcsolásáról” szól. Arról szól, hogy a kriptográfiát be kell építeni a tervezésbe, a szabályzatba és az életciklus-kezelésbe. Ez magában foglalja a tárolt adatokat, a továbbított adatokat, az identitások és tranzakciók hitelesítését, a jóváhagyott algoritmusokat, kulcstárakat, HSM-eket, ütemezett kulcsrotációt, visszavonást, valamint a penetrációs teszteléssel és kódfelülvizsgálattal végzett ellenőrzést.

Mit várnak az auditorok, amikor kulcsokra vonatkozó bizonyítékot kérnek

A legtöbb auditmegállapítás egy egyszerű kéréssel indul: „Mutassa meg a titkosítási szabályzatot és a kulcskezelési nyilvántartásokat.”

Gyenge válaszok például:

• „A felhőszolgáltató alapértelmezetten mindent titkosít.”
• „TLS-t használunk.”
• „A titkok a titoktárban vannak.”
• „A mérnöki csapat kezeli a rotációt.”
• „A kulcsot az alkalmazás kezeli.”

Ezek az állítások műszakilag igazak lehetnek, de nem teljes bizonyítékok. Egy ISO-auditor a kulcskezelést visszaköti a kockázatértékeléshez, az alkalmazhatósági nyilatkozathoz, a szabályzati követelményekhez, az operatív kontrollhoz és a megőrzött dokumentációhoz. Egy NIST CSF értékelő azt fogja kérdezni, hogy a kriptográfiai eszközök azonosítottak, védettek, felügyeltek és helyreállíthatók-e. Egy DORA-auditor igazgatóság által jóváhagyott IKT-kockázatirányítást, harmadik felektől való függőségeket, incidenskezelést és rezilienciatesztelést keres. Egy GDPR-felülvizsgáló azt kérdezi, hogy a titkosítás és a kulcsok szétválasztása csökkenti-e az érintetteket fenyegető kockázatot, és hogy az adatkezelő igazolni tudja-e az elszámoltathatóságot.

A Clarysec vállalati Kriptográfiai kontrollok szabályzata Kriptográfiai kontrollok szabályzata közvetlenül kezeli ezt a bizonyítékrést:

„Központi Kulcskezelési Nyilvántartást kell fenntartani valamennyi kriptográfiai kulcs, életciklusállapotuk, kijelölt gondnokaik és felhasználási kontextusaik rögzítésére.”
Hivatkozás: Vállalati szabályzat, Kriptográfiai kontrollok szabályzata, Irányítási követelmények, 5.2 pont Kriptográfiai kontrollok szabályzata

Ez a mondat megváltoztatja az auditbeszélgetést. A szervezetnek nem törzsi tudást kell felkutatnia, hanem be tud mutatni egy nyilvántartást, amely összeköti a kulcsokat az eszközökkel, tulajdonosokkal, adatosztályozásokkal, rendszerekkel, felhőfiókokkal, rotációs dátumokkal, felhasználási kontextusokkal és bizonyítékokkal.

KKV-k számára a Clarysec Kriptográfiai kontrollok szabályzata – KKV Kriptográfiai kontrollok szabályzata – KKV ugyanezt az elvárást arányosan alkalmazza:

„Az IT-támogatási szolgáltatónak naprakész nyilvántartást kell vezetnie a használatban lévő kriptográfiai eszközökről és tanúsítványokról.”
Hivatkozás: KKV-szabályzat, Kriptográfiai kontrollok szabályzata – KKV, Irányítási követelmények, 5.1.2 pont Kriptográfiai kontrollok szabályzata – KKV

Egy szabályozott pénzügyi intézménynek szüksége lehet HSM-ceremóniákra, megosztott ismeretre, kettős kontrollra, formális kulcsgondnoki kijelölésekre és negyedéves hozzáférés-felülvizsgálatokra. Egy kisebb SaaS-szolgáltató karbantartott leltárral, jóváhagyott algoritmusokkal, dokumentált KMS-tulajdonlással és rotációs bizonyítékokkal kezdheti. Mindkettőnek kockázatarányos irányításra van szüksége.

Az a kulcséletciklus, amelyet az IBIR-nek kontrollálnia kell

A gyakorlati kulcskezelési program az életciklust követi. Minden szakaszhoz tulajdonos, jóváhagyott módszer, technikai kontroll, változásbejegyzés és auditbizonyíték szükséges.

A vállalati Kriptográfiai kontrollok szabályzata megerősíti a biztonságos generálást:

„Kulcsgenerálás: biztonságos hardver- vagy szoftvermodulokkal történik (pl. HSM-ek, FIPS 140-2 szerint ellenőrzött rendszerek).”
Hivatkozás: Vállalati szabályzat, Kriptográfiai kontrollok szabályzata, A szabályzat végrehajtásának követelményei, 6.3.1 pont Kriptográfiai kontrollok szabályzata

A rotációt is meghatározza:

„Kulcsrotáció: meghatározott időközönként, illetve kompromittálódás vagy szerepkör-változás esetén azonnal szükséges.”
Hivatkozás: Vállalati szabályzat, Kriptográfiai kontrollok szabályzata, A szabályzat végrehajtásának követelményei, 6.3.4 pont Kriptográfiai kontrollok szabályzata

KKV-k esetében ugyanez az elv egyszerűbb üzemeltetési nyelven jelenik meg:

„A kulcsrotációnak a lejárati ütemezések szerint vagy feltételezett kompromittálódás esetén kell megtörténnie.”
Hivatkozás: KKV-szabályzat, Kriptográfiai kontrollok szabályzata – KKV, A szabályzat végrehajtásának követelményei, 6.3.4 pont Kriptográfiai kontrollok szabályzata – KKV

Ezek a pontok a NIS2 és a DORA szempontjából azért fontosak, mert az elavult vagy rosszul irányított kulcsok nem csupán bizalmassági gyengeségek. Incidensreagálási akadályokká, beszállítói függőségi problémákká, katasztrófa utáni helyreállítási hibákká és ügyfélértesítési problémákká válhatnak.

Felhőalapú KMS, HSM és BYOK: a megosztott felelősség csapdája

A felhőalapú titkosítás a hamis biztonságérzet egyik leggyakoribb forrása. Egy felhőszolgáltató alapértelmezetten titkosíthatja a tárolást, de ez önmagában nem jelenti azt, hogy a szervezet irányítja a kulcsot.

A Zenith Blueprint Kontrollok működésben fázisának 23. lépése az ISO/IEC 27002:2022 5.23 kontrollt a felhőirányításra, átláthatóságra és megosztott felelősségre fókuszálva magyarázza. Kiemeli, hogy a szolgáltató biztosíthatja az infrastruktúrát, de az ügyfél továbbra is felelős az adataiért, konfigurációiért, hozzáférési szabályzataiért és incidensreagálási felkészültségéért.

„A felhőszolgáltatók biztosítják az infrastruktúrát, de továbbra is Ön felelős az adataiért, a konfigurációiért, a hozzáférési szabályzataiért és az incidensreagálási felkészültségéért.”
Hivatkozás: Zenith Blueprint, Kontrollok működésben fázis, 23. lépés, Szervezeti kontrollok 5.19–5.37 Zenith Blueprint

Itt válik a felhőbeli kulcsfelelősség igazgatósági szintű kockázattá. Egy SaaS-vállalat használhat szolgáltató által kezelt titkosítást alacsony kockázatú naplókhoz, ügyfél által kezelt kulcsokat ügyféladatbázisokhoz, BYOK-ot szabályozott bérlőkhöz és HSM-mel támogatott gyökérkulcsokat aláíráshoz vagy tokenizációhoz. Minden döntésnek megfelelési következménye van.

A Clarysec vállalati Felhőszolgáltatások használatára vonatkozó szabályzata Felhőszolgáltatások használatára vonatkozó szabályzat egyértelmű kontrollirányt ad:

„Ügyfél által kezelt kulcsokat (CMK-k) vagy Bring Your Own Key (BYOK) megoldást kell használni, ahol ezt a felhőszolgáltató támogatja.”
Hivatkozás: Vállalati szabályzat, Felhőszolgáltatások használatára vonatkozó szabályzat, A szabályzat végrehajtásának követelményei, 6.4.2 pont Felhőszolgáltatások használatára vonatkozó szabályzat

Ez nem jelenti azt, hogy minden felhőszolgáltatásnak BYOK-ot kell használnia. Azt jelenti, hogy a szervezetnek tudatosan kell döntenie, kockázat, ügyfélvállalások, szerződéses követelmények és helyreállíthatóság alapján.

A DORA Article 28 és Article 30 ezt különösen relevánssá teszi a pénzügyi szervezetek számára. IKT harmadik féllel kapcsolatos kockázatkezelést, az IKT-szerződéses megállapodások nyilvántartását, kellő gondosságot, auditálási és vizsgálati jogokat, incidenssegítséget, adatvédelmet és hozzáférést, helyreállítási és visszaszolgáltatási rendelkezéseket írnak elő. Ha egy felhőszolgáltató vagy SaaS-beszállító titkosítási kulcsokat kezel kritikus vagy fontos funkcióhoz, ennek a kapcsolatnak láthatónak kell lennie az IKT harmadik fél nyilvántartásban és a szerződéses kontrollokban.

A NIS2 ellátásilánc-biztonságot is előír, beleértve a beszállító-specifikus sérülékenységeket, kiberbiztonsági gyakorlatokat és biztonságos fejlesztési eljárásokat. Ha egy kritikus beszállító birtokolja a kulcsait, üzemelteti a KMS-ét, biztosítja a HSM-et, kezeli a tanúsítvány-életciklust vagy hosztolja a titkosított biztonsági mentéseket, akkor a beszállító a kriptográfiai kontrollkörnyezet része.

Algoritmus-jóváhagyás és kriptoagilitás 2026-ban

Egy 2026-os kulcskezelési szabályzatnak nem csak az „AES-256” és a „TLS 1.2 vagy újabb” tételeket kell felsorolnia. Olyan jóváhagyási és felülvizsgálati folyamatot kell kialakítania, amely támogatja a kriptoagilitást. A kriptoagilitás azt jelenti, hogy a szervezet azonosítani tudja, hol használnak algoritmusokat, protokollokat, tanúsítványokat és kulcshosszakat, fel tudja mérni a gyengeségnek vagy elavulásnak való kitettséget, és pánik nélkül tud migrálni.

A Clarysec KKV-szabályzata kimondja:

„Csak az IT-támogatási szolgáltató által jóváhagyott iparági legjobb gyakorlat szerinti algoritmusok és protokollok használhatók (pl. AES-256, RSA 2048, TLS 1.2 vagy újabb).”
Hivatkozás: KKV-szabályzat, Kriptográfiai kontrollok szabályzata – KKV, A szabályzat végrehajtásának követelményei, 6.2.1 pont Kriptográfiai kontrollok szabályzata – KKV

Dokumentálást is előír:

„Minden titkosítási módszert (pl. AES-256, TLS 1.2+) és kulcskezelési folyamatot dokumentálni kell.”
Hivatkozás: KKV-szabályzat, Kriptográfiai kontrollok szabályzata – KKV, Irányítási követelmények, 5.3.1 pont Kriptográfiai kontrollok szabályzata – KKV

Az auditra való felkészültséget biztosító változat egy jóváhagyott kriptográfiai szabvány, amely tartalmazza:

• Engedélyezett algoritmusok és protokollok tárolt adatokhoz, továbbított adatokhoz, aláírásokhoz, jelszó-hash-eléshez, tokenizációhoz és biztonsági mentésekhez.
• Tiltott algoritmusok, protokollok és könyvtárak.
• Minimális kulcshosszak és tanúsítvány-érvényességi idők.
• Jóváhagyott KMS-, HSM-, hitelesítésszolgáltatói és titokkezelő platformok.
• Biztonságos véletlenszám-generálási követelmények.
• Fejlesztői útmutatás kriptográfiai könyvtárakhoz.
• Kivételkezelési folyamat örökölt rendszerekhez.
• Felülvizsgálati kiváltó okok sérülékenységek, szabályozási változások, beszállítói változások és posztkvantum átállási tervezés esetére.

A posztkvantum tervezés nem követeli meg, hogy minden szervezet azonnal lecserélje az összes kriptográfiát. Leltárt viszont megkövetel. Kriptográfiai leltár nélkül nem lehet tudni, mely rendszerek használnak hosszú élettartamú nyilvános kulcsú titkosítást, mely tanúsítványok védik a kritikus szolgáltatásokat, hol találhatók az aláírókulcsok, vagy mely beszállítóknak kell támogatniuk a migrációt. A Kulcskezelési Nyilvántartás nem bürokrácia. A kriptoagilitás alapja.

90 perces kulcskezelési bizonyíték-sprint

A Clarysec gyakran alkalmaz rövid bizonyíték-sprintet a vezetés, a biztonsági, felhő- és megfelelőségi csapatok bevonásával. A cél, hogy a szétszórt kulcsismeret gyorsan auditbizonyítékká alakuljon.

1. lépés: Válasszon ki egy kritikus szolgáltatást

Válasszon olyan rendszert, amely számít a NIS2, a DORA vagy a GDPR szempontjából. Ilyen lehet az ügyfélidentitás-kezelés, fizetésfeldolgozás, tranzakciófigyelés, éles ügyféladatbázis, titkosított biztonsági mentési platform vagy ügyféloldali API.

2. lépés: Nyissa meg a Kulcskezelési Nyilvántartást

A struktúrához használja a Kriptográfiai kontrollok szabályzata központi nyilvántartásra vonatkozó követelményét. Ha még nincs ilyen, hozzon létre egyszerű nyilvántartást az alábbi mezőkkel:

3. lépés: Kövesse végig a hozzáférést és a kettős kontrollt

Nagy hatású kriptográfiai műveletek esetén alkalmazni kell a kettős kontrollt és a legkisebb jogosultság elvét. A vállalati Kriptográfiai kontrollok szabályzata kimondja:

„A kettős kontrollt és a legkisebb jogosultság elvét alkalmazni kell az érzékeny kriptográfiai műveletekre (pl. gyökérkulcs-importok, HSM-adminisztráció).”
Hivatkozás: Vállalati szabályzat, Kriptográfiai kontrollok szabályzata, A szabályzat végrehajtásának követelményei, 6.6.2 pont Kriptográfiai kontrollok szabályzata

Tegye fel a következő kérdéseket:

• Ki tilthatja le vagy törölheti a kulcsot?
• Ki módosíthatja a kulcsszabályzatot?
• Ki fejtheti vissza közvetlenül az adatokat?
• A break-glass szerepkörök felügyeltek és időkorlátosak?
• Az MFA kikényszerített a kiemelt jogosultságú kulcsműveleteknél?
• A kiemelt jogosultságú műveletek naplózottak és felülvizsgáltak?

4. lépés: Gyűjtsön be öt bizonyítékot

Gyűjtsön össze öt bejegyzést, amely igazolja a kontroll működését:

1. Kulcslétrehozási vagy importálási napló.
2. Aktuális KMS- vagy HSM-hozzáférési szabályzat.
3. Legutóbbi kulcsrotációhoz kapcsolódó változásjegy.
4. SIEM-lekérdezés, amely kulcshasználatot vagy adminisztratív műveleteket mutat.
5. Helyreállítási vagy visszaállítási teszt bizonyítéka.

5. lépés: Képezze le kockázatra és szabályozásra

Adjon hozzá rövid kockázati állítást: „A kulcs jogosulatlan használata vagy elvesztése uniós személyes adatok kitettségéhez, ügyfélszolgáltatás-kieséshez és kritikus rendszerek helyreállításának akadályozásához vezethet.” Ezután képezze le a releváns kötelezettségekre.

90 perc alatt a csapat általában meg tudja állapítani, hogy a kulcsirányítás valós vagy csak feltételezett.

Incidensjelentés: amikor a kulcskompromittálódás elindítja az órát

A feltételezett kulcskompromittálódás nem automatikusan bejelentésköteles adatvédelmi incidens, de elindíthatja a szabályozói határidőket.

A NIS2 alapján az alapvető és fontos szervezeteknek indokolatlan késedelem nélkül be kell jelenteniük a szolgáltatásnyújtást érintő jelentős incidenseket. A szakaszos modell tartalmazza a tudomásszerzéstől számított 24 órán belüli korai figyelmeztetést, a 72 órán belüli incidensbejelentést, a kért állapotfrissítéseket, valamint a végső jelentést legkésőbb az incidensbejelentést követő egy hónapon belül.

A DORA alapján a pénzügyi szervezeteknek észlelniük, kezelniük és bejelenteniük kell az IKT-vonatkozású incidenseket, nyilván kell tartaniuk az incidenseket és jelentős kiberfenyegetéseket, súlyosság és érintett szolgáltatáskritikusság szerint osztályozniuk kell az incidenseket, kommunikálniuk kell az érdekelt felekkel, jelenteniük kell a jelentős incidenseket a felső vezetésnek és az illetékes hatóságoknak, gyökérok-elemzést kell végezniük és helyesbítő intézkedéseket kell végrehajtaniuk. A jelentéstétel kiszervezése lehetséges lehet, de a felelősség a pénzügyi szervezetnél marad.

A GDPR alapján a kérdés az, hogy történt-e személyesadat-sértés, azaz személyes adatok véletlen vagy jogellenes megsemmisítése, elvesztése, megváltoztatása, jogosulatlan közlése vagy az azokhoz való jogosulatlan hozzáférés. Az erős titkosítás nem kompromittálódott kulcsokkal érdemben megváltoztathatja az adatvédelmi incidens kockázatelemzését. A gyenge kulcskezelés alááshatja ezt az érvet.

A kulcskompromittálódási forgatókönyveknek meg kell határozniuk:

• Hogyan észlelhető a feltételezett kulcskitettség.
• Ki nyilvánítja kriptográfiai incidenssé az eseményt.
• Hogyan azonosítják az érintett adatokat, szolgáltatásokat, ügyfeleket és joghatóságokat.
• Hogyan vonják vissza vagy rotálják a kulcsokat.
• Hogyan állítják helyre a függő rendszereket.
• Hogyan őrzik meg a bizonyítékok sértetlenségét.
• Hogyan születnek jogi, szabályozói és ügyfélértesítési döntések.

A Kulcskezelési Nyilvántartás ebben a folyamatban alapvetővé válik. Enélkül a reagálók időt veszítenek annak azonosításával, hogy mit védett a kulcs. Ezzel gyorsan behatárolhatják a hatást.

Auditnézőpont: egy kontrollkészlet, több bizonyítékfelhasználó

A különböző auditorok eltérő háttérből közelítik meg a kriptográfiai kulcskezelést, de ugyanazokra a bizonyítékokra jutnak.

Egy erős auditcsomag kriptográfiai kulcskezeléshez jellemzően tartalmazza:

• Jóváhagyott Kriptográfiai kontrollok szabályzata.
• Jóváhagyott Felhőszolgáltatások használatára vonatkozó szabályzat, ahol a felhőalapú titkosítás releváns.
• Kriptográfiai szabvány és algoritmuslista.
• Kulcskezelési Nyilvántartás.
• Tanúsítvány- és titokleltár.
• KMS-, HSM- és titoktár-architektúra.
• IAM- és kiemelt jogosultságú hozzáférés-felülvizsgálati bizonyítékok.
• Rotációs és visszavonási bejegyzések.
• Biztonsági mentési, letétbe helyezési és helyreállítási tesztbizonyítékok.
• Kulcstevékenységre vonatkozó naplózási és felügyeleti szabályok.
• Beszállítói és felhőalapú megosztott felelősségi leképezés.
• Incidensforgatókönyv feltételezett kulcskompromittálódásra.
• Kivételek és kockázatelfogadások.
• Vezetőségi felülvizsgálati és auditkorrekciós bejegyzések.

Ez a csomag a kontrollállítást bizonyítékká alakítja.

Gyakori megállapítások kulcskezelési auditokban

A leggyakoribb megállapítások elkerülhetők:

1. Nincs egységes leltár a kulcsokról, tanúsítványokról és kriptográfiai eszközökről.
2. A felhőszolgáltató alapértelmezett titkosítását teljes kulcsirányításként kezelik.
3. Nincs tulajdonos vagy gondnok kijelölve az éles kulcsokhoz.
4. A rotáció létezik tanúsítványokra, de nem alkalmazáskulcsokra vagy adatbázis-CMK-kra.
5. A titkok és kulcsok ugyanabban a titoktárban vannak osztályozás nélkül.
6. A fejlesztők jóváhagyott mintákon kívül is létrehozhatnak kulcsokat.
7. Nincs bizonyíték arra, hogy a KMS-adminisztrátorokat felülvizsgálják.
8. A helyreállítási eljárások léteznek, de soha nem tesztelték őket.
9. A kulcskompromittálódás nem szerepel az incidensreagálási forgatókönyvekben.
10. Örökölt algoritmusok maradnak belső szolgáltatásokban, mert senki nem felel a helyesbítő intézkedésért.
11. BYOK-vállalások szerepelnek az ügyfélszerződésekben, de nem jelennek meg az üzemeltetésben.
12. A beszállító által kezelt titkosítás nem része a beszállítói kockázati felülvizsgálatoknak.

Minden megállapítás visszavezethető az irányításra. Ezért a kriptográfia nem kezelhető pusztán mérnöki projektként. Kapcsolódnia kell az IBIR alkalmazási területéhez, a kockázatkezeléshez, a szabályzatokhoz, a beszállítókhoz, a felhőhöz, a hozzáféréshez, a naplózáshoz, az incidensekhez és a folytonossághoz.

Tegye auditkésszé a kulcsirányítást a következő incidens előtt

Ha szervezete NIS2-re, DORA-ra, GDPR Article 32 szerinti bizonyítékokra, ISO/IEC 27001:2022 tanúsításra vagy posztkvantum kriptoagilitásra készül, kezdje egy kérdéssel: elő tud állítani ma egy teljes Kulcskezelési Nyilvántartást?

Ha nem, a Clarysec segíthet a köré épülő kontrollrendszer kialakításában.

Használja a Zenith Blueprint Zenith Blueprint útmutatót a munka strukturálásához a Kockázatkezelési fázis 14. lépésén és a Kontrollok működésben fázis 20. lépésén keresztül. Használja a Zenith Controls Zenith Controls anyagot az ISO/IEC 27002:2022 8.24, 5.17 és 5.23 kontrollok NIS2, DORA, GDPR, NIST és audit elvárások közötti leképezéséhez. Használja a Clarysec Kriptográfiai kontrollok szabályzata Kriptográfiai kontrollok szabályzata, Kriptográfiai kontrollok szabályzata – KKV Kriptográfiai kontrollok szabályzata – KKV és Felhőszolgáltatások használatára vonatkozó szabályzat Felhőszolgáltatások használatára vonatkozó szabályzat dokumentumait, hogy a követelményeket működési szabályokká alakítsa.

A gyakorlati következő lépés egyszerű: válasszon ki egy kritikus szolgáltatást, készítsen leltárt a kulcsairól, igazolja a tulajdonlást, ellenőrizze a hozzáférést, gyűjtse be a rotációs bizonyítékokat és tesztelje a helyreállítást. Ha ez több mint egy napot vesz igénybe, a kriptográfiai irányítás figyelmet igényel, mielőtt a szabályozó hatóság, az auditor vagy az incidensreagálási csapat nyomás alatt felteszi ugyanezt a kérdést.