De fleste sikkerhedshændelser i cloud involverer ikke, at cloududbyderens egen infrastruktur brydes. De involverer kundens konfiguration: en storage bucket, der er efterladt offentlig, en adgangsnøgle committet til et repository, en administratorkonto uden multifaktorgodkendelse eller en database, der kan nås fra hele internettet. Cloududbydere arbejder efter en model for delt ansvar, hvor de sikrer den underliggende platform, og I sikrer det, I konfigurerer på den. Denne guide oplister de mest almindelige risici ved fejlkonfiguration i cloud og praktiske kontroller for hver af dem.
Hvad det er
Fejlkonfiguration i cloud er enhver indstilling i jeres cloudkonti, der eksponerer data eller systemer mere end tilsigtet, eller som gør, at I ikke kan opdage og komme jer efter problemer. Den har en tendens til at hobe sig op, efterhånden som teams vokser, projekter oprettes hurtigt, og midlertidige ændringer bliver permanente. Hovedkategorierne er de samme på tværs af AWS, Microsoft Azure og Google Cloud. Identitet og adgang: for brede roller, langlivede adgangsnøgler, delte konti og manglende MFA. Lagring: buckets, blobs eller snapshots, som alle kan læse, eller som er delt for bredt. Netværk: security groups eller firewallregler åbne for alle adresser, eksponerede administrationsporte og flade netværk uden segmentering. Hemmeligheder: legitimationsoplysninger i kode, miljøfiler eller containerimages. Logning: auditlogs, der er slået fra, ikke opbevares eller aldrig gennemgås. Kryptering: følsomme data lagret uden kryptering eller med dårligt administrerede nøgler. Modstandsdygtighed: backups, der mangler, ikke er testet eller er lagret i den samme konto, som de skal beskytte. Styring: ukendte konti, ressourcer uden tags og projekter uden ejer.
Hvem er det for?
Denne tjekliste er nyttig for:
- Startups og SMV’er, hvis cloudmiljø er vokset hurtigt uden et formelt design
- Teams, der forbereder sig på en kundes sikkerhedsgennemgang eller due diligence
- Organisationer, der planlægger at køre AI- eller dataworkloads i cloud
- Ledere, der har arvet cloudkonti fra tidligere medarbejdere eller leverandører
Hvad det hjælper med at afklare
At gennemgå tjeklisten hjælper med at afklare:
- Hvem der har administrativ adgang, og om den er beskyttet og stadig nødvendig
- Hvilke data der kan nås offentligt, bevidst eller ej
- Om I ville opdage og kunne undersøge mistænkelig aktivitet
- Om I kunne gendanne kritiske systemer, hvis en konto blev kompromitteret
Hvad er inkluderet
- Håndhæv MFA for alle menneskelige brugere, især administratorer og root- eller ejerkontoen
- Erstat langlivede adgangsnøgler med roller eller kortlivede legitimationsoplysninger, hvor det er muligt
- Gennemgå roller med henblik på mindste privilegium, og fjern ubrugte brugere og rettigheder
- Bloker som standard offentlig adgang til lagring, og gennemgå eventuelle undtagelser
- Begræns administrationsporte og databaser til kendte netværk eller privat adgang
- Flyt hemmeligheder til en administreret secrets-tjeneste, og scan repositories for lækkede nøgler
- Aktivér auditlogning i alle konti og regioner, der er i brug, og opbevar logs sikkert
- Opsæt alarmer for højrisikohændelser såsom nye administratorer, deaktiveret logning eller offentlig lagring
- Kryptér følsomme data ved lagring, og kontrollér, hvem der kan administrere nøgler
- Tag backup af kritiske data til en separat konto eller placering, og test gendannelsen
- Vedligehold en oversigt over konti, projekter og ressourceejere
- Brug infrastructure as code, og gennemgå ændringer, før de anvendes
Hvad er ikke inkluderet?
- En påstand om, at et gennemgået miljø ikke kan kompromitteres
- En formel cloudrevision, certificering eller compliancegodkendelse
- Penetrationstest, medmindre det afgrænses separat
- Løbende overvågning eller administreret drift, medmindre det aftales separat
Hvornår du skal vælge det
Brug denne tjekliste, når I ikke har gennemgået jeres cloudkonti i nogen tid, før en kundes eller investors sikkerhedsgennemgang, efter udskiftning af medarbejdere eller leverandører og før I indfører AI eller store dataworkloads. Hvis I ikke hurtigt kan svare på, hvem der har administrativ adgang til hver konto, så start dér.
Vores tilgang
Prioritér identitet først, fordi de fleste andre kontroller afhænger af den. Fjern derefter offentlig eksponering, sikr hemmeligheder, og sørg for, at logning og backup vil understøtte detektion og genopretning. Behandl rettelser som udviklingsarbejde med ejere og ændringsstyring, ikke som en engangsoprydning. Vores tjeneste Cloud Platform & Production Engineering omfatter arkitekturbeslutninger, release-pipelines, observability, backup og runbooks for genopretning for aftalte miljøer, hvor ændringer i produktion kun foretages efter en godkendt plan og med udtrykkelig skriftlig autorisation. Har I først brug for et dokumenteret billede af, hvor I står, kan en Security Baseline Review give observationer graderet efter alvorlighed, og en AI & Cloud Readiness-gennemgang giver et parathedsscorecard og et beslutningsnotat med fokus på fundamentet for AI-workloads. Penetrationstest af applikationer hostet i cloud kan afgrænses separat. Gennemgå tjeklisten regelmæssigt; konfigurationen glider, efterhånden som teams og projekter ændrer sig.
Ofte stillede spørgsmål
Relaterede artikler
Start
Vil I have et klarere billede af jeres cloudkonfiguration?
Del, hvilke udbydere og konti I bruger, hvad der kører der, og eventuelle kommende gennemgange eller migreringer. Vi foreslår et skriftligt omfang.
Anmod om et skriftligt omfang