Bezpečnost a správa tajných údajů

Proč je správa tajných údajů klíčová pro cloud-native

Tajné údaje (secrets) – přístupové klíče, hesla, tokeny, certifikáty, šifrovací klíče – jsou životně důležitá aktiva každé cloud-native aplikace. 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 tajných údajů (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 minimem lidského přístupu a s měřitelnými zásadami least privilege a zero trust.

Terminologie a rozsah: co všechno je „secret“

• Autentizační tajemství: hesla, API klíče, OAuth/OIDC tokeny, cookies s relací.
• Kryptografické materiály: soukromé klíče, certifikáty (mTLS, TLS), KMS klíče, klíče pro šifrování aplikačních dat.
• Konfigurační tajemství: connection stringy, DSN s kredencemi, podpisové klíče pro JWT/Webhooky.
• Metadata a zásady: TTL, oprávnění, rozsah (scope), auditní stopy, atestační podmínky.

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

• Zero trust: nedůvěřovat implicitně síti, instancím ani uživatelům; prokázat identitu každé entity (workload, uživatel, pipeline) a vynutit politiky při každé žádosti.
• Least privilege: tajemství a klíče jsou přidělovány pouze v rozsahu a na dobu nezbytnou k vykonání úkolu; oddělení rolí mezi vývojem, provozem a bezpečností.
• Just-in-time (JIT) & short-lived credentials: preferovat krátkodobé, automaticky rotované a odvolatelné přístupy před statickými klíči.
• Zákaz sdílených účtů a neopakovatelná identita: každá identita je jednoznačná, auditovatelná a má vlastní limitované pověření.

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

1. Generování: kryptograficky silné zdroje náhody, centrálně řízené politiky délky a typu.
2. Distribuce: šifrovaným kanálem s ověřením protistrany; žádné posílání přes e-mail či chat.
3. Uložení: mimo hostitele (trezor), v paměti jen krátce, na disku pouze šifrovaně s hardwarovou ochranou klíčů.
4. Použití: za běhu ideálně přes paměťové mounty nebo tmpfs, nikoli v proměnných prostředí, logách či core dumpu.
5. Rotace: plánovaná i ad-hoc po incidentu; bez výpadků, s dvojicí platných pověření během přechodu.
6. Zneplatnění: okamžité zneplatnění a propagace změny; audit dopadu a validace, že stará pověření již nefungují.

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 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.
• Envelope šifrování: datový klíč (DEK) šifruje payload; DEK je šifrovaný key-encryption key z KMS/HSM → zajišťuje výkon i bezpečnost.

„Secret zero“: bootstrap identita workloadu

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

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

Kubernetes: integrace a anti-vzory

• Nepoužívejte nativní Secret jako trvalý trezor: je pouze base64 kódovaný a spoléhá se na šifrování at-rest klíčem clusteru; hodí se pouze pro nízkorizikové hodnoty.
• CSI Secrets Store: mount tajemství přímo z externího trezoru do tmpfs; rotace bez restartu podu.
• Sidecar/Agent: Vault Agent/SDK, který získá, obnoví a injektuje tajemství přes soubory nebo memfd.
• RBAC a NetworkPolicy: izolovat přístup k trezoru jen pro konkrétní ServiceAccount a namespace; egress allowlist.
• Certifikáty a mTLS: automatizovaná PKI (SPIRE, cert-manager, ACME) s krátkou životností certifikátů pro komunikaci služba-služba.

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

Funkce a edge runtime se spouštějí často a krátce, což zvyšuje riziko úniku přes studené starty a logy:

• On-invoke fetch: získat tajemství při volání s milisekundovým TTL a cache v paměti pouze pro daný execution context.
• Per-function identity: role pro každou funkci, ne sdílené pro celý účet; žádná tajemství v environmentálních proměnných.
• Limity: hlídat počet volání na trezor (rate-limit), používat lokální cache proxy s atestací.

Dynamická tajemství, leasing a automatická rotace

• Dynamické DB přístupy: trezor vytváří na vyžádání unikátní databázové uživatele s TTL a rolemi; po vypršení platnosti se účet deaktivuje.
• Cloud credentials: brokering dočasných IAM rolí (STS/OAuth token exchange) místo dlouhodobých přístupových klíčů.
• Leasing a obnovování: klient žádá renew před expirací; server může revoke při incidentu.

Politiky a policy-as-code

• Oddělení povinností (SoD): jeden tým navrhuje politiky, jiný provozuje trezor, další vyvíjí aplikace.
• OPA/REGO: validace žádostí o tajemství (kdo/co/kdy/kde) proti deklarativním pravidlům, včetně kontextu (namespace, labely, atestace).
• Schvalování a výjimky: citlivé přístupy vyžadují break-glass s logováním a omezeným časovým oknem.

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

• In-transit: mTLS s moderními šiframi; ověřování certifikátů, pinning CA.
• At-rest: klíče v KMS/HSM, data na discích šifrována; hierarchie klíčů, rotace KEK bez nutnosti re-šifrování celého obsahu.
• In-use: confidential computing (TEE) a paměťové izolace 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; krátkodobé certifikáty (hodiny/dny), automatická obnova.
• OAuth/OIDC: uživatelské identity, delegace přístupu; podpisové klíče rotovat a publikovat přes JWKS.
• JWT: krátký exp, omezený scope, validace aud/iss; nikdy netrvalé refresh bez ochrany.

Integrace do CI/CD a IaC

• Bez tajemství v repozitáři: používat pre-commit skenery (gitleaks, trufflehog) a server-side politiky pro blokaci.
• OIDC federace z CI do cloudu/trezoru: žádné statické klíče v „secrets“ CI systému; krátkodobé přidělování rolí.
• IaC šifrování: SOPS/Sealed Secrets/age s integrací KMS; přístup k dešifrování pouze v kontrolovaných prostředích.
• Quality gates: pipeline selže, pokud tajemství unikne do artefaktu, logu či image vrstvy.

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

• Audit logy: kdo/co/kdy/kde/jak dlouho; immutable úložiště (WORM), korelační ID s aplikačními logy.
• Detekce anomálií: netypické vzory čtení tajemství, nadměrné obnovy, přístupy z neznámých identit nebo sítí.
• Testy obnovy: pravidelně cvičit rotaci a odvolání tajemství bez výpadku; scénáře úniků formou tabletop exercise.

Incident response: postup při úniku tajemství

1. Detekce a izolace: zablokovat podezřelý přístup, zmrazit dotčené služby a účty.
2. Okamžitá rotace: automatizovaná změna tajemství v trezoru, KMS přebalení klíčů; invalidace tokenů.
3. Forenzní analýza: prozkoumat auditní záznamy, mapovat dopad (kde bylo tajemství použito).
4. Remediace a post-mortem: oprava politik, zlepšení detekce, aktualizace runbooku.

Výkonnost a spolehlivost trezoru

• Vysoká dostupnost: více uzlů, kvórum pro unseal, geografická redundance.
• Caching: lokální cache s krátkým TTL; dávat pozor na „thundering herd“ efekt při expiraci.
• Rate-limit a backoff: ochrana proti DoS útokům i chybné implementaci klientů.

Data vs. konfigurace: co je tajemství a co není

• Není secret: veřejné URL, názvy služeb, feature flagy bez citlivosti, veřejné klíče.
• Je secret: vše, co umožní autentizaci, autorizaci nebo dešifrování; i interní end-pointy, pokud odhalují privilegovaná rozhraní.
• Oddělení: ukládat necitlivou konfiguraci jinde; omezí to blast radius při kompromitaci trezoru.

Post-kvantová připravenost a kryptografická agilita

• Agilita: navrhovat rozhraní tak, aby bylo možné migrovat algoritmy a klíče bez zásahu do aplikací.
• Hybridní podpisy: kombinace dnešních a post-kvantových algoritmů během přechodu; sledování standardizace.
• Krátká životnost klíčů: zkracuje okno zneužitelnosti i u budoucích kryptografických zlomů.

Typické anti-vzory a jak se jim vyhnout

• Tajemství v image: žádná tajemství ve vrstvách kontejneru ani v .env souborech; používat runtime injekci.
• Perzistentní root klíče: nahraďte krátkodobými rolemi; statické klíče pouze tam, kde není alternativa, a s přísnou kompenzací.
• Logování tajemství: sanitizace a maskování na úrovni knihoven i log pipeline; zákaz set -x v CI skriptech.
• Jedno trezorové konto „na všechno“: segmentace podle prostředí (dev/test/stage/prod), aplikací a týmů.

Checklist pro bezpečnou správu tajemství

• Centralizovaný trezor + KMS/HSM pro kořenové klíče.
• Workload identity (SPIFFE/SPIRE nebo cloud OIDC), žádné dlouhodobé klíče.
• Krátkodobé, dynamické přístupy (DB/cloud), automatická rotace a zneplatnění.
• mTLS mezi službami, automatizovaná PKI s krátkým TTL.
• CSI/sidecar injekce tajemství do tmpfs, nikoli do environmentálních proměnných.
• Policy-as-code (OPA), SoD a schvalování výjimek.
• Skenery úniků v git/CI, zákaz tajemství v artefaktech a image.
• Audit logy do WORM úložiště, alerty na anomálie.
• Pravidelná cvičení rotace a incident response.

Roadmapa zavedení (0–30–90–180 dní)

• 0