Ekstern ID og forvirret stedfortreder

Når du lar en tredjepart anta en rolle i kontoen din, kan det oppstå en sikkerhetsrisiko kalt problemet med den forvirrede stedfortrederen. Ekstern ID er den enkle, men avgjørende kontrollen som forhindrer dette. Dette mønsteret dukker opp på eksamen når en SaaS-leverandør trenger tilgang til AWS-kontoen din.

En forvirret stedfortreder er en betrodd enhet (stedfortrederen) som lures til å bruke myndigheten sin på vegne av en angriper. I AWS har en tredjepartstjeneste tillatelse til å anta roller i mange kundekontoer. En angriper kan lure den til å anta din rolle hvis ingenting knytter forespørselen til det legitime kundeforholdet.

Se for deg en overvåkingsbasert SaaS-tjeneste som antar en rolle i hver kundekonto. SaaS-tjenesten bruker én AWS-identitet for alle. Hvis en angriper som også er kunde, gjetter ARN-en til rollen din, kan vedkommende overtale SaaS-tjenesten til å anta din rolle, siden SaaS-tjenesten er den betrodde principalen. Konto-ID alene er ikke nok til å forhindre dette.

Den eksterne ID-en er en unik, hemmelig verdi som leverandøren tilordner kundeforholdet deres. Du legger den inn som en betingelse i rollens tillitspolicy, og leverandøren må oppgi nøyaktig samme verdi når den kaller AssumeRole. Siden angriperen ikke kjenner den eksterne ID-en, kan vedkommende ikke lure leverandøren til å anta rollen din.

Denne tillitspolicyen krever den samsvarende eksterne ID-en. AssumeRole lykkes bare når leverandøren sender den identiske verdien, noe som avverger angrepet med en forvirret stedfortreder.

Det avgjørende er at leverandøren, ikke kunden, genererer og kontrollerer den eksterne ID-en. Dette hindrer kunder i å samarbeide om å gjenbruke samme verdi. AWS-dokumentasjonen er tydelig: Som tredjepart må du tilordne hver kunde en unik ekstern ID og kreve den ved hver antakelse.

Den eksterne ID-en er ikke ment å være hemmelig på samme måte som et passord; den kan stå i instruksjoner for oppsett. Sikkerhetsverdien ligger i at den er unik per kunde og kontrolleres av leverandøren, slik at en angriper ikke kan få stedfortrederen til å bruke verdien til feil kunde. Se på den som et token mot etterligning, ikke som en legitimasjonsopplysning.

Den eksterne ID-en styrer hvem som kan anta rollen, men du må fortsatt avgrense hva rollen kan gjøre med stramme tillatelsespolicyer. Selv en korrekt autorisert leverandør bør bare få de minste nødvendige tillatelsene. Kombiner ekstern ID, en spesifikk principal og tillatelser basert på minste privilegium for sikker tredjepartstilgang.

Mønsteret med en forvirret stedfortreder gjelder også AWS-tjenester som handler på dine vegne. Tillit mellom tjenester bruker ofte betingelsesnøkler som aws:SourceArn og aws:SourceAccount i ressurspolicyer for å sikre at tjenesten som kaller, handler på vegne av din ressurs. Det er samme defensive idé i en annen innpakning.

Når en oppgave beskriver at en tredjepart eller SaaS-tjeneste antar en rolle på tvers av kontoer, innebærer det sikre svaret nesten alltid en ekstern ID i tillitspolicyen. Hvis scenarioet gjelder kommunikasjon mellom tjenester, bør du i stedet se etter betingelser med aws:SourceArn/aws:SourceAccount. Når du gjenkjenner signalet, finner du raskt riktig kontroll.

Problemet med den forvirrede stedfortrederen gjør at en angriper kan lure en betrodd tredjepart til å misbruke tilgangen sin. Den eksterne ID-en, som er unik per kunde og kontrolleres av leverandøren, forhindrer dette ved å kreve en samsvarende verdi ved AssumeRole. For AWS-tjenester bruker du aws:SourceArn og aws:SourceAccount. Kombiner alltid disse med tillatelser basert på minste privilegium.

Problemet med den forvirrede stedfortrederen oppstår når en betrodd tredjepart lures til å misbruke tilgangen sin på tvers av kontoer. Den eksterne ID-en, som er unik per kunde og kontrolleres av leverandøren, forhindrer dette gjennom en tillitspolicybetingelse på sts:ExternalId. For tillit mellom AWS-tjenester bruker du aws:SourceArn og aws:SourceAccount, alltid med minste privilegium.