Polityki i uprawnienia w AWS IAM — jak działają?

Czym jest polityka IAM?

Najprościej mówiąc, polityka IAM to dokument (najczęściej w formacie JSON) opisujący, kto może wykonać jakie operacje, na jakich zasobach i pod jakimi warunkami. To zestaw reguł określających uprawnienia — nic więcej i nic mniej.

AWS Identity and Access Management (IAM) to usługa, która kontroluje dostęp do zasobów w chmurze Amazona. Jej centralnym elementem są właśnie polityki (ang. policies). Zgodnie z dokumentacją AWS, polityka to obiekt, który po powiązaniu z tożsamością (użytkownikiem, grupą, rolą) lub z zasobem określa ich uprawnienia. Gdy podmiot (principal) wysyła żądanie do AWS, usługa ocenia obowiązujące polityki i na tej podstawie zezwala na operację lub jej odmawia.

Warto od razu ustalić, czym IAM nie jest. To nie jest zapora sieciowa ani mechanizm szyfrowania. To warstwa autoryzacji („kto ma prawo wykonać daną akcję na danym zasobie") działająca po uwierzytelnieniu („kto to w ogóle jest"). Same polityki nie przechowują danych — opisują reguły. Większość z nich to dokumenty JSON o ściśle określonej strukturze.

Tak wygląda najprostsza polityka w praktyce:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::photos/*"
    }
  ]
}

Ta polityka pozwala odczytywać wszystkie obiekty w buckecie photos — i nic poza tym. Kluczowa cecha: uprawnienie działa niezależnie od sposobu wykonania operacji. Jeśli polityka zezwala na akcję GetUser, użytkownik może ją wywołać przez konsolę AWS, przez CLI albo przez API — reguła jest ta sama.

Kto za tym stoi?

IAM to usługa Amazon Web Services, oferowana bez dodatkowych opłat jako część platformy AWS. Model uprawnień opiera się na języku polityk, którego aktualna wersja nosi oznaczenie 2012-10-17 — data ta jest wersją języka, a nie datą stworzenia usługi, i AWS zaleca jej stosowanie do dziś. Cały opisywany mechanizm pochodzi bezpośrednio z oficjalnej dokumentacji AWS IAM.

Jak to działa?

Zasada oceny żądania jest z pozoru prosta, ale ma kilka warstw. Przebiega w trzech krokach: uwierzytelnienie podmiotu, zebranie kontekstu żądania (jaka akcja, jaki zasób, jakie warunki) i właściwa ocena polityk.

Po uwierzytelnieniu AWS dysponuje czterema elementami opisującymi żądanie — i dopiero na nich przeprowadza ocenę polityk:

• Principal — uwierzytelniona tożsamość stojąca za żądaniem: użytkownik IAM, rola, konto lub usługa AWS.
• Action — konkretna operacja API, o którą prosi principal, np. s3:GetObject czy ec2:StartInstances.
• Resource — zasób lub zasoby, na których akcja ma zostać wykonana, wskazane przez ARN.
• Context — dodatkowe atrybuty żądania sprawdzane przez klucze warunków: adres IP, pora, obecność MFA, region czy szyfrowanie połączenia.

Fundamentem jest reguła domyślnej odmowy (default deny): jeśli żadna polityka wyraźnie nie zezwala na akcję, żądanie zostaje odrzucone. Aby operacja została dozwolona, musi istnieć wyraźne zezwolenie (explicit allow). Nad wszystkim góruje jednak wyraźna odmowa (explicit deny) — jeśli którakolwiek obowiązująca polityka zawiera Deny, żądanie zostaje zablokowane niezależnie od liczby zezwoleń. To hierarchia bez wyjątków: deny zawsze wygrywa z allow.

Gdy w grę wchodzi kilka typów polityk, logika się komplikuje. Polityki tożsamościowe^?Polityki tożsamościowe: Polityki przypinane do tożsamości IAM — użytkownika, grupy lub roli. Nadają jej uprawnienia. i polityki zasobowe^?Polityki zasobowe: Polityki przypinane bezpośrednio do zasobu (np. bucketa S3). Określają, kto i jakie akcje może na nim wykonać. działają na zasadzie sumy (union) — akcja jest dozwolona, jeśli zezwala na nią którakolwiek z nich. Natomiast granice uprawnień (permissions boundaries), polityki SCP^?SCP: Service Control Policy — polityka AWS Organizations wyznaczająca maksymalne uprawnienia dla kont w organizacji i RCP^?RCP: Resource Control Policy — odpowiednik SCP działający na poziomie zasobów, a nie tożsamości działają na zasadzie iloczynu (intersection): akcja musi być dozwolona przez wszystkie obowiązujące warstwy jednocześnie. Szczegółowo opisuje to strona o logice oceny polityk.

Najlepiej widać to na przykładzie. Gdy wszystkie warstwy zezwalają:

Wystarczy jednak, że jedna z warstw działających na zasadzie iloczynu odmówi:

Pojedyncze Deny w SCP przekreśla wszystkie zezwolenia — to właśnie w praktyce znaczy „iloczyn".

Typowy przebieg autoryzacji

W praktyce cała ścieżka — od aplikacji do decyzji — wygląda tak:

Z jakich elementów się składa?

Dokument JSON polityki zbudowany jest ze stwierdzeń (statements). Każdy element tablicy Statement opisuje jedną niezależną regułę uprawnień. Pojedyncze stwierdzenie zawiera zestaw pól:

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

• Version — wersja języka polityk (zalecana 2012-10-17).
• Effect — Allow lub Deny.
• Action — lista akcji. Każda usługa AWS definiuje własny zestaw akcji, np. s3:GetObject, ec2:StartInstances czy dynamodb:PutItem.
• Resource — zasoby, których dotyczą akcje, identyfikowane przez ARN^?ARN: Amazon Resource Name — unikalny identyfikator zasobu w AWS. Nie wszystkie akcje pozwalają wskazać konkretny zasób — część wymaga użycia "*". Nie oznacza to automatycznie dostępu do wszystkiego: dla wielu akcji AWS po prostu nie pozwala wskazać bardziej szczegółowego zasobu.
• Principal — określa, kto otrzymuje uprawnienia: konto AWS, użytkownik IAM, rola IAM albo usługa AWS. Wymagany w politykach zasobowych, a w tożsamościowych pomijany, bo podmiot jest domyślny.
• Condition — opcjonalne warunki oparte na tzw. kluczach warunków (condition keys), np. aws:SourceIp, aws:CurrentTime, aws:PrincipalArn, aws:RequestedRegion czy aws:SecureTransport. Pozwalają zawęzić dostęp — na przykład do konkretnego adresu IP albo wyłącznie do połączeń szyfrowanych.

Przykładowa reguła w praktyce: stwierdzenie z warunkiem "Bool": {"aws:MultiFactorAuthPresent": "true"} zadziała tylko wtedy, gdy użytkownik zalogował się z drugim składnikiem uwierzytelnienia. Jeśli warunek nie jest spełniony, całe stwierdzenie zostaje pominięte.

Gdy w polityce jest wiele stwierdzeń — lub gdy do podmiotu przypięto wiele polityk — AWS analizuje wszystkie obowiązujące stwierdzenia. Wystarczy jedno pasujące Allow, aby akcja mogła zostać dozwolona — chyba że wcześniej pojawi się pasujące Deny, które zawsze ma pierwszeństwo. AWS zaleca dzielenie uprawnień na osobne, funkcjonalne polityki (np. osobno zarządzanie S3, osobno zarządzanie użytkownikami) zamiast jednego przeładowanego dokumentu.

Jak czytać politykę IAM?

Prostą politykę da się odczytać, zadając po kolei pięć pytań:

Do czego może być używane?

Polityki IAM regulują właściwie każdy dostęp w AWS. W praktyce spotyka się kilka głównych typów.

Polityki tożsamościowe

Przypina się je do użytkowników, grup i ról. Dzielą się na dwa rodzaje:

• Zarządzane (managed) — wielokrotnego użytku; obejmują gotowe polityki AWS oraz własne polityki klienta.
• Wbudowane (inline) — przypięte na sztywno do jednej tożsamości i usuwane razem z nią.

Polityki zasobowe

Przypina się je bezpośrednio do zasobu — najczęstsze przykłady to polityki bucketów Amazon S3 oraz polityki zaufania ról IAM (trust policy). Ta ostatnia nie określa, co rola może robić, lecz kto może ją przyjąć (akcja sts:AssumeRole) — to jedno z najczęściej mylonych rozróżnień w IAM. Polityki zasobowe umożliwiają też dostęp międzykontowy: w polu Principal można wskazać konto lub podmiot z innego konta AWS.

Warstwy ograniczające

To mechanizmy nadrzędne, które nie nadają uprawnień, a jedynie je zawężają:

• Granice uprawnień — wyznaczają maksymalny pułap, jaki polityka tożsamościowa może przyznać danemu bytowi.
• SCP i RCP — guardrails w AWS Organizations, działające na poziomie całej organizacji lub jednostki organizacyjnej (OU^?OU: Organizational Unit — grupa kont w AWS Organizations, na którą można nałożyć wspólne polityki (np. SCP).):
  • SCP (Service Control Policy) — maksymalne uprawnienia dla tożsamości (użytkowników i ról) w kontach organizacji.
  • RCP (Resource Control Policy) — analogiczny pułap, ale nakładany na zasoby.
• Polityki sesyjne — przekazuje się je przy tymczasowym przyjmowaniu roli przez STS^?STS: AWS Security Token Service — usługa wydająca tymczasowe poświadczenia dostępu — mogą jedynie zawężać uprawnienia wynikające z roli, nigdy ich rozszerzać.

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

Najczęstsze nieporozumienie dotyczy różnicy między politykami, które nadają uprawnienia, a tymi, które je ograniczają. Tylko polityki tożsamościowe i zasobowe faktycznie przyznają dostęp. Granice uprawnień, SCP oraz RCP nigdy niczego nie nadają — jedynie zawężają to, co przyznały inne polityki. To rozróżnienie jest źródłem wielu błędów konfiguracyjnych: administrator dodaje SCP i dziwi się, że użytkownik nic nie może, bo brakuje polityki nadającej uprawnienia.

Drugą osią jest sposób łączenia — suma kontra iloczyn. Najkrócej ujmuje to tabela:

W modelu iloczynu każda dodana warstwa może tylko odebrać uprawnienia, nigdy ich dodać.

Warto też odróżnić polityki od list kontroli dostępu (ACL) — to jedyny typ polityki w AWS, który nie używa składni JSON i służy do przyznawania dostępu międzykontowego (np. w starszych konfiguracjach S3). W większości nowych wdrożeń AWS zaleca polityki zasobowe zamiast ACL.

Najważniejsze ograniczenia i wyzwania

Polityki mają fizyczne limity rozmiaru, przez co złożone uprawnienia często trzeba rozbijać na kilka dokumentów. Poważniejszym wyzwaniem jest jednak sama złożoność modelu: przy wielu nakładających się warstwach (tożsamościowa + zasobowa + granica + SCP + sesyjna) ustalenie faktycznych, efektywnych uprawnień bywa nietrywialne. Łatwo o dwa przeciwne błędy — nadmiar uprawnień (ryzyko bezpieczeństwa) albo nadmierne zawężenie (blokada działania).

AWS udostępnia narzędzia łagodzące te problemy: IAM Access Analyzer oferuje ponad 100 kontroli walidacyjnych polityk oraz może wygenerować propozycję polityki o minimalnych uprawnieniach na podstawie realnej aktywności zapisanej w CloudTrail^?CloudTrail: usługa AWS rejestrująca historię wywołań API na koncie. Informacje o „ostatnim użyciu" (last accessed) pomagają usuwać nieużywane uprawnienia. Mimo to odpowiedzialność za poprawną konfigurację spoczywa na zespole — to element modelu współdzielonej odpowiedzialności.

Konto root stanowi osobny przypadek: domyślnie ma pełne uprawnienia do konta i polityki IAM go nie ograniczają — nie można przypiąć mu polityki tożsamościowej ani ustawić granicy uprawnień. Podlega jednak SCP i RCP w ramach organizacji. Dlatego AWS zaleca, by dostępu root używać tylko w wyjątkowych sytuacjach.

Dlaczego to jest istotne?

IAM jest w praktyce najważniejszą pojedynczą warstwą bezpieczeństwa w AWS — i jednocześnie najczęstszym źródłem incydentów. Większość publicznych wycieków danych z chmury nie wynika z „włamania" w klasycznym sensie, lecz ze zbyt szeroko nadanego dostępu: otwartego bucketa, roli z uprawnieniami *, klucza dostępu, który nigdy nie powinien był powstać. Zrozumienie, że deny zawsze wygrywa z allow, że SCP niczego nie nadaje, a efektywny dostęp to iloczyn wielu warstw, przekłada się bezpośrednio na to, czy środowisko jest bezpieczne.

Dla juniora wchodzącego w chmurę to wiedza fundamentalna. AWS konsekwentnie promuje zasadę najmniejszych uprawnień (least privilege) oraz preferencję dla poświadczeń tymczasowych (ról) zamiast długotrwałych kluczy dostępu — obie rekomendacje wprost wynikają z dokumentu o najlepszych praktykach IAM. Opanowanie języka polityk nie jest więc detalem technicznym, lecz warunkiem odpowiedzialnego korzystania z chmury.

Polityki IAM to nie osobny produkt, tylko wspólny język uprawnień całego AWS. Kilka pojęć — allow, deny, principal, action, resource, condition — oraz kilka reguł oceny wystarcza, by opisać dostęp do niemal każdej usługi. To rzadki przypadek, w którym niewielki, spójny model steruje ogromnym, złożonym systemem.

Źródła

• AWS — IAM User Guide: Policies and permissions in AWS Identity and Access Management — link
• AWS — IAM User Guide: Policy evaluation logic — link
• AWS — IAM User Guide: Security best practices in IAM — link
• AWS — Organizations User Guide: Service control policies (SCPs) — link