Amazon DOP-C02: Bezpieczeństwo, zgodność i ład — Przewodnik do nauki

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Część AWS DevOps Engineer Professional DOP-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Wykrywanie zagrożeń, higiena danych uwierzytelniających i zarządzanie podatnościami

Security Hub służy jako centralny panel („pane of glass”) do przeglądu wyników (findings) z różnych kont i regionów. Włącz go z użyciem delegowanego administratora, agreguj wyniki i aktywuj odpowiednie standardy (AWS Foundational Security Best Practices, CIS, PCI DSS, jeśli ma to zastosowanie). Wyniki trafiają do formatu AWS Security Finding Format (ASFF), który normalizuje dane wejściowe z usług GuardDuty, Inspector, IAM Access Analyzer, Config, Macie i narzędzi partnerskich. Skonfiguruj wzorce EventBridge, aby kierować krytyczne wyniki do automatyzacji naprawczych (SSM Automation, Lambda) i powiadomień (SNS, czat).

GuardDuty zapewnia zarządzane wykrywanie zagrożeń bez konieczności zarządzania potokami logów płaszczyzny danych (data-plane). Analizuje zdarzenia zarządcze i zdarzenia danych z CloudTrail, logi VPC Flow Logs, logi zapytań DNS z Route 53 Resolver oraz logi audytowe EKS w celu wykrywania anomalii w zachowaniu, eksfiltracji poświadczeń, kopania kryptowalut (crypto-mining), eksfiltracji przez DNS i innych zagrożeń. Włącz Malware Protection do skanowania S3 oraz EC2/EBS w przypadku podejrzanej aktywności. Użyj automatycznego włączania w całej organizacji i systematycznie archiwizuj wyniki o niskim znaczeniu (low-signal) za pomocą reguł tłumienia (suppression rules), aby skupić się na tych, które wymagają działania.

Amazon Inspector ciągle ocenia instancje EC2 (za pośrednictwem agenta SSM) pod kątem podatności CVE w pakietach, obrazy kontenerów ECR pod kątem podatności przed wdrożeniem oraz funkcje Lambda pod kątem podatności CVE w pakietach kodu. Inspector wymaga, aby instancje EC2 miały zainstalowanego agenta SSM, profil instancji zezwalał na uprawnienia SSM, a także zapewniony był ruch wychodzący (egress) do punktów końcowych SSM/KMS (przez VPC endpoints, jeśli dostęp do internetu jest ograniczony). Skonfiguruj Inspector, aby wysyłał wyniki do Security Hub i uruchamiał procesy łatania (patch workflows) za pomocą Systems Manager Patch Manager lub procesy naprawcze oparte na runbookach. Używaj tagów do określania zakresu zasobów objętych skanowaniem oraz do oddzielania środowisk testowych (sandbox) od obciążeń podlegających regulacjom.

Secrets Manager centralizuje przechowywanie, rotację i dostęp międzykontowy do danych uwierzytelniających, zapewniając przy tym silne możliwości audytu. Preferuj Secrets Manager nad Parameter Store dla poświadczeń wymagających rotacji, wykorzystując wbudowaną rotację dla RDS/Aurora lub rotację opartą na Lambda dla systemów zewnętrznych. Etykiety tymczasowe (staging labels), takie jak AWSCURRENT i AWSPREVIOUS, umożliwiają rotację bez przestojów (zero-downtime). Uruchamiaj funkcje Lambda do rotacji w sieciach VPC z niezbędnymi punktami końcowymi (Secrets Manager, RDS, KMS) i ograniczaj ruch wychodzący (egress). W celu użycia międzykontowego, dołącz politykę zasobów (resource-based policy), która nadaje uprawnienie GetSecretValue podmiotom (principals) z innych kont; upewnij się, że polityka klucza KMS (CMK) dla danego sekretu pozwala podmiotom konsumującym na deszyfrację oraz, w razie potrzeby, na tworzenie grantów. Dla celów odtwarzania po awarii (disaster recovery) lub kontroli lokalizacji, replikuj sekrety między regionami i zsynchronizuj okna czasowe rotacji.

Ochrona danych i bezpieczeństwo sieciowe

Projektuj szyfrowanie przy użyciu KMS z jawnymi politykami kluczy. To polityki kluczy, a nie tylko polityki IAM, ostatecznie autoryzują podmioty zabezpieczeń do wykonywania operacji kryptograficznych na kluczu CMK. Przyjmij model polityki klucza oparty na rolach i zasadzie najmniejszych uprawnień: deleguj administrację do centralnej roli administratora KMS; przyznawaj prawa do użycia wąsko zdefiniowanym rolom obciążeń roboczych; nie zezwalaj na symbol wieloznaczny kms:*, aby uniknąć przypadkowej eskalacji uprawnień. Używaj kluczy warunkowych (kms:EncryptionContext:*), aby powiązać deszyfrowanie z oczekiwanymi kontekstami. Klucze wieloregionowe umożliwiają szyfrowanie w trybie active-active, gdzie dane są replikowane między regionami.

Granty są właściwym narzędziem do delegowania tymczasowego lub wąsko zdefiniowanego użycia klucza bez edytowania polityki klucza i są wymagane w niektórych przepływach usług (np. EC2 Auto Scaling używający zaszyfrowanych szablonów uruchamiania, użycie obrazów AMI między kontami). Aby zezwolić innemu kontu na tworzenie grantów, polityka klucza musi zezwalać na kms:CreateGrant dla podmiotów zabezpieczeń tego konta; beneficjent grantu musi dostarczyć token grantu do natychmiastowego użycia w tej samej ścieżce wywołania. W przypadku zaszyfrowanych obrazów AMI między kontami, skopiuj i zaszyfruj AMI za pomocą klucza CMK, udostępnij AMI, zezwól docelowemu kontu na tworzenie grantów na kluczu CMK i spraw, aby docelowa rola powiązana z usługą otrzymała grant.

Szyfrowanie kopertowe to domyślny wzorzec: wygeneruj klucz danych za pomocą KMS, zaszyfruj dane lokalnie za pomocą klucza danych w postaci jawnej, a następnie przechowuj tylko szyfrogram i zaszyfrowany klucz danych. Przy odczycie wywołaj operację KMS Decrypt, aby odzyskać klucz danych w postaci jawnej do pamięci. Minimalizuje to liczbę wywołań KMS dla dużych ładunków danych i ogranicza ujawnienie klucza w postaci jawnej. Tam, gdzie jest to wspierane, używaj zarządzanego przez usługę SSE-KMS (S3, EBS, RDS) dla prostoty operacyjnej, ale nadal dostosowuj polityki kluczy dla producentów/konsumentów działających na różnych kontach.

Bezpieczeństwo VPC zaczyna się od grup bezpieczeństwa opartych na zasadzie najmniejszych uprawnień. Grupy bezpieczeństwa są stanowe; ruch powrotny jest domyślnie dozwolony. Preferuj odwołania do grup bezpieczeństwa zamiast reguł opartych na CIDR, aby unikać kruchych list dozwolonych adresów IP i zachować spójność intencji z kodem infrastruktury. Domyślne zezwolenia na ruch wychodzący są ryzykowne; jawnie ograniczaj ruch wychodzący (egress) do wymaganych miejsc docelowych i używaj punktów końcowych VPC do dostępu do usług AWS. Listy NACL są bezstanowe i oceniane jako pierwsze; utrzymuj je jako ogólne kontrole na poziomie podsieci z jawnymi regułami powrotnymi dla portów efemerycznych tylko wtedy, gdy musisz zaimplementować dodatkową granicę lub spełnić wymagania regulacyjne; w przeciwnym razie preferuj grupy bezpieczeństwa ze względu na łatwość zarządzania.

Wyeliminuj zależności od internetu, używając punktów końcowych VPC. Bramowe punkty końcowe (S3, DynamoDB) kierują ruch prywatnie przez sieć AWS; dołącz politykę punktu końcowego, aby ograniczyć dostęp do określonych bucketów lub tabel. Interfejsowe punkty końcowe (AWS PrivateLink) udostępniają usługi AWS (Secrets Manager, KMS, SSM, ECR, CloudWatch) poprzez prywatne adresy IP; wdrażaj je w podsieciach z odpowiednimi grupami bezpieczeństwa i włącz Prywatny DNS, aby standardowe nazwy usług były rozwiązywane na prywatne adresy. W przypadku mikrousług w modelu producent-konsument działających na różnych kontach/VPC, publikuj usługę punktu końcowego opartą na NLB i pozwól konsumentom tworzyć do niej interfejsowe punkty końcowe za pośrednictwem PrivateLink, unikając peeringu lub bram tranzytowych i utrzymując ruch z dala od publicznego internetu. Połącz te kontrole z podsieciami bez NAT i IGW oraz scentralizowaną inspekcją ruchu wychodzącego, gdy dostęp do internetu jest wymagany.

Praktyczny scenariusz problemowy

Expedia Group rozszerza swoją działalność na setki kont AWS w wielu regionach i musi wdrożyć rygorystyczne podstawy bezpieczeństwa: brak ruchu wychodzącego do internetu dla obciążeń roboczych, automatyczne korygowanie błędnych konfiguracji, scentralizowane wykrywanie zagrożeń, rotacja sekretów oraz kontrolowane udostępnianie zaszyfrowanych obrazów AMI między kontami w celu standaryzacji złotych obrazów.

1. Ustanów zarządzanie wieloma kontami za pomocą AWS Organizations i AWS Control Tower

• Działanie: Utwórz jednostki organizacyjne (OU) dla Sandbox, Dev, Prod i Security. Wdróż Control Tower, aby ustanowić landing zone, włączyć obowiązkowe barierki ochronne (guardrails) i zintegrować IAM Identity Center. Użyj Account Factory for Terraform (AFT), aby dostarczać konta poprzez GitOps.
• Dlaczego: Control Tower zapewnia gotowe do użycia, ciągle egzekwowane barierki ochronne (reguły SCP i Config). AFT standaryzuje provisioning kont na dużą skalę i kodyfikuje standardy w kontroli wersji.

2. Stwórz polityki SCP, aby wymusić globalne barierki ochronne z wyjątkami

• Działanie: Dołącz polityki SCP, które zabraniają wyłączania CloudTrail i AWS Config, ograniczają regiony i zapobiegają publicznym listom ACL w S3. Uwzględnij wyjątki oparte na warunkach dla roli administratora bezpieczeństwa w OU Security. Zezwól na tworzenie/używanie wymaganych ról powiązanych z usługami.
• Dlaczego: Polityki SCP ograniczają uprawnienia wszystkich podmiotów zabezpieczeń, włącznie z rootem, zapobiegając dryfowi konfiguracji, jednocześnie pozwalając na kontrolowane wyjątki dla operacji centralnych.

3. Wdróż pakiety zgodności (conformance packs) Config z automatycznym korygowaniem

• Działanie: Z konta z delegowanymi uprawnieniami administratora w OU Security włącz AWS Config w całej organizacji i utwórz agregator. Wdróż pakiet zgodności, który wymusza domyślne szyfrowanie EBS, ograniczone SSH, obowiązkowe tagi z domyślnymi wartościami i wymagany WAF na publicznych punktach wejścia. Przypisz każdą regułę do dokumentów SSM Automation w celu automatycznych napraw (np. dołącz domyślny profil instancji, ustaw brakujące tagi na weekly).
• Dlaczego: Pakiety zgodności dostarczają spójną, audytowalną politykę jako kod z automatycznym korygowaniem, które utrzymuje środowiska w stanie zgodności bez nadmiaru zgłoszeń.

4. Scentralizuj wykrywanie za pomocą Security Hub, GuardDuty i Inspector

• Działanie: Włącz GuardDuty i Inspector w całej organizacji z delegowanym administratorem. Włącz standardy Security Hub (AWS FSBP i CIS) i agreguj wyniki. Utwórz reguły EventBridge, aby kierować wyniki o wysokiej ważności do runbooków SSM Automation i tematu SNS dla zespołu dyżurnego.
• Dlaczego: Zarządzane wykrywanie i ocena podatności zapewniają ciągłą ochronę przy minimalnym obciążeniu operacyjnym, a Security Hub konsoliduje sygnały w celu szybszej analizy i reakcji.

5. Wymuś zasadę najmniejszych uprawnień w IAM za pomocą granic uprawnień (permission boundaries) i ABAC

• Działanie: Na kontach provisionowanych przez AFT, wymagaj, aby role tworzone przez deweloperów miały dołączoną granicę uprawnień, która zabrania iam:PassRole z wyjątkiem wybranych ról i ogranicza API o wysokim wpływie. Użyj zestawów uprawnień IAM Identity Center z ABAC, aby określić zakres działań według tagów zespołu.
• Dlaczego: Granice uprawnień umożliwiają bezpieczną samoobsługę, jednocześnie zapobiegając eskalacji uprawnień; ABAC redukuje rozrost polityk i pozostaje zgodny z atrybutami tożsamości.

6. Utwardź ścieżki sieciowe za pomocą punktów końcowych VPC i PrivateLink

• Działanie: Usuń IGW/NAT z podsieci aplikacyjnych. Utwórz interfejsowe punkty końcowe dla KMS, Secrets Manager, SSM, ECR, CloudWatch oraz bramowe punkty końcowe dla S3/DynamoDB z restrykcyjnymi politykami punktów końcowych. Publikuj wewnętrzne usługi platformy za pośrednictwem NLB wspieranych przez PrivateLink w celu konsumpcji między kontami.
• Dlaczego: Prywatna łączność eliminuje ekspozycję na internet i zapewnia, że usługi pozostają dostępne w zamkniętych środowiskach.

7. Zaimplementuj strategię kluczy KMS z grantami dla obrazów AMI między kontami

• Działanie: Utwórz klucze CMK dla każdego środowiska z politykami kluczy o zakresie ograniczonym do ról. Na koncie budującym obrazy, zaszyfruj złote obrazy AMI i udostępnij je. Zaktualizuj politykę CMK, aby zezwolić docelowym kontom na tworzenie grantów, a następnie utwórz granty dla ról powiązanych z usługami na tych docelowych kontach.
• Dlaczego: Granty zapewniają ograniczoną w zakresie, audytowalną delegację bez konieczności edytowania polityk kluczy dla każdego konsumenta, umożliwiając Auto Scaling uruchamianie instancji z zaszyfrowanych obrazów AMI na różnych kontach.

8. Standaryzuj rotację sekretów i dostęp między kontami

• Działanie: Przechowuj poświadczenia baz danych i API w Secrets Manager. Zaimplementuj rotację za pomocą Lambda dla celów innych niż RDS i włącz wbudowaną rotację dla RDS. W przypadku współdzielonych sekretów platformy, dołącz polityki oparte na zasobach, przyznające GetSecretValue rolom konsumentów na innych kontach i upewnij się, że polityki CMK zezwalają na deszyfrowanie. Umieść funkcje Lambda do rotacji w VPC z niezbędnymi punktami końcowymi.
• Dlaczego: Automatyczna rotacja zmniejsza ryzyko związane z poświadczeniami; polityki oparte na zasobach w połączeniu z odpowiednimi ustawieniami KMS umożliwiają bezpieczną konsumpcję między kontami, zachowując zasadę najmniejszych uprawnień i ślady audytowe.

Ta architektura zapewnia Expedia Group egzekwowalne barierki ochronne, udowadnialną zgodność, automatyczne naprawy i ściśle kontrolowane ścieżki dostępu do danych, jednocześnie zachowując tempo pracy deweloperów dzięki bezpiecznej samoobsłudze i prywatnej łączności.

← Monitorowanie · Wszystkie domeny · Kontenery i operacje serverless →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Amazon →