rotacja kluczy

Rotacja kluczy to planowa wymiana kluczy kryptograficznych albo innych sekretów, takich jak tokeny API czy hasła kont serwisowych, na nowe. NIST opisuje ją przez pojęcie okresu kryptograficznego (cryptoperiod): czasu, w którym dany klucz może być używany przez uprawnione podmioty ^[1]. Dobrze dobrany okres ogranicza między innymi ilość informacji dostępnej do kryptoanalizy i skalę szkód, jeśli pojedynczy klucz zostanie skompromitowany ^[1]. Osobną sytuacją jest rotacja awaryjna, czyli natychmiastowa wymiana klucza po incydencie.

Po co wymieniać klucze

NIST wymienia sześć korzyści z ograniczenia okresu kryptograficznego ^[1]. Ograniczony okres zmniejsza ilość danych dostępnych do kryptoanalizy i zakres szkód po kompromitacji jednego klucza. Ogranicza też czas używania danego algorytmu do jego szacowanego okresu przydatności. Skraca czas na próby obejścia zabezpieczeń fizycznych, proceduralnych i logicznych, które chronią klucz. Zawęża okno, w którym dane mogą zostać ujawnione przez przypadkowe ujawnienie klucza. Wreszcie ogranicza czas na kosztowną obliczeniowo kryptoanalizę ^[1]. Wybór długości okresu jest kompromisem, w którym trzeba ocenić ryzyko i skutki ujawnienia ^[1].

Skrajną formą rotacji są sekrety dynamiczne. OWASP opisuje aplikację, która przy starcie prosi o dane dostępowe do bazy i dostaje nowe, wygenerowane tylko na tę sesję ^[2].

Jak działa

Rotacja nie polega na samym wygenerowaniu nowego klucza. Nowy klucz trzeba rozprowadzić do wszystkich systemów, które go używają, przełączyć na niego ruch, a stary wycofać. Przy kluczach służących do weryfikacji starych danych, na przykład podpisów, stary klucz publiczny bywa jeszcze potrzebny przez pewien czas po zakończeniu używania klucza prywatnego ^[1].

RYS. 1Cykl rotacji klucza

OWASP zaleca, by w dokumentacji każdego sekretu opisać, jak się go rotuje, oraz które zależne systemy mogą przestać działać w trakcie rotacji ^[2]. Zaleca też ograniczanie udziału człowieka i automatyzację wymiany, bo ręczna obsługa sprzyja błędom ^[2].

Rodzaje

Rotacja planowa odbywa się w ustalonych odstępach. NIST podaje sugerowane okresy kryptograficzne dla różnych typów kluczy; wybrane zestawia tabela ^[1].

Rotacja wymuszona terminem ważności dotyczy certyfikatów. Głosowanie SC081v3 CA/Browser Forum przewiduje skrócenie maksymalnego okresu ważności certyfikatów TLS z 398 do 47 dni w latach 2026–2029 ^[6]. Przy tak krótkim terminie wymiana certyfikatów musi być zautomatyzowana.

Rotacja awaryjna następuje po wycieku albo jego podejrzeniu. NIST stanowi, że skompromitowany klucz traci ważność niezależnie od okresu kryptograficznego ^[1], a wszystkie skompromitowane klucze należy unieważnić i w razie potrzeby zastąpić ^[1]. OWASP wymaga, by nowy sekret dało się szybko utworzyć i wdrożyć, najlepiej automatycznie, a ujawnione klucze natychmiast unieważnić ^[2]. Organizacja powinna mieć plan odtwarzania po kompromitacji, obejmujący ponowne wygenerowanie kluczy ^[3].

W WordPressie

Najważniejszym obiektem rotacji w WordPressie są klucze bezpieczeństwa i sole w pliku wp-config.php. Dokumentacja wymienia osiem stałych: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY oraz odpowiadające im sole AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT ^[4]. Można je zmienić w dowolnej chwili, co unieważnia wszystkie istniejące ciasteczka logowania i zmusza użytkowników do ponownego zalogowania ^[4]. Nowe wartości najlepiej wygenerować oficjalnym generatorem WordPress.org ^[4].

// wp-config.php — fragment po rotacji (wartości z generatora, tu skrócone)
define( 'AUTH_KEY',        'nowa-losowa-wartosc...' );
define( 'SECURE_AUTH_KEY', 'nowa-losowa-wartosc...' );

Zmiana soli wylogowuje także atakującego, który ukradł ciasteczko sesji, co czyni ją standardowym krokiem po przejęciu sesji ^[4]. Nie zastępuje jednak zmiany haseł: kto zna hasło administratora, po prostu zaloguje się ponownie.

Poza wp-config.php rotacji wymagają klucze API bramek płatności, usług pocztowych i CDN zapisane w ustawieniach wtyczek, hasła aplikacji, hasło użytkownika bazy danych oraz klucze SSH do serwera. Ich przechowywanie opisuje zarządzanie sekretami.

Zagrożenia i skutki braku rotacji

Klucz, który nigdy nie jest wymieniany, chroni coraz więcej danych i ma coraz więcej okazji do wycieku. Wyciek odkryty późno oznacza długi okres, w którym atakujący może z niego korzystać. OWASP ujmuje cel rotacji wprost: skradzione dane uwierzytelniające mają działać tylko przez krótki czas ^[2].

Szczególnie groźny jest sekret zapisany w kodzie. Hasło zaszyte w kodzie trafia do repozytorium, kopii i historii zmian. OWASP zwraca uwagę, że usunięcie go z historii gita wymaga jej przepisania, co rodzi inne problemy ^[2]; dlatego po ujawnieniu sekretu jedyną pewną reakcją jest jego unieważnienie i wymiana.

Historia i przykłady

• Token w publicznym repozytorium. Sekurak opisał w lutym 2024 roku token GitHub Enterprise pracownika Mercedes-Benz, pozostawiony w publicznym repozytorium ^[8]. Według historii commitów token wyciekł pod koniec września 2023 roku, a unieważniono go dopiero 24 stycznia 2024 roku ^[8]. Autorzy podkreślali, że przechowywanie sekretów w repozytoriach utrudnia ich rotowanie i zarządzanie dostępem ^[8].
• Klucze DKIM i odtwarzanie wiadomości. W artykule o atakach DKIM replay sekurak zaleca rotowanie kluczy DKIM, na przykład co 6 miesięcy, i gotowość do ich natychmiastowego odwołania przy masowym ataku ^[7]. Opisany tam przypadek ProtonMaila pokazuje skalę problemu: w szczytowym momencie fałszywy ruch stanowił 98% poczty, którą Gmail odbierał jako pochodzącą z domeny protonmail.com ^[7]. Mechanizm opisuje hasło SPF / DKIM / DMARC (uwierzytelnianie poczty).
• Po przejęciu strony. CERT Polska po infekcji witryny rekomenduje zmianę wszystkich haseł i kluczy, do których atakujący mógł mieć dostęp: danych panelu hostingu, kont administratora CMS, haseł SSH i FTP, kluczy SSH oraz danych logowania użytkowników ^[5]. To rotacja awaryjna będąca częścią czyszczenia przejętej strony.