Zarządzanie sekretami — Vault, KMS i bezpieczna rotacja

Zarządzanie sekretami obejmuje hasła usługowe, tokeny, klucze API, certyfikaty i materiał kryptograficzny używany przez aplikacje. Sekret wpisany do repozytorium, obrazu kontenera albo zmiennej w publicznym pipeline może zostać skopiowany na lata — nawet jeśli później usuniemy go z bieżącej wersji kodu.

Bezpieczny system nie tylko przechowuje sekrety. Wydaje je właściwej tożsamości, na krótki czas, rejestruje użycie, rotuje bez przestoju i pozwala szybko unieważnić dostęp po incydencie.

Vault, KMS i secret manager — różne role

KMS zarządza kluczami szyfrującymi i operacjami kryptograficznymi. Aplikacja może poprosić o odszyfrowanie klucza danych bez uzyskania dostępu do klucza głównego. Secret manager przechowuje wartości takie jak hasło bazy lub token. System klasy Vault może dodatkowo generować dynamiczne, krótkotrwałe poświadczenia.

Nie szyfruj wszystkich sekretów jednym statycznym kluczem zapisanym obok aplikacji. Stosuj envelope encryption, osobne granice środowisk i politykę opartą na tożsamości workloadu.

Najpierw tożsamość, potem sekret

Aplikacja powinna uwierzytelnić się przez mechanizm platformy: rolę chmurową, Kubernetes ServiceAccount, workload identity albo certyfikat. Unikaj „sekretu startowego”, który musi zostać wpisany do konfiguracji, aby pobrać inne sekrety.

Każdy workload otrzymuje tylko potrzebne wartości. Usługa raportowa nie powinna czytać poświadczeń produkcyjnej administracji, a pipeline testowy nie potrzebuje kluczy produkcyjnych.

Krótki TTL i dynamiczne credentials

Dynamiczne poświadczenia są tworzone na żądanie, przypisane do konkretnej usługi i automatycznie wygasają. Skradziony token ważny 30 minut ma mniejszy blast radius niż hasło bazy niezmieniane od pięciu lat.

Nie każda integracja wspiera dynamikę. Dla sekretów statycznych ustal właściciela, termin rotacji, odbiorców i procedurę awaryjną. Rotacja musi być testowalna i wykonywana bez ręcznego logowania na dziesiątki serwerów.

Rotacja bez przerwy

Bezpieczny wzorzec używa okresu nakładania:

utwórz nową wersję sekretu;
udostępnij ją aplikacjom;
potwierdź, że wszystkie instancje przełączyły się;
unieważnij starą wersję;
monitoruj błędy i pozostaw kontrolowany rollback.

Jeśli konsument cache’uje sekret przez wiele godzin, sama zmiana w magazynie nie kończy rotacji. Potrzebny jest sygnał odświeżenia albo krótki cache TTL.

Sekrety w CI/CD i kontenerach

Nie zapisuj wartości w Dockerfile, warstwie obrazu, artefakcie, logu kompilacji ani pliku .env przesyłanym do repo. Pipeline powinien otrzymywać token przez federację tożsamości, a nie długowieczny klucz chmurowy.

Skanowanie sekretów w commitach jest potrzebne, ale wykryty klucz należy natychmiast unieważnić. Usunięcie go z historii Git nie cofa wcześniejszego odczytu. Zasady łańcucha dostaw opisujemy w przewodniku DevSecOps.

Monitoring i reakcja

Loguj tożsamość, nazwę sekretu, operację, czas i wynik — bez wartości sekretu. Alarmuj na masowy odczyt, dostęp z nowego środowiska, użycie administracyjne i próby pobrania sekretu innego tenanta.

Po wycieku:

unieważnij sekret i aktywne sesje;
ustal systemy, które mogły go skopiować;
przejrzyj logi użycia od momentu możliwej ekspozycji;
rotuj sekrety pochodne;
usuń przyczynę, np. nadmierne logowanie lub zbyt szeroką rolę;
zachowaj dowody dla planu reagowania na incydenty.

Checklista secrets management

Centralny magazyn zamiast sekretów w kodzie.
Workload identity bez statycznego bootstrap tokenu.
Minimalne polityki per aplikacja i środowisko.
Szyfrowanie, wersjonowanie i audyt.
Krótki TTL lub automatyczna rotacja.
Test wymiany bez przestoju i kontrolowany rollback.
Redakcja sekretów w logach, trace’ach i błędach.
Regularne skanowanie repozytoriów oraz obrazów.
Procedura awaryjnego unieważnienia.

Dobry magazyn nie naprawi złej architektury uprawnień. Największą wartość daje połączenie tożsamości workloadu, minimalnego dostępu, krótkiego życia i mierzalnej rotacji.

Rotacja bez przerwy i bez fałszywego sukcesu

Bezpieczna rotacja ma fazę nakładania: system akceptuje nowy i stary sekret przez krótki, kontrolowany czas, następnie klienci przechodzą na nowy, a stary zostaje unieważniony. Monitoruj użycie obu wersji, bo samo wygenerowanie klucza nie oznacza migracji aplikacji. Procedura awaryjna musi działać także wtedy, gdy główny vault lub control plane jest niedostępny.

Inwentaryzuj sekret razem z właścicielem, konsumentami, zakresem i maksymalnym czasem życia. Preferuj poświadczenia dynamiczne i tożsamość workloadu zamiast kopiowanych tokenów. Log nie może zawierać wartości sekretu, lecz powinien wskazywać, kto ją odczytał i do jakiego celu. Testuj unieważnienie na canary oraz skanuj repozytoria i obrazy po rotacji.

Źródła: NIST SP 800-57, OWASP Secrets Management, NIST SP 800-190.