Nie wybieraj algorytmu postkwantowego, dopóki nie wiesz, gdzie w Twojej infrastrukturze działa kryptografia klucza publicznego. NIST opublikował FIPS 203, 204 i 205 w sierpniu 2024 roku i zaleca, by organizacje zaczęły migrację już teraz. Standardy mówią, na co przejść. Nie mówią nic o tym, co uruchamiasz dzisiaj, a ustalenie tego jest najwolniejszą częścią pracy.
Czego wymagają terminy
Według strony projektu NIST, zgodnie z harmonogramem przejścia z NIST IR 8547 algorytmy podatne na ataki kwantowe zostaną uznane za przestarzałe i ostatecznie usunięte ze standardów NIST do 2035 roku, a systemy wysokiego ryzyka mają przejść znacznie wcześniej. Strona wersji roboczej IR 8547 odnotowuje, że 27 października 2026 roku zastąpiła ją wersja końcowa. Nasze źródła nie wymieniają podatnych standardów ani wcześniejszych terminów dla systemów wysokiego ryzyka, więc sprawdź je w samym tekście NIST.
Brytyjski NCSC przekłada harmonogram na kamienie milowe, pod które zespół IT może planować budżet, w swoich wytycznych dotyczących harmonogramów migracji do PQC:
| Do | Czego oczekuje NCSC |
|---|---|
| 2028 | Określić cele migracji, przeprowadzić pełne rozpoznanie (discovery) i przygotować wstępny plan |
| 2031 | Przeprowadzić wczesną migrację o najwyższym priorytecie i rozwinąć plan w pełną mapę drogową |
| 2035 | Zakończyć migrację wszystkich systemów, usług i produktów |
Inwentarz zasila wszystkie trzy zadania na 2028 rok. Jeśli jest ubogi, pozostałe dwa zadania sprowadzają się do zgadywania.
Co trafia na listę
Celem jest wszystko, co opiera się na asymetrycznej kryptografii klucza publicznego, którą według NCSC komputery kwantowe będą w stanie złamać. Sekcja NCSC o discovery obejmuje następujące obszary:
- systemy i usługi, które prowadzisz, dla użytkowników wewnętrznych i zewnętrznych;
- produkty, które wytwarzasz lub używasz i które pełnią funkcję kryptograficzną, bezpieczeństwa, komunikacyjną lub przetwarzania danych;
- aplikacje oraz sprzęt sieciowy, taki jak routery, przełączniki, bramy, VPN-y i stacje bazowe;
- urządzenia mobilne, serwery i stacje robocze;
- urządzenia IoT i ICS z funkcją komunikacyjną, tokeny wydawane użytkownikom oraz urządzenia i czujniki zainstalowane w terenie;
- dane, które przechowujesz, ich oczekiwany czas życia i wartość dla przeciwnika oraz sposób ich ochrony w tranzycie i w spoczynku.
Certyfikaty nie są wymienione na tej liście, choć NCSC ma osobną sekcję o firmowym PKI. Dodaj publiczne certyfikaty webowe, wewnętrzne CA, certyfikaty klienckie i klucze do podpisywania kodu jako osobne wiersze; to nasza ocena, nie NCSC. Dodaj też dostawców usług zarządzanych.
To nie jest formalny rejestr zasobów. Zapisz dla każdego systemu jego charakter, skalę, wersję, poziom poprawek i zależności; wystarczy jeden wiersz na system.
Gdzie inwentaryzacje zawodzą
Trzy miejsca wymagają świadomego sprawdzenia, bo żadne z nich nie pojawia się w eksporcie certyfikatów ani na liście pakietów: klucze zaszyte na stałe w kodzie aplikacji lub konfiguracji, klucze podpisujące przechowywane w HSM oraz firmware w urządzeniach wbudowanych i terenowych, których nie zaktualizujesz tak jak serwera. NCSC wskazuje jako ograniczenie sprzęt o długim cyklu życia i rzadką wymianę, a właśnie w tych urządzeniach najbardziej to doskwiera.
Spisanie wszystkiego w tydzień
Zacznij od góry, od kluczowych usług i ich wzajemnych zależności, a potem przejdź od dołu tam, gdzie ten widok się kończy. Podział, który sprawdzi się w małym zespole:
- Dzień pierwszy. Wypisz kluczowe usługi i dane, które każda z nich obsługuje, i oznacz dane, które muszą pozostać tajne przez lata. Wyślij tego samego dnia poniższy e-mail do dostawców, bo odpowiedzi trwają najdłużej.
- Dni drugi i trzeci. Wyeksportuj listy certyfikatów z każdego CA, które prowadzisz, i poproś każdy zespół kupujący certyfikaty o ich listy. Dodaj konfiguracje VPN i dostępu zdalnego. Zbierz SBOM-y, lockfile'e lub listy pakietów dla oprogramowania, które budujesz i uruchamiasz, i przeszukaj je pod kątem bibliotek kryptograficznych i ich wersji. Przeszukaj repozytoria i katalogi konfiguracyjne pod kątem zapisanych w nich kluczy prywatnych i certyfikatów; każdy znaleziony przypadek to wiersz, a klucz prywatny w repozytorium i tak trzeba naprawić.
- Dzień czwarty. Uruchom skaner TLS na zewnętrznych i wewnętrznych endpointach oraz sprawdź klucze hosta SSH i propozycje VPN lub IPsec, które oferują Twoje bramy. Porównaj wyniki ze swoimi wierszami; wynik skanowania to weryfikacja krzyżowa, a nie zamiennik.
- Dzień piąty. Scal dane, oznacz luki i wpisz „nieznane" tam, gdzie nie udało się niczego potwierdzić.
Pytania do dostawców, które zmieszczą się w jednym e-mailu:
- Które z Waszych produktów lub usług, z których korzystamy, opierają się na kryptografii klucza publicznego i jakie biblioteki w jakich wersjach zawierają?
- Jaki jest Wasz plan migracji do PQC, z datami?
NCSC zaleca, by upewnić się, że dostawcy usług zarządzanych przeprowadzają te oceny dla usług, które prowadzą dla Ciebie. Zapytanie na piśmie to nasza rekomendacja, jak to zrobić.
Zamiana listy w plan
Dla każdego wiersza wybierz jedną ze strategii NCSC: migrację w miejscu (in-place migration), przeniesienie na nową platformę (re-platform), wycofanie usługi, eksploatację do końca życia (end-of-life) albo zaakceptowanie ryzyka. Systemy bez kryptografii klucza publicznego nie wymagają żadnych działań.
Uszereguj wiersze według czasu życia i wartości chronionych danych, a następnie według zależności od sprzętu o długim cyklu życia.
Spodziewaj się, że przez jakiś czas stare i nowe rozwiązania będą działać obok siebie. Wybieraj produkty z elastycznością kryptograficzną (cryptographic agility), czyli takie, które łatwo obsługują alternatywne zestawy algorytmów, i z wyprzedzeniem ustal, kiedy zakończysz wsparcie dla tradycyjnych algorytmów.
Dopiero wtedy wybieraj algorytmy. NIST oczekuje, że ML-KEM (FIPS 203) do uzgadniania kluczy oraz ML-DSA (FIPS 204) i SLH-DSA (FIPS 205) do podpisów staną się fundamentem większości wdrożeń. FIPS 203 zawiera uwagę planistyczną o problemie, który zostanie poprawiony w przyszłej rewizji, więc przed wdrożeniem na jego podstawie sprawdź erratę. NIST nadal standaryzuje Falcon i HQC; zmian szukaj na jego stronie projektu PQC.
Jeśli potrzebujesz pomocy przy discovery, nasz zespół konsultingowy przeprowadza takie oceny.
Od czego zacząć
- Wyznacz właściciela, zarezerwuj tydzień i wyślij e-mail do dostawców pierwszego dnia.
- Zbuduj jeden wiersz na system: właściciel, przeznaczenie, miejsca użycia kryptografii klucza publicznego, wersje, zależności, czas życia danych, dostawca, wybrana strategia, docelowa data.
- Zbierz certyfikaty, konfiguracje VPN i SBOM-y, a potem uruchom skanowanie TLS, SSH i przeszukiwanie repozytoriów.
- Sprawdź ręcznie klucze zaszyte na stałe, podpisywanie oparte na HSM i firmware urządzeń wbudowanych, a wszystko niepotwierdzone oznacz jako „nieznane".
- Uszereguj wiersze według czasu życia danych i zależności od sprzętu, przypisz każdemu strategię NCSC i docelową datę, aby arkusz stał się Twoim planem na 2028 rok.
- Przeczytaj końcową wersję IR 8547 pod kątem terminów wycofania dla systemów wysokiego ryzyka i tam, gdzie to wymagane, ustal wewnętrzne terminy wcześniejsze niż 2035.
