Cyber Security Academy · Lekcja

Magazyny i przechowalnie sekretów

Centralizowanie sekretów za pomocą narzędzi takich jak Vault

Magazyny i przechowalnie sekretów to bezpłatna lekcja Cyber Security Academy na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cyber Security Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Co rozwiązuje magazyn sekretów

Magazyn sekretów (lub sejf) to scentralizowana, wzmocniona usługa, której jedynym zadaniem jest przechowywanie sekretów oraz kontrolowanie i audytowanie dostępu do nich. Zastępuje rozproszone pliki i zmienne środowiskowe powodujące rozprzestrzenianie się sekretów.

Dobry menedżer sekretów zapewnia cztery podstawowe funkcje:

Centralne przechowywanie — jedno autorytatywne źródło prawdy.
Kontrola dostępu — szczegółowe zasady określające, kto i co może odczytać.
Rejestrowanie audytowe — zapis każdego dostępu na potrzeby reagowania na incydenty.
Szyfrowanie — sekrety są szyfrowane podczas przechowywania i przesyłania.

Przykłady obejmują HashiCorp Vault, AWS Secrets Manager, Azure Key Vault i GCP Secret Manager.

Jak zbudowany jest HashiCorp Vault

HashiCorp Vault to popularny menedżer sekretów o otwartym kodzie źródłowym. Organizuje funkcje w modułowe silniki sekretów montowane pod ścieżkami.

Silnik KV przechowuje statyczne sekrety w formacie klucz-wartość.
Silnik Database generuje dynamiczne, krótkotrwałe dane uwierzytelniające do baz danych.
Silnik PKI wystawia certyfikaty TLS na żądanie.
Silnik Transit zapewnia szyfrowanie jako usługę bez ujawniania kluczy.

Z Vault można korzystać za pośrednictwem interfejsu HTTP API lub CLI. Każda ścieżka podlega zasadom określającym, kto może w niej odczytywać lub zapisywać dane.

# Enable a KV v2 secrets engine at the 'secret/' path
vault secrets enable -path=secret kv-v2

# Write and read a static secret
vault kv put secret/app/db password='S3cr3t' user='app'
vault kv get secret/app/db

Model seal/unseal

Vault chroni swoje dane za pomocą mechanizmu seal/unseal. Po uruchomieniu Vault jest zapieczętowany — zna lokalizację zaszyfrowanych danych, ale nie może ich odszyfrować.

Klucz główny, który odszyfrowuje dane przechowywane w systemie, jest szyfrowany kluczem unseal. Dzięki mechanizmowi Shamir's Secret Sharing klucz unseal zostaje podzielony na wiele fragmentów, które są rozdzielane między różnych operatorów.

Aby odtworzyć klucz i odpieczętować Vault, należy dostarczyć konfigurowalny próg (na przykład 3 z 5 fragmentów). Żadna pojedyncza osoba nie może odpieczętować Vault samodzielnie, co chroni przed przejęciem przez osobę wewnątrz organizacji.

# Initialize Vault: 5 key shares, threshold of 3 to unseal
vault operator init -key-shares=5 -key-threshold=3

# Each operator supplies one shard until threshold is met
vault operator unseal <shard-1>
vault operator unseal <shard-2>
vault operator unseal <shard-3>

Uwierzytelnianie: kim jesteś

Przed odczytaniem dowolnego sekretu klient musi się uwierzytelnić, aby uzyskać token. Vault obsługuje wiele metod uwierzytelniania dostosowanych do różnych tożsamości:

AppRole dla aplikacji i systemów CI (role ID + secret ID).
Kubernetes wykorzystuje token konta usługi poda.
AWS/GCP/Azure IAM ufa tożsamości platformy chmurowej.
OIDC/LDAP dla użytkowników poprzez SSO.

Najważniejsza zasada brzmi: tożsamość pochodzi z platformy, a nie z długotrwałego hasła. Pod Kubernetes potwierdza swoją tożsamość za pomocą własnego tokenu konta usługi, więc nie ma sekretu rozruchowego, który mógłby wyciec.

# App authenticates via AppRole to receive a token
vault write auth/approle/login \
  role_id="db-app-role" \
  secret_id="$WRAPPED_SECRET_ID"
# Response includes client_token used for subsequent reads

Autoryzacja za pomocą zasad

Uwierzytelnianie potwierdza tożsamość, a zasady określają, co dana tożsamość może robić. Zasady Vault są zapisane w HCL i stosują zasadę najmniejszych uprawnień — przyznają wyłącznie dostęp do ścieżek i możliwości wymaganych przez dane obciążenie.

Ta zasada umożliwia usłudze odczyt wyłącznie własnego sekretu bazy danych i niczego więcej:

Możliwości odpowiadają czasownikom API: read, create, update, delete i list. Należy domyślnie odmawiać dostępu i przyznawać go jawnie.

# policy: billing-app.hcl
path "secret/data/billing/*" {
  capabilities = ["read"]
}
path "database/creds/billing-readonly" {
  capabilities = ["read"]
}
# everything else is implicitly denied

Chmurowe magazyny sekretów

Jeśli system działa w jednej chmurze, zarządzany magazyn dostawcy eliminuje obciążenia operacyjne — nie ma potrzeby obsługi seal/unseal ani serwerów wymagających aktualizacji:

AWS Secrets Manager integruje się z IAM i obsługuje wbudowane funkcje Lambda do rotacji.
Azure Key Vault przechowuje sekrety, klucze i certyfikaty oraz obsługuje RBAC.
GCP Secret Manager zapewnia wersjonowane sekrety chronione przez powiązania IAM.

Dostęp jest kontrolowany przez system IAM chmury, więc obciążenie odczytuje sekret za pomocą istniejącej roli — bez osobnego hasła. Kompromisem jest uzależnienie od dostawcy i słabsza obsługa wielu chmur w porównaniu z Vault.

# Read a secret from AWS Secrets Manager (workload uses its IAM role)
aws secretsmanager get-secret-value \
  --secret-id prod/billing/db \
  --query SecretString --output text

# GCP equivalent
gcloud secrets versions access latest --secret=billing-db

Szyfrowanie jako usługa

Czasami nie trzeba w ogóle przechowywać sekretu — zamiast tego można szyfrować dane aplikacji, nie pozwalając aplikacji na bezpośredni dostęp do klucza szyfrującego. Właśnie do tego służy silnik Transit w Vault.

Aplikacja wysyła do Vault tekst jawny, otrzymuje szyfrogram i nigdy nie widzi klucza. Odszyfrowywanie działa tak samo. Nazywa się to szyfrowaniem jako usługą.

Korzyść jest taka, że klucze znajdują się wyłącznie wewnątrz Vault, można nimi centralnie zarządzać i przeprowadzać ich rotację, a przejęta aplikacja nie może ujawnić klucza, którego nigdy nie posiadała.

# Encrypt data without the app ever seeing the key
vault write transit/encrypt/orders-key \
  plaintext=$(echo -n 'card=4111...' | base64)
# returns: ciphertext=vault:v1:abc123...

# Decrypt later
vault write transit/decrypt/orders-key ciphertext='vault:v1:abc123...'

Wstrzykiwanie sekretów do obciążeń

Magazyn sekretów jest użyteczny tylko wtedy, gdy aplikacje mogą korzystać z sekretów bez zapisywania na stałe ścieżki lub tokenu. Typowe sposoby wstrzykiwania:

Sidecar/agent — Vault Agent działa obok aplikacji, uwierzytelnia się i zapisuje sekrety we współdzielonym wolumenie w pamięci.
CSI driver — Kubernetes montuje sekrety jako pliki za pośrednictwem sterownika Secrets Store CSI.
Pobieranie przez SDK — aplikacja bezpośrednio wywołuje API magazynu sekretów podczas uruchamiania.

Należy preferować montowanie w systemie plików w pamięci (tmpfs) zamiast używania zmiennych środowiskowych oraz unikać zapisywania sekretów na dysku, gdzie mogą pozostać.

# Vault Agent template renders a secret to an in-memory file
template {
  contents = "DB_PASS={{ with secret \"secret/app/db\" }}{{ .Data.data.password }}{{ end }}"
  destination = "/run/secrets/db.env"
}

Rejestrowanie audytowe i rozliczalność

Każde zdarzenie odczytu, zapisu i uwierzytelniania w magazynie sekretów powinno być rejestrowane w dzienniku audytowym. To właśnie umożliwia uzasadnienie sposobu zarządzania sekretami podczas incydentu.

Dzienniki audytowe odpowiadają na kluczowe pytania: kto uzyskał dostęp do którego sekretu, kiedy i skąd. Vault hashuje wrażliwe wartości w dziennikach, aby sam dziennik nie ujawniał sekretów.

Należy przesyłać dzienniki audytowe do oddzielnego systemu odpornego na manipulacje (SIEM), aby atakujący, który przejmie hosta magazynu, nie mógł również usunąć dowodów wskazujących, do czego uzyskał dostęp.

# Enable a file audit device (HMAC-hashes secret values)
vault audit enable file file_path=/var/log/vault/audit.log

# Forward to a SIEM/syslog endpoint for tamper resistance
vault audit enable syslog tag="vault" facility="AUTH"

Ochrona samego magazynu sekretów

Scentralizowany magazyn koncentruje ryzyko — jeśli magazyn upadnie, upada wszystko. Należy zabezpieczyć go jako najważniejszy zasób:

Należy używać TLS na wszystkich punktach końcowych; nigdy nie należy udostępniać niezaszyfrowanego API.
Magazyn należy utrzymywać w prywatnej sieci, za ścisłymi regułami zapory sieciowej.
Należy włączyć auto-unseal za pośrednictwem chmurowego KMS, aby uniknąć ręcznego zarządzania fragmentami klucza, ale trzeba ściśle chronić ten klucz KMS.
Należy używać krótkich wartości TTL tokenów i odnawialnych dzierżaw, aby skradzione tokeny szybko traciły ważność.
Należy niezwłocznie instalować poprawki i monitorować dzienniki audytowe pod kątem anomalii.

Magazyn zamienia wiele punktów awarii na jeden, za to wyjątkowo dobrze chroniony.

Wybór właściwego magazynu

Nie ma jednego najlepszego narzędzia — magazyn należy dopasować do środowiska:

Jedna chmura, proste potrzeby — należy użyć natywnego menedżera (AWS/Azure/GCP), aby ograniczyć narzut operacyjny do minimum.
Wiele chmur lub środowisko on-prem — HashiCorp Vault zapewnia spójną, przenośną abstrakcję.
Potrzeba dynamicznych sekretów lub szyfrowania jako usługi — silniki Vault oferują największe możliwości.
Środowisko intensywnie wykorzystujące Kubernetes — należy połączyć magazyn ze sterownikiem CSI lub operatorem, takim jak External Secrets.

Niezależnie od wyboru cel pozostaje ten sam: jedno audytowane źródło prawdy z kontrolą dostępu, zastępujące rozproszone sekrety w postaci zwykłego tekstu.

Szybki test

Sprawdź swoją wiedzę na temat modelu ochrony Vault.

Podsumowanie: Vault i magazyny sekretów

Nauczyłeś się, jak zastąpić rozproszone sekrety centralnym, audytowanym magazynem.

Magazyn sekretów zapewnia centralne przechowywanie, kontrolę dostępu, rejestrowanie audytowe i szyfrowanie.
HashiCorp Vault korzysta z wymiennych silników sekretów oraz modelu seal/unseal chronionego przez Shamir's Secret Sharing.
Metody uwierzytelniania ustalają tożsamość na podstawie platformy (Kubernetes, IAM, AppRole), a zasady egzekwują minimalne uprawnienia.
Natywne magazyny chmurowe (AWS, Azure, GCP) rezygnują z przenośności na rzecz niskiego narzutu operacyjnego.
Silnik Transit udostępnia szyfrowanie jako usługę, dzięki czemu aplikacje nigdy nie przechowują kluczy.
Należy wstrzykiwać sekrety za pomocą agentów lub CSI do magazynu w pamięci, rejestrować każdy dostęp i zabezpieczać magazyn jako najważniejszy zasób.

Następnie zwiększymy bezpieczeństwo sekretów, generując je dynamicznie i nadając im krótki czas życia.

Często zadawane pytania

Czy lekcja „Magazyny i przechowalnie sekretów” jest bezpłatna?

Tak — pełny tekst „Magazyny i przechowalnie sekretów” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cyber Security Academy, przejdź na CoddyKit PRO. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Magazyny i przechowalnie sekretów”?

Centralizowanie sekretów za pomocą narzędzi takich jak Vault Ćwiczysz Cyber Security Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Cyber Security Academy?

Nie wymagamy żadnego doświadczenia. Cyber Security Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.

Ile czasu zajmuje lekcja „Magazyny i przechowalnie sekretów”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Cyber Security Academy?

Tak. Każda lekcja Cyber Security Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

← Powrót do Cyber Security Academy