Oppdage bruk av root-kontoen

Root-brukeren er kontoeieridentiteten som opprettes når en AWS-konto åpnes, og den har ubegrenset tilgang til alle handlinger og ressurser. Den kan ikke begrenses av IAM-policyer eller SCP-er. På grunn av denne omfattende tilgangen er all bruk av root-brukeren en sikkerhetshendelse med høy signalverdi som det er verdt å varsle om umiddelbart.

AWS anbefaler å bruke root-brukeren bare til de få oppgavene som krever det, og deretter aldri bruke den igjen. De bør aktivere MFA for root, fjerne tilgangsnøklene fullstendig og opprette IAM-identiteter eller Identity Center-brukere for daglig arbeid. Etter at kontoen er låst ned, bør legitim root-aktivitet være sjelden og planlagt.

Fordi root nesten aldri bør logge på, er en uventet root-pålogging en sterk indikasjon på kompromittering eller brudd på retningslinjer. Deteksjon av dette er en av de standardiserte overvåkingskontrollene i CIS Benchmark og et vanlig eksamensscenario: Det forventede svaret er et CloudTrail-basert metrikkfilter og en alarm, ikke en manuell gjennomgang.

Deteksjonen bruker tre deler De allerede kjenner: CloudTrail registrerer påloggings- og API-hendelser, CloudWatch Logs mottar disse hendelsene når CloudTrail er konfigurert til å levere dem til en logggruppe, og et metrikkfilter med alarm gjør root-hendelser om til en umiddelbar varsling. Alle delene må være på plass for at kjeden skal fungere.

I en CloudTrail-hendelse er feltet userIdentity.type lik Root når root-brukeren utfører handlingen. Et metrikkfilter kan samsvare med dette feltet. For å unngå støy fra rutinemessige automatiserte hendelser utelukker filtre ofte også AWS-tjenestehendelser, slik at bare reelle menneskelige root-handlinger utløser varslingen.

Som standard skriver CloudTrail til S3, ikke til CloudWatch Logs. For å utløse alarmer i tilnærmet sanntid må De konfigurere sporet til også å levere hendelser til en CloudWatch Logs-gruppe. Dette krever en IAM-rolle som lar CloudTrail skrive til logggruppen. Uten dette leveringstrinnet har metrikkfilteret ingenting å samsvare med.

Opprett et metrikkfilter på CloudTrail-logggruppen med et mønster som samsvarer med userIdentity.type = Root. Knytt hvert treff til en metrikk, for eksempel RootAccountUsageCount, med verdien én. Nå øker hver root-handling en metrikk De kan overvåke, slik at et skjult JSON-felt blir omgjort til et målbart signal.

Knytt en CloudWatch-alarm til metrikken med en terskel på én over én kort periode, slik at den utløses ved den aller første root-hendelsen. Pek alarmen mot et SNS-emne som sikkerhetsteamet abonnerer på. Resultatet er et nesten umiddelbart varsel i det øyeblikket root brukes.

I en organisasjon har hver medlemskonto sin egen root-bruker. Et organisasjonsspor kan sentralisere CloudTrail på tvers av alle kontoer, og De kan bygge deteksjonen én gang mot den sentrale logggruppen. Dette sikrer at ingen root-aktivitet i en medlemskonto forblir uovervåket, noe som er et viktig krav til styring.

Når alarmen utløses, bør De behandle det som en hendelse inntil det motsatte er bevist. Bekreft om aktiviteten var en planlagt og autorisert oppgave. Hvis ikke, må De sikre kontoen: Bytt root-passordet, kontroller at MFA fortsatt er aktivert, gjennomgå nylige root-handlinger i CloudTrail og se etter nye IAM-identiteter eller nøkler som en angriper kan ha opprettet.

Deteksjon av root-bruk knytter sammen CloudTrail, CloudWatch Logs, metrikkfiltre, alarmer og SNS i én realistisk kontroll. Forvent spørsmål der feil svar foreslår manuell gjennomgang, IAM-policyer for root eller SCP-er. Det riktige svaret er alltid automatisert deteksjon og umiddelbar varsling, fordi root ikke kan begrenses, bare overvåkes.

Root-brukeren er ubegrenset og bør låses bort med MFA og uten tilgangsnøkler. All bruk er en hendelse med høy signalverdi. Detekter den ved å levere CloudTrail til CloudWatch Logs, legge til et metrikkfilter for userIdentity.type = Root og utløse en CloudWatch-alarm mot et SNS-emne. I organisasjoner sentraliserer et organisasjonsspor denne deteksjonen på tvers av alle kontoer.