Bezpečnost a logování v serverless prostředí: ochrana

Specifika bezpečnosti a logování v serverless

Serverless computing (FaaS a spravované backendové služby) mění bezpečnostní model: infrastrukturu vlastní poskytovatel, izolace runtime je jemnozrnná a životní cyklus funkcí je efemérní. Ochrana se proto zaměřuje na identitu a přístup (IAM), integritu artefaktů, řízení datových toků a observabilitu bez pevného hostitele. Logování musí být strukturované, korelované napříč událostmi a zohledňovat náklady, protože objem logů roste s počtem vyvolání.

Model hrozeb serverless aplikací

• Napadení dodavatelského řetězce: škodlivé knihovny, kroky sestavení a kontejnerové obrazy pro runtime.
• Chybná konfigurace IAM: nadměrná oprávnění funkcí, otevřená témata/fronty/odběry.
• Injekce prostřednictvím událostí: payloady z API Gateway, webhooků, front a datových proudů.
• Úniky tajemství: proměnné prostředí, nesprávná práce se službou Secrets Manager, ladicí logy.
• Laterální pohyb: mezi funkcemi a spravovanými službami prostřednictvím rolí a tokenů metadat.
• Rizika víceklientského prostředí: izolace na straně poskytovatele (hypervisor, microVM), noisy neighbor.

Identity a přístup: princip nejmenších oprávnění

• Role pro každou funkci: každá funkce má vlastní roli IAM s oprávněními omezenými na konkrétní zdroje a akce.
• Bezpečné volání mezi službami: upřednostňujte autorizaci založenou na identitě (identity-based; podepsané požadavky, identita úlohy) před sdílenými tokeny.
• Krátkodobé přihlašovací údaje: federace a vydávání dočasných tokenů; zákaz statických klíčů v kódu.
• Oddělení účtů/projektů: prod a non-prod v samostatných účtech s centrální správou zásad.

Správa tajemství a kryptografie

• Secrets Manager/KMS: tajemství nikdy neukládejte v proměnných prostředí v čitelné podobě; načítejte je podle potřeby s krátkou dobou uložení v mezipaměti.
• Rotace: automatická rotace klíčů a hesel; verzování tajemství s řízeným nasazováním.
• Šifrování při přenosu (TLS/mTLS) a v klidu (spravované klíče, případně zákaznické KMS se zásadami klíčů key policy).
• Citlivá data v logách: implementujte redakci/maskování na úrovni loggeru a brány.

Bezpečné hranice: API brána, fronty a události

• API Gateway: WAF, omezení rychlosti, mTLS pro privátní API, validace schémat (OpenAPI/JSON Schema) pro payload.
• Architektura řízená událostmi: autorizace na úrovni témat/front; fronta nedoručených zpráv (DLQ) a zásady opakování bez nekonečných smyček.
• Datové proudy: ACL na úrovni partition, sledování prodlev, idempotentní konzument.

Síť a kontrola odchozího provozu

• Privátní konektivita: privátní koncové body k databázím a tajemstvím, žádný veřejný internet, pokud to není nutné.
• Proxy pro odchozí provoz: kontrola výstupního provozu (DLP, seznam povolených URL), pravidla pouze pro odchozí provoz, centralizovaný audit.
• Integrace s VPC: pozor na latenci při cold startech a limity soketů; definujte bezpečná pravidla SG/NSG.

Integrita sestavení a artefaktů

• Reprodukovatelná sestavení a SBOM (seznam závislostí), podepisování nasazovacích balíčků/kontejnerů a vynucování pravidel na straně platformy.
• Zásady jako kód (Policy as Code): OPA/Rego či nativní zásady pro validaci infrastruktury jako kódu a konfigurací funkcí (timeout, paměť, odchozí provoz, role).

Zabezpečení runtime a hardening

• Časové limity a paměť: nastavte konzervativní limity; zabráníte tak DoS útokům způsobeným nekonečnými smyčkami a nadměrnými alokacemi.
• Neperzistentní data: vyhněte se ukládání dat mimo /tmp; vše citlivé ukládejte do spravovaných úložišť se šifrováním.
• Bezpečné parsování: limity velikosti požadavků, streamování namísto načtení všeho do vyrovnávací paměti, knihovny odolné vůči útokům zip-bomb/XXE.

Idempotence, obnovitelnost a odolnost

• Idempotentní handlery: klíče pro deduplikaci, podmíněné zápisy, kontrola pořadí událostí.
• DLQ a odkládání zpráv: oddělení chyb obchodní logiky od dočasných poruch; metriky DLQ jako spouštěč incidentu.
• Zpožďování a náhodný rozptyl: exponenciální zpožďování, aby se nezhoršovalo přetížení.

Observabilita: logy, metriky a trasování

• Strukturované logy: JSON s poli trace_id, span_id, correlation_id, tenant, pii_redacted, severity.
• Distribuované trasování: předávání kontextu prostřednictvím hlaviček API Gateway/front (W3C Trace Context), spany serverless funkcí pro cold/warm starty.
• Metriky: latence p50/p95/p99, chybovost, počty vyvolání, throttling, využití paměti/CPU přepočtené poskytovatelem.
• Vzorkování logů: adaptivní vzorkování při špičkách; přístup nejprve chyby (error-first) a vzorkování na konci toku (tail-based) pro anomálie.

Strukturované logování: doporučené schéma

Řízení nákladů na logy a telemetrii

• Víceúrovňové cíle: krátká doba uchovávání v úložišti „hot“, dlouhodobá v levném objektovém úložišti.
• Filtrování u zdroje: potlačení úrovně DEBUG v produkci s možností zvýšení na vyžádání prostřednictvím příznaku funkce.
• Směrování logů: kritické události do SIEM, ostatní do datového jezera; metriky z logů pro agregované přehledy.

Detekce hrozeb a reakce v serverless

• Behaviorální pravidla: anomálie ve voláních IAM, neobvyklé cíle odchozího provozu, nárůst odpovědí 4xx/5xx.
• Signály z platformy: throttling, časté cold starty (indikace zátěže či útoků), navýšení limitů.
• Automatizovaná reakce: izolace verze funkce (příznak funkce), zablokování odchozího provozu, rotace tajemství, povinné dodatečné ověření pro správcovské akce.

Soukromí a soulad s předpisy

• Správa osobních údajů: minimalizace, pseudonymizace, šifrování na úrovni polí, zaznamenávání účelů zpracování.
• Umístění dat: volba regionů a zákaznických klíčů (BYOK); kontrola záloh a exportů logů.
• WORM/neměnnost: neměnné úložiště pro audity a forenzní logy.

Testování bezpečnosti v toku řízeném událostmi

• Kontraktní testy vstupních payloadů a schémat; generativní testy hraničních hodnot.
• Chaos testy a vkládání poruch: výpadky závislostí (tajemství, DB, odchozí provoz), časové limity, duplikace událostí.
• Bezpečnostní skenování: SAST/DAST, SCA, zásady IaC, kontrola veřejných zdrojů.

Bezpečný návrh front a databází

• Zabezpečení na úrovni řádků/sloupců pro víceklientský model; připravené příkazy a parametrizované dotazy.
• Omezení počtu připojení: sdružování připojení v serverless (proxy/služby sidecar) s TLS a identitou.
• TTL a doba uchovávání: automatické mazání dočasných dat (tokenů, záznamů v mezipaměti).

Praktická matice rizik a kontrol

Provozní SLO a bezpečnostní metriky

• Bezpečnost: doba rotace tajemství, počet zamítnutých neautorizovaných volání, pokrytí zásadami.
• Observabilita: procento korelovaných požadavků (pokrytí trasováním), latence ingestování logů, p99 doba vyšetřování.
• Spolehlivost: chybovost handlerů, míra DLQ, p95 cold startů a jejich dopad na SLO.

Kontrolní seznam bezpečnosti a logování v serverless

• Má každá funkce vlastní roli IAM s minimálními oprávněními?
• Načítají se tajemství z trezoru a jsou automaticky rotována?
• Validují se schémata payloadů na hranici (API/fronta) a jsou omezeny jejich velikosti?
• Je zapnuta mTLS/privátní konektivita ke kritickým službám?
• Jsou logy strukturované, obsahují ID trasování/korelace a jsou redigovány osobní údaje?
• Existuje DLQ, zásada opakování s exponenciálním zpožďováním a idempotence?
• Je v CI/CD aktivní kontrolní brána zásad jako kódu a podepisování artefaktů?
• Máte definované SLO a výstrahy (chybovost, latence, throttling, nárůst DLQ)?
• Je u auditních logů zajištěna neměnnost WORM a řízení doby uchovávání?

Závěr: Bezpečnost jako vlastnost architektury, logy jako produkt

Ve světě serverless se nelze spoléhat na tradiční perimetr ani agenty instalované na jednotlivých hostitelích. Ochrana je výsledkem návrhu řízeného identitou, bezpečných hranic událostí, důsledné správy tajemství a prvotřídní observability. Logy nejsou odpad, ale produkt – musí být strukturované, korelované, nákladově řízené a připravené na forenzní analýzu. Vzniká tak architektura, která je pružná, auditovatelná a odolná vůči moderním hrozbám.