External ID ja hämmentynyt sijainen

Kun annat kolmannen osapuolen olettaa roolin tililläsi, voi syntyä tietoturvariski nimeltä hämmentyneen sijaisen ongelma. Ulkoinen tunniste on yksinkertainen mutta tärkeä hallintakeino, joka estää tämän. Tämä toimintamalli tulee kokeessa vastaan aina, kun SaaS-toimittaja tarvitsee pääsyn AWS-tilillesi.

Hämmentynyt sijainen on luotettu taho (sijainen), joka huijataan käyttämään valtuuksiaan hyökkääjän puolesta. AWS:ssä kolmannen osapuolen palvelulla voi olla lupa olettaa rooleja monilla asiakastileillä. Hyökkääjä voisi huijata sen olettamaan sinun roolisi, jos pyyntöä ei millään tavalla sidota aitoon asiakassuhteeseen.

Kuvitellaan valvontaan käytettävä SaaS-palvelu, joka olettaa roolin jokaisella asiakastilillä. SaaS-palvelu käyttää samaa AWS-identiteettiä kaikkien asiakkaiden puolesta. Jos hyökkääjä, joka on myös asiakas, arvaa roolisi ARN:n, hän voi saada SaaS-palvelun olettamaan sinun roolisi, koska SaaS-palvelu on luotettu päämies. Pelkkä tilitunnus ei riitä estämään tätä.

Ulkoinen tunniste on toimittajan asiakassuhteellesi määrittämä yksilöllinen ja salainen arvo. Lisäät sen roolin luottamuskäytäntöön ehtona, ja toimittajan on toimitettava täsmälleen sama arvo AssumeRole-kutsun yhteydessä. Koska hyökkääjä ei tiedä ulkoista tunnistettasi, hän ei voi huijata toimittajaa olettamaan rooliasi.

Tämä luottamuskäytäntö edellyttää vastaavaa ulkoista tunnistetta. AssumeRole onnistuu vain, kun toimittaja välittää saman arvon, mikä estää hämmentyneen sijaisen hyökkäyksen.

Ratkaisevaa on, että toimittaja, ei asiakas, luo ulkoisen tunnisteen ja hallitsee sitä. Näin asiakkaat eivät voi sopia saman arvon uudelleenkäytöstä. AWS:n ohje on yksiselitteinen: kolmannen osapuolen on määritettävä jokaiselle asiakkaalle yksilöllinen ulkoinen tunniste ja edellytettävä sitä jokaisessa oletuksessa.

Ulkoista tunnistetta ei ole tarkoitettu salaiseksi salasanan tavoin, vaan se voi näkyä käyttöönottovaiheen ohjeissa. Sen tietoturva-arvo perustuu siihen, että se on asiakaskohtainen ja toimittajan hallinnassa, joten hyökkääjä ei voi saada sijaista käyttämään väärän asiakkaan arvoa. Käsittele sitä toisena osapuolena esiintymisen estävänä tunnisteena, ei tunnistetietona.

Ulkoinen tunniste hallitsee sitä, kuka voi olettaa roolin, mutta sinun on silti rajattava mitä rooli voi tehdä tarkoin määritetyillä käyttöoikeuskäytännöillä. Oikein valtuutetullekin toimittajalle tulee antaa vain tarvittavat vähimmäisoikeudet. Yhdistä turvallisessa kolmannen osapuolen pääsyssä ulkoinen tunniste, tietty päämies ja vähimpien käyttöoikeuksien periaate.

Hämmentyneen sijaisen toimintamalli koskee myös AWS-palveluita, jotka toimivat puolestasi. Palveluiden välinen luottamus käyttää resurssikäytännöissä usein ehtoja, kuten aws:SourceArn ja aws:SourceAccount, varmistaakseen, että kutsuva palvelu toimii sinun resurssisi puolesta. Kyseessä on sama puolustava ajatus eri muodossa.

Aina kun kysymyksessä kuvataan kolmannen osapuolen tai SaaS-palvelun olettavan roolin tilien välillä, turvallinen vastaus sisältää lähes aina ulkoisen tunnisteen luottamuskäytännössä. Jos tilanteessa on kyse palveluiden välisestä toiminnasta, etsi sen sijaan ehtoja aws:SourceArn/aws:SourceAccount. Tunnusmerkin tunnistaminen ohjaa suoraan oikeaan hallintakeinoon.

Hämmentyneen sijaisen ongelma antaa hyökkääjälle mahdollisuuden huijata luotettua kolmatta osapuolta käyttämään pääsyään väärin. Ulkoinen tunniste, joka on asiakaskohtainen ja toimittajan hallinnassa, estää tämän edellyttämällä vastaavaa arvoa AssumeRole-kutsussa. AWS-palveluiden kohdalla käytä tunnisteita aws:SourceArn ja aws:SourceAccount. Yhdistä nämä aina vähimpien käyttöoikeuksien periaatteeseen.

Hämmentyneen sijaisen ongelma syntyy, kun luotettu kolmas osapuoli huijataan käyttämään tilien välistä pääsyään väärin. Ulkoinen tunniste, joka on asiakaskohtainen ja toimittajan hallinnassa, estää tämän luottamuskäytännön sts:ExternalId-ehdolla. AWS-palveluiden välisessä luottamuksessa käytä tunnisteita aws:SourceArn ja aws:SourceAccount sekä aina vähimpien käyttöoikeuksien periaatetta.