Model sdílené odpovědnosti

Proč je model sdílené odpovědnosti klíčový

Model sdílené odpovědnosti definuje hranici mezi tím, za co odpovídá poskytovatel cloudových služeb (CSP), a za co zákazník (spotřebitel cloudu). Bez jasného rozdělení povinností vznikají bezpečnostní mezery, které patří mezi nejčastější příčiny incidentů v cloudu. Cílem tohoto článku je vysvětlit principy modelu napříč IaaS, PaaS, SaaS i novějšími službami (kontejnery, serverless, spravované databáze, AI), včetně praktických doporučení, metrik a kontrolních seznamů.

Základní princip: kdo spravuje „zdi“ a kdo „obsah“

Poskytovatel typicky zabezpečuje fyzickou infrastrukturu, virtualizační vrstvu a základní služby platformy. Zákazník zabezpečuje konfiguraci účtů a identit, data, aplikace a procesy jejich správy. Hranice je dynamická: čím více „spravovaná“ je služba, tím více přechází odpovědnost na poskytovatele, ale odpovědnost za data a jejich použití zůstává vždy na zákazníkovi.

Rozdíly dle servisního modelu: IaaS, PaaS, SaaS

• IaaS – CSP spravuje datacentrum, síť, hypervizor a hardware. Zákazník spravuje operační systémy VM, kontejnery, middleware, aplikace, data, identity a síťové politiky v tenantovi.
• PaaS – CSP navíc zajišťuje runtime, databázový engine, škálování. Zákazník konfiguruje síťové přístupy, šifrování, identity, parametry služby, a odpovídá za bezpečný kód, tajemství a data.
• SaaS – CSP spravuje aplikaci i platformu. Zákazník nastavuje přístupová práva, politiky sdílení, DLP, integrace, audit a nese odpovědnost za obsah, konfiguraci, compliance a životní cyklus uživatelů.

Specifika pro kontejnery a Kubernetes

• Managed K8s – CSP spravuje control plane, zákazník worker nody (pokud nejsou plně spravované), síťové politiky, RBAC, image, tajemství, admission kontroly, pod security kontext.
• Obrazy – zákazník odpovídá za SBOM, skenování zranitelností, podepisování (Sigstore), minimalizaci base image a rotaci tajemství.
• Multitenance – izolace mezi namespace nestačí; u citlivých workloadů preferovat dedikované clustery či pod-level sandboxing.

Serverless a „plně spravované“ služby

U funkcí a spravovaných databází/queue služeb CSP spravuje OS, runtime, škálování a patching. Zákazník spravuje triggery, politiky přístupu (IAM), validaci vstupů, síťové perimeter-less modely (VPC vazby), kryptografii dat a logování. Přestože se snižuje provozní zátěž, roste význam konfigurace a správného použití služeb.

Identity a přístup: dlouhodobé klíče vs. krátkodobé tokeny

• Odpovědnost CSP – dostupnost a bezpečnost IAM služby, kryptografické primitivy.
• Odpovědnost zákazníka – princip nejmenších oprávnění, přiřazování rolí přes skupiny, absolutní minimální použití statických klíčů, MFA, passkeys, JIT přístupy, oddělení produkce/testu, správa strojových identit a rotace tajemství.
• Pokročilé řízení – CIEM pro analýzu nadměrných oprávnění, policy-as-code a guardrails v pipeline.

Data: klasifikace, šifrování a klíče

• Klasifikace – rozdělit data (veřejná, interní, citlivá, regulovaná) a aplikovat odpovídající DLP a retenční politiky.
• Šifrování v klidu a přenosu – volit vždy zapnuto, preferovat správu klíčů v KMS/HSM, pro vysoce citlivá data uvažovat BYOK nebo HYOK.
• Správa klíčů – rotace, oddělení rolí, audit přístupů, ochrana před omylnou delecí klíče, test dešifrovatelnosti záloh.

Síť a segmentace v cloudu

CSP dodává základní izolaci tenantů a regionální separaci. Zákazník navrhuje VPC/VNet topologii, subnety, security groups, síťové ACL, privátní endpointy, WAF, rate-limiting, DDoS plány a mikrosegmentaci mezi workloady. Zero Trust znamená ověřování identity, kontextu a stavu zařízení při každém spojení, i uvnitř cloudu.

Konfigurace služeb: nejčastější zdroj rizika

• Otevřené storage buckety – zákazník odpovídá za policy, blokaci veřejného přístupu a šifrování.
• Exponované management rozhraní – vyžadovat privátní přístup, PAM a schvalování změn.
• Nadměrná oprávnění IAM – zavést recertifikaci přístupů a automatizované kontroly.

DevSecOps a supply chain bezpečnost

• Pipeline – skenování kódu (SAST), závislostí (SCA), běhové testy (DAST), integrační testy a policy gates.
• Artefakty – podepisování, SBOM, repozitáře s politikou důvěry a karanténou.
• Infra-as-Code – OPA/policy-as-code, skenování Terraform/ARM/CloudFormation před nasazením, drift detection.

Observabilita, logy a forenzika

CSP zajišťuje telemetrii platformy a auditní stopy. Zákazník musí centralizovat logy (SIEM), povolit detailní audit pro kritické služby, nastavit retenci, nepopiratelnost (WORM/immutable), definovat detekční pravidla (MAP na MITRE ATT&CK) a pravidelně testovat forenzní postupy (izolace instancí, snapshoty, export logů).

BC/DR: dostupnost, zálohy a regionální strategie

• Dostupnost – využívat zónovou redundanci, multi-region architektury a automatické škálování.
• Zálohování – strategie 3-2-1-1-0, test obnovy, oddělená backup doména, ochrana před ransomwarovým mazáním.
• RTO/RPO – měřitelné cíle s pravidelnými cvičeními, dokumentovaný runbook a odpovědnosti.

Compliance a regulace

CSP poskytuje certifikace (ISO/IEC 27001, SOC 2, PCI DSS, HIPAA aj.) a sdílené artefakty (reporty, auditní záznamy). Zákazník nese odpovědnost za mapování kontrol ke konkrétnímu použití, Data Processing Agreements, lokalitu dat, privacy-by-design a řízení práv subjektů údajů. V multi-cloudu je nutné sladit rozdílné implementace kontrol.

RACI a smluvní vymezení

Pro každou službu vypracujte RACI matici (Responsible, Accountable, Consulted, Informed). Smluvně ošetřete SLA (dostupnost, podpora), zodpovědnost za incidenty, oznamovací lhůty, penetrační testy a pojistné krytí. V rámci organizace definujte jasné rozhraní mezi týmy SecOps, DevOps, NetOps, FinOps.

Model sdílené odpovědnosti pro AI a data science

• Poskytovatel – bezpečnost trénovací infrastruktury, izolace tenantů, dostupnost modelových endpointů.
• Zákazník – governance dat, ochrana před data leakage, řízení prompt injection, filtrování výstupů, API key management, validace výsledků a audit experimentů.

Rozšíření: „shared fate“ a odpovědnost za výsledek

Někteří poskytovatelé rozvíjejí koncept shared fate, kdy kromě sdílené odpovědnosti nabízejí guardrails, šablony a automatizované kontroly, jež snižují riziko chyb konfigurace. Zákazník však i nadále nese odpovědnost za správné použití (enablement, governance, dohled a reakci).

Metriky zralosti a průběžné vyhodnocování

• Pokrytí kontrol – procento služeb s povolenými cloud-native bezpečnostními funkcemi (šifrování, audit, privátní endpointy).
• MTTD/MTTR – čas do detekce a nápravy cloudových incidentů.
• Drift a odchylky – měsíční počet odhalených a uzavřených config drift případů.
• Least privilege skóre – míra nadměrných oprávnění dle CIEM.
• Test obnovy – frekvence a úspěšnost DR cvičení, procento kritických workloadů s ověřeným RTO/RPO.

Bezpečnostní nástroje a automatizace

• CSPM – průběžná kontrola konfigurací a souladu (misconfig, public exposure, šifrování, tagování).
• CIEM – analýza a oprava nadměrných oprávnění IAM.
• CWPP – ochrana workloadů (VM, kontejnery, serverless) v běhu, hardening a detekce chování.
• DSPM – data security posture management pro objevování, klasifikaci a řízení rizik dat napříč cloudy.
• Infra-as-Code skenery – prevence chyb před nasazením, policy-as-code jako brány v CI/CD.

Typické scénáře a hraniční případy

• Marketplace image – kdo patchuje? Pokud není explicitně „managed“, patchování OS je na zákazníkovi.
• Managed databáze – CSP patchuje engine; zákazník nastavuje síť, šifrování, přístup, audit a logiku obnovy.
• Bring Your Own License – odpovědnost za licenční compliance a bezpečný deployment je na zákazníkovi.
• Cross-region replikace – CSP poskytuje mechaniku, zákazník rozhoduje o geo-compliance a konsistenci.

Incident response v cloudu

IR plán musí reflektovat API-first přístup: izolace prostředí (tagy, politiky), záchytné snapshoty, spolupráci s CSP podporou, právní a compliance kroky, notifikaci zákazníků a rotaci klíčů. Důležitá je viditelnost (telemetrie), automatizace (playbooky, SOAR) a kontrolované cvičení (table-top, purple teaming).

Kontrolní seznam minimálních opatření

• Zapnout default šifrování a audit u všech služeb; logy směrovat do centrálního SIEM s immutable úložištěm.
• Implementovat MFA/Passkeys a least privilege s pravidelnou recertifikací přístupů; omezit statické klíče.
• Nastavit privátní konektivitu a WAF/DDoS ochranu pro veřejné služby; mikrosegmentaci uvnitř cloudu.
• Nasadit CSPM/CIEM/CWPP/DSPM a policy-as-code v CI/CD; skenovat IaC a kontejnery.
• Upravit backup/DR s testy obnovy, oddělenou doménou a ochrannými rolemi.
• Definovat RACI, IR playbooky, pravidelná cvičení a metriky zralosti.

Praktický příklad rozdělení odpovědností

• Spravovaná DB (PaaS) – CSP: patching, HA, fyzická bezpečnost; zákazník: schéma a data, IAM, síťový přístup, šifrování klíči v KMS, DLP, auditní logy, zálohy a retence.
• VM v IaaS – CSP: hypervizor, fyzická síť; zákazník: OS hardening, patching, EDR/XDR, firewall na hostu, šifrování disků, rotační klíče, monitoring.
• SaaS kolaborační nástroj – CSP: aplikační bezpečnost a dostupnost; zákazník: správa tenant politik (sdílení, retention, DLP), lifecycle uživatelů, audit přístupů, integrace s IdP.

Závěr: sdílená odpovědnost jako průběžná disciplína

Model sdílené odpovědnosti není jednorázový dokument, ale operativní rámec pro každodenní rozhodování. Přijetím policy-as-code, automatizovaných kontrol, měřitelných metrik a pravidelného tréninku lze minimalizovat chyby konfigurace a zrychlit reakci na hrozby. Bez ohledu na typ služby platí, že za správu identit, konfigurací a dat nese odpovědnost zákazník – a právě v tom spočívá síla i závazek cloudu.