Upravljanje kriptografskih ključev za ISO 27001, NIS2 in DORA

Ob 08:17 v ponedeljek zjutraj vodja informacijske varnosti (CISO) evropskega podjetja SaaS prejme sporočilo vodje inženiringa: »Čez konec tedna smo zamenjali ključ za šifriranje podatkovne zbirke, vendar ena integracija ni več mogla dešifrirati zapisov. Vrnili smo se na stari ključ iz trezorja ključev.«

Deset minut pozneje pooblaščena oseba za varstvo podatkov (DPO) vpraša, ali prizadeti zapisi vključujejo osebne podatke iz EU. Finance vprašajo, ali bi to lahko postal operativni incident, ki ga je treba prijaviti regulirani stranki. Nabava vpraša, ali je lastnik ključa, ki ga upravlja naročnik, ponudnik storitev v oblaku ali podjetje. Generalni direktor zastavi edino vprašanje, ki v upravnem odboru šteje: »Ali lahko dokažemo, da smo to ustrezno upravljali?«

To je trenutek, ko izjava »uporabljamo šifriranje« ni več pomirjujoča in postane vprašanje dokazil.

Leta 2026 je upravljanje kriptografskih ključev na presečišču kontrol ISO/IEC 27001:2022, kibernetske higiene NIS2, upravljanja tveganj IKT po DORA, dokazil o varnosti obdelave po GDPR Article 32, deljene odgovornosti v oblaku in načrtovanja postkvantne kriptoagilnosti. Pravo vprašanje ni, ali šifriranje obstaja. Pravo vprašanje je, ali lahko organizacija z evidencami pokaže, da so ključi varno generirani, dodeljeni lastnikom, shranjeni v odobrenih okoljih KMS ali HSM, rotirani po urniku, varno obnovljeni, preklicani ob kompromitaciji in povezani s poslovnim tveganjem.

Clarysec v pripravljalnih projektih vedno znova opaža isti vzorec. Šifriranje je uvedeno po posameznih sistemih, upravljanje ključev pa je razdrobljeno. Digitalna potrdila živijo v preglednicah. Dovoljenja KMS v oblaku so podedovana iz starih projektov. Razvijalci vedo, katere skrivnosti so pomembne, ISMS pa ne. Presojevalci prejmejo posnetke zaslona namesto dokazil o življenjskem ciklu. Ekipe za NIS2 in DORA govorijo o odpornosti, ekipe za zasebnost o šifriranju in psevdonimizaciji po GDPR, nihče pa ne prevzame celovitega lastništva nad kriptografsko kontrolno ravnino.

Zrel odgovor ni več kriptografije v izolaciji. Zrel odgovor je upravljano upravljanje kriptografskih ključev, povezano z obravnavo tveganj, arhitekturo v oblaku, nadzorom dobaviteljev, nadzorom dostopa, beleženjem, odzivom na incidente in regulativnimi dokazili.

Zakaj je upravljanje ključev zdaj vprašanje upravljanja

NIS2 uvršča politike kriptografije in šifriranja med minimalne ukrepe za upravljanje kibernetskih tveganj za bistvene in pomembne subjekte. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, vključno z analizo tveganj, obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, varnim razvojem, kibernetsko higieno, nadzorom dostopa, upravljanjem sredstev ter politikami kriptografije in šifriranja. Zahteva tudi, da organi upravljanja odobrijo in nadzorujejo ukrepe za upravljanje kibernetskih tveganj.

Za ponudnike SaaS, oblaka, upravljanih storitev in kibernetske varnosti je lahko področje uporabe širše, kot predvidevajo številne ekipe. NIS2 zajema sektorje, kot so digitalna infrastruktura, ponudniki storitev računalništva v oblaku, ponudniki podatkovnih centrov, ponudniki DNS, ponudniki storitev zaupanja, ponudniki upravljanih storitev, ponudniki upravljanih varnostnih storitev, spletne tržnice, iskalniki in platforme družbenih omrežij, kadar so izpolnjeni pragi velikosti ali kritičnosti.

DORA za finančne subjekte postavlja višjo letvico. Od 17. januarja 2025 DORA zahteva dokumentiran okvir upravljanja tveganj IKT, odgovornost upravnega organa, načrte neprekinjenega poslovanja IKT ter načrte odzivanja in obnovitve, testiranje digitalne operativne odpornosti, upravljanje tveganj tretjih oseb na področju IKT in poročanje o incidentih. Za finančne subjekte, opredeljene po nacionalnih pravilih NIS2, DORA deluje kot sektorski pravni akt Unije za enakovredne obveznosti NIS2. Fintech podjetje ne bi smelo vzpostavljati ločenega upravljanja kriptografije za NIS2, DORA in ISO. Potrebuje en zagovorljiv model kontrol.

GDPR dodaja dimenzijo dokazil o zasebnosti. GDPR Article 32 je mesto, kjer se šifriranje običajno ocenjuje kot varnostni ukrep za varnost obdelave, vendar izjava »podatki so šifrirani« ni popoln odgovor. Regulatorji in presojevalci vprašajo, kdo nadzoruje ključe, kako je dostop omejen, kako se zazna kompromitacija, kako deluje obnovitev in ali zasnova ustreza tveganju za posameznike.

ISO/IEC 27001:2022 daje organizacijam sistem upravljanja, s katerim te obveznosti povežejo. Klavzule 4.1 do 4.4 zahtevajo kontekst, zahteve zainteresiranih strani, obseg ISMS in medsebojno povezane procese. Klavzule 5.1 do 5.3 zahtevajo voditeljstvo, politiko, vire in dodeljene odgovornosti. Klavzule 6.1.1 do 6.1.3 zahtevajo oceno tveganj, obravnavo tveganj, izbor kontrol, izjavo o uporabnosti in odobritev lastnika tveganja. Klavzule 8.1 do 8.3 zahtevajo nadzorovano izvajanje, ponovno oceno tveganj ob spremembah, izvedbo načrtov obravnave tveganj in hrambo dokumentiranih rezultatov.

Za upravljanje kriptografskih ključev mora ISMS odgovoriti na pet vprašanj:

1. Katera informacijska sredstva, tokovi podatkov in storitve zahtevajo kriptografsko zaščito?
2. Kateri ključi, digitalna potrdila, skrivnosti in kriptografske storitve jih varujejo?
3. Kdo je lastnik teh kriptografskih sredstev, kdo jih upravlja, odobrava in spremlja?
4. Kako so nadzorovani generiranje, hramba, uporaba, rotacija, deponiranje, obnovitev, preklic in uničenje?
5. Katera dokazila potrjujejo, da so kontrole delovale, kot je bilo zasnovano?

Kontrolna hrbtenica ISO 27001 za upravljanje kriptografskih ključev

Clarysec upravljanje kriptografskih ključev obravnava kot verigo kontrol, ne kot eno samo kontrolo. V Zenith Controls: vodniku za navzkrižno skladnost Zenith Controls se tema primarno preslika na kontrolo 8.24 ISO/IEC 27002:2022, uporabo kriptografije, s pomembnimi podpornimi povezavami na 5.17, avtentikacijske informacije, in 5.23, informacijsko varnost pri uporabi storitev v oblaku.

Ta povezava je pomembna. Odpoved upravljanja ključev je redko samo »slabo šifriranje«. Pogosto gre za težavo avtentikacije, upravljanja oblaka, dobavitelja, vrzel v beleženju ali odpoved upravljanja sprememb.

Zenith Blueprint: 30-koračni načrt za presojevalce Zenith Blueprint to operacionalizira v fazi upravljanja tveganj, korak 14, politike obravnave tveganj in regulativni navzkrižni sklici. Vzorec kriptografske politike določa, da mora organizacija opredeliti, kje je kriptografija potrebna, odobriti algoritme in protokole, opredeliti upravljanje ključev, zajeti primere uporabe, kot sta šifriranje celotnega diska in varna komunikacija, ter politiko povezati z GDPR Article 32.

»Šifrirni ključi morajo biti varno shranjeni (npr. v trezorju ključev/HSM), dostop pa omejen na pooblaščeno osebje.«
Pripis: Zenith Blueprint, faza upravljanja tveganj, korak 14, politike obravnave tveganj in regulativni navzkrižni sklici Zenith Blueprint

V fazi Kontrole v praksi, korak 20, gre Zenith Blueprint globlje. Pri kriptografiji ne gre za »vklop šifriranja«. Gre za vgradnjo kriptografije v zasnovo, politiko in upravljanje življenjskega cikla. To vključuje podatke v mirovanju, podatke med prenosom, avtentikacijo identitet in transakcij, odobrene algoritme, trezorje ključev, HSM, načrtovano rotacijo ključev, preklic ter preverjanje s penetracijskim testiranjem in pregledom izvorne kode.

Kaj presojevalci pričakujejo, ko zahtevajo dokazila o ključih

Večina revizijskih ugotovitev se začne s preprosto zahtevo: »Pokažite nam politiko šifriranja in zapise o upravljanju ključev.«

Šibki odgovori vključujejo:

• »Ponudnik storitev v oblaku privzeto šifrira vse.«
• »Uporabljamo TLS.«
• »Skrivnosti so v trezorju.«
• »Rotacijo ključev ureja inženirska ekipa.«
• »Ključ upravlja aplikacija.«

Te izjave so lahko tehnično pravilne, vendar niso popolna dokazila. Presojevalec ISO bo upravljanje ključev povezal nazaj z oceno tveganj, izjavo o uporabnosti, zahtevami politike, operativno kontrolo in hranjeno dokumentacijo. Ocenjevalec NIST CSF bo vprašal, ali so kriptografska sredstva identificirana, zaščitena, spremljana in obnovljiva. Presojevalec DORA bo iskal upravljanje tveganj IKT, ki ga je odobril upravni organ, odvisnosti od tretjih oseb, upravljanje incidentov in testiranje odpornosti. Pregledovalec GDPR bo vprašal, ali šifriranje in ločevanje ključev zmanjšujeta tveganje za posameznike ter ali lahko upravljavec izkaže odgovornost.

Clarysecova korporativna Politika kriptografskih kontrol Politika kriptografskih kontrol neposredno naslavlja vrzel v dokazilih:

»Voditi je treba centraliziran register upravljanja ključev, v katerem so evidentirani vsi kriptografski ključi, njihov status v življenjskem ciklu, dodeljeni skrbniki in konteksti uporabe.«
Pripis: Korporativna politika, Politika kriptografskih kontrol, zahteve upravljanja, klavzula 5.2 Politika kriptografskih kontrol

Ta stavek spremeni revizijski pogovor. Namesto iskanja neformalnega znanja lahko organizacija pokaže register, ki ključe poveže s sredstvi, lastniki, razvrstitvami podatkov, sistemi, računi v oblaku, datumi rotacije, konteksti uporabe in dokazili.

Za MSP Clarysecova Politika kriptografskih kontrol za MSP Politika kriptografskih kontrol za MSP enako pričakovanje prilagodi obsegu:

»Ponudnik IT-podpore mora vzdrževati posodobljen popis kriptografskih orodij in digitalnih potrdil v uporabi.«
Pripis: Politika za MSP, Politika kriptografskih kontrol za MSP, zahteve upravljanja, klavzula 5.1.2 Politika kriptografskih kontrol za MSP

Regulirana finančna institucija lahko potrebuje formalne postopke HSM, deljeno znanje, dvojno kontrolo, formalna imenovanja skrbnikov in četrtletne preglede pravic dostopa. Majhen ponudnik SaaS lahko začne z vzdrževanim popisom, odobrenimi algoritmi, dokumentiranim lastništvom KMS in dokazili o rotaciji ključev. Oba potrebujeta upravljanje, sorazmerno s tveganjem.

Življenjski cikel ključev, ki ga mora nadzorovati vaš ISMS

Praktičen program upravljanja ključev sledi življenjskemu ciklu. Vsaka faza potrebuje lastnika, odobreno metodo, tehnično kontrolo, zapis o spremembi in revizijska dokazila.

Korporativna Politika kriptografskih kontrol poudarja varno generiranje:

»Generiranje ključev: izvaja se z uporabo varnih strojnih ali programskih modulov (npr. HSM, sistemi, validirani po FIPS 140-2).«
Pripis: Korporativna politika, Politika kriptografskih kontrol, zahteve za izvajanje politike, klavzula 6.3.1 Politika kriptografskih kontrol

Določa tudi rotacijo ključev:

»Rotacija ključev: zahtevana je v opredeljenih intervalih ali takoj ob kompromitaciji oziroma spremembi vloge.«
Pripis: Korporativna politika, Politika kriptografskih kontrol, zahteve za izvajanje politike, klavzula 6.3.4 Politika kriptografskih kontrol

Za MSP je isto načelo izraženo v enostavnejšem operativnem jeziku:

»Rotacija ključev mora potekati v skladu z razporedi poteka veljavnosti ali ob sumu kompromitacije.«
Pripis: Politika za MSP, Politika kriptografskih kontrol za MSP, zahteve za izvajanje politike, klavzula 6.3.4 Politika kriptografskih kontrol za MSP

Te klavzule so pomembne za NIS2 in DORA, ker zastareli ali slabo upravljani ključi niso le slabost zaupnosti. Postanejo lahko ovire pri odzivu na incidente, težave odvisnosti od dobaviteljev, odpovedi obnovitve po nesreči in težave pri obveščanju strank.

KMS v oblaku, HSM in BYOK: past deljene odgovornosti

Šifriranje v oblaku je eden najpogostejših virov lažnega občutka varnosti. Ponudnik storitev v oblaku lahko privzeto šifrira hrambo, vendar to samo po sebi ne pomeni, da je organizacija upravljala ključ.

Zenith Blueprint, faza Kontrole v praksi, korak 23, pojasnjuje kontrolo 5.23 ISO/IEC 27002:2022 s poudarkom na upravljanju oblaka, vidnosti in deljeni odgovornosti. Poudarja, da ponudnik lahko varuje infrastrukturo, vendar naročnik ostaja odgovoren za podatke, konfiguracije, politike dostopa in pripravljenost na odziv na incidente.

»Ponudniki storitev v oblaku varujejo infrastrukturo, vendar ste še vedno odgovorni za svoje podatke, svoje konfiguracije, svoje politike dostopa in svojo pripravljenost na odziv na incidente.«
Pripis: Zenith Blueprint, faza Kontrole v praksi, korak 23, organizacijske kontrole 5.19-5.37 Zenith Blueprint

Tu odgovornost za ključe v oblaku postane tveganje na ravni upravnega organa. Podjetje SaaS lahko uporablja šifriranje, ki ga upravlja ponudnik, za nizko tvegane dnevnike, ključe, ki jih upravlja naročnik, za podatkovne zbirke strank, BYOK za regulirane najemnike in korenske ključe, podprte s HSM, za podpisovanje ali tokenizacijo. Vsaka izbira ima posledice za skladnost.

Clarysecova korporativna Politika uporabe storitev v oblaku Politika uporabe storitev v oblaku določa jasno usmeritev kontrole:

»Ključi, ki jih upravlja naročnik (CMK), ali Bring Your Own Key (BYOK) se uporabljajo tam, kjer jih ponudnik storitev v oblaku podpira.«
Pripis: Korporativna politika, Politika uporabe storitev v oblaku, zahteve za izvajanje politike, klavzula 6.4.2 Politika uporabe storitev v oblaku

To ne pomeni, da mora vsaka storitev v oblaku uporabljati BYOK. Pomeni, da mora organizacija odločitev sprejeti načrtno, na podlagi tveganja, zavez do strank, pogodbenih zahtev in zmožnosti obnovitve.

DORA Article 28 in Article 30 sta za finančne subjekte pri tem posebej relevantna. Zahtevata upravljanje tveganj tretjih oseb na področju IKT, registre pogodbenih dogovorov IKT, skrbni pregled, pravice do revizije in pregleda, podporo pri incidentih, varstvo podatkov in dostop, določbe o obnovitvi in vrnitvi. Če ponudnik storitev v oblaku ali dobavitelj SaaS upravlja šifrirne ključe za kritično ali pomembno funkcijo, mora biti to razmerje vidno v registru tretjih oseb IKT in pogodbenih kontrolah.

NIS2 zahteva tudi varnost dobavne verige, vključno z ranljivostmi, značilnimi za posamezne dobavitelje, praksami kibernetske varnosti in postopki varnega razvoja. Če kritični dobavitelj hrani vaše ključe, upravlja vaš KMS, zagotavlja vaš HSM, upravlja življenjski cikel vaših digitalnih potrdil ali gosti šifrirane varnostne kopije, je dobavitelj del vašega kriptografskega kontrolnega okolja.

Odobritev algoritmov in kriptoagilnost v letu 2026

Politika upravljanja ključev v letu 2026 ne sme zgolj navesti »AES-256« in »TLS 1.2 ali novejši«. Vzpostaviti mora postopek odobritve in pregleda, ki podpira kriptoagilnost. Kriptoagilnost pomeni, da lahko organizacija ugotovi, kje se uporabljajo algoritmi, protokoli, digitalna potrdila in dolžine ključev, oceni izpostavljenost slabostim ali opustitvi ter izvede migracijo brez panike.

Clarysecova politika za MSP določa:

»Uporabljajo se lahko samo algoritmi in protokoli, skladni z najboljšimi industrijskimi praksami, ki jih odobri ponudnik IT-podpore (npr. AES-256, RSA 2048, TLS 1.2 ali novejši).«
Pripis: Politika za MSP, Politika kriptografskih kontrol za MSP, zahteve za izvajanje politike, klavzula 6.2.1 Politika kriptografskih kontrol za MSP

Zahteva tudi dokumentiranje:

»Vse metode šifriranja (npr. AES-256, TLS 1.2+) in procesi upravljanja ključev morajo biti dokumentirani.«
Pripis: Politika za MSP, Politika kriptografskih kontrol za MSP, zahteve upravljanja, klavzula 5.3.1 Politika kriptografskih kontrol za MSP

Različica, pripravljena na presojo, je odobren kriptografski standard, ki vključuje:

• Dovoljene algoritme in protokole za podatke v mirovanju, podatke med prenosom, podpise, zgoščevanje gesel, tokenizacijo in varnostne kopije.
• Nedovoljene algoritme, protokole in knjižnice.
• Minimalne dolžine ključev in obdobja veljavnosti digitalnih potrdil.
• Odobrene KMS, HSM, overitelje digitalnih potrdil in platforme za upravljanje skrivnosti.
• Zahteve za varno generiranje naključnih števil.
• Navodila za razvijalce glede kriptografskih knjižnic.
• Postopek izjem za zastarele sisteme.
• Sprožilce pregledov za ranljivosti, spremembe predpisov, spremembe dobaviteljev in načrtovanje postkvantnega prehoda.

Postkvantno načrtovanje od organizacij ne zahteva, da takoj zamenjajo vso kriptografijo. Zahteva pa popis. Brez kriptografskega popisa ne morete vedeti, kateri sistemi uporabljajo dolgoročno šifriranje z javnimi ključi, katera digitalna potrdila varujejo kritične storitve, kje so podpisni ključi ali kateri dobavitelji morajo podpreti migracijo. Register upravljanja ključev ni birokracija. Je temelj kriptoagilnosti.

90-minutni sprint dokazil za upravljanje ključev

Clarysec pogosto uporabi kratek sprint dokazil z vodstvom ter ekipami za varnost, oblak in skladnost. Cilj je hitro pretvoriti razpršeno znanje o ključih v revizijska dokazila.

Korak 1: Izberite eno kritično storitev

Izberite sistem, ki je pomemben za NIS2, DORA ali GDPR. Primeri vključujejo identiteto strank, obdelavo plačil, spremljanje transakcij, produkcijsko podatkovno zbirko strank, platformo šifriranih varnostnih kopij ali API, namenjen strankam.

Korak 2: Odprite register upravljanja ključev

Uporabite zahtevo Politike kriptografskih kontrol glede centraliziranega registra kot strukturo. Če ga še nimate, ustvarite preprost register s temi polji:

Korak 3: Sledite dostopu in dvojni kontroli

Za kriptografske operacije z velikim vplivom uporabite dvojno kontrolo in načelo najmanjših privilegijev. Korporativna Politika kriptografskih kontrol določa:

»Za občutljive kriptografske operacije (npr. uvoz korenskih ključev, administracija HSM) je treba uporabiti načeli dvojne kontrole in najmanjših privilegijev.«
Pripis: Korporativna politika, Politika kriptografskih kontrol, zahteve za izvajanje politike, klavzula 6.6.2 Politika kriptografskih kontrol

Vprašajte:

• Kdo lahko onemogoči ali izbriše ključ?
• Kdo lahko spremeni politiko ključa?
• Kdo lahko neposredno dešifrira podatke?
• Ali so vloge za nujni dostop (break-glass) spremljane in časovno omejene?
• Ali je MFA obvezen za privilegirane operacije s ključi?
• Ali se privilegirana dejanja beležijo in pregledujejo?

Korak 4: Pridobite pet dokaznih zapisov

Zberite pet zapisov, ki dokazujejo, da kontrola deluje:

1. Dnevnik ustvarjanja ali uvoza ključa.
2. Trenutna politika dostopa KMS ali HSM.
3. Zadnji zahtevek za spremembo pri rotaciji ključa.
4. Poizvedba SIEM, ki prikazuje uporabo ključa ali administrativna dejanja.
5. Dokazilo o testu obnovitve ali povrnitve.

Korak 5: Preslikajte na tveganje in predpise

Dodajte kratko izjavo o tveganju: »Nepooblaščena uporaba ali izguba tega ključa bi lahko razkrila osebne podatke iz EU, prekinila storitev za stranke in poslabšala obnovitev kritičnih sistemov.« Nato jo preslikajte na relevantne obveznosti.

V 90 minutah lahko ekipa običajno ugotovi, ali je upravljanje ključev dejansko vzpostavljeno ali zgolj predpostavljeno.

Poročanje o incidentih: ko kompromitacija ključa sproži časovnik

Domnevna kompromitacija ključa ni samodejno prijavljiva kršitev, lahko pa sproži regulativni časovnik.

Po NIS2 morajo bistveni in pomembni subjekti brez nepotrebnega odlašanja prijaviti pomembne incidente, ki vplivajo na zagotavljanje storitev. Fazni model vključuje zgodnje opozorilo v 24 urah od seznanitve, obvestilo o incidentu v 72 urah, posodobitve stanja na zahtevo in končno poročilo najpozneje en mesec po obvestilu o incidentu.

Po DORA morajo finančni subjekti zaznavati, upravljati in prijavljati incidente, povezane z IKT, evidentirati incidente in pomembne kibernetske grožnje, razvrščati incidente po resnosti in kritičnosti prizadetih storitev, komunicirati z zainteresiranimi stranmi, poročati o večjih incidentih višjemu vodstvu in pristojnim organom, izvesti analizo temeljnega vzroka in sprejeti sanacijske ukrepe. Zunanje izvajanje poročanja je lahko mogoče, vendar odgovornost ostaja pri finančnem subjektu.

Po GDPR je ključno vprašanje, ali je prišlo do kršitve varnosti osebnih podatkov, torej do nenamernega ali nezakonitega uničenja, izgube, spremembe, nepooblaščenega razkritja osebnih podatkov ali dostopa do njih. Močno šifriranje z nekompromitiranimi ključi lahko bistveno spremeni analizo tveganja kršitve. Slabo upravljanje ključev lahko ta argument izniči.

Odzivni priročniki za kompromitacijo ključev morajo opredeliti:

• Kako se zazna domnevna izpostavljenost ključa.
• Kdo razglasi kriptografski incident.
• Kako se identificirajo prizadeti podatki, storitve, stranke in jurisdikcije.
• Kako se ključi prekličejo ali rotirajo.
• Kako se obnovijo odvisni sistemi.
• Kako se ohrani celovitost dokazov.
• Kako se sprejemajo pravne, regulativne in strankam namenjene odločitve o obveščanju.

Register upravljanja ključev v tem procesu postane bistven. Brez njega odzivne ekipe izgubljajo čas z ugotavljanjem, kaj je ključ varoval. Z njim lahko hitro določijo obseg vpliva.

Revizijski pogled: en nabor kontrol, več uporabnikov dokazil

Različni presojevalci pristopajo k upravljanju kriptografskih ključev iz različnih izhodišč, vendar se ustavijo pri istih dokazilih.

Močan revizijski paket za upravljanje kriptografskih ključev običajno vsebuje:

• Odobreno Politiko kriptografskih kontrol.
• Odobreno Politiko uporabe storitev v oblaku, kadar je relevantno šifriranje v oblaku.
• Kriptografski standard in seznam algoritmov.
• Register upravljanja ključev.
• Popis digitalnih potrdil in skrivnosti.
• Arhitekturo KMS, HSM in trezorjev ključev.
• Dokazila o pregledih IAM in privilegiranega dostopa.
• Evidence rotacije in preklica.
• Dokazila o testih varnostnega kopiranja, deponiranja in obnovitve.
• Pravila beleženja in spremljanja dejavnosti ključev.
• Preslikavo dobaviteljev in deljene odgovornosti v oblaku.
• Odzivni priročnik za domnevno kompromitacijo ključev.
• Izjeme in sprejeme tveganj.
• Evidence pregledov vodstva in odprave revizijskih ugotovitev.

Ta paket pretvori trditev o kontroli v dokaz.

Pogoste ugotovitve pri revizijah upravljanja ključev

Najpogostejšim ugotovitvam se je mogoče izogniti:

1. Ni enotnega popisa ključev, digitalnih potrdil in kriptografskih orodij.
2. Privzeto šifriranje ponudnika storitev v oblaku se obravnava kot celovito upravljanje ključev.
3. Produkcijskim ključem ni dodeljen lastnik ali skrbnik.
4. Rotacija obstaja za digitalna potrdila, ne pa za aplikacijske ključe ali CMK podatkovnih zbirk.
5. Skrivnosti in ključi so pomešani v istem trezorju brez razvrstitve.
6. Razvijalci lahko ustvarjajo ključe zunaj odobrenih vzorcev.
7. Ni dokazil, da se skrbniki KMS pregledujejo.
8. Postopki obnovitve obstajajo, vendar niso bili nikoli testirani.
9. Kompromitacija ključa ni vključena v odzivne priročnike za incidente.
10. Zastareli algoritmi ostajajo v internih storitvah, ker nihče ne prevzame lastništva nad sanacijo.
11. Zaveze BYOK so vključene v pogodbe s strankami, vendar niso odražene v operativnem izvajanju.
12. Šifriranje, ki ga upravlja dobavitelj, ni vključeno v preglede tveganj dobaviteljev.

Vsaka ugotovitev se vrne k upravljanju. Zato kriptografije ni mogoče obravnavati kot izključno inženirski projekt. Povezana mora biti z obsegom ISMS, obravnavo tveganj, politiko, dobavitelji, oblakom, dostopom, beleženjem, incidenti in neprekinjenim poslovanjem.

Pripravite upravljanje ključev na presojo pred naslednjim incidentom

Če se vaša organizacija pripravlja na NIS2, DORA, dokazila za GDPR Article 32, certifikacijo ISO/IEC 27001:2022 ali postkvantno kriptoagilnost, začnite z enim vprašanjem: ali lahko danes predložite popoln register upravljanja ključev?

Če ne, vam lahko Clarysec pomaga vzpostaviti kontrolni sistem okoli njega.

Uporabite Zenith Blueprint Zenith Blueprint za strukturiranje dela skozi fazo upravljanja tveganj, korak 14, in fazo Kontrole v praksi, korak 20. Uporabite Zenith Controls Zenith Controls za preslikavo kontrol ISO/IEC 27002:2022 8.24, 5.17 in 5.23 na NIS2, DORA, GDPR, NIST in revizijska pričakovanja. Uporabite Clarysecovo Politiko kriptografskih kontrol Politika kriptografskih kontrol, Politiko kriptografskih kontrol za MSP Politika kriptografskih kontrol za MSP in Politiko uporabe storitev v oblaku Politika uporabe storitev v oblaku, da zahteve pretvorite v operativna pravila.

Praktični naslednji korak je preprost: izberite eno kritično storitev, popišite njene ključe, dokažite lastništvo, preverite dostop, pridobite dokazila o rotaciji ključev in testirajte obnovitev. Če to traja več kot en dan, vaše kriptografsko upravljanje potrebuje pozornost, preden regulator, presojevalec ali ekipa za odziv na incidente pod pritiskom zastavi isto vprašanje.