Bezpieczeństwo AWS: IAM, VPC i model współdzielonej odpowiedzialności

Model współdzielonej odpowiedzialności

Bezpieczeństwo w AWS opiera się na fundamentalnej zasadzie, o którą potyka się wiele organizacji: AWS odpowiada za bezpieczeństwo samej chmury, a Ty za bezpieczeństwo w chmurze. AWS zabezpiecza fizyczne centra danych, hiperwizor, infrastrukturę usług zarządzanych i bazową sieć. Ty odpowiadasz za wszystko, co budujesz na wierzchu: dane, aplikacje, konfigurację IAM, reguły grup zabezpieczeń, wybór szyfrowania i logowanie.

Ta granica przesuwa się w zależności od typu usługi:

• IaaS (EC2): zarządzasz systemem operacyjnym, środowiskiem uruchomieniowym, aplikacją i danymi
• PaaS (RDS, Lambda): AWS zarządza systemem i środowiskiem; Ty zarządzasz aplikacją i danymi
• SaaS (Amazon WorkMail): AWS zarządza niemal wszystkim; Ty zarządzasz dostępem i danymi

Błędna konfiguracja po Twojej stronie granicy — publicznie dostępny bucket S3, zbyt szeroka rola IAM, grupa zabezpieczeń otwarta na 0.0.0.0/0 — to Twoja odpowiedzialność, niezależnie od tego, jak bezpieczna jest infrastruktura AWS.

IAM: najważniejsza kontrola bezpieczeństwa w AWS

AWS Identity and Access Management (IAM) decyduje, kto i co może robić we wszystkich usługach AWS. Prawidłowa konfiguracja IAM to pojedyncze działanie o największym wpływie na bezpieczeństwo AWS.

Ochrona konta root

Konto root AWS ma nieograniczony dostęp do wszystkiego i nie da się go ograniczyć politykami. Chroń je:

• Włącz sprzętowe MFA na koncie root zaraz po utworzeniu konta
• Nigdy nie twórz kluczy dostępu dla roota
• Używaj roota tylko do zadań, które go wymagają (rozliczenia, ustawienia konta, zmiana planu wsparcia)
• Ustaw alerty rozliczeniowe w CloudWatch, by zauważyć nieoczekiwane użycie

Użytkownicy, role i polityki IAM

Dla ludzi wybieraj IAM Identity Center (dawniej SSO) z tożsamościami sfederowanymi z firmowego katalogu zamiast pojedynczych użytkowników IAM. Dla tożsamości maszynowych (instancje EC2, funkcje Lambda, zadania ECS) zawsze używaj ról IAM zamiast wpisanych na stałe kluczy dostępu — role zapewniają tymczasowe poświadczenia, które rotują automatycznie.

Pisz polityki zgodnie z zasadą najmniejszych uprawnień:

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

Używaj IAM Access Analyzer, aby wykrywać zbyt szerokie polityki i zewnętrzny dostęp do zasobów. Regularnie generuj raporty poświadczeń (aws iam generate-credential-report), by audytować nieużywane klucze dostępu i użytkowników.

Service Control Policies (SCP)

W AWS Organizations polityki SCP działają jako maksymalne granice uprawnień dla całych kont lub jednostek organizacyjnych (OU). Używaj ich do egzekwowania zabezpieczeń w całej organizacji:

• Zakaz wyłączania CloudTrail
• Ograniczenie dozwolonych regionów
• Zakaz tworzenia publicznych bucketów S3
• Wymóg MFA dla wrażliwych operacji

VPC: izolacja sieci w AWS

Virtual Private Cloud (VPC) to Twoja prywatna sieć w AWS. Projektuj ją z myślą o bezpieczeństwie od samego początku:

Projekt podsieci

Rozdziel zasoby na warstwy podsieci publicznych, prywatnych i danych:

• Podsieci publiczne: tylko load balancery i bramy NAT — nic więcej
• Podsieci prywatne: serwery aplikacji, funkcje Lambda, zadania ECS — bez bezpośredniego dostępu do internetu
• Podsieci danych: bazy RDS, ElastiCache i inne magazyny danych — bez żadnej drogi do internetu

Zasoby w podsieciach prywatnych łączą się z internetem przez NAT Gateway (tylko ruch wychodzący). Ruch przychodzący z internetu powinien wchodzić wyłącznie przez load balancer w podsieci publicznej.

Grupy zabezpieczeń a NACL

Grupy zabezpieczeń (Security Groups) to stanowe zapory przypisane do pojedynczych zasobów — jeśli zezwolisz na ruch przychodzący na port 443, ruch powrotny jest automatycznie dozwolony. Stosuj zasadę najmniejszych uprawnień: tam, gdzie to możliwe, wskazuj jako źródło konkretne ID grup zabezpieczeń zamiast zakresów IP.

Network ACL są bezstanowe i działają na poziomie podsieci — trzeba zdefiniować zarówno reguły przychodzące, jak i wychodzące. Używaj NACL do szerokich kontroli na poziomie podsieci, a grup zabezpieczeń do precyzyjnej kontroli pojedynczych zasobów.

VPC Flow Logs

Włącz VPC Flow Logs dla wszystkich podsieci i przesyłaj je do CloudWatch Logs lub S3. Logi przepływów rejestrują adresy IP źródła i celu, porty, protokół oraz decyzje o akceptacji lub odrzuceniu — niezbędne w analizie kryminalistycznej i wykrywaniu anomalii.

Logowanie i monitoring: warstwa widoczności bezpieczeństwa

• CloudTrail: rejestruje każde wywołanie API AWS — kto, co, kiedy i skąd. Włącz go we wszystkich regionach, włącz walidację plików logów i przesyłaj je do bucketu S3 z polityką SCP blokującą usuwanie. To absolutna podstawa.
• AWS Config: rejestruje zmiany konfiguracji zasobów AWS i ocenia je względem reguł zgodności
• Amazon GuardDuty: wykrywanie zagrożeń oparte na uczeniu maszynowym, analizujące CloudTrail, VPC Flow Logs i logi DNS w poszukiwaniu przejętych poświadczeń, przejętych instancji i rekonesansu
• AWS Security Hub: zbiera wyniki z GuardDuty, Config, Inspector i narzędzi zewnętrznych w jednej konsoli z oceną według benchmarku CIS

Bezpieczeństwo S3

Publicznie wystawione buckety S3 to wciąż jedna z najczęstszych przyczyn wycieków danych z chmury. Egzekwuj na poziomie konta:

• Włącz S3 Block Public Access na poziomie konta — nadpisuje ono ustawienia poszczególnych bucketów
• Włącz domyślne szyfrowanie (SSE-S3 lub SSE-KMS) we wszystkich bucketach
• Włącz S3 Object Lock dla bucketów z logami audytowymi, aby zapobiec ich usunięciu
• Używaj polityk bucketów do wymuszania wyłącznie HTTPS: aws:SecureTransport: false → Deny
• Regularnie audytuj uprawnienia bucketów i wyszukuj dane wrażliwe za pomocą Macie