Upravljanje kriptografskim ključevima za ISO 27001, NIS2 i DORA
U 08:17 u ponedjeljak ujutro CISO europske SaaS tvrtke prima poruku od voditelja inženjeringa: „Tijekom vikenda rotirali smo ključ za šifriranje baze podataka, ali jedna integracija prestala je dešifrirati zapise. Vratili smo promjenu koristeći stari ključ iz trezora.”
Deset minuta kasnije DPO pita uključuju li zahvaćeni zapisi osobne podatke iz EU-a. Financije pitaju može li to postati prijavljivi operativni incident za reguliranog klijenta. Nabava pita drži li ključ kojim upravlja korisnik pružatelj usluga u oblaku ili tvrtka. CEO postavlja jedino pitanje koje je važno pred upravom: „Možemo li dokazati da smo time pravilno upravljali?”
To je trenutak u kojem „koristimo šifriranje” prestaje biti umirujuća izjava i postaje pitanje dokazivosti.
U 2026. upravljanje kriptografskim ključevima nalazi se na sjecištu kontrola ISO/IEC 27001:2022, kibernetičke higijene prema NIS2, upravljanja IKT rizicima prema DORA, dokaza o sigurnosti obrade prema GDPR Article 32, podijeljene odgovornosti u oblaku i planiranja postkvantne kriptoagilnosti. Stvarno pitanje nije postoji li šifriranje. Stvarno je pitanje može li organizacija zapisima pokazati da se ključevi sigurno generiraju, dodjeljuju vlasnicima, pohranjuju u odobrenim KMS ili HSM okruženjima, rotiraju prema rasporedu, sigurno oporavljaju, opozivaju u slučaju kompromitacije i mapiraju na poslovni rizik.
Clarysec u radu na spremnosti za reviziju stalno vidi isti obrazac. Šifriranje je implementirano po sustavima, ali je upravljanje ključevima fragmentirano. Certifikati se vode u proračunskim tablicama. Dozvole za KMS u oblaku naslijeđene su iz starih projekata. Razvojni inženjeri znaju koje su tajne vrijednosti važne, ali ISMS to ne zna. Revizori dobivaju snimke zaslona umjesto dokaza životnog ciklusa. Timovi za NIS2 i DORA govore o otpornosti, timovi za privatnost govore o šifriranju i pseudonimizaciji prema GDPR-u, a nitko ne upravlja kriptografskom kontrolnom ravninom od početka do kraja.
Zreo odgovor nije više kriptografije izdvojene od svega ostalog. Zreo odgovor je formalno upravljanje kriptografskim ključevima povezano s obradom rizika, arhitekturom oblaka, nadzorom nad dobavljačima, kontrolom pristupa, evidentiranjem događaja, odgovorom na incidente i regulatornim dokazima.
Zašto je upravljanje ključevima sada pitanje upravljanja
NIS2 politike kriptografije i šifriranja svrstava u minimalne mjere upravljanja kibernetičkim rizicima za ključne i važne subjekte. Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere, uključujući analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, siguran razvoj, kibernetičku higijenu, kontrolu pristupa, upravljanje imovinom te politike kriptografije i šifriranja. Također zahtijeva da upravljačka tijela odobre i nadziru mjere upravljanja kibernetičkim rizicima.
Za SaaS, oblak, upravljane usluge i pružatelje kibernetičke sigurnosti primjenjivost može biti šira nego što mnogi timovi pretpostavljaju. NIS2 obuhvaća sektore kao što su digitalna infrastruktura, pružatelji usluga računalstva u oblaku, pružatelji podatkovnih centara, DNS pružatelji, pružatelji usluga povjerenja, pružatelji upravljanih usluga, pružatelji upravljanih sigurnosnih usluga, internetska tržišta, tražilice i platforme društvenih mreža kada su ispunjeni pragovi veličine ili kritičnosti.
DORA podiže zahtjeve za financijske subjekte. Od 17. siječnja 2025. DORA zahtijeva dokumentirani okvir upravljanja IKT rizicima, odgovornost upravljačkog tijela, IKT neprekidnost poslovanja te planove odgovora i oporavka, testiranje digitalne operativne otpornosti, upravljanje IKT rizikom trećih strana i prijavljivanje incidenata. Za financijske subjekte utvrđene prema nacionalnim pravilima NIS2, DORA djeluje kao sektorski poseban pravni akt Unije za ekvivalentne obveze NIS2. Fintech ne bi trebao voditi odvojeno upravljanje kriptografijom za NIS2, DORA i ISO. Potreban mu je jedan dokaziv model kontrola.
GDPR dodaje dimenziju dokaza za privatnost. GDPR Article 32 mjesto je na kojem se šifriranje najčešće ocjenjuje kao zaštitna mjera sigurnosti obrade, ali „podaci su šifrirani” nije potpun odgovor. Regulatori i revizori pitaju tko kontrolira ključeve, kako je pristup ograničen, kako se otkriva kompromitacija, kako funkcionira oporavak i odgovara li dizajn riziku za pojedince.
ISO/IEC 27001:2022 organizacijama daje sustav upravljanja koji povezuje te obveze. Točke 4.1 do 4.4 zahtijevaju kontekst, zahtjeve zainteresiranih strana, opseg ISMS-a i međusobno povezane procese. Točke 5.1 do 5.3 zahtijevaju vodstvo, politiku, resurse i dodijeljene odgovornosti. Točke 6.1.1 do 6.1.3 zahtijevaju procjenu rizika, obradu rizika, odabir kontrola, Izjavu o primjenjivosti i odobrenje vlasnika rizika. Točke 8.1 do 8.3 zahtijevaju kontrolirano odvijanje procesa, ponovno procjenjivanje rizika kada nastanu promjene, provedbu planova obrade rizika i zadržavanje dokumentiranih rezultata.
Za upravljanje kriptografskim ključevima ISMS mora odgovoriti na pet pitanja:
- Koja informacijska imovina, tokovi podataka i usluge zahtijevaju kriptografsku zaštitu?
- Koji ključevi, certifikati, tajne vrijednosti i kriptografske usluge ih štite?
- Tko je vlasnik, tko administrira, tko odobrava i tko nadzire tu kriptografsku imovinu?
- Kako su kontrolirani generiranje, pohrana, uporaba, rotacija, deponiranje, oporavak, opoziv i uništenje?
- Koji dokazi potvrđuju da su kontrole djelovale kako je predviđeno?
Kontrolna okosnica ISO 27001 za upravljanje kriptografskim ključevima
Clarysec upravljanje kriptografskim ključevima promatra kao lanac kontrola, a ne kao jednu kontrolu. U Zenith Controls: vodič za međusobnu usklađenost Zenith Controls, tema se primarno mapira na kontrolu ISO/IEC 27002:2022 8.24, uporaba kriptografije, uz važne potporne odnose s 5.17, informacije za autentifikaciju, i 5.23, informacijska sigurnost pri korištenju usluga u oblaku.
Taj je odnos važan. Neuspjeh u upravljanju ključevima rijetko je samo „loše šifriranje”. Često je riječ o problemu autentifikacije, problemu upravljanja oblakom, problemu dobavljača, praznini u evidentiranju događaja ili neuspjehu upravljanja promjenama.
| Područje ISO/IEC 27002:2022 | Zašto je važno za upravljanje ključevima | Tipični dokazi |
|---|---|---|
| 8.24 Uporaba kriptografije | Definira odobrene slučajeve uporabe kriptografije, algoritme, protokole, životni ciklus ključeva i očekivanja implementacije | Kriptografska politika, standard algoritama, postupak životnog ciklusa ključeva, KMS konfiguracija, zapisi o rotaciji |
| 5.17 Informacije za autentifikaciju | Štiti vjerodajnice, tajne vrijednosti, tokene i autentifikacijski materijal povezan s privilegiranim kriptografskim operacijama | Popis tajnih vrijednosti, zapisi pristupa trezoru, pregledi privilegiranog pristupa, dokazi MFA |
| 5.23 Informacijska sigurnost pri korištenju usluga u oblaku | Definira podijeljenu odgovornost, vlasništvo nad ključevima u oblaku, odluke o CMK ili BYOK i upravljanje pružateljem usluga | Registar usluga u oblaku, matrica podijeljene odgovornosti, KMS arhitektura, sigurnosni pregled dobavljača |
| 5.19 do 5.22 Sigurnost dobavljača | Osigurava da dobavljači i pružatelji IKT usluga ispunjavaju zahtjeve šifriranja, skrbništva nad ključevima, incidenata i revizije | Ugovori, dubinska analiza dobavljača, potvrde dobavljača, pregledi praćenja |
| 5.24 do 5.28 Upravljanje incidentima | Povezuje sumnju na kompromitaciju ključa s procjenom događaja, odgovorom, učenjem i prikupljanjem dokaza | Operativne upute za incidente, operativne upute za kompromitaciju ključa, forenzički dnevnički zapisi, naučene lekcije |
| 8.15 i 8.16 Evidentiranje događaja i nadzor | Otkriva neovlaštenu uporabu ključeva, sumnjive API pozive, neuspjele pokušaje dešifriranja i promjene politike | SIEM upozorenja, KMS revizijski zapisi, pravila za otkrivanje anomalija |
| 8.32 Upravljanje promjenama | Kontrolira rotacije, migracije, nadogradnje algoritama, hitni opoziv i rad na postkvantnoj tranziciji | Zahtjevi za promjenu, odobrenja, planovi povrata, rezultati testiranja |
Zenith Blueprint: revizorov plan u 30 koraka Zenith Blueprint pretvara to u operativni rad u fazi upravljanja rizicima, koraku 14, politike obrade rizika i regulatorna unakrsna upućivanja. Uzorak politike kriptografije navodi da organizacija treba definirati gdje je kriptografija potrebna, odobriti algoritme i protokole, definirati upravljanje ključevima, obuhvatiti slučajeve uporabe kao što su šifriranje cijelog diska i sigurne komunikacije te povezati politiku s GDPR Article 32.
„Ključevi za šifriranje moraju se sigurno pohranjivati (npr. u trezoru ključeva/HSM-u), a pristup mora biti ograničen na ovlašteno osoblje.”
Atribucija: Zenith Blueprint, faza upravljanja rizicima, korak 14, politike obrade rizika i regulatorna unakrsna upućivanja Zenith Blueprint
U fazi kontrole u praksi, koraku 20, Zenith Blueprint ide dublje. Kriptografija nije „uključivanje šifriranja”. Riječ je o ugradnji kriptografije u dizajn, politiku i upravljanje životnim ciklusom. To uključuje podatke u mirovanju, podatke u prijenosu, autentifikaciju identiteta i transakcija, odobrene algoritme, spremišta ključeva, HSM-ove, planiranu rotaciju, opoziv i provjeru kroz penetracijsko testiranje i pregled koda.
Što revizori očekuju kada zatraže dokaze o ključevima
Većina nalaza revizije započinje jednostavnim zahtjevom: „Pokažite mi svoju politiku šifriranja i zapise o upravljanju ključevima.”
Slabi odgovori uključuju:
- „Pružatelj usluga u oblaku sve šifrira prema zadanim postavkama.”
- „Koristimo TLS.”
- „Tajne vrijednosti su u trezoru.”
- „Inženjerski tim upravlja rotacijom.”
- „Ključem upravlja aplikacija.”
Te izjave mogu biti tehnički točne, ali nisu potpuni dokazi. ISO revizor povezat će upravljanje ključevima s procjenom rizika, Izjavom o primjenjivosti, zahtjevima politike, operativnom kontrolom i zadržanom dokumentacijom. Procjenitelj prema NIST CSF pitat će jesu li kriptografska imovina identificirana, zaštićena, nadzirana i oporavljiva. DORA revizor tražit će upravljanje IKT rizicima odobreno na razini upravljačkog tijela, ovisnosti o trećim stranama, upravljanje incidentima i testiranje otpornosti. Pregled prema GDPR-u pitat će smanjuju li šifriranje i odvajanje ključeva rizik za pojedince i može li voditelj obrade dokazati odgovornost.
Clarysecova korporativna Politika kriptografskih kontrola Politika kriptografskih kontrola izravno rješava prazninu u dokazima:
„Mora se održavati centralizirani Registar upravljanja ključevima u kojem se evidentiraju svi kriptografski ključevi, njihov status životnog ciklusa, dodijeljeni skrbnici i konteksti uporabe.”
Atribucija: korporativna politika, Politika kriptografskih kontrola, zahtjevi upravljanja, točka 5.2 Politika kriptografskih kontrola
Ta rečenica mijenja revizijski razgovor. Umjesto traženja neformalnog znanja, organizacija može pokazati registar koji povezuje ključeve s imovinom, vlasnicima, klasifikacijama podataka, sustavima, računima u oblaku, datumima rotacije, kontekstima uporabe i dokazima.
Za mala i srednja poduzeća Clarysecova Politika kriptografskih kontrola za MSP Politika kriptografskih kontrola za MSP skalira isto očekivanje:
„Pružatelj IT podrške mora održavati ažuran popis kriptografskih alata i certifikata koji se koriste”
Atribucija: politika za MSP, Politika kriptografskih kontrola za MSP, zahtjevi upravljanja, točka 5.1.2 Politika kriptografskih kontrola za MSP
Regulirana financijska institucija može trebati HSM ceremonije, podijeljeno znanje, dvostruku kontrolu, formalna imenovanja skrbnika i tromjesečne preglede pristupa. Mali SaaS pružatelj može započeti s održavanim popisom, odobrenim algoritmima, dokumentiranim vlasništvom nad KMS-om i dokazima rotacije. Oboje trebaju upravljanje razmjerno riziku.
Životni ciklus ključa koji vaš ISMS treba kontrolirati
Praktičan program upravljanja ključevima prati životni ciklus. Svaka faza treba vlasnika, odobrenu metodu, tehničku kontrolu, zapis promjene i revizijske dokaze.
| Faza životnog ciklusa | Ključno pitanje upravljanja | Očekivanje kontrole | Primjer dokaza |
|---|---|---|---|
| Klasifikacija | Koji podaci ili transakcije trebaju kriptografsku zaštitu? | Klasifikacija podataka identificira osobne podatke, financijske podatke, vjerodajnice, zapise dnevnika, sigurnosne kopije i osjetljive konfiguracije | Registar klasifikacije podataka, matrica zahtjeva za šifriranje |
| Dizajn | Koja je kriptografska metoda odobrena? | Odobreni algoritmi, protokoli, biblioteke i duljine ključeva definiraju se i pregledavaju | Kriptografski standard, zapis odluke o arhitekturi |
| Generiranje | Kako se ključevi sigurno stvaraju? | Ključevi se generiraju u odobrenom KMS-u, HSM-u ili validiranim modulima, a ne ručno ili u izvornom kodu | Dnevnički zapisi stvaranja KMS ključa, zapis HSM ceremonije |
| Dodjela | Tko je vlasnik i administrator ključa? | Dodjeljuju se poslovni vlasnik, tehnički skrbnik i zamjenski skrbnik | Registar upravljanja ključevima |
| Pohrana | Gdje je ključ pohranjen? | Ključevi se pohranjuju u KMS, HSM ili trezor s kontrolama pristupa i revizijskim bilježenjem | KMS politika, konfiguracija trezora, zapisi pristupa |
| Uporaba | Koji sustavi mogu koristiti ključ? | Primjenjuju se načelo najmanjih ovlasti, identitet radnog opterećenja, razdvajanje dužnosti i odobreni API pristup | IAM politika, mapiranje servisnog računa |
| Rotacija | Kada i zašto se ključ rotira? | Planirana rotacija i rotacija potaknuta događajem za kompromitaciju ili promjenu uloge | Raspored rotacije, zahtjevi za promjenu, rezultati testiranja |
| Deponiranje i oporavak | Kako se usluge mogu oporaviti bez izlaganja ključeva? | Postupci sigurnosnog kopiranja i oporavka testirani su, a pristup je kontroliran | Test oporavka, zapis odobrenja deponiranja |
| Opoziv | Što se događa nakon kompromitacije ili stavljanja izvan uporabe? | Ključevi i certifikati se opozivaju ili onemogućuju, a ovisni sustavi ažuriraju | Prijava incidenta, zapisnik opoziva |
| Uništenje | Kako se umirovljeni ključevi uništavaju? | Sigurno brisanje ili kriptografsko brisanje slijedi zahtjeve zadržavanja i pravne zahtjeve | Zapis o uništenju, KMS raspored brisanja |
Korporativna Politika kriptografskih kontrola pojačava sigurno generiranje:
„Generiranje ključeva: provodi se korištenjem sigurnih hardverskih ili softverskih modula (npr. HSM-ovi, sustavi validirani prema FIPS 140-2).”
Atribucija: korporativna politika, Politika kriptografskih kontrola, zahtjevi za implementaciju politike, točka 6.3.1 Politika kriptografskih kontrola
Također propisuje rotaciju:
„Rotacija ključeva: zahtijeva se u definiranim intervalima ili odmah nakon kompromitacije ili promjene uloge.”
Atribucija: korporativna politika, Politika kriptografskih kontrola, zahtjevi za implementaciju politike, točka 6.3.4 Politika kriptografskih kontrola
Za mala i srednja poduzeća isto se načelo pojavljuje jednostavnijim operativnim jezikom:
„Rotacija ključeva mora se provoditi u skladu s rasporedima isteka ili nakon sumnje na kompromitaciju”
Atribucija: politika za MSP, Politika kriptografskih kontrola za MSP, zahtjevi za implementaciju politike, točka 6.3.4 Politika kriptografskih kontrola za MSP
Te su točke važne za NIS2 i DORA jer zastarjeli ili slabo upravljani ključevi nisu samo slabosti povjerljivosti. Mogu postati zapreke u odgovoru na incidente, problemi ovisnosti o dobavljačima, neuspjesi oporavka od katastrofe i problemi obavješćivanja klijenata.
KMS u oblaku, HSM i BYOK: zamka podijeljene odgovornosti
Šifriranje u oblaku jedan je od najčešćih izvora lažne sigurnosti. Pružatelj usluga u oblaku može šifrirati pohranu prema zadanim postavkama, ali to ne znači automatski da je vaša organizacija uspostavila upravljanje ključevima.
Zenith Blueprint, faza kontrole u praksi, korak 23, objašnjava kontrolu ISO/IEC 27002:2022 5.23 usmjeravajući se na upravljanje oblakom, vidljivost i podijeljenu odgovornost. Naglašava da pružatelj usluga može osiguravati infrastrukturu, ali korisnik ostaje odgovoran za podatke, konfiguracije, politike pristupa i spremnost za odgovor na incidente.
„Pružatelji usluga u oblaku osiguravaju infrastrukturu, ali vi ste i dalje odgovorni za svoje podatke, svoje konfiguracije, svoje politike pristupa i svoju spremnost za odgovor na incidente.”
Atribucija: Zenith Blueprint, faza kontrole u praksi, korak 23, organizacijske kontrole 5.19-5.37 Zenith Blueprint
Tu odgovornost za ključeve u oblaku postaje rizik na razini upravljačkog tijela. SaaS tvrtka može koristiti šifriranje kojim upravlja pružatelj za zapise dnevnika niskog rizika, ključeve kojima upravlja korisnik za korisničke baze podataka, BYOK za regulirane zakupce i korijenske ključeve podržane HSM-om za potpisivanje ili tokenizaciju. Svaki izbor ima implikacije za usklađenost.
Clarysecova korporativna Politika korištenja usluga u oblaku Politika korištenja usluga u oblaku daje jasan smjer kontrole:
„Ključevi kojima upravlja korisnik (CMK) ili Bring Your Own Key (BYOK) moraju se koristiti kada ih pružatelj usluga u oblaku podržava.”
Atribucija: korporativna politika, Politika korištenja usluga u oblaku, zahtjevi za implementaciju politike, točka 6.4.2 Politika korištenja usluga u oblaku
To ne znači da svaka usluga u oblaku mora koristiti BYOK. Znači da organizacija mora svjesno odlučiti na temelju rizika, obveza prema klijentima, ugovornih zahtjeva i mogućnosti oporavka.
| Model vlasništva nad ključem | Prikladan slučaj uporabe | Fokus upravljanja |
|---|---|---|
| Ključevi kojima upravlja pružatelj | Telemetrija niskog rizika, neosjetljivi zapisi dnevnika, standardno platformsko šifriranje | Potvrditi kontrole pružatelja, dokumentirati osnovu rizika, pratiti konfiguraciju usluge |
| Ključevi kojima upravlja korisnik | Produkcijske baze podataka, sigurnosne kopije, evidencije klijenata, regulirana radna opterećenja | Dodijeliti vlasnika, ograničiti pristup, evidentirati uporabu ključa, rotirati i testirati oporavak |
| BYOK ili vanjsko upravljanje ključevima | Zakupci visokog rizika, ugovorno razdvajanje, obveze prema reguliranim klijentima | Upravljati uvozom, skrbništvom, opozivom, uvjetima dobavljača i testiranjem otpornosti |
| Ključevi podržani HSM-om | Korijenski ključevi za potpisivanje, certifikacijska tijela, tokenizacija i tajne vrijednosti visoke vrijednosti | Primijeniti dvostruku kontrolu, zapise ceremonija, razdvajanje dužnosti i strogi nadzor pristupa |
DORA Article 28 i Article 30 to čine posebno relevantnim za financijske subjekte. Zahtijevaju upravljanje IKT rizikom trećih strana, registre IKT ugovornih aranžmana, dubinsku analizu dobavljača, prava na reviziju i inspekciju, pomoć pri incidentima, zaštitu podataka i pristup, odredbe o oporavku i povratu. Ako pružatelj usluga u oblaku ili SaaS dobavljač upravlja ključevima za šifriranje za kritičnu ili važnu funkciju, taj odnos mora biti vidljiv u registru IKT trećih strana i ugovornim kontrolama.
NIS2 također zahtijeva sigurnost opskrbnog lanca, uključujući ranjivosti specifične za dobavljače, prakse kibernetičke sigurnosti i postupke sigurnog razvoja. Ako kritični dobavljač drži vaše ključeve, upravlja vašim KMS-om, pruža vaš HSM, upravlja životnim ciklusom vaših certifikata ili hostira šifrirane sigurnosne kopije, dobavljač je dio vašeg kriptografskog kontrolnog okruženja.
Odobravanje algoritama i kriptoagilnost u 2026.
Politika upravljanja ključevima za 2026. ne bi trebala samo navesti „AES-256” i „TLS 1.2 ili noviji”. Treba uspostaviti postupak odobravanja i pregleda koji podržava kriptoagilnost. Kriptoagilnost znači da organizacija može identificirati gdje se koriste algoritmi, protokoli, certifikati i duljine ključeva, procijeniti izloženost slabostima ili zastarijevanju i migrirati bez panike.
Clarysecova politika za MSP navodi:
„Smiju se koristiti samo algoritmi i protokoli prema najboljim industrijskim praksama koje je odobrio pružatelj IT podrške (npr. AES-256, RSA 2048, TLS 1.2 ili noviji)”
Atribucija: politika za MSP, Politika kriptografskih kontrola za MSP, zahtjevi za implementaciju politike, točka 6.2.1 Politika kriptografskih kontrola za MSP
Također zahtijeva dokumentaciju:
„Sve metode šifriranja (npr. AES-256, TLS 1.2+) i procesi upravljanja ključevima moraju biti dokumentirani”
Atribucija: politika za MSP, Politika kriptografskih kontrola za MSP, zahtjevi upravljanja, točka 5.3.1 Politika kriptografskih kontrola za MSP
Verzija spremna za reviziju jest odobreni kriptografski standard koji uključuje:
- Dopuštene algoritme i protokole za podatke u mirovanju, podatke u prijenosu, potpise, sažimanje lozinki, tokenizaciju i sigurnosne kopije.
- Zabranjene algoritme, protokole i biblioteke.
- Minimalne duljine ključeva i razdoblja valjanosti certifikata.
- Odobrene KMS, HSM, certifikacijska tijela i platforme za upravljanje tajnim vrijednostima.
- Zahtjeve za sigurno generiranje slučajnih brojeva.
- Smjernice za razvojne inženjere za kriptografske biblioteke.
- Postupak iznimke za naslijeđene sustave.
- Okidače pregleda za ranjivosti, regulatorne promjene, promjene dobavljača i planiranje postkvantne tranzicije.
Postkvantno planiranje ne zahtijeva da svaka organizacija odmah zamijeni svu kriptografiju. Zahtijeva inventar. Bez kriptografskog inventara ne možete znati koji sustavi koriste dugotrajno šifriranje javnim ključem, koji certifikati štite kritične usluge, gdje se nalaze ključevi za potpisivanje ili koji dobavljači moraju podržati migraciju. Registar upravljanja ključevima nije birokracija. On je temelj kriptoagilnosti.
90-minutni sprint za dokaze o upravljanju ključevima
Clarysec često koristi kratki sprint za dokaze s rukovodstvom, sigurnosnim timovima, timovima za oblak i timovima za usklađenost. Cilj je raspršeno znanje o ključevima brzo pretvoriti u revizijske dokaze.
Korak 1: Odaberite jednu kritičnu uslugu
Odaberite sustav koji je važan za NIS2, DORA ili GDPR. Primjeri uključuju korisnički identitet, obradu plaćanja, praćenje transakcija, produkcijsku korisničku bazu podataka, platformu za šifrirane sigurnosne kopije ili API dostupan klijentima.
Korak 2: Otvorite Registar upravljanja ključevima
Koristite zahtjev Politike kriptografskih kontrola za centralizirani registar kao strukturu. Ako ga još nemate, izradite jednostavan registar sa sljedećim poljima:
| Polje registra | Primjer unosa |
|---|---|
| ID ključa ili certifikata | prod-db-cmk-eu-west-01 |
| Kontekst uporabe | Šifriranje produkcijske korisničke baze podataka |
| Zaštićeni podaci | Osobni podaci korisnika iz EU-a i metapodaci za naplatu |
| Vlasnik | Head of Platform |
| Skrbnik | Cloud Security Lead |
| Lokacija pohrane | KMS u oblaku, regija EU |
| Vrsta ključa | Simetrični ključ kojim upravlja korisnik |
| Datum stvaranja | 2026-01-14 |
| Učestalost rotacije | 180 dana |
| Zadnja rotacija | 2026-04-10 |
| Sljedeća rotacija | 2026-10-07 |
| Model pristupa | Samo servisna uloga, administratorski pristup preko hitne grupe |
| Evidentiranje događaja | KMS API dnevnički zapisi prosljeđuju se u SIEM |
| Metoda oporavka | KMS sigurnosna kopija i testirani postupak vraćanja |
| Ovisnost o dobavljaču | KMS pružatelja usluga u oblaku |
| Mapiranje usklađenosti | ISO 8.24, 5.17, 5.23, GDPR Article 32, NIS2 Article 21, DORA IKT rizik |
| Poveznica na dokaz | Zahtjev za promjenu, snimka zaslona KMS-a, IAM pregled, upit dnevničkih zapisa, test oporavka |
Korak 3: Pratite pristup i dvostruku kontrolu
Za kriptografske operacije visokog utjecaja primijenite dvostruku kontrolu i načelo najmanjih ovlasti. Korporativna Politika kriptografskih kontrola navodi:
„Na osjetljive kriptografske operacije moraju se primijeniti načela dvostruke kontrole i najmanjih ovlasti (npr. uvoz korijenskih ključeva, administracija HSM-a).”
Atribucija: korporativna politika, Politika kriptografskih kontrola, zahtjevi za implementaciju politike, točka 6.6.2 Politika kriptografskih kontrola
Pitajte:
- Tko može onemogućiti ili izbrisati ključ?
- Tko može promijeniti politiku ključa?
- Tko može izravno dešifrirati podatke?
- Prate li se hitne uloge i jesu li vremenski ograničene?
- Provodi li se MFA za privilegirane operacije s ključevima?
- Evidentiraju li se i pregledavaju privilegirane radnje?
Korak 4: Prikupite pet zapisa dokaza
Prikupite pet zapisa koji dokazuju da kontrola radi:
- Dnevnički zapis stvaranja ili uvoza ključa.
- Trenutačna KMS ili HSM politika pristupa.
- Zadnji zahtjev za promjenu rotacije ključa.
- SIEM upit koji prikazuje uporabu ključa ili administratorske radnje.
- Dokaz testiranja oporavka ili vraćanja.
Korak 5: Mapirajte na rizik i regulativu
Dodajte kratku izjavu o riziku: „Neovlaštena uporaba ili gubitak ovog ključa mogao bi izložiti osobne podatke iz EU-a, prekinuti korisničku uslugu i narušiti oporavak kritičnih sustava.” Zatim je mapirajte na relevantne obveze.
| Obveza | Što dokazi podržavaju |
|---|---|
| ISO/IEC 27001:2022 točke 6 i 8 | Obrada rizika, operativna kontrola, dokumentirani rezultati |
| ISO/IEC 27002:2022 8.24 | Odobrena uporaba kriptografije i kontrola životnog ciklusa ključeva |
| NIS2 Article 21 | Politike kriptografije i šifriranja, kibernetička higijena, kontrola pristupa, upravljanje imovinom |
| DORA Articles 5, 6, 17, 28 i 30 | IKT upravljanje, okvir IKT rizika, proces incidenta, ovisnosti o trećim stranama i ugovori |
| GDPR Article 5 i Article 32 | Odgovornost, cjelovitost i povjerljivost, sigurnost obrade |
| NIST CSF 2.0 | Identifikacija imovine, zaštita podataka, otkrivanje anomalija, odgovor i oporavak |
U 90 minuta tim obično može utvrditi je li upravljanje ključevima stvarno ili pretpostavljeno.
Prijavljivanje incidenata: kada kompromitacija ključa pokreće rokove
Sumnja na kompromitaciju ključa nije automatski prijavljiva povreda, ali može pokrenuti regulatorne rokove.
Prema NIS2, ključni i važni subjekti moraju bez nepotrebnog odgađanja prijaviti značajne incidente koji utječu na pružanje usluge. Fazni model uključuje rano upozorenje u roku od 24 sata od saznanja, obavijest o incidentu u roku od 72 sata, ažuriranja statusa kada se zatraže i završno izvješće najkasnije mjesec dana nakon obavijesti o incidentu.
Prema DORA, financijski subjekti moraju otkrivati, upravljati i prijavljivati incidente povezane s IKT-om, evidentirati incidente i značajne kibernetičke prijetnje, klasificirati incidente prema ozbiljnosti i kritičnosti zahvaćene usluge, komunicirati s dionicima, prijavljivati velike incidente višem rukovodstvu i nadležnim tijelima, provoditi analizu temeljnog uzroka i otklanjati nedostatke. Povjeravanje prijavljivanja vanjskom izvođaču može biti moguće, ali odgovornost ostaje na financijskom subjektu.
Prema GDPR-u, pitanje postaje je li došlo do povrede osobnih podataka, što znači slučajno ili nezakonito uništenje, gubitak, izmjenu, neovlašteno otkrivanje ili pristup osobnim podacima. Snažno šifriranje uz nekompromitirane ključeve može bitno promijeniti analizu rizika povrede. Slabo upravljanje ključevima može potkopati taj argument.
Operativne upute za kompromitaciju ključa trebaju definirati:
- Kako se otkriva sumnja na izlaganje ključa.
- Tko proglašava kriptografski incident.
- Kako se identificiraju zahvaćeni podaci, usluge, klijenti i jurisdikcije.
- Kako se ključevi opozivaju ili rotiraju.
- Kako se ovisni sustavi vraćaju.
- Kako se očuva cjelovitost dokaza.
- Kako se donose odluke o pravnim, regulatornim i korisničkim obavijestima.
Registar upravljanja ključevima postaje ključan tijekom tog procesa. Bez njega osobe zadužene za odgovor gube vrijeme utvrđujući što je ključ štitio. S njim mogu brzo odrediti opseg utjecaja.
Revizijska perspektiva: jedan skup kontrola, mnogi korisnici dokaza
Različiti revizori pristupaju upravljanju kriptografskim ključevima iz različitih područja, ali svi se približavaju istim dokazima.
| Revizijska perspektiva | Vjerojatno revizijsko pitanje | Dokazi koji funkcioniraju |
|---|---|---|
| Revizor ISO/IEC 27001:2022 | Je li upravljanje kriptografskim ključevima odabrano kroz obradu rizika, dokumentirano u Izjavi o primjenjivosti i provedeno prema planu? | Procjena rizika, Izjava o primjenjivosti, kriptografska politika, Registar upravljanja ključevima, zapisi o rotaciji |
| Procjenitelj NIST CSF | Jesu li kriptografska imovina identificirana, zaštićena, nadzirana i oporavljiva? | Popisi imovine i podataka, kontrole pristupa, KMS dnevnički zapisi, SIEM upozorenja, zapisi odgovora i oporavka |
| DORA revizor | Jesu li ovisnosti o ključevima dio upravljanja IKT rizicima, nadzora trećih strana, testiranja otpornosti i prijavljivanja incidenata? | Okvir IKT rizika, registar trećih strana, ugovori za KMS u oblaku, testovi neprekidnosti, proces klasifikacije incidenata |
| Pregled prema GDPR-u | Smanjuje li šifriranje rizik za pojedince i može li voditelj obrade dokazati odgovornost? | Klasifikacija podataka, odvajanje ključeva, zapisi pristupa, dizajn šifriranja, procjena rizika povrede |
| ISACA ili COBIT 2019 revizor | Jesu li definirani ciljevi upravljanja, vlasništvo nad rizikom, učinkovitost kontrola i odgovornost uprave? | RACI, metrike kontrola, preispitivanje uprave, Registar iznimki, praćenje korektivnih mjera nakon revizije |
Snažan revizijski paket za upravljanje kriptografskim ključevima obično sadrži:
- Odobrenu Politiku kriptografskih kontrola.
- Odobrenu Politiku korištenja usluga u oblaku kada je šifriranje u oblaku relevantno.
- Kriptografski standard i popis algoritama.
- Registar upravljanja ključevima.
- Popis certifikata i tajnih vrijednosti.
- Arhitekturu KMS-a, HSM-a i trezora.
- Dokaze pregleda IAM-a i privilegiranog pristupa.
- Zapise o rotaciji i opozivu.
- Dokaze testiranja sigurnosnog kopiranja, deponiranja i oporavka.
- Pravila evidentiranja događaja i nadzora aktivnosti ključeva.
- Mapiranje dobavljača i podijeljene odgovornosti u oblaku.
- Operativne upute za incidente za sumnju na kompromitaciju ključa.
- Iznimke i prihvaćanja rizika.
- Zapise preispitivanja uprave i korektivnih mjera nakon revizije.
Taj paket pretvara tvrdnju o kontroli u dokaz.
Česti nalazi u revizijama upravljanja ključevima
Najčešći nalazi mogu se izbjeći:
- Ne postoji jedinstveni popis ključeva, certifikata i kriptografskih alata.
- Zadano šifriranje pružatelja usluga u oblaku tretira se kao potpuno upravljanje ključevima.
- Produkcijskim ključevima nije dodijeljen vlasnik ili skrbnik.
- Rotacija postoji za certifikate, ali ne za aplikacijske ključeve ili CMK-ove baza podataka.
- Tajne vrijednosti i ključevi pomiješani su u istom trezoru bez klasifikacije.
- Razvojni inženjeri mogu stvarati ključeve izvan odobrenih obrazaca.
- Nema dokaza da se administratori KMS-a pregledavaju.
- Postupci oporavka postoje, ali nikada nisu testirani.
- Kompromitacija ključa nije uključena u operativne upute za odgovor na incidente.
- Naslijeđeni algoritmi ostaju u internim uslugama jer nitko ne posjeduje otklanjanje nedostataka.
- BYOK obveze preuzimaju se u ugovorima s klijentima, ali nisu odražene u operacijama.
- Šifriranje kojim upravlja dobavljač nije uključeno u preglede rizika dobavljača.
Svaki se nalaz vraća na upravljanje. Zato se kriptografija ne može tretirati kao isključivo inženjerski projekt. Mora se povezati s opsegom ISMS-a, obradom rizika, politikom, dobavljačima, oblakom, pristupom, evidentiranjem događaja, incidentima i neprekidnošću poslovanja.
Učinite upravljanje ključevima spremnim za reviziju prije sljedećeg incidenta
Ako se vaša organizacija priprema za NIS2, DORA, dokaze prema GDPR Article 32, certifikaciju ISO/IEC 27001:2022 ili postkvantnu kriptoagilnost, počnite jednim pitanjem: možete li danas izraditi potpun Registar upravljanja ključevima?
Ako ne možete, Clarysec vam može pomoći izgraditi kontrolni sustav oko njega.
Koristite Zenith Blueprint Zenith Blueprint za strukturiranje rada kroz fazu upravljanja rizicima, korak 14, i fazu kontrole u praksi, korak 20. Koristite Zenith Controls Zenith Controls za mapiranje kontrola ISO/IEC 27002:2022 8.24, 5.17 i 5.23 kroz NIS2, DORA, GDPR, NIST i revizijska očekivanja. Koristite Clarysecovu Politiku kriptografskih kontrola Politika kriptografskih kontrola, Politiku kriptografskih kontrola za MSP Politika kriptografskih kontrola za MSP i Politiku korištenja usluga u oblaku Politika korištenja usluga u oblaku kako biste zahtjeve pretvorili u operativna pravila.
Praktičan sljedeći korak je jednostavan: odaberite jednu kritičnu uslugu, popišite njezine ključeve, dokažite vlasništvo, provjerite pristup, prikupite dokaze o rotaciji i testirajte oporavak. Ako to traje dulje od jednog dana, vaše kriptografsko upravljanje zahtijeva pozornost prije nego što regulator, revizor ili tim za odgovor na incidente postavi isto pitanje pod pritiskom.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
