Cloud a sdílená odpovědnost: Devět z deseti průniků máte na svědomí vy

Slýcháme to v každé druhé firmě: „Naše data jsou v cloudu, takže o bezpečnost se stará Microsoft / AWS / Google." Plus pokrčení ramen, jako že je tohle téma vyřízené.

V tom okamžiku obvykle někdo z bezpečnostního týmu nasadí lehce trpitelský výraz, protože ví, co dnes nebo zítra řeknou statistiky. A statistiky jsou nemilosrdné: Gartner už několik let v řadě tvrdí, že 99 % cloudových bezpečnostních incidentů vzniká chybou zákazníka, ne providera. IBM ve své zprávě Cost of a Data Breach Report 2025 přidává, že průměrná doba identifikace průniku je 158 dní, u veřejných cloudů celý cyklus (identifikace + zvládnutí) trvá 251 dní – přes osm měsíců.

V cloudu se nelámou hypervisory. Lámou se konfigurace.

Pojďme se podívat, co to znamená v praxi – a co konkrétně z toho plyne pro IT specialistu, který má svou firmu dotáhnout do souladu se zákonem č. 264/2025 Sb.

Co vlastně sdílíte

Sdílená odpovědnost je princip, na kterém stojí byznys model všech hyperscalerů. AWS to nazývá Shared Responsibility Model, Microsoft Shared Responsibility, Google se v poslední době přiklání k pojmu Shared Fate. Pojmenování se liší, princip je stejný:

Provider zodpovídá za bezpečnost cloudu jako takového. Vy zodpovídáte za bezpečnost v něm.

V praxi to znamená, že provider drží:

• fyzické datacentrum (kontrolovaný přístup, kamery, EMI ochrana, hašení),
• hardware (servery, disky, síťové prvky),
• hypervisor a izolaci tenantů,
• páteřní síť mezi regiony,
• dostupnost samotné služby v rámci SLA.

A vy držíte všechno ostatní:

• konfigurace všech zdrojů (S3 buckety, security groups, NSG, VPC, firewall rules),
• identity a přístupy (IAM uživatelé, role, klíče, tokeny),
• šifrování dat (v klidu i při přenosu),
• patchování operačních systémů a aplikací (v IaaS),
• monitoring a detekci anomálií,
• zálohování (ano, opravdu),
• klasifikaci a retence dat,
• compliance.

Když uvidíte oblíbený obrázek shared responsibility ve stylu „šachovnice", neignorujte ho. Je to nejdůležitější diagram pro pochopení, kde leží vaše právní odpovědnost. Když dojde k úniku přes špatně nastavený S3 bucket, AWS vás u soudu neobhájí. Bucket byl ve vašem účtu, politika byla ve vaší správě, „Block Public Access" jste vypnuli vy. 

Hranice se posouvá podle typu služby

A teď to dostává zajímavou dimenzi, kterou managementu vysvětlíte těžko, ale která je v praxi klíčová: hranice odpovědnosti se posouvá podle servisního modelu.

IaaS (Infrastructure as a Service) – například AWS EC2, Azure Virtual Machines, GCP Compute Engine. Provider drží železo a virtualizaci. Vy držíte úplně všechno nad tím: OS, patche, runtime, aplikace, data. Pokud si pustíte Ubuntu 20.04 a nepatchujete ho, je to váš problém. Pokud má v kernelu CVE-2024-XYZ zveřejněnou minulý čtvrtek a vy jste ji nezapatchovali do pondělí, hackeři mají dveře dokořán a u soudu vás SLA neochrání.

PaaS (Platform as a Service) – AWS Lambda, Azure App Service, GCP Cloud Run. Provider drží železo, virtualizaci, OS, runtime. Vy držíte aplikační kód, konfiguraci runtimu a hlavně data, identity a přístupy. OS patche už jsou jejich – ale data, IAM a šifrování stále vaše.

SaaS (Software as a Service) – Microsoft 365, Google Workspace, Salesforce, GitHub. Provider drží téměř všechno. Vy ale stále držíte: identity (kdo se přihlásí), oprávnění (co může dělat), data (klasifikace, retence, exfiltrační kontrola) a konfiguraci samotné služby (sharing settings, externí přístupy, audit logy).

Zapamatovatelné pravidlo, které funguje pro všechny modely: data, identity a konfigurace jsou vždycky vaše. Bez výjimek. Ve všech servisních modelech. Ve všech cloudech.

Kde se to nejčastěji rozsype

Pojďme si projít tři oblasti, kde IT specialisté nejčastěji selhávají – a kde také nejčastěji prasknou breaching kauzy v médiích.

1. Defaultní konfigurace

Tohle je nejtřeskutější téma. Defaultní nastavení cloudových služeb optimalizuje na rychlost nasazení, ne na bezpečnost. Vývojář si vytvoří S3 bucket pro test, klikne na pár checkboxů, do produkce projde release – a bucket s testovacími daty (která jsou někdy reálná!) zůstane veřejně přístupný.

Konkrétní defaulty, které stojí za audit:

• AWS S3: buckety byly vždy private by default. Od dubna 2023 mají nové buckety navíc automaticky aktivované S3 Block Public Access a vypnuté ACLs (vytvořené přes API, CLI, SDK i CloudFormation). „Block Public Access" lze stále vypnout. Starší buckety vytvořené před dubnem 2023 nemají tuto ochranu automaticky aktivní.
• AWS Security Groups: výchozí SG povoluje veškerou odchozí komunikaci na 0.0.0.0/0.
• Azure Storage Accounts: veřejný přístup může být povolen na úrovni účtu i kontejneru.
• Azure NSG: výchozí pravidla povolují většinu vnitrosíťové komunikace.
• GCP Cloud Storage: veřejné buckety vyžadují manuální akci, ale je to jeden klik.
• GCP Firewall: „default-allow-internal" povoluje všechen provoz v rámci VPC.

A pak ty drobnosti, které „nejsou tak vidět":

• CloudTrail (AWS) / Activity Log (Azure) / Cloud Audit Logs (GCP) nejsou implicitně zapnuté ve všech regionech.
• Šifrování při přenosu mezi službami je obvykle TLS, ale šifrování v klidu (encryption at rest) musí být explicitně povolené u většiny služeb.
• Backup u managed databází (RDS, Azure SQL, Cloud SQL) má často default retenci 7 dní, někdy 1 den. Pokud byste chtěli déle, musíte to nastavit.

Kdo nečte AWS Well-Architected Framework, Azure Security Baseline nebo GCP Security Foundations Blueprint, nedělá svou práci. Tečka.

2. IAM – tichý zabiják

Druhá oblast, kde začíná většina cloudových průniků. Verizon DBIR 2025 uvádí, že ukradené přihlašovací údaje jsou iniciální vektor 22 % všech průniků a u útoků na základní webové aplikace dokonce 88 %. Identity and Access Management je v cloudu jediný reálný perimetr – tradiční síťová hranice tu nefunguje, protože vaše služby žijí v multitenantním prostředí.

Typické problémy:

• Wildcard oprávnění. Politika s "Action": "s3:*", "Resource": "*" se napíše rychle a funguje. Také ale dává komukoli s tou rolí přístup ke všem bucketům v účtu, nejen k tomu, který chcete.
• Dlouho neměněné access keys. AWS access keys, které někdo vytvořil v roce 2022, fungují dodnes. Pokud je nerotuje (a 90 dní je dobré pravidlo), pak unikající klíč z GitHub commitu z roku 2023 funguje pořád.
• Service accounts s nadbytečnými oprávněními. EC2 instance role, Lambda execution role, GKE service account – často mají oprávnění typu „pro jistotu trochu víc". Pokud takovou instanci/funkci kompromituje útočník, dostane oprávnění celé role.
• AdministratorAccess (AWS) / Owner (Azure, GCP) pro někoho, kdo to nepotřebuje. Princip nejmenšího oprávnění není v cloudu volitelný.
• Žádné MFA na privilegované účty. Heslo bez druhého faktoru je v roce 2026 stejné jako mít vchodové dveře místo zámku zalepené páskou.

Reálný případ: v roce 2019 utrpěla Capital One průnik 106 milionů zákaznických záznamů. Útok šel přes špatně nakonfigurovaný WAF, který umožnil SSRF útok na metadata endpoint. Útočník získal AWS credentials připojené k EC2 instanci a tyto credentials měly oprávnění číst všechny S3 buckety v účtu. Cloudová infrastruktura nebyla prolomena – byly prolomeny konfigurace a IAM práva.

3. Zálohy: nejvíc nepříjemné překvapení

Tohle je oblast, kde dochází k největším nedorozuměním – a často až ve chvíli, kdy je pozdě.

Cloud SLA není totéž, co zálohy. AWS S3 garantuje 99,999999999 % trvanlivost dat (jedenáct devítek), což je úžasné. Ale když někdo s patřičnými právy soubor smaže, AWS ho už neobnoví. Trvanlivost se týká hardwarových selhání, ne lidských.

Versioning není totéž, co backup. Když máte na bucketu zapnutý versioning, smazaný soubor je sice obnovitelný. Pokud ale útočník získá oprávnění a smaže i historické verze (s3:DeleteObjectVersion), je všechno pryč.

Managed služby mají vlastní retenci, kterou musíte nastavit. RDS default často 7 dní. Pokud chcete měsíční retenci, musíte si ji nakonfigurovat, někdy doplnit přes AWS Backup. Azure SQL Database má vlastní long-term retention. GCP Cloud SQL podobně.

SaaS data si musíte zálohovat sami. Microsoft 365 a Google Workspace nezálohují vaše data ve smyslu, jaký byste očekávali od enterprise backup řešení. Mají retenční politiky pro smazané položky (typicky 30–93 dní), ale to není totéž jako point-in-time obnova z minulého roku. Pokud uživatel smaže celý mailbox a zjistíte to po 100 dnech, máte problém. Pro skutečnou ochranu potřebujete externí backup řešení (Veeam, Druva, Spanning, AvePoint...).

Klíčový princip: pokud nemáte 3-2-1 i v cloudu, žádné zálohy nemáte. Tři kopie dat, dvě různé technologie/lokace, jedna mimo provozní účet (ideálně mimo cloud nebo v jiném tenantu/účtu).

Co k tomu říká český zákon

Zákon č. 264/2025 Sb. cloud explicitně nezakazuje ani nepreferuje. Říká však jasně, že bezpečnostní opatření se vztahují na celé regulované služby, bez ohledu na to, jestli běží lokálně, hybridně nebo v cloudu.

Z toho plyne několik konkrétních povinností.

Vyhláška 409/2025 Sb. (vyšší režim) v § 9 a v příloze č. 5 popisuje řízení dodavatelů. Cloudový poskytovatel je významný dodavatel, takže smlouva (často SLA, který přijímáte click-through) musí zahrnovat:

• bezpečnostní opatření na straně poskytovatele,
• právo na audit (alespoň ve formě poskytnutí auditních zpráv typu SOC 2, ISO 27001),
• povinnost informovat o bezpečnostních incidentech,
• exit strategii (jak data dostat zpět),
• sankce za nedodržení.

Reálně to znamená, že místo akceptace clickwrap smluv musíte přejít na enterprise smluvní vrstvu (AWS Enterprise Agreement, Microsoft Enterprise Agreement, Google Cloud reseller přes Cloud4Y nebo podobné).

Vyhláška 410/2025 Sb. (nižší režim) je v požadavcích mírnější, ale i tady platí povinnost mít přehled o dodavatelích a jejich roli.

Vyhláška 412/2025 Sb. se týká specificky orgánů veřejné správy využívajících cloud computing – pokud cílíte na zákazníky z veřejné správy, jejich nákupní procesy se budou této vyhlášky držet a budou po vás chtít konkrétní bezpečnostní úrovně.

A pak je tu hlášení incidentů. Pokud váš poskytovatel cloudu zaznamená incident, který ovlivňuje vaši regulovanou službu, máte 24 hodin na první hlášení NÚKIB. To platí i tehdy, když „za to může cloud" – z pohledu zákazníka jste regulovaný subjekt vy, ne hyperscaler.

Praktický checklist pro IT specialistu

Pokud máte hodinu času a chcete v cloudu kriticky zhodnotit, kde stojíte, projděte si toto. Není to vyčerpávající seznam (to by byl Well-Architected Framework s rozsahem 200+ stran), ale je to top dvacet bodů, které řeší 80 % nejčastějších incidentů.

Identity:

• [ ] MFA povinné pro všechny lidské uživatele, bez výjimek.
• [ ] Root účet (AWS) / Global Admin (Azure) / Org Admin (GCP) se nepoužívá pro každodenní práci.
• [ ] Žádné dlouho-trvající access keys – federace s vaším IdP (Okta, Entra ID, Google) nebo IAM Identity Center / Azure AD.
• [ ] Audit IAM politik s wildcardy alespoň jednou za půl roku.
• [ ] Rotace API klíčů max. po 90 dnech.

Konfigurace:

• [ ] Žádný S3 bucket / Storage account / Cloud Storage bucket není veřejný, pokud k tomu není explicitní byznys důvod.
• [ ] Šifrování at-rest je zapnuté všude (S3 SSE, EBS encryption, Azure Storage SSE, GCP CMEK).
• [ ] TLS 1.2+ minimum pro veškerou komunikaci.
• [ ] Security Groups / NSG / Firewall rules nepovolují 0.0.0.0/0 na management porty (SSH, RDP, databáze).

Zálohy & DR:

• [ ] Zálohy běží podle dokumentované politiky (RPO, RTO, retence).
• [ ] Zálohy jsou v jiném regionu/účtu/tenantu – ne ve stejném prostředí jako produkce.
• [ ] Test obnovy se provádí alespoň jednou ročně. Skutečně se provádí, ne jen píše v politice.
• [ ] M365 / Google Workspace data zálohujete externím nástrojem.

Monitoring & detekce:

• [ ] CloudTrail / Activity Log / Audit Logs zapnuté ve všech regionech, posílané do SIEM (nebo alespoň do centrálního logování).
• [ ] CSPM nástroj sleduje konfigurační drift (AWS Security Hub, Microsoft Defender for Cloud, GCP Security Command Center, nebo cross-cloud Wiz/Prisma Cloud/Lacework).
• [ ] Definovaná alerty pro: nové IAM role s admin oprávněními, změny v security groups, otevření portu 22/3389 na 0.0.0.0/0, vytvoření veřejných bucketů.
• [ ] Runbook pro incident response specifický pro cloud (kdo má root oprávnění izolovat instanci, jak se forenzně získává image atd.).

Pokud má váš management pochybnost, jestli má smysl do toho investovat, ukažte mu jeden statistický údaj: průměrný čas k identifikaci průniku je více než pět měsíců, u veřejných cloudů přes osm měsíců do plného zvládnutí. Osm měsíců s otevřenými dveřmi.

Závěr: kdo na to skutečně dohlíží

Tady je nepříjemná pravda, kterou ve firmě nikdo neříká: shared responsibility model nefunguje sám od sebe. Provider vám pošle hezkou tabulku, řekne „takhle to máte", a tím to končí. Žádný cloud provider vám nezavolá, když máte veřejný S3 bucket s 2,6 milionu zákaznických záznamů. Žádný cloud provider vám nepošle alert, že vaše IAM role má *:* oprávnění. Žádný cloud provider vás nepřinutí zálohovat.

To je vaše práce. A v kontextu zákona 264/2025 Sb. už ne práce „nice to have" – ale práce, kterou musíte umět doložit dokumentovaně, s evidencí změn, hodnocením rizik a plánem řešení.

Pokud potřebujete pomoc s tím, jak cloudovou agendu zarámovat do požadavků vyhlášek 409/410 (a popřípadě 412), Kraita Cyber One vám pomůže: zmapuje cloudové dodavatele jako součást dodavatelského řetězce, projde s vámi GAP analýzu konkrétně pro cloudové prostředí, vygeneruje dokumentaci podle metodiky NÚKIB a propojí ji s vašimi existujícími technickými kontrolami v AWS/Azure/GCP.

→ Vyzkoušejte demo zdarma

Nebo 15 minut nezávazně s naším týmem – bez přesvědčování, jen konkrétní odpovědi.

A jestli vám teorie nestačí a chcete vidět, jak shared responsibility selhává v praxi – příští díl série Skutečné příběhy z kyberprostoru se přesně tomu věnuje. Jeden velký výrobce aut, 800 000 elektromobilů, GPS souřadnice na centimetry přesně, žádný útočník není potřeba. Jen špatně nastavený cloud bucket. Vyjde tento pátek.

Zdroje

• Gartner: Through 2025, 99% of cloud security failures will be the customer's fault (původně predikce 95% do 2020, postupně aktualizovaná)
• IBM Cost of a Data Breach Report 2025 (lifecycle průniků: 158 dní identifikace + 83 dní zvládnutí, public cloud 251 dní)
• Verizon Data Breach Investigations Report 2025 (22 % průniků přes ukradené credentials, 88 % útoků na základní web aplikace)
• Tenable: Cloud Security Risk Report 2025
• AWS Shared Responsibility Model – aws.amazon.com/compliance/shared-responsibility-model
• Microsoft Shared Responsibility for Cloud Computing – learn.microsoft.com
• Google Cloud Shared Fate Model – cloud.google.com/blog
• CISA Binding Operational Directive 25-01 (cloud configuration)
• Capital One Data Breach 2019 – případová studie SSRF + IAM misconfiguration
• Zákon č. 264/2025 Sb., zákon o kybernetické bezpečnosti
• Vyhláška č. 409/2025 Sb., § 9 a příloha č. 5 (řízení dodavatelů, smluvní ustanovení)
• Vyhláška č. 410/2025 Sb. (režim nižších povinností)
• Vyhláška č. 411/2025 Sb. (bezpečnostní úrovně ISVS)
• Vyhláška č. 412/2025 Sb. (bezpečnostní pravidla pro orgány veřejné správy využívající cloud)

‍