IAM - jak nie dać się zhackować na AWS. Poradnik bezpieczeństwa

Czym jest AWS IAM?

AWS Identity and Access Management (IAM) (dokumentacja) to usługa, która kontroluje kto i co może robić na Twoim koncie AWS. Każde wywołanie API, każde kliknięcie w konsoli, każde wdrożenie przez CLI przechodzi przez IAM. Jeśli Twoje konto AWS to budynek biurowy, IAM to system kart dostępu, kamer i zamków - decyduje kto wejdzie, do którego pokoju i co może tam zrobić.

W projektach, które prowadziłem, bezpieczeństwo IAM było zawsze fundamentem. Widziałem konta AWS, na których ktoś dał pełne uprawnienia administratora wszystkim programistom "bo tak było szybciej". Efekt? Przypadkowe usunięcie bazy produkcyjnej przez juniora, który pomylił środowisko. IAM to nie biurokracja - to polisa ubezpieczeniowa, która kosztuje zero złotych, a chroni przed katastrofą.

IAM jest usługą globalną (nie jest powiązana z konkretnym regionem) i co ważne - jest całkowicie darmowa. Nie płacisz za tworzenie użytkowników, grup, ról czy polityk. Nie ma wymówki, żeby nie wdrożyć go porządnie.

Users, Groups, Roles, Policies - podstawowe pojęcia

IAM opiera się na czterech filarach. Każdy pełni inną funkcję i zrozumienie różnic między nimi to klucz do bezpieczeństwa.

IAM User (Użytkownik) to tożsamość przypisana konkretnej osobie lub aplikacji. Każdy użytkownik ma unikalne dane logowania (login i hasło do konsoli, opcjonalnie klucze dostępowe do CLI/API). Analogia: to jak imienna karta do biura - wiesz kto wszedł i kiedy.

IAM Group (Grupa) to kolekcja użytkowników z tymi samymi uprawnieniami. Zamiast nadawać każdemu programiście uprawnienia osobno, tworzysz grupę "Developers" i dodajesz do niej ludzi. Gdy ktoś odchodzi z zespołu - usuwasz z grupy i gotowe. To jak departament w firmie - wszyscy na tym samym piętrze mają dostęp do tych samych sal.

IAM Role (Rola) to tożsamość, którą można "założyć" tymczasowo. Rola nie ma stałych danych logowania - generuje krótkotrwałe tokeny. Używają ich usługi AWS (np. EC2 potrzebuje roli, żeby czytać z S3), ale też ludzie, którzy potrzebują tymczasowego dostępu do innego konta. Analogia: to jak przepustka gościnna - działa przez określony czas i daje ściśle określone uprawnienia.

IAM Policy (Polityka) to dokument JSON, który definiuje uprawnienia. Policy sam w sobie nic nie robi - musisz go podpiąć do użytkownika, grupy lub roli. Mówi "kto może co robić z jakimi zasobami". To jak regulamin budynku - sam leży na półce, ale gdy go podpiszesz, zaczynają obowiązywać zasady.

Root account - dlaczego go NIE używasz

Pierwszą rzeczą, którą robię na każdym nowym koncie AWS, jest zabezpieczenie root account. Oto moja procedura:

Krok 1: Włącz MFA na root

Krok 2: Stwórz IAM User z uprawnieniami administratora

# Stwórz użytkownika
aws iam create-user --user-name emil-admin

# Włącz dostęp do konsoli (ustaw hasło)
aws iam create-login-profile --user-name emil-admin \
  --password 'TwojeS1lneH@slo!' --password-reset-required

# Podepnij politykę AdministratorAccess
aws iam attach-user-policy --user-name emil-admin \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Krok 3-5: Zabezpiecz root i włącz monitoring

1. Wyloguj się z root i schowaj hasło - zapisz je w menedżerze haseł i nie loguj się na root bez wyraźnej potrzeby
2. Usuń klucze dostępowe root - jeśli istnieją, usuń je natychmiast. Root nigdy nie powinien mieć access keys
3. Włącz alarmy CloudWatch - ustaw alert na logowanie root, żebyś wiedział, gdyby ktoś próbował go użyć

Na co dzień pracujesz na IAM User lub przez IAM Role z assume role. Root leży w sejfie i czeka na sytuację awaryjną. To nie nadgorliwość - to standard w każdej profesjonalnej organizacji korzystającej z AWS.

Principle of Least Privilege

Zasada minimalnych uprawnień (Principle of Least Privilege) to fundament bezpieczeństwa. Brzmi prosto: dawaj użytkownikom i usługom tylko te uprawnienia, których potrzebują do wykonania swojej pracy. Ani jednego uprawnienia więcej.

W praktyce wygląda to tak: jeśli deweloper potrzebuje deployować aplikację na EC2, nie dawaj mu AdministratorAccess. Daj mu ec2:StartInstances, ec2:StopInstances, s3:PutObject na konkretny bucket i logs:CreateLogGroup. Nic więcej.

Wiem, że brzmi to pracochłonnie. Na początku wszyscy chcą dać *:* (dostęp do wszystkiego), bo "działa i nie trzeba się zastanawiać". Ale pracowałem z firmami, gdzie jeden AdministratorAccess na koncie deweloperskim doprowadził do przypadkowego usunięcia tablic routingu VPC produkcyjnego. Przywracanie środowiska trwało 6 godzin i kosztowało firmę więcej niż pensja tego inżyniera za miesiąc.

Jak wdrożyć least privilege w praktyce?

• Zacznij od zera uprawnień i dodawaj tylko to, co jest potrzebne
• Użyj IAM Access Analyzer do identyfikacji nieużywanych uprawnień
• Przeglądaj CloudTrail logi, żeby zobaczyć, jakich API faktycznie używa dany użytkownik
• Generuj polityki na podstawie rzeczywistego użycia (logów CloudTrail) za pomocą IAM Access Analyzer - funkcja policy generation
• Regularnie (co kwartał) rób audyt uprawnień i usuwaj te, które nie były używane od 90 dni

IAM Policies - jak działają

Polityki IAM to dokumenty JSON składające się z jednego lub wielu "statements" (deklaracji). Każdy statement odpowiada na trzy pytania: czy pozwolić? na co? wobec czego?

Oto przykład polityki, która pozwala odczytywać obiekty z konkretnego bucketa S3:

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

Rozłóżmy to na części:

• Version - zawsze "2012-10-17" (to aktualna wersja języka polityk AWS, nie data Twojej polityki)
• Effect - "Allow" (pozwól) lub "Deny" (zabroń). Domyślnie wszystko jest zabronione, więc musisz jawnie pozwalać
• Action - lista operacji API (np. s3:GetObject, ec2:RunInstances). Możesz użyć wildcard s3:Get*, ale staraj się tego unikać
• Resource - ARN zasobów, których dotyczy polityka. Im bardziej konkretny, tym bezpieczniej

Ważna zasada: Deny zawsze wygrywa z Allow. Jeśli jedna polityka mówi "Allow s3:*" a druga "Deny s3:DeleteBucket", to DeleteBucket będzie zablokowany. To pozwala tworzyć "guardrails" - zabezpieczenia, które obowiązują niezależnie od innych polityk.

AWS rozróżnia dwa typy polityk:

• AWS Managed Policies - gotowe polityki tworzone i utrzymywane przez AWS (np. ReadOnlyAccess, PowerUserAccess). Wygodne na start, ale często zbyt szerokie
• Customer Managed Policies - Twoje własne polityki, dopasowane do potrzeb. Wymagają więcej pracy, ale są bezpieczniejsze, bo kontrolujesz każde uprawnienie

Jak stworzyć własną politykę IAM

Załóżmy, że chcesz stworzyć politykę pozwalającą na odczyt obiektów z konkretnego bucketa S3. Oto jak to zrobić:

# Stwórz plik z polityką
cat > s3-readonly-policy.json << 'POLICY'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::moj-bucket",
        "arn:aws:s3:::moj-bucket/*"
      ]
    }
  ]
}
POLICY

# Stwórz politykę w AWS
aws iam create-policy \
  --policy-name S3-ReadOnly-MojBucket \
  --policy-document file://s3-readonly-policy.json

# Podepnij politykę do użytkownika
aws iam attach-user-policy \
  --user-name emil-admin \
  --policy-arn arn:aws:iam::123456789012:policy/S3-ReadOnly-MojBucket

IAM Roles - klucz do bezpieczeństwa

Jeśli miałbym wskazać jeden element IAM, który najczęściej jest źle wdrożony, to byłyby to role. Wielu inżynierów nadal wrzuca klucze dostępowe (access keys) bezpośrednio w kod aplikacji na EC2 zamiast użyć IAM Role. To jak zostawić klucz pod wycieraczką - niby działa, ale każdy może go znaleźć.

EC2 Instance Role - gdy aplikacja działa na EC2 i potrzebuje dostępu do S3, DynamoDB czy SQS, nie tworzysz kluczy dostępowych. Tworzysz IAM Role z odpowiednimi uprawnieniami i podpinasz ją do instancji EC2. SDK automatycznie pobiera tymczasowe credentiale z Instance Metadata Service. Zero kluczy w kodzie, zero ryzyka wycieku.

Cross-account access - masz konto deweloperskie i produkcyjne? Zamiast tworzyć użytkowników na obu kontach, tworzysz rolę na koncie produkcyjnym i pozwalasz użytkownikom z konta dev "assume" (przejąć) tę rolę. Dostają tymczasowe tokeny ważne np. godzinę. Po godzinie muszą ponownie się uwierzytelnić. To dużo bezpieczniejsze niż stałe klucze dostępowe.

Service-linked roles - niektore usługi AWS (jak ELB, RDS, Auto Scaling) potrzebują roli do zarządzania zasobami w Twoim koncie. AWS tworzy je automatycznie. Nie modyfikuj ich - są skonfigurowane z minimalnymi uprawnieniami potrzebnymi do działania danej usługi.

Zasada numer jeden: jeśli coś może używać roli zamiast kluczy dostępowych - niech używa roli. Klucze dostępowe to ostatnia deska ratunku, a nie domyślny wybór.

Jak stworzyć IAM Role dla EC2

Typowy scenariusz: Twoja aplikacja na EC2 musi czytać pliki z S3. Zamiast wrzucać klucze do kodu, tworzysz rolę:

# Stwórz trust policy (kto może założyć rolę)
cat > trust-policy.json << 'TRUST'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"Service": "ec2.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }
  ]
}
TRUST

# Stwórz rolę
aws iam create-role \
  --role-name EC2-S3-ReadOnly-Role \
  --assume-role-policy-document file://trust-policy.json

# Podepnij politykę do roli
aws iam attach-role-policy \
  --role-name EC2-S3-ReadOnly-Role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Stwórz instance profile i dodaj rolę
aws iam create-instance-profile \
  --instance-profile-name EC2-S3-ReadOnly-Profile

aws iam add-role-to-instance-profile \
  --instance-profile-name EC2-S3-ReadOnly-Profile \
  --role-name EC2-S3-ReadOnly-Role

# Podepnij profil do instancji EC2
aws ec2 associate-iam-instance-profile \
  --instance-id i-0123456789abcdef0 \
  --iam-instance-profile Name=EC2-S3-ReadOnly-Profile

MFA - Multi-Factor Authentication

Multi-Factor Authentication dodaje drugą warstwę ochrony przy logowaniu. Nawet jeśli ktoś zdobędzie Twoje hasło (phishing, wyciek, brute force), bez drugiego składnika (kodu z telefonu lub klucza sprzętowego) nie zaloguje się na konto.

Na AWS masz kilka opcji MFA:

• Virtual MFA - aplikacja na telefonie (Google Authenticator, Authy, Microsoft Authenticator). Darmowa, łatwa do ustawienia, wystarczająca dla większości przypadków
• Hardware TOTP token - fizyczne urządzenie generujące kody (np. tokeny Thales, dawniej Gemalto). Droższe, ale nie wymaga telefonu
• FIDO2 Security Key - klucz sprzętowy USB (YubiKey, Titan). Najlepsza opcja dla root account - odporny na phishing

Jak skonfigurować MFA dla IAM User:

# Stwórz wirtualne urządzenie MFA
aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name emil-admin-mfa \
  --outfile /tmp/QRCode.png \
  --bootstrap-method QRCodePNG

# Otwórz /tmp/QRCode.png i zeskanuj kod aplikacją Authenticator
# Następnie włącz MFA podając dwa kolejne kody:
aws iam enable-mfa-device \
  --user-name emil-admin \
  --serial-number arn:aws:iam::123456789012:mfa/emil-admin-mfa \
  --authentication-code1 123456 \
  --authentication-code2 789012

Shared Responsibility Model

AWS działa w modelu współdzielonej odpowiedzialności. AWS zabezpiecza infrastrukturę (centra danych, sprzęt, sieć, hypervisor), a Ty zabezpieczasz to, co na niej budujesz. Zrozumienie tej granicy to podstawa - bo jeśli ktoś zhackuje Twoje konto przez słabe hasło, AWS nie ponosi za to odpowiedzialności.

W skrócie: AWS dba o bezpieczeństwo chmury (security OF the cloud), a Ty dbasz o bezpieczeństwo w chmurze (security IN the cloud). Jeśli zostawisz otwarte drzwi (publiczny S3 bucket, brak MFA), to Twoja odpowiedzialność - nie AWS.

Najczęstsze błędy bezpieczeństwa na AWS

Przez lata pracy z AWS widziałem dziesiątki incydentów bezpieczeństwa. Większość wynikała z tych samych, powtarzalnych błędów. Oto najczęstsze z nich:

Każdy z tych błędów jest w pełni eliminowalny. To nie są zaawansowane ataki zero-day - to podstawowe błędy konfiguracji, które można naprawić w kilka godzin.

Security tools na AWS

AWS daje Ci potężny zestaw narzędzi do monitorowania i zabezpieczania konta. Oto te, które powinieneś włączyć od pierwszego dnia:

• AWS CloudTrail - loguje każde wywołanie API na Twoim koncie. Kto, co, kiedy i skąd. To Twój "monitoring z kamer" - jeśli coś się stanie, CloudTrail powie Ci dokładnie co się wydarzyło. Włącz go na wszystkich regionach i wysyłaj logi do centralnego bucketa S3
• Amazon GuardDuty - inteligentna detekcja zagrożeń. Analizuje logi CloudTrail, VPC Flow Logs i DNS, szukając podejrzanych aktywności (np. logowanie z nieznanego kraju, cryptocurrency mining, skanowanie portów). Włączasz jednym kliknięciem
• AWS Security Hub - centralny dashboard bezpieczeństwa. Zbiera findings z GuardDuty, Inspector, Macie i innych usług w jednym miejscu. Daje Ci security score i listę rzeczy do naprawienia, posortowaną po priorytecie
• AWS Config - monitoruje konfigurację zasobów i sprawdza, czy są zgodne z Twoimi regułami (np. "czy wszystkie buckety S3 mają włączone szyfrowanie?", "czy security groups nie mają otwartego portu 22 na 0.0.0.0/0?"). Działa ciągle i alarmuje, gdy coś się zmieni
• AWS KMS - zarządzanie kluczami szyfrowania. Szyfruj dane at rest (S3, EBS, RDS); szyfrowanie in transit zapewnia TLS (certyfikaty z AWS Certificate Manager). KMS integruje się z praktycznie każdą usługą AWS

IAM best practices checklist

AWS Organizations i multi-account

Pojedyncze konto AWS na początku wystarczy, ale w miarę rozwoju organizacji multi-account to jedyna rozsądna strategia. AWS Organizations pozwala zarządzać wieloma kontami z jednego miejsca.

Typowa struktura to:

• Management account - tylko do zarządzania organizacją i rozliczeń
• Security account - centralne logowanie (CloudTrail, GuardDuty, Security Hub)
• Dev / Staging / Prod - oddzielne konta na każde środowisko
• Sandbox - konto do eksperymentów z ograniczonym budżetem

Organizations daje Ci Service Control Policies (SCP) - polityki, które definiują maksymalne uprawnienia dla całego konta. Nawet admin na koncie produkcyjnym nie może przekroczyć granic SCP. To dodatkowa warstwa ochrony, którą polecam wdrożyć jak najwcześniej.

Z mojego doświadczenia, przejście na multi-account to jedna z najlepszych decyzji architektonicznych, jaką firma może podjąć. Izolacja środowisk eliminuje całą kategorię błędów ("kto znowu deployował na prod zamiast na dev?") i upraszcza audyt bezpieczeństwa.

Następny krok

Bezpieczeństwo IAM to fundament, ale AWS to znacznie więcej. Jeśli dopiero zaczynasz przygodę z chmurą, przeczytaj Jak zacząć z AWS w 2026 - kompletny przewodnik od zera.

Planujesz certyfikację? Sprawdź Jak zdać AWS Cloud Practitioner - IAM to jeden z kluczowych tematów na egzaminie i po przeczytaniu tego artykułu masz już solidną bazę.

A jeśli wolisz uczyć się z instruktorem, dołącz do darmowego kursu AWS od podstaw, gdzie krok po kroku pokażę Ci jak skonfigurować IAM na żywym koncie AWS.