Zasady oparte na tożsamości a zasady oparte na zasobie

Uprawnienia w AWS wynikają z zasad dołączonych w dwóch miejscach: do tożsamości (użytkownika, grupy lub roli) albo do zasobu (takiego jak bucket S3 lub klucz KMS). Zrozumienie, który typ ma zastosowanie i jak typy te się łączą, jest niezbędne na egzaminie, ponieważ dostęp między kontami zależy całkowicie od tego rozróżnienia.

Zasada oparta na tożsamości jest dołączona do podmiotu IAM i określa, co ten podmiot może robić. Nie zawiera elementu Principal, ponieważ podmiotem jest ten, do którego zasadę dołączono. Zasady te mogą być zarządzane przez AWS, zarządzane przez klienta lub osadzone; są najczęstszym sposobem przyznawania uprawnień.

Zasada oparta na zasobach jest dołączona bezpośrednio do zasobu i zawiera element Principal, określający, kto może uzyskać dostęp. Przykładami są zasady bucketów S3, zasady kluczy KMS, zasady kolejek SQS i zasady funkcji Lambda. Określają one zarówno podmiot (Principal), jak i działanie (Action) dotyczące konkretnego zasobu.

Ta zasada bucketa S3 przyznaje innemu kontu dostęp do odczytu. Principal określa zaufane konto, co może zrobić wyłącznie zasada oparta na zasobach.

W obrębie jednego konta zasady oparte na tożsamości i zasobach tworzą sumę: żądanie jest dozwolone, jeśli którakolwiek z nich na to zezwala (i żadna nie odmawia). Obiekt S3 może więc być dostępny, jeśli zezwala na to zasada użytkownika albo zasada bucketa. Wystarczy otwarcie dostępu po jednej ze stron.

W przypadku dostępu między kontami reguła jest bardziej rygorystyczna: obie strony muszą zezwalać na dostęp. Podmiot potrzebuje zasady opartej na tożsamości, która zezwala na dane działanie, a także zasada oparta na zasobie na drugim koncie musi przyznać dostęp temu podmiotowi. Brak któregokolwiek elementu powoduje odrzucenie żądania. To rozróżnienie jest często sprawdzane na egzaminie.

Zasady zaufania ról są technicznie rodzajem zasad opartych na zasobach, dlatego przyjmowanie roli między kontami wymaga zarówno zasady zaufania, jak i uprawnienia tożsamości wywołującego sts:AssumeRole. Rozpoznanie zasady zaufania jako zasady opartej na zasobach pomaga ujednolicić sposób rozumienia przyznawania dostępu.

Nie każda usługa obsługuje zasady oparte na zasobach. Najważniejsze z nich to: S3, KMS, SQS, SNS, Lambda, Secrets Manager i ECR. Jeśli usługa nie obsługuje zasad zasobów, dostęp między kontami trzeba przyznać przez przyjęcie roli. Na egzaminie może pojawić się pytanie, czy dane podejście jest w ogóle możliwe dla wybranej usługi.

Zasad opartych na tożsamości należy używać do ogólnych uprawnień typu „ten zespół może wykonywać te działania”. Zasad opartych na zasobach należy używać, gdy trzeba przyznać dostęp konkretnemu zewnętrznemu podmiotowi, włączyć współdzielenie między kontami w obsługującej je usłudze albo ustawić uprawnienia, które pozostają związane z samym zasobem.

Ponieważ dostęp może pochodzić z obu stron, audyt wymaga sprawdzenia obu. IAM Access Analyzer analizuje zasady oparte na zasobach, aby znaleźć zasoby udostępnione zewnętrznie lub publicznie. Po stronie tożsamości pomocne są symulacja zasad i dane o ostatnim użyciu dostępu. Kompletna analiza nigdy nie ogranicza się do jednego typu zasad.

Dostęp w obrębie jednego konta jest sumą (dowolna zasada może zezwolić), natomiast dostęp między kontami wymaga, aby zezwalały na niego obie zasada tożsamości i zasada zasobu. Zasady tożsamości nie zawierają Principal, a zasady zasobów go zawierają. Należy dopasować typ zasady do sytuacji i pamiętać, które usługi w ogóle obsługują zasady oparte na zasobach.

Sprawdź rozumienie typów zasad.

Zasady oparte na tożsamości są dołączane do podmiotów i nie zawierają elementu Principal; zasady oparte na zasobach są dołączane do zasobów i określają Principal. Dostęp w obrębie jednego konta jest sumą obu typów, natomiast dostęp między kontami wymaga zgody obu stron. Tylko niektóre usługi (S3, KMS, SQS, SNS, Lambda, Secrets Manager, ECR) obsługują zasady zasobów; w przeciwnym razie należy użyć przyjęcia roli.