Migracja do kryptografii postkwantowej z wykorzystaniem ISO 27001

Szum projektora jest jedynym dźwiękiem w sali posiedzeń zarządu. Sarah, pełniąca funkcję CISO, właśnie zakończyła kwartalną aktualizację ryzyk, gdy prezes zarządu podnosi wydruk artykułu z serwisu finansowego. Nagłówek jest bezpośredni: „Kwantowe odliczanie: czy Twoje dane są już przestarzałe?”
„Sarah” — mówi, bardziej z autentyczną troską niż oskarżycielsko — „wydaliśmy miliony na szyfrowanie. Mamy zgodność. Jesteśmy bezpieczni. Ten artykuł twierdzi, że wystarczająco silny komputer kwantowy mógłby to wszystko złamać. Czy jesteśmy narażeni? Co z danymi, które szyfrujemy i przechowujemy już teraz? Czy to tykająca bomba?”
To rozmowa, która przenosi się dziś z konferencji bezpieczeństwa do komitetów wykonawczych. Problemem nie jest już to, czy komputery kwantowe są interesujące dla badaczy. Problemem jest to, czy dzisiejsze decyzje kryptograficzne będą chronić jutrzejsze zobowiązania biznesowe.
Dla wielu organizacji uczciwa odpowiedź jest niewygodna. Szyfrowanie jest wszędzie: bramy TLS, VPN, portale klientów, tokeny tożsamości, kopie zapasowe baz danych, aplikacje mobilne, platformy płatnicze, S/MIME, SSH, integracje API, usługi SaaS, sprzętowe moduły bezpieczeństwa (HSM), chmurowe usługi zarządzania kluczami, podpisywanie oprogramowania układowego, podpisywanie kodu i umowy cyfrowe.
Na tym polega problem. Kryptografia jest wszędzie, ale często nigdzie nie wskazano jej właściciela.
Migracja do kryptografii postkwantowej nie dotyczy wyłącznie przyszłego, kryptograficznie istotnego komputera kwantowego. Dotyczy również dzisiejszego ryzyka „zbierz teraz, odszyfruj później”, w którym przeciwnicy przechwytują zaszyfrowane dane już dziś i czekają, aż przyszłe możliwości pozwolą na ich praktyczne odszyfrowanie. Jeżeli organizacja przechowuje dane osobowe, dokumentację medyczną, dane finansowe objęte regulacjami, tajemnice przedsiębiorstwa, komunikację prawną, dane infrastruktury krajowej, oprogramowanie układowe produktów albo długookresową własność intelektualną, ryzyko już dziś ma charakter ryzyka cyklu życia.
Plan migracji kryptograficznej odporny na zagrożenia kwantowe nie jest projektem paniki. To uporządkowany program nadzoru, inwentaryzacji, zarządzania dostawcami, architektury, testowania i audytu. Praktyczne pytanie dla CISO jest proste:
Jak zbudować plan migracji postkwantowej, który będzie wiarygodny dla kierownictwa, użyteczny dla inżynierów i możliwy do obrony przed audytorami?
Odpowiedź polega na osadzeniu prac w ISO/IEC 27001:2022, interpretowaniu zabezpieczeń przez pryzmat ISO/IEC 27002:2022, wykorzystaniu standardów kryptografii postkwantowej NIST jako technicznego kompasu oraz stworzeniu jednego modelu dowodowego wspierającego obowiązki wynikające z ISO 27001, NIST, COBIT 2019, GDPR, DORA i NIS2.
Dlaczego kryptografia postkwantowa należy do SZBI
Częstym błędem jest przypisanie migracji postkwantowej wyłącznie inżynierom kryptografii. Inżynierowie są niezbędni, ale sami nie rozwiążą problemu zarządczego.
Migracja postkwantowa obejmuje zarządzanie aktywami, klasyfikację danych, zarządzanie dostawcami, bezpieczną architekturę, zarządzanie kluczami, rozwój aplikacji, bezpieczeństwo chmury, reagowanie na incydenty, ciągłość działania, ryzyko prawne, odpowiedzialność regulacyjną oraz dowody audytowe. Są to obszary SZBI.
ISO/IEC 27001:2022 zapewnia ramy zarządzania. Wymaga, aby organizacja rozumiała kontekst, strony zainteresowane, ryzyka, cele, odpowiedzialności, kompetencje, udokumentowane informacje, planowanie operacyjne, ocenę wyników, audyt wewnętrzny, przegląd zarządzania oraz ciągłe doskonalenie. ISO/IEC 27002:2022 zapewnia następnie interpretację zabezpieczeń, szczególnie w obszarach 8.24 Use of cryptography, 5.9 Inventory of information and other associated assets, 5.12 Classification of information, 5.21 Managing information security in the ICT supply chain, 5.23 Information security for use of cloud services, 8.25 Secure development life cycle, 8.8 Management of technical vulnerabilities, 8.16 Monitoring activities oraz 5.30 ICT readiness for business continuity.
W Clarysec gotowość postkwantowa jest dlatego traktowana jako transformacja prowadzona w ramach SZBI, a nie jako izolowana wymiana algorytmów.
Jak wskazano w materiale Clarysec Zenith Blueprint: 30-etapowa mapa drogowa audytora, faza 2, krok 8, „Określenie zakresu aktywów, zależności i dowodów”:
„Zabezpieczeniu nie można ufać, dopóki organizacja nie potrafi wykazać, gdzie ma zastosowanie, kto jest jego właścicielem, jakie dowody je wspierają i jakie ryzyko ogranicza.”
To zdanie jest szczególnie ważne dla kryptografii postkwantowej. Zanim wymienisz algorytmy, musisz wiedzieć, gdzie są używane.
Materiał Clarysec Zenith Controls: przewodnik po zgodności przekrojowej ujmuje kryptografię jako powiązany łańcuch dowodowy, a nie pojedyncze ustawienie techniczne:
„Zapewnienie skuteczności zabezpieczeń kryptograficznych jest audytowane przez cały cykl życia informacji: identyfikację, klasyfikację, zatwierdzone użycie, ochronę kluczy, monitorowanie operacyjne, zależność od dostawcy, obsługę wyjątków i okres przechowywania dowodów.”
Takie spojrzenie na cykl życia zapobiega najczęstszej porażce: zadawaniu wyłącznie pytania „Czy używamy algorytmów bezpiecznych kwantowo?”. Lepsze pytania brzmią:
- Które systemy wymagają migracji postkwantowej w pierwszej kolejności?
- Które dane wymagają poufności przez okres dłuższy niż horyzont ryzyka kwantowego?
- Którzy dostawcy kontrolują nasze szyfrowanie, podpisy, certyfikaty lub zarządzanie kluczami?
- Które aplikacje zapewniają zwinność kryptograficzną, a które mają twardo zakodowane mechanizmy?
- Jakie zabezpieczenia kompensujące istnieją do czasu zakończenia migracji?
- Jakie dowody wykażą, że decyzje były oparte na ryzyku i podlegały przeglądowi?
Od zagrożenia kwantowego do audytowalnego ryzyka biznesowego
Użyteczny plan postkwantowy zaczyna się od scenariuszy ryzyka. Należy unikać ogólnych stwierdzeń typu „komputery kwantowe mogą złamać szyfrowanie”. Zamiast tego należy tworzyć audytowalne zapisy ryzyka, które łączą wpływ biznesowy, zagrożenie, podatność, aktywa objęte wpływem, obecne zabezpieczenia, ryzyko szczątkowe oraz działania w zakresie postępowania z ryzykiem.
Na przykład:
„Zaszyfrowane dokumenty tożsamości klientów przechowywane przez siedem lat mogą być podatne na przyszłe odszyfrowanie, jeżeli kopie zapasowe zostaną dziś wyeksfiltrowane, a obecna kryptografia klucza publicznego stanie się w przyszłości możliwa do złamania.”
Ten scenariusz wskazuje na okres przechowywania danych, szyfrowanie kopii zapasowych, zarządzanie kluczami, kontrolę dostępu, hosting u dostawcy, monitorowanie oraz priorytet migracji.
Inny przykład:
„Podpisywanie oprogramowania układowego dla urządzeń połączonych opiera się na schematach podpisu, które mogą nie pozostać wiarygodne przez oczekiwany cykl życia urządzenia.”
To wskazuje na bezpieczeństwo produktu, bezpieczne mechanizmy aktualizacji, możliwości HSM, bezpieczeństwo klientów, zapewnienie jakości projektu po stronie dostawcy oraz długoterminową odporność operacyjną.
Trzeci przykład:
„Zarchiwizowana komunikacja prawna zaszyfrowana dziś może wymagać poufności przez ponad piętnaście lat, tworząc ekspozycję typu „zbierz teraz, odszyfruj później”.”
To wskazuje na klasyfikację, okres przechowywania, ochronę kryptograficzną, zabezpieczenie prawne, bezpieczną komunikację oraz akceptację ryzyka przez kadrę kierowniczą.
Ryzyko nie ogranicza się do przyszłego „Q-Day”. Obejmuje trzy powiązane zagadnienia:
- Zbierz teraz, odszyfruj później — przeciwnicy gromadzą dziś zaszyfrowane dane w celu ich przyszłego odszyfrowania.
- Kompromitacja podpisów cyfrowych — przyszłe ataki podważają zaufanie do aktualizacji oprogramowania, tokenów tożsamości, dokumentów prawnych, oprogramowania układowego i transakcji finansowych.
- Nieskuteczność wynikająca z koncentracji kryptograficznej — szeroka klasa produktów, protokołów, bibliotek lub dostawców staje się przestarzała w tym samym czasie.
Polityka korporacyjna Clarysec Polityka kryptografii i zarządzania kluczami, klauzula 5.1, ujmuje wymaganie zarządcze następująco:
„Zabezpieczenia kryptograficzne muszą być wybierane, wdrażane, przeglądane i wycofywane na podstawie klasyfikacji informacji, wymaganego czasu ochrony, zatwierdzonych standardów kryptograficznych, własności kluczy oraz udokumentowanych decyzji dotyczących postępowania z ryzykiem.”
Ta klauzula jest krytyczna, ponieważ wymagany czas ochrony staje się czynnikiem priorytetyzacji. Krótkotrwałe dane sesyjne i długoterminowa dokumentacja medyczna nie niosą tego samego ryzyka kwantowego. Klucz do podpisywania kodu, który podtrzymuje zaufanie do urządzenia przez piętnaście lat, ma inny profil ryzyka niż krótkotrwały wewnętrzny certyfikat testowy.
Ta sama rodzina polityk, określana w materiałach Clarysec jako Polityka zabezpieczeń kryptograficznych, może również formalizować oczekiwania dotyczące przeglądów poprzez następujące brzmienie:
Klauzula 5.4: Standardy algorytmów i długości kluczy
„Wszystkie algorytmy kryptograficzne i długości kluczy używane w organizacji muszą być wybierane z zatwierdzonej listy utrzymywanej przez zespół ds. bezpieczeństwa informacji. Lista ta musi być przeglądana corocznie pod kątem najlepszych praktyk branżowych oraz wytycznych krajowych organów cyberbezpieczeństwa (np. NIST, ENISA), ze szczególnym uwzględnieniem rozwoju postkwantowych standardów kryptograficznych. Mapa drogowa migracji systemów z algorytmów podatnych na ataki oparte na technologiach kwantowych musi być utrzymywana jako część inwentarza aktywów kryptograficznych.”
Nie wymaga to niebezpiecznego, przedwczesnego wdrożenia. Wymaga świadomości, planowania, przeglądu i dowodów.
Wykorzystaj standardy NIST PQC jako techniczny kompas
Prace NIST nad kryptografią postkwantową dają organizacjom wiarygodny kierunek techniczny. NIST ustandaryzował ML-KEM do ustanawiania kluczy, ML-DSA do podpisów cyfrowych oraz SLH-DSA do bezstanowych podpisów opartych na funkcjach skrótu. Standardy te dają dostawcom i architektom podstawę do tworzenia map drogowych oraz projektów pilotażowych.
Dla CISO celem nie jest zapamiętywanie szczegółów algorytmów. Celem jest stworzenie ścieżki migracji, która pozwoli przyjmować zatwierdzone rozwiązania kryptograficzne bez naruszania usług biznesowych, zobowiązań dotyczących zgodności ani identyfikowalności audytowej.
Plan migracji zgodny z kierunkiem NIST powinien obejmować cztery ścieżki:
- Odkrywanie — identyfikację miejsc występowania podatnej kryptografii klucza publicznego.
- Priorytetyzację — uszeregowanie systemów według wrażliwości danych, wymaganego czasu ochrony, ekspozycji, wpływu na integralność i krytyczności biznesowej.
- Architekturę przejściową — określenie, gdzie będą testowane i przyjmowane mechanizmy hybrydowe, zapewniające zwinność kryptograficzną lub postkwantowe.
- Zapewnienie — wytworzenie dowodów, że decyzje, wyjątki, zależności od dostawców, testy i ryzyka szczątkowe są kontrolowane.
Szczególnej uwagi wymaga zwinność kryptograficzna. System zwinny kryptograficznie może zmieniać algorytmy, rozmiary kluczy, biblioteki, certyfikaty i protokoły bez istotnego przeprojektowania. W erze postkwantowej nie jest to luksus. To wymóg odporności.
Jeżeli API płatnicze ma twardo zakodowane biblioteki kryptograficzne i nie ma udokumentowanego właściciela, nie jest zwinne kryptograficznie. Jeżeli aplikacja mobilna stosuje przypinanie certyfikatów bez zarządzanej ścieżki aktualizacji, migracja może stać się kosztowna. Jeżeli urządzenie IoT ma piętnastoletni czas pracy w terenie i nie obsługuje większych podpisów ani bezpiecznych aktualizacji oprogramowania układowego, ryzyko ma charakter strategiczny.
Zbuduj inwentarz kryptograficzny przed wyborem ścieżki migracji
Większość organizacji nie posiada kompletnego inwentarza kryptograficznego. Mogą mieć inwentarz certyfikatów, arkusz kalkulacyjny do zarządzania kluczami, zapisy HSM, listę chmurowego KMS albo wpisy w CMDB. Rzadko mają jednak jeden widok zależności kryptograficznych.
Plan migracji do kryptografii postkwantowej wymaga kryptograficznego wykazu komponentów, czyli CBOM. Nie musi być doskonały pierwszego dnia. Musi jednak być ustrukturyzowany, mieć właściciela i być stale doskonalony.
Co najmniej należy ująć następujące pola:
| Pole inwentarza | Dlaczego ma znaczenie dla migracji postkwantowej |
|---|---|
| Usługa biznesowa | Priorytetyzuje migrację według wpływu biznesowego |
| Właściciel aktywa | Przypisuje rozliczalność i uprawnienia decyzyjne |
| Klasyfikacja danych | Identyfikuje wymagania dotyczące poufności i integralności |
| Wymagany czas ochrony | Ujawnia ekspozycję typu „zbierz teraz, odszyfruj później” |
| Funkcja kryptograficzna | Rozdziela szyfrowanie, wymianę kluczy, podpisy, haszowanie i certyfikaty |
| Algorytm i protokół | Identyfikuje miejsca użycia podatnych mechanizmów klucza publicznego |
| Biblioteka lub implementacja | Pokazuje zależności programowe i ograniczenia aktualizacji |
| Lokalizacja kluczy | Pokazuje, czy klucze znajdują się w HSM, chmurowym KMS, oprogramowaniu, punkcie końcowym lub platformie dostawcy |
| Zależność od dostawcy | Ujawnia, gdzie migracja zależy od stron trzecich |
| Złożoność migracji | Wspiera sekwencjonowanie, testowanie i planowanie budżetu |
| Źródło dowodów | Sprawia, że inwentarz jest gotowy do audytu |
Początkowy inwentarz może wyglądać następująco:
| Identyfikator aktywa | Nazwa aktywa | Właściciel | Krytyczność biznesowa | Użycie kryptografii | Lokalizacja | Ekspozycja postkwantowa | Priorytet migracji |
|---|---|---|---|---|---|---|---|
| APP-042 | API rozliczeń klientów | Zespół technologii finansowych | Wysoka | Podpisy RSA-2048, TLS, szyfrowanie AES-256 | AWS eu-west-1 | Wysoka dla zaufania zależnego od RSA | 1 |
| NET-007 | VPN dostępu zdalnego | Infrastruktura IT | Wysoka | Uwierzytelnianie ECDSA, IKEv2 | Infrastruktura lokalna i brzeg chmurowy | Wysoka dla uwierzytelniania zależnego od ECC | 1 |
| DB-011 | Zarchiwizowana dokumentacja pacjentów | Zgodność | Wysoka przy 30-letnim okresie przechowywania | Szyfrowanie bazy danych AES-256 | Lokalna baza danych | Niższa dla szyfrowania symetrycznego; wysoka, jeżeli klucze są wymieniane lub opakowywane podatnymi metodami klucza publicznego | 2 |
| CODE-001 | Podpisywanie kodu CI/CD | DevOps | Wysoki wpływ na integralność | Podpisywanie kodu RSA-4096 | HSM i potok budowania | Wysoka dla długoterminowego zaufania do podpisów | 1 |
Ta tabela natychmiast pokazuje, dlaczego inwentarz ma znaczenie. AES-256 nie jest takim samym rodzajem ryzyka kwantowego jak RSA lub ECC, ale zarchiwizowana dokumentacja pacjentów może nadal zależeć od podatnego opakowywania kluczy, certyfikatów, systemów tożsamości lub kanałów transferu kopii zapasowych. Podpisywanie kodu może nie chronić poufności, ale chroni integralność oprogramowania i zaufanie.
W Zenith Controls kryptografia jest krzyżowo powiązana ze standardami wspierającymi, które zapewniają dodatkową głębię. ISO/IEC 27005 wspiera zarządzanie ryzykiem bezpieczeństwa informacji i pomaga przełożyć niepewność kwantową na ustrukturyzowane scenariusze ryzyka. ISO/IEC 27017 wspiera zabezpieczenia specyficzne dla chmury, co jest niezbędne, gdy usługi kryptograficzne są dostarczane przez chmurowy KMS, zarządzany TLS, szyfrowanie SaaS lub certyfikaty platformowe. ISO/IEC 27018 ma znaczenie, gdy dane osobowe są przetwarzane w publicznych usługach chmurowych. ISO 22301 ma znaczenie tam, gdzie awaria kryptografii mogłaby wpływać na ciągłość usług krytycznych. ISO/IEC 27036 wspiera bezpieczeństwo relacji z dostawcami, co jest kluczowe, gdy dostawcy zarządzają szyfrowaniem, podpisami, certyfikatami lub bezpieczną komunikacją w imieniu organizacji.
Wniosek jest prosty: nie da się migrować tego, czego nie można znaleźć.
Priorytetyzuj według wrażliwości, czasu ochrony, ekspozycji i trudności migracji
Gdy CBOM istnieje, priorytetyzacja staje się oparta na dowodach. Najlepszym punktem wyjścia jest niewielka liczba systemów krytycznych, a nie próba osiągnięcia doskonałości w całej organizacji.
Wyobraźmy sobie firmę z sektora usług finansowych z trzema systemami o wysokiej wartości:
- repozytorium dokumentów klientów przechowujące dowody tożsamości przez dziesięć lat,
- bramę API B2B obsługującą transakcje z partnerami,
- platformę podpisywania kodu dla aktualizacji oprogramowania desktopowego.
Korzystając z Zenith Blueprint, faza 2, krok 8, zespół pozyskuje aktywa z CMDB, certyfikaty z platformy zarządzania certyfikatami, klucze z HSM i chmurowego KMS, klasy danych z rejestru prywatności oraz zależności od dostawców z zapisów zakupowych.
Następnie ocenia systemy:
| System | Wrażliwość danych | Wymagany czas ochrony | Ekspozycja zewnętrzna | Zależność od dostawcy | Priorytet migracji |
|---|---|---|---|---|---|
| Repozytorium dokumentów klientów | Bardzo wysoka | Długi | Średnia | Chmurowy KMS i dostawca przechowywania | Krytyczny |
| Brama API B2B | Wysoka | Krótki do średniego | Bardzo wysoka | Dostawca zarządzania API | Wysoki |
| Platforma podpisywania kodu | Bardzo wysoki wpływ na integralność | Długoterminowe zaufanie do urządzeń | Średnia | HSM i narzędzia potoku budowania | Krytyczny |
Repozytorium dokumentów klientów staje się priorytetem ze względu na czas wymaganej poufności. Platforma podpisywania kodu staje się priorytetem, ponieważ zaufanie do podpisów wpływa na integralność oprogramowania i bezpieczeństwo klientów. Brama API ma wysoki priorytet ze względu na ekspozycję zewnętrzną, ale przechowywane przez nią dane mogą wymagać krótszego okresu poufności.
Rejestr ryzyk powinien następnie powiązać każdy scenariusz z postępowaniem z ryzykiem i dowodami:
| Scenariusz ryzyka | Obecne zabezpieczenie | Decyzja dotycząca postępowania z ryzykiem | Wymagane dowody |
|---|---|---|---|
| Długookresowe rejestry klientów mogą być narażone na przyszłe odszyfrowanie | Szyfrowanie danych w spoczynku, kontrola dostępu, chmurowy KMS | Ocenić mapę drogową szyfrowania pamięci masowej, wzmocnić separację kluczy, przejrzeć kryptografię transferu kopii zapasowych | CBOM, mapa drogowa dostawcy, decyzja architektoniczna, zapis postępowania z ryzykiem |
| Zaufanie do aktualizacji oprogramowania może zostać osłabione przez przyszłą kompromitację podpisów | HSM do podpisywania kodu, zatwierdzanie wydań | Ocenić gotowość do podpisów postkwantowych, strategię znakowania czasem oraz cykl życia podpisywania | Inwentarz podpisywania, raport możliwości HSM, procedura bezpiecznego rozwoju oprogramowania |
| Kryptografia API partnerów może być trudna do szybkiej zmiany | Certyfikaty TLS, konfiguracja bramy API | Wdrożyć testowanie zwinności kryptograficznej oraz przegląd mapy drogowej dostawcy | Skan TLS, konfiguracja bazowa, oświadczenie dostawcy |
Polityka korporacyjna Clarysec Polityka bezpiecznego rozwoju oprogramowania, klauzula 6.4, przedstawia perspektywę dostarczania oprogramowania:
„Przeglądy projektu bezpieczeństwa muszą oceniać zależności kryptograficzne, cykl życia bibliotek, elastyczność algorytmiczną, postępowanie z sekretami, mechanizmy aktualizacji oraz komponenty kontrolowane przez dostawców przed zatwierdzeniem do środowiska produkcyjnego.”
Ta klauzula przekształca gotowość postkwantową w wymaganie inżynieryjne. Zapobiega wdrażaniu przez zespoły nowych systemów, których nie będzie można później migrować.
Realizuj 12-miesięczną mapę drogową zrozumiałą dla audytorów
W wielu organizacjach migracja postkwantowa potrwa lata. Pierwszy rok powinien przeprowadzić organizację od niepewności do zarządzanej migracji.
| Miesiąc | Strumień prac | Wynik | Dowody |
|---|---|---|---|
| 1 | Mandat kadry kierowniczej | Zakres na poziomie zarządu, apetyt na ryzyko i ścieżka finansowania | Protokoły komitetu sterującego, zatwierdzona karta programu |
| 1 do 2 | Odkrywanie kryptograficzne | Początkowy CBOM obejmujący usługi krytyczne | Eksport inwentarza, powiązania z CMDB, oświadczenia właścicieli systemów |
| 2 do 3 | Przegląd danych i wymaganego czasu ochrony | Spriorytetyzowana lista długookresowych danych wrażliwych i aktywów o wysokim wpływie na integralność | Rejestr klasyfikacji, harmonogram okresów przechowywania, zapisy ryzyka |
| 3 do 4 | Przegląd zależności od dostawców | Mapa drogowa dostawcy i analiza luk kontraktowych | Kwestionariusze dostawców, klauzule umowne, wyjątki od ryzyka |
| 4 do 6 | Ocena architektury i zwinności kryptograficznej | Docelowe wzorce architektoniczne i ograniczenia migracji | Zapisy przeglądów architektury, decyzje projektowe |
| 6 do 8 | Wdrożenie pilotażowe | Test hybrydowy lub postkwantowy w wybranym środowisku niskiego ryzyka | Wyniki testów, plan wycofania zmian, ustalenia dotyczące wydajności |
| 8 do 10 | Aktualizacja polityk i procedur | Zaktualizowane zasady dotyczące kryptografii, zarządzania kluczami, dostawców, bezpiecznego rozwoju oprogramowania i aktywów | Zatwierdzone polityki, zapisy szkoleń |
| 10 do 12 | Gotowość do audytu | Audyt wewnętrzny, przegląd zarządzania i odświeżenie planu postępowania z ryzykiem | Raport z audytu, działania korygujące, zaktualizowany plan postępowania z ryzykiem |
W Zenith Blueprint, faza 3, krok 14, „Projektowanie postępowania z ryzykiem i własność”, mapa drogowa ostrzega przed niefinansowanymi intencjami bezpieczeństwa:
„Plan postępowania z ryzykiem bez właściciela, oczekiwań dowodowych, ścieżki budżetowej i daty przeglądu nie jest planem. To nierozwiązane ryzyko z lepszym formatowaniem.”
Właśnie w ten sposób programy postkwantowe zawodzą. Produkują slajdy uświadamiające, ale nie tworzą backlogu działań naprawczych z przypisanymi właścicielami. Omawiają algorytmy, ale nie aktualizują umów z dostawcami. Dokumentują ryzyko, ale nie testują wzorców migracyjnych.
Wiarygodna mapa drogowa tworzy zapisy decyzji, właścicieli, zależności, oczekiwania dowodowe, budżety i daty przeglądów.
Włącz dostawców do programu na wczesnym etapie
Wiele zależności kryptograficznych jest realizowanych w modelu outsourcingu. Dostawcy chmurowi terminują TLS. Platformy SaaS szyfrują rejestry. Dostawcy tożsamości podpisują tokeny. Procesory płatnicze zarządzają certyfikatami. Dostawcy sprzętu kontrolują podpisywanie oprogramowania układowego. Dostawcy usług zarządzanych obsługują VPN i bramy bezpieczeństwa.
Nawet jeżeli wewnętrzny zespół jest gotowy, migracja może zostać zablokowana przez możliwości dostawców.
Polityka korporacyjna Clarysec Polityka bezpieczeństwa dostawców i stron trzecich, klauzula 5.6, stanowi:
„Dostawcy świadczący usługi istotne dla bezpieczeństwa muszą ujawniać istotne zależności, odpowiedzialności kryptograficzne, dowody zapewnienia, procesy obsługi podatności oraz zmiany w mapie drogowej, które mogą wpływać na profil ryzyka organizacji.”
W kontekście gotowości postkwantowej należy zapytać dostawców krytycznych:
- Jakie algorytmy, protokoły, certyfikaty i usługi zarządzania kluczami chronią nasze dane lub transakcje?
- Czy utrzymujecie inwentarz kryptograficzny lub CBOM?
- Jaka jest Wasza mapa drogowa postkwantowa zgodna z NIST?
- Czy będziecie wspierać hybrydową wymianę kluczy, podpisy postkwantowe lub odporne na zagrożenia kwantowe ustanawianie kluczy?
- Jak będą komunikowane zmiany dotyczące certyfikatów, tokenów, podpisywania i szyfrowania?
- Jakie działania będą wymagane po stronie klienta?
- Jakie środowiska testowe będą dostępne?
- Jak będą obsługiwane wydajność, interoperacyjność i wycofanie zmian?
- Czy odpowiedzialności kryptograficzne są zdefiniowane w umowie lub modelu współdzielonej odpowiedzialności?
- Jakie opcje wyjścia lub przenoszalności istnieją, jeżeli Wasza mapa drogowa nie spełni naszych wymagań dotyczących ryzyka?
Odpowiedzi dostawców powinny zasilać rejestr ryzyk. Słabe odpowiedzi nie zawsze oznaczają konieczność natychmiastowej wymiany, ale wymagają postępowania z ryzykiem. Mogą być potrzebne zabezpieczenia kompensujące, aneksy do umów, klauzule powiadomień, planowanie wyjścia, wzmocnione monitorowanie albo zmieniona strategia zakupowa.
Jest to szczególnie istotne w świetle oczekiwań dotyczących odporności operacyjnej w DORA i NIS2. DORA kładzie nacisk na zarządzanie ryzykiem ICT i zarządzanie ryzykiem stron trzecich ICT, w tym nadzór nad krytycznymi zależnościami. NIS2 Article 21 wymaga odpowiednich i proporcjonalnych technicznych, operacyjnych oraz organizacyjnych środków zarządzania ryzykiem bezpieczeństwa, w tym bezpieczeństwa łańcucha dostaw, obsługi incydentów, ciągłości działania oraz kryptografii tam, gdzie jest to właściwe. GDPR Article 32 wymaga bezpieczeństwa odpowiedniego do ryzyka, obejmującego poufność, integralność, dostępność, odporność oraz zdolność do zapewnienia ciągłej ochrony danych osobowych.
Język regulacyjny jest różny, ale logika zabezpieczeń pozostaje spójna: znaj swoje zależności, zarządzaj ryzykiem, zachowuj dowody i działaj, zanim odporność zostanie naruszona.
Mapowanie zgodności przekrojowej: jeden plan migracji, wiele obowiązków
Silny plan migracji do kryptografii postkwantowej powinien unikać tworzenia oddzielnych pakietów dowodowych dla każdych ram. Te same podstawowe dowody mogą wspierać wiele obowiązków, jeżeli są właściwie ustrukturyzowane.
Zenith Controls mapuje temat kryptografii na ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST, COBIT 2019, GDPR, DORA i NIS2, koncentrując się na celu zabezpieczenia, a nie na etykiecie używanej przez dane ramy.
| Ramy | Jak plan postkwantowy wspiera zgodność |
|---|---|
| ISO/IEC 27001:2022 | Wykazuje dobór zabezpieczeń oparty na ryzyku, udokumentowane informacje, audyt wewnętrzny, przegląd zarządzania i ciągłe doskonalenie |
| ISO/IEC 27002:2022 | Wspiera interpretację zabezpieczeń dla 8.24 Use of cryptography, inwentarza aktywów, klasyfikacji, bezpieczeństwa dostawców, usług chmurowych, bezpiecznego rozwoju oprogramowania, monitorowania i ciągłości |
| Standardy NIST PQC | Zapewniają kierunek techniczny dla przejścia na zatwierdzone algorytmy postkwantowe i planowania kryptograficznego |
| NIST Cybersecurity Framework 2.0 | Łączy działania migracyjne z wynikami Govern, Identify, Protect, Detect, Respond i Recover |
| COBIT 2019 | Dostosowuje ryzyko kryptograficzne do celów zarządzania i nadzoru, takich jak APO12 Managed Risk, APO13 Managed Security, APO10 Managed Vendors, DSS05 Managed Security Services oraz MEA03 Managed Compliance |
| GDPR | Wspiera oczekiwania Article 32 dotyczące odpowiedniego bezpieczeństwa, poufności, integralności, odporności i rozliczalności przetwarzania danych osobowych |
| DORA | Wspiera zarządzanie ryzykiem ICT, zarządzanie ryzykiem stron trzecich ICT, testowanie odporności, gotowość do incydentów i nadzór organu zarządzającego |
| NIS2 | Wspiera środki zarządzania ryzykiem bezpieczeństwa z Article 21, bezpieczeństwo łańcucha dostaw, obsługę incydentów, ciągłość działania i rozliczalność zarządczą |
Kluczowe jest ponowne wykorzystanie dowodów. Inwentarz kryptograficzny wspiera zarządzanie aktywami ISO, wyniki Identify w NIST, widoczność aktywów ICT w DORA, zarządzanie ryzykiem NIS2 oraz rozliczalność GDPR. Kwestionariusze dostawców wspierają zabezpieczenia ISO dotyczące dostawców, ryzyko stron trzecich ICT w DORA, bezpieczeństwo łańcucha dostaw NIS2 oraz nadzór nad dostawcami w COBIT. Wyniki testów migracyjnych wspierają bezpieczną zmianę, testowanie odporności, gotowość do audytu i przegląd zarządzania.
O co zapytają audytorzy
Kryptografia postkwantowa nadal jest wyłaniającym się tematem audytowym, ale audytorzy już dziś mają wystarczające oczekiwania kontrolne, aby zadawać trudne pytania.
Audytor ISO/IEC 27001:2022 zwykle zacznie od ryzyka. Zapyta, czy ryzyko kryptograficzne związane z technologiami kwantowymi zostało zidentyfikowane, ocenione, objęte postępowaniem, monitorowane i przeglądane w ramach SZBI. Będzie oczekiwał dowodów, że zabezpieczenia kryptograficzne są dobierane na podstawie ryzyka biznesowego, a odpowiedzialności są zdefiniowane.
Asesor zorientowany na NIST może skupić się na widoczności aktywów, mechanizmach ochrony, ryzyku łańcucha dostaw, zarządzaniu podatnościami i wynikach zarządzania. Może zapytać, czy organizacja zidentyfikowała systemy używające podatnej kryptografii klucza publicznego oraz czy planowanie migracji jest zgodne z kierunkiem NIST.
Audytor COBIT lub ISACA często zapyta o nadzór. Kto jest rozliczalny? W jaki sposób zarząd otrzymuje raporty? Czy inwestycje są priorytetyzowane? Czy zależności od dostawców są zarządzane? Czy korzyści, ryzyka i zasoby są zrównoważone?
Audytor prywatności może skupić się na tym, czy szyfrowanie i zarządzanie kluczami pozostają odpowiednie do wrażliwości i okresu przechowywania danych osobowych.
Osoba prowadząca przegląd z perspektywy DORA lub NIS2 będzie analizować odporność, koncentrację stron trzecich ICT, ciągłość operacyjną oraz gotowość do incydentów.
| Perspektywa audytu | Prawdopodobne pytania | Dowody do przygotowania |
|---|---|---|
| ISO/IEC 27001:2022 | Czy ryzyko postkwantowe jest uwzględnione w procesie zarządzania ryzykiem SZBI? Czy zabezpieczenia kryptograficzne są wybierane i przeglądane? | Rejestr ryzyk, plan postępowania z ryzykiem, Deklaracja stosowania, zatwierdzenia polityk, wyniki audytu wewnętrznego |
| NIST | Czy organizacja zinwentaryzowała wykorzystanie kryptografii i zaplanowała migrację w kierunku zatwierdzonych podejść? | CBOM, decyzje architektoniczne, wyniki pilotażu, backlog migracyjny |
| COBIT 2019 | Czy przejście kryptograficzne jest zarządzane, finansowane i monitorowane? | Raporty dla zarządu, protokoły organów zarządczych, KPI, panele ryzyka dostawców |
| GDPR | Czy ochrona kryptograficzna pozostaje odpowiednia do wrażliwości i okresu przechowywania danych osobowych? | Klasyfikacja danych, odniesienia do DPIA, harmonogram okresów przechowywania, projekt szyfrowania |
| DORA | Czy zależności ICT i zależności od dostawców są rozumiane i odporne? | Rejestr aktywów ICT, oświadczenia dostawców, dowody testów, plany wyjścia |
| NIS2 | Czy środki zarządzania ryzykiem łańcucha dostaw i bezpieczeństwa są skuteczne? | Przeglądy dostawców, procedury incydentowe, plany ciągłości, zapisy postępowania z ryzykiem |
Zenith Controls zaleca traktowanie przygotowania do audytu jako ścieżki dowodowej. Nie czekaj, aż audytorzy poproszą o zrzuty ekranu i arkusze kalkulacyjne. Zbuduj przestrzeń roboczą GRC, która łączy każde ryzyko kryptograficzne z jego właścicielem, aktywami objętymi wpływem, dostawcami, decyzjami, testami, wyjątkami i datami przeglądu.
Zaktualizuj polityki, aby program stał się operacyjny
Większość polityk kryptograficznych została napisana z myślą o tradycyjnych wymaganiach dotyczących poufności i integralności. Migracja postkwantowa wymaga ukierunkowanych uzupełnień.
Polityka kryptografii i zarządzania kluczami powinna obejmować zatwierdzone standardy, częstotliwość przeglądów, klasyfikację danych, wymagany czas ochrony, zwinność kryptograficzną, generowanie kluczy, przechowywanie kluczy, rotację, niszczenie, własność, cykl życia certyfikatów, odpowiedzialność za HSM, odpowiedzialność za chmurowy KMS, zatwierdzanie wyjątków, kryptografię kontrolowaną przez dostawców oraz monitorowanie przejścia postkwantowego.
Polityka bezpiecznego rozwoju oprogramowania powinna obejmować zatwierdzanie bibliotek kryptograficznych, zakaz stosowania twardo zakodowanych algorytmów bez przeglądu, śledzenie zależności, bezpieczne mechanizmy aktualizacji, testy wydajności dla większych kluczy lub podpisów, kompatybilność wsteczną, wycofanie zmian oraz modelowanie zagrożeń dla produktów o długim cyklu życia.
Polityka bezpieczeństwa dostawców powinna obejmować transparentność kryptograficzną, wnioski o mapy drogowe postkwantowe, umowne obowiązki powiadamiania, współdzieloną odpowiedzialność za szyfrowanie i zarządzanie kluczami, planowanie wyjścia oraz przenoszalność.
Procedura zarządzania aktywami powinna obejmować pola inwentarza kryptograficznego, własność, źródła dowodów, częstotliwość przeglądów oraz integrację z CMDB, inwentarzem chmurowym, zarządzaniem certyfikatami, zapisami HSM i repozytoriami kodu.
W tym miejscu biblioteka polityk Clarysec pomaga organizacjom działać szybciej. Zamiast pisać od pustej strony, zespoły mogą dostosować klauzule polityk do procedur, rejestrów, kwestionariuszy i dowodów audytowych.
Unikaj najczęstszych błędów w migracji postkwantowej
Najgroźniejsze błędy są zwykle błędami zarządzania, a nie błędami technicznymi.
Rozpoczynanie od algorytmów zamiast od aktywów. Jeżeli nie wiesz, gdzie używana jest kryptografia, wybór algorytmu nie pomoże.
Ignorowanie czasu życia danych. Krótkotrwałe dane transakcyjne i długookresowe archiwa wrażliwe nie niosą tego samego ryzyka.
Traktowanie dostawców jako późniejszego etapu. Wiele zabezpieczeń kryptograficznych jest zarządzanych przez dostawców. Jeżeli dostawcy nie zostaną włączeni wcześnie, plan może być nierealistyczny.
Zapominanie o podpisach. Planowanie postkwantowe nie dotyczy wyłącznie szyfrowania. Podpisy cyfrowe, podpisywanie kodu, certyfikaty, tokeny tożsamości, aktualizacje oprogramowania układowego i podpisywanie dokumentów wymagają uwagi.
Zakładanie, że dostawcy chmury rozwiążą wszystko. Platformy chmurowe odegrają ważną rolę, ale odpowiedzialność pozostaje współdzielona. Nadal trzeba wiedzieć, które usługi, konfiguracje, klucze, regiony i integracje są objęte wpływem.
Brak tworzenia dowodów audytowych. Plan migracji, którego nie można udowodnić, nie zaspokoi potrzeb kierownictwa, regulatorów, klientów ani audytorów.
Pomijanie testów wydajności i interoperacyjności. Algorytmy postkwantowe mogą wpływać na rozmiar ładunku, przebieg handshake, opóźnienia, pamięć masową, ograniczenia systemów wbudowanych i kompatybilność.
Wskaźniki, które CISO powinien raportować zarządowi
Raportowanie dla zarządu powinno być wystarczająco proste do zrozumienia i jednocześnie wystarczająco konkretne, aby wymuszać działania. Należy unikać szczegółowych debat o algorytmach. Trzeba skupić się na ekspozycji, postępie, decyzjach i ryzyku szczątkowym.
| Wskaźnik | Znaczenie dla zarządu |
|---|---|
| Odsetek usług krytycznych z ukończonym inwentarzem kryptograficznym | Pokazuje widoczność |
| Odsetek długookresowych danych wrażliwych odwzorowanych na zabezpieczenia kryptograficzne | Pokazuje przygotowanie na ryzyko „zbierz teraz, odszyfruj później” |
| Liczba krytycznych dostawców, od których otrzymano mapę drogową postkwantową | Pokazuje gotowość stron trzecich |
| Liczba wysokiego ryzyka wyjątków kryptograficznych | Pokazuje niezarządzaną ekspozycję |
| Odsetek aplikacji krytycznych ocenionych pod kątem zwinności kryptograficznej | Pokazuje wykonalność migracji |
| Status ukończenia pilotażu | Pokazuje praktyczny postęp |
| Zaległe otwarte działania dotyczące postępowania z ryzykiem | Pokazuje ryzyko wykonawcze |
| Trend ryzyka szczątkowego | Pokazuje, czy program zmniejsza ekspozycję |
Użyteczny komunikat dla zarządu może brzmieć tak:
„Zakończyliśmy odkrywanie kryptograficzne dla 72 procent usług krytycznych. Dwa systemy mają krytyczną długookresową ekspozycję poufności, a trzech dostawców nie przedstawiło jeszcze map drogowych postkwantowych. Uruchomiliśmy projekt gotowości do podpisywania kodu oraz przegląd zależności od chmurowego KMS. Na dziś nie rekomendujemy awaryjnej wymiany, ale niepewność po stronie dostawców pozostaje największym ryzykiem szczątkowym.”
To język zarządzanego ryzyka cybernetycznego.
Praktyczna lista kontrolna na ten tydzień
Nie trzeba czekać na pełną pewność. Zacznij od kroków, które natychmiast poprawią widoczność i zarządzanie.
- Wyznacz właściciela kryptografii postkwantowej.
- Dodaj ryzyko kryptograficzne związane z technologiami kwantowymi do rejestru ryzyk SZBI.
- Zidentyfikuj dziesięć najważniejszych usług z długookresowymi danymi wrażliwymi lub wysokim wpływem na integralność.
- Zbuduj minimalny użyteczny CBOM dla tych usług.
- Poproś dostawców krytycznych o ich mapę drogową postkwantową.
- Przejrzyj polityki dotyczące kryptografii, bezpiecznego rozwoju oprogramowania, dostawców i aktywów.
- Zidentyfikuj systemy z twardo zakodowanymi algorytmami, przestarzałymi bibliotekami, ręczną rotacją certyfikatów lub słabą odpowiedzialnością właścicielską.
- Wybierz jeden pilotaż niskiego ryzyka do testowania zwinności kryptograficznej.
- Zdefiniuj wskaźniki dla zarządu i częstotliwość raportowania.
- Zaplanuj audyt wewnętrzny skoncentrowany na zarządzaniu kryptografią i dowodach.
Najważniejszym krokiem jest przekształcenie niepewności w zarządzane działania. Ryzyko kwantowe może dotyczyć przyszłości, ale dług kryptograficzny istnieje już dziś.
Kolejne kroki z Clarysec
Migracja postkwantowa będzie jedną z najbardziej złożonych transformacji bezpieczeństwa następnej dekady, ponieważ obejmuje tożsamość, szyfrowanie, podpisy, dostawców, chmurę, oprogramowanie, urządzenia, archiwa i dowody audytowe. Organizacje, które zaczną od nadzoru i inwentaryzacji, będą działały szybciej niż te, które zaczekają na wymianę w ostatniej chwili.
Clarysec może pomóc zbudować plan migracji kryptograficznej odporny na zagrożenia kwantowe, wykorzystując:
- Zenith Blueprint: 30-etapowa mapa drogowa audytora do etapowego wdrożenia i gotowości do audytu
- Zenith Controls: przewodnik po zgodności przekrojowej do mapowania ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST, COBIT 2019, GDPR, DORA i NIS2
- Polityka kryptografii i zarządzania kluczami do gotowych zarządczo reguł kryptograficznych
- Polityka bezpieczeństwa dostawców i stron trzecich do wymagań dotyczących map drogowych dostawców i zapewnienia
- Polityka bezpiecznego rozwoju oprogramowania do praktyk inżynieryjnych wspierających zwinność kryptograficzną
Najlepszy moment na rozpoczęcie planowania postkwantowego jest zanim regulator, audytor, klient lub członek zarządu poprosi o dowody. Zacznij od inwentarza, powiąż go z ryzykiem i buduj ścieżkę migracji — jedna kontrolowana decyzja po drugiej.
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


