In English

Cloud • Artikel

11 oktober, 2021

Vanliga misstag i cloudmiljöer

Cloudmiljöer anses ofta vara både säkrare och enklare att ta hand om än ett datacenter i en fysisk lokal, vilket gör att allt fler företag väljer att gå över till en molnbaserad drift. Men även molnmiljöer kan medföra risker om de inte hanteras på rätt sätt – här är några av de vanligaste misstagen.

Allt fler företag använder väljer att gå från on-premises till cloudmiljöer för att effektivisera, skala och sänka verksamhetens kostnader. I många fall anses cloudmiljöer även vara ett säkrare alternativ, då flera av dem tillhandahåller funktioner och verktyg som kan användas för att höja säkerheten.

Men företag som använder molntjänster är inte förskonade från incidenter och dataläckor, som i många fall uppstår på grund av felkonfigurationer i miljön. Dessa felkonfigurationer kan exempelvis handla om att man använder standardregler för tjänster eller har för generösa användarrättigheter. Sådana misstag kan i sin tur orsaka att för mycket data exponeras och/eller öka möjligheten för angripare att ta över hela miljön. Det är därför viktigt att ha koll på vanliga misstag när du sätter upp din cloudmiljö och hur dessa kan undvikas.

Här är några av de vanligaste felkonfigurationerna i miljöerna som finns i Azure, Amazon Web Services och Google Cloud Platform.

För öppna privilegier

S3 buckets, Containers & Blobs, Buckets; dessa är de vanligaste lagringstyperna i AWS, Azure respektive GCP. Kortfattat är det ett sätt att lagra filer i molnet. För enkelhetens skull kallas alla lagringstyper i denna artikel för buckets, men de kan även gå under andra namn beroende på leverantör.

Exempel på URL:er kan vara:

https://s3.amazonaws.com/[bucket]/ eller https://[bucket].s3.amazonaws.com (Amazon)

[blobnamn].blob.core.windows.net, [filservicenamn].file.core.windows.net (Azure)

https://www.googleapis.com/storage/v1/b/[bucketnamn] (GCP)

Som administratör kan du sätta olika sorters tillåtelse för vem som har åtkomst till vad, och hur de ska få åtkomst. Men inställningarna tillåter även valet att göra lagringen publikt tillgänglig, vilket gör att vem som helst på internet skulle kunna få tillgång till dess innehåll.

Som angripare är denna lagring ofta det första man letar efter. Det finns webbsidor som använder stora mängder data, så kallad data mining, som söker efter existerande cloud-buckets. Dessa finns sedan publikt för vem som helst att söka efter. Eftersom buckets behöver en unik URL som följer en standard efter vad cloudleverantören använder, går det ofta att använda skript för att hitta en publik bucket.

Vid flytt av data till molnet är det lätt glömma av att kontrollera sina storage-permissions, och det är alltid värt att dubbelkolla om lagringen är korrekt exponerad.

Dåligt lagrade nycklar 

Dåligt lagrade nycklar är ett av de misstag som kan innebära vägen in för angripare. Exempel på nycklar är bland annat API-nycklar, lösenord och SSH-nycklar. Dessa behöver lagras på ett optimalt sätt, och framförallt inte i klartext. Vissa nycklar går bland annat att hitta i buckets, kod eller skript som är bifogade på en VM (Virtual Machine). Dessa kan sedan användas för att ta över resurser där nyckeln används.

I de fall någon sorts autentiserad tillåtelse krävs, behöver du sannolikt använda en nyckel. Men att lagra nycklar effektivt och säkert kan ibland vara en utmaning. Och om en nyckel skulle bli läckt, vad gör man då?

Cloudleverantörer kan erbjuda en sorts “keyvault”. Där ska hemligheter lagras, och det är upp till leverantören att garantera dess säkerhet. Det är en relativt enkel lösning för resurser som lever i cloud. Här kan du också använda “key rotation” som kan byta ut hemligheten. Detta kan ställas in på en specifik tidpunkt eller med ett visst tidsintervall, eller manuellt om en nyckel skulle läcka.

Vid hybridlösningar, i de fall du både har egna servrar och cloudlösning, kan ansvaret för nyckelförvaring variera. Vissa omständigheter, såsom företagskrav, kan dock förbjuda lagring av hemligheter i en keyvault.

Som tumregel bör nycklar inte sparas i klartext även om du inte räknar med att någon skulle kunna hitta filen där nycklarna sparas. När du förvarar nycklar bör de alltid vara krypterade och ha någon form av rutin för att förnya dem ifall de skulle läckas online. Keyvaults hos populära cloudleverantörer krypterar nyckeln som standard, men du kan också välja att kryptera nyckeln själv.

Det är även viktigt att ha kontroll över vem som har åtkomst till att läsa ut hemligheter, vilket är en av andledningarna till att använda IAM - man skyddar helt enkelt inte pengar i ett kassaskåp om vem som helst kan öppna det.

Övertagna konton 

En av fördelarna med cloudlösningar är att användarna kan logga in och komma åt program och information var de än befinner sig, så länge de har tillgång till internet. Baksidan är just tillgängligheten, eftersom den öppnar upp möjligheten att ta över konton genom phishing, svaga lösenord, brute-force eller läckta, återanvända lösenord. Kombineras detta med otillräcklig IAM kan konsekvenserna bli allvarliga.

I många fall erbjuder cloudlösningar verktyg för att skydda konton från att bli övertagna genom dessa metoder. Ett exempel är krav på multi-faktorsautentisering (MFA), som är en växande säkerhetsstandard. Multi-faktorsautentisering innebär ett extra krav utöver ditt lösenord som visar på att du verkligen är du. Oftast innebär det att du behöver komplettera lösenordet med en verifieringskod som skickas till din telefon via SMS, eller genereras via en app, till exempel Google Authenticator.

Som standard brukar cloudlösningar även blockera användare från att logga in efter x antal felaktiga inloggningar, vilket bland annat kan hjälpa mot brute-force-attacker. Detta är generellt något som är påslaget för standardtjänster, men det går också att ta hjälp av olika övervakningstjänster som cloudleverantörerna brukar erbjuda. Dessa övervakningstjänster kan hjälpa till att hålla koll på ovanlig trafik, samt ge möjlighet att agera på denna. Utöver det går det även att ställa in så att användare endast kan logga in via VPN eller en specifik enhet.

Till sist är det alltid viktigt att utbilda sina anställda om cyberhot och hur de skyddar sig emot dem. Se hela organisationen som en måltavla, där en anställd med ett svagt lösenord eller bristande kunskap om phishing kan utgöra ett lika stort hot mot säkerheten som en dåligt konfigurerad miljö.

Vill du veta mer om hur du kan säkra upp din molnmiljö?

Vi på Sentor hjälper många olika företag att säkra upp sina molnmiljöer genom säkerhetstestning. Med erfarenhet av att säkerhetsgranska cloudmiljöer såsom AWS, Azure, och GCP kan vi hjälpa din säkerhetsstruktur att bli så säker som möjligt. Hör av dig på info@sentorsecurity.com, så berättar vi mer!