SOC 2
Kontrolní mechanismy pro bezpečný, dostupný a důvěryhodný provoz informačních systémů.
SOC 2 jako rámec provozní důvěry
Organizace, která svěřuje citlivá data externímu dodavateli, nepotřebuje pouze obecné ujištění, že jsou jeho systémy bezpečné. Potřebuje ověřitelný způsob, jak posoudit, zda dodavatel řídí přístupy, změny, incidenty, dostupnost služeb a ochranu informací systematicky, dlouhodobě a na základě doložitelných kontrol.
Právě k tomuto účelu slouží rámec SOC 2. Nejde o technický produkt, bezpečnostní značku ani certifikát, který by si organizace mohla jednostranně udělit. Výstupem posouzení je atestační zpráva připravená nezávislým auditorem na základě Trust Services Criteria vydávaných AICPA. [1]
Auditor neposuzuje pouze existenci interních směrnic. Hodnotí také způsob, jakým jsou kontrolní mechanismy navrženy, přiřazeny konkrétním vlastníkům, dokumentovány a v případě zprávy Type II dlouhodobě vykonávány.
Audit není náhradou bezpečnosti. Je nezávislým ověřením, že deklarované kontroly skutečně existují, mají vlastníka, vytvářejí důkazy a fungují způsobem odpovídajícím popisu systému.
Pro dodavatele veřejné správy je tento přístup důležitý zejména proto, že propojuje technickou architekturu s řízením organizace. Bezpečnost aplikace nelze oddělit od správy identit, řízení změn, odpovědnosti pracovníků, kontroly subdodavatelů, reakce na incidenty nebo obnovy provozu po selhání infrastruktury.
Co přesně zpráva SOC 2 popisuje
Předmětem zprávy není abstraktní bezpečnost celé firmy bez jasných hranic. Posouzení se vztahuje k popsanému systému, poskytovaným službám, infrastruktuře, procesům, pracovníkům, datům a kontrolám, které byly zahrnuty do definovaného rozsahu.
Popis systému by měl umožnit čtenáři pochopit, jak služba funguje, jaké závazky organizace přijímá vůči zákazníkům a které kontroly podporují jejich splnění. Součástí bývá také vymezení externích dodavatelů, předpokládaných zákaznických kontrol a oblastí, které byly z posouzení výslovně vyloučeny. [2]
Pro zákazníka je rozsah zásadní. Zpráva vydaná pro jednu službu automaticky nepotvrzuje stav všech produktů, poboček nebo systémů organizace. Při posuzování dodavatele je proto nutné ověřit, zda auditovaný systém skutečně odpovídá službě, kterou zákazník používá nebo plánuje používat.
Stejně důležité je období posouzení, případné výjimky z fungování kontrol a vyjádření auditora. Samotná existence dokumentu není dostatečná bez pochopení jeho rozsahu a závěrů.
Pět kategorií Trust Services Criteria
Trust Services Criteria zahrnují bezpečnost, dostupnost, integritu zpracování, důvěrnost a soukromí. Bezpečnost představuje povinný základ. Ostatní kategorie se zahrnují podle povahy služby, smluvních závazků a typu zpracovávaných informací. [1]
Bezpečnost se zaměřuje na ochranu systémů před neoprávněným přístupem, změnou, zneužitím nebo poškozením. Nejde pouze o ochranu před externím útočníkem. Součástí je také interní řízení oprávnění, oddělení odpovědností, správa privilegovaných účtů, bezpečnost vývojového procesu a pravidelné vyhodnocování provozních a kybernetických rizik.
Dostupnost posuzuje, zda je služba provozována v souladu s dohodnutými závazky. Organizace musí být schopna prokázat řízení kapacity, zálohování, obnovy, kontinuity provozu a reakce na technická selhání. Dostupnost proto není pouze údaj o procentu provozuschopnosti, ale také schopnost obnovit kritické funkce v definovaném čase.
Integrita zpracování se týká úplnosti, přesnosti, včasnosti a oprávněnosti zpracování. U datových a automatizačních platforem je důležité, aby bylo možné dohledat původ vstupních dat, provedené transformace, validační pravidla, schválení změny a vztah výsledku k očekávanému procesu.
Důvěrnost chrání informace označené na základě smlouvy, interní klasifikace nebo povahy služby jako neveřejné. Zahrnuje řízení celého životního cyklu dat od jejich přijetí přes používání a archivaci až po bezpečné odstranění.
Soukromí se zaměřuje na osobní údaje a způsob, jakým jsou shromažďovány, používány, uchovávány, zveřejňovány a likvidovány. SOC 2 v této oblasti nenahrazuje GDPR. Může však poskytovat strukturované důkazy o existenci procesů podporujících ochranu osobních údajů.
Kontrolní prostředí nezačíná u technologií
Technická kontrola bez určeného vlastníka, pravidelného vyhodnocování a doložitelného výstupu je obtížně auditovatelná a často také provozně nespolehlivá.
Kontrolní prostředí začíná způsobem, jakým vedení organizace rozděluje odpovědnosti, schvaluje zásady, vyhodnocuje rizika a kontroluje jejich plnění. Teprve na tuto vrstvu navazují konkrétní technická opatření.
Důležitou součástí je také pravidelné vzdělávání pracovníků, řešení střetu rolí, správa výjimek, vnitřní komunikace a mechanismus pro hlášení bezpečnostních nebo etických problémů.
Řízení identit a přístupových oprávnění
Každý přístup do produkčního prostředí musí být přiřaditelný konkrétní osobě nebo řízené technické identitě. Sdílené účty omezují dohledatelnost a komplikují vyšetřování incidentů.
Přístupová práva se přidělují podle principu nejmenších privilegií. Uživatel získává pouze taková oprávnění, která potřebuje pro svou aktuální pracovní roli. Privilegované operace mohou vyžadovat vícefaktorové ověření, časově omezené oprávnění nebo schválení odpovědnou osobou.
Kontrola nekončí vytvořením účtu. Oprávnění musí být pravidelně revidována, změněna při přechodu pracovníka do jiné role a bez zbytečného odkladu odebrána při ukončení spolupráce. Důkazní řetězec má zachycovat, kdo o přístup požádal, kdo jej schválil, kdy byl přidělen a kdy byl naposledy ověřen.
U technických účtů je nutné řídit jejich účel, vlastníka, privilegia, rotaci tajných údajů a způsob použití. Nepoužívané nebo osiřelé identity představují významné provozní riziko.
Šifrování, klíče a klasifikace informací
Citlivá data musí být chráněna při přenosu i při uložení. Komunikace mezi klientem, aplikační vrstvou, databázemi a interními službami má využívat současné kryptografické protokoly. Stejně důležité je bezpečné řízení kryptografických klíčů, certifikátů a přístupových tajemství.
Hesla, API klíče a další citlivé hodnoty nemají být ukládány přímo ve zdrojovém kódu nebo běžných konfiguračních souborech. Mají být spravovány prostřednictvím řízeného úložiště s auditní stopou, omezenou dobou platnosti a definovaným procesem rotace.
Šifrování chrání obsah dat. Samo o sobě však neřeší oprávněnost přístupu, správu klíčů, dobu uchování ani riziko neoprávněného použití dat oprávněným účtem.
Ochrana informací zahrnuje také jejich klasifikaci. Organizace musí vědět, která data jsou veřejná, interní, důvěrná nebo mimořádně citlivá. Od klasifikace se následně odvíjí způsob ukládání, sdílení, zálohování, archivace a likvidace.
Auditní stopa a sledovatelnost dat
Prokazatelnost je základní vlastností prostředí připraveného na audit. Nestačí tvrdit, že jsou změny kontrolovány. Organizace musí být schopna předložit záznamy ukazující, kdo změnu provedl, kdy k ní došlo, proč byla schválena a jaký měla dopad.
U datových platforem je důležitá také datová lineage. Výstup analytického nebo automatizačního procesu by měl být dohledatelný až ke zdrojovým datům a jednotlivým transformacím. To umožňuje analyzovat chyby, ověřovat integritu zpracování a určit odpovědnost za konkrétní změnu.
Atodat chápe sledovatelnost jako produktovou vlastnost, nikoliv jako dodatečnou auditní vrstvu. Systém navržený s důrazem na původ dat, verzování a historii operací usnadňuje technickou správu i pozdější předložení auditních důkazů.
Auditní záznamy musí být chráněny před neoprávněnou změnou, uchovávány po definovanou dobu a dostupné pracovníkům, kteří je potřebují pro monitoring, vyšetřování nebo audit.
Monitoring a detekce událostí
Bezpečnostní monitoring musí být zaměřený na události, které mohou indikovat zneužití účtu, změnu konfigurace, nestandardní přístup k datům, selhání kontrolního mechanismu nebo narušení dostupnosti.
Samotné shromažďování logů nestačí. Organizace musí určit, které události vyžadují upozornění, kdo je vyhodnotí, jak rychle má dojít k reakci a jak bude eskalován potvrzený incident.
Reakce na bezpečnostní incidenty
Proces reakce na incident má zahrnovat identifikaci, klasifikaci, omezení dopadu, odstranění příčiny, obnovu služby a následné vyhodnocení. Jednotlivé fáze musí mít přiřazené odpovědnosti a očekávané výstupy.
Součástí je evidence rozhodnutí, komunikace s dotčenými stranami, uchování relevantních důkazů a přijetí nápravných opatření, aby se stejný typ incidentu neopakoval.
Pravidelné testování plánu reakce na incidenty pomáhá ověřit, že odpovědné osoby znají své role a že dokumentované postupy odpovídají skutečné infrastruktuře. Simulace může odhalit neaktuální kontakty, nedostupné nástroje, chybějící oprávnění nebo závislost na konkrétní osobě.
Výsledkem cvičení nemá být pouze potvrzení jeho provedení. Organizace by měla evidovat zjištění, vlastníky nápravných opatření a termíny jejich dokončení.
Řízení změn a bezpečný vývojový proces
Změny produkčního prostředí představují jednu z častých příčin provozních incidentů. Vývoj, testování, schvalování a nasazování změn proto musí být odděleno a dokumentováno. Každá významná změna má mít známého autora, popis účelu, výsledek testování a záznam o schválení.
Automatizované nasazování může riziko snížit, pokud je postaveno nad kontrolovaným procesem. Automatizace sama o sobě ale není kontrolou. Kontrolou je definovaný postup, který zabraňuje obcházení testů, omezuje přístup k produkci a vytváří auditní stopu každého nasazení.
Bezpečný vývojový proces musí počítat nejen s běžnou změnou, ale také s urgentní opravou, návratem na předchozí verzi a řešením kritické zranitelnosti.
Bezpečnostní požadavky mají být součástí návrhu od počátku vývojového cyklu. Zahrnují kontrolu závislostí, správu zranitelností, revizi zdrojového kódu, oddělení prostředí, testování obnovy a pravidla pro řešení kritických nálezů.
Kontinuita provozu a obnova po selhání
Dostupnost služby závisí na schopnosti organizace obnovit provoz po technickém selhání, lidské chybě, bezpečnostním incidentu nebo výpadku externího dodavatele.
Zálohování je pouze první částí tohoto procesu. Záloha, kterou nelze v požadovaném čase obnovit, neposkytuje dostatečnou provozní jistotu. Organizace proto definuje cílový čas obnovy a maximální přípustnou ztrátu dat.
Tyto hodnoty musí odpovídat skutečným smluvním a provozním požadavkům. Postupy obnovy mají být pravidelně testovány a výsledky testů dokumentovány.
Součástí kontinuity je také znalost závislostí. Pokud je služba závislá na cloudové platformě, poskytovateli identity, externím API, síťové infrastruktuře nebo konkrétním subdodavateli, musí být tato závislost zahrnuta do analýzy rizik a plánu obnovy.
Řízení dodavatelů
Bezpečnostní úroveň organizace může být významně ovlivněna subdodavateli. Externí poskytovatel může provozovat infrastrukturu, zpracovávat data, poskytovat bezpečnostní nástroje nebo mít privilegovaný přístup k technickému prostředí.
Před zahájením spolupráce je proto nutné vyhodnotit rizika, smluvně stanovit bezpečnostní požadavky a průběžně ověřovat, zda dodavatel tyto podmínky nadále splňuje.
SOC 2 Type I a Type II
Zpráva SOC 2 Type I posuzuje návrh kontrol k určitému datu. Auditor hodnotí, zda jsou kontroly vhodně navrženy pro dosažení stanovených cílů.
Type II posuzuje nejen návrh, ale také provozní účinnost kontrol v průběhu definovaného období. Auditor vybírá vzorky důkazů a ověřuje, zda byly kontroly skutečně vykonávány konzistentně. Tato dlouhodobá provozní dimenze dává zprávě Type II větší váhu při hodnocení kritických dodavatelů. [3]
Návrh kontroly odpovídá na otázku, zda by kontrola měla být schopna dosáhnout svého cíle. Provozní účinnost odpovídá na otázku, zda kontrola v posuzovaném období skutečně fungovala.
Atodat staví své procesy a technické kontroly tak, aby odpovídaly relevantním kritériím SOC 2, a směřuje k nezávislému posouzení. Dokud není formální audit dokončen a příslušná zpráva vydána, není správné tuto připravenost prezentovat jako již získanou certifikaci nebo hotovou zprávu SOC 2.
Vztah k ISO 27001, GDPR a NIS2
SOC 2 nelze považovat za náhradu systému řízení informační bezpečnosti podle ISO/IEC 27001. Oba rámce se v řadě témat překrývají, ale používají odlišný způsob ověřování a mají jiný výstup. ISO/IEC 27001 vede k certifikaci systému řízení informační bezpečnosti, zatímco SOC 2 vede k atestační zprávě popisující konkrétní systém a jeho kontroly. [4]
SOC 2 stejně tak nenahrazuje právní povinnosti podle GDPR, směrnice NIS2 nebo dalších evropských předpisů. Může však pomoci vytvořit a doložit kontrolní prostředí podporující řízení přístupů, ochranu dat, reakci na incidenty, kontinuitu a dohledatelnost. [5] [6]
Soulad s jedním rámcem proto nelze automaticky vydávat za soulad se všemi ostatními. Každý rámec má vlastní rozsah, terminologii, právní účinky a mechanismus ověřování.
Co to znamená pro zákazníka Atodatu
Pro zákazníka není nejdůležitější samotný název rámce, ale kvalita důkazů, které může dodavatel předložit.
Organizace by měla být schopna vysvětlit, jak řídí přístupy, jak reaguje na incidenty, jak testuje zálohy, jak schvaluje změny, jak spravuje zranitelnosti a jak kontroluje externí dodavatele.
Přístup Atodatu je založený na tom, že bezpečnostní kontrola má být propojena s reálným fungováním systému. Auditní stopa, původ dat, správa oprávnění a řízení změn nemají existovat pouze v dokumentaci. Mají být součástí produktů a provozních procesů.
Důvěra nevzniká jednorázovým dokumentem. Vzniká opakovatelným výkonem kontrol a schopností tento výkon zpětně prokázat.
Chcete projít konkrétní bezpečnostní kontroly, architekturu systému nebo požadavky vašeho projektu?
Zdroje a další informace
[1] AICPA & CIMA — 2017 Trust Services Criteria with Revised Points of Focus
[2] AICPA & CIMA — 2018 SOC 2 Description Criteria with Revised Implementation Guidance
[3] Secure Controls Framework — Trust Services Criteria, SOC 2 Type I a Type II
[4] International Organization for Standardization — ISO/IEC 27001 — Information security management systems
[5] Evropská unie — Nařízení Evropského parlamentu a Rady (EU) 2016/679 — GDPR
[6] Evropská unie — Směrnice Evropského parlamentu a Rady (EU) 2022/2555 — NIS2