Beredskabsplan for cloudsikkerhedshændelser: bedste praksis og trin for trin

Livscyklussen for håndtering af hændelser, tilpasset cloud

NIST SP 800-61 Rev. 3 præsenterer ikke længere håndtering af hændelser som en selvstændig cyklus i fire faser. Den kobler aktiviteterne til CSF 2.0-funktionerne: Govern, Identify, Protect, Detect, Respond og Recover. I praksis organiserer de fleste teams stadig deres runbooks efter de velkendte faser nedenfor, og det fungerer fint, så længe forberedelse og erfaringer føres tilbage i governance.

Trin 1: Forbered planen, folkene og platformen

Definér omfang og governance

Angiv, hvilke miljøer planen dækker: alle cloudkonti, abonnementer og projekter samt de SaaS-platforme, der indeholder forretningsdata (Microsoft 365, Google Workspace, Salesforce og lignende). Registrér dataklassifikationer, for en lækage af kunders personoplysninger eskalerer hurtigere end en åben testbucket.

Udpeg en ejer af planen, en gennemgangsrytme (mindst årligt og efter større hændelser eller ændringer af arkitekturen) og kobling til dine planer for forretningskontinuitet og disaster recovery. Under NIS2 kræver artikel 20, at ledelsesorganerne i væsentlige og vigtige enheder godkender risikostyringsforanstaltningerne for cybersikkerhed og fører tilsyn med gennemførelsen, så godkendelse på bestyrelsesniveau er ikke længere frivillig for omfattede virksomheder.

Fordel roller, før du får brug for dem

Udpeg en stedfortræder til hver rolle, og hav en kontaktliste uden for de almindelige kanaler. Hvis angriberen har din Microsoft 365-tenant, er Teams ikke et sikkert krisehåndteringsrum.

Indret platformen til respons

• Central, manipulationssikker logning. Send CloudTrail, aktivitetslogs i Azure, sign-in- og auditlogs i Microsoft Entra ID, Google Cloud Audit Logs, flow logs for VPC/NSG og DNS-logs til en dedikeret log-konto eller et workspace, som administratorer i produktion ikke kan slette fra. Brug object lock eller uforanderlig lagring til arkivet.
• Opbevaring, der passer til undersøgelser. Når et brud måles i måneder, er 30 dages logs for lidt. Fastsæt opbevaringen efter dataklasse og lovkrav.
• Break-glass-adgang. Hav et lille antal nødkonti med hardware-MFA, opbevaret og overvåget separat, så responsteamet ikke bliver låst ude, når det er identitetsudbyderen, der er under angreb.
• Forberedt forensisk kapacitet. En separat forensics-konto eller et abonnement med værktøjer klar, hvor du kan kopiere snapshots til analyse uden at røre produktionen.
• Segmentering og mindste rettigheder. Separate konti pr. miljø, afgrænsede roller og service control policies begrænser, hvor langt en hændelse kan sprede sig.
• Uforanderlige gendannelsespunkter. Versionerede backups på tværs af konti og images, du kan genopbygge fra, beskyttet mod de samme legitimationsoplysninger som dem, der driver produktionen.

Trin 2: Opdag og triagér cloudhændelser

God detektion i cloud kombinerer udbyderens indbyggede trusselsdetektion med din egen korrelation. De native tjenester kender platformen, dit SIEM kender din forretningskontekst.

• Aktivér Amazon GuardDuty, Microsoft Defender for Cloud eller Google Security Command Center i alle konti og regioner, ikke kun produktion.
• Videresend fund og identitetslogs til ét SIEM, så en anomali i et Entra ID-login og et usædvanligt AWS API-kald fra samme bruger vises som én sag.
• Alarmér på hændelser med stærkt signal: login som root eller global administrator, nye adgangsnøgler til privilegerede brugere, deaktiveret logning, offentlige politikker for lagring, nye regioner i brug, pludselige udsving i forbruget af beregning.
• Tilføj trusselsinformation, så alarmer knyttet til kendt ondsindet infrastruktur rykker øverst i køen.

En enkel triagematrix

Eksempel på runbook: mistænkelig brug af en adgangsnøgle

1. Bekræft aktiviteten i audit-loggen: kilde-IP, user agent, regioner og API-kald de seneste timer.
2. Deaktivér nøglen (slet den ikke endnu), og tilbagekald aktive sessioner for principalen.
3. Undersøg, hvad nøglen kunne nå, og hvad den gjorde: nye brugere, roller, nøgler, instanser, dataopslag.
4. Tag snapshots af berørte instanser, og eksportér de relevante logs til forensics-kontoen.
5. Underret incident commander og jura, hvis dataadgang er sandsynlig.
6. Roter alle hemmeligheder, principalen kunne læse, og fjern derefter den persistens, angriberen har oprettet.

Trin 3: Sikr beviser på cloudens vilkår

Forensics i cloud handler mest om hastighed og automatisering. Skriv disse trin ind i alle runbooks, der ender i lukning eller genopbygning:

• Tag disk-snapshots og, hvor dine værktøjer understøtter det, et hukommelsesaftryk, før du isolerer eller stopper en VM.
• Mærk isolerede ressourcer med hændelsens ID, så ingen "rydder op" i beviserne.
• Kopiér snapshots og logudtræk til forensics-kontoen, og registrér, hvem der har haft adgang og hvornår.
• Hold alle systemer på synkroniseret tid (NTP, UTC i logs), så du kan korrelere hændelser på tværs af udbydere.
• Vid, hvordan du anmoder din udbyder om oplysninger. Kontrakter med SaaS-leverandører og MSSP'er bør angive, hvilke logs de gemmer, hvor længe, og hvor hurtigt de udleverer dem.

AWS Security Incident Response Guide gennemgår disse metoder i detaljer for AWS. De samme principper gælder i Azure og Google Cloud.

Trin 4: Inddæmm, fjern og genopret

Kortsigtet inddæmning

• Isolér instanser ved at bytte deres security group eller NSG ud med en deny-all-gruppe, der kun tillader forensisk adgang.
• Deaktivér nøgler, tilbagekald tokens og sessioner, og gennemtving nulstilling af adgangskoder og MFA for kompromitterede identiteter.
• Bloker offentlig adgang til åben lagring. Anvend en eksplicit deny-politik eller en service control policy, hvis angriberen har administratorrettigheder.
• Tilføj WAF-regler eller rate limits mod angreb på applikationslaget.

Langsigtet inddæmning og fjernelse

• Fjern bagdørsbrugere, roller, nøgler, planlagte opgaver, Lambda-funktioner eller container-images, angriberen har tilføjet.
• Genopbyg workloads fra kendte, gode images og infrastructure as code i stedet for at "rense" dem på stedet.
• Ret rodårsagen: den for vidtgående rolle, den lækkede hemmelighed i CI/CD-pipelinen, det ikke-patchede image.
• Tilføj et værn (policy-as-code, SCP, Azure Policy), så den samme fejlkonfiguration ikke kan vende tilbage.

Genopretning og validering

Gendan kritiske tjenester først fra rene backups, og verificér derefter integriteten: Kør tests, sammenlign konfigurationen med IaC, og kontrollér, at adgangspolitikkerne er som tilsigtet. Hold skærpet overvågning på de berørte konti i en fastsat periode, for eksempel 30 dage, fordi angribere ofte forsøger at vende tilbage. Designet af din disaster recovery i cloud afgør, hvor hurtigt dette trin kan gå.

Trin 5: Kommunikation, jura og lovbestemte frister

Frister for underretning løber fra det tidspunkt, du bliver opmærksom på hændelsen, ikke fra undersøgelsen er slut. Skriv dem ind i planen med navngivne ansvarlige.

NIS2 er et direktiv, så national lovgivning fastsætter den præcise myndighed og indberetningsformatet. Tjek, hvordan dit land har gennemført det. Tjek også kundekontrakter: Mange B2B-aftaler har deres egne frister for underretning.

Forbered skabeloner til interne opdateringer, kundebeskeder og rapporter til myndighederne på forhånd. Aftal en underretningsmatrix baseret på alvorlighed: hvem der får besked ved kritisk, høj, middel og lav alvorlighed, og hvor hurtigt. Lad altid eksterne udtalelser gå gennem jura.

Trin 6: Test, mål og forbedr

Øvelser

• Tabletop-øvelser mindst to gange om året: Gennemgå en lækket adgangsnøgle, en kompromitteret global administrator eller ransomware på VM'er i cloud med teknisk, juridisk og kommunikationsfaglig deltagelse.
• Tekniske øvelser mindst årligt i en konto uden for produktion: Kør runbooks til inddæmning for alvor, og tag tid.
• Restore-tests, der beviser, at du kan genopbygge fra IaC og backups i en ren konto.

Nøgletal

Automatisér de gentagelige trin

Automatisering skærer minutter af hver hændelse. Typiske kandidater: at deaktivere en nøgle, som GuardDuty har markeret, at isolere en instans ved et fund med høj alvorlighed og at oprette en ticket med bevis vedhæftet. I Azure gør playbooks i Microsoft Sentinel bygget på Logic Apps det samme. Bevar et menneskeligt godkendelsestrin for handlinger, der kan forårsage nedbrud.

Noter om platformene AWS, Azure og Google Cloud

AWS

• Brug et CloudTrail-trail for hele organisationen, der dækker alle regioner, med management events og data events for følsomme S3-buckets.
• Aktivér GuardDuty med en delegeret administratorkonto, og saml fund i AWS Security Hub.
• Send fund med høj alvorlighed via Amazon EventBridge til dit vagt- eller ITSM-værktøj, så en responder får alarm inden for få minutter.

Azure

• Aktivér de relevante planer i Microsoft Defender for Cloud på alle abonnementer.
• Kontrollér adgang med sign-in- og auditlogs i Microsoft Entra ID. Brug Conditional Access til at blokere risikable login under en hændelse.
• Brug analytics-regler og playbooks i Microsoft Sentinel til korrelation og respons.

Google Cloud

• Aktivér Security Command Center på organisationsniveau.
• Gem Cloud Audit Logs og VPC Flow Logs, og eksportér dem til et aflåst log-projekt.
• Google Security Operations (tidligere Chronicle) giver SIEM og SOAR, hvis du standardiserer på Google.

Multicloud

Den største svaghed i multicloud er manglende overblik. Normalisér logs fra alle udbydere i ét SIEM, brug ét sæt definitioner af alvorlighed, og skriv runbooks, der angiver den tilsvarende handling på hver platform. Test de API-kald, din automatisering afhænger af, for udbyderne ændrer dem.

Sådan hjælper Opsio

Opsios SOC-tjeneste og managed detection and response leverer overvågning og respons døgnet rundt for AWS- og Azure-miljøer fra vores teams i Sverige og Indien. Vi hjælper kunder med at skrive og teste deres plan, opsætte central logning og automatisere de første trin i inddæmningen.

For Branäsgruppen, en af Sveriges største skiresortgrupper, driver Opsio kritiske applikationer på tværs af flere Availability Zones med daglige inkrementelle og ugentlige fulde backups, der gemmes i 60 dage. Casen om Branäsgruppen rapporterer en gennemsnitlig tid på 2 dage til at identificere og løse kritiske problemer og over 99,9 % oppetid for applikationerne.

Ofte stillede spørgsmål

Hvad er bedste praksis for håndtering af hændelser i cloud?

Slå audit-logning til overalt, og gem den centralt. Følg NIST SP 800-61 Rev. 3, skriv runbooks til almindelige cloudhændelser, automatisér sikring af beviser, inddæm via identitets- og netværkskontroller, genopbyg fra IaC, og test planen med regelmæssige tabletop-øvelser.

Hvordan adskiller håndtering af hændelser i cloud sig fra on-premises?

Du deler ansvaret med udbyderen, beviserne kommer fra logs og API'er og ikke fra fysiske diske, ressourcer kan forsvinde på få sekunder, og de fleste angreb bruger stjålne identiteter. Inddæmning er som regel en ændring af IAM eller politikker og ikke at hive stikket ud på en server.

Hvad bør en skabelon til en beredskabsplan for cloudhændelser indeholde?

Omfang og governance, roller med stedfortrædere og kontaktoplysninger, definitioner af alvorlighed, logkilder og opbevaring, runbooks pr. hændelsestype, håndtering af beviser, en underretningsmatrix med frister for GDPR og NIS2, eskaleringskontakter hos udbydere, trin til genopretning og en testplan.

Hvordan integrerer man håndtering af hændelser med sikkerhedsværktøjer i cloud?

Send fund fra GuardDuty, Defender for Cloud eller Security Command Center og identitetslogs ind i ét SIEM, knyt hver alarmtype til en runbook, og automatisér første trin med lav risiko som deaktivering af nøgler eller isolering af instanser, med menneskelig godkendelse af handlinger, der forstyrrer driften.

Hvor ofte bør en beredskabsplan for cloudhændelser testes?

Kør tabletop-øvelser mindst to gange om året, mindst én teknisk øvelse om året og en ekstra gennemgang efter enhver større hændelse eller ændring af arkitekturen. Opdatér runbooks efter hver test.