Zarządzanie kluczami kryptograficznymi dla ISO 27001, NIS2 i DORA

O 08:17 w poniedziałek rano CISO europejskiej spółki SaaS otrzymuje wiadomość od osoby kierującej zespołem inżynierskim: „W weekend przeprowadziliśmy rotację klucza szyfrowania bazy danych, ale jedna integracja przestała odszyfrowywać rekordy. Wycofaliśmy zmianę, używając starego klucza z magazynu kluczy”.

Dziesięć minut później DPO pyta, czy dotknięte rekordy obejmują dane osobowe z UE. Dział finansów pyta, czy może to stać się incydentem operacyjnym podlegającym zgłoszeniu dla regulowanego klienta. Dział zakupów pyta, czy właścicielem klucza zarządzanego przez klienta jest dostawca usług chmurowych, czy spółka. CEO zadaje jedyne pytanie, które będzie miało znaczenie na posiedzeniu zarządu: „Czy możemy udowodnić, że zarządzaliśmy tym prawidłowo?”.

To właśnie moment, w którym stwierdzenie „stosujemy szyfrowanie” przestaje być uspokajającą deklaracją, a staje się problemem dowodowym.

W 2026 r. zarządzanie kluczami kryptograficznymi znajduje się na styku zabezpieczeń ISO/IEC 27001:2022, cyberhigieny NIS2, zarządzania ryzykiem ICT w DORA, dowodów bezpieczeństwa przetwarzania wymaganych przez GDPR Article 32, współdzielonej odpowiedzialności w chmurze obliczeniowej oraz planowania kryptoagilności postkwantowej. Rzeczywisty problem nie polega na tym, czy szyfrowanie istnieje. Polega na tym, czy organizacja może wykazać w zapisach, że klucze są bezpiecznie generowane, przypisane właścicielom, przechowywane w zatwierdzonych środowiskach KMS lub HSM, rotowane zgodnie z harmonogramem, bezpiecznie odzyskiwane, unieważniane po naruszeniu oraz mapowane do ryzyka biznesowego.

Clarysec wielokrotnie obserwuje ten sam wzorzec w pracach nad gotowością. Szyfrowanie jest wdrażane system po systemie, ale nadzór nad kluczami pozostaje rozproszony. Certyfikaty są utrzymywane w arkuszach kalkulacyjnych. Uprawnienia do KMS w chmurze są dziedziczone po starych projektach. Programiści wiedzą, które sekrety są istotne, ale SZBI tego nie odzwierciedla. Audytorzy otrzymują zrzuty ekranu zamiast dowodów z cyklu życia. Zespoły NIS2 i DORA rozmawiają o odporności, zespoły ds. prywatności o szyfrowaniu i pseudonimizacji w GDPR, a nikt nie odpowiada całościowo za płaszczyznę kontroli kryptograficznych.

Dojrzałą odpowiedzią nie jest samo dodanie kryptografii. Jest nią nadzorowane zarządzanie kluczami kryptograficznymi powiązane z postępowaniem z ryzykiem, architekturą chmury, nadzorem nad dostawcami, kontrolą dostępu, rejestrowaniem, reagowaniem na incydenty i dowodami regulacyjnymi.

Dlaczego zarządzanie kluczami stało się kwestią nadzorczą

NIS2 czyni polityki kryptografii i szyfrowania częścią minimalnych środków zarządzania ryzykiem cyberbezpieczeństwa dla podmiotów kluczowych i ważnych. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego rozwoju oprogramowania, cyberhigieny, kontroli dostępu, zarządzania aktywami oraz polityk kryptografii i szyfrowania. Wymaga również, aby organy zarządzające zatwierdzały i nadzorowały środki zarządzania ryzykiem cyberbezpieczeństwa.

W przypadku dostawców SaaS, usług chmurowych, usług zarządzanych i usług cyberbezpieczeństwa zakres stosowania może być szerszy, niż zakłada wiele zespołów. NIS2 obejmuje sektory takie jak infrastruktura cyfrowa, dostawcy usług przetwarzania w chmurze, dostawcy centrów danych, dostawcy DNS, dostawcy usług zaufania, dostawcy usług zarządzanych, dostawcy zarządzanych usług bezpieczeństwa, internetowe platformy handlowe, wyszukiwarki i platformy społecznościowe, jeżeli spełnione są progi wielkości lub krytyczności.

DORA podnosi poprzeczkę dla podmiotów finansowych. Od 17 stycznia 2025 r. DORA wymaga udokumentowanych ram zarządzania ryzykiem ICT, odpowiedzialności zarządu, planów ciągłości działania ICT oraz planów reagowania i odzyskiwania, testowania cyfrowej odporności operacyjnej, zarządzania ryzykiem ICT związanym z zewnętrznymi dostawcami oraz zgłaszania incydentów. W przypadku podmiotów finansowych wskazanych w krajowych przepisach NIS2 DORA działa jako sektorowy akt prawa Unii równoważny dla obowiązków NIS2. Fintech nie powinien prowadzić odrębnego nadzoru kryptograficznego dla NIS2, DORA i ISO. Potrzebuje jednego możliwego do obrony modelu kontroli.

GDPR dodaje wymiar dowodowy w obszarze prywatności. GDPR Article 32 jest miejscem, w którym szyfrowanie zwykle ocenia się jako środek ochrony bezpieczeństwa przetwarzania, ale stwierdzenie „dane są zaszyfrowane” nie jest pełną odpowiedzią. Organy regulacyjne i audytorzy pytają, kto kontroluje klucze, jak ograniczony jest dostęp, jak wykrywane jest naruszenie, jak działa odzyskiwanie oraz czy projekt odpowiada ryzyku dla osób fizycznych.

ISO/IEC 27001:2022 zapewnia organizacjom system zarządzania, który pozwala połączyć te obowiązki. Klauzule 4.1 do 4.4 wymagają określenia kontekstu, wymagań stron zainteresowanych, zakresu SZBI i powiązanych procesów. Klauzule 5.1 do 5.3 wymagają przywództwa, polityki, zasobów i przypisanych odpowiedzialności. Klauzule 6.1.1 do 6.1.3 wymagają oceny ryzyka, postępowania z ryzykiem, doboru zabezpieczeń, Deklaracji stosowania oraz zatwierdzenia przez właściciela ryzyka. Klauzule 8.1 do 8.3 wymagają kontrolowanej eksploatacji, ponownej oceny ryzyka w przypadku zmian, wdrożenia planów postępowania z ryzykiem oraz przechowywania udokumentowanych wyników.

W przypadku zarządzania kluczami kryptograficznymi SZBI musi odpowiedzieć na pięć pytań:

1. Które aktywa informacyjne, przepływy danych i usługi wymagają ochrony kryptograficznej?
2. Które klucze, certyfikaty, sekrety i usługi kryptograficzne je chronią?
3. Kto jest właścicielem tych aktywów kryptograficznych, kto nimi administruje, kto je zatwierdza i monitoruje?
4. Jak kontrolowane są generowanie, przechowywanie, użycie, rotacja, depozyt, odzyskiwanie, unieważnianie i niszczenie?
5. Jakie dowody potwierdzają, że zabezpieczenia działały zgodnie z projektem?

Kręgosłup zabezpieczeń ISO 27001 dla zarządzania kluczami kryptograficznymi

Clarysec traktuje zarządzanie kluczami kryptograficznymi jako łańcuch zabezpieczeń, a nie pojedynczą kontrolę. W Zenith Controls: przewodnik po zgodności przekrojowej Zenith Controls temat mapuje się przede wszystkim do zabezpieczenia 8.24 w ISO/IEC 27002:2022, użycie kryptografii, z istotnymi relacjami wspierającymi do 5.17, informacje uwierzytelniające, oraz 5.23, bezpieczeństwo informacji przy korzystaniu z usług chmurowych.

Ta relacja ma znaczenie. Nieskuteczność zarządzania kluczami rzadko jest wyłącznie „złym szyfrowaniem”. Często jest to problem uwierzytelniania, problem nadzoru nad chmurą, problem dostawcy, luka w rejestrowaniu albo nieskuteczność zarządzania zmianami.

Zenith Blueprint: 30-etapowa mapa drogowa audytora Zenith Blueprint przekłada to na działanie w fazie zarządzania ryzykiem, krok 14, polityki postępowania z ryzykiem i odniesienia regulacyjne. Przykładowa polityka kryptografii wskazuje, że organizacja musi określić, gdzie potrzebna jest kryptografia, zatwierdzić algorytmy i protokoły, zdefiniować zarządzanie kluczami, objąć przypadki użycia takie jak szyfrowanie pełnodyskowe i bezpieczna komunikacja oraz powiązać politykę z GDPR Article 32.

„Klucze szyfrowania muszą być przechowywane bezpiecznie, np. w sejfie kluczy/HSM, a dostęp do nich musi być ograniczony do uprawnionego personelu”.
Źródło: Zenith Blueprint, faza zarządzania ryzykiem, krok 14, polityki postępowania z ryzykiem i odniesienia regulacyjne Zenith Blueprint

W fazie zabezpieczeń w praktyce, krok 20, Zenith Blueprint idzie głębiej. Kryptografia nie polega na „włączeniu szyfrowania”. Polega na osadzeniu kryptografii w projekcie, polityce i zarządzaniu cyklem życia. Obejmuje to dane w spoczynku, dane w tranzycie, uwierzytelnianie tożsamości i transakcji, zatwierdzone algorytmy, sejfy kluczy, HSM, zaplanowaną rotację, unieważnianie oraz walidację przez testy penetracyjne i przegląd kodu.

Czego oczekują audytorzy, gdy proszą o dowody dotyczące kluczy

Większość ustaleń z audytu zaczyna się od prostego żądania: „Proszę pokazać politykę szyfrowania i zapisy zarządzania kluczami”.

Słabe odpowiedzi obejmują:

• „Dostawca usług chmurowych szyfruje wszystko domyślnie”.
• „Używamy TLS”.
• „Sekrety są w sejfie”.
• „Zespół inżynierski obsługuje rotację”.
• „Kluczem zarządza aplikacja”.

Te stwierdzenia mogą być technicznie prawdziwe, ale nie stanowią pełnych dowodów. Audytor ISO powiąże zarządzanie kluczami z oceną ryzyka, Deklaracją stosowania, wymaganiami polityki, kontrolą operacyjną i przechowywaną dokumentacją. Asesor NIST CSF zapyta, czy aktywa kryptograficzne są zidentyfikowane, chronione, monitorowane i możliwe do odzyskania. Audytor DORA będzie szukał zatwierdzonego przez zarząd nadzoru nad ryzykiem ICT, zależności od zewnętrznych dostawców, zarządzania incydentami i testowania odporności. Przeglądający GDPR zapyta, czy szyfrowanie i separacja kluczy ograniczają ryzyko dla osób fizycznych oraz czy administrator danych może wykazać rozliczalność.

Enterprise Polityka zabezpieczeń kryptograficznych Clarysec Polityka zabezpieczeń kryptograficznych bezpośrednio adresuje lukę dowodową:

„Należy utrzymywać scentralizowany Rejestr zarządzania kluczami w celu ewidencjonowania wszystkich kluczy kryptograficznych, ich statusu cyklu życia, przypisanych opiekunów oraz kontekstów użycia”.
Źródło: Polityka Enterprise, Polityka zabezpieczeń kryptograficznych, wymagania nadzorcze, klauzula 5.2 Polityka zabezpieczeń kryptograficznych

To zdanie zmienia rozmowę audytową. Zamiast odtwarzać wiedzę plemienną, organizacja może pokazać rejestr łączący klucze z aktywami, właścicielami, klasyfikacjami danych, systemami, kontami chmurowymi, datami rotacji, kontekstami użycia i dowodami.

Dla MŚP Polityka zabezpieczeń kryptograficznych-sme Clarysec Polityka zabezpieczeń kryptograficznych-sme - MŚP skaluje to samo oczekiwanie:

„Dostawca wsparcia IT musi utrzymywać aktualny inwentarz używanych narzędzi kryptograficznych i certyfikatów”.
Źródło: Polityka MŚP, Polityka zabezpieczeń kryptograficznych-sme, wymagania nadzorcze, klauzula 5.1.2 Polityka zabezpieczeń kryptograficznych-sme - MŚP

Regulowana instytucja finansowa może potrzebować ceremonii HSM, podziału wiedzy, podwójnej kontroli, formalnych powołań opiekunów i kwartalnych przeglądów dostępu. Mały dostawca SaaS może zacząć od utrzymywanego inwentarza, zatwierdzonych algorytmów, udokumentowanej własności KMS i dowodów rotacji. Oba podmioty potrzebują nadzoru proporcjonalnego do ryzyka.

Cykl życia kluczy, który powinien kontrolować Twój SZBI

Praktyczny program zarządzania kluczami podąża za cyklem życia. Każdy etap wymaga właściciela, zatwierdzonej metody, technicznego zabezpieczenia, zapisu zmiany i dowodu audytowego.

Enterprise Polityka zabezpieczeń kryptograficznych wzmacnia bezpieczne generowanie:

„Generowanie kluczy: wykonywane z użyciem bezpiecznych modułów sprzętowych lub programowych, np. HSM, systemów zwalidowanych zgodnie z FIPS 140-2”.
Źródło: Polityka Enterprise, Polityka zabezpieczeń kryptograficznych, wymagania dotyczące wdrożenia polityki, klauzula 6.3.1 Polityka zabezpieczeń kryptograficznych

Określa również rotację:

„Rotacja kluczy: wymagana w zdefiniowanych odstępach czasu lub natychmiast po naruszeniu albo zmianie roli”.
Źródło: Polityka Enterprise, Polityka zabezpieczeń kryptograficznych, wymagania dotyczące wdrożenia polityki, klauzula 6.3.4 Polityka zabezpieczeń kryptograficznych

Dla MŚP ta sama zasada pojawia się w prostszym języku operacyjnym:

„Rotacja kluczy musi następować zgodnie z harmonogramami wygaśnięcia lub w przypadku podejrzenia naruszenia”.
Źródło: Polityka MŚP, Polityka zabezpieczeń kryptograficznych-sme, wymagania dotyczące wdrożenia polityki, klauzula 6.3.4 Polityka zabezpieczeń kryptograficznych-sme - MŚP

Te klauzule mają znaczenie dla NIS2 i DORA, ponieważ nieaktualne lub słabo nadzorowane klucze nie są wyłącznie słabościami poufności. Mogą stać się blokadami w reagowaniu na incydenty, problemami zależności od dostawców, nieskutecznością odtwarzania po awarii i problemami powiadamiania klientów.

KMS w chmurze, HSM i BYOK: pułapka współdzielonej odpowiedzialności

Szyfrowanie w chmurze obliczeniowej jest jednym z najczęstszych źródeł fałszywego poczucia bezpieczeństwa. Dostawca usług chmurowych może domyślnie szyfrować pamięć masową, ale nie oznacza to automatycznie, że organizacja objęła klucz nadzorem.

Zenith Blueprint, faza zabezpieczeń w praktyce, krok 23, wyjaśnia zabezpieczenie 5.23 ISO/IEC 27002:2022, koncentrując się na nadzorze nad chmurą, widoczności i współdzielonej odpowiedzialności. Podkreśla, że dostawca może zabezpieczać infrastrukturę, ale klient pozostaje odpowiedzialny za dane, konfiguracje, polityki dostępu i gotowość do reagowania na incydenty.

„Dostawcy chmury zabezpieczają infrastrukturę, ale nadal odpowiadasz za swoje dane, swoje konfiguracje, swoje polityki dostępu oraz swoją gotowość do reagowania na incydenty”.
Źródło: Zenith Blueprint, faza zabezpieczeń w praktyce, krok 23, zabezpieczenia organizacyjne 5.19-5.37 Zenith Blueprint

W tym miejscu odpowiedzialność za klucze chmurowe staje się ryzykiem na poziomie zarządu. Spółka SaaS może używać szyfrowania z kluczami zarządzanymi przez dostawcę dla logów niskiego ryzyka, kluczy zarządzanych przez klienta dla baz danych klientów, BYOK dla regulowanych tenantów oraz kluczy głównych wspartych HSM dla podpisywania lub tokenizacji. Każdy wybór ma konsekwencje dla zgodności.

Enterprise Polityka korzystania z chmury obliczeniowej Clarysec Polityka korzystania z chmury obliczeniowej określa jasny kierunek kontroli:

„Klucze zarządzane przez klienta (CMK) lub Bring Your Own Key (BYOK) należy stosować tam, gdzie wspiera je dostawca usług chmurowych”.
Źródło: Polityka Enterprise, Polityka korzystania z chmury obliczeniowej, wymagania dotyczące wdrożenia polityki, klauzula 6.4.2 Polityka korzystania z chmury obliczeniowej

Nie oznacza to, że każda usługa chmurowa musi używać BYOK. Oznacza to, że organizacja powinna podejmować świadomą decyzję opartą na ryzyku, zobowiązaniach wobec klientów, wymaganiach umownych i możliwości odzyskania danych.

DORA Article 28 i Article 30 czynią to szczególnie istotnym dla podmiotów finansowych. Wymagają zarządzania ryzykiem ICT związanym z zewnętrznymi dostawcami, rejestrów ustaleń umownych dotyczących ICT, due diligence, praw audytu i inspekcji, wsparcia incydentowego, ochrony danych i dostępu, a także postanowień dotyczących odzyskiwania i zwrotu. Jeżeli dostawca usług chmurowych lub dostawca SaaS zarządza kluczami szyfrowania dla funkcji krytycznej lub istotnej, relacja ta musi być widoczna w rejestrze zewnętrznych dostawców ICT i w kontrolach umownych.

NIS2 wymaga również bezpieczeństwa łańcucha dostaw, w tym uwzględnienia podatności specyficznych dla dostawców, praktyk cyberbezpieczeństwa i procedur bezpiecznego rozwoju oprogramowania. Jeżeli dostawca krytyczny przechowuje Twoje klucze, obsługuje Twój KMS, dostarcza Twój HSM, zarządza cyklem życia certyfikatów albo hostuje szyfrowane kopie zapasowe, jest częścią Twojego środowiska kontroli kryptograficznej.

Zatwierdzanie algorytmów i kryptoagilność w 2026 r.

Polityka zarządzania kluczami w 2026 r. nie powinna jedynie wymieniać „AES-256” i „TLS 1.2 lub nowszy”. Powinna ustanawiać proces zatwierdzania i przeglądu wspierający kryptoagilność. Kryptoagilność oznacza, że organizacja potrafi ustalić, gdzie używane są algorytmy, protokoły, certyfikaty i długości kluczy, ocenić ekspozycję na słabość lub wycofanie oraz przeprowadzić migrację bez paniki.

Polityka MŚP Clarysec stanowi:

„Można stosować wyłącznie algorytmy i protokoły zgodne z najlepszymi praktykami branżowymi, zatwierdzone przez dostawcę wsparcia IT, np. AES-256, RSA 2048, TLS 1.2 lub nowszy”.
Źródło: Polityka MŚP, Polityka zabezpieczeń kryptograficznych-sme, wymagania dotyczące wdrożenia polityki, klauzula 6.2.1 Polityka zabezpieczeń kryptograficznych-sme - MŚP

Wymaga również dokumentacji:

„Wszystkie metody szyfrowania, np. AES-256, TLS 1.2+, oraz procesy zarządzania kluczami muszą być udokumentowane”.
Źródło: Polityka MŚP, Polityka zabezpieczeń kryptograficznych-sme, wymagania nadzorcze, klauzula 5.3.1 Polityka zabezpieczeń kryptograficznych-sme - MŚP

Wersją gotową do audytu jest zatwierdzony standard kryptograficzny obejmujący:

• Dozwolone algorytmy i protokoły dla danych w spoczynku, danych w tranzycie, podpisów, hashowania haseł, tokenizacji i kopii zapasowych.
• Niedozwolone algorytmy, protokoły i biblioteki.
• Minimalne długości kluczy i okresy ważności certyfikatów.
• Zatwierdzone KMS, HSM, urzędy certyfikacji i platformy zarządzania sekretami.
• Wymagania dotyczące bezpiecznego generowania liczb losowych.
• Wytyczne dla programistów dotyczące bibliotek kryptograficznych.
• Proces obsługi wyjątków dla systemów legacy.
• Wyzwalacze przeglądu dla podatności, zmian regulacyjnych, zmian dostawców i planowania przejścia postkwantowego.

Planowanie postkwantowe nie wymaga, aby każda organizacja natychmiast zastąpiła całą kryptografię. Wymaga natomiast inwentarza. Bez inwentarza kryptograficznego nie wiadomo, które systemy używają długoterminowego szyfrowania kluczem publicznym, które certyfikaty chronią usługi krytyczne, gdzie znajdują się klucze podpisujące ani którzy dostawcy muszą wspierać migrację. Rejestr zarządzania kluczami nie jest biurokracją. Jest fundamentem kryptoagilności.

90-minutowy sprint dowodowy dla zarządzania kluczami

Clarysec często stosuje krótki sprint dowodowy z udziałem kierownictwa, zespołów bezpieczeństwa, chmury i zgodności. Celem jest szybkie przekształcenie rozproszonej wiedzy o kluczach w dowody audytowe.

Krok 1: Wybierz jedną usługę krytyczną

Wybierz system istotny dla NIS2, DORA lub GDPR. Przykłady obejmują tożsamość klienta, przetwarzanie płatności, monitorowanie transakcji, produkcyjną bazę danych klientów, platformę szyfrowanych kopii zapasowych albo API dostępne dla klientów.

Krok 2: Otwórz Rejestr zarządzania kluczami

Wykorzystaj wymaganie Polityki zabezpieczeń kryptograficznych dotyczące scentralizowanego rejestru jako strukturę. Jeżeli jeszcze go nie masz, utwórz prosty rejestr z następującymi polami:

Krok 3: Prześledź dostęp i podwójną kontrolę

Dla operacji kryptograficznych o wysokim wpływie stosuj podwójną kontrolę i zasadę najmniejszych uprawnień. Enterprise Polityka zabezpieczeń kryptograficznych stanowi:

„Zasady podwójnej kontroli i najmniejszych uprawnień muszą być stosowane do wrażliwych operacji kryptograficznych, np. importu kluczy głównych, administracji HSM”.
Źródło: Polityka Enterprise, Polityka zabezpieczeń kryptograficznych, wymagania dotyczące wdrożenia polityki, klauzula 6.6.2 Polityka zabezpieczeń kryptograficznych

Zapytaj:

• Kto może wyłączyć lub usunąć klucz?
• Kto może zmienić politykę klucza?
• Kto może bezpośrednio odszyfrować dane?
• Czy role break-glass są monitorowane i ograniczone czasowo?
• Czy MFA jest wymuszane dla uprzywilejowanych operacji na kluczach?
• Czy działania uprzywilejowane są rejestrowane i przeglądane?

Krok 4: Pobierz pięć zapisów dowodowych

Zbierz pięć zapisów, które potwierdzają działanie zabezpieczenia:

1. Log utworzenia lub importu klucza.
2. Aktualna polityka dostępu KMS lub HSM.
3. Ostatnie zgłoszenie zmiany dotyczące rotacji klucza.
4. Zapytanie SIEM pokazujące użycie klucza lub działania administracyjne.
5. Dowód testu odzyskiwania lub odtworzenia.

Krok 5: Zmapuj do ryzyka i regulacji

Dodaj krótkie stwierdzenie ryzyka: „Nieuprawnione użycie lub utrata tego klucza mogłaby ujawnić dane osobowe z UE, zakłócić obsługę klientów i utrudnić odzyskiwanie systemów krytycznych”. Następnie zmapuj je do odpowiednich obowiązków.

W ciągu 90 minut zespół zwykle jest w stanie ustalić, czy nadzór nad kluczami jest rzeczywisty, czy jedynie zakładany.

Zgłaszanie incydentów: kiedy naruszenie klucza uruchamia zegar

Podejrzenie naruszenia klucza nie jest automatycznie naruszeniem podlegającym zgłoszeniu, ale może uruchomić bieg terminów regulacyjnych.

Zgodnie z NIS2 podmioty kluczowe i ważne muszą bez zbędnej zwłoki zgłaszać istotne incydenty wpływające na świadczenie usług. Model etapowy obejmuje wczesne ostrzeżenie w ciągu 24 godzin od uzyskania wiedzy, zgłoszenie incydentu w ciągu 72 godzin, aktualizacje statusu na żądanie oraz raport końcowy nie później niż miesiąc po zgłoszeniu incydentu.

Zgodnie z DORA podmioty finansowe muszą wykrywać, obsługiwać i zgłaszać incydenty związane z ICT, ewidencjonować incydenty i istotne cyberzagrożenia, klasyfikować incydenty według wagi i krytyczności dotkniętej usługi, komunikować się z interesariuszami, zgłaszać poważne incydenty kierownictwu wyższego szczebla i właściwym organom, przeprowadzać analizę przyczyny źródłowej oraz realizować działania naprawcze. Outsourcing zgłaszania może być możliwy, ale odpowiedzialność pozostaje po stronie podmiotu finansowego.

W ramach GDPR pytanie brzmi, czy doszło do naruszenia ochrony danych osobowych, czyli przypadkowego lub niezgodnego z prawem zniszczenia, utraty, zmiany, nieuprawnionego ujawnienia danych osobowych albo nieuprawnionego dostępu do nich. Silne szyfrowanie z nienaruszonymi kluczami może istotnie zmienić analizę ryzyka naruszenia. Słabe zarządzanie kluczami może ten argument podważyć.

Playbooki naruszenia klucza powinny określać:

• Jak wykrywa się podejrzenie ujawnienia klucza.
• Kto deklaruje incydent kryptograficzny.
• Jak identyfikuje się dotknięte dane, usługi, klientów i jurysdykcje.
• Jak klucze są unieważniane lub rotowane.
• Jak odtwarzane są systemy zależne.
• Jak zachowywana jest integralność materiału dowodowego.
• Jak podejmowane są decyzje prawne, regulacyjne i dotyczące powiadomień klientów.

Rejestr zarządzania kluczami staje się w tym procesie niezbędny. Bez niego zespoły reagowania tracą czas na ustalanie, co chronił dany klucz. Z nim mogą szybko określić zakres wpływu.

Perspektywa audytu: jeden zestaw zabezpieczeń, wielu odbiorców dowodów

Różni audytorzy podchodzą do zarządzania kluczami kryptograficznymi z różnych perspektyw, ale ostatecznie oczekują tych samych dowodów.

Silny pakiet audytowy dla zarządzania kluczami kryptograficznymi zwykle obejmuje:

• Zatwierdzoną Politykę zabezpieczeń kryptograficznych.
• Zatwierdzoną Politykę korzystania z chmury obliczeniowej, jeżeli szyfrowanie w chmurze jest istotne.
• Standard kryptograficzny i listę algorytmów.
• Rejestr zarządzania kluczami.
• Inwentarz certyfikatów i sekretów.
• Architekturę KMS, HSM i sejfu.
• Dowody z przeglądów IAM i dostępu uprzywilejowanego.
• Zapisy rotacji i unieważnienia.
• Dowody testów kopii zapasowych, depozytu i odzyskiwania.
• Reguły rejestrowania i monitorowania aktywności kluczy.
• Mapowanie współdzielonej odpowiedzialności dostawców i chmury.
• Playbook incydentowy dla podejrzenia naruszenia klucza.
• Wyjątki i akceptacje ryzyka.
• Zapisy przeglądu zarządzania i poaudytowych działań naprawczych.

Taki pakiet zamienia deklarację kontroli w dowód.

Typowe ustalenia w audytach zarządzania kluczami

Najczęstszych ustaleń można uniknąć:

1. Brak jednego inwentarza kluczy, certyfikatów i narzędzi kryptograficznych.
2. Domyślne szyfrowanie dostawcy usług chmurowych traktowane jako pełny nadzór nad kluczami.
3. Brak właściciela lub opiekuna przypisanego do kluczy produkcyjnych.
4. Rotacja istnieje dla certyfikatów, ale nie dla kluczy aplikacyjnych ani CMK baz danych.
5. Sekrety i klucze są mieszane w tym samym sejfie bez klasyfikacji.
6. Programiści mogą tworzyć klucze poza zatwierdzonymi wzorcami.
7. Brak dowodów, że administratorzy KMS podlegają przeglądom.
8. Procedury odzyskiwania istnieją, ale nigdy nie zostały przetestowane.
9. Naruszenie klucza nie jest ujęte w playbookach reagowania na incydenty.
10. Algorytmy legacy pozostają w usługach wewnętrznych, ponieważ nikt nie odpowiada za działania naprawcze.
11. Zobowiązania BYOK są składane w umowach z klientami, ale nie są odzwierciedlone w operacjach.
12. Szyfrowanie zarządzane przez dostawcę nie jest uwzględniane w przeglądach ryzyka dostawcy.

Każde ustalenie mapuje się z powrotem do nadzoru. Dlatego kryptografii nie można traktować jako wyłącznie projektu inżynierskiego. Musi łączyć się z zakresem SZBI, postępowaniem z ryzykiem, polityką, dostawcami, chmurą, dostępem, rejestrowaniem, incydentami i ciągłością działania.

Przygotuj nadzór nad kluczami do audytu przed kolejnym incydentem

Jeżeli Twoja organizacja przygotowuje się do NIS2, DORA, dowodów na potrzeby GDPR Article 32, certyfikacji ISO/IEC 27001:2022 albo postkwantowej kryptoagilności, zacznij od jednego pytania: czy możesz dziś przedstawić kompletny Rejestr zarządzania kluczami?

Jeżeli nie, Clarysec może pomóc zbudować wokół niego system kontroli.

Użyj Zenith Blueprint Zenith Blueprint, aby ustrukturyzować prace przez fazę zarządzania ryzykiem, krok 14, oraz fazę zabezpieczeń w praktyce, krok 20. Użyj Zenith Controls Zenith Controls, aby zmapować zabezpieczenia ISO/IEC 27002:2022 8.24, 5.17 i 5.23 do NIS2, DORA, GDPR, NIST i oczekiwań audytowych. Użyj Polityki zabezpieczeń kryptograficznych Clarysec Polityka zabezpieczeń kryptograficznych, Polityki zabezpieczeń kryptograficznych-sme Polityka zabezpieczeń kryptograficznych-sme - MŚP oraz Polityki korzystania z chmury obliczeniowej Polityka korzystania z chmury obliczeniowej, aby przekształcić wymagania w reguły operacyjne.

Praktyczny następny krok jest prosty: wybierz jedną usługę krytyczną, zinwentaryzuj jej klucze, wykaż własność, zweryfikuj dostęp, pobierz dowody rotacji i przetestuj odzyskiwanie. Jeżeli zajmuje to więcej niż jeden dzień, nadzór kryptograficzny wymaga uwagi, zanim organ regulacyjny, audytor albo zespół reagowania na incydenty zada to samo pytanie pod presją.