AWS IAM
AWS Identity and Access Management
Kontroluj kto ma dostęp do czego w Twoim koncie AWS. Fundamentalny serwis bezpieczeństwa - darmowy i globalny.
AWS IAM (Identity and Access Management) to serwis, który pozwala precyzyjnie zarządzać dostępem do zasobów AWS. Tworzysz użytkowników, grupy i role, a następnie przypisujesz im polityki (policies) określające co mogą - i czego nie mogą - robić.
IAM jest całkowicie darmowy i globalny - działa we wszystkich regionach jednocześnie. To pierwszy serwis, który powinieneś skonfigurować po utworzeniu konta AWS. Zasada numer jeden: nigdy nie używaj konta root do codziennej pracy. Stwórz sobie użytkownika IAM z uprawnieniami administratora i włącz MFA.
IAM opiera się na zasadzie least privilege - dawaj tylko te uprawnienia, które są absolutnie niezbędne. Jeśli Lambda potrzebuje czytać z jednego bucketa S3, nie dawaj jej dostępu do wszystkich bucketów.
IAM obsługuje do 5000 użytkowników na konto AWS i do 10 000 ról. Ale w praktyce best practice to minimalizacja użytkowników IAM na rzecz ról i federacji tożsamości. Duże firmy często mają 0 użytkowników IAM - wszyscy logują się przez SSO/Identity Center.
Używaj IAM Access Analyzer do znajdowania zasobów udostępnionych na zewnątrz Twojego konta. Włącz AWS CloudTrail, żeby mieć pełny audit log kto, co i kiedy robił. Regularnie przeglądaj IAM Credential Report - pokazuje ostatnią aktywność każdego użytkownika.
Nigdy nie umieszczaj access keys w kodzie źródłowym, na GitHubie ani w zmiennych środowiskowych na stałe. Jeśli klucze wyciekną, atakujący może w minuty postawić farmy do kopania kryptowalut na Twoim koncie. Zawsze używaj ról IAM zamiast kluczy, gdzie to możliwe.
IAM (Identity and Access Management) kontroluje KTO moze CO robic na JAKICH zasobach w Twoim koncie AWS. Kazde wywolanie API w AWS przechodzi przez IAM - to centralny punkt kontroli bezpieczenstwa. IAM jest globalny (nie per region) i darmowy.
Tworzenie tozsamosci (User, Role, Group)
IAM User to tozsamosc z dlugoteminowymi credentials (haslo do konsoli, access keys do CLI/API). IAM Group to kolekcja userow z wspolnymi uprawnieniami (np. grupa "Developers"). IAM Role to tozsamosc BEZ stalych credentials - tymczasowe tokeny sa generowane przez STS. Best practice: uzywaj IAM Roles zamiast Users wszedzie gdzie to mozliwe (EC2, Lambda, ECS).
Polaczenie polityk (Policies)
Policy to JSON dokument definiujacy uprawnienia. Typy: AWS Managed (utrzymywane przez AWS, np. AmazonS3ReadOnlyAccess), Customer Managed (Twoje wlasne), Inline (bezposrednio w user/role/group). Polityki maja: Effect (Allow/Deny), Action (np. s3:GetObject), Resource (ARN zasobu), opcjonalnie Condition (warunki). Deny zawsze wygrywa nad Allow.
Definiowanie uprawnien (JSON)
Przyklad polityki: {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:GetObject","s3:PutObject"],"Resource":"arn:aws:s3:::my-bucket/*","Condition":{"IpAddress":{"aws:SourceIp":"10.0.0.0/8"}}}]}. Klucz Version to zawsze 2012-10-17. Wildcard * mozna uzywac w Action i Resource. Condition pozwala na warunki: IP, czas, MFA, tag, VPC endpoint i wiele wiecej.
Assume Role - przejemowanie roli
Aby uzyc IAM Role, tozsamosc "przejmuje" ja przez STS AssumeRole. Trust Policy na roli definiuje KTO moze ja przejac (np. serwis EC2, inne konto AWS, user z MFA). Po assume role STS zwraca tymczasowe credentials (Access Key + Secret Key + Session Token) wazne od 15 min do 12 godzin. Instancje EC2 automatycznie assume swouj Instance Profile role.
Ewaluacja polityk
Przy kazdym API call IAM ewaluuje: 1) Czy jest explicit Deny - jesli tak, DENY. 2) Czy jest explicit Allow - jesli tak, Allow. 3) Brak pasujacego statement - implicit Deny. Kolejnosc ewaluacji: SCPs (Organization) -> Resource-based policies -> Permission boundaries -> Session policies -> Identity-based policies. Zrozumienie tej kolejnosci jest kluczowe do debugowania uprawnien.
Przyznanie lub odmowa dostepu
Koncowy wynik to Allow lub Deny. Cross-account access wymaga Allow zarowno w identity-based policy (konto zrodlowe) JAK I resource-based policy (konto docelowe). Wyjatki: resource-based policy z Principal na konkretnego usera moze zezwalac nawet bez identity-based policy w koncie zrodlowym. IAM Policy Simulator pozwala testowac polityki bez faktycznego wykonywania operacji.
IAM to najwazniejszy serwis AWS z perspektywy bezpieczenstwa. Zle skonfigurowany IAM to przyczyna wiekszosci naruszen bezpieczenstwa w chmurze.
Least Privilege - minimum potrzebnych uprawnien
Nigdy nie nadawaj "Action": "*" ani "Resource": "*" w produkcji. Zacznij od zera i dodawaj uprawnienia w miare potrzeb. Uzywaj IAM Access Analyzer do generowania polityk na podstawie CloudTrail - analizuje jakie API calls byly faktycznie wykonywane i proponuje minimalna polityke. Regularnie przegladaj nieuzywane uprawnienia: IAM Access Advisor pokazuje kiedy uprawnienia byly ostatnio uzyte.
PoczatkujacyService Control Policies (SCPs) - guardrails organizacji
SCPs w AWS Organizations definiuja MAKSYMALNE uprawnienia dla calego konta lub OU (Organizational Unit). SCP nie nadaje uprawnien - ogranicza to, co identity-based policies moga zrobic. Przyklad: SCP blokujacy regiony (DenyAllOutsideEU) uniemozliwia uruchomienie zasobow poza eu-central-1 i eu-west-1, niezaleznie od uprawnien usera. SCP nie wplywa na root usera konta zarzadzajacego (management account).
ZaawansowanyPermission Boundaries - delegowanie bez ryzyka
Permission Boundary to polityka ustawiona na userze/roli, ktora definiuje MAKSYMALNE mozliwe uprawnienia. Nawet jesli identity policy daje "s3:*", a boundary pozwala tylko "s3:GetObject" - efektywnie masz tylko GetObject. Uzywaj do delegowania tworzenia ról - deweloper moze tworzyc IAM Roles, ale tylko z permission boundary, ktora Ty kontrolujesz. Zapobiega eskalacji uprawnien.
ZaawansowanyIAM Access Analyzer - wykryj publiczny dostep
Access Analyzer skanuje Twoje konto i wykrywa zasoby udostepnione publicznie lub cross-account: S3 buckety, IAM roles, KMS keys, Lambda functions, SQS queues. Darmowy w podstawowej wersji. Od 2024 wspiera tez custom policy checks - mozes zdefiniowac reguey (np. "zadna polityka nie moze dawac s3:* do *") i sprawdzac nowe polityki przed wdrozeniem w pipeline CI/CD.
PoczatkujacyMFA - wymuszanie wielopoziomowej autentykacji
Wymus MFA dla wszystkich IAM userow z dostepem do konsoli. Dla operacji krytycznych (np. usuwanie zasobow) dodaj warunek MFA w policy: "Condition":{"Bool":{"aws:MultiFactorAuthPresent":"true"}}. Wspierane typy MFA: virtual (aplikacja np. Google Authenticator), hardware token (YubiKey), FIDO2 security key. Root user ZAWSZE powinien miec MFA. Rozwaaz AWS IAM Identity Center (SSO) zamiast IAM userow.
PoczatkujacyCross-account roles - bezpieczny dostep miedzy kontami
Zamiast tworzyc IAM userow w kazdym koncie, stworz role cross-account. W koncie docelowym: IAM Role z Trust Policy wskazujaca na konto zrodlowe. W koncie zrodlowym: polityke pozwalajaca na sts:AssumeRole. Uzytkownik przejmuje role przez STS i dostaje tymczasowe credentials. Mozesz wymagac MFA do assume role (Condition: aws:MultiFactorAuthPresent). External ID chroni przed "confused deputy" w scenariuszach third-party.
ZaawansowanyScreenshoty z AWS Console
Wkrotce pojawia sie tu zrzuty ekranu pokazujace jak korzystac z AWS IAM bezposrednio w konsoli AWS.
Do czego sluzy AWS IAM?
Kontrola dostępu (RBAC)
Określ precyzyjnie kto może uruchamiać EC2, czytać z S3, tworzyć bazy danych. Grupy ułatwiają zarządzanie - dodajesz użytkownika do grupy "Developers" i automatycznie dostaje odpowiednie uprawnienia.
Federacja tożsamości i SSO
Logowanie do AWS przez firmowy Active Directory, Google Workspace, Okta lub GitHub. Pracownicy nie potrzebują osobnych haseł do AWS - używają istniejących firmowych kont.
Role dla serwisów (Service Roles)
Pozwól Lambda czytać z S3, EC2 korzystać z SSM Parameter Store, ECS pobierać obrazy z ECR - bez hardcodowanych kluczy API. Role automatycznie rotują credentials.
Cross-account access
Bezpiecznie udostępniaj zasoby między kontami AWS. Np. konto produkcyjne ma rolę, którą mogą założyć developerzy z konta dev - bez kopiowania danych.
Co musisz wiedziec?
IAM User
Tożsamość osoby lub aplikacji z własnymi credentials. Może mieć login/hasło (konsola) i/lub access keys (CLI/API). Best practice: minimalizuj liczbę Users, preferuj Role.
IAM Group
Logiczny zbiór użytkowników z tymi samymi uprawnieniami. Np. "Developers" (EC2 + S3 + Lambda), "DBAdmins" (RDS + DynamoDB). Użytkownik może być w wielu grupach.
IAM Role
Tożsamość z uprawnieniami, ale BEZ stałych credentials. Credentials są tymczasowe (STS). Idealny dla serwisów AWS, federacji, cross-account access. Zawsze bezpieczniejszy niż User.
IAM Policy
Dokument JSON z regułami Allow/Deny. Określa: kto (Principal), co (Action, np. s3:GetObject), na czym (Resource, np. arn:aws:s3:::moj-bucket/*), kiedy (Condition). Domyślnie: wszystko jest Deny.
MFA (Multi-Factor Authentication)
Dodatkowa warstwa bezpieczeństwa - oprócz hasła wymagany kod z aplikacji (Google Authenticator, Authy) lub klucza sprzętowego (YubiKey). Obowiązkowe dla konta root i zalecane dla wszystkich.
Identity Center (dawniej AWS SSO)
Centralny punkt logowania do wielu kont AWS i aplikacji chmurowych. Integruje się z Active Directory, Okta, Google. Recommended way do zarządzania dostępem w organizacji.
Architektura: Bezpieczny dostep z IAM Roles
Wzorzec produkcyjny gdzie kazdy komponent ma minimalny zestaw uprawnien przez dedykowana IAM Role. Zero dlugoteminowych credentials, pelna audytowalnosc przez CloudTrail.
Porownanie IAM Users vs Roles vs SSO
| Cecha | IAM Users | IAM Roles | IAM Identity Center (SSO) |
|---|---|---|---|
| Przypadek uzycia | Konta serwisowe, CLI | Serwisy AWS, cross-account | Ludzie, wiele kont AWS |
| Bezpieczenstwo | Klucze dlugoterminowe (ryzyko) | Tymczasowe credentiale (bezpieczne) | Tymczasowe credentiale + MFA |
| Zarzadzanie | Per-user w kazdym koncie | Centralne policy, assume role | Centralny portal, grupy, permission sets |
| Rotacja kluczy | Reczna (wymagana!) | Automatyczna (STS) | Automatyczna |
| Best practice 2024+ | Unikaj dla ludzi | Preferowane dla serwisow | Preferowane dla ludzi |
Ile kosztuje AWS IAM?
Darmowy
IAM jest całkowicie bezpłatny. Nie ma żadnych opłat za tworzenie użytkowników, grup, ról, polityk czy certyfikatów.
$0.00 - zawsze, bez limitu
IAM Identity Center
Również darmowy. SSO do wielu kont AWS i aplikacji SAML 2.0 bez dodatkowych kosztów.
Nielimitowana liczba użytkowników SSO
IAM Roles Anywhere
Dla workloadów on-premises korzystających z ról IAM. Płacisz za certyfikaty i żądania.
$0.15 za 1000 wydanych credentials
Free Tier
IAM nie wymaga Free Tier - jest darmowy na stałe dla każdego konta AWS. Twórz dowolną liczbę zasobów IAM.
Zawsze darmowy, bez ograniczeń
Przyklady AWS CLI
Lista użytkowników IAM
Wyświetl wszystkich IAM users z datą utworzenia
aws iam list-users \
--query 'Users[].{Name:UserName,Created:CreateDate}' \
--output tableKto ja jestem?
Sprawdź aktualną tożsamość AWS (User/Role, konto)
aws sts get-caller-identityUtwórz użytkownika
Nowy IAM user z dostępem do konsoli i CLI
aws iam create-user --user-name jan-kowalski
# Dodaj do grupy
aws iam add-user-to-group \
--user-name jan-kowalski \
--group-name DevelopersSprawdź uprawnienia roli
Lista polityk przypiętych do roli Lambda
aws iam list-attached-role-policies \
--role-name lambda-execution-role \
--output tableQuiz: AWS IAM
Sprawdz czy dobrze rozumiesz podstawy. Kliknij odpowiedz — feedback pojawi sie od razu.
1. Co jest bezpieczniejsze - IAM User z access keys czy IAM Role?
2. Jaka jest domyślna reguła w IAM (jeśli nic nie skonfigurujesz)?
3. Czy IAM jest serwisem regionalnym czy globalnym?
4. Co powinieneś zrobić jako PIERWSZE po utworzeniu konta AWS?
Czesto uzywane razem z AWS IAM
Czytaj więcej o AWS IAM
Chcesz poznac AWS IAM w praktyce?
Darmowy kurs "AWS od podstaw" pokazuje jak uzywac AWS IAM krok po kroku. Teoria + praktyka od zera.