Bezpečnostné riziká a ochrana v serverless prostredí

Specifiká bezpečnosti a logovania v serverless prostredí

Serverless computing, zahŕňajúci modely ako FaaS (Function as a Service) a spravované backendové služby, zásadne mení tradičný bezpečnostný model IT infraštruktúry. V tomto prístupe je hardvér a virtualizácia vlastnená a spravovaná poskytovateľom cloudových služieb, pričom izolácia runtime prostredia je veľmi jemnozrnná a životný cyklus funkcií je efemérny, teda dočasný. Z týchto dôvodov sa ochrana nezameriava primárne na hardvérový alebo hostiteľský level, ale skôr na bezpečnosť identity a prístupu (IAM), integritu nasadených artefaktov, správne riadenie dátových tokov a napokon na komplexnú observabilitu v prostredí bez pevne definovaného hostiteľa.

Logovanie v serverless je nevyhnutne štruktúrované a musí umožniť koreláciu medzi jednotlivými udalosťami naprieč celým systémom, pričom zároveň musí byť citlivé k nákladom na spracovanie, keďže objem generovaných logov exponenciálne rastie s počtom vyvolaní jednotlivých funkcií.

Model hrozieb pre serverless aplikácie

• Ohrozenie dodávateľského reťazca: riziko zavlečenia škodlivých knižníc, upravených build krokov alebo kontajnerových základov pre runtime prostredia.
• Nesprávna konfigurácia IAM: pridelenie nadmerných oprávnení pre funkcie, otvorené topic-y, queue alebo subscription.
• Injekcia cez udalosti: neoverené alebo škodlivé údaje z API Gateway, webhookov, front správ alebo dátových streamov.
• Úniky tajomstiev: nevhodné ukladanie citlivých údajov v environmentálnych premenných, nesprávna správa v Secrets Manager alebo detailné debugovací logy obsahujúce tajomstvá.
• Laterálny pohyb: presuny napadnutia medzi funkciami a spravovanými službami prostredníctvom kompromitovaných rolí alebo metadata tokenov.
• Riziká viacerých tenantov: nedostatočná izolácia na úrovni poskytovateľa (hypervízor, microVM), ktorá môže viesť k efektu noisy neighbor.

Identita a prístup: zásada minimálnych oprávnení

• Role pre každú funkciu: každá serverless funkcia by mala mať pridelenú samostatnú IAM rolu s striktne obmedzenými oprávneniami na konkrétne zdroje a akcie.
• Bezpečné volanie medzi službami: odporúča sa využívať autorizáciu založenú na identite (napr. signované požiadavky alebo workload identity), čím sa eliminuje používanie zdieľaných tokenov.
• Krátkodobé prihlasovacie údaje: implementácia federácie identít a vydávanie dočasných tokenov; zakázané je používanie statických kľúčov priamo v kóde.
• Oddelenie účtov a projektov: produkčné a neprodukčné prostredia by mali byť spravované v samostatných účtoch alebo projektoch s centrálnou správou bezpečnostných zásad.

Správa tajomstiev a kryptografické opatrenia

• Secrets Manager a KMS: citlivé údaje sa nikdy neukladajú v prostredí ako textové premenné, ale dynamicky sa načítavajú na požiadanie s krátkym cachingom.
• Automatická rotácia: pravidelná automatizovaná zmena kľúčov a hesiel vrátane správy verzií tajomstiev a riadeného nasadzovania.
• Šifrovanie: zabezpečené dáta by mali byť vždy šifrované počas prenosu (in transit) pomocou TLS/mTLS a tiež v pokojovom stave (at rest) pomocou poskytovateľských alebo zákazníckych šifrovacích kľúčov so správne definovanými politikami.
• Ochrana citlivých údajov v logoch: aplikovanie redakcie alebo maskovania priamo v loggeroch a na úrovni API gateway, aby sa predišlo úniku osobných alebo iných citlivých informácií.

Bezpečnostné hranice: API brána, fronty správ a eventy

• API Gateway: využitie Web Application Firewallu (WAF), limitácie počtu požiadaviek (rate limiting), zabezpečenie privátnych API cez mTLS a validácia vstupných dát pomocou schém ako OpenAPI či JSON Schema.
• Event-driven architektúra: implementácia autorizácie na úrovni topicov alebo queue, nasadenie dead-letter queues (DLQ) a retry mechanizmus bez vzniku nekonečných spracovateľských slučiek.
• Dátové prúdy: uplatnenie ACL na úrovni partitionov, monitorovanie oneskorení spracovania (lag monitoring) a použitie idempotentných konzumentov pre zabránenie duplicitnej práce.

Sieť a kontrola egressu

• Privátna konektivita: používanie privátnych endpointov pri prístupe k databázam či tajomstvám, vyhýbanie sa verejnému internetu pokiaľ to nie je nevyhnutné.
• Proxy pre egress: kontrola výstupných spojení na základe DLP, zoznamov povolených URL a centralizovaná evidencia egress aktivít.
• Integrácia s VPC: pozornosť pri konfigurácii kvôli potenciálnemu nárastu latencie pri cold-startoch a limitom počtu socketov; nastavenie bezpečných Security Group a Network Security Group pravidiel.

Integrita buildov a nasadených artefaktov

• Reprodukovateľné buildy a SBOM: zabezpečenie opakovateľnosti zostavenia aplikácie a vedenie detailného zoznamu závislostí (Software Bill Of Materials), podpísanie deployment balíčkov či kontajnerov a vynútenie týchto pravidiel na platforme.
• Politiky ako kód (Policy as Code): používanie nástrojov ako OPA/Rego alebo natívnych cloudových politik na validáciu infraštruktúry a konfigurácie funkcií (nastavenie timeoutov, pamäte, egressu, rolí).

Bezpečnosť počas runtime a hardening

• Timeouty a limit pamäte: nastavenie konzervatívnych limitov pre jednotlivé funkcie na zabránenie DoS útokom spôsobeným nekonečnými slučkami alebo nadmerným využívaním zdrojov.
• Vyhnutie sa perzistentným dátam: minimalizovať ukladanie dát mimo dočasného priestoru /tmp; citlivé dáta ukladajte výhradne do spravovaných šifrovaných úložísk.
• Bezpečné parsovanie vstupov: zaviesť limity na veľkosť požiadaviek, preferovať streaming pred plným načítaním do bufferu, používať knižnice odolné voči útokom typu zip-bomb alebo XXE (XML External Entity).

Idempotencia, obnoviteľnosť a odolnosť systému

• Idempotentné handlery: implementácia mechanizmov na deduplikáciu pomocou unikátnych kľúčov, podmienené zápisy a kontrola správneho poradia spracovania udalostí.
• Dead-letter queue a parkovanie chýb: separácia chýb obchodnej logiky od dočasných porúch, využitie metrik DLQ ako indikátorov pre spustenie bezpečnostných či prevádzkových procesov.
• Backoff a jitter: uplatnenie exponenciálneho oneskorenia a náhodného jitteru pri retry mechanizmoch, aby sa predišlo zhoršovaniu preťaženia systému.

Observabilita: logovanie, metriky a trasovanie

• Štruktúrované logy: využitie formátu JSON s polami ako trace_id, span_id, correlation_id, tenant, pii_redacted a severity, čo umožní efektívne prehľadávanie a spracovanie dát.
• Distribuované trasovanie: propagácia kontextu pomocou štandardu W3C Trace Context cez API Gateway a fronty správ vrátane zaznamenania cold a warm startov serverless funkcií.
• Metriky výkonu: sledovanie percentilov latencie (p50, p95, p99), chybovosti, počtu vyvolaní, počtu throttle udalostí a využitia pamäte a CPU, ktoré poskytuje cloudový poskytovateľ.
• Vzorkovanie logov: adaptívne vzorkovanie počas špičiek záťaže, s prioritou logovania chýb (error-first) a analýzou chýb na konci sledovania (tail-based sampling) na odhalenie anomálií.

Odporúčané schéma pre štruktúrované logovanie

Riadenie nákladov na logovanie a telemetriu v serverless

Efektívne riadenie nákladov na logovanie a telemetriu je kľúčové pre udržateľnosť serverless riešení. Odporúča sa nastaviť cielené agregovanie a filtrovanie logov, využiť vzorkovanie a uchovávať dáta len po nevyhnutne dlhú dobu. Využitie cloudových nástrojov na analýzu a archívovanie môže výrazne znížiť finančné zaťaženie pri zachovaní kvality dohľadu.

Zároveň je vhodné pravidelne revidovať monitorovacie a bezpečnostné politiky tak, aby odrážali aktuálne hrozby a architektonické zmeny v prostredí. Celkový prístup k bezpečnosti v serverless infraštruktúre by mal byť holistický a dynamický, pričom kombinuje prevenciu, detekciu aj reakciu na incidenty s cieľom maximalizovať ochranu dát a služieb.