zarządzanie sekretami

Zarządzanie sekretami to kontrolowane przechowywanie, wydawanie, audytowanie i wymiana sekretów aplikacji: kluczy API, tokenów, haseł do baz danych, kluczy SSH i certyfikatów. Sekrety trafiają do dedykowanego systemu zamiast do kodu, plików konfiguracyjnych czy repozytorium. OWASP zwraca uwagę, że sekrety są dziś używane wszędzie, a wiele organizacji nadal trzyma je wprost w kodzie źródłowym i plikach konfiguracyjnych ^[1]. Zarządzanie sekretami jest odpowiedzią na ten problem.

Jak działa

Sekret ma swój cykl życia. OWASP wyróżnia w nim tworzenie, rotację, unieważnienie i wygaśnięcie ^[1]. Nowy sekret powinien być wygenerowany bezpiecznie i kryptograficznie wystarczająco silny do swojego celu ^[1]. Regularna rotacja sprawia, że skradzione poświadczenia działają tylko przez krótki czas ^[1].

RYS. 1Cykl życia sekretu

Centralny system sekretów wydaje sekret tylko uprawnionej aplikacji lub osobie i zapisuje, kto po niego sięgnął. OWASP zaleca, aby inżynierowie nie mieli dostępu do wszystkich sekretów, zgodnie z zasadą najmniejszych uprawnień ^[1]. Audyt powinien odpowiadać co najmniej na pytania, kto zażądał sekretu i dla jakiego systemu, kiedy go użyto oraz kiedy i przez kogo został zmieniony ^[1].

Najdalej idą sekrety dynamiczne. Aplikacja przy starcie prosi o dane do bazy i dostaje nowe, ważne tylko dla tej sesji ^[1]. Skradziony sekret szybko traci wtedy wartość.

Rodzaje sekretów

W WordPressie

Głównym magazynem sekretów WordPressa jest plik wp-config.php. Zawiera on nazwę bazy, użytkownika, hasło i host bazy danych w stałych DB_NAME, DB_USER, DB_PASSWORD i DB_HOST ^[3]. Są w nim też klucze bezpieczeństwa i sole. Dokumentacja radzi, by były długie, losowe i skomplikowane, najlepiej z generatora, i podaje, że ich zmiana unieważnia wszystkie istniejące ciasteczka, więc użytkownicy muszą zalogować się ponownie ^[3]. Przykładowych kluczy z dokumentacji nie należy używać ^[3].

Utwardzanie pliku wp-config.php (wp-config hardening) opisuje podręcznik utwardzania WordPressa. Plik można przenieść o jeden katalog wyżej niż instalacja, choć część specjalistów uważa, że daje to niewiele, a zrobione nieostrożnie może zaszkodzić ^[4]. Ważniejsze są uprawnienia plików: tylko właściciel i serwer WWW powinni móc czytać plik, co zwykle oznacza uprawnienia 400 albo 440 ^[4]. Użytkownik bazy do zwykłej pracy potrzebuje uprawnień SELECT, INSERT, UPDATE i DELETE ^[4].

Sekret nie musi być wpisany w pliku wprost. Na serwerach, które na to pozwalają, wp-config.php może czytać wartości ze zmiennych środowiskowych ustawionych poza katalogiem strony:

define( 'DB_PASSWORD', getenv( 'WP_DB_PASSWORD' ) );

Wtyczki przechowują klucze API usług zewnętrznych zwykle w tabeli opcji bazy danych. Wyciek bazy albo jej kopii ujawnia więc również te sekrety.

Zagrożenia i skutki

• Zaszyte w kodzie hasło. MITRE opisuje słabość CWE-798 jako produkt zawierający na stałe wpisane poświadczenia, takie jak hasło albo klucz kryptograficzny ^[2]. Gdy każda instalacja ma te same poświadczenia, możliwe są masowe ataki, na przykład robaki ^[2]. Naprawa po wdrożeniu wymaga zwykle łatki dla wszystkich użytkowników ^[2].
• Publicznie dostępne pliki wrażliwe, na przykład kopia pliku konfiguracyjnego albo zrzut bazy w katalogu strony.
• Sekrety w historii repozytorium. Usunięcie pliku w nowym commicie nie usuwa go z historii Git.
• Atak na potok CI/CD (CI/CD pipeline compromise), w którym napastnik czyta sekrety używane przy wdrożeniu.
• Błędy w samym systemie sekretów, który staje się celem o wysokiej wartości.

Dobre praktyki

• Trzymać sekrety poza kodem. MITRE zaleca przechowywanie ich w silnie chronionym, zaszyfrowanym pliku konfiguracyjnym albo bazie niedostępnej dla osób z zewnątrz ^[2].
• Nie wpisywać sekretów do definicji kontenerów. OWASP ostrzega, że sekrety w poleceniach Dockera ENV i ARG łatwo wyciekają razem z definicją obrazu ^[1].
• Wykrywać sekrety automatycznie. GitHub skanuje całą historię Git na wszystkich gałęziach w poszukiwaniu kluczy API, haseł i tokenów, a o wykrytych sekretach partnerów powiadamia ich wystawców, by mogli je unieważnić ^[5].
• Po wycieku najpierw unieważnić i wymienić sekret, potem usuwać go z miejsc, gdzie się pojawił, i zapisać przebieg zdarzenia ^[1]. Pomaga w tym ustalona rotacja kluczy.
• Rozważyć pułapki typu canary token, które alarmują przy próbie użycia fałszywego klucza.
• Hasła ludzi trzymać w menedżerze haseł, a nie w notatkach czy wiadomościach.

Historia i przykłady

Pod koniec września 2023 roku pracownik Mercedes-Benz zostawił w publicznym repozytorium token dostępu do firmowego serwera GitHub Enterprise; wykryli go badacze RedHunt Labs ^[6]. Token unieważniono 24 stycznia 2024 roku, po około czterech miesiącach ^[6]. Dawał dostęp do części repozytoriów z kodem źródłowym, między innymi oprogramowania pojazdów i narzędzi diagnostycznych ^[6].

11 sierpnia 2025 roku Sekurak opisał dziewięć podatności z numerami CVE w HashiCorp Vault, popularnym narzędziu do zarządzania sekretami, znalezionych przez badaczy firmy Cyata ^[7]. Najpoważniejsza, CVE-2025-6000, pozwalała atakującemu z uprawnieniami administratora aplikacji na zdalne wykonanie kodu ^[7]. Poprawki zawiera Vault Community Edition 1.20.1 ^[7].