Zabezpieczenia konta AWS

Masz konto AWS, masz IAM userów. Teraz musisz się upewnić, że nikt niepowołany nie dostanie się do Twojego konta. Bo jeśli ktoś przejmie Twoje konto AWS, może w kilka godzin wygenerować rachunek na tysiące dolarów (np. kopiąc kryptowaluty na drogich instancjach).

To nie jest teoria. To się zdarza regularnie. Dlatego bezpieczeństwo konta to temat numer 1.

MFA (Multi-Factor Authentication)

MFA dodaje drugi czynnik weryfikacji oprócz hasła. Nawet jeśli ktoś pozna Twoje hasło, bez drugiego czynnika nie zaloguje się.

Dwa czynniki to:

  • Coś co wiesz - hasło
  • Coś co masz - telefon z aplikacją authenticator lub fizyczny klucz

Typy MFA w AWS

Virtual MFA Device - aplikacja na telefonie generująca kody TOTP (6-cyfrowe, zmiana co 30 sekund).

Popularne aplikacje:

  • Google Authenticator
  • Microsoft Authenticator
  • Authy (backup w chmurze)

Darmowe, łatwe w konfiguracji, wystarczające dla większości użytkowników.

FIDO2 Security Key / passkey - fizyczny klucz USB (np. YubiKey) albo passkey zapisany w telefonie. Podłączasz do komputera i dotykasz przycisku.

Zalety: odporny na phishing (nie da się „podrobić" klucza), szybki w użyciu.

Wady: kosztuje ok. 200-300 PLN, musisz go mieć fizycznie przy sobie.

Hardware MFA Device - dedykowane urządzenie generujące kody (np. Gemalto token). Zamawiasz od AWS lub partnerów.

Używane głównie w korporacjach ze ścisłymi wymaganiami compliance. Dla indywidualnych użytkowników: virtual MFA wystarczy.

⚠️ EXAM ALERT
Na egzaminie: MFA na koncie root to obowiązkowy best practice. Pytania mogą brzmieć: „Jaki jest pierwszy krok zabezpieczenia nowo utworzonego konta AWS?" Odpowiedź: Włącz MFA na koncie root. Zapamiętaj też, że MFA można włączyć na dowolnym koncie IAM, nie tylko root.

Password Policy

AWS pozwala ustawić politykę haseł dla wszystkich IAM userów w koncie:

  • Minimalna długość hasła (domyślnie 8 znaków, rekomendowane: 14+)
  • Wymagane typy znaków: wielkie litery, małe litery, cyfry, znaki specjalne
  • Rotacja hasła - wymuszenie zmiany co X dni (np. co 90 dni)
  • Prevent password reuse - blokada ponownego użycia ostatnich N haseł
  • Allow users to change own password - czy user może sam zmienić hasło

Ustawia się to w: IAM → Account settings → Password policy.

Narzędzia audytu bezpieczeństwa

IAM Credentials Report

Raport CSV pokazujący status bezpieczeństwa wszystkich userów w koncie:

  • Kiedy ostatnio zmieniono hasło
  • Czy MFA jest włączone
  • Czy Access Keys są aktywne i kiedy ostatnio używane
  • Kiedy user ostatnio się logował

Generujesz go w: IAM → Credential report → Download.

IAM Access Advisor

Pokazuje, które usługi konkretny user rzeczywiście wykorzystywał (i kiedy ostatnio). Pomaga w stosowaniu least privilege: jeśli user nie korzystał z S3 od 6 miesięcy, prawdopodobnie nie potrzebuje do niego dostępu.

💡 Pro tip
Zrób sobie nawyk: raz w miesiącu pobierz Credentials Report i sprawdź, czy:
✅ Wszyscy mają MFA
✅ Nikt nie ma starych, nieużywanych Access Keys
✅ Nikt nie logował się od miesięcy (konto zombie?)
To 5 minut, które może uchronić Cię przed poważnym incydentem.
🏢 Scenariusz: Wyciek Access Key

Developer Jan commituje kod na GitHub. Nie zauważa, że w kodzie jest jego AWS Access Key. Bot skanujący GitHub wykrywa klucz w ciągu sekund. W ciągu godziny na koncie AWS Jana działają już dziesiątki drogich instancji kopiących kryptowaluty.

Co robić?

  • Natychmiast dezaktywuj Access Key w IAM
  • Sprawdź CloudTrail, jakie akcje wykonano
  • Usuń utworzone zasoby (instancje, role, inne klucze)
  • Wygeneruj nowy Access Key
  • Na przyszłość: używaj ról zamiast Access Keys, skanuj kod narzędziem git-secrets

Gdy masz wiele kont AWS (np. dev, staging, production), AWS Organizations pozwala zarządzać nimi centralnie. Możesz tworzyć SCP (Service Control Policies), czyli polityki na poziomie organizacji, które ograniczają NAWET administratorów w podkontach.

Przykład SCP: „Żadne konto w organizacji nie może uruchamiać instancji poza regionem EU". Nawet administrator w koncie dev nie obejdzie tego ograniczenia.

Więcej o Organizations w lekcji o architekturze wielu kont.

🧠 Podsumowanie
  • MFA na root = obowiązkowe. MFA na IAM = rekomendowane
  • 3 typy MFA: virtual (app), security key (FIDO2/passkey), hardware token
  • Password Policy: ustaw min. długość, rotację, złożoność
  • Credentials Report: audyt wszystkich userów w koncie
  • Access Advisor: sprawdzaj, z czego user faktycznie korzysta
  • Access Keys na GitHub = katastrofa. Używaj ról!
🧪 Sprawdź się

Jaki jest pierwszy krok zabezpieczenia nowo utworzonego konta AWS?

A Włączenie MFA na koncie root
B Ustawienie budżetu
C Utworzenie instancji EC2
MFA na root to zawsze pierwszy krok. Root ma nieograniczone uprawnienia, więc jego zabezpieczenie jest priorytetem numer 1.

Które narzędzie IAM pokazuje raport bezpieczeństwa WSZYSTKICH userów w koncie?

A IAM Access Advisor
B IAM Credentials Report
C IAM Policy Simulator
Credentials Report to raport CSV z informacjami o wszystkich userach (MFA, hasła, Access Keys). Access Advisor pokazuje dane o jednym konkretnym userze.

Developer przypadkowo wrzucił AWS Access Key na GitHub. Co powinien zrobić NAJPIERW?

A Usunąć commit z GitHuba
B Zmienić hasło do konta AWS
C Dezaktywować Access Key w IAM
Dezaktywacja klucza w IAM natychmiast uniemożliwia jego użycie. Usunięcie commita nie wystarczy (boty skanują w sekundach, a historia git zachowuje dane). Zmiana hasła nie pomoże, bo Access Key to osobny mechanizm.