Czym jest AWS IAM i jak działa zarządzanie dostępem w AWS?

Czym jest AWS IAM?

AWS Identity and Access Management (IAM) to usługa, która — jak opisuje ją sam Amazon w dokumentacji IAM — „pomaga bezpiecznie kontrolować dostęp do zasobów AWS". Przy każdym żądaniu wysłanym do chmury IAM odpowiada na dwa pytania: kto to robi (uwierzytelnianie) i czy wolno mu to zrobić (autoryzacja).

Warto zaznaczyć, czym IAM nie jest: to nie model AI ani firewall, lecz fundamentalna warstwa zarządzania tożsamościami i uprawnieniami, wbudowana w każde konto AWS i oceniana przy każdym wywołaniu API, konsoli czy CLI. Usługa jest globalna i bezpłatna — płacisz dopiero za zasoby, do których daje dostęp.

Model IAM jest domyślnie restrykcyjny: każde żądanie jest odrzucane, dopóki nie zezwoli na nie wyraźna reguła (default deny). To odwrotność podejścia „domyślnie otwarte" — i źródło zarówno bezpieczeństwa, jak i złożoności IAM.

Jak to działa?

Sercem IAM jest logika oceny polityk (policy evaluation logic). Principal to dowolna tożsamość wykonująca akcję w AWS — użytkownik, rola, aplikacja lub usługa. Gdy principal wysyła żądanie, AWS najpierw go uwierzytelnia, potem buduje kontekst żądania (żądaną akcję, zasób, principala, tagi, adres IP, czas, status MFA i inne dane — to z nich biorą się warunki Condition), a na końcu przepuszcza to przez obowiązujące polityki, by wydać werdykt: allow albo deny.

Reguły łączenia polityk są precyzyjne i warto je zapamiętać, bo to one najczęściej zaskakują początkujących:

• Domyślnie wszystko jest zabronione. Bez wyraźnego allow żądanie zostaje odrzucone.
• Explicit deny zawsze wygrywa. Jeśli którakolwiek polityka zawiera wyraźne deny, przekreśla ono każde allow — bez wyjątków.
• Polityki tożsamościowe i zasobowe sumują się (union). Jeśli akcję dopuszcza polityka użytkownika, polityka zasobu albo obie — akcja jest dozwolona.
• Permission boundaries i polityki organizacji zawężają (intersection). Nie nadają uprawnień — mogą je tylko ograniczyć; akcja musi być dozwolona jednocześnie przez politykę tożsamościową i przez granicę/SCP^?SCP: Service Control Policy — polityka AWS Organizations ustalająca górny limit uprawnień dla całych kont w organizacji.

Kluczowe jest rozróżnienie: polityki, które nadają dostęp, dodają się do siebie; polityki, które go ograniczają (granice, SCP, RCP, sesje), działają jak kolejne bramki. Wystarczy jedno deny, by żądanie przepadło. W skrócie efektywne uprawnienia to zbiór:

Ten sam mechanizm można prześledzić krok po kroku:

Z jakich elementów się składa?

IAM opiera się na kilku typach obiektów. Po stronie tożsamości są to:

• Użytkownicy (users) — zwykle przeznaczeni dla konkretnych osób. Aplikacje mogą korzystać z użytkowników IAM i długoterminowych kluczy, ale AWS zaleca zamiast tego role i poświadczenia tymczasowe.
• Grupy (groups) — zbiory użytkowników, do których przypina się polityki zbiorczo.
• Role — tożsamości bez stałych poświadczeń, przeznaczone do „przyjmowania" (assume) przez dowolny podmiot, który ich potrzebuje.
• Root user — właściciel konta z pełnym dostępem; AWS odradza używanie go do codziennej pracy i rezerwuje go wyłącznie do garstki zadań administracyjnych na poziomie konta.

Role i AWS STS

Rola to serce współczesnego IAM: nie ma stałych poświadczeń, a po jej przyjęciu principal dostaje tymczasowe poświadczenia z STS^?STS: AWS Security Token Service — usługa AWS wydająca krótkotrwałe, automatycznie wygasające poświadczenia dostępu — krótkotrwałe, generowane dynamicznie, ważne od kilku minut do kilku godzin. Po wygaśnięciu przestają działać i nie trzeba ich ręcznie odwoływać, jak podaje dokumentacja poświadczeń tymczasowych.

Każda rola łączy dwie odrębne polityki:

Polityki

Po stronie uprawnień są polityki. AWS wyróżnia aż dziewięć typów polityk, z których w praktyce najważniejsze to:

• Polityki tożsamościowe (identity-based) — dokumenty JSON przypinane do użytkowników, grup i ról; określają, co dana tożsamość może robić.
• Polityki zasobowe (resource-based) — przypinane bezpośrednio do zasobu; wskazują, który podmiot ma dostęp. Wbrew częstemu przekonaniu nie dotyczą tylko bucketów S3 — mają je też m.in. klucze KMS, kolejki SQS, tematy SNS oraz role (jako trust policy).
• Permission boundaries — maksymalny pułap uprawnień, jaki polityki tożsamościowe mogą przyznać danej encji.
• Service Control Policies (SCP) i Resource Control Policies (RCP) — polityki AWS Organizations, ustalające górny limit uprawnień dla całych kont w organizacji.
• Polityki sesji (session policies) — przekazywane przy tworzeniu sesji tymczasowej, zawężające uprawnienia tej konkretnej sesji.

Polityki zarządzane vs inline

Uprawnienia można przypisać jako zarządzane (samodzielne, wielokrotnego użytku) albo inline (wpisane na stałe w jedną encję). Zarządzane dzielą się jeszcze na AWS Managed i Customer Managed:

W praktyce zaleca się polityki zarządzane — łatwiejsze do ponownego użycia i audytu; inline rezerwuje się do uprawnień, które mają istnieć wyłącznie z daną tożsamością.

Sama polityka to dokument JSON w wersji 2012-10-17, złożony z instrukcji (statements) z efektem (Allow/Deny), akcją, zasobem i opcjonalnymi warunkami (Condition) — np. wymuszeniem MFA^?MFA: multi-factor authentication — uwierzytelnianie wieloskładnikowe, np. hasło plus jednorazowy kod z telefonu. Oto minimalny przykład — odczyt jednego bucketa dozwolony tylko przy aktywnym MFA:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
    }
  ]
}

Do czego może być używane?

Najprostsze zastosowanie to nadanie ludziom i aplikacjom dokładnie takich uprawnień, jakich potrzebują. Ale prawdziwa siła IAM leży w rolach: pozwalają oddelegować dostęp bez rozdawania stałych kluczy (aplikacja na EC2 korzysta z zasobów bez żadnych poświadczeń na serwerze) oraz udostępnić zasoby między kontami (cross-account).

Kolejny scenariusz to federacja tożsamości — uwierzytelnia ona użytkowników poza AWS i wymienia tę tożsamość na tymczasowe poświadczenia AWS. Dzięki temu użytkownicy logujący się przez firmowy katalog (SAML 2.0) lub zewnętrznego dostawcę (OpenID Connect, np. Google) korzystają z zasobów bez zakładania osobnych kont IAM.

Jak wygląda typowy request?

Teoria łączy się z praktyką na prostym przykładzie: aplikacja uruchomiona na EC2 chce odczytać plik z S3.

Na żadnym etapie na serwerze nie ma stałego klucza — poświadczenia żyją tylko przez czas sesji, a decyzję o dostępie podejmuje logika IAM na podstawie polityk przypiętych do roli.

Dobre praktyki: zasada najmniejszych uprawnień

Najważniejszą zasadą, którą AWS powtarza niemal wszędzie, jest least privilege — nadawaj tylko te uprawnienia, które są realnie potrzebne do zadania. AWS zaleca zaczynać od minimum i dodawać w miarę potrzeb, a nie odwrotnie, bo zawężanie zbyt szerokich uprawnień po fakcie jest znacznie trudniejsze i rzadko się to robi.

Pomagają w tym konkretne narzędzia: IAM Access Analyzer (ponad 100 kontroli polityk i ostrzeżenia o zbyt szerokim dostępie), generowanie polityk z logów CloudTrail oraz informacja „last accessed", pokazująca faktycznie używane uprawnienia. Warto też wiedzieć, że IAM łączy dwa modele: RBAC (poprzez role) i ABAC (poprzez tagi i warunki w politykach) — ten drugi pozwala budować uprawnienia zależne od atrybutów (np. dział, projekt) bez mnożenia osobnych polityk.

Czym różni się od innych rozwiązań?

W porównaniu z tradycyjnym modelem uprawnień w systemach czy bazach danych, IAM wyróżniają trzy cechy: jest domyślnie zamknięty, opiera się na deklaratywnych politykach JSON, a wyraźne deny ma bezwzględny priorytet.

Na tle innych chmur różnice są głównie koncepcyjne (to uproszczenie modeli, nie porównanie funkcja-po-funkcji). W Microsoft Azure warstwa tożsamości (Microsoft Entra ID, dawniej Azure AD) jest osobnym katalogiem, a uprawnienia nadaje się przez przypisania ról RBAC do zakresów. Google Cloud IAM działa zwykle przez wiązanie „członek → rola → zasób" w hierarchii projektów i folderów. IAM AWS jest natomiast silnie zasobo- i polityko-centryczny: uprawnienia wyrażasz jako dokumenty polityk przypięte do tożsamości lub zasobów, a nie tylko jako gotowe role. Pamiętaj też, że IAM działa w obrębie jednego konta — zarządzanie wieloma kontami wymaga AWS Organizations i SCP.

Najważniejsze ograniczenia i wyzwania

Największym wyzwaniem IAM jest jego złożoność. Dziewięć typów polityk, reguły sumowania i przecinania oraz bezwzględny priorytet deny sprawiają, że wyliczenie „efektywnych uprawnień" bywa nieoczywiste nawet dla doświadczonych inżynierów.

To wprost prowadzi do błędnych konfiguracji: zbyt szeroka polityka z symbolem "*" w akcji lub zasobie potrafi po cichu przyznać dostęp znacznie większy, niż zamierzano — a takie błędy są jedną z częstszych przyczyn incydentów w chmurze.

Trzecim ograniczeniem są twarde limity (quotas), o których trzeba wiedzieć już na etapie projektowania architektury:

Większość z nich można zwiększyć przez Service Quotas, ale niektóre (np. długość nazwy roli czy maksymalny czas sesji) są sztywne. Szczegóły podaje dokumentacja limitów IAM i STS.

Kto za tym stoi?

IAM tworzy i utrzymuje Amazon Web Services; usługa jest ogólnie dostępna od 2011 roku i stanowi jeden z fundamentów platformy. Wokół niej działają usługi pokrewne — STS (poświadczenia tymczasowe), IAM Identity Center (dostęp pracowników) oraz IAM Access Analyzer (walidacja polityk).

Dlaczego to jest istotne?

IAM jest cichym fundamentem bezpieczeństwa całej chmury AWS. Każde wywołanie API, każde uruchomienie serwera i każdy odczyt z bazy jest oceniane przez logikę IAM — dlatego jakość polityk jest w praktyce tożsama z jakością bezpieczeństwa wdrożenia.

Dobrze zaprojektowane uprawnienia ograniczają skutki włamania do wąskiego wycinka infrastruktury; źle zaprojektowane zamieniają pojedynczy wyciek klucza w kompromitację całego konta. Dlatego przejście od długoterminowych kluczy ku poświadczeniom tymczasowym (rolom i STS) to jedna z najważniejszych zmian w bezpieczeństwie chmurowym ostatniej dekady — klucz, którego nie ma na dysku i który i tak wygasa po godzinie, znacznie trudniej ukraść.

Dla juniora IAM to nie „kolejna usługa", lecz język, w którym wyraża się całe bezpieczeństwo AWS. Kto opanuje logikę oceny polityk, różnicę między union a intersection i sens ról zamiast stałych kluczy, ten ma klucz do bezpiecznego korzystania z całej platformy.

Źródła

• AWS — „What is IAM?" (dokumentacja IAM User Guide) — link
• AWS — „Policy evaluation logic" (IAM User Guide) — link
• AWS — „Policies and permissions in IAM" (IAM User Guide) — link
• AWS — „IAM roles" (IAM User Guide) — link
• AWS — „Temporary security credentials in IAM" (IAM User Guide) — link
• AWS — „IAM and AWS STS quotas" (IAM User Guide) — link
• AWS — strona produktowa IAM — link