Kriptogrāfisko atslēgu pārvaldība ISO 27001, NIS2 un DORA prasību izpildei

Pirmdienas rītā plkst. 08.17 Eiropas SaaS uzņēmuma informācijas drošības vadītājs saņem ziņu no inženierijas vadītāja: “Nedēļas nogalē veicām datubāzes šifrēšanas atslēgas rotāciju, bet viena integrācija pārstāja atšifrēt ierakstus. Atgriezāmies pie vecas atslēgas no seifa.”

Pēc desmit minūtēm datu aizsardzības speciālists jautā, vai skartie ieraksti ietver ES personas datus. Finanšu nodaļa jautā, vai tas var kļūt par ziņojamu darbības incidentu regulēta klienta kontekstā. Iepirkumu nodaļa jautā, vai klienta pārvaldītā atslēga pieder mākoņpakalpojumu sniedzējam vai uzņēmumam. Galvenais izpilddirektors uzdod vienīgo jautājumu, kas valdes telpā patiešām ir svarīgs: “Vai varam pierādīt, ka to pārvaldījām pienācīgi?”

Tas ir brīdis, kad frāze “mēs izmantojam šifrēšanu” pārstāj būt mierinoša un kļūst par pierādījumu jautājumu.

2026. gadā kriptogrāfisko atslēgu pārvaldība atrodas ISO/IEC 27001:2022 kontroles pasākumu, NIS2 kiberdrošības higiēnas, DORA IKT risku pārvaldības, GDPR Article 32 apstrādes drošības pierādījumu, mākoņvides dalītās atbildības un pēckvantu kriptogrāfiskās elastības plānošanas krustpunktā. Patiesais jautājums nav, vai šifrēšana pastāv. Patiesais jautājums ir, vai organizācija ar ierakstiem var pierādīt, ka atslēgas tiek droši ģenerētas, tām ir piešķirti īpašnieki, tās tiek glabātas apstiprinātās KMS vai HSM vidēs, rotētas pēc grafika, droši atjaunotas, atsauktas kompromitēšanas gadījumā un sasaistītas ar biznesa risku.

Clarysec gatavības novērtējumos atkārtoti redz vienu un to pašu modeli. Šifrēšana ir ieviesta pa sistēmām, bet atslēgu pārvaldība ir sadrumstalota. Sertifikāti atrodas izklājlapās. Mākoņvides KMS piekļuves tiesības ir mantotas no veciem projektiem. Izstrādātāji zina, kuri noslēpumi ir būtiski, bet ISMS to nezina. Auditori saņem ekrānuzņēmumus, nevis dzīves cikla pierādījumus. NIS2 un DORA komandas runā par noturību, privātuma komandas runā par GDPR šifrēšanu un pseidonimizāciju, bet neviens nepārvalda kriptogrāfisko kontroles vidi no gala līdz galam.

Nobriedusi atbilde nav vairāk kriptogrāfijas izolētos risinājumos. Tā ir pārvaldīta kriptogrāfisko atslēgu pārvaldība, kas sasaistīta ar riska apstrādi, mākoņarhitektūru, pakalpojumu sniedzēju uzraudzību, piekļuves kontroli, žurnālfiksēšanu, reaģēšanu uz incidentiem un regulatīvajiem pierādījumiem.

Kāpēc atslēgu pārvaldība tagad ir pārvaldības jautājums

NIS2 nosaka kriptogrāfijas un šifrēšanas politikas kā daļu no minimālajiem kiberdrošības risku pārvaldības pasākumiem būtiskām un svarīgām vienībām. Article 21 prasa piemērotus un samērīgus tehniskus, operacionālus un organizatoriskus pasākumus, tostarp riska analīzi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu izstrādi, kiberdrošības higiēnu, piekļuves kontroli, aktīvu pārvaldību, kā arī kriptogrāfijas un šifrēšanas politikas. Tas arī prasa, lai vadības struktūras apstiprinātu un pārraudzītu kiberdrošības risku pārvaldības pasākumus.

SaaS, mākoņpakalpojumu, pārvaldīto pakalpojumu un kiberdrošības pakalpojumu sniedzējiem piemērojamība var būt plašāka, nekā daudzas komandas pieņem. NIS2 aptver tādas nozares kā digitālā infrastruktūra, mākoņdatošanas pakalpojumu sniedzēji, datu centru pakalpojumu sniedzēji, DNS pakalpojumu sniedzēji, uzticamības pakalpojumu sniedzēji, pārvaldīto pakalpojumu sniedzēji, pārvaldīto drošības pakalpojumu sniedzēji, tiešsaistes tirdzniecības vietas, meklētājprogrammas un sociālo tīklu platformas, ja ir sasniegti lieluma vai kritiskuma sliekšņi.

DORA paaugstina prasības finanšu iestādēm. No 2025. gada 17. janvāra DORA prasa dokumentētu IKT risku pārvaldības ietvaru, valdes pārskatatbildību, IKT darbības nepārtrauktības, reaģēšanas un atjaunošanas plānus, digitālās operacionālās noturības testēšanu, IKT trešo pušu risku pārvaldību un incidentu ziņošanu. Finanšu iestādēm, kas identificētas saskaņā ar NIS2 nacionālajiem noteikumiem, DORA darbojas kā nozares specifiskais Savienības tiesību akts līdzvērtīgu NIS2 pienākumu izpildei. Fintech uzņēmumam nevajadzētu uzturēt atsevišķu kriptogrāfijas pārvaldību NIS2, DORA un ISO vajadzībām. Tam ir vajadzīgs viens pamatots kontroles modelis.

GDPR pievieno privātuma pierādījumu dimensiju. GDPR Article 32 ir vieta, kur šifrēšanu parasti vērtē kā apstrādes drošības pasākumu, bet “dati ir šifrēti” nav pilnīga atbilde. Regulatori un auditori jautā, kas kontrolē atslēgas, kā tiek ierobežota piekļuve, kā tiek atklāta kompromitēšana, kā darbojas atjaunošana un vai risinājuma arhitektūra atbilst riskam fiziskām personām.

ISO/IEC 27001:2022 dod organizācijām pārvaldības sistēmu šo pienākumu sasaistīšanai. 4.1 līdz 4.4 punkti prasa kontekstu, ieinteresēto pušu prasības, ISMS darbības jomu un savstarpēji saistītus procesus. 5.1 līdz 5.3 punkti prasa vadību, politiku, resursus un piešķirtas atbildības. 6.1.1 līdz 6.1.3 punkti prasa risku izvērtēšanu, riska apstrādi, kontroles pasākumu atlasi, Piemērojamības paziņojumu un riska īpašnieka apstiprinājumu. 8.1 līdz 8.3 punkti prasa kontrolētu darbību, riska atkārtotu izvērtēšanu izmaiņu gadījumā, riska apstrādes plānu ieviešanu un dokumentētu rezultātu glabāšanu.

Kriptogrāfisko atslēgu pārvaldībai ISMS ir jāatbild uz pieciem jautājumiem:

1. Kuriem informācijas aktīviem, datu plūsmām un pakalpojumiem ir nepieciešama kriptogrāfiskā aizsardzība?
2. Kuras atslēgas, sertifikāti, noslēpumi un kriptogrāfijas pakalpojumi tos aizsargā?
3. Kam pieder šie kriptogrāfiskie aktīvi, un kas tos administrē, apstiprina un uzrauga?
4. Kā tiek kontrolēta ģenerēšana, glabāšana, izmantošana, rotācija, deponēšana, atjaunošana, atsaukšana un iznīcināšana?
5. Kādi pierādījumi apliecina, ka kontroles pasākumi darbojās atbilstoši paredzētajam?

ISO 27001 kontroles pamats kriptogrāfisko atslēgu pārvaldībai

Clarysec kriptogrāfisko atslēgu pārvaldību vērtē kā kontroles ķēdi, nevis kā vienu atsevišķu kontroles pasākumu. Zenith Controls: The Cross-Compliance Guide Zenith Controls šī tēma galvenokārt tiek sasaistīta ar ISO/IEC 27002:2022 kontroles pasākumu 8.24, kriptogrāfijas izmantošanu, ar būtiskām atbalsta saiknēm ar 5.17, autentifikācijas informāciju, un 5.23, informācijas drošību mākoņpakalpojumu izmantošanā.

Šī saikne ir būtiska. Atslēgu pārvaldības kļūme reti ir tikai “slikta šifrēšana”. Tā bieži ir autentifikācijas problēma, mākoņpārvaldības problēma, piegādātāja problēma, žurnālfiksēšanas trūkums vai izmaiņu pārvaldības kļūme.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint šo padara operacionālu Risku pārvaldības posma 14. solī — Riska apstrādes politikas un regulatīvās savstarpējās atsauces. Tā kriptogrāfijas politikas paraugā norādīts, ka organizācijai jādefinē, kur kriptogrāfija ir nepieciešama, jāapstiprina algoritmi un protokoli, jādefinē atslēgu pārvaldība, jāaptver tādi izmantošanas gadījumi kā pilna diska šifrēšana un droša saziņa, un politika jāsasaista ar GDPR Article 32.

“Šifrēšanas atslēgas jāglabā droši (piemēram, atslēgu seifā/HSM), un piekļuve jāierobežo tikai autorizētam personālam.”
Avots: Zenith Blueprint, Risku pārvaldības posms, 14. solis, Riska apstrādes politikas un regulatīvās savstarpējās atsauces Zenith Blueprint

Kontroles darbībā posma 20. solī Zenith Blueprint iet dziļāk. Kriptogrāfija nav “šifrēšanas ieslēgšana”. Tā ir kriptogrāfijas iestrādāšana arhitektūrā, politikā un dzīves cikla pārvaldībā. Tas ietver datus glabāšanā, datus pārsūtē, identitāšu un transakciju autentifikāciju, apstiprinātus algoritmus, atslēgu seifus, HSM, plānotu rotāciju, atsaukšanu un validāciju, izmantojot ielaušanās testēšanu un koda pārskatīšanu.

Ko auditori sagaida, pieprasot atslēgu pierādījumus

Lielākā daļa audita konstatējumu sākas ar vienkāršu pieprasījumu: “Parādiet savu šifrēšanas politiku un atslēgu pārvaldības ierakstus.”

Vājas atbildes ir, piemēram:

• “Mākoņpakalpojumu sniedzējs visu šifrē pēc noklusējuma.”
• “Mēs izmantojam TLS.”
• “Noslēpumi ir seifā.”
• “Inženierijas komanda veic rotāciju.”
• “Atslēgu pārvalda lietojumprogramma.”

Šie apgalvojumi var būt tehniski patiesi, bet tie nav pilnīgi pierādījumi. ISO auditors sasaistīs atslēgu pārvaldību ar risku izvērtēšanu, Piemērojamības paziņojumu, politikas prasībām, darbības kontroli un saglabāto dokumentāciju. NIST CSF izvērtētājs jautās, vai kriptogrāfiskie aktīvi ir identificēti, aizsargāti, uzraudzīti un atjaunojami. DORA auditors meklēs valdes apstiprinātu IKT risku pārvaldību, trešo pušu atkarības, incidentu pārvaldību un noturības testēšanu. GDPR pārbaudītājs jautās, vai šifrēšana un atslēgu nodalīšana samazina risku fiziskām personām un vai pārzinis var pierādīt pārskatatbildību.

Clarysec uzņēmuma Cryptographic Controls Policy Cryptographic Controls Policy tieši risina pierādījumu trūkumu:

“Jāuztur centralizēts Atslēgu pārvaldības reģistrs, kurā reģistrē visas kriptogrāfiskās atslēgas, to dzīves cikla statusu, piešķirtos glabātājus un izmantošanas kontekstus.”
Avots: uzņēmuma politika, Cryptographic Controls Policy, Pārvaldības prasības, punkts 5.2 Cryptographic Controls Policy

Šis teikums maina audita sarunu. Tā vietā, lai meklētu neformālas zināšanas, organizācija var parādīt reģistru, kas sasaista atslēgas ar aktīviem, īpašniekiem, datu klasifikācijām, sistēmām, mākoņpakalpojumu kontiem, rotācijas datumiem, izmantošanas kontekstiem un pierādījumiem.

SME vajadzībām Clarysec Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme - SME mērogo to pašu prasību:

“IT atbalsta pakalpojumu sniedzējam jāuztur aktuāla izmantoto kriptogrāfisko rīku un sertifikātu uzskaite.”
Avots: SME politika, Cryptographic Controls Policy-sme, Pārvaldības prasības, punkts 5.1.2 Cryptographic Controls Policy-sme - SME

Regulētai finanšu iestādei var būt nepieciešamas HSM ceremonijas, dalītas zināšanas, dubultā kontrole, formāla glabātāju iecelšana un ceturkšņa piekļuves tiesību pārskatīšana. Neliels SaaS pakalpojumu sniedzējs var sākt ar uzturētu uzskaiti, apstiprinātiem algoritmiem, dokumentētām KMS īpašumtiesībām un rotācijas pierādījumiem. Abiem ir vajadzīga riskam samērīga pārvaldība.

Atslēgu dzīves cikls, kas jākontrolē jūsu ISMS

Praktiska atslēgu pārvaldības programma seko dzīves ciklam. Katrā posmā ir nepieciešams īpašnieks, apstiprināta metode, tehniskais kontroles pasākums, izmaiņu ieraksts un audita pierādījumi.

Uzņēmuma Cryptographic Controls Policy nostiprina drošu ģenerēšanu:

“Atslēgu ģenerēšana: jāveic, izmantojot drošus aparatūras vai programmatūras moduļus (piemēram, HSM, FIPS 140-2 validētas sistēmas).”
Avots: uzņēmuma politika, Cryptographic Controls Policy, Politikas ieviešanas prasības, punkts 6.3.1 Cryptographic Controls Policy

Tā arī nosaka rotāciju:

“Atslēgu rotācija: jāveic noteiktos intervālos vai nekavējoties kompromitēšanas vai lomas maiņas gadījumā.”
Avots: uzņēmuma politika, Cryptographic Controls Policy, Politikas ieviešanas prasības, punkts 6.3.4 Cryptographic Controls Policy

SME gadījumā tas pats princips izteikts vienkāršākā operacionālā valodā:

“Atslēgu rotācija jāveic saskaņā ar derīguma termiņu grafikiem vai iespējamas kompromitēšanas gadījumā.”
Avots: SME politika, Cryptographic Controls Policy-sme, Politikas ieviešanas prasības, punkts 6.3.4 Cryptographic Controls Policy-sme - SME

Šie punkti ir būtiski NIS2 un DORA kontekstā, jo novecojušas vai vāji pārvaldītas atslēgas nav tikai konfidencialitātes vājās vietas. Tās var kļūt par šķēršļiem reaģēšanai uz incidentiem, piegādātāju atkarības problēmām, avārijas atjaunošanas kļūmēm un klientu informēšanas problēmām.

Mākoņvides KMS, HSM un BYOK: dalītās atbildības slazds

Mākoņvides šifrēšana ir viens no biežākajiem maldīgas pārliecības avotiem. Mākoņpakalpojumu sniedzējs var šifrēt glabātuvi pēc noklusējuma, bet tas automātiski nenozīmē, ka jūsu organizācija pārvalda atslēgu.

Zenith Blueprint Kontroles darbībā posma 23. solī skaidro ISO/IEC 27002:2022 kontroles pasākumu 5.23, koncentrējoties uz mākoņvides pārvaldību, pārredzamību un dalīto atbildību. Tajā uzsvērts, ka pakalpojumu sniedzējs var aizsargāt infrastruktūru, bet klients joprojām ir atbildīgs par datiem, konfigurācijām, piekļuves politikām un gatavību reaģēšanai uz incidentiem.

“Mākoņpakalpojumu sniedzēji aizsargā infrastruktūru, bet jūs joprojām esat atbildīgi par saviem datiem, konfigurācijām, piekļuves politikām un gatavību reaģēšanai uz incidentiem.”
Avots: Zenith Blueprint, Kontroles darbībā posms, 23. solis, organizatoriskie kontroles pasākumi 5.19-5.37 Zenith Blueprint

Šeit mākoņvides atslēgu atbildība kļūst par valdes līmeņa risku. SaaS uzņēmums var izmantot pakalpojumu sniedzēja pārvaldītu šifrēšanu zema riska žurnāliem, klienta pārvaldītas atslēgas klientu datubāzēm, BYOK regulētiem nomniekiem un ar HSM aizsargātas saknes atslēgas parakstīšanai vai tokenizācijai. Katrai izvēlei ir atbilstības sekas.

Clarysec uzņēmuma Cloud Usage Policy Cloud Usage Policy sniedz skaidru kontroles virzienu:

“Klienta pārvaldītas atslēgas (CMK) vai Bring Your Own Key (BYOK) jāizmanto, ja mākoņpakalpojumu sniedzējs to atbalsta.”
Avots: uzņēmuma politika, Cloud Usage Policy, Politikas ieviešanas prasības, punkts 6.4.2 Cloud Usage Policy

Tas nenozīmē, ka katram mākoņpakalpojumam jāizmanto BYOK. Tas nozīmē, ka organizācijai jāpieņem apzināts lēmums, balstoties uz risku, klientu saistībām, līgumiskajām prasībām un atjaunojamību.

DORA Article 28 un Article 30 to padara īpaši nozīmīgu finanšu iestādēm. Tie prasa IKT trešo pušu risku pārvaldību, IKT līgumisko vienošanos reģistrus, sākotnējo izpēti, audita un pārbaudes tiesības, incidentu atbalstu, datu aizsardzību un piekļuvi, atjaunošanas un atgriešanas noteikumus. Ja mākoņpakalpojumu sniedzējs vai SaaS piegādātājs pārvalda šifrēšanas atslēgas kritiskai vai svarīgai funkcijai, šīm attiecībām jābūt redzamām IKT trešo pušu reģistrā un līgumiskajos kontroles pasākumos.

NIS2 arī prasa piegādes ķēdes drošību, tostarp piegādātājiem specifiskas ievainojamības, kiberdrošības prakses un drošas izstrādes procedūras. Ja kritisks piegādātājs glabā jūsu atslēgas, darbina jūsu KMS, nodrošina jūsu HSM, pārvalda jūsu sertifikātu dzīves ciklu vai mitina šifrētas rezerves kopijas, piegādātājs ir daļa no jūsu kriptogrāfiskās kontroles vides.

Algoritmu apstiprināšana un kriptogrāfiskā elastība 2026. gadā

2026. gada atslēgu pārvaldības politikai nevajadzētu tikai uzskaitīt “AES-256” un “TLS 1.2 vai jaunāku”. Tai jānosaka apstiprināšanas un pārskatīšanas process, kas atbalsta kriptogrāfisko elastību. Kriptogrāfiskā elastība nozīmē, ka organizācija var identificēt, kur tiek izmantoti algoritmi, protokoli, sertifikāti un atslēgu garumi, izvērtēt pakļautību vājām vietām vai novecošanai un migrēt bez panikas.

Clarysec SME politikā noteikts:

“Drīkst izmantot tikai IT atbalsta pakalpojumu sniedzēja apstiprinātus nozares labākās prakses algoritmus un protokolus (piemēram, AES-256, RSA 2048, TLS 1.2 vai jaunāku).”
Avots: SME politika, Cryptographic Controls Policy-sme, Politikas ieviešanas prasības, punkts 6.2.1 Cryptographic Controls Policy-sme - SME

Tā arī prasa dokumentāciju:

“Visas šifrēšanas metodes (piemēram, AES-256, TLS 1.2+) un atslēgu pārvaldības procesi ir jādokumentē.”
Avots: SME politika, Cryptographic Controls Policy-sme, Pārvaldības prasības, punkts 5.3.1 Cryptographic Controls Policy-sme - SME

Auditam gatavā versija ir apstiprināts kriptogrāfijas standarts, kas ietver:

• Atļautos algoritmus un protokolus datiem glabāšanā, datiem pārsūtē, parakstiem, paroļu jaukšanai, tokenizācijai un rezerves kopijām.
• Aizliegtos algoritmus, protokolus un bibliotēkas.
• Minimālos atslēgu garumus un sertifikātu derīguma termiņus.
• Apstiprinātās KMS, HSM, sertifikācijas iestādes un noslēpumu pārvaldības platformas.
• Drošas nejaušo skaitļu ģenerēšanas prasības.
• Izstrādātāju norādījumus kriptogrāfiskajām bibliotēkām.
• Izņēmumu procesu mantotajām sistēmām.
• Pārskatīšanas ierosinātājus ievainojamību, regulatīvo izmaiņu, piegādātāju izmaiņu un pēckvantu pārejas plānošanas gadījumā.

Pēckvantu plānošana neprasa katrai organizācijai nekavējoties aizstāt visu kriptogrāfiju. Tā prasa uzskaiti. Bez kriptogrāfiskās uzskaites nav iespējams zināt, kuras sistēmas izmanto ilgtermiņa publiskās atslēgas šifrēšanu, kuri sertifikāti aizsargā kritiskus pakalpojumus, kur atrodas parakstīšanas atslēgas vai kuriem piegādātājiem jāatbalsta migrācija. Atslēgu pārvaldības reģistrs nav birokrātija. Tas ir kriptogrāfiskās elastības pamats.

90 minūšu atslēgu pārvaldības pierādījumu sprints

Clarysec bieži izmanto īsu pierādījumu sprintu ar vadību, drošības, mākoņpakalpojumu un atbilstības komandām. Mērķis ir ātri pārvērst izkliedētās zināšanas par atslēgām audita pierādījumos.

1. solis: izvēlieties vienu kritisku pakalpojumu

Izvēlieties sistēmu, kas ir būtiska NIS2, DORA vai GDPR kontekstā. Piemēri ir klientu identitāte, maksājumu apstrāde, transakciju uzraudzība, ražošanas klientu datubāze, šifrētu rezerves kopiju platforma vai klientiem pieejama API.

2. solis: atveriet Atslēgu pārvaldības reģistru

Izmantojiet Cryptographic Controls Policy prasību par centralizētu reģistru kā struktūru. Ja jums tā vēl nav, izveidojiet vienkāršu reģistru ar šādiem laukiem:

3. solis: izsekojiet piekļuvi un dubulto kontroli

Augstas ietekmes kriptogrāfiskām operācijām piemērojiet dubulto kontroli un minimāli nepieciešamās tiesības. Uzņēmuma Cryptographic Controls Policy nosaka:

“Sensitīvām kriptogrāfiskām operācijām (piemēram, saknes atslēgu importam, HSM administrēšanai) jāpiemēro dubultās kontroles mehānismi un minimāli nepieciešamās tiesības.”
Avots: uzņēmuma politika, Cryptographic Controls Policy, Politikas ieviešanas prasības, punkts 6.6.2 Cryptographic Controls Policy

Jautājiet:

• Kas var atspējot vai dzēst atslēgu?
• Kas var mainīt atslēgas politiku?
• Kas var tieši atšifrēt datus?
• Vai break-glass lomas tiek uzraudzītas un ierobežotas laikā?
• Vai MFA tiek piemērota priviliģētām atslēgu operācijām?
• Vai priviliģētās darbības tiek žurnālfiksētas un pārskatītas?

4. solis: iegūstiet piecus pierādījumu ierakstus

Savāciet piecus ierakstus, kas pierāda, ka kontroles pasākums darbojas:

1. Atslēgas izveides vai importa žurnāls.
2. Pašreizējā KMS vai HSM piekļuves politika.
3. Pēdējais atslēgas rotācijas izmaiņu pieteikums.
4. SIEM vaicājums, kas parāda atslēgas izmantošanu vai administratīvās darbības.
5. Atjaunošanas vai rezerves kopijas atjaunošanas testa pierādījumi.

5. solis: sasaistiet ar risku un regulējumu

Pievienojiet īsu riska formulējumu: “Neatļauta šīs atslēgas izmantošana vai zudums varētu atklāt ES personas datus, traucēt klientu pakalpojumu un pasliktināt kritisko sistēmu atjaunošanu.” Pēc tam sasaistiet to ar attiecīgajiem pienākumiem.

90 minūtēs komanda parasti var noteikt, vai atslēgu pārvaldība ir reāla vai tikai pieņemta.

Incidentu ziņošana: kad atslēgas kompromitēšana iedarbina termiņu

Iespējama atslēgas kompromitēšana automātiski nav ziņojams pārkāpums, bet tā var iedarbināt regulatīvo termiņu.

Saskaņā ar NIS2 būtiskām un svarīgām vienībām bez nepamatotas kavēšanās jāziņo par nozīmīgiem incidentiem, kas ietekmē pakalpojumu sniegšanu. Pakāpeniskais modelis ietver agrīnu brīdinājumu 24 stundu laikā pēc uzzināšanas, incidenta paziņojumu 72 stundu laikā, statusa atjauninājumus pēc pieprasījuma un gala ziņojumu ne vēlāk kā vienu mēnesi pēc incidenta paziņojuma.

Saskaņā ar DORA finanšu iestādēm jāatklāj, jāpārvalda un jāpaziņo ar IKT saistīti incidenti, jāreģistrē incidenti un nozīmīgi kiberdraudi, jāklasificē incidenti pēc smaguma pakāpes un skartā pakalpojuma kritiskuma, jāsazinās ar iesaistītajām pusēm, jāziņo par būtiskiem incidentiem augstākajai vadībai un kompetentajām iestādēm, jāveic pamatcēloņa analīze un jānovērš trūkumi. Ziņošanas ārpakalpojums var būt iespējams, bet atbildība paliek finanšu iestādei.

Saskaņā ar GDPR jautājums kļūst par to, vai ir noticis personas datu aizsardzības pārkāpums, proti, nejauša vai nelikumīga personas datu iznīcināšana, nozaudēšana, pārveidošana, neatļauta izpaušana vai piekļuve tiem. Droša šifrēšana ar nekompromitētām atslēgām var būtiski mainīt pārkāpuma riska analīzi. Vāja atslēgu pārvaldība var šo argumentu vājināt.

Atslēgu kompromitēšanas rokasgrāmatām jādefinē:

• Kā tiek atklāta iespējama atslēgas eksponēšana.
• Kas paziņo par kriptogrāfisku incidentu.
• Kā tiek identificēti skartie dati, pakalpojumi, klienti un jurisdikcijas.
• Kā atslēgas tiek atsauktas vai rotētas.
• Kā tiek atjaunotas atkarīgās sistēmas.
• Kā tiek saglabāta pierādījumu integritāte.
• Kā tiek pieņemti juridiskie, regulatīvie un klientu informēšanas lēmumi.

Šajā procesā Atslēgu pārvaldības reģistrs kļūst būtisks. Bez tā reaģētāji tērē laiku, noskaidrojot, ko atslēga aizsargāja. Ar to viņi var ātri noteikt ietekmes apjomu.

Audita skatījums: viens kontroles kopums, daudzi pierādījumu lietotāji

Dažādi auditori kriptogrāfisko atslēgu pārvaldībai pieiet no dažādiem skatpunktiem, bet viņi nonāk pie tiem pašiem pierādījumiem.

Spēcīga audita pakete kriptogrāfisko atslēgu pārvaldībai parasti ietver:

• Apstiprinātu Cryptographic Controls Policy.
• Apstiprinātu Cloud Usage Policy, ja mākoņvides šifrēšana ir būtiska.
• Kriptogrāfijas standartu un algoritmu sarakstu.
• Atslēgu pārvaldības reģistru.
• Sertifikātu un noslēpumu uzskaiti.
• KMS, HSM un seifu arhitektūru.
• IAM un priviliģētās piekļuves pārskatīšanas pierādījumus.
• Rotācijas un atsaukšanas ierakstus.
• Rezerves kopiju, deponēšanas un atjaunošanas testu pierādījumus.
• Žurnālfiksēšanas un uzraudzības noteikumus atslēgu darbībām.
• Piegādātāju un mākoņvides dalītās atbildības kartējumu.
• Incidentu rokasgrāmatu iespējamai atslēgas kompromitēšanai.
• Izņēmumus un riska pieņemšanas.
• Vadības pārskatīšanas un audita neatbilstību novēršanas ierakstus.

Šī pakete kontroles apgalvojumu pārvērš pierādījumā.

Biežākie konstatējumi atslēgu pārvaldības auditos

Biežākie konstatējumi ir novēršami:

1. Nav vienotas atslēgu, sertifikātu un kriptogrāfisko rīku uzskaites.
2. Mākoņpakalpojumu sniedzēja noklusējuma šifrēšana tiek uzskatīta par pilnīgu atslēgu pārvaldību.
3. Ražošanas atslēgām nav piešķirts īpašnieks vai glabātājs.
4. Rotācija pastāv sertifikātiem, bet ne lietojumprogrammu atslēgām vai datubāzu CMK.
5. Noslēpumi un atslēgas ir sajaukti vienā seifā bez klasifikācijas.
6. Izstrādātāji var izveidot atslēgas ārpus apstiprinātiem modeļiem.
7. Nav pierādījumu, ka KMS administratori tiek pārskatīti.
8. Atjaunošanas procedūras pastāv, bet nekad nav testētas.
9. Atslēgas kompromitēšana nav iekļauta incidentu reaģēšanas rokasgrāmatās.
10. Mantotie algoritmi paliek iekšējos pakalpojumos, jo neviens nav atbildīgs par trūkumu novēršanu.
11. BYOK saistības ir iekļautas klientu līgumos, bet nav atspoguļotas operācijās.
12. Piegādātāja pārvaldīta šifrēšana nav iekļauta piegādātāju riska pārskatīšanā.

Katrs konstatējums atgriežas pie pārvaldības. Tāpēc kriptogrāfiju nedrīkst uzskatīt par tīri inženierijas projektu. Tai jābūt sasaistītai ar ISMS darbības jomu, riska apstrādi, politiku, piegādātājiem, mākoni, piekļuvi, žurnālfiksēšanu, incidentiem un nepārtrauktību.

Padariet atslēgu pārvaldību gatavu auditam pirms nākamā incidenta

Ja jūsu organizācija gatavojas NIS2, DORA, GDPR Article 32 pierādījumiem, ISO/IEC 27001:2022 sertifikācijai vai pēckvantu kriptogrāfiskajai elastībai, sāciet ar vienu jautājumu: vai jūs šodien varat sagatavot pilnīgu Atslēgu pārvaldības reģistru?

Ja nē, Clarysec var palīdzēt izveidot kontroles sistēmu ap to.

Izmantojiet Zenith Blueprint Zenith Blueprint, lai strukturētu darbu Risku pārvaldības posma 14. solī un Kontroles darbībā posma 20. solī. Izmantojiet Zenith Controls Zenith Controls, lai kartētu ISO/IEC 27002:2022 kontroles pasākumus 8.24, 5.17 un 5.23 pāri NIS2, DORA, GDPR, NIST un audita prasībām. Izmantojiet Clarysec Cryptographic Controls Policy Cryptographic Controls Policy, Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme - SME un Cloud Usage Policy Cloud Usage Policy, lai prasības pārvērstu darbības noteikumos.

Praktiskais nākamais solis ir vienkāršs: izvēlieties vienu kritisku pakalpojumu, uzskaitiet tā atslēgas, pierādiet īpašumtiesības, pārbaudiet piekļuvi, iegūstiet rotācijas pierādījumus un testējiet atjaunošanu. Ja tas prasa vairāk nekā vienu dienu, jūsu kriptogrāfiskajai pārvaldībai ir jāpievērš uzmanība, pirms regulators, auditors vai incidentu reaģēšanas komanda uzdod to pašu jautājumu spiediena apstākļos.