Cyber Security Academy · Lekcja

Dynamiczne sekrety i dzierżawienie

Krótkotrwałe dane uwierzytelniające wygasające automatycznie

Dynamiczne sekrety i dzierżawienie to bezpłatna lekcja Cyber Security Academy na CoddyKit. To lekcja 3 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.

Sekrety statyczne a dynamiczne

Sekret statyczny jest tworzony raz i używany bezterminowo — na przykład to samo hasło do bazy danych, współdzielone przez dziesięć usług przez lata. Sekrety statyczne są domyślnym rozwiązaniem i zarazem problemem: mają długi czas życia, są szeroko współdzielone i trudno je rotować.

Sekret dynamiczny jest generowany na żądanie, unikalny dla jednego odbiorcy i automatycznie wygasa. Zamiast przechowywać hasło, magazyn tworzy zupełnie nowe dane uwierzytelniające za każdym razem, gdy są żądane.

Ta jedna zmiana rozwiązuje najtrudniejsze problemy związane z zarządzaniem sekretami: rotacja staje się automatyczna, a promień rażenia każdego wycieku zmniejsza się niemal do zera.

Jak działają sekrety dynamiczne

Sekrety dynamiczne wymagają, aby magazyn miał uprzywilejowany dostęp do systemu backendowego. Przepływ dla bazy danych wygląda następująco:

Administrator konfiguruje magazyn, podając główne poświadczenie DB i szablon tworzenia.
Aplikacja uwierzytelnia się i żąda poświadczenia.
Magazyn wykonuje w bazie danych polecenie CREATE USER, zwracając nową nazwę użytkownika i hasło.
Po wygaśnięciu dzierżawy magazyn automatycznie wykonuje polecenie DROP USER.

Aplikacja nigdy nie widzi długoterminowego hasła — otrzymuje tymczasowe dane uwierzytelniające powiązane z jej tożsamością i dzierżawą.

# Configure Vault's database engine with a creation statement
vault write database/roles/billing-readonly \
  db_name=appdb \
  creation_statements="CREATE ROLE \"{{name}}\" LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON billing TO \"{{name}}\";" \
  default_ttl="1h" max_ttl="24h"

Żądanie dynamicznych danych uwierzytelniających

Gdy aplikacja potrzebuje dostępu do bazy danych, prosi magazyn o dane uwierzytelniające. Odpowiedź zawiera unikalną, świeżo utworzoną nazwę użytkownika i hasło oraz dzierżawę określającą czas ich ważności.

Każdy odbiorca otrzymuje własne dane uwierzytelniające. Jeśli uruchomią się dwa pody tej samej usługi, otrzymają dwie różne nazwy użytkowników, co umożliwia audytowanie poszczególnych odbiorców na poziomie bazy danych.

vault read database/creds/billing-readonly

# Example response:
# lease_id     database/creds/billing-readonly/abc123
# lease_duration  1h
# password     A1b-2Cd3-temp-xyz
# username     v-approle-billing-9f3a2

Dzierżawy: kontrakt czasu życia

Dzierżawa to umowa określająca, jak długo dany sekret pozostaje ważny. Każdy dynamiczny sekret ma wartość TTL (czas życia) oraz opcjonalny max TTL.

default_ttl — czas, przez który poświadczenie pozostaje ważne przed wygaśnięciem.
max_ttl — bezwzględny limit czasu, nawet w przypadku odnowień.

Po wygaśnięciu dzierżawy magazyn unieważnia poświadczenie — aktywnie usuwa użytkownika bazy danych. Wygaśnięcie nie jest tylko flagą; uruchamia rzeczywiste czyszczenie. Dzięki temu wyciek dynamicznych sekretów sam się naprawia: skradzione poświadczenie staje się bezużyteczne w czasie określonym przez TTL.

Odnawianie i unieważnianie dzierżaw

Długotrwałe aplikacje, działające dłużej niż dzierżawa, muszą odnowić ją przed wygaśnięciem. Odnowienie wydłuża TTL aż do wartości max TTL, po czym aplikacja musi zażądać nowych danych uwierzytelniających.

Operatorzy mogą również natychmiast unieważnić dzierżawę — to wyłącznik awaryjny podczas incydentu. Unieważnienie dzierżawy od razu usuwa powiązane poświadczenie, niezależnie od pozostałego TTL.

Można nawet unieważnić wszystkie dzierżawy pod danym prefiksem, aby natychmiast odciąć całą usługę lub środowisko.

# Renew a lease before it expires
vault lease renew database/creds/billing-readonly/abc123

# Revoke a single lease immediately (incident kill switch)
vault lease revoke database/creds/billing-readonly/abc123

# Revoke every lease under a path prefix
vault lease revoke -prefix database/creds/billing-readonly

Poza bazami danych

Sekrety dynamiczne nie ograniczają się do baz danych. Vault i podobne narzędzia generują krótkotrwałe dane uwierzytelniające dla wielu systemów:

Cloud IAM — tymczasowe klucze dostępu AWS/GCP/Azure uzyskiwane za pomocą mechanizmu assume-role w stylu STS.
SSH — podpisane, krótkotrwałe certyfikaty SSH zamiast statycznych kluczy.
PKI/TLS — certyfikaty wydawane na żądanie i ważne przez krótki czas.
RabbitMQ, MongoDB, Consul — efemeryczne dane uwierzytelniające usług.

Wszędzie obowiązuje ten sam schemat: zażądaj, używaj krótko, pozwól na automatyczne wygaśnięcie. Statyczne, długoterminowe klucze chmurowe są częstym źródłem naruszeń bezpieczeństwa; dynamiczne dane uwierzytelniające IAM eliminują ten problem.

# Generate temporary AWS credentials scoped to a role
vault read aws/creds/deploy-role
# returns short-lived access_key, secret_key, security_token

# Sign an SSH key for short-lived access (valid minutes, not forever)
vault write ssh/sign/admin public_key=@id_ed25519.pub ttl=15m

Dlaczego sekrety dynamiczne ograniczają promień rażenia

Rozważmy wyciek poświadczenia w każdym z modeli:

Statyczne — hasło pozostaje ważne do chwili, gdy człowiek je zauważy, obróci i zaktualizuje u każdego odbiorcy. Okres narażenia trwa dni lub miesiące.
Dynamiczne — poświadczenie wygasa w czasie TTL (często od kilku minut do godziny), a ponadto jest przypisane do jednego odbiorcy i ma minimalne uprawnienia. Okres narażenia jest bardzo krótki, a szkody ograniczone.

Sekrety dynamiczne zmieniają rotację z bolesnego, ręcznego projektu w automatyczną i ciągłą właściwość systemu.

Kompromis związany z poświadczeniem głównym

Sekrety dynamiczne są potężnym rozwiązaniem, ale wymagają, aby magazyn przechowywał wysoce uprzywilejowane poświadczenie root dla każdego backendu, w którym może tworzyć użytkowników odpowiadających wydawanym poświadczeniom. Koncentruje to ryzyko w magazynie.

Sposoby ograniczenia ryzyka:

Należy rotować samo główne poświadczenie, aby nawet magazyn nie przechowywał pierwotnego hasła administratora.
Zakres uprawnień konta root należy ograniczyć dokładnie do tych potrzebnych do tworzenia i usuwania użytkowników — niczego więcej.
Należy rygorystycznie izolować i monitorować hosta magazynu, ponieważ staje się on teraz celem o wysokiej wartości.

Vault może rotować własne główne poświadczenie, dzięki czemu po zakończeniu konfiguracji nie zna go żaden człowiek.

# After configuring the engine, rotate the root credential
# so even operators no longer know the original password
vault write -force database/rotate-root/appdb

Obsługa wygaśnięcia w kodzie aplikacji

Aplikacje należy pisać tak, aby uwzględniały zmianę poświadczeń. W przypadku sekretów statycznych kod odczytuje hasło raz podczas uruchamiania. W przypadku sekretów dynamicznych kod musi:

Pobrać poświadczenie i zapamiętać TTL dzierżawy.
Odnowić dzierżawę lub ponownie pobrać nowe poświadczenie przed jej wygaśnięciem.
Gracefully reconnect when an old credential is revoked.

Typowym rozwiązaniem jest agent typu sidecar, który obsługuje cykl życia dzierżawy i aktualizuje lokalny plik sekretu, dzięki czemu aplikacja musi jedynie ponownie wczytać konfigurację. Należy również odświeżać pule połączeń, aby nie próbowały nadal używać wygasłego poświadczenia.

# Vault Agent auto-renews and re-templates on rotation
auto_auth { method "approle" { ... } }
template {
  contents    = "{{ with secret \"database/creds/billing-readonly\" }}{{ .Data.username }}:{{ .Data.password }}{{ end }}"
  destination = "/run/secrets/db"
  command     = "systemctl reload billing-app"
}

Kiedy sekrety statyczne są nieuniknione

Nie każdy sekret może być dynamiczny. Niektóre interfejsy API firm zewnętrznych wydają jeden długoterminowy klucz, którego nie można wygenerować na żądanie. W przypadku tych sekretów statycznych należy stosować środki kompensacyjne:

Przechowywać je w magazynie, nigdy w kodzie.
Ograniczać je do minimalnych uprawnień.
Rotować je zgodnie z harmonogramem (zostanie to omówione w następnej lekcji).
Monitorować ich użycie pod kątem anomalii.

Praktyczna zasada: preferować sekrety dynamiczne; gdy użycie statycznych jest konieczne, konsekwentnie je rotować i audytować.

Sekrety dynamiczne w CI/CD

Potoki CI/CD to idealny przypadek zastosowania. Tradycyjnie potok przechowuje długoterminowe klucze wdrożeniowe — łakomy cel. W przypadku sekretów dynamicznych potok:

Uwierzytelnia się w Vault za pomocą swojej tożsamości OIDC (np. tokenu OIDC GitHub Actions).
Żąda krótkotrwałych poświadczeń chmurowych ważnych tylko przez czas trwania zadania.
Pozwala im automatycznie wygasnąć po zakończeniu zadania.

Żaden długoterminowy klucz wdrożeniowy nigdy nie istnieje. Przejęty log potoku ujawnia poświadczenie, które jest już nieważne, zanim ktokolwiek zdąży go odczytać.

# GitHub Actions job exchanges its OIDC token for a short-lived AWS role
# No static AWS keys stored as repo secrets
permissions:
  id-token: write
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123:role/deploy
      aws-region: eu-central-1

Szybki test

Sprawdź swoją wiedzę na temat dzierżaw i sekretów dynamicznych.

Podsumowanie: sekrety dynamiczne i dzierżawy

Nauczyłeś się, jak krótkotrwałe i automatycznie wygasające poświadczenia zmieniają zarządzanie sekretami.

Sekrety dynamiczne są generowane na żądanie, unikalne dla każdego odbiorcy i automatycznie wygasają, w przeciwieństwie do używanych ponownie sekretów statycznych.
Dzierżawa określa TTL i max TTL; po wygaśnięciu magazyn unieważnia poświadczenie i przeprowadza rzeczywiste czyszczenie.
Dzierżawy mogą być odnawiane przez długotrwałe aplikacje lub natychmiast unieważniane jako wyłącznik awaryjny podczas incydentu.
Sekrety dynamiczne działają w przypadku baz danych, Cloud IAM, SSH, PKI i innych systemów, ograniczając promień rażenia i automatyzując rotację.
Kompromisem jest uprzywilejowane poświadczenie root w magazynie — należy je rotować i ściśle ograniczyć jego zakres.
Aplikacje i potoki CI/CD należy projektować tak, aby obsługiwały wygaśnięcie; należy preferować sekrety dynamiczne, a statyczne rotować, gdy ich użycie jest nieuniknione.

Następnie omówimy rotację kluczy i wykrywanie wycieków, gdy mimo wszystko do nich dojdzie.

Często zadawane pytania

Czy lekcja „Dynamiczne sekrety i dzierżawienie” jest bezpłatna?

Tak — pełny tekst „Dynamiczne sekrety i dzierżawienie” 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 „Dynamiczne sekrety i dzierżawienie”?

Krótkotrwałe dane uwierzytelniające wygasające automatycznie Ć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 3 z 4.

Ile czasu zajmuje lekcja „Dynamiczne sekrety i dzierżawienie”?

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