AWS-rootlogins blijven monitoren

Veel AWS-beveiligingscontroles zijn gebouwd rond de historische aanname dat ConsoleLogin-events van root in us-east-1 verschijnen. Een regiofilter in EventBridge, een CloudWatch metric filter, een SIEM-route of een geplande query kan die aanname ongemerkt vasthouden. Het gevolg is geen mislukte authenticatie, maar een gat in de monitoring van de meest bevoorrechte identiteit binnen het account.

CloudTrail registreert geslaagde en mislukte consolelogins met het type identiteit, de regio, broncontext en authenticatiegegevens. Alertlogica moet het event uit alle drie de rootloginregio's verzamelen en daarna één vaste opvolging starten. Afzonderlijke regionale regels zijn bruikbaar, zolang zij in hetzelfde incidentproces uitkomen en de verwerkingsregio niets verandert aan urgentie of eigenaarschap.

Omgevingen met meerdere accounts vragen om een controle op organisatieniveau. Een volledige trail of event data store kan de managementevents al verzamelen, terwijl lokale regels of downstream subscriptions nog steeds op één regio filteren. Beoordeel daarom de hele route van eventgeneratie naar notificatie, retentie en onderzoek voordat centrale logging als volledig wordt beschouwd.

De rootgebruiker van een AWS-account heeft bevoegdheden die gewone IAM-rollen niet horen te dragen. Dagelijks beheer gebruikt benoemde of federatieve toegang met rechten die bij de taak passen. Rootcredentials blijven gereserveerd voor de beperkte accounttaken waarvoor zij noodzakelijk zijn, met sterke multi-factorauthenticatie en een vastgelegde eigenaar voor toegang en herstel.

Monitoring moet onderscheid maken tussen de rootlogin en de acties erna. Een ConsoleLogin-alert bewijst dat de rootidentiteit de console heeft geopend. CloudTrail-managementevents laten zien wat daarna veranderde. Een onderzoek heeft dus zowel het loginevent als de daaropvolgende accountactiviteit nodig, gecorreleerd op tijd en account in plaats van op de aanname dat ieder relevant record in dezelfde regio staat.

AWS Organizations kan voor ondersteunde beheertaken in memberaccounts ook tijdelijke roottoegang gebruiken. Deze sessies leveren ander bewijs op, waaronder AssumeRoot-activiteit, en horen niet in dezelfde regel als ConsoleLogin te verdwijnen. Het beheermodel benoemt ieder bevoorrecht pad, waarom het bestaat en welk bewijs bij gebruik wordt verwacht.

Begin bij de huidige CloudTrail-architectuur. Bevestig welke organisation trails, accounttrails en event data stores managementevents uit us-east-1, us-east-2 en us-west-2 verzamelen. Controleer daarna de regiofilters in EventBridge, CloudWatch, log subscriptions, beveiligingstooling en een externe SIEM. Een brede trail kan nog steeds een smalle alert voeden.

Werk de detectie bij en test haar met een gecontroleerde, geautoriseerde rootlogin. De test moet aantonen dat iedere mogelijke verwerkingsregio dezelfde alertbestemming bereikt, dat account en regio zichtbaar zijn en dat de procedure uitlegt hoe een operator controleert of de activiteit verwacht was. Verzwak de regel niet omdat regionale routering meer dan één bronlocatie oplevert.

Leg de wijziging vast in de AWS-accountbasis en herhaal de controle wanneer de identiteitsarchitectuur, organisation trails of logbestemmingen veranderen. Rootmonitoring is een kleine controle met grote gevolgen. Zij heeft een verantwoordelijke eigenaar, een bekende testmethode en bewijs nodig dat niet bij één engineer blijft hangen.