IAM od zera – co mówi Ci Twoje konto AWS zanim zaczniesz cokolwiek robić

Zanim postawisz pierwszą instancję EC2, zanim uruchomisz Lambda, zanim w ogóle pomyślisz o architekturze – sprawdź, w jakim stanie jest Twój IAM. Większość włamań na AWS wynika nie z dziur w usługach, ale z błędów konfiguracji tożsamości. Dwie komendy, które pokażę Ci dzisiaj, to punkt wyjścia każdego audytu.

IAM – o co w tym chodzi?

IAM (Identity and Access Management) to serce bezpieczeństwa AWS. Zarządza tym, kto może robić co w Twoim koncie. W IAM mamy kilka kluczowych pojęć:

User – konkretna osoba lub aplikacja z własnym zestawem poświadczeń
Group – zbiór userów, którym możemy przypisać uprawnienia hurtem
Role – tożsamość bez hasła, którą można “założyć” (AssumeRole) np. przez serwis AWS lub inny account
Policy – dokument JSON definiujący uprawnienia (co wolno, czego nie wolno, na jakich zasobach)

Brzmi prosto. Problem w tym, że w praktyce konta AWS rozrastają się organicznie i po kilku miesiącach nikt już nie wie, kto ma dostęp do czego. Właśnie dlatego zaczynamy od diagnostyki.

Komenda nr 1: Szybkie health-check konta

$ aws iam get-account-summary

To jedno polecenie zwraca skrót stanu bezpieczeństwa całego konta. Zobaczmy, co nam mówi:

MFAEnabled              : ✓ true
RootAccessKeys          : ✓ 0
AccountsWithoutPassword : ✓ 0

`MFAEnabled: true` ✓

Root user ma włączone MFA (Multi-Factor Authentication). To absolutne minimum. Root to konto z nieograniczonymi uprawnieniami – nie można go zablokować żadną IAM policy. Wyjątkiem są konta działające w ramach AWS Organizations, gdzie SCP (Service Control Policies) mogą ograniczać działania nawet roota – ale to już temat na osobny artykuł.

Jeśli ktoś przejmie hasło roota bez MFA, masz problem egzystencjalny. Włączone MFA oznacza, że logowanie wymaga też fizycznego urządzenia (klucz sprzętowy, aplikacja TOTP). Dobra wiadomość.

`RootAccessKeys: 0` ✓

Root nie ma aktywnych access keys. To kluczowe. Access keys to poświadczenia API – mogą być użyte automatycznie, bez MFA, z dowolnego miejsca na świecie. AWS wprost mówi: nie twórz access keys dla roota. Jeśli ta liczba byłaby większa od 0, pierwsza rzecz do zrobienia to ich usunięcie.

`AccountsWithoutPassword: 0` ✓

Wszystkie IAM users, które mają włączony dostęp do konsoli, mają ustawione hasło. Zero “martwych dusz” – kont bez hasła, które mogłyby czekać na przypadkowe aktywowanie lub nadużycie.

Podsumowanie: Trzy zielone. Konto wygląda na zadbane od strony podstawowej higieny. Ale to dopiero wstęp.

Komenda nr 2: Symulacja polityk IAM

$ aws iam simulate-principal-policy \
  --action-names sts:AssumeRole

Co to jest `simulate-principal-policy`?

To narzędzie pozwala zasymulować, czy dany principal (user, role) ma uprawnienie do wykonania konkretnej akcji – bez faktycznego jej wykonywania. Używaj tego do debugowania polityk i do audytów.

Newsletter AWS

Tutoriale, case study, nowości z chmury · co tydzień · po polsku

🔒 Zero spamu · wypis jednym kliknięciem

Wynik:

EvalDecision : ⚠ implicitDeny

`implicitDeny` – co to znaczy?

W IAM istnieją dwa typy odmowy:

Typ	Co oznacza
explicitDeny	Polityka wprost mówi `"Effect": "Deny"` dla tej akcji
implicitDeny	Brak jakiejkolwiek polityki z `"Effect": "Allow"` – domyślna odmowa

AWS działa na zasadzie deny by default. Jeśli nie ma explicite Allow, akcja jest zablokowana. implicitDeny przy sts:AssumeRole oznacza, że testowany principal nie ma w ogóle polityki, która pozwalałaby mu przejmować role.

Kiedy to jest OK, a kiedy problem?

OK – jeśli testujesz zwykłego usera, który nie powinien AssumeRole. Wynik oczekiwany.
Problem – jeśli testujesz serwis (np. Lambda, EC2 instance profile), który powinien przejmować rolę, ale nie może. To typowy błąd konfiguracyjny, który objawia się tajemniczymi błędami AccessDenied w logach.

Jak naprawić?

Dodaj do roli lub usera politykę z Allow na sts:AssumeRole:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/NazwaRoli"
    }
  ]
}

Pamiętaj, że AssumeRole wymaga uprawnień z dwóch stron:

Principal musi mieć Allow na sts:AssumeRole (identity-based policy)
Docelowa rola musi mieć trust policy pozwalającą temu principalowi ją przejąć (resource-based policy)

Praktyczny workflow audytu IAM

Zamiast od razu rzucać się w głąb konsoli, zacznij od terminala:

# 1. Ogólny stan konta
aws iam get-account-summary

# 2. Lista wszystkich userów
aws iam list-users

# 3. Kto ma aktywne access keys?
aws iam list-users --query 'Users[*].UserName' --output text | \
  xargs -I{} aws iam list-access-keys --user-name {}

# 4. Credential report – pełny obraz
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d

Credential report to złoto dla audytora – pokazuje kiedy ostatnio używano każdego klucza, czy MFA jest włączone per user, kiedy ostatnia zmiana hasła.

TL;DR

get-account-summary – szybki przegląd zdrowia konta, sprawdź zwłaszcza root access keys i MFA
simulate-principal-policy – debuguj uprawnienia zanim zaczniesz płakać nad AccessDenied o 2 w nocy
implicitDeny ≠ błąd konfiguracji, to może być stan oczekiwany – kluczowy jest kontekst
IAM to nie jednorazowa konfiguracja, to ciągły proces – regularnie rób credential report i usuwaj nieużywane klucze

AWS Security Hub i IAM Access Analyzer to kolejny krok po opanowaniu podstaw – ale o tym w osobnym wpisie.