Zarządzanie sekretami w pipeline'ach CI/CD systemów obronnych: Vault, HSM i rotacja kluczy

Każdy system oprogramowania obronnego zależy od sekretów: certyfikaty TLS uwierzytelniające tożsamości usług, klucze API autoryzujące dostęp do zewnętrznych usług, hasła do baz danych chroniące dane operacyjne, klucze szyfrowania chroniące informacje niejawne oraz klucze podpisywania kodu weryfikujące integralność oprogramowania układowego i kodu. Jeśli te sekrety są obsługiwane nieostrożnie — przechowywane w plikach konfiguracyjnych, umieszczane w repozytoriach kodu źródłowego, przekazywane jako zmienne środowiskowe w postaci jawnej lub pozostawiane bez zmian przez czas nieokreślony — stają się wektorami ataku obchodzącymi wszystkie inne mechanizmy kontroli bezpieczeństwa.

Zarządzanie sekretami w obronnych pipeline'ach CI/CD nie dotyczy przede wszystkim zapobiegania błędom deweloperów (choć to również). Chodzi o wdrożenie architektury bezpieczeństwa, w której sekrety nigdy nie istnieją w postaci jawnej poza kontekstem ich autoryzowanego użycia, gdzie każde użycie sekretu jest audytowane, gdzie sekrety mają zdefiniowany czas życia i są automatycznie rotowane, a kompromitacja dowolnego pojedynczego sekretu ma ograniczony promień rażenia dzięki krótkiemu czasowi wygaśnięcia i ograniczonemu dostępowi.

Typy sekretów w pipeline'ach obronnych

Obronne pipeline'y CI/CD spotykają się z szerszą gamą typów sekretów niż ich komercyjne odpowiedniki, ponieważ wdrażane przez nie systemy mają surowsze wymagania dotyczące kontroli dostępu i uwierzytelniania:

Certyfikaty TLS uwierzytelniają tożsamości usług we wdrożeniach mTLS i chronią komunikację sieciową. W obronnym klastrze Kubernetes z siatką usług każdy mikroserwis ma własny certyfikat — potencjalnie tysiące certyfikatów łącznie, wszystkie wymagające rotacji przed wygaśnięciem. Certyfikaty dla usług zewnętrznych muszą być podpisane przez autoryzowany CA; wewnętrzne certyfikaty usług mogą być podpisane przez wewnętrzny CA zarządzany przez Vault lub płaszczyznę sterowania siatki usług.

Klucze API i tokeny dostępu autoryzują wywołania między usługami, dostęp do zewnętrznych kanałów informacji o zagrożeniach, dostęp do SIEM API oraz integrację z backendami systemów niejawnych. Są to zazwyczaj statyczne sekrety (nie generowane dynamicznie) i najczęściej pojawiają się w repozytoriach kodu źródłowego przez błąd dewelopera.

Dane uwierzytelniające baz danych chronią dostęp do operacyjnych i niejawnych baz danych. Statyczne dane uwierzytelniające bazy danych — para nazwa użytkownika i hasło, która nigdy się nie zmienia — stanowią istotne ryzyko bezpieczeństwa: jeśli dane uwierzytelniające zostaną skompromitowane, dostęp pozostaje do czasu ręcznej rotacji, co może nie nastąpić przez miesiące lub lata. Dynamiczne dane uwierzytelniające z krótkim czasem życia są znacznie bezpieczniejsze.

Klucze podpisywania kodu służą do podpisywania wydań oprogramowania, obrazów kontenerów, pakietów oprogramowania układowego i pakietów konfiguracji. Klucze te są wyjątkowo wrażliwe — skompromitowany klucz podpisywania kodu pozwala atakującemu na podpisanie złośliwego kodu, któremu będą ufać wszystkie systemy ufające temu kluczowi. Klucze podpisywania kodu powinny być chronione przez sprzęt HSM i wymagać autoryzacji wielostronnej do użycia.

HashiCorp Vault: dynamiczne sekrety i dziennik audytu

HashiCorp Vault jest standardową platformą zarządzania sekretami dla obronnych środowisk DevSecOps. Vault zapewnia scentralizowane, auditowane repozytorium sekretów, ujednolicone API do pobierania sekretów oraz silnik dynamicznych sekretów, który generuje ograniczone czasowo, celowe dane uwierzytelniające zamiast wymagać od aplikacji przechowywania długotrwałych statycznych sekretów.

Dynamiczne sekrety są najpotężniejszą funkcją bezpieczeństwa Vault. Zamiast przechowywać statyczne hasło do bazy danych, które aplikacje pobierają, Vault dynamicznie generuje nowego użytkownika bazy danych z ograniczonymi czasowo danymi uwierzytelniającymi za każdym razem, gdy aplikacja żąda dostępu. Dane uwierzytelniające automatycznie wygasają, a użytkownik bazy danych jest odwoływany po upływie okresu dzierżawy (zazwyczaj 1–24 godziny). Atakujący, który przechwyci dynamiczne dane uwierzytelniające bazy danych, ma wąskie okno do ich wykorzystania przed wygaśnięciem; atakujący z statycznymi danymi uwierzytelniającymi ma nieograniczony dostęp do czasu ręcznej rotacji.

Silniki dynamicznych sekretów Vault obejmują PostgreSQL, MySQL, MSSQL, MongoDB, Cassandra, Elasticsearch (do zarządzania logami), PKI (wystawianie certyfikatów), AWS IAM (poświadczenia chmurowe) i inne. W środowiskach obronnych silnik sekretów PKI — który umożliwia Vault działanie jako pośredni CA wystawiający krótkotrwałe certyfikaty TLS na żądanie — jest szczególnie cenny: certyfikaty wystawiane z TTL 24 godzin eliminują okno nadużycia certyfikatu w przypadku jego kompromitacji.

Dziennik audytu Vault rejestruje każde wywołanie API do Vault: każde żądanie sekretu, każdą próbę uwierzytelnienia, każde wyszukiwanie polityki. Dziennik audytu jest tylko do dołączania i nie może być modyfikowany przez administratorów Vault. W środowiskach obronnych dziennik audytu dostarcza ślad dowodowy wymagany przez akredytację: kto uzyskał dostęp do jakiego sekretu, kiedy i z jakiego systemu. Dzienniki audytu Vault powinny być przekazywane do SIEM w celu korelacji ze zdarzeniami aplikacji i sieci.

Sprzętowe moduły bezpieczeństwa: gdy programowy Vault jest niewystarczający

HashiCorp Vault zabezpiecza własne klucze szyfrowania (klucz główny używany do odpieczętowania Vault i szyfrowania jego repozytorium sekretów) za pomocą programowego podejścia do szyfrowania kluczy. W większości środowisk jest to odpowiednie zabezpieczenie. W środowiskach obronnych z wymaganiami FIPS 140-2 poziom 3 — które dotyczą systemów bezpieczeństwa narodowego i systemów obsługujących niejawny materiał kryptograficzny — klucze główne muszą być chronione przez sprzęt, a nie oprogramowanie.

FIPS 140-2 poziom 3 wymaga fizycznego zabezpieczenia z dowodem ingerencji, uwierzytelniania opartego na tożsamości dla operatorów oraz krytycznych parametrów bezpieczeństwa (klucze prywatne), które nigdy nie są eksportowane w postaci jawnej. Programowe magazyny kluczy, niezależnie od tego, jak dobrze zaszyfrowane, nie spełniają tego wymagania, ponieważ sam klucz szyfrowania istnieje w pamięci oprogramowania, gdzie jest potencjalnie dostępny dla uprzywilejowanego atakującego oprogramowania.

Automatyczne odpieczętowywanie HSM dla Vault jest standardową architekturą: klucz główny Vault jest opakowany przez klucz HSM, a Vault automatycznie odpieczętowuje się, wysyłając swój opakowany klucz główny do HSM w celu odpakowania przy uruchomieniu. HSM wykonuje deszyfrowanie w swoich granicach odpornych na ingerencję — klucz główny nigdy nie istnieje w postaci jawnej poza HSM. Ta architektura spełnia wymagania FIPS 140-2 poziom 3 dla warstwy ochrony klucza głównego.

Obsługiwana integracja HSM dla HashiCorp Vault Enterprise obejmuje Thales (dawniej SafeNet) Luna, nCipher nShield, AWS CloudHSM i Azure Dedicated HSM. W izolowanych środowiskach obronnych wymagane są opcje HSM na miejscu (Thales Luna, nCipher nShield) — usługi HSM oparte na chmurze nie są dostępne z izolowanych sieci.

Rotacja kluczy bez przestoju

Rotacja kluczy — zastąpienie istniejącego klucza kryptograficznego nowym — jest niezbędna dla higieny bezpieczeństwa: ogranicza okno narażenia w przypadku kompromitacji klucza i spełnia regulacyjne wymagania dotyczące limitów czasu życia kluczy. Jednak rotacja kluczy wymagająca przestoju aplikacji lub złożonej ręcznej koordynacji jest często odkładana bezterminowo, niwecząc jej wartość bezpieczeństwa.

Wersjonowanie kluczy Vault umożliwia rotację bez przestoju dla sekretów i kluczy szyfrowania. Gdy silnik szyfrowania tranzytowego Vault (który zapewnia szyfrowanie jako usługę dla aplikacji) rotuje klucz, tworzy nową wersję klucza, zachowując starsze wersje do deszyfrowania danych zaszyfrowanych poprzednimi wersjami. Aplikacje szyfrujące nowe dane używają bieżącej wersji klucza; istniejący szyfrogramy mogą być nadal deszyfrowane przy użyciu starej wersji do czasu aktualizacji aplikacji w celu ponownego szyfrowania. Rotacja jest przezroczysta dla aplikacji — nie musi być wyłączana.

Okresy karencji dla rotacji certyfikatów pozwalają na stopniowe wdrażanie nowych certyfikatów: nowy certyfikat jest dystrybuowany i otrzymuje zaufanie przed unieważnieniem starego, tak aby nie było okna, w którym niektóre usługi mają nowy certyfikat, a inne jeszcze go nie otrzymały. Silnik sekretów PKI Vault obsługuje konfigurowanie TTL certyfikatów i okresów odnowienia w celu automatyzacji zarządzania tym okresem karencji.

Integracja CI/CD: wzorce wstrzykiwania sekretów

Sekrety muszą docierać do aplikacji i komponentów infrastruktury, które ich potrzebują, bez ujawniania ich w dziennikach pipeline'u CI/CD, zrzutach zmiennych środowiskowych lub warstwach obrazów kontenerów. Trzy wzorce integracji dominują w obronnych środowiskach CI/CD:

Sidecar agenta Vault (w Kubernetes) wdraża kontener Vault Agent obok kontenera aplikacji. Vault Agent uwierzytelnia się w Vault przy użyciu tożsamości konta usługi Kubernetes poda, pobiera skonfigurowane sekrety i zapisuje je do wspólnego wolumenu w pamięci lub wstrzykuje je do środowiska kontenera aplikacji. Sekrety nigdy nie pojawiają się w specyfikacji poda ani w obrazie kontenera — są wstrzykiwane w czasie wykonania z Vault.

External Secrets Operator to operator Kubernetes, który synchronizuje sekrety z zewnętrznych magazynów sekretów (Vault, AWS Secrets Manager, Azure Key Vault) do Kubernetes Secrets. Zapewnia deklaratywne, zgodne z GitOps podejście: zasób niestandardowy ExternalSecret w konfiguracji GitLab/Kubernetes deklaruje, jakie sekrety są potrzebne i skąd pochodzą; operator obsługuje pobieranie i synchronizację. Kubernetes Secrets utworzone przez operatora mogą być normalnie montowane w podach.

W przypadku pipeline'ów GitLab CI integracja GitLab-Vault (integracja GitLab CI/CD Vault przy użyciu uwierzytelniania JWT) pozwala zadaniom pipeline'u uwierzytelniać się w Vault przy użyciu ich tożsamości JWT GitLab i pobierać sekrety na czas trwania zadania pipeline'u. Sekrety są dostępne jako zmienne środowiskowe w ramach zadania i nigdy nie są przechowywane w konfiguracji GitLab CI ani repozytorium.