De fleste sikkerhetshendelser i skyen handler ikke om å bryte seg inn i skyleverandørens egen infrastruktur. De handler om kundens konfigurasjon: en lagringsbøtte som er åpen for alle, en tilgangsnøkkel lagt inn i et kodelager, en administratorkonto uten flerfaktorautentisering eller en database som kan nås fra hele internett. Skyleverandører arbeider etter en modell for delt ansvar, der de sikrer den underliggende plattformen og dere sikrer det dere konfigurerer på den. Denne guiden lister opp de vanligste risikoene ved feilkonfigurasjon i skyen og praktiske kontroller for hver av dem.
Hva det er
Feilkonfigurasjon i skyen er enhver innstilling i skykontoene som eksponerer data eller systemer mer enn tiltenkt, eller som gjør at dere ikke kan oppdage og gjenopprette etter problemer. Den har en tendens til å hope seg opp etter hvert som teamene vokser, prosjekter opprettes raskt og midlertidige endringer blir permanente. Hovedkategoriene er de samme på tvers av AWS, Microsoft Azure og Google Cloud. Identitet og tilgang: for vide roller, langlivede tilgangsnøkler, delte kontoer og manglende MFA. Lagring: bøtter, blobber eller øyeblikksbilder som kan leses av alle eller er delt for bredt. Nettverk: sikkerhetsgrupper eller brannmurregler som er åpne for alle adresser, eksponerte administrasjonsporter og flate nettverk uten segmentering. Hemmeligheter: innloggingsdetaljer i kode, miljøfiler eller containeravbildninger. Logging: revisjonslogger som er slått av, ikke oppbevares eller aldri gjennomgås. Kryptering: sensitive data lagret uten kryptering eller med dårlig forvaltede nøkler. Robusthet: sikkerhetskopier som mangler, ikke er testet eller lagres i samme konto som de skal beskytte. Styring: ukjente kontoer, ressurser uten merking og prosjekter uten eier.
Hvem det er for
Denne sjekklisten er nyttig for:
- Oppstartsselskaper og SMB-er der skymiljøet har vokst raskt uten en formell design
- Team som forbereder seg på en sikkerhetsgjennomgang fra en kunde eller en due diligence
- Organisasjoner som planlegger å kjøre AI- eller dataarbeidslaster i skyen
- Ledere som har arvet skykontoer fra tidligere ansatte eller leverandører
Hva det hjelper med å klarlegge
Å gå gjennom sjekklisten bidrar til å avklare:
- Hvem som har administratortilgang, og om den er beskyttet og fortsatt nødvendig
- Hvilke data som er offentlig tilgjengelige, med vilje eller ikke
- Om dere ville oppdaget og kunne undersøkt mistenkelig aktivitet
- Om dere kunne gjenopprettet kritiske systemer hvis en konto ble kompromittert
Hva er inkludert
- Håndhev MFA for alle menneskelige brukere, særlig administratorer og rot- eller eierkontoen
- Erstatt langlivede tilgangsnøkler med roller eller kortlivede innloggingsdetaljer der det er mulig
- Gjennomgå roller med tanke på minste privilegium, og fjern ubrukte brukere og tillatelser
- Blokker offentlig tilgang til lagring som standard, og gjennomgå eventuelle unntak
- Begrens administrasjonsporter og databaser til kjente nettverk eller privat tilgang
- Flytt hemmeligheter til en administrert tjeneste for hemmeligheter, og skann kodelagre for lekkede nøkler
- Aktiver revisjonslogging i alle kontoer og regioner som er i bruk, og oppbevar loggene sikkert
- Sett opp varsler for høyrisikohendelser som nye administratorer, deaktivert logging eller offentlig lagring
- Krypter sensitive data ved lagring, og kontroller hvem som kan forvalte nøkler
- Ta sikkerhetskopi av kritiske data til en separat konto eller lokasjon, og test gjenoppretting
- Oppretthold en oversikt over kontoer, prosjekter og ressurseiere
- Bruk infrastruktur som kode, og gjennomgå endringer før de tas i bruk
Hva er ikke inkludert
- En påstand om at et gjennomgått miljø ikke kan kompromitteres
- En formell skyrevisjon, sertifisering eller godkjenning av etterlevelse
- Penetrasjonstesting, med mindre det er avgrenset separat
- Kontinuerlig overvåking eller administrert drift, med mindre det er avtalt separat
Når skal den velges
Bruk denne sjekklisten når dere ikke har gjennomgått skykontoene på en stund, før en sikkerhetsgjennomgang fra en kunde eller investor, etter endringer blant ansatte eller leverandører, og før dere innfører AI eller store dataarbeidslaster. Hvis dere ikke raskt kan svare på hvem som har administratortilgang til hver konto, start der.
Vår tilnærming
Prioriter identitet først, fordi de fleste andre kontroller avhenger av den. Fjern deretter offentlig eksponering, sikre hemmeligheter og sørg for at logging og sikkerhetskopier vil støtte deteksjon og gjenoppretting. Behandle rettelser som teknisk arbeid med eiere og endringskontroll, ikke som en engangsopprydding. Tjenesten vår Cloud Platform & Production Engineering dekker arkitekturbeslutninger, utgivelsesløp, observerbarhet, sikkerhetskopiering og håndbøker for gjenoppretting for avtalte miljøer, der endringer i produksjon bare gjøres etter en godkjent plan og uttrykkelig skriftlig autorisasjon. Hvis dere først trenger en dokumentert oversikt over hvor ting står, kan en Security Baseline Review gi observasjoner gradert etter alvorlighet, og en AI & Cloud Readiness-gjennomgang gir et resultatkort for beredskap og et beslutningsnotat med fokus på grunnmuren for AI-arbeidslaster. Penetrasjonstesting av applikasjoner i skyen kan avgrenses separat. Gå gjennom sjekklisten jevnlig; konfigurasjonen glir etter hvert som team og prosjekter endres.
Ofte stilte spørsmål
Beslektede artikler
Kom i gang
Vil dere ha et klarere bilde av skykonfigurasjonen?
Fortell oss hvilke leverandører og kontoer dere bruker, hva som kjører der, og eventuelle kommende gjennomganger eller migreringer. Vi foreslår et skriftlig omfang.
Be om et skriftlig omfang