Jak zarządzać kluczami API i sekretami, żeby nie wyciekały?

Co liczy się jako sekret

Sekret to wszystko, czego system używa, żeby udowodnić swoją tożsamość albo odblokować dostęp bez wpisywania hasła przez człowieka za każdym razem. W praktyce masz do czynienia z czterema typowymi rodzajami.

Klucze API i tokeny. Długie ciągi znaków wydawane przez usługę, żeby twoje oprogramowanie mogło ją wywołać. Klucz do dostawcy wysyłki e-maili, token do CRM, personal access token do konta GitHub developera. Niektóre są ograniczone do jednej wąskiej akcji, inne mogą zrobić niemal wszystko, co może zrobić konto.

Hasła i connection stringi. Dane uwierzytelniające, których aplikacje używają, żeby dotrzeć do baz danych, kolejek wiadomości i wewnętrznych usług. Connection string do bazy danych często pakuje host, nazwę użytkownika i hasło w jedną linię, co czyni go szczególnie szkodliwym, jeśli wycieknie.

Klucze prywatne i certyfikaty. Materiał kryptograficzny stojący za certyfikatami TLS, dostępem SSH i podpisywaniem kodu. Klucz prywatny to ta połowa, która musi pozostać tajna. Jeśli wycieknie, atakujący może podszyć się pod twój serwer albo podpisać oprogramowanie tak, jakby był tobą.

Dane uwierzytelniające chmury i usług. Klucze dostępu do AWS, Azure czy Google Cloud oraz dane uwierzytelniające kont serwisowych, które pozwalają jednemu systemowi działać w imieniu drugiego. To zwykle cele o najwyższej wartości, bo pojedynczy klucz chmurowy może sięgnąć przez całe środowisko.

To, co łączy wszystkie cztery: są to dane uwierzytelniające typu bearer. Kto trzyma ciąg znaków, ten może go użyć. Zwykle nie ma drugiego składnika ani pytania „czy to na pewno ty”. Dlatego wyciek jest poważny i dlatego te dane uwierzytelniające zasługują na przynajmniej tyle samo troski, co ludzkie hasło.

Dlaczego sekrety to rosnące ryzyko

W ostatnich latach zmieniły się dwie rzeczy. Po pierwsze, oprogramowanie przeszło od monolitycznych aplikacji do wielu małych usług i integracji SaaS zszytych ze sobą przez API. Każda integracja potrzebuje własnych danych uwierzytelniających, więc liczba sekretów na firmę gwałtownie wzrosła. Wiele z nich należy do systemów, a nie do ludzi, dlatego często nazywa się je tożsamościami maszynowymi (NHI), i zwykle są długowieczne i słabo nadzorowane.

Po drugie, wolumen ujawnionych sekretów rośnie rok do roku. GitGuardian, firma, która skanuje publiczny kod pod kątem wyciekłych danych uwierzytelniających, publikuje coroczny raport State of Secrets Sprawl. Edycja 2026 znalazła 28 649 024 nowych sekretów dodanych do publicznych repozytoriów GitHub w 2025 roku, wzrost o 34% względem poprzedniego roku. Wcześniejsze edycje pokazują ten sam trend rosnący z roku na rok, od około 11 milionów w 2021 do 29 milionów w 2025.

To liczby z publicznego kodu, ta część problemu, którą da się zmierzyć z zewnątrz. Repozytoria wewnętrzne są gorsze: ten sam raport z 2026 roku znalazł, że są około sześć razy bardziej narażone niż publiczne na zawieranie zaszytego na sztywno sekretu, a około 32% zawiera przynajmniej jeden.

Ryzyko nie polega tylko na tym, że sekrety wyciekają. Polega na tym, że pozostają niebezpieczne. GitGuardian śledził sekrety po raz pierwszy ujawnione w 2022 roku i stwierdził, że 64% z nich wciąż było ważnych i możliwych do wykorzystania cztery lata później. Wyciekły klucz rzadko jest szybko sprzątany, bo jego odwołanie oznacza znalezienie każdego miejsca, gdzie jest używany, i zastąpienie go bez psucia produkcji. Więc wyciekłe sekrety się kumulują, a każdy z nich to stałe zaproszenie.

Powód, dla którego ma to znaczenie dla firmy twojej wielkości, jest ten sam, co dla dużych firm. Verizon 2024 Data Breach Investigations Report znalazł, że użycie skradzionych danych uwierzytelniających występowało w 31% naruszeń w ciągu poprzedniej dekady. Atakujący nie muszą wyważać drzwi, jeśli znajdą klucz pod wycieraczką.

Jak wyciekają sekrety

Wycieki rzadko są dramatyczne. Biorą się ze zwykłych skrótów, które w danym momencie wydają się nieszkodliwe. Oto te najczęstsze.

Zaszyte na sztywno w kodzie źródłowym. Developer wkleja klucz bezpośrednio do pliku, żeby coś zadziałało, planując posprzątać później. Sprzątanie nie następuje. Teraz sekret żyje w bazie kodu, widoczny dla każdego, kto ma do niej dostęp.

Commitowane do Gita. To najczęstsza i najbardziej uporczywa wersja zaszywania na sztywno. Kiedy sekret zostanie zacommitowany do repozytorium Git, usunięcie go z bieżącej wersji go nie usuwa. Git zachowuje pełną historię, więc sekret pozostaje w poprzednich commitach, chyba że sama historia zostanie przepisana. Jeśli to repozytorium kiedykolwiek stanie się publiczne, zostanie skopiowane na laptop kontraktora albo wypchnięte na prywatne konto, sekret idzie razem z nim. Asystenci kodowania AI pogorszyli tę sytuację: dane GitGuardian z 2026 roku pokazały, że commity wspomagane przez AI wyciekają sekrety mniej więcej dwa razy częściej niż bazowo.

Leżące w plikach konfiguracyjnych. Pliki konfiguracyjne, pliki środowiskowe takie jak .env, i szablony infrastruktury często zawierają prawdziwe dane uwierzytelniające. Trafiają do e-maili, są pakowane do backupów, kopiowane między maszynami i czasem przypadkiem trafiają do kontroli wersji.

Udostępniane w czacie i ticketach. Kiedy ktoś potrzebuje klucza, żeby coś przetestować, najszybszą drogą jest wklejenie go do Slacka, Teams albo ticketu w Jirze. Działa, a potem zostaje tam na stałe w przeszukiwalnym archiwum, które może przeczytać dużo więcej osób, niż powinno. Raport GitGuardian z 2026 roku znalazł, że około 28% wycieków bierze się całkowicie spoza repozytoriów kodu, w narzędziach do współpracy i produktywności, i że te wycieki są często poważniejsze, bo widzi je więcej osób.

Osadzone w artefaktach builda. Obrazy kontenerów, paczki aplikacji mobilnych i pakiety wdrożeniowe mogą nieść sekrety wypieczone podczas builda. Łatwo je przeoczyć, bo nikt nie otwiera ich ręcznie, ale dla atakującego zbadanie ich jest trywialne.

Sekrety wyciekają, bo wygodnie się je kopiuje, a niewygodnie śledzi. Kontrole poniżej działają, redukując liczbę miejsc, w których człowiek w ogóle musi dotknąć surowych danych uwierzytelniających.

Kontrole, które działają

Nie potrzebujesz wszystkich naraz od pierwszego dnia. Zacznij od pierwszych dwóch, które usuwają większość ekspozycji, a potem dokładaj kolejne.

Nigdy nie zaszywaj na sztywno

Najcenniejsza pojedyncza zasada: sekrety nigdy nie należą do kodu źródłowego. Kod powinien odwoływać się do sekretu po nazwie i pobierać jego wartość w czasie działania skądś spoza bazy kodu. W praktyce zwykle oznacza to odczyt ze zmiennej środowiskowej albo wywołanie managera sekretów przy starcie aplikacji. Kod mówi „daj mi hasło do bazy danych”, a wartość przychodzi skądinąd. Inżynierowie znają ten wzorzec; zadaniem lidera IT jest uczynić go niepodlegającym negocjacji oczekiwaniem, a nie miłym dodatkiem.

Używaj managera sekretów albo vaulta

Manager sekretów to dedykowany system, który przechowuje dane uwierzytelniające w formie zaszyfrowanej, kontroluje, kto i co może odczytać każdą z nich, i loguje każdy dostęp. Aplikacje żądają sekretów od niego w czasie działania, zamiast nosić własne kopie. Popularne opcje to natywne managery chmurowe, takie jak AWS Secrets Manager, Azure Key Vault i Google Secret Manager, oraz samodzielne narzędzia, takie jak HashiCorp Vault. Dla małego środowiska manager sekretów wbudowany w chmurę, której już używasz, jest zwykle najbardziej praktycznym punktem startowym.

Vault sam z siebie nie rozwiązuje problemu. Raport GitGuardian z 2025 roku odnotował, że niektóre repozytoria używające managera sekretów wciąż wyciekały sekrety, bo manager pomaga tylko przy sekretach faktycznie w nim przechowywanych. To dyscyplina umieszczania tam każdego sekretu sprawia, że to działa.

Ograniczaj zakres kluczy

Daj każdemu kluczowi minimalny dostęp, jakiego potrzebuje, i nic ponadto. Klucz, który tylko czyta listę mailingową, nie powinien też móc usuwać użytkowników. Kiedy tworzysz dane uwierzytelniające, ogranicz je pod względem uprawnień, a tam, gdzie usługa to wspiera, także pod względem źródłowego IP albo środowiska. Wąski zakres oznacza, że wyciekły klucz robi ograniczoną szkodę. Ułatwia też bezpieczną rotację, bo możesz wymienić jeden klucz zbudowany do konkretnego celu, nie dotykając tuzina niepowiązanych systemów.

Powiązany nawyk: wydawaj osobne dane uwierzytelniające dla każdej aplikacji i każdego środowiska. Dzielenie jednego klucza między staging i produkcję albo między trzy usługi zamienia każdą rotację w ryzykowne wydarzenie o szerokim blast radius, co jest jednym z powodów, dla których zespoły w ogóle unikają rotacji.

Rotuj je

Rotacja oznacza zastąpienie sekretu świeżą wartością według regularnego harmonogramu i natychmiast, kiedy podejrzewasz ekspozycję. Chodzi o to, żeby ograniczyć, jak długo dane uwierzytelniające są użyteczne. Jeśli klucz wyciekł sześć miesięcy temu, ale zrotowałeś go pięć miesięcy temu, wyciek jest już bezwartościowy.

Rotacja to kontrola, którą zespoły pomijają najczęściej, bo jest naprawdę trudna, kiedy sekrety są rozproszone i dzielone. To praktyczny argument za managerem sekretów i wąskim zakresem: kiedy każde dane uwierzytelniające żyją w jednym miejscu i służą jednemu celowi, rotacja staje się rutynowym działaniem, a nie hazardem na produkcji. Rotuj dane uwierzytelniające o wysokiej wartości, klucze chmurowe, hasła do baz danych, klucze podpisujące, według zdefiniowanego harmonogramu, a każdy sekret, który mógł zostać wystawiony, rotuj natychmiast.

Skanuj repozytoria pod kątem sekretów

Załóż, że mimo najlepszych zasad sekret czasem wyląduje w kodzie. Automatyczne skanowanie go złapie. Pomagają dwie warstwy. Sprawdzenie pre-commit albo pre-push na maszynach developerów blokuje sekret, zanim w ogóle dotrze do wspólnego repozytorium. Skan po stronie serwera na repozytorium łapie wszystko, co się prześlizgnęło, i cię alarmuje. Robią to skanery open source, takie jak Gitleaks i TruffleHog, własna push protection GitHuba i narzędzia komercyjne. Żaden skaner nie jest idealny; push protection w szczególności ma problem z generycznymi danymi uwierzytelniającymi, które nie mają rozpoznawalnego wzorca, więc traktuj skanowanie jako siatkę bezpieczeństwa, a nie gwarancję.

Kiedy skaner znajdzie zacommitowany sekret, pamiętaj, że usunięcie linii nie wystarczy. Sekret nadal jest w historii Gita, więc jedyną bezpieczną odpowiedzią jest odwołanie go i rotacja, a opcjonalnie także wyczyszczenie historii.

Odwołuj przy offboardingu i przy ekspozycji

Każdy sekret ma właściciela i cykl życia, a koniec tego cyklu to część, o której zapomina się najczęściej. Kiedy pracownik albo kontraktor odchodzi, odwołaj powiązane z nim personal access tokeny, klucze SSH i klucze API, tak samo jak wyłączyłbyś jego konto e-mail. Kiedy klucz zostaje wystawiony, najpierw go odwołaj, pytania zadaj potem. Odwołane dane uwierzytelniające są nieszkodliwe, bez względu na to, gdzie skończyły.

Tu opłaca się inwentarz. Nie da się odwołać czegoś, o czego istnieniu się nie wie. Nawet prosty rejestr tego, jakie sekrety istnieją, co każdy z nich odblokowuje, gdzie jest przechowywany i kto jest jego właścicielem, zamienia offboarding i reagowanie na incydenty ze zgadywania w listę kontrolną.

Ułożenie tego w rutynę

Kontrole wzajemnie się wzmacniają. Manager sekretów daje ci jedno miejsce do przechowywania, ograniczania zakresu, rotacji i odwoływania. Wąski zakres czyni rotację bezpieczną. Skanowanie łapie błędy, które się prześlizgują. Odwoływanie zamyka pętlę. Sensowna sekwencja startowa dla małego zespołu:

1. Zatrzymaj krwawienie: włącz skanowanie repozytoriów i sprawdzanie pre-commit, żeby żadne nowe sekrety nie trafiały do kodu.
2. Postaw managera sekretów, zaczynając od tego wbudowanego w twoją obecną chmurę, i przenieś do niego dane uwierzytelniające.
3. Zrób inwentarz tego, jakie sekrety istnieją i co każdy z nich odblokowuje.
4. Wydaj ponownie te o wysokiej wartości jako wąsko ograniczone klucze per aplikacja.
5. Ustaw harmonogram rotacji dla danych uwierzytelniających, które mają największe znaczenie.
6. Dodaj odwoływanie sekretów do swojej listy kontrolnej offboardingu.

Żaden z tych kroków nie jest sam w sobie duży. Zrobione po kolei, prowadzą cię od „nie mamy pojęcia, gdzie są nasze klucze” do stanu, w którym wyciekłe dane uwierzytelniające są niedogodnością, a nie naruszeniem.

Źródła

• State of Secrets Sprawl 2026, GitGuardian · https://www.gitguardian.com/state-of-secrets-sprawl-report-2026 (28 649 024 nowych sekretów w publicznych repozytoriach GitHub w 2025 roku, +34% rok do roku; 64% sekretów z 2022 roku wciąż ważnych cztery lata później; ~28% wycieków poza repozytoriami kodu; repozytoria wewnętrzne ~6 razy bardziej narażone na zawieranie sekretów; commity wspomagane przez AI wyciekają ~2 razy częściej niż bazowo)
• State of Secrets Sprawl 2025, GitGuardian · https://www.gitguardian.com/state-of-secrets-sprawl-report-2025 (trend narastania sekretów rok do roku; repozytoria używające managerów sekretów wciąż wyciekały sekrety; wyciekłe sekrety pozostają ważne przez lata)
• 2024 Data Breach Investigations Report, Verizon · https://www.verizon.com/business/resources/reports/dbir/ (użycie skradzionych danych uwierzytelniających wystąpiło w 31% naruszeń w ciągu poprzednich dziesięciu lat)