Unieważnianie i rotacja ujawnionych sekretów

Gdy potwierdzisz wyciek danych uwierzytelniających, liczy się szybkość — ale także kolejność działań. Nagłe wyłączenie klucza może przerwać działanie środowiska produkcyjnego, jeśli wcześniej nie ustalisz, co jest od niego zależne.

Celem jest odcięcie atakującego przy jednoczesnym zachowaniu działania legalnych obciążeń, najlepiej w ramach jednej przećwiczonej sekwencji.

Pierwszym działaniem w przypadku wycieku klucza dostępu jest jego dezaktywacja, a nie usunięcie. Ustawienie statusu klucza na Inactive natychmiast uniemożliwia jego użycie.

Dotychczasowe zachowanie klucza (w stanie nieaktywnym) pozwala na jego wykorzystanie do korelacji forensycznej w CloudTrail. Usuń go dopiero po zakończeniu dochodzenia.

W przypadku legalnych zastosowań rotacja oznacza wydanie nowego klucza dostępu, zaktualizowanie każdego miejsca, w którym używano starego, a następnie dezaktywację przejętego klucza.

Taka kolejność zapobiega przestojowi: nowe dane uwierzytelniające działają, zanim stare zostaną wyłączone. Zawsze najpierw sprawdź, czy aplikacja działa z nowym kluczem.

Dezaktywacja klucza długoterminowego nie kończy tymczasowych danych uwierzytelniających, które mogły już zostać przez niego wygenerowane. W przypadku ról użyj funkcji IAM revoke sessions, która dołącza zasadę odmowy na podstawie czasu granicznego wystawienia tokenu.

Unieważnia to każdą aktywną sesję starszą niż wskazany moment i zatrzaskuje drzwi przed danymi uwierzytelniającymi, które znalazły się już w rękach atakującego.

Przed rotacją ustal, gdzie znajduje się sekret. CloudTrail pokazuje, które usługi i adresy IP używały klucza.

Sekret wpisany na stałe w wielu miejscach pokazuje dokładnie, dlaczego hardcoding jest niebezpieczny. Zmapowanie każdego użytkownika gwarantuje, że rotacja nie pozostawi zapomnianego uszkodzonego systemu ani kopii sekretu nadal wykorzystywanej w środowisku.

AWS Secrets Manager przechowuje sekrety, takie jak hasła do baz danych i klucze API, oraz może automatycznie rotować je zgodnie z harmonogramem za pomocą funkcji Lambda.

Automatyczna rotacja oznacza, że wycieknięty sekret ma krótki okres użyteczności, a aplikacje pobierają aktualną wartość w czasie działania zamiast przechowywać nieaktualną kopię wpisaną na stałe w kod.

Jeden wyciek danych uwierzytelniających często otwiera drogę do kolejnych. Jeśli atakujący użył klucza do odczytania bazy danych, hasła do tej bazy również mogły zostać przejęte.

Wykonaj rotację także sekretów zależnych. Prześledź cały łańcuch: każdy sekret, do którego atakujący mógł uzyskać dostęp, należy uznać za ujawniony i zastąpić.

Jeśli AWS wykryje ujawnienie klucza, może dołączyć do użytkownika AWSCompromisedKeyQuarantineV2, odmawiając dostępu do działań wysokiego ryzyka, a jednocześnie pozostawiając możliwość przeprowadzenia dochodzenia.

Nie odłączaj jej po prostu i nie przechodź dalej. Potraktuj ją jako sygnał, że nadal musisz przeprowadzić rzeczywiste działania naprawcze — dezaktywację, rotację i przegląd.

Rotacja zatrzymuje przyszłe nadużycia, ale nie cofa wcześniejszych szkód. Użyj CloudTrail, aby wyświetlić każde działanie wykonane przez przejęte dane uwierzytelniające.

Wycofaj złośliwe zmiany: usuń nieautoryzowanych użytkowników IAM, usuń klucze będące tylnymi furtkami i zlikwiduj zasoby utworzone przez atakującego. Ograniczenie skutków i sprzątanie to dwa oddzielne, niezbędne kroki.

Po odzyskaniu kontroli ogranicz przyszłe ryzyko. Zastąp klucze długoterminowe tymczasowymi danymi uwierzytelniającymi opartymi na rolach, włącz automatyczną rotację sekretów i dodaj skanowanie sekretów do potoku CI/CD.

Najskuteczniejsza poprawa ma charakter architektoniczny: jeśli nie istnieje statyczny sekret, który można wykraść, atakujący nie ma czego szukać.

Działania naprawcze nie są zakończone, dopóki nie zostaną udokumentowane. Zapisz, które dane uwierzytelniające poddano rotacji, co zrobił atakujący i jakie zmiany wycofano.

Powiadom interesariuszy wymienionych w runbooku, a jeśli ujawniono dane podlegające regulacjom, wypełnij obowiązki związane z powiadomieniem o naruszeniu. Przejrzysta dokumentacja zamienia incydent w lekcję i pozwala przejść późniejsze audyty.

Proszę wybrać właściwe pierwsze działanie.

Aby zareagować na wyciek danych uwierzytelniających, należy dezaktywować klucz dostępu (zachowując go do analizy kryminalistycznej), zmienić go na nowy bez przerywania działania usługi oraz unieważnić aktywne sesje ról, aby wyłączyć już wydane tymczasowe dane uwierzytelniające. Najpierw należy zidentyfikować wszystkich użytkowników klucza, zmienić sekrety w systemach zależnych, do których mógł uzyskać dostęp atakujący, oraz wycofać złośliwe zmiany na podstawie CloudTrail. Należy używać Secrets Manager do automatycznej rotacji i przejść na tymczasowe dane uwierzytelniające oparte na rolach, aby zapobiec powtórzeniu incydentu.