Datová suverenita a bezpečnost: proč citlivá data nepatří do veřejného cloudu

• Hodnocení citlivosti dat
• Datová suverenita a jurisdikce
• Klasifikace dat a rozložení rizika
• Modely cloudových služeb a rozdělení odpovědnosti
• Regulatorní požadavky
• On-premise infrastruktura
• Hybridní model
• Certifikace a auditní zprávy
• Jak se rozhodnout

Hodnocení citlivosti dat

Při hodnocení citlivosti dat nestačí sledovat pouze jejich obsah, protože významnou roli hrají také důsledky případného incidentu. Výrobní dokumentace může představovat zásadní konkurenční výhodu, zatímco nedostupnost provozní databáze dokáže zastavit výrobu i bez jediného uniklého souboru. Do hodnocení proto patří možné finanční škody, dopad na zákazníky a doba, po kterou může firma daný systém postrádat.

Pokud je veřejný cloud správně navržen a konfigurován, může nabídnout stejnou nebo vyšší úroveň ochrany než vlastní infrastruktura. Velcí poskytovatelé investují značné prostředky do zabezpečení datacenter, monitoringu a obrany proti rozsáhlým útokům. Podnik však část přímé kontroly nahrazuje smluvním vztahem, takže potřebuje přesně rozumět tomu, co dodavatel skutečně garantuje a které části zabezpečení zůstávají na zákazníkovi.

Datová suverenita a jurisdikce

Datová suverenita začíná kontrolou nad celým životním cyklem dat. Umístění dat popisuje, ve které zemi nebo regionu se nachází hlavní databáze. Datová suverenita sahá dál a zahrnuje právní i technickou kontrolu nad informacemi od jejich vzniku až po konečné odstranění. Evropské datacentrum je důležitým parametrem, ale samo neprozradí, odkud pracuje technická podpora nebo kde vznikají záložní kopie.

Část informací může zvolený region opouštět, aniž by šlo o obsah dokumentů nebo databází. Diagnostické záznamy, uživatelské identifikátory a provozní metadata mohou prozradit citlivé informace o interních systémech. Před podpisem smlouvy je proto potřeba zjistit, jak služba zachází také s těmito vedlejšími daty a kteří subdodavatelé se na zpracování podílejí.

Právní požadavky se mohou odvíjet nejen od umístění datacentra, ale také od sídla poskytovatele a zapojených subdodavatelů. U citlivých dat je zároveň podstatné, zda lze vzdálený zásah pracovníka podpory předem schválit a následně dohledat. Pokud dodavatel nedokáže popsat své administrátorské přístupy nebo celý řetězec subdodavatelů, firma jen obtížně prokáže, že má riziko pod kontrolou.

Správa šifrovacích klíčů

Jedním z důležitých parametrů datové suverenity je správa šifrovacích klíčů, pomocí kterých se zašifrovaná data uzamykají a znovu zpřístupňují. Zjednodušeně fungují jako klíč od trezoru: kdo je ovládá, může data dešifrovat, případně k nim přístup zablokovat. Pokud klíče vytváří a uchovává výhradně cloudový poskytovatel, firma se spoléhá na jeho procesy a oprávnění. Některé služby proto umožňují, aby si organizace klíče spravovala sama a mohla je v případě potřeby zneplatnit. Ani toto řešení však automaticky nezaručuje, že poskytovatel nikdy nepracuje s daty v dešifrované podobě, protože během samotného zpracování mohou být informace dočasně dešifrovány uvnitř cloudové infrastruktury. Rozhodující je proto celá architektura služby, nejen místo, kde jsou klíče uloženy.

Klasifikace dat a rozložení rizika

O vhodném prostředí rozhoduje dopad incidentu. Jednotná cloudová strategie pro všechny firemní systémy bývá administrativně pohodlná, ale nemusí odpovídat skutečnému riziku. Veřejné marketingové materiály nevyžadují stejnou ochranu jako zdravotní dokumentace, zdrojové kódy nebo konstrukční podklady k novému výrobku. Nejvyšší úroveň izolace má smysl u dat, jejichž ztráta by způsobila závažnou a obtížně napravitelnou škodu.

Rizikem není pouze únik informací, protože závažné důsledky může mít také jejich neoprávněná změna. Pozměněný laboratorní výsledek, výrobní parametr nebo finanční záznam může napáchat větší škodu než jeho zveřejnění. U provozních systémů rozhoduje dostupnost, jelikož několikahodinová odstávka může stát více než samotná infrastruktura.

Dobře provedená klasifikace dat zároveň pomáhá rozdělit rozpočet podle skutečného rizika. Firma nemusí stavět nejdražší prostředí pro každou aplikaci, ale může soustředit investice na několik kritických systémů. Méně citlivé služby pak dál využijí pružnost veřejného cloudu, aniž by se do něj automaticky přesouvala nejcennější firemní aktiva.

Modely cloudových služeb a rozdělení odpovědnosti

Rozdělení bezpečnostních povinností není u každého cloudu stejné:

• U infrastruktury jako služby, tedy IaaS, poskytovatel spravuje datacentrum, fyzické servery a virtualizační vrstvu. Zákazník obvykle odpovídá za operační systém, jeho aktualizace, aplikace a nastavení síťových pravidel.
• U platformy jako služby, označované jako PaaS, přebírá dodavatel také správu operačního prostředí.
• SaaS posouvá hranici ještě dál, protože poskytovatel provozuje celou aplikaci.

Rozdílné rozdělení odpovědnosti se nejvýrazněji projeví při vzniku a vyšetřování bezpečnostního incidentu. K nechtěnému zveřejnění úložiště stačí jedno chybné nastavení ze strany zákazníka, přestože samotná platforma funguje podle návrhu. Útočník může robustní ochranu datacentra obejít také prostřednictvím kompromitovaného administrátorského účtu. U každé služby proto musí být zřejmé, které kontroly provádí dodavatel a co musí pravidelně ověřovat interní bezpečnostní tým.

Regulatorní požadavky

GDPR

Regulace mění technickou volbu v riziko pro vedení firmy. Z pohledu GDPR není rozhodující samotné umístění osobních údajů na vlastním serveru nebo ve veřejném cloudu, ale úroveň ochrany odpovídající riziku konkrétního zpracování. Organizace musí vybrat vhodného zpracovatele a nastavit odpovídající technická i organizační opatření. U přenosů mimo Evropský hospodářský prostor potřebuje také platný právní základ a posouzení skutečné úrovně ochrany.

Výše maximální sankce neznamená, že každý špatně nastavený cloudový projekt automaticky skončí pokutou ve stovkách milionů korun. Přesto jasně ukazuje, že závislost na externím dodavateli patří mezi témata, o kterých musí mít přehled také vrcholné vedení. Při výběru řešení je potřeba hodnotit smluvní podmínky, plán kontinuity a schopnost přejít k jinému dodavateli.

DORA pro finanční sektor

Pro finanční sektor přidává další vrstvu požadavků nařízení DORA, které se uplatňuje od 17. ledna 2025. Zaměřuje se na digitální provozní odolnost a rizika spojená s externími poskytovateli informačních a komunikačních technologií. Banka, pojišťovna nebo jiná regulovaná instituce proto sleduje také koncentraci klíčových procesů u jediného partnera a dopad jeho případného výpadku.

On-premise infrastruktura

On-premise infrastruktura běží ve firemních prostorách nebo v zařízení, které má organizace přímo pod kontrolou. Bezpečnostní tým může přesně vymezit síťové segmenty, omezit vzdálený přístup a řídit změny bez závislosti na možnostech veřejné služby. Tento model má největší hodnotu tam, kde podnik potřebuje provozní nezávislost nebo musí citlivá data držet v izolovaném prostředí.

S vyšší mírou kontroly se pojí odpovědnost za celý životní cyklus vlastní infrastruktury. Do rozpočtu nevstupuje jen cena serverů a úložišť, ale také jejich pravidelná obnova, spotřeba energie a servis. Významnou položkou jsou lidé, kteří infrastrukturu průběžně aktualizují, sledují její stav a dokážou ji obnovit po incidentu.

Samotné umístění serveru uvnitř firmy vyšší bezpečnost nezaručuje, pokud organizace zanedbává správu a kontrolu přístupů. Zastaralé systémy nebo příliš široká administrátorská oprávnění mohou vytvořit koncentrované riziko. On-premise dává smysl tehdy, když firma dokáže zajistit odbornou správu a má dostatečnou kapacitu pro poruchy i krátkodobé špičky.

Zálohy a obnova provozu

Odolnost vlastního prostředí proti ransomwaru výrazně zvyšují neměnné nebo offline zálohy, ke kterým se napadený účet nedostane. Útočníci se totiž často pokoušejí odstranit produkční data i běžně připojené záložní kopie. Takto oddělená záloha může rozhodnout o tom, zda firma obnoví provoz z vlastních zdrojů, nebo zůstane závislá na požadavcích útočníka.

Použitelnou obnovu nelze prokázat pouze existencí záložní kopie, protože problém se často ukáže až při jejím skutečném použití. Organizace musí ověřovat, zda jsou data čitelná a zda z nich dokáže v požadovaném čase zprovoznit kritické systémy. Pravidelný test může včas odhalit poškozené zálohy, chybějící systémové závislosti nebo postup, který je v praxi příliš pomalý.

Hybridní model

Kombinace více prostředí představuje pro řadu firem praktický způsob, jak vyvážit kontrolu nad citlivými daty s pružností cloudových služeb. Kritická databáze nebo systém správy identit může zůstat ve vlastní infrastruktuře, zatímco veřejný cloud obslouží zákaznický web, analytické úlohy nebo dočasné navýšení výkonu. Privátní cloud k tomu přidává automatizaci a pružnější přidělování prostředků ve vyhrazeném prostředí.

Přínos hybridního modelu závisí na tom, zda architektura skutečně respektuje zamýšlený tok informací. Aplikace provozovaná v cloudu může pravidelně kopírovat interní databázi a původní bezpečnostní záměr tím obejít. Návrh proto musí předem určit, která data smějí firemní prostředí opustit, zda se mají před přenosem omezit a jak bude každý přístup zaznamenán.

S rozdělením systémů mezi více prostředí rostou nároky na jednotnou správu a bezpečnostní dohled. Tým potřebuje společný přehled o přihlášeních a podezřelých událostech na obou stranách. Bez něj může část útoku zůstat viditelná pouze v cloudu a další část uvnitř firemní sítě, takže souvislosti nikdo včas nerozpozná.

Certifikace a auditní zprávy

Bezpečnostní certifikace a auditní zprávy pomáhají při prověřování dodavatele, jejich název však sám o sobě neříká, co bylo posouzeno. Certifikát se může vztahovat jen na konkrétní datacentrum, pobočku nebo část služby. Firma si proto potřebuje vyžádat přesný rozsah auditu a ověřit, zda pokrývá produkt i region, které plánuje používat.

Odlišný typ podkladu představuje zpráva SOC 2, která vzniká na základě nezávislého posouzení vybraných bezpečnostních a provozních kontrol organizace. Při hodnocení je důležité zjistit, zda jde o zprávu typu I, která hodnotí návrh kontrol k určitému datu, nebo typu II sledující jejich fungování během delšího období. V automobilovém průmyslu může být relevantní také TISAX, tedy oborový mechanismus pro hodnocení a sdílení výsledků auditů informační bezpečnosti mezi výrobci, dodavateli a dalšími partnery. Jeho vypovídací hodnota závisí na konkrétním rozsahu posouzení a přiděleném štítku TISAX.

Každé marketingové tvrzení o certifikaci potřebuje oporu v platném dokumentu a přesně vymezeném rozsahu. Použití certifikovaného kryptografického modulu neznamená certifikaci celého produktu a osvědčení poskytovatele nemusí pokrývat všechny nabízené služby. Přesné formulace chrání zákazníka před nesprávným rozhodnutím a dodavatele před slibem, který by nedokázal doložit.

Šest otázek, které by měly předcházet rozhodnutí

• Jakou škodu způsobí únik, změna nebo delší nedostupnost dat?
• Kde se nacházejí hlavní data, zálohy a provozní metadata?
• Kdo může data technicky otevřít a kdo spravuje šifrovací klíče?
• Kteří subdodavatelé se na službě podílejí?
• Jak rychle lze systém obnovit nebo přesunout k jinému dodavateli?
• Dokáže firma své rozhodnutí doložit vedení, zákazníkovi nebo regulátorovi?

Jak se rozhodnout

Pokud firma na některou z uvedených otázek nemá jasnou odpověď, vzniká konkrétní úkol pro smlouvu, technickou architekturu nebo interní procesy. Veřejný cloud tím ještě nemusí být automaticky vyloučen, ale nejasnost je potřeba odstranit před migrací. Dodatečná změna šifrování, exportního formátu nebo umístění dat bývá výrazně dražší než správně navržený projekt od začátku.

Citlivá data potřebují prostředí, které odpovídá důsledkům případného incidentu. Veřejný cloud může nabídnout vysokou úroveň zabezpečení i provozní pružnost, podnik však musí znát hranice své kontroly a přesné rozdělení odpovědnosti. On-premise a hybridní model mají největší hodnotu tam, kde provozní nezávislost, právní požadavky nebo cena úniku převáží nad výhodou rychlého nasazení.

Volba mezi veřejným cloudem, on-premise infrastrukturou a hybridním modelem není otázka technické módy, ale přímý důsledek toho, jak firma ocení dopad možného incidentu. Klíčové proměnné jsou vždy stejné: kdo drží šifrovací klíče, pod jakou jurisdikci data spadají, jak je smlouva pokrývá a co se stane při výpadku nebo odchodu od dodavatele. Správně postavená architektura nemusí být ani nejdražší, ani nejsložitější – musí ale odpovídat skutečnému riziku, nikoliv jen provozní pohodlnosti. Nejdražší změny jsou vždy ty, které firma řeší až po migraci.

Peter Vnuk

Technologie jsou pro mě práce i zábava – nejvíc se věnuji smartphonům, notebookům, audiotechnice, umělé inteligenci a všemu hi-tech. Rád recenzuji novinky, sleduji futuristické trendy a odhaduji další vývoj technologií. Fascinuje mě sci-fi a vize budoucího světa, které často inspirují i reálný technologický pokrok. Profesionálně se věnuji také videohrám a hernímu průmyslu. Když zrovna nepracuji, rád si odpočinu u dobré hry, kvalitního piva nebo tvorbou technologických memes na Facebooku.