GH GambleHub

Zarządzanie kluczem i rotacja

Klucze to „korzenie zaufania platformy”. "Niezawodny system zarządzania kluczami (procesy KMS/HSM + + telemetria) przekształca kryptografię z jednorazowej integracji w codzienną operację: klucze są regularnie aktualizowane, ich użycie jest przejrzyste, kompromisy są zlokalizowane, a klienci doświadczają kluczowej zmiany bez przestojów.

1) Cele i zasady

Zwinność krypto: możliwość zmiany długości algorytmu/klucza bez dużych migracji.
Najmniejsza ekspozycja: klucze prywatne nie pozostawiają KMS/HSM; operacje podpisywania/odszyfrowywania - usunięte.
Krótkotrwałe artefakty: Żetony/klucze sesji na żywo minuty-godziny, nie tygodnie.
Okna dual-key/Dual-cert: obroty bezpieczne dla awarii.
Izolacja regionalna i lokatorska: klucze są podzielone przez region i najemcę.
Pełna zdolność audytu: niezmienny dziennik transakcji, kwalifikacje HSM, kontrola dostępu.

2) Klasyfikacja kluczowa

Główny klucz CA/Master: niezwykle rzadkie zastosowanie, przechowywane w HSM, używane do wydawania kluczy pośrednich lub opakowań kluczy danych.
Obsługa: podpis JWT/event, TLS, podpis webhook, szyfrowanie config/PII.
Sesja/czas: DPoP, mTLS-binding, ECDH-wyjście dla kanału/dialogu.
Integracja: Klucze partnerskie (publiczne) i sekrety HMAC.
Klucze danych (DEK): używać szyfrowania koperty pod KEK, nie są przechowywane wprost.

3) Kluczowa polityka identyfikacji i wykorzystania

Każdy klucz ma „dziecko” (klucz jest identyfikowany w żetonach/nagłówkach):
yaml key:
kid: "eu-core-es256-2025-10"
alg: "ES256"         # или EdDSA, RSA-PSS, AES-GCM, XChaCha20-Poly1305 purpose: ["jwt-sign","webhook-sign"]
scope: ["tenant:brand_eu","region:EE"]
status: "active"       # active      next      retiring      revoked created_at: "2025-10-15T08:00:00Z"
valid_to:  "2026-01-15T08:00:00Z"

Zasady: „jeden cel - jeden klucz” (minimalny podział), wyraźne obszary stosowania i harmonogram.

4) Kluczowy cykl życia (KMS/HSM)

1. Generowanie: w HSM/KMS, z polityką eksportu = odrzucone.
2. Publikacja: dla asymetrii - JWKS/certyfikat z 'kid'.
3. Użyj: zdalne operacje (znak/odszyfrowanie) z kontrolowanym IAM.
4. Obróć: uruchom klucz 'next' i włącz podwójną akceptację.
5. Przejście na emeryturę: przetłumaczyć starą na „emeryturę”, a następnie „odwołaną”.
6. Zniszczyć: zniszczyć materiał (z protokołem oczyszczenia) po oknie sporu.

5) Rotacja: Strategie

Zaplanowany: kalendarz (na przykład co 1-3 miesiące dla podpisu JWT, 6-12 miesięcy dla sert-TLS).
Rolling: stopniowa zmiana konsumentów (JWKS zawiera już nowy klucz; Emiter zaczyna podpisywać nowe po rozgrzaniu buforów).
przymusowe (bezpieczeństwo): natychmiastowa rotacja po kompromisie; krótkie podwójnie akceptowane okno, agresywne wygaśnięcie artefaktów.
Rozłożony na region/najemcę: aby nie „klaskać” całego świata w tym samym czasie.

Złota zasada: najpierw publikacja, potem podpis jest nowy, a dopiero po wygaśnięciu - przypomnienie starego.

6) Okno dwukluczykowe

Publikujemy JWKS ze starym i nowym „dzieckiem”.
Weryfikatorzy akceptują oba.
Emiter w N minut/godziny rozpoczyna podpisywanie nowych.
Monitorujemy udział kontroli starego/nowego „dzieciaka”.
Po osiągnięciu celu, retyrim jest stary.

yaml jwks:
keys:
- kid: "eu-core-es256-2025-10" # new alg: "ES256"
use: "sig"
crv: "P-256"
x: "<...>"; y: "<...>"
- kid: "eu-core-es256-2025-07" # old alg: "ES256"
use: "sig"
...

7) Zasady podpisywania i zatwierdzania

Algorytmy domyślne: ES256/EdDSA podpisu; RSA-PSS, jeżeli jest to wymagane.
Zakaz stosowania 'żadnych '/słabych algorytmów; whitelisting po stronie weryfikacyjnej.
Zegar skew: pozwalamy ± 300 c, odchylenia dziennika.
Wklejanie kluczy (usługi wewnętrzne) i krótka pamięć podręczna TTL JWKS (30-60 s).

8) Szyfrowanie koperty i KDF

Przechowywać dane w ten sposób:

ciphertext = AEAD_Encrypt(DEK, plaintext, AAD=tenant    region    table    row_id)
DEK = KMS. Decrypt (KEK, EncryptedDEK )//on access
EncryptedDEK = KMS. Encrypt (KEK, DEK )//on write

KEK (Key Encryption Key) jest przechowywany w KMS/HSM, obracany regularnie.
DEK jest tworzony na obiekt/partię; podczas obracania KEK wykonujemy ponowne zawijanie (szybko, bez ponownego szyfrowania danych).
Dla strumieni - ECDH + HKDF do wyjścia krótkotrwałe klucze kanału.

9) Regionalność i wielu najemców

Klucze i JWKS są regionalizowane: „eu-core”, „latam-core” to różne zestawy kluczy.
oddzielenie IAM/audytu od najemcy/regionu; klucze nie „przepływają” między rezydencjami.
Kod dziecięcy z prefiksem domeny zaufania: „eu-core-es256-2025-10”.

10) Tajemnice integracji (HMAC, klucze API)

Przechowywać w Secret Store obsługiwanym przez KMS, wydać za pośrednictwem krótkotrwałych tajemnic klienta (zasady rotacji ≤ 90 dni).
Wsparcie dla dwóch aktywnych tajemnic (dual-secret) podczas rotacji.
Dla haków internetowych - znacznik czasu + podpis nadwozia HMAC; okno czasowe ≤ 5 min.

11) Kontrola dostępu i procesy

Macierz IAM: kto może „generować”, „znak”, „odszyfrować”, „obracać”, „niszczyć” (role minimalne).
Zasada 4-eye: wrażliwe operacje wymagają dwóch potwierdzeń.
Zmień okna: okna umożliwiające nowy klucz i przetestowanie regionów kanaryjskich.
Runbooks: szablony procedur dla zaplanowanych i wymuszonych obrotów.

12) Obserwowalność i audyt

Metryka:
  • „sign _ p95 _ ms”, „decrypt _ p95 _ ms”, „jwks _ skew _ ms”,
  • zużycie przez „dziecko”, „old _ kid _ usage _ ratio”,
  • 'invalid _ signature _ rate', 'decrypt _ failure _ rate'.
Dzienniki/audyt:
  • Każda operacja podpisu/deszyfrowania to „kto/co/kiedy/gdzie/kid/cel”.
  • Historia stanu klucza oraz żądania rotacji/cofnięcia.
  • Kwalifikacje HSM, kluczowe materiały dostęp dzienniki.

13) Playbooks (incydenty)

1. Kompromis klucza podpisu

Natychmiastowe cofnięcie starego „dzieciaka” (lub przełożenie na „przejście na emeryturę” z minimalnym oknem), publikacja nowego JWKS, skrócone żetony TTL, siła wylogowania/niepełnosprawność RT, komunikacja z właścicielami integracji, audyt retro.

2. MASA 'INVALID _ SIGNATURE' po rotacji

Sprawdź pamięć podręczną JWKS/zegar, powrót podwójnie akceptowane, rozszerzyć okno, dystrybuować do klientów.

3. Zwiększenie opóźnień KMS/HSM

Włączanie lokalnego pamięci podręcznej podpisu jest niedozwolone; zamiast - partia/kolejka w emiterze, autoskalowanie serwera proxy HSM, priorytetyzacja strumieni krytycznych.

4. Awaria jednego regionu

uruchomienie regionalnych procedur izolacji; nie „wyciągać” kluczy z innych regionów; funkcje degradacji związane z podpisami w regionie upadłym.

14) Badanie

Kontrakt: poprawność JWKS, poprawność 'kid '/alg/use, kompatybilność klienta.
Negatywny: fałszywy podpis, przestarzałe „dziecko”, niepoprawny alg, zegar.
Chaos: natychmiastowa rotacja, niedostępność KMS, dryf czasowy.
Ładunek: podpisy szczytowe (JWT/webhaki), szczytowe odszyfrowania (PII/wypłaty).
E2E: okno dual-key: release - verification - traffic transfer - rejection of the old one.

15) Przykład konfiguracji (YAML)

yaml crypto:
regions:
- id: "eu-core"
jwks_url: "https://sts. eu/.well-known/jwks. json"
rotation:
jwt_sign: { interval_days: 30, window_dual: "48h" }
webhook: { interval_days: 60, window_dual: "72h" }
kek:   { interval_days: 90, action: "rewrap" }
alg_policy:
sign: ["ES256","EdDSA"]
tls: ["TLS1. 2+","ECDSA_P256"]
publish:
jwks_cache_ttl: "60s"
audit:
hsm_attestation_required: true two_person_rule: true

16) Przykład JWKS i znaczników w artefakcie

Fragment nagłówka JWT:
json
{ "alg":"ES256", "kid":"eu-core-es256-2025-10", "typ":"JWT" }
JWKS (część publiczna):
json
{ "keys":[
{"kty":"EC","use":"sig","crv":"P-256","kid":"eu-core-es256-2025-10","x":"...","y":"..."},
{"kty":"EC","use":"sig","crv":"P-256","kid":"eu-core-es256-2025-07","x":"...","y":"..."}
]}

17) Anty-wzory

Długotrwałe klucze „na lata” i wspólne dla wszystkich regionów.
Rotacja „w jednej chwili” bez podwójnej akceptacji.
Eksport kluczy prywatnych z KMS/HSM „dla prędkości”.
Zadania mieszania: podpisz JWT i szyfruj dane jednym kluczem.
Brak kłód/kwalifikacji HSM i ograniczeń IAM.
Nie ma mechanizmu ponownego zawijania DEK w obrocie KEK.
Ręczne „sekrety” w sklepie, zamiast Secret Store.

18) Lista kontrolna przedsprzedaży

  • Wszystkie klucze prywatne w KMS/HSM; Matryca IAM i zasada 4-eye są dostrojone.
  • Zatwierdza się politykę algorytmu, kluczowe długości i okresy życia.
  • Umożliwiony proces podwójnego klucza z monitorowaniem udziału „dzieci”.
  • JWKS jest publikowany z krótkim TTL i ocieplenie pamięci podręcznej; klienci akceptują klucz ≥ 2.
  • Szyfrowanie koperty: KEK obraca się, odwijanie DEK bez przestoju.
  • Izolacja regionalna i oddzielne zestawy kluczowych najemców.
  • Kompromisowe/rolling/force rotation playbooks; biegi treningowe.
  • Włączone są mierniki ('old _ kid _ usage _ ratio', 'invalid _ signature _ rate') i alerty.
  • contract/negative/chaos/load/E2E przeszedł zestaw testowy.
  • Dokumentacja dla integracji: jak obsługiwać zmianę 'kid', które okna i kody błędów.

Wnioski

Kluczowe zarządzanie to dyscyplina operacyjna: KMS/HSM jako źródło prawdy, regularne i bezpieczne rotacje z podwójnym kluczem, regionalną i lokatorską izolacją, szyfrowaniem kopert i obserwowalnością. Przestrzegając tych zasad, otrzymasz kontur kryptograficzny, który skaluje się, jest odporny na incydenty i łatwy do wyjaśnienia audytorowi - a deweloperzy i integratorzy doświadczają każdej zmiany bez bólu.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.