Molnsäkerhet

Modellen för delat ansvar definierar hur säkerhetsansvar fördelas mellan en molnleverantör och dess kunder. Leverantören ansvarar för säkerheten i molnet. Fysisk hårdvara, datacenter, global nätverksinfrastruktur och de hanterade tjänster den driver. Kunden ansvarar för säkerheten i molnet. Allt de konfigurerar, driftsätter och bygger ovanpå den infrastrukturen.

Modellen förändras beroende på tjänstetyp. I IaaS hanterar kunden operativsystem, runtime, middleware, data och applikationer. Leverantören hanterar hårdvara och virtualisering. I PaaS hanterar leverantören också runtime och OS, kunden ansvarar för applikationskod och data. I SaaS hanterar leverantören nästan allt och kunden ansvarar primärt för identitet, åtkomstkonfiguration och datastyrning.

Att förstå var ansvarsgränsen ligger för varje använd tjänst är avgörande för att bygga ett komplett säkerhetsprogram. Många molnmiljöer använder flera tjänstetyper simultant. EC2-instanser (IaaS), RDS-databaser (PaaS) och SaaS-samarbetsverktyg, alla i samma konto. Var och en har olika kundansvar som måste hanteras uttryckligen.

Den farligaste missuppfattningen är att anta att en leverantörs efterlevnadscertifiering täcker kundens arbetsbelastning. En leverantör certifierad under PCI DSS ansvarar för sin del, kunden måste självständigt uppfylla PCI DSS-kraven för sin applikationskod, datahantering och konfigurationsval.

Moln-IAM (Identity and Access Management) är den uppsättning policyer, roller och mekanismer som styr vem eller vad som kan utföra åtgärder på molnresurser. Varje stor leverantör (AWS, Azure, GCP) har ett IAM-system i sin kärna. Att behärska IAM är grundläggande för molnsäkerhet eftersom nästan varje allvarligt molnintrång involverar en IAM-felkonfiguration eller kompromiss.

Principen om minsta behörighet är designmålet. Varje identitet bör bara ha de behörigheter som krävs för dess specifika funktion. I praktiken innebär detta att använda roller snarare än användare med direkta behörigheter, att begränsa policyer till specifika resurser snarare än hela konton och att regelbundet granska och ta bort oanvända behörigheter. Jokerteckensåtgärder och -resurser i policyer är varningstecken.

Privilegieeskalering i molnmiljöer sker ofta genom IAM-felkonfigurationer snarare än genom att utnyttja applikationssårbarheter. En angripare som kan ändra sina egna IAM-policyer, skapa nya användare eller anta andra roller kan eskalera från minimal åtkomst till fullständig administrativ kontroll. Automatiserade verktyg identifierar dessa eskaleringsvägar.

IAM Access Analyzer och motsvarande verktyg analyserar faktiska API-anropshistorik för att identifiera vilka behörigheter en roll faktiskt använder i praktiken och föreslår en minimalt nödvändig policy. Att börja med en bred policy och sedan begränsa den baserat på observerad användning är mer praktiskt än att försöka definiera minimibehörigheter i förväg.

Nätverkssegmentering i molnet innebär att dela infrastrukturen i isolerade nätverkssegment (VPC:er, undernät, säkerhetsgrupper) så att en kompromiss av ett segment inte direkt kan nå ett annat. Arkitekturmålet är att arbetsbelastningar bara kan kommunicera med de tjänster de legitimt behöver. En komprometterad webbserver bör inte kunna nå databasservern direkt.

En välsegmenterad molnarkitektur placerar offentliga resurser (lastbalanserare, CDN:er, API-gateways) i offentliga undernät, applikationsservrar i privata undernät utan offentliga IP-adresser och databaser i ett separat privat undernät som bara är tillgängligt från applikationsskiktet. Varje lagers säkerhetsgrupp tillåter bara specifika portar och källor.

Zero Trust-nätverk utvidgar segmentering genom att ta bort implicit förtroende från nätverksposition. Även inom ett privat undernät måste tjänster autentisera sig mot varandra snarare än att förlita sig på antagandet att allt inuti VPC:n är säkert. Detta implementeras via service mesh-mTLS, API gateway-autentisering och strikta säkerhetsgruppsregler.

En vanlig felkonfiguration är säkerhetsgrupper som tillåter inkommande trafik från 0.0.0.0/0 på portar som bara borde vara interna. Internetbaserade skannrar indexerar dessa exponeringar inom minuter från att de skapas. Automatiserad policyverkställighet via molnleverantörers skyddsräcken detekterar och åtgärdar valfritt dessa felkonfigurationer.

Molnlagringstjänster (AWS S3, Azure Blob Storage, GCP Cloud Storage) är bland de mest felkonfigurerade och intrångsutsatta molnresurserna. De lagrar stora mängder känslig data och är tillgängliga från internet om de inte uttryckligen begränsas. Att säkra molnlagring kräver lagerbaserade kontroller, däribland åtkomstpolicyer, kryptering, versionering och åtkomstloggning.

Åtkomstkontroll för molnlagring fungerar via IAM-policyer och bucket-policyer. Den viktigaste kontrollen är att blockera offentlig åtkomst på kontonivå, vilket åsidosätter alla konfigurationer på objekt- eller bucket-nivå som oavsiktligt kan göra data offentlig. Denna enskilda inställning förhindrar den vanligaste kategorin av lagringsrelaterade dataintrång.

Kryptering i vila tillhandahålls som standard i alla större molnlagringstjänster med leverantörshanterade nycklar. Kundhanterade nycklar (CMK) ger kunden kontroll över nyckelns livscykel. Vem som kan använda nyckeln, när den kan roteras och fullständiga granskningsloggar för varje nyckelanvändning. För data som omfattas av regulatoriska krav är kundhanterade nycklar ofta obligatoriska.

Offentligt tillgängliga lagringsbuckets har orsakat många uppmärksammade dataintrång. Lösningen är lagerbaserad. Använd offentliga åtkomstblock på kontonivå, kör CSPM-verktyg som varnar för offentliga lagringsresurser, validera lagringsbehörigheter i IaC-granskningar och aktivera åtkomstloggning. Förlita dig aldrig på dunkelhet som ersättning för korrekt åtkomstkontroll.

Effektiv molnsäkerhet kräver omfattande loggning av API-anrop, resurskonfigurationsändringar, autentiseringshändelser och nätverkstrafik. Utan loggar finns det inget sätt att detektera ett pågående angrepp, utreda ett intrång eller demonstrera efterlevnad. I molnmiljöer innebär detta att aktivera tjänster som AWS CloudTrail, Azure Monitor och GCP Cloud Audit Logs i varje konto och region.

Loggtäckning bör spänna över både kontrollplanet (API-anrop som ändrar konfiguration) och dataplanet (åtkomst till faktisk data). CloudTrail fångar kontrollplansaktivitet. VPC-flödesloggar fångar nätverksnivåtrafik. S3-åtkomstloggar fångar läsningar och skrivningar till objektlagring. Att centralisera alla loggkällor i en SIEM möjliggör korrelation och avisering över hela attackkedjan.

Avisering om säkerhetsrelevanta händelser är vad som omvandlar loggning från en efterlevnadsbockövning till ett aktivt försvar. Viktiga händelser att aviserara om inkluderar. Root-kontoanvändning, IAM-policyändringar, säkerhetsgruppsmodifieringar, ovanliga geografiska åtkomstmönster och deaktivering av säkerhetstjänster. Molnbaserade tjänster aggregerar dessa signaler.

Ett kritiskt gap i många organisationer är loggning utan övervakning. CloudTrail är aktiverat men inga varningar är konfigurerade. Loggdata är bara användbar när någon eller något automatiserat system aktivt tittar på den och reagerar på avvikelser. Att etablera ett mål för medeltid till detektion och mäta mot det avslöjar om övervakningsprogrammet är effektivt.

Molnfelkonfigurationer är den ledande orsaken till molnsäkerhetsincidenter. Till skillnad från attacker som kräver sofistikerat utnyttjande är felkonfigurationer enkla förbiseenden som exponerar resurser direkt. Vanliga exempel inkluderar offentligt tillgängliga lagringsbuckets, alltför tillåtande IAM-roller, okrypterade databaser och säkerhetsgrupper som tillåter all inkommande trafik.

CSPM-verktyg skannar kontinuerligt molnkonton mot säkerhetsriktmärken. De utvärderar tusentals konfigurationskontroller inom IAM, nätverk, lagring, loggning och beräkning. Fynd prioriteras efter risknivå och hjälper säkerhetsteamen att fokusera åtgärdsinsatserna på de farligaste problemen.

Infrastruktur som kod (IaC) för felkonfigurationsdetektion tidigare i livscykeln. Säkerhetslintningsverktyg analyserar Terraform- och CloudFormation-mallar innan driftsättning. När en säkerhetsregel kränks ser utvecklaren fyndet i sin PR-granskning, inte efter att resursen har driftsatts och exponerats.

Grundorsaken till de flesta felkonfigurationer är inte illvilja utan bekvämlighet. En utvecklare öppnar en port 'bara för att testa' och stänger den aldrig. En bucket görs offentlig för att dela en fil och låses aldrig ner igen. Det systemiska försvaret är att automatisera detektion och verkställa säkra standardvärden via policyer snarare än att förlita sig på mänsklig disciplin.

Offentlig exponeringsrisk är den attackyta som skapas när molnresurser som borde vara privata är nåbara från det offentliga internet. Varje offentligt tillgänglig endpoint är en potentiell ingångspunkt för angripare. I molnmiljöer kan resurser oavsiktligt bli offentliga genom en enda felkonfigurerad säkerhetsgruppsregel eller en oavsiktligt tilldelad offentlig IP-adress.

Verktyg för attackythantering (attack surface management) identifierar och katalogiserar kontinuerligt alla internetvända resurser i en molnmiljö. Detta inkluderar lastbalanserare, API-gateways, instanser med offentliga IP-adresser, exponerade databaser och offentliga lagringsbuckets. Många organisationer är förvånade att upptäcka resurser de inte visste var offentliga.

Att minska offentlig exponering kräver en kombination av kontroller. Använd privata undernät för interna tjänster utan direkt internetåtkomst, placera all offentlig trafik bakom en lastbalanserare eller API-gateway som tillhandahåller TLS-terminering och WAF-skydd, blockera direkt offentlig IP-tilldelning för applikationsservrar och verkställ offentliga åtkomstblock på lagringstjänster.

Internetbaserade skannrar indexerar alla offentligt tillgängliga tjänster kontinuerligt. En ny offentlig endpoint kan hittas och undersökas inom minuter från att den skapas. Det tidsfönster mellan oavsiktlig exponering och angriparens upptäckt är mycket kort. Automatiserad detektion och åtgärd för offentlig exponering är avgörande.

Säkra standardvärden innebär att konfigurera molnkonton, tjänster och resurser att vara säkra från det ögonblick de skapas, och kräva ett uttryckligt val för att aktivera mindre säkra konfigurationer snarare än tvärtom. Modern molnsäkerhetspraxis inverterar detta. Börja inlåst och öppna bara det som uttryckligen behövs.

Att implementera säkra standardvärden kräver en säkerhetsbaslinje på kontonivå som tillämpas på varje nytt konto vid skapandet. En typisk baslinje inkluderar. Obligatorisk MFA för alla IAM-användare, CloudTrail aktiverat i alla regioner, offentliga åtkomstblock för S3 aktiverade, standardkryptering för EBS-volymer och RDS-instanser, och Service Control Policies som förhindrar deaktivering av säkerhetsverktyg.

Verkställighet av organisationspolicyer via verktyg som AWS Organizations SCPs, Azure Policy och GCP Organization Policy gör det möjligt för säkerhetsteam att sätta skyddsräcken som inte kan åsidosättas av enskilda kontoadministratörer. Detta säkerställer att även om en utvecklare felkonfigurerar sitt konto, förhindrar kontroller på organisationsnivå de farligaste resultaten.

Säkra standardvärden ersätter inte aktiv säkerhetstestning men minskar dramatiskt skadeverkningarna av misstag. När standardinställningen är säker och standardsvaret är 'nej, du måste uttryckligen tillåta det', blir felkonfigurationer som skapar exponering undantag som kräver förklaring snarare än normen.