Rotacja kluczy API

czym to jest

Klucz API to dane uwierzytelniające, które dają programowy dostęp do systemu lub usługi. Zwykle to długi ciąg znaków generowany przez platformę i wykorzystywany przez aplikacje, skrypty lub integracje do uwierzytelniania bez procesu logowania użytkownika.

Klucze API dają dostęp bezpośrednio. Nie ma prośby o MFA. Nie ma sesji, która wygasa przy zamknięciu przeglądarki. Klucz jest ważny, dopóki nie zostanie odebrany. W wielu środowiskach klucze wygenerowane podczas konfiguracji są wciąż aktywne lata później, bo nikt nie ustalił harmonogramu rotacji i nic się nie zepsuło.

To samo dotyczy tokenów usługowych, danych uwierzytelniających usług OAuth i innych długowiecznych danych dostępu programowego. Wspólnym problemem jest to, że trwają, nie wymagają ponownego uwierzytelnienia i często nie są śledzone tak, jak konta użytkowników.

dlaczego się gromadzi

Klucze API są tworzone, żeby rozwiązać bieżący problem. Deweloper musi połączyć dwa systemy, więc generuje klucz. Konfigurowana jest integracja, dostaje token. Jednorazowy skrypt sięga do API, powstaje klucz zaszyty na stałe w kodzie.

Po utworzeniu klucz albo jest gdzieś przechowywany (plik konfiguracyjny, zmienna środowiskowa, secrets manager, jeśli środowisko go ma), albo zostaje zapomniany. W obu przypadkach działa tak długo, jak jest potrzebny, a potem działa dalej, gdy przestaje być potrzebny.

Brak harmonogramu rotacji to główna przyczyna strukturalna. Wiele platform domyślnie nie wymusza wygasania kluczy. Nie ma prośby o odnowienie, nie ma alertu, gdy klucz nie był rotowany od 12 miesięcy. Klucze, które działają, nie tworzą widocznych problemów, więc nikt ich nie rusza.

Brak inwentaryzacji to pogłębia. Zespoły mogą nie wiedzieć, ile kluczy istnieje, z czym są połączone ani kto je utworzył. Gdy ktoś odchodzi, jego klucze zwykle nie są uwzględniane w procesie offboardingu, bo nikt nie wie o ich istnieniu.

co to kosztuje

Wyeksponowany klucz API daje dostęp do dowolnego systemu, dla którego został wygenerowany. Jeśli klucz trafił do publicznego repozytorium kodu, został wklejony w wiadomości na czacie albo przechowywany w miejscu ze słabymi kontrolami dostępu, każdy, kto go znalazł, ma ten dostęp. Sam klucz nie odróżnia autoryzowanej aplikacji od nieautoryzowanej.

Bez inwentaryzacji nie da się szybko zareagować. Reagowanie na incydent z wyciekłym kluczem zaczyna się od pytań: który to był klucz, do czego miał dostęp i czy wciąż jest ważny? W środowiskach, gdzie klucze nie są śledzone, każde z tych pytań wymaga sporo czasu na dochodzenie.

Raport IBM Cost of a Data Breach (2025) podaje, że średni czas identyfikacji i opanowania naruszenia to 241 dni. Wyciekły klucz API bez inwentaryzacji i bez polityki rotacji może być aktywnie używany przez cały ten okres.

Jest też luka w offboardingu. Klucze utworzone przez byłych pracowników nie zawsze pojawiają się w procesie offboardingu. Konto pracownika w IdP jest zamykane. Jego klucze API, wciąż ważne, nie.

co działa

Wszystko zaczyna się od inwentaryzacji, bo klucza, o którym nikt nie wie, nie da się zrotować ani odebrać. Większość platform chmurowych i głównych narzędzi SaaS udostępnia stronę zarządzania kluczami API z listą każdego aktywnego klucza wraz z datą utworzenia, datą ostatniego użycia i kontem, które go utworzyło. Zebrane razem z różnych platform dane te odpowiadają na pytania, które liczą się w incydencie: ile kluczy istnieje, które są faktycznie używane i kto za każdy z nich odpowiada.

Daty ostatniego użycia wykonują większość analitycznej pracy. Klucz nieużywany od miesięcy to kandydat do odebrania. Jeśli system, któremu służył, wciąż działa, to albo używa innej ścieżki uwierzytelniania, albo w ogóle już nie działa, a klucz zwykle można wycofać po teście. Nazwiska twórców mają równie duże znaczenie. Klucze wygenerowane przez osoby, które od tego czasu odeszły z firmy, leżą poza każdym procesem offboardingu opartym na kontach w katalogu, a klucz z wysokimi uprawnieniami należący do odeszłego właściciela to najpilniejsza rzecz, jaką ta inwentaryzacja może ujawnić.

Rotacja na harmonogramie utrzymuje inwentaryzację rzetelną w czasie. Każdy aktywny klucz ma zdefiniowany okres rotacji i nazwanego właściciela, przy czym klucze o wysokich uprawnieniach, czyli wszystko z dostępem do zapisu lub uprawnieniami administracyjnymi, rotuje się częściej niż te tylko do odczytu. Harmonogram żyje w dokumentacji, nie w czyjejś pamięci, bo właśnie tam zgubiły się oryginalne klucze.

Krótkotrwałe tokeny biją to wszystko tam, gdzie platforma je wspiera. Token, który wygasa automatycznie, ogranicza okno ekspozycji z założenia, dlatego dojrzałe środowiska traktują długowieczne, statyczne klucze jako rozwiązanie zapasowe, nie domyślne.