C5-attestering: förbered underlag för molnförsäkran

En molnkund vill veta vilka skydd leverantören driver och vilka som förblir kundens eget ansvar. Tysklands federala myndighet för informationssäkerhet (BSI) publicerar Cloud Computing Compliance Criteria Catalogue, C5, som en strukturerad grund för att granska denna försäkran. För en CTO innebär förberedelserna att göra tjänstens avgränsning, kontrollernas implementering och de operativa posterna granskningsbara – inte bara att samla ihop policyer.

C5 är en kriteriekatalog som används för oberoende attestering, inte en certifiering i ISO-stil. BSI:s dokumentation om C5 är den primära referensen. Börja med att komma överens med den oberoende revisorn om tillämplig utgåva, syftet med försäkran och granskningens omfattning.

Definiera exakt vilken tjänst rapporten ska omfatta

Beskriv molntjänsten, driftsplatser, organisatoriska gränser och beroenden. En rapport som omfattar en tjänst omfattar inte automatiskt varje produkt under samma varumärke. Identifiera produktionskomponenter, administrationsgränssnitt, supportverksamhet och externa tjänster som kan påverka påståendena i försäkran.

Systembeskrivningen ska låta en utomstående förstå hur kunddata kommer in i, rör sig genom och lämnar tjänsten. Ta med administrationsvägar, driftsättningsprocesser, säkerhetsövervakning, säkerhetskopiering och ansvarsfördelningen mellan team. Förklara relevanta egenskaper hos tjänsten och driftsförhållanden i stället för att låta arkitekturdiagram ersätta den löpande beskrivningen.

Klarlägg dessa frågor om omfattning innan underlag samlas in:

• Vilka produkter, regioner och miljöer ingår?
• Vilka team administrerar produktionen eller kan komma åt kundinformation?
• Vilka underliggande leverantörer stöder tjänsten, och hur hanteras deras kontroller?
• Vilka konfigurationer och säkerhetsuppgifter ligger kvar hos kunderna?
• Vilka väsentliga förändringar skedde, eller planeras, under granskningsperioden?

Ge undantag en uttrycklig motivering. Om en äldre driftsättning är undantagen, se till att uttalanden riktade till kunder inte antyder att den omfattas. Leveransen är en versionshanterad systembeskrivning som stöds av poster om arkitektur, beroenden och ansvar.

Välj rapporttyp innan kalendern för underlag sätts

Försäkran enligt C5 uttrycks i regel genom en revisors attesteringsrapport. Typ 1 avser kontrollernas utformning och implementering vid en viss tidpunkt. Typ 2 granskar dessutom deras operativa effektivitet under en angiven period.

Typ 1 kan vara en användbar milstolpe när en kontrollmiljö byggs upp, men den besvarar inte samma fråga som typ 2. Bekräfta vad kunderna faktiskt kräver innan ni väljer en tillfällig rapport.

Kom överens med revisorn om perioden och förväntningarna på underlag. Anta inte en universell längd på observationsperioden. En rutin som skrivs i slutet av en period kan inte fastställa att kontrollen fungerade tidigare. På samma sätt raderar ett lyckat aktuellt test inte ett historiskt misslyckande.

Bygg underlagen kring ansvar och utförande

Som en praktisk förberedelsemetod, bygg ett register över underlag som kopplar varje tillämpligt kriterium till den implementerade kontrollen, ägare, tjänstens avgränsning, källa för underlag, granskningsfrekvens och olösta brister. Registrera beslut om tillämplighet och deras motivering; undvik att markera ett kriterium som irrelevant bara för att implementeringen skulle vara svår.

Skilj mellan tre frågor: vad som ska hända, vad som är implementerat och vad som faktiskt hände. En policy besvarar den första. Konfigurationsposter kan stödja den andra. Ärenden, loggar, godkännanden och testresultat stöder den tredje.

Detta är praktiska exempel, inte en fullständig checklista för C5. Använd den överenskomna katalogen och omfattningen för att avgöra den krävda täckningen, inklusive organisatoriska, personalrelaterade, fysiska och tekniska kontroller.

Gör underlagen reproducerbara

Spara för varje export eller skärmbild källsystem, insamlingsdatum, relevant period, filter och vem som samlade in den. Förklara om den representerar hela populationen eller ett utvalt objekt. Revisorer behöver förstå den population som de väljer stickprov ur; en mapp som bara innehåller lyckade exempel räcker inte.

Föredra poster som bevarar aktör, tidsstämpel, åtgärd och utfall. Skydda underlagen mot obehörig ändring och undvik onödig exponering av kunddata. Där maskering behövs, bevara tillräckligt sammanhang för att granskaren ska förstå vad posten bevisar.

Skilj ärvda kontroller från kvarvarande ansvar

En infrastrukturleverantörs försäkran kan stödja fysisk säkerhet eller kontroller i den underliggande plattformen. Den fastställer inte att er applikations behörighetskontroll per tenant fungerar. Dokumentera beroendet, den relevanta rapportens omfattning, period, undantag och det ansvar som ert team fortfarande måste uppfylla.

Kompletterande kundkontroller behöver också praktiska formuleringar. ”Kunden ansvarar för säkerheten” är för brett. Ange uppgifter som att administrera användare i kundens tenant, konfigurera identitetsfederation eller granska åtkomstpolicyer som kunden styr. Håll dessa ansvarsområden konsekventa i systembeskrivningen, tjänstedokumentationen och avtalen.

Driv förberedelserna som ett tekniskt program

Börja med en gapanalys mot de överenskomna kriterierna. Skilj saknad implementering från saknade underlag: de kräver olika åtgärder. En odokumenterad granskning kan kräva bättre poster; en behörighetsgranskning som aldrig ägde rum kräver en operativ kontroll.

Ge varje brist en ägare, en åtgärd, ett beroende och ett måldatum. Prioritera frågor som påverkar separation mellan tenants, privilegierad åtkomst, ändringar i produktion, incidenthantering och återställningsförmåga utifrån tjänstens risker – inte bara de enklaste dokumentationsuppgifterna.

Kontrollera före typ 2-perioden att återkommande kontroller har genomförbara scheman och beständiga poster. Bekräfta vem som utför dem vid frånvaro eller personalomsättning. För händelsestyrda kontroller, som avslut av konton, se till att den population som utlöser kontrollen kan identifieras.

Genomför en genomgång av beredskapen med representativa underlag. Följ en ändring från begäran till driftsättning, en administratör som slutar fram till återkallelsen och en återställningsövning fram till korrigerande åtgärd. Det synliggör brustna överlämningar som en policygranskning kan missa.

Upprätthåll under granskningen ett register över förfrågningar med ägare och svarsstatus. Håll originalposterna tillgängliga, förklara avvikelser öppet och följ upp åtgärder separat från historiska underlag. Skriv inte om gamla poster för att få dem att se ut att uppfylla kraven. Revisorn avgör hur iakttagelser påverkar testningen och uttalandet.

Räkneexempel: en förvaltad applikation på extern infrastruktur

Anta, som illustration, att en leverantör driver en applikation med flera tenants i en region, använder en extern infrastrukturleverantör och söker försäkran av typ 2. Dess team styr applikationsreleaser, behörigheter per tenant, produktionsadministration och återställningsrutiner.

Beskrivningen av omfattningen identifierar applikationen, databasen, administrationsplanet, supportverktygen och infrastrukturberoendet. Den förklarar vilka underliggande kontroller som ärvs och vilka som ligger kvar hos applikationsleverantören.

För isolering mellan tenants registrerar teamet sin behörighetsdesign, automatiserade negativa tester, iakttagelser från säkerhetstester och godkännanden av releaser. Det sparar också ändringsposter som visar när behörighetslogiken ändrades. Infrastrukturrapporten är ett stödjande underlag om beroendet, inte ett bevis på isolering i applikationen.

För privilegierad åtkomst sparar teamet populationen av administratörer, godkännanden av tilldelningar, granskningsbeslut och poster om borttagning. Anta att en granskning upptäcker ett oanvänt supportkonto. Teamet registrerar upptäckten, återkallelsen, bedömningen av exponeringen och den förebyggande åtgärden. Det är mer trovärdigt än att bara lämna in den uppstädade kontolistan.

För återställning sparar teamet ett resultat från ett återställningstest som visar vad som återställdes, förfluten tid, kontroller av dataintegritet och olösta begränsningar. Ett konfigurerat säkerhetskopieringsjobb ensamt visar inte återställningsförmåga. Varje uppsättning underlag har en ägare och en definierad period, så att revisorn kan koppla posterna till den kontroll som granskas.

Återanvänd arbete med försäkran utan att påstå likvärdighet

ISO/IEC 27001 gäller ett avgränsat ledningssystem för informationssäkerhet. SOC 2 är en attesteringsrapport med egna kriterier och ett eget rapporteringssammanhang. C5 fokuserar på försäkran för molntjänster enligt BSI:s katalog.

Befintliga riskbedömningar, behörighetskontroller, incidentrutiner och operativa poster kan stödja mer än ett program. Återanvänd dem genom versions- och omfattningsspecifika mappningar och kontrollera sedan om det finns skillnader i krav eller rapportering. En gemensam kontroll innebär inte automatiskt likvärdighet mellan ramverk.

Välj portföljen av försäkringar utifrån faktiska kundkrav och tjänstens risker. C5 är inte universellt obligatoriskt för varje molnleverantör; krav i upphandlingar, avtal eller tillämpliga sektorsregler behöver granskas separat. Varken en C5-rapport eller något annat dokument för försäkran fastställer på egen hand efterlevnad av GDPR eller NIS2.

Förbered rapporten för kundernas beslut

Kunderna behöver systembeskrivningen, datumet eller perioden, det faktiska uttalandet, undantagen och ansvarsgränserna – inte bara rapportens beteckning. När rapporter delas, respektera avtalad sekretess och ge sammanhang för kundens bedömning.

Förklara status för åtgärder utan att antyda att senare rättelser ändrar det historiska uttalandet. Om rapportperioden ligger före en större arkitekturförändring, ange den begränsningen. Planera återkommande granskningar utifrån kundernas förväntningar och förändringar i driften i stället för att behandla attesteringen som ett tidlöst intyg.

Secani hjälper team att koppla kontrollernas implementering och underlag till granskade krav. Modellera tjänsten och beroendena, utse ägare och granskare, koppla stödjande poster och omvandla brister i underlagen till uppgifter. Håll mänskligt godkännande uttryckligt för mappningar och slutsatser. Modellen för revisionsberedskap hjälper till att bevara omfattningen och ansvaret bakom varje påstående.

Frågor att lösa före den första granskningen

Är det BSI som utfärdar rapporten?

BSI publicerar katalogen. En oberoende revisor genomför granskningen och utfärdar attesteringsrapporten; bekräfta tillämpligt ramverk för försäkran och villkoren för uppdraget med revisorn.

Vad händer om ingen verklig incident har inträffat?

Hitta inte på en incidentpost. Spara underlag som visar att processen har implementerats och, där det är lämpligt, övats. Kom överens med revisorn om hur avsaknaden av händelser påverkar testningen.

Vad bör teamet göra härnäst?

Välj en representativ produktionstjänst och ta fram dess beskrivning av omfattningen, ansvarsmatris och register över underlag. Gå igenom dessa tre leveranser med den blivande revisorn innan ni sätter ihop ett stort underlagspaket.