Správa kryptografických kľúčov pre ISO 27001, NIS2 a DORA

V pondelok ráno o 08:17 dostane CISO európskej SaaS spoločnosti správu od vedúceho vývoja: „Cez víkend sme vykonali rotáciu šifrovacieho kľúča databázy, ale jedna integrácia prestala dešifrovať záznamy. Zmenu sme vrátili pomocou starého kľúča z trezora.“

O desať minút neskôr sa DPO pýta, či dotknuté záznamy zahŕňajú osobné údaje z EÚ. Finančné oddelenie sa pýta, či z toho môže vzniknúť prevádzkový incident podliehajúci hláseniu regulovanému zákazníkovi. Obstarávanie sa pýta, či kľúč spravovaný zákazníkom vlastní cloudový poskytovateľ alebo spoločnosť. CEO kladie jedinú otázku, na ktorej v zasadacej miestnosti záleží: „Vieme preukázať, že sme to riadili správne?“

To je okamih, keď veta „používame šifrovanie“ prestáva byť upokojujúcou formuláciou a stáva sa otázkou dôkazov.

V roku 2026 sa správa kryptografických kľúčov nachádza na priesečníku kontrol ISO/IEC 27001:2022, kybernetickej hygieny podľa NIS2, riadenia rizík IKT podľa DORA, dôkazov o bezpečnosti spracúvania podľa GDPR Article 32, spoločnej zodpovednosti v cloude a plánovania postkvantovej kryptografickej agility. Skutočnou otázkou nie je, či šifrovanie existuje. Skutočnou otázkou je, či organizácia vie prostredníctvom záznamov preukázať, že kľúče sa bezpečne generujú, majú priradených vlastníkov, sú uložené v schválených prostrediach KMS alebo HSM, rotujú podľa harmonogramu, bezpečne sa obnovujú, pri kompromitácii sa zneplatňujú a sú namapované na riziká organizácie.

Clarysec pri práci na pripravenosti opakovane vidí rovnaký vzorec. Šifrovanie je implementované systém po systéme, ale správa kľúčov je roztrieštená. Certifikáty žijú v tabuľkových prehľadoch. Oprávnenia cloudového KMS sa dedia zo starých projektov. Vývojári vedia, ktoré tajomstvá sú dôležité, ale ISMS o nich nevie. Audítori dostávajú snímky obrazovky namiesto dôkazov o životnom cykle. Tímy pre NIS2 a DORA hovoria o odolnosti, tímy pre ochranu súkromia hovoria o šifrovaní a pseudonymizácii podľa GDPR a nikto nevlastní kryptografickú riadiacu rovinu od začiatku do konca.

Zrelou odpoveďou nie je viac kryptografie izolovane. Je ňou riadená správa kryptografických kľúčov prepojená s ošetrením rizík, cloudovou architektúrou, dohľadom nad dodávateľmi, riadením prístupu, logovaním, reakciou na incidenty a regulačnými dôkazmi.

Prečo je správa kľúčov dnes otázkou správy a riadenia

NIS2 zaraďuje politiky kryptografie a šifrovania medzi minimálne opatrenia riadenia kybernetických rizík pre základné a dôležité subjekty. Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia vrátane analýzy rizík, riešenia incidentov, kontinuity, bezpečnosti dodávateľského reťazca, bezpečného vývoja, kybernetickej hygieny, riadenia prístupu, správy aktív a politík kryptografie a šifrovania. Zároveň vyžaduje, aby riadiace orgány schvaľovali opatrenia riadenia kybernetických rizík a dohliadali na ne.

Pri poskytovateľoch SaaS, cloudových služieb, riadených služieb a služieb kybernetickej bezpečnosti môže byť uplatniteľnosť širšia, než mnohé tímy predpokladajú. NIS2 pokrýva sektory ako digitálna infraštruktúra, poskytovatelia cloudových výpočtových služieb, poskytovatelia dátových centier, poskytovatelia DNS, poskytovatelia dôveryhodných služieb, poskytovatelia riadených služieb, poskytovatelia riadených bezpečnostných služieb, online trhoviská, vyhľadávače a platformy sociálnych sietí, ak sú splnené prahové hodnoty veľkosti alebo kritickosti.

DORA zvyšuje latku pre finančné subjekty. Od 17. januára 2025 DORA vyžaduje zdokumentovaný rámec riadenia rizík IKT, zodpovednosť predstavenstva, plány kontinuity činností IKT a plány reakcie a obnovy, testovanie digitálnej prevádzkovej odolnosti, riadenie rizík IKT tretích strán a nahlasovanie incidentov. Pre finančné subjekty identifikované podľa vnútroštátnych pravidiel NIS2 pôsobí DORA ako odvetvovo špecifický právny akt Únie pre rovnocenné povinnosti podľa NIS2. Fintech by nemal prevádzkovať oddelenú správu kryptografie pre NIS2, DORA a ISO. Potrebuje jeden obhájiteľný model kontrol.

GDPR pridáva rozmer dôkazov o ochrane súkromia. GDPR Article 32 je miesto, kde sa šifrovanie bežne hodnotí ako ochranné opatrenie bezpečnosti spracúvania, ale veta „údaje sú šifrované“ nie je úplnou odpoveďou. Regulátori a audítori sa pýtajú, kto riadi kľúče, ako je obmedzený prístup, ako sa zisťuje kompromitácia, ako funguje obnova a či návrh zodpovedá riziku pre dotknuté osoby.

ISO/IEC 27001:2022 poskytuje organizáciám systém manažérstva, ktorý tieto povinnosti prepája. Kapitoly 4.1 až 4.4 vyžadujú kontext, požiadavky zainteresovaných strán, rozsah ISMS a vzájomne pôsobiace procesy. Kapitoly 5.1 až 5.3 vyžadujú vedenie, politiku, zdroje a priradené zodpovednosti. Kapitoly 6.1.1 až 6.1.3 vyžadujú posúdenie rizík, ošetrenie rizík, výber kontrol, vyhlásenie o aplikovateľnosti (SoA) a schválenie vlastníkom rizika. Kapitoly 8.1 až 8.3 vyžadujú riadenú prevádzku, prehodnotenie rizík pri zmenách, implementáciu plánov ošetrenia rizík a uchovávanie zdokumentovaných výsledkov.

Pri správe kryptografických kľúčov musí ISMS odpovedať na päť otázok:

1. Ktoré informačné aktíva, toky údajov a služby vyžadujú kryptografickú ochranu?
2. Ktoré kľúče, certifikáty, tajomstvá a kryptografické služby ich chránia?
3. Kto tieto kryptografické aktíva vlastní, spravuje, schvaľuje a monitoruje?
4. Ako sú riadené generovanie, uchovávanie, používanie, rotácia, úschova, obnova, revokácia a zničenie?
5. Aké dôkazy preukazujú, že kontroly fungovali podľa návrhu?

Kontrolná chrbtica ISO 27001 pre správu kryptografických kľúčov

Clarysec posudzuje správu kryptografických kľúčov ako reťazec kontrol, nie ako jednu kontrolu. V Zenith Controls: The Cross-Compliance Guide Zenith Controls sa téma mapuje predovšetkým na kontrolu ISO/IEC 27002:2022 8.24, používanie kryptografie, s dôležitými podpornými väzbami na 5.17, autentifikačné informácie, a 5.23, informačnú bezpečnosť pri používaní cloudových služieb.

Na tejto väzbe záleží. Zlyhanie správy kľúčov je len zriedka iba „zlé šifrovanie“. Často ide o problém autentifikácie, problém cloudovej správy a riadenia, problém dodávateľa, medzeru v logovaní alebo zlyhanie riadenia zmien.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint to operacionalizuje vo fáze riadenia rizík, krok 14, politiky ošetrenia rizík a regulačné krížové odkazy. Vzor kryptografickej politiky uvádza, že organizácia má definovať, kde je kryptografia potrebná, schvaľovať algoritmy a protokoly, definovať správu kľúčov, pokryť prípady použitia ako celodiskové šifrovanie a bezpečná komunikácia a prepojiť politiku s GDPR Article 32.

„Šifrovacie kľúče musia byť bezpečne uložené (napr. v trezore kľúčov/HSM) a prístup musí byť obmedzený na oprávnený personál.“
Zdroj: Zenith Blueprint, fáza riadenia rizík, krok 14, politiky ošetrenia rizík a regulačné krížové odkazy Zenith Blueprint

Vo fáze Kontroly v praxi, krok 20, ide Zenith Blueprint hlbšie. Kryptografia nie je o „zapnutí šifrovania“. Ide o začlenenie kryptografie do návrhu, politiky a riadenia životného cyklu. Zahŕňa to údaje v pokoji, údaje pri prenose, autentifikáciu identít a transakcií, schválené algoritmy, trezory kľúčov, HSM, plánovanú rotáciu, revokáciu a overenie prostredníctvom penetračného testovania a preskúmania kódu.

Čo audítori očakávajú, keď žiadajú dôkazy ku kľúčom

Väčšina auditných zistení sa začína jednoduchou požiadavkou: „Ukážte mi vašu politiku šifrovania a záznamy o správe kľúčov.“

Slabé odpovede zahŕňajú:

• „Cloudový poskytovateľ šifruje všetko predvolene.“
• „Používame TLS.“
• „Tajomstvá sú v trezore.“
• „Rotáciu rieši vývojový tím.“
• „Kľúč spravuje aplikácia.“

Tieto tvrdenia môžu byť technicky pravdivé, ale nie sú úplnými dôkazmi. Audítor ISO prepojí správu kľúčov späť na posúdenie rizík, vyhlásenie o aplikovateľnosti (SoA), požiadavky politiky, prevádzkovú kontrolu a uchovávanú dokumentáciu. Posudzovateľ NIST CSF sa bude pýtať, či sú kryptografické aktíva identifikované, chránené, monitorované a obnoviteľné. Audítor DORA bude hľadať predstavenstvom schválenú správu a riadenie rizík IKT, závislosti od tretích strán, riadenie incidentov a testovanie odolnosti. Posudzovateľ GDPR sa bude pýtať, či šifrovanie a oddelenie kľúčov znižujú riziko pre dotknuté osoby a či prevádzkovateľ vie preukázať zodpovednosť.

Podniková Cryptographic Controls Policy spoločnosti Clarysec Cryptographic Controls Policy priamo rieši medzeru v dôkazoch:

„Musí sa udržiavať centralizovaný register správy kľúčov na evidenciu všetkých kryptografických kľúčov, ich stavu životného cyklu, priradených správcov a kontextov používania.“
Zdroj: Podniková politika, Cryptographic Controls Policy, požiadavky na správu a riadenie, kapitola 5.2 Cryptographic Controls Policy

Táto veta mení auditnú diskusiu. Namiesto naháňania neformálnych znalostí môže organizácia predložiť register, ktorý prepája kľúče s aktívami, vlastníkmi, klasifikáciami údajov, systémami, cloudovými účtami, dátumami rotácie, kontextmi používania a dôkazmi.

Pre MSP škáluje Cryptographic Controls Policy-sme spoločnosti Clarysec Cryptographic Controls Policy-sme - SME rovnaké očakávanie:

„Poskytovateľ IT podpory musí udržiavať aktuálny inventár používaných kryptografických nástrojov a certifikátov.“
Zdroj: Politika pre MSP, Cryptographic Controls Policy-sme, požiadavky na správu a riadenie, kapitola 5.1.2 Cryptographic Controls Policy-sme - SME

Regulovaná finančná inštitúcia môže potrebovať ceremónie HSM, rozdelenú znalosť, dvojitú kontrolu, formálne menovania správcov a štvrťročné preskúmania prístupových práv. Malý poskytovateľ SaaS môže začať udržiavaným inventárom, schválenými algoritmami, zdokumentovaným vlastníctvom KMS a dôkazmi o rotácii. Obe organizácie potrebujú správu a riadenie primerané riziku.

Životný cyklus kľúčov, ktorý má váš ISMS riadiť

Praktický program správy kľúčov sleduje životný cyklus. Každá etapa potrebuje vlastníka, schválenú metódu, technickú kontrolu, záznam o zmene a auditný dôkaz.

Podniková Cryptographic Controls Policy posilňuje bezpečné generovanie:

„Generovanie kľúčov: Vykonáva sa pomocou bezpečných hardvérových alebo softvérových modulov (napr. HSM, systémy validované podľa FIPS 140-2).“
Zdroj: Podniková politika, Cryptographic Controls Policy, požiadavky na implementáciu politiky, kapitola 6.3.1 Cryptographic Controls Policy

Špecifikuje aj rotáciu:

„Rotácia kľúčov: Vyžaduje sa v definovaných intervaloch alebo okamžite pri kompromitácii alebo zmene roly.“
Zdroj: Podniková politika, Cryptographic Controls Policy, požiadavky na implementáciu politiky, kapitola 6.3.4 Cryptographic Controls Policy

Pre MSP sa rovnaký princíp objavuje v jednoduchšom prevádzkovom jazyku:

„Rotácia kľúčov sa musí vykonávať v súlade s harmonogramami uplynutia platnosti alebo pri podozrení na kompromitáciu.“
Zdroj: Politika pre MSP, Cryptographic Controls Policy-sme, požiadavky na implementáciu politiky, kapitola 6.3.4 Cryptographic Controls Policy-sme - SME

Tieto kapitoly sú dôležité pre NIS2 a DORA, pretože zastarané alebo zle riadené kľúče nie sú len slabinami dôvernosti. Môžu sa stať prekážkami pri reakcii na incidenty, problémami závislosti od dodávateľov, zlyhaniami obnovy po havárii a problémami s notifikáciami zákazníkov.

Cloudový KMS, HSM a BYOK: pasca spoločnej zodpovednosti

Cloudové šifrovanie je jedným z najčastejších zdrojov falošnej istoty. Cloudový poskytovateľ môže predvolene šifrovať úložisko, ale to automaticky neznamená, že vaša organizácia riadi kľúč.

Zenith Blueprint, fáza Kontroly v praxi, krok 23, vysvetľuje kontrolu ISO/IEC 27002:2022 5.23 so zameraním na cloudovú správu a riadenie, viditeľnosť a spoločnú zodpovednosť. Zdôrazňuje, že poskytovateľ môže zabezpečovať infraštruktúru, ale zákazník zostáva zodpovedný za údaje, konfigurácie, politiky prístupu a pripravenosť na reakciu na incidenty.

„Cloudoví poskytovatelia zabezpečujú infraštruktúru, ale vy ste stále zodpovední za svoje údaje, svoje konfigurácie, svoje politiky prístupu a svoju pripravenosť na reakciu na incidenty.“
Zdroj: Zenith Blueprint, fáza Kontroly v praxi, krok 23, organizačné opatrenia 5.19-5.37 Zenith Blueprint

Tu sa zodpovednosť za cloudové kľúče stáva rizikom na úrovni predstavenstva. SaaS spoločnosť môže používať šifrovanie spravované poskytovateľom pre nízkorizikové logy, kľúče spravované zákazníkom pre zákaznícke databázy, BYOK pre regulovaných nájomcov a koreňové kľúče podporené HSM na podpisovanie alebo tokenizáciu. Každá voľba má dôsledky pre súlad.

Podniková Cloud Usage Policy spoločnosti Clarysec Cloud Usage Policy poskytuje jasné smerovanie kontroly:

„Kľúče spravované zákazníkom (CMK) alebo Bring Your Own Key (BYOK) sa majú používať tam, kde ich podporuje cloudový poskytovateľ.“
Zdroj: Podniková politika, Cloud Usage Policy, požiadavky na implementáciu politiky, kapitola 6.4.2 Cloud Usage Policy

To neznamená, že každá cloudová služba musí používať BYOK. Znamená to, že organizácia musí rozhodovať zámerne na základe rizika, záväzkov voči zákazníkom, zmluvných požiadaviek a obnoviteľnosti.

DORA Article 28 a Article 30 robia túto tému obzvlášť relevantnou pre finančné subjekty. Vyžadujú riadenie rizík IKT tretích strán, registre zmluvných dohôd v oblasti IKT, náležitú starostlivosť, práva na audit a inšpekciu, pomoc pri incidentoch, ochranu údajov a prístup, ustanovenia o obnove a vrátení. Ak cloudový poskytovateľ alebo dodávateľ SaaS spravuje šifrovacie kľúče pre kritickú alebo dôležitú funkciu, tento vzťah musí byť viditeľný v registri tretích strán IKT a v zmluvných kontrolách.

NIS2 vyžaduje aj bezpečnosť dodávateľského reťazca vrátane zraniteľností špecifických pre dodávateľa, postupov kybernetickej bezpečnosti a postupov bezpečného vývoja. Ak kritický dodávateľ drží vaše kľúče, prevádzkuje váš KMS, poskytuje váš HSM, spravuje životný cyklus certifikátov alebo hostuje šifrované zálohy, dodávateľ je súčasťou vášho kryptografického kontrolného prostredia.

Schvaľovanie algoritmov a kryptografická agilita v roku 2026

Politika správy kľúčov v roku 2026 by nemala iba uvádzať „AES-256“ a „TLS 1.2 alebo novšie“. Má zaviesť proces schvaľovania a preskúmania, ktorý podporuje kryptografickú agilitu. Kryptografická agilita znamená, že organizácia vie identifikovať, kde sa používajú algoritmy, protokoly, certifikáty a dĺžky kľúčov, posúdiť vystavenie slabinám alebo zastaraniu a migrovať bez paniky.

Politika Clarysec pre MSP uvádza:

„Používať sa môžu iba algoritmy a protokoly podľa odvetvových osvedčených postupov schválené poskytovateľom IT podpory (napr. AES-256, RSA 2048, TLS 1.2 alebo novšie).“
Zdroj: Politika pre MSP, Cryptographic Controls Policy-sme, požiadavky na implementáciu politiky, kapitola 6.2.1 Cryptographic Controls Policy-sme - SME

Vyžaduje aj dokumentáciu:

„Všetky metódy šifrovania (napr. AES-256, TLS 1.2+) a procesy správy kľúčov musia byť zdokumentované.“
Zdroj: Politika pre MSP, Cryptographic Controls Policy-sme, požiadavky na správu a riadenie, kapitola 5.3.1 Cryptographic Controls Policy-sme - SME

Verzia pripravená na audit je schválený kryptografický štandard, ktorý obsahuje:

• Povolené algoritmy a protokoly pre údaje v pokoji, údaje pri prenose, podpisy, hashovanie hesiel, tokenizáciu a zálohy.
• Nepovolené algoritmy, protokoly a knižnice.
• Minimálne dĺžky kľúčov a obdobia platnosti certifikátov.
• Schválené platformy KMS, HSM, certifikačné autority a nástroje na správu tajomstiev.
• Požiadavky na bezpečné generovanie náhodných čísel.
• Usmernenia pre vývojárov ku kryptografickým knižniciam.
• Proces výnimiek pre legacy systémy.
• Spúšťače preskúmania pri zraniteľnostiach, regulačných zmenách, zmenách dodávateľov a plánovaní postkvantovej transformácie.

Postkvantové plánovanie nevyžaduje, aby každá organizácia okamžite nahradila celú kryptografiu. Vyžaduje však inventár. Bez kryptografického inventára neviete, ktoré systémy používajú dlhoživotné šifrovanie verejným kľúčom, ktoré certifikáty chránia kritické služby, kde sa nachádzajú podpisové kľúče ani ktorí dodávatelia musia podporovať migráciu. Register správy kľúčov nie je byrokracia. Je základom kryptografickej agility.

90-minútový dôkazový sprint správy kľúčov

Clarysec často používa krátky dôkazový sprint s vedením, bezpečnostnými, cloudovými a compliance tímami. Cieľom je rýchlo premeniť rozptýlené znalosti o kľúčoch na auditovateľné dôkazy.

Krok 1: Vyberte jednu kritickú službu

Vyberte systém, ktorý je relevantný pre NIS2, DORA alebo GDPR. Príklady zahŕňajú zákaznícku identitu, spracovanie platieb, monitorovanie transakcií, produkčnú zákaznícku databázu, platformu šifrovaného zálohovania alebo API určené pre zákazníkov.

Krok 2: Otvorte register správy kľúčov

Použite požiadavku Cryptographic Controls Policy na centralizovaný register ako štruktúru. Ak ho ešte nemáte, vytvorte jednoduchý register s týmito poľami:

Krok 3: Sledujte prístup a dvojitú kontrolu

Pri kryptografických operáciách s vysokým dopadom uplatnite dvojitú kontrolu a zásadu minimálnych oprávnení. Podniková Cryptographic Controls Policy uvádza:

„Na citlivé kryptografické operácie (napr. import koreňových kľúčov, správa HSM) sa musia uplatňovať zásady dvojitej kontroly a minimálnych oprávnení.“
Zdroj: Podniková politika, Cryptographic Controls Policy, požiadavky na implementáciu politiky, kapitola 6.6.2 Cryptographic Controls Policy

Pýtajte sa:

• Kto môže kľúč deaktivovať alebo vymazať?
• Kto môže zmeniť politiku kľúča?
• Kto môže údaje priamo dešifrovať?
• Sú roly break-glass monitorované a časovo obmedzené?
• Je pre privilegované operácie s kľúčmi vynucovaná MFA?
• Sú privilegované akcie logované a preskúmavané?

Krok 4: Získajte päť dôkazových záznamov

Zhromaždite päť záznamov, ktoré preukazujú, že kontrola funguje:

1. Log vytvorenia alebo importu kľúča.
2. Aktuálna politika prístupu ku KMS alebo HSM.
3. Posledný záznam zmeny rotácie kľúča.
4. Dotaz v SIEM zobrazujúci používanie kľúča alebo administrátorské akcie.
5. Dôkaz o teste obnovy alebo rekonštrukcie.

Krok 5: Namapujte na riziko a reguláciu

Pridajte krátke vyhlásenie o riziku: „Neoprávnené použitie alebo strata tohto kľúča by mohli sprístupniť osobné údaje z EÚ, narušiť zákaznícku službu a zhoršiť obnovu kritických systémov.“ Potom ho namapujte na relevantné povinnosti.

Za 90 minút tím zvyčajne dokáže určiť, či je správa a riadenie kľúčov skutočné alebo iba predpokladané.

Nahlasovanie incidentov: keď kompromitácia kľúča spúšťa čas

Podozrenie na kompromitáciu kľúča nie je automaticky porušením podliehajúcim oznamovaniu, ale môže spustiť regulačné lehoty.

Podľa NIS2 musia základné a dôležité subjekty bez zbytočného odkladu oznamovať významné incidenty ovplyvňujúce poskytovanie služieb. Fázovaný model zahŕňa včasné varovanie do 24 hodín od nadobudnutia vedomosti, oznámenie incidentu do 72 hodín, stavové aktualizácie na vyžiadanie a záverečnú správu najneskôr do jedného mesiaca od oznámenia incidentu.

Podľa DORA musia finančné subjekty detegovať, riadiť a oznamovať incidenty súvisiace s IKT, zaznamenávať incidenty a významné kybernetické hrozby, klasifikovať incidenty podľa závažnosti a kritickosti dotknutej služby, komunikovať so zainteresovanými stranami, hlásiť závažné incidenty vrcholovému manažmentu a príslušným orgánom, vykonať analýzu koreňovej príčiny a prijať nápravné opatrenia. Outsourcing hlásenia môže byť možný, zodpovednosť však zostáva na finančnom subjekte.

Podľa GDPR sa otázka mení na to, či došlo k porušeniu ochrany osobných údajov, teda k náhodnému alebo nezákonnému zničeniu, strate, zmene, neoprávnenému sprístupneniu osobných údajov alebo neoprávnenému prístupu k nim. Silné šifrovanie s nekompromitovanými kľúčmi môže zásadne zmeniť analýzu rizika porušenia. Slabá správa kľúčov môže tento argument podkopať.

Playbooky kompromitácie kľúčov majú definovať:

• Ako sa zisťuje podozrenie na sprístupnenie kľúča.
• Kto vyhlasuje kryptografický incident.
• Ako sa identifikujú dotknuté údaje, služby, zákazníci a jurisdikcie.
• Ako sa kľúče zneplatňujú alebo rotujú.
• Ako sa obnovujú závislé systémy.
• Ako sa zachováva integrita dôkazov.
• Ako sa prijímajú rozhodnutia o právnych, regulačných a zákazníckych notifikáciách.

Register správy kľúčov sa počas tohto procesu stáva nevyhnutným. Bez neho pracovníci reakcie strácajú čas zisťovaním, čo kľúč chránil. S ním vedia rýchlo určiť rozsah dopadu.

Auditný pohľad: jeden súbor kontrol, mnoho príjemcov dôkazov

Rôzni audítori pristupujú k správe kryptografických kľúčov z rôznych východísk, ale zbiehajú sa pri rovnakých dôkazoch.

Silný auditný balík pre správu kryptografických kľúčov zvyčajne obsahuje:

• Schválenú Cryptographic Controls Policy.
• Schválenú Cloud Usage Policy, ak je relevantné cloudové šifrovanie.
• Kryptografický štandard a zoznam algoritmov.
• Register správy kľúčov.
• Inventár certifikátov a tajomstiev.
• Architektúru KMS, HSM a trezorov.
• Dôkazy o preskúmaní IAM a privilegovaného prístupu.
• Záznamy o rotácii a revokácii.
• Dôkazy o testovaní záloh, úschovy a obnovy.
• Pravidlá logovania a monitorovania aktivity kľúčov.
• Mapovanie spoločnej zodpovednosti dodávateľov a cloudu.
• Incidentný playbook pre podozrenie na kompromitáciu kľúča.
• Výnimky a akceptácie rizík.
• Záznamy preskúmania manažmentom a nápravných opatrení z auditu.

Tento balík premieňa tvrdenie o kontrole na dôkaz.

Bežné zistenia pri auditoch správy kľúčov

Najčastejším zisteniam sa dá predísť:

1. Neexistuje jednotný inventár kľúčov, certifikátov a kryptografických nástrojov.
2. Predvolené šifrovanie cloudového poskytovateľa sa považuje za úplnú správu kľúčov.
3. Produkčným kľúčom nie je priradený vlastník ani správca.
4. Rotácia existuje pre certifikáty, ale nie pre aplikačné kľúče alebo databázové CMK.
5. Tajomstvá a kľúče sú zmiešané v tom istom trezore bez klasifikácie.
6. Vývojári môžu vytvárať kľúče mimo schválených vzorov.
7. Neexistuje dôkaz, že administrátori KMS podliehajú preskúmaniu.
8. Postupy obnovy existujú, ale nikdy neboli otestované.
9. Kompromitácia kľúča nie je zahrnutá v playbookoch reakcie na incidenty.
10. Legacy algoritmy zostávajú v interných službách, pretože nikto nevlastní nápravu.
11. Záväzky BYOK sú prijaté v zákazníckych zmluvách, ale neodrážajú sa v prevádzke.
12. Šifrovanie spravované dodávateľom nie je zahrnuté do preskúmaní dodávateľského rizika.

Každé zistenie sa vracia k správe a riadeniu. Preto kryptografiu nemožno považovať za čisto inžiniersky projekt. Musí byť prepojená s rozsahom ISMS, ošetrením rizík, politikou, dodávateľmi, cloudom, prístupom, logovaním, incidentmi a kontinuitou.

Pripravte správu kľúčov na audit ešte pred ďalším incidentom

Ak sa vaša organizácia pripravuje na NIS2, DORA, dôkazy podľa GDPR Article 32, certifikáciu ISO/IEC 27001:2022 alebo postkvantovú kryptografickú agilitu, začnite jednou otázkou: viete dnes predložiť úplný register správy kľúčov?

Ak nie, Clarysec vám pomôže vybudovať okolo neho systém kontrol.

Použite Zenith Blueprint Zenith Blueprint na štruktúrovanie práce cez fázu riadenia rizík, krok 14, a fázu Kontroly v praxi, krok 20. Použite Zenith Controls Zenith Controls na mapovanie kontrol ISO/IEC 27002:2022 8.24, 5.17 a 5.23 naprieč NIS2, DORA, GDPR, NIST a auditnými očakávaniami. Použite Cryptographic Controls Policy spoločnosti Clarysec Cryptographic Controls Policy, Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme - SME a Cloud Usage Policy Cloud Usage Policy na premenu požiadaviek na prevádzkové pravidlá.

Praktický ďalší krok je jednoduchý: vyberte jednu kritickú službu, zinventarizujte jej kľúče, preukážte vlastníctvo, overte prístup, získajte dôkazy o rotácii a otestujte obnovu. Ak to trvá viac než jeden deň, vaša správa kryptografických kľúčov potrebuje pozornosť skôr, než regulátor, audítor alebo tím reakcie na incidenty položí tú istú otázku pod tlakom.