
En cloudkunde vil vide, hvilke beskyttelsesforanstaltninger udbyderen driver, og hvilke der forbliver kundens eget ansvar. Det tyske forbundskontor for informationssikkerhed (BSI) udgiver Cloud Computing Compliance Criteria Catalogue, C5, som et struktureret grundlag for at efterprøve denne assurance. For en CTO betyder forberedelse at gøre tjenestens afgrænsning, implementeringen af kontroller og de operationelle registreringer efterprøvelige – ikke blot at samle politikker.
C5 er et kriteriekatalog, der bruges til uafhængig erklæringsafgivelse, ikke en certificering i ISO-forstand. BSI's C5-dokumentation er den primære reference. Begynd med at aftale den gældende udgave, assurance-målet og undersøgelsens omfang med den uafhængige revisor.
Beskriv cloudtjenesten, driftslokationer, organisatoriske afgrænsninger og afhængigheder. En rapport, der dækker én tjeneste, dækker ikke automatisk alle produkter under samme brand. Identificér produktionskomponenter, administrationsgrænseflader, supportfunktioner og eksterne tjenester, der kan påvirke assurance-udsagnene.
Systembeskrivelsen bør gøre det muligt for en udenforstående at forstå, hvordan kundedata kommer ind i, bevæger sig gennem og forlader tjenesten. Medtag administrationsveje, deploymentprocesser, sikkerhedsovervågning, backup og ansvarsfordelingen mellem teams. Forklar relevante egenskaber ved tjenesten og driftsbetingelser i stedet for at lade arkitekturdiagrammer erstatte den beskrivende tekst.
Afklar disse spørgsmål om omfang, før evidens indsamles:
Giv udeladelser en eksplicit begrundelse. Hvis en ældre installation er udeladt, skal I sikre, at udsagn over for kunderne ikke antyder, at den er dækket. Leverancen er en versioneret systembeskrivelse understøttet af registreringer af arkitektur, afhængigheder og ansvar.
C5-assurance udtrykkes som regel gennem en revisors erklæringsrapport. Type 1 omhandler kontrollernes design og implementering på et bestemt tidspunkt. Type 2 undersøger derudover den operationelle effektivitet over en angivet periode.
| Beslutning | Type 1 | Type 2 |
|---|---|---|
| Tidsmæssig afgrænsning | Angivet dato | Angivet undersøgelsesperiode |
| Evidensens fokus | Hensigtsmæssigt design og implementering | Design, implementering og drift over tid |
| Betydning for planlægningen | Fastlæg kontroltilstanden på referencedatoen | Bevar operationelle registreringer i hele perioden |
Type 1 kan være en nyttig milepæl, når et kontrolmiljø etableres, men den besvarer ikke det samme spørgsmål som Type 2. Bekræft, hvad kunderne faktisk kræver, før I vælger en foreløbig rapport.
Aftal perioden og forventningerne til evidens med revisoren. Antag ikke en universel længde for observationsperioden. En procedure, der er skrevet mod slutningen af en periode, kan ikke fastslå, at kontrollen fungerede tidligere. Ligeledes sletter en vellykket aktuel test ikke et historisk svigt.
Som praktisk forberedelsesmetode kan I opbygge et evidensregister, der forbinder hvert gældende kriterium med den implementerede kontrol, ejer, tjenestens afgrænsning, evidenskilde, reviewfrekvens og uafklarede mangler. Registrér beslutninger om anvendelighed og deres begrundelse; undgå at markere et kriterium som irrelevant, blot fordi implementeringen ville være vanskelig.
Adskil tre spørgsmål: hvad der bør ske, hvad der er implementeret, og hvad der faktisk skete. En politik besvarer det første. Konfigurationsregistreringer kan understøtte det andet. Sager, logge, godkendelser og testresultater understøtter det tredje.
| Kontrolområde | Implementeringsevidens | Operationel evidens |
|---|---|---|
| Identitetsadministration | Rolledefinitioner, konfiguration af privilegeret adgang | Registreringer af nyansatte og fratrådte, adgangsgennemgange, tilbagekaldelser |
| Ændringsstyring | Beskyttet deploymentvej, godkendelsesregler | Ændringer, godkendelser, testresultater, gennemgang af nødændringer |
| Hændelseshåndtering | Responsprocedure, ansvar for eskalering | Hændelsesregistreringer, øvelser, korrigerende handlinger |
| Robusthed | Backupkonfiguration, genopretningsmål | Gendannelsestests, genopretningsresultater, opfølgningsarbejde |
| Leverandørstyring | Fortegnelse over afhængigheder, evalueringsprocedure | Gennemgang af udbyderrapporter, vurderinger af undtagelser |
Det er praktiske eksempler, ikke en fuldstændig C5-tjekliste. Brug det aftalte katalog og omfang til at fastlægge den krævede dækning, herunder organisatoriske, personalemæssige, fysiske og tekniske kontroller.
Bevar for hver eksport eller hvert skærmbillede kildesystemet, indsamlingsdatoen, den relevante periode, filtre og den person, der indsamlede det. Forklar, om det repræsenterer hele populationen eller et udvalgt element. Revisorer skal forstå den population, de udtager stikprøver fra; en mappe, der kun indeholder vellykkede eksempler, er ikke tilstrækkelig.
Foretræk registreringer, der bevarer aktør, tidsstempel, handling og resultat. Beskyt evidensen mod uautoriseret ændring, og undgå unødig eksponering af kundedata. Hvor der er behov for redigering, skal der bevares tilstrækkelig kontekst til, at revieweren kan forstå, hvad registreringen beviser.
En infrastrukturudbyders assurance kan understøtte fysisk sikkerhed eller kontroller i den underliggende platform. Den fastslår ikke, at jeres applikations autorisation pr. tenant virker. Dokumentér afhængigheden, den relevante rapports omfang, periode, undtagelser og det ansvar, jeres team stadig skal opfylde.
Komplementære kundekontroller kræver også en praktisk formulering. »Kunden er ansvarlig for sikkerheden« er for bredt. Angiv opgaver som administration af tenantbrugere, konfiguration af identitetsføderation eller gennemgang af kundestyrede adgangspolitikker. Hold dette ansvar konsistent på tværs af systembeskrivelsen, tjenestedokumentationen og de kontraktlige aftaler.
Begynd med en gap-analyse op mod de aftalte kriterier. Skeln mellem manglende implementering og manglende evidens: De kræver forskellige løsninger. En udokumenteret gennemgang kan kræve bedre registreringer; en adgangsgennemgang, der aldrig fandt sted, kræver en operationel kontrol.
Tildel hver mangel en ejer, en afhjælpende handling, en afhængighed og en måldato. Prioritér problemer, der påvirker adskillelse af tenants, privilegeret adgang, produktionsændringer, hændelseshåndtering og genopretning, ud fra tjenestens risici – ikke blot de letteste dokumentationsopgaver.
Før Type 2-perioden skal I kontrollere, at tilbagevendende kontroller har realistiske tidsplaner og holdbare registreringer. Bekræft, hvem der udfører dem ved fravær eller medarbejderudskiftning. For hændelsesdrevne kontroller, som lukning af konti, skal I sikre, at den udløsende population kan identificeres.
Gennemfør en parathedsgennemgang med repræsentativ evidens. Følg én ændring fra anmodning til deployment, én fratrædende administrator gennem tilbagekaldelse og én genopretningsøvelse frem til korrigerende handling. Det afslører brudte overdragelser, som en gennemgang af politikker kan overse.
Under undersøgelsen bør I føre et register over anmodninger med ejere og svarstatus. Hold de oprindelige registreringer tilgængelige, forklar uoverensstemmelser åbent, og følg afhjælpning adskilt fra historisk evidens. Omskriv ikke gamle registreringer for at få dem til at se compliant ud. Revisoren afgør, hvordan fund påvirker testen og konklusionen.
Antag illustrativt, at en udbyder driver en multi-tenant-applikation i én region, bruger en ekstern infrastrukturudbyder og ønsker Type 2-assurance. Teamet kontrollerer applikationsudgivelser, tenantrettigheder, produktionsadministration og genopretningsprocedurer.
Beskrivelsen af omfanget identificerer applikationen, databasen, administrationslaget, supportværktøjerne og infrastrukturafhængigheden. Den forklarer, hvilke underliggende kontroller der arves, og hvilke der forbliver hos applikationsudbyderen.
For adskillelse af tenants registrerer teamet sit autorisationsdesign, automatiserede negative tests, fund fra sikkerhedstests og godkendelser af udgivelser. Det bevarer også ændringsregistreringer, der viser, hvornår autorisationslogikken blev ændret. Infrastrukturrapporten er understøttende evidens for afhængigheden, ikke et bevis for applikationens isolation.
For privilegeret adgang bevarer teamet populationen af administratorer, godkendelser af tildelinger, reviewbeslutninger og registreringer af fjernelser. Antag, at en gennemgang opdager en ubrugt supportkonto. Teamet registrerer opdagelsen, tilbagekaldelsen, vurderingen af eksponering og den forebyggende handling. Det er mere troværdigt end kun at indsende den oprydede kontoliste.
For genopretning bevarer det et resultat af en gendannelsestest, der viser, hvad der blev gendannet, den forløbne tid, kontroller af dataintegritet og uløste begrænsninger. Et konfigureret backupjob alene demonstrerer ikke, at gendannelse er mulig. Hvert evidenssæt har en ejer og en defineret periode, så revisoren kan forbinde registreringerne med den kontrol, der undersøges.
ISO/IEC 27001 vedrører et afgrænset ledelsessystem for informationssikkerhed. SOC 2 er en erklæringsrapport med egne kriterier og egen rapporteringskontekst. C5 fokuserer på assurance for cloudtjenester efter BSI's katalog.
Eksisterende risikovurderinger, adgangskontroller, hændelsesprocedurer og operationelle registreringer kan understøtte mere end ét program. Genbrug dem via versions- og omfangsspecifikke mappings, og kontrollér derefter for forskelle i krav eller rapportering. En fælles kontrol er ikke automatisk ensbetydende med ækvivalens mellem frameworks.
Vælg porteføljen af assurance ud fra faktiske kundekrav og tjenestens risici. C5 er ikke universelt obligatorisk for alle cloududbydere; krav i udbud, kontrakter eller gældende sektorregler kræver en separat gennemgang. Hverken en C5-rapport eller et andet assurance-dokument fastslår i sig selv overholdelse af GDPR eller NIS2.
Kunderne har brug for systembeskrivelsen, datoen eller perioden, den faktiske konklusion, undtagelser og ansvarsafgrænsninger – ikke kun rapportens betegnelse. Når I deler rapporter, skal den kontraktlige fortrolighed respekteres, og der skal gives kontekst til kundens vurdering.
Forklar status for afhjælpning uden at antyde, at senere rettelser ændrer den historiske konklusion. Hvis rapportperioden ligger før en større arkitekturændring, skal denne begrænsning angives. Aftal tilbagevendende undersøgelser ud fra kundernes forventninger og ændringer i driften i stedet for at behandle erklæringen som et tidløst bevis.
Secani hjælper teams med at forbinde implementering af kontroller og evidens med gennemgåede krav. Modellér tjenesten og afhængighederne, udpeg ejere og reviewere, knyt understøttende registreringer til, og gør evidensmangler til opgaver. Hold den menneskelige godkendelse eksplicit for mappings og konklusioner. Modellen for audit-parathed hjælper med at bevare omfanget og ansvaret bag hvert udsagn.
BSI udgiver kataloget. En uafhængig revisor gennemfører undersøgelsen og udsteder erklæringsrapporten; bekræft det gældende assurance-framework og opgavens vilkår med revisoren.
Opfind ikke en hændelsesregistrering. Bevar evidens for, at processen er implementeret og, hvor det er hensigtsmæssigt, øvet. Aftal med revisoren, hvordan fraværet af hændelser påvirker testen.
Tag én repræsentativ produktionstjeneste, og udarbejd dens beskrivelse af omfanget, ansvarsmatrix og evidensregister. Gennemgå disse tre leverancer med den kommende revisor, før I samler en stor evidenspakke.
Secani forbinder scopes, dokumentation, opgaver og AI-agenter i ét fælles arbejdsområde.
Stil praktiske spørgsmål om kvalifikationer, brancheerfaring, forventninger til evidens, tidsplan, uafhængighed og de samlede omkostninger ved vurderingen.
Læs ISO-certifikater og SOC 2-rapporter i kontekst: scope, periode, undtagelser, kundens ansvar og evidens for afhjælpning.
Planlæg en uafhængig, dokumentationsbaseret intern audit, og før fundene gennem korrigerende handlinger frem til en kontrol af effektiviteten.