External ID og den forvirrede stedfortræder

Når du lader en tredjepart antage en rolle på din konto, kan der opstå en sikkerhedsrisiko kaldet problemet med den forvirrede stedfortræder. Det eksterne ID er den enkle, men afgørende kontrol, der forhindrer dette. Mønstret optræder på eksamen, når en SaaS-leverandør skal have adgang til din AWS-konto.

En forvirret stedfortræder er en betroet enhed (stedfortræderen), der narres til at bruge sin myndighed på vegne af en angriber. I AWS har en tredjepartstjeneste tilladelse til at antage roller på mange kundekonti. En angriber kan narre tjenesten til at antage din rolle, hvis intet knytter anmodningen til den legitime kunderelation.

Forestil dig en overvågningsbaseret SaaS-tjeneste, der antager en rolle på hver kundekonto. SaaS-tjenesten bruger den samme AWS-identitet for alle. Hvis en angriber, der også er kunde, gætter din rolle-ARN, kan vedkommende måske overtale SaaS-tjenesten til at antage din rolle, fordi SaaS-tjenesten er den betroede principal. Konto-ID'et alene er ikke nok til at forhindre dette.

Det eksterne ID er en unik, hemmelig værdi, som leverandøren tildeler jeres relation. Du indsætter det som en betingelse i rollens tillidspolitik, og leverandøren skal angive nøjagtig den samme værdi ved kaldet til AssumeRole. Da angriberen ikke kender dit eksterne ID, kan vedkommende ikke narre leverandøren til at antage din rolle.

Denne tillidspolitik kræver det tilsvarende eksterne ID. AssumeRole lykkes kun, når leverandøren sender den identiske værdi, hvilket besejrer angrebet med den forvirrede stedfortræder.

Det afgørende er, at leverandøren genererer og kontrollerer det eksterne ID – ikke kunden. Det forhindrer kunder i at samarbejde om at genbruge den samme værdi. AWS' vejledning er tydelig: Som tredjepart skal du tildele hver kunde et unikt eksternt ID og kræve det ved hver antagelse.

Det eksterne ID er ikke beregnet til at være hemmeligt som en adgangskode; det kan fremgå af opsætningsvejledninger. Dets sikkerhedsværdi kommer af, at det er unikt for hver kunde og kontrolleres af leverandøren, så en angriber ikke kan få stedfortræderen til at bruge den forkerte kundes værdi. Betragt det som et token mod identitetsefterligning, ikke som en legitimationsoplysning.

Det eksterne ID styrer hvem der kan antage rollen, men du skal stadig afgrænse hvad rollen kan gøre med stramme tilladelsespolitikker. Selv en korrekt godkendt leverandør bør kun få de minimale nødvendige tilladelser. Kombiner eksternt ID, en specifik principal og mindst mulige tilladelser for sikker adgang for tredjeparter.

Mønstret med den forvirrede stedfortræder gælder også AWS-tjenester, der handler på dine vegne. Tillid mellem tjenester bruger ofte betingelsesnøgler som aws:SourceArn og aws:SourceAccount i ressourcepolitikker for at sikre, at den kaldende tjeneste handler for din ressource – den samme defensive idé i en anden indpakning.

Når et spørgsmål beskriver en tredjepart eller SaaS-tjeneste, der antager en rolle på tværs af konti, omfatter det sikre svar næsten altid et eksternt ID i tillidspolitikken. Hvis scenariet handler om kommunikation mellem tjenester, skal du i stedet se efter betingelser med aws:SourceArn/aws:SourceAccount. Når du genkender signalet, finder du direkte frem til den rigtige kontrol.

Problemet med den forvirrede stedfortræder gør det muligt for en angriber at narre en betroet tredjepart til at misbruge sin adgang. Det eksterne ID, som er unikt for hver kunde og kontrolleres af leverandøren, forhindrer dette ved at kræve en tilsvarende værdi ved AssumeRole. For AWS-tjenester skal du bruge aws:SourceArn og aws:SourceAccount. Kombiner altid disse med mindst mulige tilladelser.

Problemet med den forvirrede stedfortræder opstår, når en betroet tredjepart narres til at misbruge sin adgang på tværs af konti. Det eksterne ID, som er unikt for hver kunde og kontrolleres af leverandøren, forhindrer dette via en betingelse i tillidspolitikken for sts:ExternalId. Til tillid mellem AWS-tjenester skal du bruge aws:SourceArn og aws:SourceAccount, altid sammen med mindst mulige tilladelser.