IAM: strażnik Twojego konta AWS
AWS IAM (Identity and Access Management) to usługa, która kontroluje kto może robić co w Twoim koncie AWS. Bez IAM, każdy kto zna Twoje dane logowania ma dostęp do wszystkiego. Z IAM, precyzyjnie określasz uprawnienia.
Pomyśl o IAM jak o systemie kart dostępu w biurze. Recepcjonistka ma kartę do lobby, programista do biura i serwerowni, a dyrektor do wszystkiego. Nikt nie dostaje klucza generalnego, chyba że naprawdę musi.
Fundamenty IAM
IAM opiera się na 4 elementach:
IAM User to tożsamość przypisana do konkretnej osoby lub aplikacji. Każdy user ma unikalne dane logowania.
Dwa typy dostępu:
- Console access - login + hasło (dla ludzi)
- Programmatic access - Access Key ID + Secret Access Key (dla CLI/SDK)
Best practice: jeden user = jedna osoba. Nigdy nie dziel konta.
IAM Group to kolekcja użytkowników. Zamiast nadawać uprawnienia każdemu z osobna, tworzysz grupę i przypisujesz uprawnienia do grupy.
Przykłady grup:
- Developers - dostęp do EC2, S3, Lambda
- DBAdmins - dostęp do RDS, DynamoDB
- ReadOnly - tylko odczyt, zero zapisu
Użytkownik może należeć do wielu grup jednocześnie.
IAM Role to tożsamość z uprawnieniami, ale bez stałych danych logowania. Rola jest „zakładana" tymczasowo.
Kto używa ról?
- Usługi AWS - np. EC2 zakłada rolę, żeby czytać z S3
- Użytkownicy - tymczasowo przełączają się na rolę z innymi uprawnieniami
- Zewnętrzne systemy - np. użytkownicy z innego konta AWS
Role są bezpieczniejsze niż Access Keys, bo credentials są tymczasowe i rotowane automatycznie.
IAM Policy to dokument JSON, który definiuje uprawnienia. Mówi: „Pozwól (Allow) lub zabroń (Deny) wykonania określonych akcji na określonych zasobach."
Przykład polityki (pozwala czytać z S3):
{"Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-bucket/*"}
Polityki przypisujesz do: użytkowników, grup lub ról.
Root User vs IAM User
| Cecha | Root User | IAM User |
|---|---|---|
| Tworzenie | Automatycznie przy rejestracji | Ręcznie przez admina |
| Uprawnienia | Pełne, nieograniczone | Tylko te, które przyznasz |
| Można ograniczyć? | Nie | Tak (przez polityki) |
| Używać na co dzień? | NIE! | Tak |
| MFA | Obowiązkowe! | Zalecane |
Masz firmę z 3 programistami. Zamiast dawać każdemu hasło do konta root, tworzysz:
- Grupę „Developers" z polityką dostępu do EC2, S3, Lambda
- 3 konta IAM (jan, anna, tomek), każde dodane do grupy Developers
- Osobne konto „admin" z polityką AdministratorAccess (ale NIE root!)
Teraz Jan ma dostęp do EC2 i S3, ale nie może kasować kont IAM ani zmieniać billingu. Jeśli Jan odchodzi z firmy, usuwasz jego konto IAM. Proste i bezpieczne.
Zasada najmniejszych uprawnień (Least Privilege)
To złota zasada IAM i jedna z najważniejszych koncepcji na egzaminie:
Dawaj każdemu dokładnie tyle uprawnień, ile potrzebuje do wykonania swojej pracy. Ani więcej.
Developer nie potrzebuje dostępu do billingu. HR nie potrzebuje dostępu do baz danych. Administrator nie powinien pracować na koncie root.
Password - do logowania w konsoli. Można wymusić politykę haseł (min. długość, znaki specjalne, rotacja).
Access Keys - para: Access Key ID (publiczny) + Secret Access Key (prywatny). Do CLI i SDK. Można mieć max 2 pary. Można dezaktywować bez usuwania.
Temporary credentials - generowane przez STS (Security Token Service) gdy ktoś zakłada rolę. Mają czas wygaśnięcia. Najbezpieczniejsza opcja.
Best practice: używaj ról zamiast Access Keys wszędzie, gdzie to możliwe. Access Keys mogą wycieknąć (np. ktoś wrzuci je na GitHub).
- IAM = kontrola „kto może co" w AWS
- 4 elementy: Users, Groups, Roles, Policies
- Root User: zabezpiecz MFA, nie używaj na co dzień
- Least Privilege: dawaj minimum wymaganych uprawnień
- Rola > Access Key (bezpieczniejsze credentials)
- IAM jest usługą globalną (nie zależy od regionu)
Firma ma 10 developerów, którzy potrzebują dostępu do EC2 i S3. Jaki jest najlepszy sposób zarządzania uprawnieniami?
Co oznacza zasada „Least Privilege"?
Instancja EC2 musi czytać pliki z S3. Jak najlepiej przyznać jej dostęp?