Tajne zarządzanie

Tajne zarządzanie

1) Dlaczego i co dokładnie uważamy za „sekret”

Tajemnica - każdy materiał, którego ujawnienie prowadzi do kompromisu systemu lub danych: hasła, żetony API, klucze prywatne OAuth/JWT, klucze SSH, certyfikaty, klucze szyfrujące (KEK/DEK), klucze podpisu webhaka, bazy danych DSN/bufory, klucze dostawcy (płatności, dostawcy poczty/SMS), sole/pieprz ciasteczek, żetony bot/czat, licencje.
Sekrety żyją w kodzie, konfiguracji, środowisku, obrazach kontenerów, CI/CD, Terraform/Ansible, logs/dumps - zadanie zarządzania tajemnicami: konto → przechowywanie → dostawa → użycie → obrót → odpowiedź → audyt → wykorzystanie.

2) Zasady architektury

Centralizacja. Jedna warstwa zaufana (Vault/Cloud Secret Manager/KMS) do przechowywania, wydawania i audytu.
Najmniejsze przywileje (PoLP). Dostęp tylko do niezbędnych usług/ról, przez minimalny okres.
Krótkie życie. Preferowane są tajemnice dynamiczne/czasowe z TTL/leasingiem.
Kryptowaluta. Możliwość zmiany algorytmów/długości kluczy bez przestoju.
Oddzielenie tajemnic od kodu/obrazów. Żadnych haseł w repozytoriach, żadnych obrazów Dockera.
Obserwacja i audyt. Każda operacja wydawania/odczytu tajemnic jest rejestrowana i usuwana.
Automatyczna rotacja. Rotacja jest procesem rurociągu, a nie ręcznym działaniem.

3) Typowe rozwiązania i role komponentów

KMS/HSM. Zaufanie podstawowe, operacje szyfrowania/pakowania kluczy (koperta).
Sekretny menedżer/skarbiec. Tajny sklep wersji, ACL, audyt, tajemnice dynamiczne (DB, cloud-IAM, PKI), szablony obrotów.
PKI/CA. Wydawanie krótkotrwałych podpisów mTLS/SSH/JWT.
Agent/boczny. Dostarczanie tajemnic do czasu trwania (tmpfs, in-memory k/v, hot-reload files).
Kierowcy/operatorzy CSI. Integracja z Kubernetes (Secret Store CSI Driver, cert-manager).
Warstwa szyfrowania w Git. SOPS/wiek, git-crypt (dla kodu infrastruktury).

4) Klasyfikacja i polityka

• TTL/częstotliwość dzierżawy i rotacji;
• metoda wyjściowa (dynamika vs static), format, media;
• polityka dostępu (kto/gdzie/kiedy/dlaczego), mTLS i wymogi dotyczące wzajemnego uwierzytelniania;
• audyt (rejestrujemy, ile przechowujemy, kto ocenia);
• break-glass procedury i wspomnienia.

5) Tajny cykl życia

1. Tworzenie: poprzez API Secret Manager z metadanymi (właściciel, tagi, zakres).
2. Przechowywanie: zaszyfrowane (koperta: DEK owinięta KEK z KMS/HSM).
3. Dostawa: na wniosek upoważnionego podmiotu (OIDC/JWT, SPIFFE/SVID, mTLS).
4. Zastosowanie: wyłącznie w pamięci/w tmpfs; zakaz pozyskiwania drewna/dumpingów.

5. Rotacja: przez TTL lub wydarzenie (kompromis); Obsługa wersji równoległych (N-1)

6. Wycofanie/zablokowanie: natychmiastowe wygaśnięcie umowy najmu, wyłączenie konta/klucza w systemie docelowym.
7. Usuwanie: zniszczenie wersji/materiału, jasny łańcuch audytu.

6) Tajemnice dynamiczne (zalecane domyślnie)

• Poświadczenia bazy danych (Postgres/MySQL) z TTL 15-60 min.
• Tymczasowe klawisze chmury (AWS/GCP/Azure) według roli serwisowej.
• Certyfikaty SSH (5-30 minut), certyfikaty X.509 (godzina/dzień).
• Tymczasowy JWT do podpisywania wniosków, brokerów biletów sesyjnych.
• Plusy: minimalny promień wybuchu, uproszczone wycofanie (nic nie „pozostanie” na świecie).

7) Dostarczanie tajemnic w czasie trwania

• Secret Store CSI Driver → montaż tajemnic z menedżera zewnętrznego do kapsuły jako pliki (tmpfs).
• Unikaj Kubernetes Secret jako jedynego źródła (base64 „szyfrowanie”); W razie potrzeby należy włączyć dostawcę KMS dla etcd.
• Agent Sidecar (Vault Agent/Secrets Store) z auto-reneval leasing i hot-reload.
• VM/Bare-metal: agent systemowy + mTLS do Vault/Secret Manager, pamięć podręczna, minimalny TCB.
• Serverless: integracja w chmurze z przejrzystą wymianą tajemnic jako zmiennych/plików środowiskowych, ale unikaj długotrwałych envvars - najlepiej plików/w pamięci.

Przykład (Kubernetes + CSI, koncepcyjnie)

yaml apiVersion: v1 kind: Pod metadata: { name: app }
spec:
serviceAccountName: app-sa # is associated with a role in Secret Manager volumes:
- name: secrets csi:
driver: secrets-store. csi. k8s. io readOnly: true volumeAttributes:
secretProviderClass: app-spc containers:
- name: app volumeMounts:
- mountPath: /run/secrets name: secrets readOnly: true

8) Integracja CI/CD i IaC

CI: pracownicy otrzymują tokeny krótkotrwałe zgodnie z OIDC (Workload Identity). Zakaz „zamaskowanych” sekretów, które dostają się do dzienników; krok „wyciek skanu” (trufflehog/gitleaks).
CD: Deploy bierze sekrety w czasie wyświetlania, nie zapisuje ich do artefaktów.
IaC: Terraform przechowuje zmienne w Secret Manager; stan jest zaszyfrowany i dostęp jest ograniczony.
SOPS/age: dla repo - przechowywać zaszyfrowane manifesty, klucze - pod kontrolą KMS.

Przykład (fragment SOPS)

yaml apiVersion: v1 kind: Secret metadata: { name: app }
data:
PASSWORD: ENC[AES256_GCM,data:...,sops:...]
sops:
kms:
- arn: arn:aws:kms:...
encrypted_regex: '^(data    stringData)$'
version: '3. 8. 0'

9) Zasady dostępu i uwierzytelnianie obciążenia pracą

Identyfikacja obciążenia pracą: SPIFFE/SPIRE, Kubernetes SA → OIDC → IAM-рола, mTLS.
Tymczasowe żetony: krótki TTL, wąski zakres.
ABAC/RBAC w Secret Manager: „kto może odczytać sekret X w środowisku Y” jest oddzielony od „kto może tworzyć/obracać”.
Wielozadaniowość: oddzielne obszary nazw/pierścienie kluczy na najemcę; poszczególnych polityk i sprawozdawczości.

10) Obrót, wersje i kompatybilność

Oddziel tajny identyfikator i jego wersję ('secret/app/db # v17').
Obsługa dwóch aktywnych wersji (N i N-1) dla rotacji non-stop.
Rotacja jest oparta na zdarzeniach: na zwolnieniu, kompromisie, zmianie dostawcy, migracji algorytmów.
Zautomatyzuj: rotacja cron/backend w Vault/Secret Manager + wyzwalacze webhook do ponownego uruchomienia/reneval aplikacji.

Mini przepis „dwa klucze” rotacja webhook

text
T0: we publish two secrets in the provider: current, next
T1: the application starts accepting signatures by both current and next
T2: external system switches signature to next
T3: we do next -> current, re-release new next

11) Przechowywanie poza runtime: kopie zapasowe i artefakty

Nigdy nie dostać się do artefaktów (obrazy, archiwa dziennika, dumps).
Kopie zapasowe Secret Manager - szyfrowanie, klawisze pamięci masowej poza tą samą pętlą (rozdzielenie zadań).
Tagi i skany DLP: wykrywanie tajemnic w S3/Blob/GCS, Git, artefakty CI.

12) Obserwowalność, audyt i SLO

Metryki: liczba problemów/tajemnica/usługa, udział wygasłej leasingu, średni TTL, czas rotacji, czas konwergencji (sekundy/minuty przed „akceptacją” nowej wersji).
Dzienniki audytu: kto/co/kiedy/gdzie/dlaczego; przechowywanie oddzielnie, również zaszyfrowane.
SLO: 99% wyjście <200 ms; 0 wycieków w dziennikach; 100% tajemnic posiada właściciela/TTL/tagi; 100% tajemnic krytycznych - dynamiczny lub rotacyjny ≤ 30 dni.
Alerty: secret wygasa <7 dni (dla statycznych), kolec w uwierzytelniających awariach przechowywania, brak tajnych odczytów> N days (dead days), nieoczekiwane źródła geo/ASN.

13) Częste błędy i jak ich uniknąć

Sekrety w Git/obrazie. Użyj SOPS/wiek i skanery; polityka zakazu „gołych” linii.
Envvars jako medium długoterminowe. Daj pierwszeństwo plikom tmpfs/in-memory; oczyścić środowisko w widelcach/porzuciach.
Te same sekrety dla dev/stage/prod. Podziel przez środowisko.
Długotrwałe hasła statyczne. Przejdź do dynamicznego/krótkotrwałego.
Jeden klucz mistrzowski "dla wszystkiego. "Podziel przez najemcę/projekt/usługę.
Bez ładowania na gorąco. Aplikacja wymaga ponownego uruchomienia → okno luki podczas obrotu.

14) Przykłady integracji (schemat)

Skarbiec dynamiczny dostęp Postgres

hcl
Vault: role -> issues the user to the database with TTL 30m and privileges only to the app path "database/creds/app-role" {
capabilities = ["read"]
}
Application requests/database/creds/app-role -> receives (user, pass, ttl)

Podpis JWT wniosków (krótkoterminowy)

Klucz prywatny jest przechowywany w Secret Manager; usługa żąda krótkotrwałego znaku podpisania, a lokalny agent podpisuje ładunek (klucz nie jest przekazywany do aplikacji jako ciąg).

Certyfikaty SSH dla administratorów

Wydawanie SSH-cert przez 10 minut przez SSO (OIDC), bez dystrybucji kluczy stałych.

15) Bezpieczeństwo wokół krawędzi

Kłody/ścieżki/mierniki: sanitarniki, filtry dla znanych klawiszy/wzorów; „tajne” pola - maskowanie w APM.
Dumps/Crash Reports: Domyślnie Cut; w razie potrzeby - szyfrować i czyścić.
Aplikacje klienckie/mobilne: zminimalizuj sekrety offline, użyj pamięci masowej platformy (Keychain/Keystore), wiązanie urządzenia, TLS-pinning z walcowaniem awaryjnym.

16) Zgodność

PCI DSS: zabronić przechowywania PAN/tajemnic bez szyfrowania; ścisła kontrola dostępu i rotacja.

ISO 27001/SOC 2 - Zarządzanie aktywami, pozyskiwanie drewna, kontrola dostępu, wymagania dotyczące rekonfiguracji

RODO/lokalne organy regulacyjne: minimalizacja, dostęp w razie potrzeby, audyt.

17) Procesy i książka startowa

Uruchomienie

1. Spis tajemnic (repozytoria, CIs, obrazy, czas trwania, kopie zapasowe).
2. Klasyfikacja i tagi (właściciel, środowisko, najemca, rotacja-polityka).
3. Integracja skarbca/chmury SM + KMS/HSM.
4. Skonfiguruj wyjście przez identyfikację obciążenia pracą (OIDC/SPIRE).
5. Włącz tajemnice dynamiczne dla DB/Cloud/PKI.
6. Automatyczny obrót i przeładowanie na gorąco; wpisy o wygaśnięciu.
7. Konfiguracja skanerów wycieków i katalogu danych/ET.

Scenariusze awaryjne

Podejrzewany wyciek: lista zatrzymania dostępu, natychmiastowa rotacja, cofnięcie certyfikatów/kluczy, ponowne wydanie żetonów, umożliwienie zwiększonego audytu, RCA.
Secret Manager nie jest dostępny: lokalny pamięć podręczna w pamięci z niskim TTL, degradacja funkcji, ograniczenie nowych połączeń, ręczny break-glass kroki.
Kompromis klucza głównego: regeneracja hierarchii kluczy, ponowne opakowanie wszystkich DEK, sprawdzenie wszystkich ekspozycji dla okna ryzyka.

18) Listy kontrolne

Przed sprzedażą

• Sekrety usunięte z kodu/obrazów; włączone skanery przecieków.
• Mechanizmy dynamiczne są dostępne dla tajemnic krytycznych.
• Dostawa za pośrednictwem sidecar/CSI/tmpfs z hot-reload, bez trwałych envvars.
• Skonfigurowane zasady IAM/ABAC, związane z tożsamością obciążenia pracą.
• Automatyczne obracanie i wersje podwójne (N, N-1) dla kompatybilności.
• Włączone mierniki/wpisy/audyty; przeszedł testy degradacji.

Operacja

• Raport miesięczny: właściciele, TTL, utracone tajemnice, nieużywane.
• Okresowe badania rotacyjne i penetracyjne ścieżek wycieków (kłody, porzucenia, artefakty).
• Plan crypto-zwinności i awaryjna wymiana CA/korzeni.

19) FAQ

P: Czy Secret Manager bez KMS wystarczy?
Odp.: Dla poziomu podstawowego - tak, ale lepiej jest używać szyfrowania koperty: KEK w KMS/HSM, tajemnice - owinięte. Upraszcza to informacje zwrotne i zgodność.

P: Co wybrać - statyczna lub dynamiczna?
Odp.: Domyślna jest dynamika. Pozostaw statyczne tylko tam, gdzie nie ma obsługiwanych dostawców, i spalić TTL do dni/godzin + automatyczny obrót.

P: Jak bezpiecznie wrzucać sekrety do mikroservice?
А: Tożsamość Workload → mTLS бSecret Manager → sidecar/CSI → масла tmpfs + hot-reload. Żadnych kłód, żadnych envvarów „na zawsze”.

P: Czy mogę zachować tajemnice w Kubernetes Secret?
Odp.: Tylko z włączonym szyfrowaniem etcd z dostawcą usług KMS i rygorystycznymi zasadami. Preferuje zewnętrzne przechowywanie i CSI.

P: Jak „crypto-erase” dostęp najemcy?
Odp.: Cofnij/zablokuj swoją politykę w Secret Managerze, unieważnij wszystkie dzierżawy, kluczową rotację/regenerację; przy użyciu KMS - wyłączyć rozpakowanie odpowiedniego KEK.

• „W odpoczynku szyfrowanie”
• „W szyfrowaniu tranzytu”
• „Kluczowe zarządzanie i rotacja”
• „Uwierzytelnianie S2S”
• „Podpisz i zweryfikuj żądania”