External ID en de confused deputy

Wanneer je een derde partij toestaat een rol in je account aan te nemen, kan een beveiligingsrisico ontstaan dat het probleem van de verwarde tussenpersoon wordt genoemd. De externe ID is de eenvoudige maar essentiële beheersmaatregel die dit voorkomt. Dit patroon komt op het examen voor wanneer een SaaS-leverancier toegang nodig heeft tot je AWS-account.

Een verwarde tussenpersoon is een vertrouwde entiteit (de tussenpersoon) die ertoe wordt misleid haar bevoegdheden namens een aanvaller te gebruiken. In AWS mag een service van een derde partij rollen in veel klantaccounts aannemen. Een aanvaller kan die service ertoe verleiden jouw rol aan te nemen als niets de aanvraag koppelt aan de legitieme klantrelatie.

Stel je een SaaS voor monitoring voor die in elk klantaccount een rol aanneemt. De SaaS gebruikt voor iedereen één AWS-identiteit. Als een aanvaller die ook klant is de ARN van jouw rol raadt, kan die de SaaS ertoe overhalen jouw rol aan te nemen, omdat de SaaS de vertrouwde principal is. Alleen de account-ID is niet voldoende om dit te voorkomen.

De externe ID is een unieke, geheime waarde die de leverancier aan jouw relatie toewijst. Je neemt deze als voorwaarde op in het vertrouwensbeleid van je rol en de leverancier moet exact dezelfde waarde meesturen wanneer deze AssumeRole aanroept. Omdat de aanvaller jouw externe ID niet kent, kan die de leverancier niet misleiden zodat deze jouw rol aanneemt.

Dit vertrouwensbeleid vereist de overeenkomende externe ID. AssumeRole slaagt alleen wanneer de leverancier exact dezelfde waarde doorgeeft, waardoor de aanval met een verwarde tussenpersoon wordt verijdeld.

Belangrijk is dat de leverancier de externe ID genereert en beheert, niet de klant. Zo wordt voorkomen dat klanten samenspannen om dezelfde waarde opnieuw te gebruiken. De richtlijnen van AWS zijn duidelijk: als derde partij moet je elke klant een unieke externe ID toewijzen en deze bij elke aanname verplicht stellen.

De externe ID is niet bedoeld als geheim zoals een wachtwoord; deze mag in installatie-instructies staan. De beveiligingswaarde komt voort uit het feit dat de ID uniek is per klant en door de leverancier wordt beheerd. Daardoor kan een aanvaller de tussenpersoon niet de waarde van de verkeerde klant laten gebruiken. Beschouw de ID als een token tegen imitatie, niet als inloggegeven.

De externe ID bepaalt wie de rol mag aannemen, maar je moet nog steeds beperken wat de rol mag doen met strikt machtigingsbeleid. Zelfs een correct geautoriseerde leverancier mag alleen de minimaal benodigde machtigingen krijgen. Combineer een externe ID, een specifieke principal en minimale machtigingen voor veilige toegang door derden.

Het patroon van de verwarde tussenpersoon is ook van toepassing op AWS-services die namens jou handelen. Vertrouwen tussen services gebruikt in resourcebeleid vaak conditiesleutels zoals aws:SourceArn en aws:SourceAccount om te controleren of de aanroepende service handelt voor jouw resource. Het is hetzelfde defensieve idee in een andere vorm.

Wanneer een vraag beschrijft dat een derde partij of SaaS in verschillende accounts een rol aanneemt, bevat het veilige antwoord vrijwel altijd een externe ID in het vertrouwensbeleid. Gaat het scenario over communicatie tussen services, let dan in plaats daarvan op de voorwaarden aws:SourceArn/aws:SourceAccount. Als je de aanwijzing herkent, kom je direct bij de juiste beheersmaatregel uit.

Door het probleem van de verwarde tussenpersoon kan een aanvaller een vertrouwde derde partij ertoe verleiden haar toegang verkeerd te gebruiken. De externe ID, die uniek is per klant en door de leverancier wordt beheerd, voorkomt dit door bij AssumeRole een overeenkomende waarde te vereisen. Gebruik voor AWS-services aws:SourceArn en aws:SourceAccount. Combineer deze altijd met minimale machtigingen.

Het probleem van de verwarde tussenpersoon ontstaat wanneer een vertrouwde derde partij wordt misleid om haar toegang tussen accounts verkeerd te gebruiken. De externe ID, die uniek is per klant en door de leverancier wordt beheerd, voorkomt dit via een voorwaarde in het vertrouwensbeleid op basis van sts:ExternalId. Gebruik voor vertrouwen tussen AWS-services aws:SourceArn en aws:SourceAccount, altijd in combinatie met minimale machtigingen.