Bezpečnost a správa tajemství: ochrana citlivých údajů

Proč je správa tajemství klíčová pro cloud native

Tajemství (secrets) – přístupové klíče, hesla, tokeny, certifikáty, šifrovací klíče – jsou životně důležitým aktivem každé aplikace cloud native. Mikroservisy, CI/CD, infrastruktura jako kód a elastická běhová prostředí (Kubernetes, serverless) výrazně zvyšují počet míst, kde se s tajemstvími pracuje. Správa tajemství (Secrets Management) proto musí řešit celý životní cyklus: bezpečné vytvoření, distribuci, používání, rotaci, audit a zneplatnění – a to automatizovaně, s minimálním lidským přístupem a s měřitelnými zásadami least privilege a zero trust.

Terminologie a rozsah: co všechno je „tajemství“

Autentizační tajemství: hesla, API klíče, tokeny OAuth/OIDC, relační cookies.
Kryptografický materiál: soukromé klíče, certifikáty (mTLS, TLS), klíče KMS, klíče pro šifrování aplikačních dat.
Konfigurační tajemství: connection stringy, DSN s přihlašovacími údaji, podpisové klíče pro JWT/webhooky.
Metadata a zásady: TTL, oprávnění, rozsah (scope), auditní stopy, podmínky atestace.

Bezpečnostní principy: zero trust, least privilege a just-in-time

Zero trust: implicitně nedůvěřovat síti, instancím ani uživatelům; ověřit identitu každé entity (workloadu, uživatele, pipeline) a vynucovat zásady při každém požadavku.
Least privilege: tajemství a klíče se přidělují pouze v rozsahu a na dobu nezbytnou k provedení úkolu; role jsou odděleny mezi vývojem, provozem a bezpečností.
Just-in-time (JIT) a short-lived pověření: upřednostňovat krátkodobé, automaticky rotované a odvolatelné přístupy před statickými klíči.
Zákaz sdílených účtů a jednoznačnost identit: každá identita je jednoznačná, auditovatelná a má vlastní omezená pověření.

Životní cyklus tajemství: od vzniku po zneplatnění

Generování: kryptograficky silné zdroje náhody, centrálně řízené zásady délky a typu.
Distribuce: šifrovaným kanálem s ověřením protistrany; tajemství neposílat e-mailem ani chatem.
Uložení: mimo hostitele (trezor), v paměti pouze krátce, na disku výhradně šifrovaně s hardwarovou ochranou klíčů.
Použití: za běhu ideálně prostřednictvím připojení do paměti (mountů) nebo tmpfs, nikoli v proměnných prostředí, protokolech či výpisech paměti.
Rotace: plánovaná i ad hoc po incidentu; bez výpadků, s dvojicí platných pověření během přechodu.
Odvolání: okamžité zneplatnění a promítnutí změny; audit dopadu a ověření, že staré pověření již nefunguje.

Architektura řešení: trezor, KMS a HSM

Trezor tajemství (Vault/Secrets Manager): centralizované API pro ukládání, vydávání a audit; podporuje dynamická tajemství, leasing, TTL a jemnozrnná oprávnění.
KMS (Key Management Service): správa hlavních (master) klíčů, generování a rotace; poskytuje envelope encryption pro šifrování aplikačních dat.
HSM (Hardware Security Module): kořen důvěry pro klíče nejvyšší hodnoty; operace se soukromými klíči probíhají uvnitř HSM.
Obálkové šifrování: datový klíč (DEK) šifruje datový obsah; DEK je zašifrován klíčem key-encryption key z KMS/HSM → výkon + bezpečnost.

„Secret zero“: zavedení identity workloadu

Nejkritičtějším problémem je, jak poprvé prokázat identitu aplikace bez natvrdo zapsaného tajemství:

Workload identity prostřednictvím SPIFFE/SPIRE: každému workloadu se podle atestace uzlu a manifestu vydá krátkodobé SVID (X.509/JWT).
Federace OIDC z CI/CD a cloudových služeb: krátkodobé tokeny se vyměňují za konkrétní role v trezoru/KMS (bez dlouhodobých statických klíčů).
Atestace uzlu (TPM/SEV/SGX/TDX): hardware umožňuje bezpečně prokázat, že workload běží v důvěryhodném prostředí.

Kubernetes: integrace a anti-patterny

Nepoužívejte nativní Secret jako trvalý trezor: hodnoty jsou pouze zakódované v base64 a spoléhají na šifrování při uložení klíčem clusteru; hodí se pro nízkorizikové hodnoty.
CSI Secrets Store: připojení tajemství přímo z externího trezoru do tmpfs; rotace bez restartu podu.
Sidecar/Agent: Vault Agent/SDK, který získává, obnovuje a předává tajemství prostřednictvím souborů nebo memfd.
RBAC a NetworkPolicy: omezit přístup k trezoru pouze pro konkrétní ServiceAccount a namespace; povolit pouze určený odchozí provoz (egress allowlist).
Certifikáty a mTLS: automatizovaná PKI (SPIRE, cert-manager, ACME) s krátkou platností certifikátů pro komunikaci mezi službami.

Serverless a edge: krátký životní cyklus, krátkodobá tajemství

Funkce a edge runtime se spouštějí často a na krátkou dobu, což zvyšuje riziko úniku při studených startech a prostřednictvím protokolů:

Načtení při vyvolání: získat tajemství při volání s TTL v řádu milisekund a ukládat ho do cache v paměti pouze pro daný execution context.
Identita pro každou funkci: samostatná role pro každou funkci, nikoli jedna sdílená pro celý účet; žádná tajemství v proměnných prostředí.
Limity: hlídat počet volání trezoru (rate limit), používat lokální proxy cache s atestací.

Dynamická tajemství, leasing a automatická rotace

Dynamické přístupy k databázím: trezor na vyžádání vytváří jedinečné databázové uživatele s TTL a rolemi; po vypršení platnosti se účet zneplatní.
Pověření pro cloud: zprostředkování dočasných rolí IAM (výměna tokenů STS/OAuth) namísto dlouhodobých přístupových klíčů.
Leasing a obnovování: klient požádá o renew před vypršením platnosti; server může při incidentu pověření revoke.

Zásady a policy-as-code

Oddělení povinností (SoD): zásady navrhuje jiný tým, než který provozuje trezor; aplikace vyvíjí další tým.
OPA/REGO: ověřování žádostí o tajemství (kdo/co/kdy/kde) podle deklarativních pravidel, včetně kontextu (namespace, štítky, atestace).
Schvalování a výjimky: citlivé přístupy vyžadují režim break-glass se záznamem a časově omezeným přístupem.

Šifrování: at-rest, in-transit a in-use

In-transit: mTLS s moderními šiframi; ověřování certifikátů, připnutí certifikační autority (CA pinning).
At-rest: klíče v KMS/HSM, data šifrovaná na discích; hierarchie klíčů, rotace klíčů KEK bez nutnosti znovu šifrovat celý obsah.
In-use: confidential computing (TEE) a izolace paměti pro zpracování citlivých dat a klíčů.

Identita uživatele a služby: PKI, OAuth/OIDC, mTLS

PKI: interní certifikační autority pro mTLS mezi službami; certifikáty s krátkou platností (hodiny/dny), automatická obnova.
OAuth/OIDC: uživatelské identity, delegování přístupu; podpisové klíče rotovat a zveřejňovat prostřednictvím JWKS.
JWT: krátká platnost exp, omezený scope, validace aud/iss; nikdy nepoužívat trvalé refresh tokeny bez ochrany.

Integrace do CI/CD a IaC

Žádná tajemství v repozitáři: používat skenery v rámci pre-commit (gitleaks, trufflehog) a zásady na straně serveru (server-side) k blokování úniků.
Federace OIDC z CI do cloudu/trezoru: žádné statické klíče v úložišti „secrets“ systému CI; krátkodobé přidělování rolí.
Šifrování IaC: SOPS/Sealed Secrets/age s integrací KMS; přístup k dešifrování pouze v kontrolovaných prostředích.
Kontrolní brány kvality: pipeline selže, pokud tajemství unikne do artefaktu, protokolu či vrstvy image.

Monitorování, audit a forenzní připravenost

Auditní protokoly: kdo/co/kdy/kde/na jak dlouho; neměnné (immutable) úložiště (WORM), korelační ID propojená s aplikačními protokoly.
Detekce anomálií: neobvyklé vzorce čtení tajemství, nadměrné obnovování, přístupy z neznámých identit/sítí.
Testy obnovy: pravidelně cvičit rotaci a odvolání tajemství bez výpadku; scénáře úniku formou tabletop cvičení.

Reakce na incident: postup při úniku tajemství

Detekce a izolace: zablokovat podezřelý přístup, zmrazit dotčené služby/účty.
Okamžitá rotace: automaticky změnit tajemství v trezoru, znovu zabalit klíče v KMS; zneplatnit tokeny.
Forenzní analýza: prověřit auditní záznamy, zmapovat dopad (kde bylo tajemství použito).
Náprava a následné vyhodnocení: opravit zásady, zlepšit detekci, aktualizovat runbook.

Výkonnost a spolehlivost trezoru

Vysoká dostupnost: více uzlů, kvórum pro unseal, geografická redundance.
Ukládání do mezipaměti: lokální cache s krátkým TTL; pozor na „thundering herd“ při vypršení platnosti.
Omezení rychlosti a exponenciální prodleva: ochrana před DoS i chybnou implementací klientů.

Data versus konfigurace: co je tajemství a co jím není

Není tajemstvím: veřejné URL, názvy služeb, necitlivé příznaky funkcí, veřejné klíče.
Je tajemstvím: vše, co umožňuje autentizaci/autorizaci nebo dešifrování; také interní koncové body, pokud zpřístupňují privilegované rozhraní.
Oddělení: necitlivou konfiguraci ukládat jinam; omezí to blast radius v případě kompromitace trezoru.

Připravenost na postkvantovou éru a kryptografická agilita

Agilita: navrhovat rozhraní tak, aby bylo možné migrovat algoritmy/klíče bez zásahů do aplikací.
Hybridní podpisy: během přechodu kombinovat současné a postkvantové algoritmy; sledovat standardizaci.
Krátká životnost klíčů: zkracuje dobu, po kterou lze klíče zneužít, i v případě budoucího prolomení kryptografie.

Typické anti-patterny a jak se jim vyhnout

Tajemství v image: žádná tajemství ve vrstvách kontejneru ani v souborech .env; používat předávání za běhu.
Trvalé klíče root: nahraďte je krátkodobými rolemi; statické klíče používejte pouze tam, kde neexistuje alternativa, a zaveďte přísná kompenzační opatření.
Protokolování tajemství: sanitizace a maskování na úrovni knihoven i pipeline protokolování; zákaz set -x ve skriptech CI.
Jeden trezorový účet „na všechno“: segmentace podle prostředí (dev/test/stage/prod), aplikací a týmů.

Kontrolní seznam pro bezpečnou správu tajemství

Centralizovaný trezor + KMS/HSM pro kořenové klíče.
Workload identity (SPIFFE/SPIRE nebo cloudové OIDC), žádné dlouhodobé klíče.
Krátkodobé, dynamické přístupy (DB/cloud), automatická rotace a odvolání.
mTLS mezi službami, automatizovaná PKI s krátkým TTL.
Předávání tajemství pomocí CSI/sidecar do tmpfs, nikoli do proměnných prostředí.
Policy-as-code (OPA), SoD a schvalování výjimek.
Skenery úniků v git/CI, zákaz tajemství v artefaktech a image.
Auditní protokoly v úložišti WORM, upozornění na anomálie.
Pravidelná cvičení rotace a reakce na incidenty.

Plán zavádění (0–30–90–180 dní)

0–30 dní: audit tajemství, odstranění z repozitářů, aktivace skenerů, zavedení trezoru pro kritická tajemství, federace OIDC z CI.
30–90 dní: mTLS mezi službami, integrace CSI/sidecar, dynamické databázové účty, policy-as-code a základní upozorňování.
90–180 dní: HSM/KMS pro kořenové klíče, SPIRE pro workload identity, automatická rotace všech tajemství, cvičení obnovy po havárii a forenzní připravenost.

Závěr

Bezpečnost a správa tajemství ve světě cloud native je inženýrská disciplína propojující kryptografii, identitu, zabezpečení sítí a provozní excelenci. Úspěch závisí na krátkodobých pověřeních, automatizované rotaci, silné identitě workloadů a centralizovaných, auditovatelných kontrolách. Investice do trezoru, KMS a policy-as-code se vrací v podobě menšího blast radius, rychlejší reakce na incidenty a vyšší důvěry v integritu vašich služeb i dat.