Datasikkerhed i skyen: gør det delte ansvar konkret

En cloududbyder driver en del af sikkerhedsmiljøet. Jeres team skal stadig fastlægge, hvilke beskyttelsesforanstaltninger det selv konfigurerer, om de dækker de data og tjenester, der er i brug, og hvordan det ved, at de forbliver effektive.

Datasikkerhed i skyen beskytter fortrolighed, integritet og tilgængelighed på tværs af lagring, behandling, deling og genopretning. Den omfatter databaser og objektlagre, men også applikationsrettigheder, eksporter fra SaaS, tjenesteidentiteter, sikkerhedskopier og de bærbare computere eller automatiseringssystemer, der kan hente data.

Set fra en CTO's perspektiv bliver delt ansvar først nyttigt, når det fører til konkrete tekniske beslutninger: hvem konfigurerer en kontrol, hvem overvåger den, hvilken dokumentation viser, at den virker, og hvem handler, når den svigter? En udbyders sikkerhedserklæring kan ikke besvare de spørgsmål for jeres implementering.

Fastlæg grænsen, før I vælger kontroller

Cloudmiljøer kombinerer infrastruktur, platforme og applikationer, der leveres eksternt. Offentlig sky bruger som regel infrastruktur, som udbyderen driver for flere kunder; privat sky er dedikeret til én organisation. Ingen af betegnelserne afgør, om jeres data er tilstrækkeligt beskyttet. Isolation, adgangsveje, driftsejerskab og genopretningsordninger betyder mere end betegnelsen.

Begynd med én forretningstjeneste, og følg dens afhængigheder. Identificér cloudkonti eller abonnementer, regioner, tjenester, datalagre, administratorer og deploymentsystemer. Medtag SaaS-produkter, som support, økonomi og udvikling bruger: En produktionsdatabase kan være stramt kontrolleret, mens dens kundeeksport ligger i et bredt delt arbejdsområde.

Fortegnelsen bør besvare disse spørgsmål:

• Hvilke oplysninger lagres eller behandles, og hvem ejer forretningsformålet?
• Hvor ligger de primære registreringer, replikaer, logfiler, eksporter, caches og sikkerhedskopier?
• Hvilke personer, workloads, leverandører og eksterne modtagere kan få adgang til dem?
• Hvilke konti, regioner og tjenester er godkendt, og hvordan opdages nye?
• Hvilke krav til opbevaring, sletning, tilgængelighed og kontrakter gælder?

Skyens skalerbarhed og fjernadgang kan forbedre driften, og administrerede tjenester kan mindske vedligeholdelsen af infrastruktur. De gør det også let at oprette ressourcer og kopier hurtigere, end reviewere kan følge med. Sikkerhedsomkostningerne omfatter derfor identitetsadministration, overvågning, indsamling af dokumentation, test af genopretning og tilsyn med leverandører – ikke kun regningen for lagerplads.

Klassificér information dér, hvor den faktisk befinder sig

Brug et overskueligt klassifikationsskema, der er knyttet til handlinger. Kategorierne offentlig, intern, fortrolig og begrænset kan f.eks. bestemme regler for deling, adgangsgennemgange, logning og opbevaring. Definér, hvilken kategori der dækker kunde-id'er, autentificeringshemmeligheder, regnskabsdata, kildekode og følsomme personoplysninger.

Automatiseret kortlægning kan hjælpe med at finde oversete datasæt, men validér resultaterne med dataejerne. En scanner kan overse komprimerede arkiver eller applikationsspecifikke felter, mens en harmløs teststreng kan give et falsk positivt fund. Registrér lokationer, der ikke er scannet, og begrænsninger i stikprøverne. En mere fuldstændig arbejdsgang for kortlægning finder du i datakortlægning og databeskyttelse.

Kortlæg ansvaret tjeneste for tjeneste

Ansvarsgrænsen ændrer sig med tjenestemodellen og udbyderens implementering. Brug det følgende som et udgangspunkt, der skal bekræftes i forhold til tjenestedokumentation og kontrakter, ikke som en universel fordeling.

Registrér for hver vigtig beskyttelsesforanstaltning udbyderens bidrag, kundens konfiguration, driftsejeren, revieweren og dokumentationskilden. Undgå registreringer som »kryptering: udbyder«. Skriv i stedet: »Udbyderen leverer administreret kryptering; platformteamet vælger nøglekonfigurationen; sikkerhedsfunktionen gennemgår dekrypteringsrettigheder; tjenesteejeren tester genopretning.«

Medtag tjenesteidentiteter og deploymentautomatisering sammen med menneskelige brugere. En pipeline, der opretter ressourcer, ændrer adgangspolitikker eller henter hemmeligheder, er en del af sikkerhedsgrænsen. Operatører af administrerede tjenester og eksterne supportleverandører har også brug for eksplicitte ansvarsområder, selv når de administrerer infrastruktur på jeres vegne.

Identificér fejl i overdragelser. Hvis udbyderen melder om en kompromitteret adgangsoplysning, hvem modtager så meddelelsen uden for arbejdstid? Hvis en database er utilgængelig, hvem beslutter så, om der skal gendannes, skiftes til en reserve eller ventes? Udpeg én ansvarlig intern ejer for hvert resultat på kundesiden, også hvor flere teams udfører arbejdet.

Vurder udbyderens dokumentation uden at strække den for langt

Gennemgå tjenestens sikkerhedsdokumentation, kommunikation ved hændelser, ordninger for supportadgang, underdatabehandlere, sletningsadfærd, genopretningsmuligheder og tilgængelige auditlogs. Kontrollér, om det relevante kontoniveau faktisk omfatter de funktioner, jeres design kræver.

Dokumentation for sikkerhed kræver en gennemgang af omfanget. En SOC 2-rapport er en erklæringsrapport, ikke en certificering. En ISO 27001-certificering vedrører et afgrænset ledelsessystem for informationssikkerhed og beviser ikke, at jeres tenant er sikkert konfigureret. Kontrollér de omfattede tjenester, rapporteringsperioden, undtagelserne og de kundekontroller, som rapporten angiver.

Hvor det er relevant, indeholder BSI's C5-katalog kriterier for sikkerhed i skyen. Skeln mellem en Type 1-vurdering af design og implementering på et bestemt tidspunkt og en Type 2-dækning af driften over en periode. Ingen af dem erstatter test af jeres egne adgange og dataflows.

Omsæt forpligtelser til tekniske krav

Fastlæg gældende lovgivning og kundeforpligtelser, før I vælger en region eller accepterer udbyderens vilkår. Anvendelsesområdet afhænger af oplysningerne, rollerne i behandlingen, sektoren, jurisdiktionerne og tjenesterelationerne. En rapport eller et certifikat fra udbyderen dokumenterer ikke jeres organisations overholdelse af loven.

For personoplysninger, der er omfattet af databeskyttelsesforordningen (GDPR), kræver artikel 32 et sikkerhedsniveau, der passer til risikoen; det er ikke et generelt krav om at kryptere ethvert datasæt under alle omstændigheder. Hvor udbyderen er databehandler, skal de kontraktlige krav i artikel 28 vurderes. Ordninger for internationale overførsler kræver en særskilt vurdering. Dataenes placering alene beviser hverken suverænitet eller overholdelse af GDPR, særligt hvor supportadgang eller underdatabehandlere skaber yderligere adgangsveje.

Som en praktisk anbefaling bør hvert relevant krav omsættes til en testbar erklæring: tilladte behandlingsregioner, godkendte modtagere, opbevaringsperioder, adgangsbegrænsninger, genopretningsmål eller overdragelser ved underretning om hændelser. Lad jurister og databeskyttelsesspecialister bekræfte fortolkningen, mens udviklingen fastlægger, hvordan kravet implementeres og dokumenteres.

Kontrollér den effektive adgang, ikke kun de tilsigtede rettigheder

Stjålne adgangsoplysninger, for vidtgående rettigheder, offentlig deling og misbrug fra insidere er almindelige veje til eksponering af data i skyen. Et krypteret lager kan stadig afsløre registreringer via en autoriseret konto eller en applikation, der returnerer den forkerte kundes data.

Føderér menneskelige identiteter, hvor det er muligt, så processerne for tiltrædelse, jobskifte og fratrædelse når cloudtjenesterne. Kræv stærk autentificering ved privilegeret adgang, foretræk phishing-resistent MFA, hvor det understøttes, og adskil rutinearbejde fra administration. Nødadgang kræver kontrollerede adgangsoplysninger, overvåget brug og en testet genopretningsproces; den må ikke blive en permanent omvej.

For workloadidentiteter bør I, hvor det understøttes, foretrække snævert afgrænsede adgangsoplysninger med kort levetid. Gennemgå tillidsrelationer: Hvilken workload må overtage en rolle, under hvilke betingelser og i hvilket miljø? Fjern indlejrede hemmeligheder fra repositories og deploymentartefakter, og begræns adgangen til selve hemmelighedstjenesten.

Vurder de effektive rettigheder på tværs af identitetspolitikker, ressourcepolitikker, overtagelse af roller, gruppemedlemskaber, delingslinks og begrænsninger på organisationsniveau. »Skrivebeskyttet« kan stadig tillade udtræk af følsomme oplysninger i stor skala. En rolle, der ikke kan læse registreringer, men kan ændre applikationen eller nøglepolitikken, kan opnå adgang indirekte.

Dokumentation for adgangsgennemgange bør angive principal, ressource, tilladte handlinger, forretningsmæssig begrundelse, godkender og eventuel dato for fjernelse. Test fratrædelser og udløbet midlertidig adgang i stedet for udelukkende at stole på en skriftlig procedure.

Undersøg eksponering og applikationsadfærd samlet

Fejlkonfigurationer kombinerer ofte flere indstillinger, der hver for sig virker rimelige. For et objektlager besvarer standardkryptering ikke, hvem der kan læse objekterne, eller om en delingspolitik gør dem offentlige. Undersøg identitet, ressourcepolitikker, applikationsadfærd og overvågning samlet.

Kontrollér begrænsninger af offentlig adgang, indgående netværkstrafik, databaselyttere, tillid på tværs af konti, adfærden for signerede links og ekstern deling. Private endpoints kan mindske eksponeringen, men de retter ikke for vidtgående rettigheder eller en sårbar applikation. Adskil miljøer, og begræns adgangen til produktion fra udviklingssystemer.

Cloud-API'er kræver autentificering og autorisation på objekt- og handlingsniveau. Et gyldigt brugertoken må ikke give nogen mulighed for at hente en anden tenants registreringer ved at ændre et id. Test eksportendpoints, administrative operationer, masseforespørgsler og uploadhåndtering. Hastighedsbegrænsninger kan mindske misbrug, men erstatter ikke autorisation.

Brug review af infrastructure as code og politiktjek til at forhindre kendte usikre indstillinger, og sammenlign derefter de godkendte regler med den udrullede konfiguration. Ændringer i konsollen, migreringer og nødrettelser kan skabe afvigelser. Registrér, hvorfor undtagelser findes, deres kompenserende kontroller, og hvornår de udløber. Trusselsmodellering kan hjælpe med at identificere veje fra en eksponeret grænseflade til følsomme data før implementeringen.

Gør kryptering og nøgleadgang til separate kontroller

Beskyt data under overførsel med moderne autentificerede protokoller og passende certifikatvalidering. Gennemgå interne applikationsforbindelser lige så vel som offentlige endpoints. For lagrede data skal I fastlægge, hvilke tjenester, replikaer, eksporter, snapshots og sikkerhedskopier der er krypteret, og under hvilke nøgleordninger.

Nøgler administreret af udbyderen og nøgler administreret af kunden understøtter forskellige driftsmæssige valg. Vælg ud fra trusselsmodellen, kontraktlige krav, administrativ adskillelse og behovet for genopretning. En kundeadministreret nøgle er ikke automatisk sikrere, hvis den samme ubegrænsede administrator kontrollerer både dataadgang og nøglerettigheder.

Dokumentér, hvem der må kryptere, dekryptere, administrere, deaktivere og slette nøgler. Gennemgå ændringer i nøglepolitikker og usædvanlig dekrypteringsaktivitet. Fastlæg processer for rotation, tilbagekaldelse, opbevaring og genopretning; afhængigt af tjenesten genkrypterer rotation af en nøgle ikke nødvendigvis alle eksisterende kopier.

KMS- og HSM-tjenester kan understøtte beskyttelse af nøgler og kryptografiske operationer, men de fjerner ikke ansvaret for livscyklussen. Test konsekvenserne af, at en nøgle ikke er tilgængelig, før en proces for sletning eller tilbagekaldelse håndhæves. En beskyttet sikkerhedskopi er ubrugelig, hvis den nødvendige nøgle ikke kan gendannes. Se kryptering og nøglehåndtering for de understøttende kryptografiske beslutninger.

Overvåg dataaktivitet, og bevar evnen til at reagere

Logningen skal dække de spørgsmål, som de reagerende skal kunne besvare. Administrative auditbegivenheder kan vise, hvem der ændrede en politik, uden at vise, hvem der downloadede et datasæt. Fastlæg, hvor logning af dataadgang er tilgængelig, om den er aktiveret, og hvilke begivenheder eller tjenester der stadig ligger uden for dækningen.

Indsaml relevante begivenheder vedrørende identitet, kontrolplan, dataadgang, applikationer, nøgleadministration og deling. Bevar konto- og ressource-id'er, aktørens identitet, tidsstempler, handlinger og resultater. Beskyt logfiler mod ændring og uautoriseret sletning. Undgå at placere følsomt indhold eller genanvendelige adgangsoplysninger i logfiler; diagnostiske data kan blive endnu en kilde til eksponering.

Prioritér detektionsscenarier som:

• Et begrænset lager, der bliver offentligt tilgængeligt.
• Ny ekstern tillid eller tildeling af en privilegeret rolle.
• Usædvanlige masseeksporter eller adgang fra en inaktiv identitet.
• Logning, der deaktiveres, eller hvis destination ændres.
• Sletning af sikkerhedskopier eller ændringer i nøgleadministrationen.

Definér, hvem der reagerer, og test alarmer gennem en kontrolleret øvelse. En regel, der sender alarmer til en indbakke, som ingen holder øje med, er ikke en effektiv detektionsproces. Registrér fejl i indsamlingen, forsinket indlæsning, nyoprettede ressourcer og begrænsninger hos udbyderen i stedet for at præsentere et dashboard som fuld dækning.

Under en hændelse skal relevant dokumentation bevares, og inddæmningen koordineres på tværs af identiteter, applikationer og lagre. Tilbagekaldelse af ét token afslutter ikke nødvendigvis andre sessioner eller standser en eksport, der allerede er i gang. Ved brud på persondatasikkerheden efter GDPR underretter databehandlere de dataansvarlige uden unødig forsinkelse. Dataansvarlige anmelder bruddet til tilsynsmyndigheden uden unødig forsinkelse og om muligt senest 72 timer efter at være blevet bekendt med det, medmindre det er usandsynligt, at bruddet indebærer en risiko for fysiske personers rettigheder og frihedsrettigheder. Brud med høj risiko kræver også underretning af de berørte personer uden unødig forsinkelse, med forbehold af undtagelserne i artikel 34. Bevar begrundelsen for anmeldelse eller manglende anmeldelse.

Brug sikkerhedsværktøjer til definerede spørgsmål

Cloudsikkerhedsværktøjer er mest nyttige, når deres omfang og beslutningsformål er klart:

Begynd håndhævelsen af DLP med repræsentative tests og gennemgang hos dataejerne. En regel, der blokerer legitimt supportarbejde, kan drive brugerne mod ukontrollerede omveje. Begræns scannere og overvågningsagenter til den adgang, de har brug for; et kortlægningsværktøj med bred læseadgang bliver selv en følsom komponent.

Automatisering kan mindske gentagne kontroller og indsamling af dokumentation. Den kan ikke fastslå, at en ikke-understøttet tjeneste er sikker, eller at en juridisk fortolkning er korrekt. Hold den menneskelige gennemgang eksplicit for væsentlige fund og undtagelser.

Påvis genopretning uafhængigt af backupstatus

Sikkerhedskopier beskytter kun mod tab og korruption, hvis de kan gendannes inden for tjenestens behov. Fastlæg sammen med forretningsejeren mål for genopretningspunkt (RPO) for acceptabelt datatab og mål for genopretningstid (RTO) for acceptabel afbrydelse.

Skeln mellem replikering, versionering, snapshots og sikkerhedskopier. Replikering kan kopiere korruption eller sletning. Snapshots kan forblive sårbare over for den samme administrator, som kontrollerer produktionen. Vælg beskyttede kopier og administrativ adskillelse, der passer til trusselsmodellen, herunder beskyttelse mod sletning, hvor det understøttes.

Gendan en repræsentativ workload i et isoleret miljø. Kontrollér datakonsistens, applikationsafhængigheder, identitetskonfiguration, nøgletilgængelighed og den forløbne genopretningstid. Gendannelse af databasen alene viser ikke, at forretningstjenesten fungerer. Registrér fejl, og test igen efter afhjælpning.

Vurder genopretning af SaaS særskilt. Udbyderens katastrofegenopretning kan gendanne platformen uden at omgøre en utilsigtet sletning i jeres tenant. Fastlæg den tilgængelige granularitet for gendannelse, opbevaringsvinduer, eksportmuligheder og ansvaret for at igangsætte genopretning. Anvend også klassifikations- og opbevaringsregler på sikkerhedskopier.

Gennemgået eksempel: en tjeneste til kundeeksport

Tag som illustration et SaaS-team, der bruger en administreret database, et objektlager til eksporter og en baggrundsworker. Antag, at eksporterne indeholder fortrolige kontaktoplysninger om kunder, at kunderne kun har adgang til deres egne eksporter, og at de aftalte genopretningsmål er fire timers datatab og otte timers afbrydelse. Det er antagelser i eksemplet, ikke anbefalede universelle mål.

Udbyderen driver den administrerede infrastruktur. Platformteamet konfigurerer netværksbegrænsninger, identiteter, kryptering og logning. Applikationsudviklerne ejer tenantautorisationen og adfærden for eksportlinks. Tjenesteejeren godkender opbevarings- og genopretningsmål; sikkerhedsfunktionen gennemgår adgang og dokumentation.

Workeren får rettighed til at læse de nødvendige databaseregistreringer og skrive eksporter til det angivne lager. Den har ikke brug for rettighed til at ændre lagerpolitikken eller slette sikkerhedskopier. Downloads går gennem tenantautorisation; eventuelle midlertidige links har begrænset gyldighed og behandles som bærertokens. Eksportfiler udløber i henhold til den godkendte opbevaringsregel.

Testen omfatter en uautentificeret anmodning om et objekt, en kunde, der forsøger at hente en anden kundes eksport, og en worker, der forsøger en forbudt administrativ handling. Reviewerne kontrollerer også, at offentlig adgang er blokeret, og at testdownloads giver de forventede auditbegivenheder.

En gendannelsesøvelse kontrollerer databasen og applikationsafhængighederne i forhold til de antagne genopretningsmål. Dokumentationen omfatter konfigurationseksporter, resultater af autorisationstests, stikprøver af adgangsbegivenheder og registreringen af gendannelsen. Hvis logning af dataadgang mangler for én region, registrerer gennemgangen manglen og tildeler afhjælpning; vellykkede tests andre steder lukker den ikke.

Bevar omfang, undtagelser og beslutninger fra gennemgange

Dokumentationen bør identificere konto, ressource, tidspunkt, indsamlingsmetode og reviewer. En konfigurationseksport fra én konto kan ikke dokumentere alle kontis tilstand. Sammenlign de indsamlede ressourcer med fortegnelsen, og registrér mislykkede indsamlinger eller utilgængelige lokationer.

Vedligehold et kompakt dokumentationssæt for hver tjeneste: ansvarskortet, den godkendte baseline, aktuelle konfigurationstjek, gennemgang af effektiv adgang, logningsdækning, genopretningsresultater og åbne undtagelser. Hver undtagelse kræver en ejer, en risikobegrundelse, kompenserende kontroller, godkendelse, udløbsdato og en betingelse for ny test.

Brug planlagte gennemgange sammen med hændelsesudløste udløsere. Væsentlige ændringer i deployment, nye regioner, leverandørskift, hændelser, ændrede dataklassifikationer og nye delingsveje bør udløse en ny vurdering. NIST Cybersecurity Framework er en nyttig organiserende reference på tværs af Govern, Identify, Protect, Detect, Respond og Recover; den er vejledning, ikke bevis for, at en implementering opfylder sine forpligtelser.

Secani kan forbinde dette arbejde med krav, målobjekter, dokumentation, ejere, opgaver og beslutninger fra gennemgange. Modellér cloudtjenesten og dens afhængigheder, knyt konfigurationseksporter og testregistreringer til de kontroller, de understøtter, og omdan manglende dækning til tildelt arbejde. Hold menneskelig godkendelse og sporbarhed til kilderne eksplicit. Cloudsikkerhedsværktøjer forbliver kilden til teknisk konfiguration og alarmer; compliance-arbejdsområdet bevarer deres omfang og de handlinger, de understøtter.

Vælg ét følsomt dataflow til den næste tekniske gennemgang. Følg hver kopi og adgangsvej, placér ansvaret på kundesiden, test de effektive rettigheder, og gendan en repræsentativ workload. Udvid omfanget, når gennemgangen giver pålidelig dokumentation og en gentagelig proces.