AWS Shared Responsibility Model
To jeden z najważniejszych tematów na egzaminie Cloud Practitioner. Shared Responsibility Model (Model Współdzielonej Odpowiedzialności) definiuje, za co odpowiada AWS, a za co odpowiadasz Ty jako klient. Zrozumienie tej granicy to klucz do zdania egzaminu i do bezpiecznego korzystania z chmury.
Zasada jest prosta: AWS odpowiada za bezpieczeństwo CHMURY (security OF the cloud), a Ty odpowiadasz za bezpieczeństwo W CHMURZE (security IN the cloud).
⚠️ Na egzaminie
Shared Responsibility Model pojawia się w WIELU pytaniach na CLF-C02. Pytania mają formę: „Kto jest odpowiedzialny za X?" Musisz umieć precyzyjnie rozdzielić odpowiedzialności AWS i klienta. Zapamiętaj formułkę: AWS = security OF the cloud, Customer = security IN the cloud.Za co odpowiada AWS (Security OF the Cloud)
AWS zarządza i chroni fizyczną infrastrukturę, na której działają wszystkie usługi AWS:
- Fizyczne data centers - budynki, ochrona fizyczna, kontrola dostępu, monitoring CCTV
- Hardware - serwery, storage, networking equipment
- Infrastruktura sieciowa - globalny backbone, regionalne połączenia
- Hypervisor - warstwa wirtualizacji oddzielająca maszyny wirtualne klientów
- Software infrastruktury - patching host OS, firmware, middleware dla managed services
- Availability Zones i Regiony - redundancja, zasilanie, chłodzenie
Podsumowując: AWS odpowiada za to, żeby infrastruktura pod spodem działała, była bezpieczna i dostępna. Ty nigdy nie musisz martwić się o fizyczny serwer, dysk czy switch.
Za co odpowiadasz Ty (Security IN the Cloud)
Klient (czyli Ty) odpowiada za to, co robi wewnątrz chmury AWS:
- Dane klienta - Twoje dane to Twoja odpowiedzialność (szyfrowanie, klasyfikacja)
- Konfiguracja platformy i aplikacji - security groups, NACLs, routing tables
- Zarządzanie tożsamością i dostępem (IAM) - kto ma dostęp do czego, MFA, password policy
- System operacyjny gościa - patching OS na EC2 (AWS NIE patchuje Twojego OS)
- Firewall i konfiguracja sieci - security groups, NACLs
- Szyfrowanie danych - client-side i server-side encryption
- Ochrona ruchu sieciowego - TLS/SSL, VPN
⚖️ Shared Responsibility Model
| Odpowiedzialność | AWS | Klient |
|---|---|---|
| Fizyczne data centers | ✅ | |
| Hardware i networking | ✅ | |
| Hypervisor | ✅ | |
| Patching host OS | ✅ | |
| Patching guest OS (EC2) | ✅ | |
| Konfiguracja security groups | ✅ | |
| Zarządzanie IAM (users, roles, policies) | ✅ | |
| Szyfrowanie danych | ✅ | |
| Dane klienta | ✅ | |
| Konfiguracja aplikacji | ✅ |
Jak model zmienia się w zależności od usługi
To kluczowa niuansacja. Granica odpowiedzialności przesuwa się w zależności od typu usługi:
IaaS (Infrastructure as a Service) - np. EC2
Przy EC2 masz największą odpowiedzialność jako klient. AWS daje Ci maszynę wirtualną, ale Ty odpowiadasz za:
- Patching systemu operacyjnego
- Konfigurację firewalla (security groups)
- Instalację i aktualizację oprogramowania
- Szyfrowanie danych na dysku
- Zarządzanie użytkownikami w OS
PaaS (Platform as a Service) - np. RDS, Elastic Beanstalk
AWS przejmuje więcej odpowiedzialności. Przy RDS na przykład:
- AWS patchuje system operacyjny i bazę danych
- AWS zarządza backupami (jeśli włączysz)
- Ty odpowiadasz za: konfigurację security groups, zarządzanie użytkownikami bazy danych, szyfrowanie
SaaS/Managed Services - np. S3, DynamoDB, Lambda
AWS przejmuje największą odpowiedzialność. Przy S3:
- AWS zarządza infrastrukturą, OS, platformą
- Ty odpowiadasz za: dane (co wrzucasz do bucketa), konfigurację dostępu (bucket policies, ACL), szyfrowanie
⚖️ Odpowiedzialność klienta: IaaS vs PaaS vs SaaS
| Odpowiedzialność | IaaS (EC2) | PaaS (RDS) | SaaS/Managed (S3, Lambda) |
|---|---|---|---|
| Patching OS | Klient ✅ | AWS ✅ | AWS ✅ |
| Patching platformy | Klient ✅ | AWS ✅ | AWS ✅ |
| Konfiguracja sieci | Klient ✅ | Klient ✅ | Częściowo AWS |
| Zarządzanie danymi | Klient ✅ | Klient ✅ | Klient ✅ |
| Szyfrowanie | Klient ✅ | Klient ✅ | Klient ✅ |
| Zarządzanie dostępem (IAM) | Klient ✅ | Klient ✅ | Klient ✅ |
💡 Zapamiętaj regułę
Im bardziej „managed" usługa, tym mniej odpowiedzialności po stronie klienta. Ale trzy rzeczy ZAWSZE leżą po stronie klienta, niezależnie od usługi: dane, szyfrowanie i zarządzanie dostępem (IAM).Scenariusze egzaminacyjne
Na egzaminie pytania o Shared Responsibility Model mogą wyglądać tak:
🏢 Scenariusz 1: Patching
Pytanie: Kto odpowiada za patching systemu operacyjnego na instancji EC2?
Odpowiedź: Klient. EC2 to IaaS, więc klient zarządza guest OS, w tym patchingiem.
Pytanie: Kto odpowiada za patching bazy danych w Amazon RDS?
Odpowiedź: AWS. RDS to managed service, więc AWS patchuje silnik bazy danych i OS pod spodem.
Odpowiedź: Klient. EC2 to IaaS, więc klient zarządza guest OS, w tym patchingiem.
Pytanie: Kto odpowiada za patching bazy danych w Amazon RDS?
Odpowiedź: AWS. RDS to managed service, więc AWS patchuje silnik bazy danych i OS pod spodem.
🏢 Scenariusz 2: Bezpieczeństwo fizyczne
Pytanie: Kto odpowiada za fizyczne bezpieczeństwo data centers AWS?
Odpowiedź: Zawsze AWS. Niezależnie od usługi, fizyczna infrastruktura to odpowiedzialność AWS. Klient nigdy nie ma fizycznego dostępu do data centers.
Odpowiedź: Zawsze AWS. Niezależnie od usługi, fizyczna infrastruktura to odpowiedzialność AWS. Klient nigdy nie ma fizycznego dostępu do data centers.
🏢 Scenariusz 3: Szyfrowanie i dane
Pytanie: Firma przechowuje dane wrażliwe w S3. Kto odpowiada za ich szyfrowanie?
Odpowiedź: Klient. AWS dostarcza narzędzia do szyfrowania (SSE-S3, SSE-KMS, SSE-C), ale decyzja o włączeniu szyfrowania leży po stronie klienta. AWS nie szyfruje danych za Ciebie automatycznie (chyba że włączysz default encryption na buckecie).
Odpowiedź: Klient. AWS dostarcza narzędzia do szyfrowania (SSE-S3, SSE-KMS, SSE-C), ale decyzja o włączeniu szyfrowania leży po stronie klienta. AWS nie szyfruje danych za Ciebie automatycznie (chyba że włączysz default encryption na buckecie).
🏢 Scenariusz 4: Security groups
Pytanie: Klient uruchomił EC2 i otworzył port 22 (SSH) na cały internet (0.0.0.0/0). Kto jest odpowiedzialny za tę lukę bezpieczeństwa?
Odpowiedź: Klient. Security groups to konfiguracja po stronie klienta. AWS daje narzędzie (security groups), ale to klient decyduje, jakie reguły ustawić.
Odpowiedź: Klient. Security groups to konfiguracja po stronie klienta. AWS daje narzędzie (security groups), ale to klient decyduje, jakie reguły ustawić.
Istnieją też Shared Controls, czyli obszary, gdzie odpowiedzialność jest współdzielona:
- Patch Management - AWS patchuje infrastrukturę i managed services; klient patchuje guest OS i aplikacje
- Configuration Management - AWS konfiguruje swoją infrastrukturę; klient konfiguruje swoje zasoby (OS, bazy danych, aplikacje)
- Awareness & Training - AWS szkoli swoich pracowników; klient szkoli swoich pracowników w zakresie bezpieczeństwa chmury
Na egzaminie pytania o Shared Controls są rzadsze, ale warto o nich wiedzieć.
W kontekście compliance (zgodność z regulacjami), odpowiedzialność też jest dzielona:
- AWS dostarcza certyfikacje i raporty compliance dla swojej infrastruktury (SOC 1/2/3, ISO 27001, PCI DSS, HIPAA). Te raporty są dostępne w AWS Artifact
- Klient odpowiada za compliance swoich aplikacji i danych. Fakt, że AWS ma certyfikat PCI DSS, nie oznacza automatycznie, że Twoja aplikacja jest zgodna z PCI DSS
AWS Artifact to darmowa usługa, w której pobierzesz raporty compliance AWS (przydatne do audytu w Twojej firmie).
⚠️ Na egzaminie
Typowy trick na egzaminie: pytanie, czy AWS odpowiada za szyfrowanie danych w S3. Odpowiedź: AWS oferuje narzędzia do szyfrowania (SSE-S3, SSE-KMS), ale klient decyduje, czy je włączyć. Odpowiedzialność za ochronę danych zawsze leży po stronie klienta. Kolejny trick: „Kto odpowiada za infrastrukturę AWS Lambda?" Odpowiedź: AWS. Lambda to fully managed service, więc AWS zarządza serwerami, patchingiem, skalowaniem. Klient odpowiada za kod i konfigurację funkcji.✅ Do zapamiętania z tej lekcji
AWS = security OF the cloud (fizyczna infrastruktura, hypervisor, host OS)
Klient = security IN the cloud (dane, IAM, guest OS, security groups, szyfrowanie)
Im bardziej managed usługa, tym mniej odpowiedzialności klienta
Dane, szyfrowanie i IAM to ZAWSZE odpowiedzialność klienta
EC2 (IaaS): klient patchuje OS. RDS (PaaS): AWS patchuje OS i DB engine
Fizyczne bezpieczeństwo data centers: ZAWSZE AWS
🧠 Podsumowanie
- Shared Responsibility Model dzieli bezpieczeństwo: AWS chroni chmurę (OF the cloud), klient chroni to, co jest w chmurze (IN the cloud)
- AWS odpowiada za: fizyczne data centers, hardware, networking, hypervisor, host OS, managed services infrastructure
- Klient odpowiada za: dane, IAM, guest OS (EC2), security groups, szyfrowanie, konfigurację aplikacji
- Granica odpowiedzialności przesuwa się w zależności od usługi: IaaS (EC2) = dużo po stronie klienta, PaaS (RDS) = AWS przejmuje więcej, SaaS/Managed (S3, Lambda) = AWS przejmuje większość
- Trzy rzeczy ZAWSZE leżą po stronie klienta: dane, szyfrowanie, zarządzanie dostępem (IAM)
- Shared Controls to obszary współdzielone: patch management, configuration management, awareness & training
- AWS Artifact dostarcza raporty compliance AWS (SOC, ISO, PCI DSS)
🧪 Sprawdź się
Kto odpowiada za patching systemu operacyjnego na instancji Amazon EC2?
A AWS
B Klient
C Odpowiedzialność jest współdzielona
EC2 to IaaS. Klient odpowiada za guest OS, w tym patching. AWS odpowiada tylko za infrastrukturę pod spodem (host OS, hypervisor, hardware). Gdyby pytanie dotyczyło RDS (PaaS), odpowiedź byłaby inna: AWS patchuje OS i silnik bazy danych.
Kto odpowiada za fizyczne bezpieczeństwo data centers AWS?
A AWS
B Klient
C Odpowiedzialność jest współdzielona
Fizyczne bezpieczeństwo data centers to ZAWSZE odpowiedzialność AWS. Klient nigdy nie ma fizycznego dostępu do infrastruktury AWS. To dotyczy: budynków, ochrony, kontroli dostępu, systemów zasilania i chłodzenia.
Firma korzysta z Amazon S3 i Amazon RDS. Która odpowiedzialność ZAWSZE leży po stronie klienta, niezależnie od usługi?
A Patching systemu operacyjnego
B Zarządzanie infrastrukturą fizyczną
C Zarządzanie danymi i dostępem (IAM)
Dane i zarządzanie dostępem (IAM) to ZAWSZE odpowiedzialność klienta, niezależnie od usługi. Patching OS zależy od usługi (klient przy EC2, AWS przy RDS). Infrastruktura fizyczna to zawsze AWS. Klient decyduje kto ma dostęp do jego zasobów i jak dane są chronione.