Amazon SCS-C02: Nadzór, konfiguracja i automatyzacja — Przewodnik do nauki

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

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

Zasady kontroli usług (Service Control Policies) i bariery ochronne na poziomie organizacji

Zasady kontroli usług (Service Control Policies) tworzą najbardziej zewnętrzną granicę tego, co jakikolwiek podmiot (principal) w organizacji AWS może zrobić. SCP nie jest polityką IAM — niczego nie nadaje, a jedynie definiuje maksymalne uprawnienia dostępne dla kont w ramach jednostki organizacyjnej (OU) lub całej organizacji. Zezwolenie (Allow) w polityce IAM, polityce zasobu lub granicy uprawnień (permissions boundary) jest całkowicie bezskuteczne, jeśli SCP zabrania danej akcji. Ta asymetria jest dokładnie powodem, dla którego SCP są właściwym narzędziem do tworzenia barier ochronnych (guardrails) na poziomie całej organizacji: ograniczeń regionalnych, blokowania usług, ochrony centralnie zarządzanych ról IAM oraz wymuszania szyfrowania podczas tworzenia zasobów.

Kanononiczna zasada SCP, która zabrania tworzenia niezaszyfrowanych tabel DynamoDB i bucketów S3, wygląda następująco:

Version: "2012-10-17"
Statement:
  - Sid: DenyUnencryptedS3
    Effect: Deny
    Action: s3:CreateBucket
    Resource: "*"
    Condition:
      StringNotEquals:
        s3:x-amz-server-side-encryption-aws-kms-key-id: !Ref CmkArn
  - Sid: DenyUnencryptedDdb
    Effect: Deny
    Action: dynamodb:CreateTable
    Resource: "*"
    Condition:
      "Null":
        dynamodb:SSESpecificationEnabled: "true"

Częstą pułapką jest próba wymuszenia zasady „nikt w organizacji nie może używać regionu us-east-2” lub „nikt nie może wyłączyć CloudTrail” za pomocą polityk IAM dołączonych do każdego konta. Nawet przy zastosowaniu granicy uprawnień i spójnych polityk tożsamości, lokalny administrator może stworzyć dla siebie furtkę. Można polegać jedynie na SCP zastosowanej na poziomie głównym (root) lub OU, ponieważ ogranicza ona nawet użytkownika root kont członkowskich (z niewielkim wyjątkiem kilku akcji, których nie można ograniczyć).

SCP powinny również chronić role typu „break-glass” i role delegowanej administracji: dodaj jawne Deny dla każdej akcji skierowanej do roli takiej jak OrganizationAccountAccessRole lub SecurityAudit, chyba że aws:PrincipalArn wywołującego pasuje do zatwierdzonej listy.

AWS Config, pakiety zgodności (Conformance Packs) i egzekwowanie na wielu kontach

AWS Config dostarcza warstwę ciągłej oceny, która uzupełnia SCP (które zapobiegają) o wykrywanie (które obserwuje i raportuje odchylenia od normy). Pakiet zgodności (conformance pack) to zbiór reguł Config — zarówno zarządzanych, jak s3-bucket-server-side-encryption-enabled, jak i niestandardowych opartych na Lambda lub Guard — spakowany jako pojedynczy, wdrażalny artefakt YAML z opcjonalnymi akcjami naprawczymi.

Aby wdrożyć standardowy zestaw bazowy w całej organizacji, łączy się dwa mechanizmy:

CloudFormation StackSets z konta zarządzającego (management account) z uprawnieniami zarządzanymi przez usługę (service-managed) i opcją AutoDeployment: Enabled, dzięki czemu każde nowe konto dołączające do organizacji automatycznie otrzymuje stos, który włącza rejestrator (recorder) i kanał dostarczania (delivery channel) usługi Config. Rozwiązuje to problem początkowej konfiguracji (bootstrap): pakiet zgodności nie może ocenić konta, na którym usługa Config nie jest włączona.
Pakiety zgodności wdrażane z konta delegowanego administratora (na przykład security-01) za pomocą PutOrganizationConformancePack. To propaguje spójny zestaw reguł na każde obecne i przyszłe konto bez konieczności ręcznej ingerencji w każde z nich.

Wzorzec delegowanego administratora i agregatora jest ważny: pozwala zespołowi bezpieczeństwa widzieć stan zgodności dla wszystkich kont w jednym miejscu, jednocześnie umożliwiając zespołom aplikacyjnym dodawanie własnych reguł lokalnie. Wdrażanie tych samych reguł bezpośrednio z konta zarządzającego zadziałałoby, ale narusza zasadę najmniejszych uprawnień (least privilege) i uniemożliwia audyty rozdziału obowiązków (separation-of-duties).

CloudFormation Guard, StackSets i Service Catalog

Zapobieganie powinno być przesunięte na wcześniejszy etap (shift left). CloudFormation Guard (cfn-guard) to silnik typu „polityka jako kod” (policy-as-code), który parsuje szablony CloudFormation (lub dowolny plik JSON/YAML) i ocenia je pod kątem deklaratywnych reguł przed wdrożeniem. Reguła Guard wygląda następująco:

rule s3_encrypted {
  Resources.*[ Type == "AWS::S3::Bucket" ] {
    Properties.BucketEncryption exists
    Properties.BucketEncryption.ServerSideEncryptionConfiguration[*] {
      ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
    }
  }
}

Włączenie tego do etapu CI/CD — zazwyczaj jako krok w kontenerze Docker, który uruchamia cfn-guard validate -r rules.guard -d template.yaml — powoduje niepowodzenie pipeline’u, zanim jakikolwiek niezgodny zasób zostanie utworzony. W przypadku naruszenia pipeline publikuje wiadomość do tematu SNS, który subskrybuje zespół bezpieczeństwa, dając im wgląd w sytuację bez stawania się wąskim gardłem ręcznych zatwierdzeń. Poleganie wyłącznie na StackSets lub przeglądzie zestawów zmian (change-set) w CloudFormation w celu powiadamiania zespołu bezpieczeństwa to pułapka: żadna z tych usług nie emituje wyników zgodności dla poszczególnych zasobów, a do czasu utworzenia stosu zasób już istnieje na koncie.

Service Catalog uzupełnia Guard na ostatnim etapie („last mile”). Zamiast pozwalać deweloperom pisać dowolne szablony CloudFormation, zespół platformowy publikuje sprawdzone produkty (bazowe konfiguracje VPC, wzorce RDS, klastry EKS) jako portfolia Service Catalog, udostępniane między kontami za pośrednictwem AWS RAM. Deweloperzy uruchamiają je z ograniczonymi parametrami, a rola IAM z ograniczeniem uruchamiania (launch constraint) provisionuje zasoby z podwyższonymi uprawnieniami, których deweloper osobiście nie posiada. Daje to audytowalny, samoobsługowy model wdrażania, w którym bazowy szablon przeszedł już weryfikację przez Guard.

Same StackSets wymagają odpowiedniej konfiguracji: używaj modelu uprawnień SERVICE_MANAGED podczas wdrażania z konta zarządzającego organizacją, włącz zaufany dostęp (trusted access) dla CloudFormation w Organizations i starannie skonfiguruj role wykonawcze (execution roles). Para AdministrationRoleARN/ExecutionRoleName (w trybie self-managed) lub role powiązane z usługą (service-linked roles, w trybie service-managed) muszą mieć uprawnienie iam:PassRole nadane roli serwisowej CloudFormation, która faktycznie tworzy zasoby. Zapomnienie o dołączeniu roli serwisowej CloudFormation i poleganie zamiast tego na poświadczeniach użytkownika wdrażającego prowadzi do sporadycznych błędów AccessDenied przy iam:PassRole — co jest częstą przyczyną nieudanych operacji StackSet. Prawidłowym wzorcem jest jedna dedykowana rola serwisowa na stos, posiadająca tylko te uprawnienia, które są niezbędne do utworzenia zadeklarowanych typów zasobów.

Zautomatyzowane potoki naprawcze

Gdy usługa Config wykryje niezgodność, działania naprawcze muszą być automatyczne dla wszystkiego, co można bezpiecznie naprawić samodzielnie. Przepływ zdarzeń jest następujący:

Config publikuje zdarzenie Compliance Change na domyślnej magistrali zdarzeń.
Reguła EventBridge filtruje wyniki NON_COMPLIANT dla określonych reguł i kieruje je do dokumentu Systems Manager Automation (dla prostych, idempotentnych poprawek, jak włączenie szyfrowania S3), funkcji Lambda (dla poprawek na poziomie API) lub maszyny stanów Step Functions (dla wieloetapowych przepływów pracy wymagających zatwierdzeń, ponownych prób lub orkiestracji międzyusługowej).

Na przykład, jeśli reguła s3-bucket-public-read-prohibited zostanie uruchomiona, skrypt runbook SSM Automation AWS-DisableS3BucketPublicReadWrite naprawia ten problem. W przypadku bardziej złożonych przepływów — powiedzmy, polityki klucza KMS, która uległa zmianie i musi zostać uzgodniona, z jednoczesnym powiadomieniem zespołu odpowiedzialnego — Step Functions koordynuje działania: odczytuje bieżącą politykę, porównuje ją z wersją wzorcową, wywołuje kms:PutKeyPolicy, a następnie publikuje powiadomienie w SNS. Przechowywanie logiki naprawczej w Step Functions zamiast w pojedynczej funkcji Lambda zapewnia obserwowalność każdego kroku i przejrzystą semantykę ponawiania prób.

IAM Access Analyzer i walidacja polityk

IAM Access Analyzer odpowiada na dwa odrębne pytania. Po pierwsze, analizatory dostępu zewnętrznego identyfikują zasoby (S3, KMS, role IAM, Lambda, SQS, Secrets Manager), których polityki przyznają dostęp podmiotom (principals) spoza zdefiniowanej strefy zaufania — konta lub organizacji. Włącz analizator na poziomie organizacji z konta delegowanego administratora, aby wyniki były agregowane centralnie.

Po drugie, walidacja polityk i generowanie polityk w Access Analyzer działają podczas ich tworzenia. Polecenie aws accessanalyzer validate-policy zwraca ostrzeżenia dotyczące bezpieczeństwa, błędy i sugestie (na przykład oznaczając zbyt szerokie Resource: "*" w połączeniu z wrażliwymi akcjami). Zintegruj to z tym samym etapem CI/CD co cfn-guard, aby polityki IAM osadzone w CloudFormation były sprawdzane przed wdrożeniem. Access Analyzer może również wygenerować politykę o najmniejszych uprawnieniach na podstawie historii CloudTrail, zastępując politykę z symbolem wieloznacznym (wildcard) dokładnymi akcjami, których rola faktycznie używała. Jest to mechaniczna odpowiedź na potrzebę „egzekwowania zasady najmniejszych uprawnień dla dostępu do danych”, działająca w połączeniu z polityką klucza KMS o zawężonym zakresie, która zezwala na kms:Decrypt tylko wtedy, gdy usługa wywołująca to S3, DynamoDB, Lambda lub EKS, za pomocą warunków kms:ViaService.

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma Meridian Financial zarządza wielokontową organizacją AWS, która obejmuje konta produkcyjne, stagingowe, deweloperskie (sandbox) oraz scentralizowane konto bezpieczeństwa. Wdrażają obciążenia robocze, używając mieszanki szablonów CloudFormation i szablonów tworzonych przez deweloperów na kontach deweloperskich; odpowiedzialność jest sfederowana pomiędzy zespołami i muszą one spełniać wewnętrzne wymogi ładu korporacyjnego dotyczące szyfrowania danych i dostępu opartego na zasadzie najmniejszych uprawnień.

Wyzwanie: Deweloperzy na kontach deweloperskich przypadkowo utworzyli publiczne buckety S3 i zbyt liberalne polityki IAM, które zostały rozpropagowane na inne konta, a zespołowi bezpieczeństwa brakuje spójnego, zautomatyzowanego egzekwowania zasad i walidacji szablonów w całej Organizacji.

Zalecane podejście:

Utwórz Service Control Policies (SCPs) na poziomie Organizacji, aby zablokować publiczny dostęp do S3, wymusić szyfrowanie bucketów i ograniczyć uprzywilejowane akcje IAM na poziomie głównym (root) Organizacji, zapewniając prewencyjne bariery ochronne (guardrails).
Ze scentralizowanego konta bezpieczeństwa wdróż agregator AWS Config i pakiety zgodności (Conformance Packs) przy użyciu CloudFormation StackSets na każde konto i do każdego regionu, aby stale oceniać publiczny dostęp do S3, wzorce dołączania polityk IAM oraz zgodność z wymogami szyfrowania.
Zintegruj reguły CloudFormation Guard (cfn-guard) z potokiem CI/CD (CodePipeline/CodeBuild) i wymagaj używania produktów Service Catalog dla zatwierdzonej infrastruktury, aby szablony były walidowane i tylko zgodne stosy mogły być provisionowane.
Włącz zautomatyzowaną remediację AWS Config za pomocą dokumentów SSM Automation lub skryptów runbook Lambda dla wyników o wysokim priorytecie (automatyczne blokowanie publicznego dostępu do S3, naprawa zbyt szerokich polityk IAM) i uruchamiaj dodatkowe przepływy pracy przez EventBridge.
Uruchamiaj centralnie IAM Access Analyzer i walidację polityk, przesyłaj wyniki do Security Hub i automatyzuj tworzenie zgłoszeń lub uruchamianie scenariuszy naprawczych (playbooks) dla wykrytych polityk międzykontowych lub zbyt liberalnych.

Uzasadnienie: Takie podejście łączy prewencyjne bariery ochronne na poziomie całej organizacji (SCPs), ciągłe wykrywanie (Config/Conformance Packs), walidację szablonów na wczesnym etapie („shift-left”) (cfn-guard/Service Catalog) oraz zautomatyzowaną remediację z IAM Access Analyzer, aby egzekwować zasadę najmniejszych uprawnień i osiągnąć spójny ład korporacyjny w środowisku wielokontowym, zgodnie z najlepszymi praktykami AWS.

AWS Config: Reguły organizacyjne, agregatory i delegowana administracja

AWS Config jest podstawą detektywnej zgodności (compliance) w AWS. Usługa ta stale rejestruje konfiguracje zasobów i ocenia je w oparciu o reguły — zarządzane przez AWS (na przykład restricted-ssh, vpc-flow-logs-enabled, encrypted-volumes) lub niestandardowe (oparte na Lambda lub Guard). W skali przedsiębiorstwa trzy decyzje architektoniczne mają większe znaczenie niż same reguły: sposób wdrażania reguł, sposób agregowania wyników i to, kto jest właścicielem narzędzi.

W przypadku wdrożeń obejmujących wiele kont i regionów w ramach AWS Organizations, prawidłowym wzorcem jest wyznaczenie konta delegowanego administratora (zazwyczaj jest to konto bezpieczeństwa lub audytu, a nie konto zarządzające) za pomocą polecenia

Version: "2012-10-17"
Statement:
  - Sid: DenyUnencryptedS3
    Effect: Deny
    Action: s3:CreateBucket
    Resource: "*"
    Condition:
      StringNotEquals:
        s3:x-amz-server-side-encryption-aws-kms-key-id: !Ref CmkArn
  - Sid: DenyUnencryptedDdb
    Effect: Deny
    Action: dynamodb:CreateTable
    Resource: "*"
    Condition:
      "Null":
        dynamodb:SSESpecificationEnabled: "true"

. Z tego konta należy użyć PutOrganizationConfigRule lub PutOrganizationConformancePack, aby rozpropagować reguły na wszystkie konta członkowskie i regiony. Pominięcie delegowanej administracji zmusza do ręcznego włączania Config na każdym koncie lub uruchamiania wszystkiego z konta zarządzającego — to drugie narusza zasadę rozdziału obowiązków, a pierwsze nie skaluje się powyżej kilku kont.

Reguły organizacyjne propagują pojedynczą definicję reguły; agregatory zbierają wyniki jej oceny. Utwórz agregator na koncie delegowanego administratora z OrganizationAggregationSource obejmującym wszystkie konta i regiony. Panel agregatora pozwala wtedy odpowiedzieć na pytania typu „które VPC na 200 kontach nie mają włączonych Flow Logs?” bez konieczności żonglowania rolami między kontami. Należy pamiętać, że agregatory są tylko do odczytu: pokazują stan zgodności, ale same nie wykonują naprawy.

Pakiety zgodności (Conformance Packs) do egzekwowania linii bazowej

Pakiet zgodności (conformance pack) łączy reguły AWS Config i akcje naprawcze w jeden szablon YAML. AWS dostarcza pakiety zmapowane na frameworki takie jak PCI DSS, HIPAA, NIST 800-53 i CIS. Wdrożenie organizacyjnego pakietu zgodności z konta delegowanego administratora pozwala targetować określone jednostki organizacyjne (OU) — na przykład stosując bardziej rygorystyczny pakiet dla OU Prod niż dla Sandbox. Jest to najwydajniejszy sposób na egzekwowanie spójnej linii bazowej na setkach kont, ponieważ jedno wywołanie API propaguje zestaw reguł i powiązane z nim akcje naprawcze wszędzie jednocześnie.

Resources:
  EncryptedVolumesRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: encrypted-volumes
      Source:
        Owner: AWS
        SourceIdentifier: ENCRYPTED_VOLUMES
  EncryptedVolumesRemediation:
    Type: AWS::Config::RemediationConfiguration
    Properties:
      ConfigRuleName: encrypted-volumes
      TargetType: SSM_DOCUMENT
      TargetId: AWSConfigRemediation-EncryptS3BucketVolume
      Automatic: true
      MaximumAutomaticAttempts: 3
      RetryAttemptSeconds: 60

Wzorce automatycznej naprawy (remediacji)

Istnieją dwie kanoniczne ścieżki naprawy, a wybór między nimi zależy od wymagań dotyczących opóźnień i złożoności.

Ścieżka natywnej naprawy w Config wykorzystuje AWS::Config::RemediationConfiguration do wywoływania runbooka SSM Automation za każdym razem, gdy reguła zgłosi stan NON_COMPLIANT. AWS dostarcza gotowe runbooki, takie jak AWS-EnableVPCFlowLogs, AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules i AWSConfigRemediation-EncryptSNSTopic. Ta ścieżka jest deklaratywna, dobrze integruje się z pakietami zgodności i jest idealna, gdy dopuszczalne jest kilkuminutowe opóźnienie.

Ścieżka oparta na EventBridge jest wymagana, gdy liczy się niskie opóźnienie lub potrzebna jest niestandardowa orkiestracja. Config emituje zdarzenie Config Rules Compliance Change przy każdej zmianie stanu. Reguła EventBridge filtruje zdarzenia na podstawie detail.newEvaluationResult.complianceType = NON_COMPLIANT i kieruje je do funkcji Lambda (lub Step Function, albo bezpośrednio do runbooka SSM). Ponieważ EventBridge uruchamia się w ciągu kilku sekund od oceny, możliwe stają się okna naprawcze poniżej jednej minuty.

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

Handler Lambda wywołuje następnie RevokeSecurityGroupIngress na problematycznej grupie bezpieczeństwa (SG). Niezależnie od wybranej ścieżki, automatyzacja musi przyjąć rolę IAM z minimalnymi uprawnieniami do modyfikacji docelowego zasobu. Częstym trybem awarii jest reguła Config, której status zgodności bez końca przełącza się między NON_COMPLIANT a COMPLIANT, ponieważ runbook naprawczy otrzymuje błąd AccessDenied — Config rejestruje wywołanie, ale po cichu kontynuuje działanie. Zawsze sprawdzaj historię wykonań SSM Automation i nadawaj roli runbooka konkretne uprawnienia modyfikujące, których potrzebuje (na przykład ec2:CreateFlowLogs, iam:PassRole dla roli dostarczającej logi przepływu oraz logs:CreateLogGroup).

SSM Automation i Patch Manager

Runbooki SSM Automation to „koń roboczy” imperatywnej naprawy. Są to wersjonowane dokumenty YAML/JSON opisujące kroki — wywołania API, zatwierdzenia, rozgałęzienia — wykonywane przez określoną przez Ciebie rolę IAM. Oprócz naprawy wyzwalanej przez Config, wykonują one zaplanowane zadania higieniczne: rotację kluczy dostępu, tagowanie niepodłączonych wolumenów EBS czy zamykanie zatrzymanych instancji po 30 dniach.

Patch Manager to podsystem SSM, który utrzymuje zgodność systemów operacyjnych z linią bazową poprawek (patch baseline) (zestawem zatwierdzonych poprawek, klasyfikacji i filtrów ważności). Instancje są grupowane w grupy poprawek (patch groups) za pomocą tagu Patch Group; okno konserwacyjne (maintenance window) planuje uruchomienie na nich dokumentu AWS-RunPatchBaseline. Status zgodności jest przekazywany z powrotem do Config i Security Hub, zamykając pętlę między stanem na poziomie systemu operacyjnego a raportowaniem organizacyjnym.

Service Catalog, CloudFormation StackSets i prewencyjne barierki ochronne (Guardrails)

Wykrywanie i naprawa mają charakter reaktywny. Aby zapobiegać niezgodnościom, użyj kontroli prewencyjnych:

Service Catalog publikuje wyselekcjonowane, sparametryzowane szablony CloudFormation jako produkty. Deweloperzy uruchamiają zatwierdzone wzorce (np. zabezpieczony VPC, zaszyfrowany klaster RDS) bez potrzeby posiadania uprawnień IAM do bazowych usług, co wymusza rozdział obowiązków między zespołem platformy a konsumentami.
CloudFormation StackSets wdrażają identyczne stosy na wielu kontach i w wielu regionach. Dzięki uprawnieniom zarządzanym przez usługę i targetowaniu na jednostki organizacyjne (OU), pojedyncza operacja instaluje rejestratory Config, role IAM lub detektory GuardDuty na każdym koncie w organizacji, włączając w to nowo utworzone konta dzięki automatycznemu wdrażaniu.
Service Control Policies (SCPs) to jedyny mechanizm, który może kategorycznie odrzucić wywołanie API na granicy organizacji. Config i SSM nie mogą zapobiec wywołaniu RunInstances bez szyfrowania — mogą jedynie wykryć to i naprawić po fakcie. Próba egzekwowania twardych zakazów („żadnych publicznych bucketów S3”) wyłącznie za pomocą reguł Config pozostawia okno czasowe między utworzeniem zasobu a jego naprawą. Połącz regułę wykrywającą Config z SCP, takim jak odmowa s3:PutBucketPublicAccessBlock, aby zlikwidować tę lukę.

Odzyskiwanie po awarii (Disaster Recovery): kopie zapasowe, szablony i kontrola źródła

Osiągnięcie celów RPO/RTO wymaga, aby zarówno dane, jak i definicje infrastruktury były odtwarzalne. AWS Backup centralizuje polityki tworzenia kopii zapasowych dla EBS, RDS, DynamoDB, EFS i FSx; polityki kopii zapasowych na poziomie organizacji wymuszają plany na kontach członkowskich, a kopie międzyregionalne i międzykontowe chronią przed utratą regionu i kompromitacją konta. RPO jest określane przez częstotliwość tworzenia kopii zapasowych; RTO zależy od mechaniki przywracania (przywracanie PITR w DynamoDB trwa minuty; przywracanie migawki RDS między regionami może zająć godzinę).

Odzyskiwanie infrastruktury opiera się na szablonach CloudFormation przechowywanych w CodeCommit (lub u innego dostawcy Git) jako jedynym źródle prawdy. Ponowne wdrożenie StackSet z szablonów objętych kontrolą wersji odbudowuje VPC, IAM i stosy aplikacji w regionie odzyskiwania w ciągu kilku minut. Przechowywanie szablonów wyłącznie w konsoli — bez repozytorium — sprawia, że RTO jest nieprzewidywalne, ponieważ brakuje powtarzalnego artefaktu.

Analiza pułapek

Trzy błędne przekonania konsekwentnie prowadzą do złych odpowiedzi. Po pierwsze, traktowanie Config jako kontroli prewencyjnej: ocenia on stan po zarejestrowaniu zmiany przez CloudTrail, więc prawdziwe zakazy wymagają SCP. Po drugie, konfigurowanie naprawy bez odpowiednio zakreskowanej roli IAM — dokument SSM istnieje, a reguła Config jest uruchamiana, ale runbook kończy się cichą porażką z powodu błędów uprawnień. Po trzecie, uruchamianie usług obejmujących całą organizację z konta zarządzającego zamiast rejestrowania delegowanego administratora, co wymusza ręczne włączanie na każdym koncie i blokuje poprawne działanie agregatorów na poziomie organizacji.

Problem praktyczny: scenariusz użycia

Scenariusz: Meridian Financial zarządza środowiskiem AWS z wieloma kontami, w tym osobnymi kontami produkcyjnymi, deweloperskimi i bezpieczeństwa w ramach AWS Organizations. Zespół ds. bezpieczeństwa musi udowodnić ciągłą zgodność z wewnętrznymi kontrolami i regulacjami, zarządzając setkami instancji EC2, bucketów S3 i funkcji Lambda w różnych regionach.

Wyzwanie: Niedawny audyt wykazał niezałatanie instancje EC2, publiczne buckety S3 i niespójne egzekwowanie bazowych standardów na różnych kontach; naprawa jest manualna i powolna, a kontrole prewencyjne nie są stosowane jednolicie.

Zalecane podejście:

Wyznacz konto Security jako delegowanego administratora AWS Config i wdróż AWS Config Aggregator za pomocą CloudFormation StackSets, aby zbierać dane o konfiguracji i zgodności ze wszystkich kont i regionów.
Wdróż pakiety zgodności AWS Config Conformance Packs na poziomie organizacji z konta Security (używając StackSets), aby skodyfikować bazowe kontrole (publiczny dostęp do S3, szyfrowanie, tagowanie), zapewniając spójne stosowanie tych samych reguł.
Dołącz automatyczne akcje naprawcze AWS Config do reguł wysokiego ryzyka, które wywołują dokumenty AWS Systems Manager Automation (zarejestrowane jako runbooki naprawcze), aby naruszenia automatycznie uruchamiały naprawę za pomocą SSM Automation lub Run Command.
Użyj AWS Systems Manager Patch Manager z SSM Patch Baselines i State Manager, aby zdefiniować grupy łatania i zautomatyzować łatanie systemów operacyjnych na wszystkich kontach; przekazuj wyniki zgodności łatania do Config Aggregator.
Publikuj zatwierdzone szablony CloudFormation w AWS Service Catalog i używaj CloudFormation StackSets do wdrażania lub aktualizowania zgodnych stosów; egzekwuj prewencyjne barierki ochronne (guardrails) za pomocą AWS Organizations Service Control Policies, aby blokować tworzenie niedozwolonych zasobów (na przykład wyłączając tworzenie publicznych bucketów S3).
Skonfiguruj Amazon EventBridge (CloudWatch Events) i SNS, aby powiadamiać zespół ds. bezpieczeństwa o niezgodnościach i uruchamiać dodatkowe przepływy pracy SSM Automation w przypadku złożonych incydentów.

Uzasadnienie: Centralizacja wykrywania za pomocą Config Aggregator i pakietów zgodności, automatyzacja naprawy poprzez SSM oraz egzekwowanie prewencyjnych barierek ochronnych (guardrails) za pomocą Service Catalog/StackSets i SCP zapewnia spójne, audytowalne kontrole i szybką naprawę, zgodnie z najlepszymi praktykami AWS w zakresie bezpieczeństwa, zgodności i zasady najmniejszych uprawnień.

← Bezpieczeństwo Edge i aplikacji · Wszystkie domeny · Podatności →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Zdaj egzamin →

Przeglądaj Amazon →