När en S3-bucket plötsligt blir publik eller en säkerhetsgrupp öppnas för hela internet behöver du kunna se vad som ändrades och när. AWS Config hjälper dig att följa resursers konfiguration och hitta avvikelser, men vad tjänsten faktiskt ser beror på vilka resurstyper du spelar in.
Få koll på ändringar utan att blanda ihop övervakning med förebyggande skydd
- Configuration recorder samlar in konfigurationsinformation för valda AWS-resurser i en region.
- Config rules bedömer om inspelade resurser följer dina krav.
- Regler stoppar inte automatiskt en otillåten ändring efter att den har gjorts.
- Kostnaden påverkas av inspelade konfigurationsobjekt och regelutvärderingar.
Se AWS Config som en ändringslogg med kontrollregler
En ändring i molnet kan lämna få synliga spår i vardagen, men AWS Config sparar konfigurationshistorik för de resurser som ingår i inspelningen. Varje sparat tillstånd kallas ett configuration item, och historiken kan hjälpa dig att reda ut vad som ändrats när en miljö plötsligt beter sig annorlunda.
Två delar styr upplägget. En configuration recorder samlar in resursdata, medan en delivery channel levererar historik och ögonblicksbilder till bland annat en S3-bucket. Regler bedömer sedan om den registrerade konfigurationen uppfyller dina krav. Enligt AWS Configs begreppsöversikt kan utvärderingen ske vid en ändring, enligt ett schema eller på båda sätten.
Här börjar ett vanligt misstag: en resurs som inte spelas in kan inte ge den historik eller regelbedömning du förväntar dig. Jag anser att det är bättre att först välja vilka resurser som måste gå att granska och sedan lägga till regler, än att slå på allt utan att förstå följderna.
Välj inspelningsomfång innan resursantalet växer
En ny miljö kan verka liten, tills autoskalning eller tillfälliga jobb börjar skapa och ta bort resurser. Eftersom AWS Config debiteras utifrån bland annat registrerade konfigurationsobjekt och aktiva regelutvärderingar kan sådan aktivitet öka förbrukningen. AWS beskriver även att den första uppstarten kan ge fler utvärderingar än senare perioder, eftersom befintliga resurser då gås igenom.
Du kan spela in alla resurstyper som stöds, välja särskilda typer eller spela in brett med undantag. Det senare kan vara praktiskt när nya resurstyper ska följas automatiskt, men kräver att undantagen granskas så att en viktig resurs inte hamnar utanför. AWS tar också upp tillfälliga arbetslaster som Spot-instanser och EMR-jobb som exempel på resurser som kan skapa mer inspelningsaktivitet. Se AWS Configs guide för val av resurser innan du bestämmer strategi.
Beslutsregel: om du behöver en komplett historik för alla stödda resursklasser väljer du bred inspelning och följer kostnaden; om en konto- eller jobbtyp skapar kortlivade resurser i stor skala, bedömer du om vissa typer kan undantas utan att förlora nödvändig spårbarhet. Priser och utvärderingsmodeller varierar, så använd AWS Configs prissida för uppskattning i aktuell region.
En regel flaggar avvikelsen men säkrar inte resursen
Om en resurs bryter mot en Config-regel kan statusen bli NON_COMPLIANT. Det betyder att konfigurationen avviker från kontrollen, inte att AWS Config automatiskt har stoppat eller återställt ändringen. Även regler i proaktivt läge bedömer egenskaper före driftsättning, men de blockerar inte i sig att resursen skapas.
Den skillnaden spelar roll när kravet är förebyggande. För att hindra otillåtna åtgärder behöver du komplettera övervakningen med kontroller som faktiskt begränsar provisionering eller behörigheter, exempelvis IAM-policyer eller Service Control Policies där de passar. Automatisk åtgärd kan också konfigureras för vissa regelutfall, men bör testas noga: en automatisk ändring av en produktionsresurs kan få följder som själva avvikelsen inte hade.
Om kravet bara är att snabbt upptäcka en publik säkerhetsgrupp kan en detektiv regel och larmflöde vara lämpligt. Om kravet är att ingen alls ska kunna skapa den konfigurationen behöver du ett separat förebyggande skydd. AWS skiljer mellan dessa utvärderingslägen i dokumentationen om AWS Config-regler.
Felsök genom att skilja mellan saknad data och regelbrott
En tom historik och en röd efterlevnadsstatus är två olika problem. Den ena pekar ofta på inspelning eller region, den andra på en regel som har utvärderat en registrerad resurs. Tabellen hjälper dig att börja på rätt ställe.
| Situation | Trolig orsak eller följd | Nästa steg |
|---|---|---|
| Resursen syns inte i inventeringen | Resurstypen spelas inte in, eller så tittar du i fel region. | Kontrollera recorder-inställningar och region för resursen. |
| Resursen finns, men regeln visar NON_COMPLIANT | En registrerad egenskap uppfyller inte regelns krav. | Öppna resursens konfigurationshistorik och jämför egenskapen med regelns parametrar. |
| En ändring syns inte direkt | Inspelning eller utvärdering kan ännu inte ha slutförts. | Kontrollera recorder-status och regelns utvärderingsläge innan du ändrar regeln. |
| Flera konton saknas i översikten | Data från kontona har inte samlats in i en aggregator eller har inte auktoriserats. | Kontrollera aggregatorns källkonton och regioner samt nödvändiga behörigheter. |
För flera konton och regioner samlar en aggregator ihop inventerings- och efterlevnadsdata till en central, skrivskyddad vy. Den distribuerar inte regler till källkontona, så använd separata verktyg eller organisationsfunktioner för själva distributionen.
Bygg en rutin som fångar avvikelser utan att skapa brus
När grundinställningen fungerar blir nästa utmaning att hålla signalerna användbara. Börja med regler som uttrycker ett tydligt krav, till exempel att en viss typ av resurs ska ha en förväntad egenskap, och bestäm vem som hanterar ett avvikande resultat. En lång lista regler utan ansvarig mottagare blir snabbt en dashboard som ingen agerar på.
För organisationer med flera konton kan conformance packs paketera regler och eventuella åtgärder för gemensam distribution. En aggregator ger överblick över status, medan ett conformance pack hjälper till att hålla samma kontrolluppsättning på flera ställen. De löser alltså olika delar av arbetet.
En hållbar start är att dokumentera vilka resurstypers historik som behövs, testa regler i en icke-produktionsmiljö och granska AWS-kostnader efter att inspelningen kommit igång. Då blir AWS Config en användbar källa till förändringsspår och efterlevnadsstatus, i stället för ännu en tjänst som samlar data utan att någon vet vad den ska göra med den.