Atestace C5: připravte důkazy pro ujištění o cloudu

Zákazník cloudu chce vědět, která ochranná opatření provozuje poskytovatel a která zůstávají jeho vlastní odpovědností. Německý Spolkový úřad pro bezpečnost v informační technice (BSI) vydává Cloud Computing Compliance Criteria Catalogue, C5, jako strukturovaný základ pro prověřování tohoto ujištění. Pro CTO znamená příprava učinit hranici služby, implementaci kontrol a provozní záznamy prověřitelnými, nikoli jen shromáždit politiky.

C5 je katalog kritérií používaný pro nezávislou atestaci, nikoli certifikace ve stylu ISO. Primárním zdrojem je dokumentace BSI k C5. Začněte tím, že se s nezávislým auditorem dohodnete na platném vydání, cíli ujištění a rozsahu prověrky.

Přesně definujte, kterou službu bude zpráva pokrývat

Popište cloudovou službu, místa provozu, organizační hranice a závislosti. Zpráva pokrývající jednu službu automaticky nepokrývá každý produkt pod stejnou značkou. Identifikujte produkční komponenty, rozhraní pro správu, provoz podpory a externí služby, které mohou ovlivnit tvrzení o ujištění.

Popis systému by měl umožnit externímu čtenáři pochopit, jak data zákazníků do služby vstupují, jak jí procházejí a jak ji opouštějí. Zahrňte cesty administrace, procesy nasazení, bezpečnostní monitoring, zálohy a rozdělení odpovědností mezi týmy. Vysvětlete relevantní vlastnosti služby a provozní podmínky, místo abyste textový popis nahradili diagramy architektury.

Než začnete sbírat důkazy, vyřešte tyto otázky rozsahu:

• Které produkty, regiony a prostředí jsou zahrnuty?
• Které týmy spravují produkci nebo mají přístup k informacím zákazníků?
• Kteří podkladoví poskytovatelé službu podporují a jak se zachází s jejich kontrolami?
• Které konfigurace a bezpečnostní úkoly zůstávají na zákaznících?
• K jakým podstatným změnám došlo nebo je naplánováno během období prověrky?

Výjimkám dejte výslovné zdůvodnění. Pokud je vyloučeno starší nasazení, zajistěte, aby prohlášení pro zákazníky nenaznačovala, že je pokryto. Výstupem je verzovaný popis systému podložený záznamy o architektuře, závislostech a odpovědnostech.

Zvolte typ zprávy dříve, než nastavíte kalendář důkazů

Ujištění podle C5 se obecně vyjadřuje atestační zprávou auditora. Type 1 se týká návrhu a implementace kontrol k určitému okamžiku. Type 2 navíc zkoumá provozní účinnost během stanoveného období.

Type 1 může být užitečným milníkem při budování kontrolního prostředí, ale neodpovídá na stejnou otázku jako Type 2. Než zvolíte průběžnou zprávu, ověřte, co zákazníci skutečně vyžadují.

Období a očekávání ohledně důkazů dohodněte s auditorem. Nepředpokládejte univerzální délku sledovaného období. Postup sepsaný ke konci období nemůže prokázat, že kontrola fungovala dříve. Stejně tak úspěšný současný test nevymaže historické selhání.

Budujte důkazy kolem odpovědnosti a provádění

Jako praktickou metodu přípravy vytvořte registr důkazů, který propojí každé použitelné kritérium s implementovanou kontrolou, vlastníkem, hranicí služby, zdrojem důkazů, frekvencí revizí a nevyřešenými mezerami. Zaznamenávejte rozhodnutí o použitelnosti a jejich zdůvodnění; neoznačujte kritérium za irelevantní jen proto, že by implementace byla obtížná.

Oddělte tři otázky: co by se mělo dít, co je implementováno a co se skutečně stalo. Politika odpovídá na první. Záznamy o konfiguraci mohou podpořit druhou. Tikety, logy, schválení a výsledky testů podporují třetí.

Jde o praktické příklady, nikoli o úplný kontrolní seznam C5. Požadované pokrytí, včetně organizačních, personálních, fyzických a technických kontrol, určete podle dohodnutého katalogu a rozsahu.

Zajistěte reprodukovatelnost důkazů

U každého exportu nebo snímku obrazovky uchovejte zdrojový systém, datum sběru, relevantní období, filtry a osobu, která jej pořídila. Vysvětlete, zda představuje celou populaci, nebo vybranou položku. Auditoři potřebují rozumět populaci, ze které vybírají vzorky; složka obsahující pouze úspěšné příklady nestačí.

Upřednostňujte záznamy, které uchovávají aktéra, časové razítko, úkon a výsledek. Chraňte důkazy před neoprávněnou změnou a vyhněte se zbytečnému vystavení dat zákazníků. Pokud je nutné začernění, zachovejte dostatek kontextu, aby revizor pochopil, co záznam prokazuje.

Oddělte zděděné kontroly od povinností, které zůstávají vám

Ujištění poskytovatele infrastruktury může podporovat fyzickou bezpečnost nebo podkladové kontroly platformy. Neprokazuje však, že funguje autorizace tenantů ve vaší aplikaci. Zdokumentujte závislost, příslušný rozsah zprávy, období, výjimky a odpovědnosti, které musí váš tým stále plnit.

Doplňkové kontroly na straně zákazníka také potřebují praktické znění. „Zákazník odpovídá za bezpečnost“ je příliš široké. Uveďte konkrétní úkoly, jako je správa uživatelů tenanta, konfigurace federace identit nebo revize přístupových politik pod kontrolou zákazníka. Tyto odpovědnosti udržujte konzistentní v popisu systému, dokumentaci služby a smluvních ujednáních.

Veďte přípravu jako inženýrský program

Začněte analýzou mezer oproti dohodnutým kritériím. Odlišujte chybějící implementaci od chybějících důkazů: vyžadují různé nápravy. Nezdokumentovaná revize může vyžadovat lepší záznamy; revize přístupů, která nikdy neproběhla, vyžaduje provozní kontrolu.

Každé mezeře přidělte vlastníka, nápravné opatření, závislost a cílové datum. Upřednostněte problémy ovlivňující oddělení tenantů, privilegovaný přístup, produkční změny, reakci na incidenty a obnovitelnost podle rizik služby, nikoli jen nejsnazší dokumentační úkoly.

Před obdobím Type 2 ověřte, že opakující se kontroly mají proveditelné harmonogramy a trvalé záznamy. Ověřte, kdo je provádí během nepřítomnosti nebo při fluktuaci zaměstnanců. U kontrol vyvolaných událostmi, jako je ukončení účtu, zajistěte, aby bylo možné identifikovat spouštěcí populaci.

Proveďte průchod připraveností s reprezentativními důkazy. Sledujte jednu změnu od žádosti až po nasazení, jednoho odcházejícího administrátora až po odebrání přístupu a jedno cvičení obnovy až po nápravné opatření. Tím se odhalí nefunkční předávání, která by revize politik mohla přehlédnout.

Během prověrky veďte registr žádostí s vlastníky a stavem odpovědí. Původní záznamy mějte k dispozici, nesrovnalosti otevřeně vysvětlujte a nápravu sledujte odděleně od historických důkazů. Nepřepisujte staré záznamy, aby vypadaly jako vyhovující. O tom, jak zjištění ovlivní testování a výrok, rozhoduje auditor.

Modelový příklad: spravovaná aplikace na externí infrastruktuře

Předpokládejme pro ilustraci, že poskytovatel provozuje multitenantní aplikaci v jednom regionu, používá externího poskytovatele infrastruktury a usiluje o ujištění Type 2. Jeho tým řídí vydávání aplikace, oprávnění tenantů, administraci produkce a postupy obnovy.

Popis rozsahu identifikuje aplikaci, databázi, řídicí rovinu, nástroje podpory a závislost na infrastruktuře. Vysvětluje, které podkladové kontroly jsou zděděné a které zůstávají na poskytovateli aplikace.

U izolace tenantů tým zaznamenává návrh autorizace, automatizované negativní testy, zjištění z bezpečnostních testů a schválení vydání. Uchovává také záznamy o změnách, které ukazují, kdy se logika autorizace změnila. Zpráva o infrastruktuře je podpůrným důkazem o závislosti, nikoli důkazem izolace aplikace.

U privilegovaného přístupu tým uchovává populaci administrátorů, schválení udělení přístupu, rozhodnutí z revizí a záznamy o odebrání. Předpokládejme, že revize odhalí nepoužívaný účet podpory. Tým zaznamená zjištění, odebrání přístupu, posouzení expozice a preventivní opatření. To je věrohodnější než předložit jen vyčištěný seznam účtů.

U obnovy uchovává výsledek testu obnovy, který ukazuje, co bylo obnoveno, uplynulý čas, kontroly integrity dat a nevyřešená omezení. Samotná nakonfigurovaná zálohovací úloha obnovitelnost neprokazuje. Každá sada důkazů má vlastníka a definované období, takže auditor může záznamy propojit s prověřovanou kontrolou.

Využívejte práci na ujištění opakovaně, aniž byste tvrdili rovnocennost

ISO/IEC 27001 se týká systému řízení bezpečnosti informací s vymezeným rozsahem. SOC 2 je atestační zpráva s vlastními kritérii a kontextem vykazování. C5 se zaměřuje na ujištění o cloudových službách podle katalogu BSI.

Stávající posouzení rizik, kontroly přístupu, postupy pro incidenty a provozní záznamy mohou podporovat více než jeden program. Využívejte je opakovaně prostřednictvím mapování specifických pro verzi a rozsah a poté ověřte rozdíly v požadavcích nebo vykazování. Sdílená kontrola neznamená automatickou rovnocennost mezi rámci.

Portfolio ujištění volte podle skutečných požadavků zákazníků a rizik služby. C5 není univerzálně povinná pro každého poskytovatele cloudu; požadavky z výběrových řízení, smluv nebo platných odvětvových předpisů vyžadují samostatnou revizi. Zpráva C5 ani jiný dokument ujištění samy o sobě nezakládají soulad s GDPR nebo NIS2.

Připravte zprávu pro rozhodování zákazníků

Zákazníci potřebují popis systému, datum nebo období, skutečný výrok, výjimky a hranice odpovědností, nikoli jen označení zprávy. Při sdílení zpráv respektujte smluvní důvěrnost a poskytněte kontext pro posouzení zákazníka.

Stav nápravy vysvětlujte, aniž byste naznačovali, že následné opravy mění historický výrok. Pokud období zprávy předchází zásadní změně architektury, toto omezení uveďte. Opakované prověrky dohodněte podle očekávání zákazníků a provozních změn, místo abyste atestaci považovali za nadčasové osvědčení.

Secani pomáhá týmům propojit implementaci kontrol a důkazy se zrevidovanými požadavky. Namodelujte službu a závislosti, přidělte vlastníky a revizory, připojte podpůrné záznamy a z mezer v důkazech vytvořte úkoly. U mapování a závěrů ponechte lidské schválení výslovné. Model připravenosti na audit pomáhá zachovat rozsah a odpovědnost za každým tvrzením.

Otázky k vyřešení před první prověrkou

Vydává zprávu BSI?

BSI vydává katalog. Prověrku provádí a atestační zprávu vydává nezávislý auditor; platný rámec ujištění a podmínky zakázky si ověřte s tímto auditorem.

Co když nedošlo k žádnému skutečnému incidentu?

Nevymýšlejte záznam o incidentu. Uchovávejte důkazy, že proces byl implementován a tam, kde je to vhodné, procvičen. S auditorem se dohodněte, jak absence událostí ovlivní testování.

Co by měl tým udělat dál?

Vezměte jednu reprezentativní produkční službu a připravte její popis rozsahu, matici odpovědností a registr důkazů. Tyto tři výstupy zrevidujte s budoucím auditorem dříve, než začnete sestavovat rozsáhlý balíček důkazů.