Kriptografinių raktų valdymas ISO 27001, NIS2 ir DORA kontekste

Pirmadienio rytą 08:17 Europos SaaS bendrovės vyriausiasis informacijos saugumo vadovas (CISO) gauna pranešimą iš inžinerijos vadovo: „Savaitgalį pakeitėme duomenų bazės šifravimo raktą, tačiau viena integracija nustojo iššifruoti įrašus. Grąžinome ankstesnę būseną naudodami seną raktą iš saugyklos.“

Po dešimties minučių duomenų apsaugos pareigūnas (DPO) klausia, ar paveiktuose įrašuose yra ES asmens duomenų. Finansų funkcija klausia, ar tai gali tapti praneštinu operaciniu incidentu reguliuojamam klientui. Pirkimų komanda klausia, kam priklauso kliento valdomas raktas – debesijos paslaugų teikėjui ar bendrovei. Generalinis direktorius užduoda vienintelį valdybai svarbų klausimą: „Ar galime įrodyti, kad tai valdėme tinkamai?“

Tai momentas, kai frazė „mes naudojame šifravimą“ nustoja raminti ir tampa įrodymų klausimu.

2026 m. kriptografinių raktų valdymas yra ISO/IEC 27001:2022 kontrolės priemonių, NIS2 kibernetinio saugumo higienos, DORA IRT rizikos valdymo, GDPR Article 32 tvarkymo saugumo įrodymų, debesijos bendros atsakomybės ir pokvantinio kriptografinio lankstumo planavimo sankirtoje. Esminis klausimas nėra tai, ar šifravimas egzistuoja. Esminis klausimas – ar organizacija gali įrašais parodyti, kad raktai generuojami saugiai, priskiriami savininkams, saugomi patvirtintose KMS arba HSM aplinkose, keičiami pagal grafiką, saugiai atkuriami, atšaukiami kompromitavimo atveju ir susiejami su verslo rizika.

Clarysec pasirengimo projektuose nuolat mato tą patį modelį. Šifravimas diegiamas atskirai kiekvienoje sistemoje, tačiau raktų valdysena lieka fragmentuota. Sertifikatai tvarkomi skaičiuoklėse. Debesijos KMS leidimai paveldimi iš senų projektų. Kūrėjai žino, kurios paslaptys svarbios, bet ISVS – ne. Auditoriai gauna ekrano kopijas vietoj gyvavimo ciklo įrodymų. NIS2 ir DORA komandos kalba apie atsparumą, privatumo komandos – apie GDPR šifravimą ir pseudonimizavimą, o kriptografinės kontrolės aplinkos nuo pradžios iki pabaigos niekas nevaldo.

Brandus atsakymas nėra daugiau atskirai taikomos kriptografijos. Tai valdoma kriptografinių raktų valdysena, susieta su rizikos tvarkymu, debesijos architektūra, tiekėjų priežiūra, prieigos kontrole, žurnalavimu, reagavimu į incidentus ir reglamentavimo įrodymais.

Kodėl raktų valdymas tapo valdysenos klausimu

NIS2 kriptografijos ir šifravimo politikas priskiria prie minimalių kibernetinio saugumo rizikos valdymo priemonių esminiams ir svarbiems subjektams. Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių, įskaitant rizikos analizę, incidentų tvarkymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų kūrimą, kibernetinio saugumo higieną, prieigos kontrolę, turto valdymą bei kriptografijos ir šifravimo politikas. Jis taip pat reikalauja, kad valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones ir prižiūrėtų jų įgyvendinimą.

SaaS, debesijos, valdomų paslaugų ir valdomų saugumo paslaugų teikėjams taikymo sritis gali būti platesnė, nei daugelis komandų mano. NIS2 apima tokius sektorius kaip skaitmeninė infrastruktūra, debesijos kompiuterijos paslaugų teikėjai, duomenų centrų teikėjai, DNS teikėjai, patikimumo užtikrinimo paslaugų teikėjai, valdomų paslaugų teikėjai, valdomų saugumo paslaugų teikėjai, internetinės prekyvietės, paieškos sistemos ir socialinių tinklų platformos, kai tenkinami dydžio arba kritiškumo slenksčiai.

DORA finansų subjektams kelia aukštesnius reikalavimus. Nuo 2025 m. sausio 17 d. DORA reikalauja dokumentuotos IRT rizikos valdymo sistemos, valdybos atskaitomybės, IRT veiklos tęstinumo ir reagavimo bei atkūrimo planų, skaitmeninio operacinio atsparumo testavimo, IRT trečiųjų šalių rizikos valdymo ir pranešimo apie incidentus. Finansų subjektams, identifikuotiems pagal nacionalines NIS2 taisykles, DORA veikia kaip sektoriui skirtas Sąjungos teisės aktas, taikomas lygiaverčiams NIS2 įpareigojimams. Fintech bendrovė neturėtų turėti atskiros kriptografinės valdysenos NIS2, DORA ir ISO tikslams. Jai reikia vieno pagrindžiamo kontrolės modelio.

GDPR prideda privatumo įrodymų dimensiją. GDPR Article 32 yra vieta, kur šifravimas dažnai vertinamas kaip tvarkymo saugumo apsaugos priemonė, tačiau atsakymo „duomenys yra užšifruoti“ nepakanka. Reguliavimo institucijos ir auditoriai klausia, kas kontroliuoja raktus, kaip ribojama prieiga, kaip aptinkamas kompromitavimas, kaip veikia atkūrimas ir ar projektinis sprendimas atitinka riziką fiziniams asmenims.

ISO/IEC 27001:2022 suteikia organizacijoms valdymo sistemą, kuria šie įpareigojimai sujungiami. 4.1–4.4 skyriai reikalauja nustatyti kontekstą, suinteresuotųjų šalių reikalavimus, ISVS taikymo sritį ir sąveikaujančius procesus. 5.1–5.3 skyriai reikalauja lyderystės, politikos, išteklių ir priskirtų atsakomybių. 6.1.1–6.1.3 skyriai reikalauja rizikos vertinimo, rizikos tvarkymo, kontrolės priemonių parinkimo, Taikomumo pareiškimo ir rizikos savininko patvirtinimo. 8.1–8.3 skyriai reikalauja kontroliuojamos veiklos, pakartotinio rizikos vertinimo įvykus pokyčiams, rizikos tvarkymo planų įgyvendinimo ir dokumentuotų rezultatų saugojimo.

Kriptografinių raktų valdymo atveju ISVS turi atsakyti į penkis klausimus:

1. Kuriems informacijos ištekliams, duomenų srautams ir paslaugoms reikalinga kriptografinė apsauga?
2. Kokie raktai, sertifikatai, paslaptys ir kriptografinės paslaugos juos saugo?
3. Kas yra šių kriptografinių išteklių savininkai, administratoriai, tvirtintojai ir stebėtojai?
4. Kaip kontroliuojamas generavimas, saugojimas, naudojimas, periodinis keitimas, deponavimas, atkūrimas, atšaukimas ir sunaikinimas?
5. Kokie įrodymai patvirtina, kad kontrolės priemonės veikė taip, kaip suprojektuota?

ISO 27001 kontrolės priemonių atrama kriptografinių raktų valdymui

Clarysec kriptografinių raktų valdymą vertina kaip kontrolės priemonių grandinę, o ne kaip vieną kontrolės priemonę. Zenith Controls: The Cross-Compliance Guide Zenith Controls šią temą pirmiausia sieja su ISO/IEC 27002:2022 kontrolės priemone 8.24, kriptografijos naudojimu, taip pat su svarbiomis palaikančiomis sąsajomis su 5.17, autentifikavimo informacija, ir 5.23, informacijos saugumu naudojant debesijos paslaugas.

Ši sąsaja svarbi. Raktų valdymo nesėkmė retai būna tik „blogas šifravimas“. Dažnai tai autentifikavimo problema, debesijos valdysenos problema, tiekėjo problema, žurnalavimo spraga arba pakeitimų valdymo nesėkmė.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint šią logiką paverčia veiksmu Rizikos valdymo etape, 14 žingsnyje, Rizikos tvarkymo politikos ir reglamentavimo kryžminės nuorodos. Jo kriptografijos politikos pavyzdys nurodo, kad organizacija turi apibrėžti, kur reikalinga kriptografija, patvirtinti algoritmus ir protokolus, apibrėžti raktų valdymą, apimti tokius naudojimo atvejus kaip viso disko šifravimas ir saugi komunikacija, ir susieti politiką su GDPR Article 32.

„Šifravimo raktai turi būti saugomi saugiai (pvz., raktų saugykloje / HSM), o prieiga turi būti ribojama tik autorizuotam personalui.“
Šaltinis: Zenith Blueprint, Rizikos valdymo etapas, 14 žingsnis, Rizikos tvarkymo politikos ir reglamentavimo kryžminės nuorodos Zenith Blueprint

Veikiančių kontrolės priemonių etape, 20 žingsnyje, Zenith Blueprint nagrinėja giliau. Kriptografija nėra „šifravimo įjungimas“. Tai kriptografijos įtraukimas į projektavimą, politiką ir gyvavimo ciklo valdymą. Tai apima saugomus duomenis, perduodamus duomenis, tapatybių ir operacijų autentifikavimą, patvirtintus algoritmus, raktų saugyklas, HSM, planinį periodinį raktų keitimą, atšaukimą ir validavimą per įsiskverbimo testavimą bei kodo peržiūrą.

Ko auditoriai tikisi prašydami raktų įrodymų

Dauguma audito išvadų prasideda paprastu prašymu: „Parodykite šifravimo politiką ir raktų valdymo įrašus.“

Silpni atsakymai:

• „Debesijos paslaugų teikėjas viską šifruoja pagal numatytuosius nustatymus.“
• „Naudojame TLS.“
• „Paslaptys yra saugykloje.“
• „Inžinerijos komanda tvarko periodinį raktų keitimą.“
• „Raktą valdo taikomoji programa.“

Šie teiginiai gali būti techniškai teisingi, tačiau jie nėra pilni įrodymai. ISO auditorius susies raktų valdymą su rizikos vertinimu, Taikomumo pareiškimu, politikos reikalavimais, operacine kontrole ir saugoma dokumentacija. NIST CSF vertintojas klaus, ar kriptografiniai ištekliai yra identifikuoti, apsaugoti, stebimi ir atkuriami. DORA auditorius ieškos valdybos patvirtintos IRT rizikos valdysenos, priklausomybių nuo trečiųjų šalių, incidentų valdymo ir atsparumo testavimo. GDPR peržiūrą atliekantis specialistas klaus, ar šifravimas ir raktų atskyrimas mažina riziką fiziniams asmenims ir ar duomenų valdytojas gali įrodyti atskaitomybę.

Clarysec organizacijos lygmens Kriptografinių kontrolės priemonių politika Kriptografinių kontrolės priemonių politika tiesiogiai sprendžia įrodymų spragą:

„Turi būti prižiūrimas centralizuotas raktų valdymo registras, kuriame fiksuojami visi kriptografiniai raktai, jų gyvavimo ciklo būsena, priskirti atsakingi saugotojai ir naudojimo kontekstai.“
Šaltinis: organizacijos politika, Kriptografinių kontrolės priemonių politika, Valdysenos reikalavimai, 5.2 skyrius Kriptografinių kontrolės priemonių politika

Šis sakinys pakeičia audito pokalbį. Užuot ieškojusi neformalių žinių, organizacija gali parodyti registrą, kuris susieja raktus su turtais, savininkais, duomenų klasifikacijomis, sistemomis, debesijos paskyromis, periodinio raktų keitimo datomis, naudojimo kontekstais ir įrodymais.

MVĮ atveju Clarysec Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme - SME taiko tą patį lūkestį proporcingu mastu:

„IT pagalbos teikėjas turi prižiūrėti aktualią naudojamų kriptografinių priemonių ir sertifikatų apskaitą.“
Šaltinis: MVĮ politika, Cryptographic Controls Policy-sme, Valdysenos reikalavimai, 5.1.2 skyrius Cryptographic Controls Policy-sme - SME

Reguliuojamai finansų įstaigai gali reikėti HSM ceremonijų, atskirtų žinių, dvigubos kontrolės, formalių atsakingų saugotojų paskyrimų ir ketvirtinių prieigos peržiūrų. Nedidelis SaaS teikėjas gali pradėti nuo prižiūrimos apskaitos, patvirtintų algoritmų, dokumentuotos KMS savininkystės ir periodinio raktų keitimo įrodymų. Abiem reikia valdysenos, proporcingos rizikai.

Raktų gyvavimo ciklas, kurį turi kontroliuoti jūsų ISVS

Praktinė raktų valdymo programa laikosi gyvavimo ciklo. Kiekvienam etapui reikia savininko, patvirtinto metodo, techninės kontrolės priemonės, pakeitimo įrašo ir audito įrodymų.

Organizacijos lygmens Kriptografinių kontrolės priemonių politika sustiprina saugų generavimą:

„Raktų generavimas: atliekamas naudojant saugius aparatinės arba programinės įrangos modulius (pvz., HSM, FIPS 140-2 validuotas sistemas).“
Šaltinis: organizacijos politika, Kriptografinių kontrolės priemonių politika, Politikos įgyvendinimo reikalavimai, 6.3.1 skyrius Kriptografinių kontrolės priemonių politika

Ji taip pat apibrėžia periodinį raktų keitimą:

„Periodinis raktų keitimas: privalomas nustatytais intervalais arba nedelsiant kompromitavimo ar vaidmens pasikeitimo atveju.“
Šaltinis: organizacijos politika, Kriptografinių kontrolės priemonių politika, Politikos įgyvendinimo reikalavimai, 6.3.4 skyrius Kriptografinių kontrolės priemonių politika

MVĮ atveju tas pats principas išreikštas paprastesne operacine kalba:

„Periodinis raktų keitimas turi būti atliekamas pagal galiojimo pabaigos grafikus arba įtarus kompromitavimą.“
Šaltinis: MVĮ politika, Cryptographic Controls Policy-sme, Politikos įgyvendinimo reikalavimai, 6.3.4 skyrius Cryptographic Controls Policy-sme - SME

Šios nuostatos svarbios NIS2 ir DORA kontekste, nes pasenę arba prastai valdomi raktai nėra vien konfidencialumo silpnybės. Jie gali tapti reagavimo į incidentus kliūtimis, priklausomybės nuo tiekėjų problemomis, atkūrimo po katastrofos nesėkmėmis ir klientų informavimo problemomis.

Debesijos KMS, HSM ir BYOK: bendros atsakomybės spąstai

Debesijos šifravimas yra vienas dažniausių klaidingo pasitikėjimo šaltinių. Debesijos paslaugų teikėjas gali šifruoti saugyklą pagal numatytuosius nustatymus, tačiau tai automatiškai nereiškia, kad jūsų organizacija valdo raktą.

Zenith Blueprint, Veikiančių kontrolės priemonių etapas, 23 žingsnis, aiškina ISO/IEC 27002:2022 kontrolės priemonę 5.23, sutelkdamas dėmesį į debesijos valdyseną, matomumą ir bendrą atsakomybę. Jame pabrėžiama, kad teikėjas gali apsaugoti infrastruktūrą, tačiau klientas lieka atskaitingas už duomenis, konfigūracijas, prieigos politikas ir pasirengimą reaguoti į incidentus.

„Debesijos paslaugų teikėjai apsaugo infrastruktūrą, tačiau jūs vis tiek esate atskaitingi už savo duomenis, konfigūracijas, prieigos politikas ir pasirengimą reaguoti į incidentus.“
Šaltinis: Zenith Blueprint, Veikiančių kontrolės priemonių etapas, 23 žingsnis, Organizacinės kontrolės priemonės 5.19-5.37 Zenith Blueprint

Čia debesijos raktų atsakomybė tampa valdybos lygmens rizika. SaaS bendrovė gali naudoti teikėjo valdomą šifravimą mažos rizikos žurnalams, kliento valdomus raktus klientų duomenų bazėms, BYOK reguliuojamiems nuomininkams ir HSM paremtus pagrindinius raktus pasirašymui arba tokenizavimui. Kiekvienas pasirinkimas turi atitikties pasekmių.

Clarysec organizacijos lygmens Debesijos paslaugų naudojimo politika Debesijos paslaugų naudojimo politika pateikia aiškią kontrolės kryptį:

„Kliento valdomi raktai (CMK) arba Bring Your Own Key (BYOK) turi būti naudojami ten, kur juos palaiko debesijos paslaugų teikėjas.“
Šaltinis: organizacijos politika, Debesijos paslaugų naudojimo politika, Politikos įgyvendinimo reikalavimai, 6.4.2 skyrius Debesijos paslaugų naudojimo politika

Tai nereiškia, kad kiekviena debesijos paslauga privalo naudoti BYOK. Tai reiškia, kad organizacija turi priimti sąmoningą sprendimą, grindžiamą rizika, įsipareigojimais klientams, sutartiniais reikalavimais ir atkuriamumu.

DORA Article 28 ir Article 30 tai daro ypač aktualu finansų subjektams. Jie reikalauja IRT trečiųjų šalių rizikos valdymo, IRT sutartinių susitarimų registrų, deramo patikrinimo, audito ir patikrinimo teisių, pagalbos incidentų atveju, duomenų apsaugos ir prieigos, atkūrimo bei grąžinimo nuostatų. Jei debesijos paslaugų teikėjas arba SaaS tiekėjas valdo šifravimo raktus, palaikančius kritinę arba svarbią funkciją, šis ryšys turi būti matomas IRT trečiųjų šalių registre ir sutartinėse kontrolės priemonėse.

NIS2 taip pat reikalauja tiekimo grandinės saugumo, įskaitant tiekėjams būdingus pažeidžiamumus, kibernetinio saugumo praktikas ir saugaus kūrimo procedūras. Jei kritinis tiekėjas turi jūsų raktus, valdo jūsų KMS, teikia jūsų HSM, valdo sertifikatų gyvavimo ciklą arba talpina šifruotas atsargines kopijas, tiekėjas yra jūsų kriptografinės kontrolės aplinkos dalis.

Algoritmų patvirtinimas ir kriptografinis lankstumas 2026 m.

2026 m. raktų valdymo politika neturėtų tik išvardyti „AES-256“ ir „TLS 1.2 arba naujesnę versiją“. Ji turi nustatyti patvirtinimo ir peržiūros procesą, palaikantį kriptografinį lankstumą. Kriptografinis lankstumas reiškia, kad organizacija gali nustatyti, kur naudojami algoritmai, protokolai, sertifikatai ir raktų ilgiai, įvertinti silpnybių arba pasenimo poveikį ir migruoti be panikos.

Clarysec MVĮ politika nurodo:

„Gali būti naudojami tik IT pagalbos teikėjo patvirtinti pramonės gerąją praktiką atitinkantys algoritmai ir protokolai (pvz., AES-256, RSA 2048, TLS 1.2 arba naujesnė versija).“
Šaltinis: MVĮ politika, Cryptographic Controls Policy-sme, Politikos įgyvendinimo reikalavimai, 6.2.1 skyrius Cryptographic Controls Policy-sme - SME

Ji taip pat reikalauja dokumentavimo:

„Visi šifravimo metodai (pvz., AES-256, TLS 1.2+) ir raktų valdymo procesai turi būti dokumentuoti.“
Šaltinis: MVĮ politika, Cryptographic Controls Policy-sme, Valdysenos reikalavimai, 5.3.1 skyrius Cryptographic Controls Policy-sme - SME

Auditui tinkama versija yra patvirtintas kriptografinis standartas, apimantis:

• Leidžiamus algoritmus ir protokolus saugomiems duomenims, perduodamiems duomenims, parašams, slaptažodžių maišos skaičiavimui, tokenizavimui ir atsarginėms kopijoms.
• Draudžiamus algoritmus, protokolus ir bibliotekas.
• Mažiausius raktų ilgius ir sertifikatų galiojimo laikotarpius.
• Patvirtintas KMS, HSM, sertifikavimo institucijas ir paslapčių valdymo platformas.
• Saugaus atsitiktinių skaičių generavimo reikalavimus.
• Kūrėjų gaires dėl kriptografinių bibliotekų.
• Išimčių procesą senosioms sistemoms.
• Peržiūros paleidiklius pažeidžiamumams, reglamentavimo pokyčiams, tiekėjų pakeitimams ir pokvantinės migracijos planavimui.

Pokvantinis planavimas nereiškia, kad kiekviena organizacija turi nedelsdama pakeisti visą kriptografiją. Jis reikalauja apskaitos. Be kriptografinės apskaitos negalite žinoti, kurios sistemos naudoja ilgalaikį viešojo rakto šifravimą, kurie sertifikatai saugo kritines paslaugas, kur yra pasirašymo raktai arba kurie tiekėjai turi palaikyti migraciją. Raktų valdymo registras nėra biurokratija. Tai kriptografinio lankstumo pagrindas.

90 minučių raktų valdymo įrodymų sprintas

Clarysec dažnai taiko trumpą įrodymų sprintą su vadovybe, saugumo, debesijos ir atitikties komandomis. Tikslas – greitai paversti išskaidytas žinias apie raktus audito įrodymais.

1 žingsnis: pasirinkite vieną kritinę paslaugą

Pasirinkite sistemą, svarbią NIS2, DORA arba GDPR. Pavyzdžiai: klientų tapatybė, mokėjimų apdorojimas, operacijų stebėsena, produkcinė klientų duomenų bazė, šifruota atsarginių kopijų platforma arba klientams skirta API.

2 žingsnis: atidarykite raktų valdymo registrą

Naudokite Kriptografinių kontrolės priemonių politika reikalavimą dėl centralizuoto registro kaip struktūrą. Jei jo dar neturite, sukurkite paprastą registrą su šiais laukais:

3 žingsnis: atsekite prieigą ir dvigubą kontrolę

Didelio poveikio kriptografinėms operacijoms taikykite dvigubą kontrolę ir mažiausių privilegijų principą. Organizacijos lygmens Kriptografinių kontrolės priemonių politika nurodo:

„Dvigubos kontrolės ir mažiausių privilegijų principai turi būti taikomi jautrioms kriptografinėms operacijoms (pvz., pagrindinių raktų importui, HSM administravimui).“
Šaltinis: organizacijos politika, Kriptografinių kontrolės priemonių politika, Politikos įgyvendinimo reikalavimai, 6.6.2 skyrius Kriptografinių kontrolės priemonių politika

Klauskite:

• Kas gali išjungti arba ištrinti raktą?
• Kas gali pakeisti rakto politiką?
• Kas gali tiesiogiai iššifruoti duomenis?
• Ar avarinės prieigos vaidmenys stebimi ir apriboti laiku?
• Ar MFA taikomas privilegijuotoms raktų operacijoms?
• Ar privilegijuoti veiksmai registruojami žurnaluose ir peržiūrimi?

4 žingsnis: surinkite penkis įrodymų įrašus

Surinkite penkis įrašus, kurie įrodo, kad kontrolės priemonė veikia:

1. Rakto sukūrimo arba importo žurnalą.
2. Dabartinę KMS arba HSM prieigos politiką.
3. Paskutinio periodinio rakto keitimo pakeitimo užklausą.
4. SIEM užklausą, rodančią rakto naudojimą arba administracinius veiksmus.
5. Atkūrimo arba atstatymo testo įrodymus.

5 žingsnis: susiekite su rizika ir reglamentavimu

Pridėkite trumpą rizikos formuluotę: „Neautorizuotas šio rakto naudojimas arba praradimas galėtų atskleisti ES asmens duomenis, sutrikdyti klientų paslaugą ir pabloginti kritinių sistemų atkūrimą.“ Tada susiekite ją su atitinkamais įpareigojimais.

Per 90 minučių komanda paprastai gali nustatyti, ar raktų valdysena yra reali, ar tik numanoma.

Pranešimas apie incidentus: kai rakto kompromitavimas paleidžia laikmatį

Įtariamas rakto kompromitavimas automatiškai nėra praneštinas pažeidimas, tačiau jis gali paleisti reglamentavimo laikmatį.

Pagal NIS2 esminiai ir svarbūs subjektai turi nepagrįstai nedelsdami pranešti apie reikšmingus incidentus, darančius poveikį paslaugų teikimui. Etapinis modelis apima ankstyvą įspėjimą per 24 valandas nuo sužinojimo, pranešimą apie incidentą per 72 valandas, būsenos atnaujinimus, kai jų prašoma, ir galutinę ataskaitą ne vėliau kaip per vieną mėnesį nuo pranešimo apie incidentą.

Pagal DORA finansų subjektai turi aptikti, valdyti ir pranešti apie su IRT susijusius incidentus, registruoti incidentus ir reikšmingas kibernetines grėsmes, klasifikuoti incidentus pagal sunkumą ir paveiktos paslaugos kritiškumą, komunikuoti su suinteresuotosiomis šalimis, pranešti apie didelius incidentus vyresniajai vadovybei ir kompetentingoms institucijoms, atlikti pagrindinės priežasties analizę ir šalinti trūkumus. Ataskaitų teikimo perdavimas išorės teikėjui gali būti galimas, tačiau atsakomybė lieka finansų subjektui.

Pagal GDPR klausimas tampa toks: ar įvyko asmens duomenų saugumo pažeidimas, t. y. atsitiktinis arba neteisėtas asmens duomenų sunaikinimas, praradimas, pakeitimas, neautorizuotas atskleidimas arba prieiga prie jų. Stiprus šifravimas su nekompromituotais raktais gali reikšmingai pakeisti pažeidimo rizikos analizę. Silpnas raktų valdymas gali sugriauti šį argumentą.

Rakto kompromitavimo veiksmų planai turi apibrėžti:

• Kaip aptinkamas įtariamas rakto atskleidimas.
• Kas paskelbia kriptografinį incidentą.
• Kaip identifikuojami paveikti duomenys, paslaugos, klientai ir jurisdikcijos.
• Kaip raktai atšaukiami arba periodiškai pakeičiami.
• Kaip atkuriamos priklausomos sistemos.
• Kaip išsaugomas įrodymų vientisumas.
• Kaip priimami teisiniai, reglamentavimo ir klientų informavimo sprendimai.

Šio proceso metu raktų valdymo registras tampa būtinas. Be jo reagavimo komandos gaišta laiką aiškindamosi, ką raktas saugojo. Su juo jos gali greitai apibrėžti poveikio apimtį.

Audito perspektyva: vienas kontrolės priemonių rinkinys, daug įrodymų naudotojų

Skirtingi auditoriai į kriptografinių raktų valdymą žiūri iš skirtingų profesinių perspektyvų, tačiau jie susiveda į tuos pačius įrodymus.

Stiprus kriptografinių raktų valdymo audito paketas paprastai apima:

• Patvirtintą Kriptografinių kontrolės priemonių politiką.
• Patvirtintą Debesijos paslaugų naudojimo politiką, kai aktualus debesijos šifravimas.
• Kriptografinį standartą ir algoritmų sąrašą.
• Raktų valdymo registrą.
• Sertifikatų ir paslapčių apskaitą.
• KMS, HSM ir saugyklos architektūrą.
• IAM ir privilegijuotos prieigos peržiūros įrodymus.
• Periodinio raktų keitimo ir atšaukimo įrašus.
• Atsarginių kopijų, deponavimo ir atkūrimo testų įrodymus.
• Žurnalų tvarkymo ir stebėsenos taisykles raktų veiklai.
• Tiekėjų ir debesijos bendros atsakomybės susiejimą.
• Incidento veiksmų planą įtariamam rakto kompromitavimui.
• Išimtis ir rizikos priėmimus.
• Vadovybės peržiūros ir audito neatitikčių šalinimo įrašus.

Šis paketas kontrolės teiginį paverčia įrodymu.

Dažnos išvados raktų valdymo audituose

Dažniausių išvadų galima išvengti:

1. Nėra vienos raktų, sertifikatų ir kriptografinių priemonių apskaitos.
2. Debesijos paslaugų teikėjo numatytasis šifravimas laikomas pilna raktų valdysena.
3. Produkciniams raktams nepriskirtas savininkas arba atsakingas saugotojas.
4. Periodinis keitimas taikomas sertifikatams, bet ne taikomųjų programų raktams ar duomenų bazių CMK.
5. Paslaptys ir raktai laikomi toje pačioje saugykloje be klasifikavimo.
6. Kūrėjai gali kurti raktus už patvirtintų modelių ribų.
7. Nėra įrodymų, kad KMS administratoriai peržiūrimi.
8. Atkūrimo procedūros egzistuoja, bet niekada nebuvo testuotos.
9. Rakto kompromitavimas neįtrauktas į reagavimo į incidentus veiksmų planus.
10. Senieji algoritmai lieka vidinėse paslaugose, nes niekas nėra atsakingas už taisomuosius veiksmus.
11. BYOK įsipareigojimai įtraukiami į klientų sutartis, bet neatsispindi operacijose.
12. Tiekėjo valdomas šifravimas neįtraukiamas į tiekėjų rizikos peržiūras.

Kiekviena išvada grįžta prie valdysenos. Todėl kriptografijos negalima laikyti vien inžineriniu projektu. Ji turi būti susieta su ISVS taikymo sritimi, rizikos tvarkymu, politika, tiekėjais, debesija, prieiga, žurnalavimu, incidentais ir tęstinumu.

Parenkite raktų valdyseną auditui iki kito incidento

Jei jūsų organizacija rengiasi NIS2, DORA, GDPR Article 32 įrodymams, ISO/IEC 27001:2022 sertifikavimui arba pokvantiniam kriptografiniam lankstumui, pradėkite nuo vieno klausimo: ar šiandien galite pateikti pilną raktų valdymo registrą?

Jei ne, Clarysec gali padėti sukurti aplink jį veikiančią kontrolės sistemą.

Naudokite Zenith Blueprint Zenith Blueprint, kad struktūruotumėte darbą per Rizikos valdymo etapo 14 žingsnį ir Veikiančių kontrolės priemonių etapo 20 žingsnį. Naudokite Zenith Controls Zenith Controls, kad susietumėte ISO/IEC 27002:2022 kontrolės priemones 8.24, 5.17 ir 5.23 su NIS2, DORA, GDPR, NIST ir audito lūkesčiais. Naudokite Clarysec Kriptografinių kontrolės priemonių politika Kriptografinių kontrolės priemonių politika, Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme - SME ir Debesijos paslaugų naudojimo politika Debesijos paslaugų naudojimo politika, kad reikalavimus paverstumėte veiklos taisyklėmis.

Praktinis kitas žingsnis paprastas: pasirinkite vieną kritinę paslaugą, inventorizuokite jos raktus, įrodykite savininkystę, patikrinkite prieigą, surinkite periodinio raktų keitimo įrodymus ir ištestuokite atkūrimą. Jei tai užtrunka ilgiau nei dieną, jūsų kriptografinė valdysena reikalauja dėmesio dar prieš reguliuotojui, auditoriui ar reagavimo į incidentus komandai užduodant tą patį klausimą esant spaudimui.