Amazon SCS-C02: Governance, Konfiguration und Automatisierung — Lernleitfaden

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

Teil des AWS Security Specialty SCS-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Service Control Policies und Guardrails auf Organisationsebene

Service Control Policies (SCPs) bilden die äußerste Grenze dessen, was ein Principal in einer AWS Organization tun kann. Eine SCP ist keine IAM-Richtlinie – sie gewährt nichts, sondern definiert lediglich die maximalen Berechtigungen, die für Konten unter einer OU oder der gesamten Organisation verfügbar sind. Ein Allow in einer IAM-Richtlinie, einer Ressourcenrichtlinie oder einer Permissions Boundary ist vollständig unwirksam, wenn eine SCP die Aktion verweigert. Genau diese Asymmetrie macht SCPs zum richtigen Werkzeug für organisationsweite Guardrails: Regionsbeschränkungen, gesperrte Services, Schutz zentral verwalteter IAM-Rollen und die Erzwingung von Verschlüsselung bei der Ressourcenerstellung.

Eine kanonische SCP, die die Erstellung unverschlüsselter DynamoDB-Tabellen und S3-Buckets verweigert, sieht wie folgt aus:

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"

Eine häufige Falle ist der Versuch, Regeln wie „Niemand in der Organisation darf us-east-2 verwenden“ oder „Niemand darf CloudTrail deaktivieren“ durch IAM-Richtlinien in jedem einzelnen Konto durchzusetzen. Selbst mit einer Permissions Boundary und abgestimmten Identitätsrichtlinien kann sich ein lokaler Administrator eine Hintertür schaffen. Nur auf eine SCP, die auf der Root-Ebene oder einer OU angewendet wird, ist Verlass, da sie selbst den Root-Benutzer von Mitgliedskonten einschränkt (mit der kleinen Ausnahme einer Handvoll nicht einschränkbarer Aktionen).

SCPs sollten auch Break-Glass- und delegierte Administrationsrollen schützen: Fügen Sie ein explizites Deny für jede Aktion hinzu, die auf eine Rolle wie OrganizationAccountAccessRole oder SecurityAudit abzielt, es sei denn, der aws:PrincipalArn des Aufrufers stimmt mit einer genehmigten Liste überein.

AWS Config, Conformance Packs und kontenübergreifende Durchsetzung

AWS Config bietet die kontinuierliche Auswertungsebene, die SCPs (die verhindern) durch Erkennung (die Abweichungen beobachtet und meldet) ergänzt. Ein Conformance Pack ist ein Bündel von Config-Regeln – sowohl verwaltete Regeln wie s3-bucket-server-side-encryption-enabled als auch benutzerdefinierte Regeln, die auf Lambda oder Guard basieren – verpackt als ein einziges, bereitstellbares YAML-Artefakt mit optionalen Korrekturmaßnahmen.

Um eine Standard-Baseline organisationsweit auszurollen, werden zwei Mechanismen kombiniert:

• CloudFormation StackSets aus dem Verwaltungskonto mit service-verwalteten Berechtigungen und AutoDeployment: Enabled, sodass jedes neue Konto, das der Organisation beitritt, automatisch einen Stack erhält, der den Config Recorder und den Delivery Channel aktiviert. Dies löst das Bootstrap-Problem: Ein Conformance Pack kann kein Konto auswerten, in dem Config nicht aktiviert ist.

• Conformance Packs, die vom delegierten Administratorkonto (z. B. security-01) mit PutOrganizationConformancePack bereitgestellt werden. Dadurch wird ein konsistenter Regelsatz an jedes aktuelle und zukünftige Konto verteilt, ohne dass jedes Konto manuell angefasst werden muss.

Das Muster des delegierten Administrators und Aggregators ist wichtig: Es ermöglicht dem Sicherheitsteam, die Compliance aller Konten an einem Ort einzusehen, während Anwendungsteams weiterhin die Möglichkeit haben, ihre eigenen Regeln lokal hinzuzufügen. Die Bereitstellung derselben Regeln direkt aus dem Verwaltungskonto würde zwar funktionieren, verstößt aber gegen das Prinzip der geringsten Rechte (Least Privilege) und verhindert Audits zur Funktionstrennung (Separation of Duties).

CloudFormation Guard, StackSets und Service Catalog

Prävention sollte nach links verlagert werden (Shift Left). CloudFormation Guard (cfn-guard) ist eine Policy-as-Code-Engine, die CloudFormation-Vorlagen (oder beliebiges JSON/YAML) parst und sie vor der Bereitstellung anhand deklarativer Regeln auswertet. Eine Guard-Regel sieht wie folgt aus:

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

Die Einbindung in eine CI/CD-Stufe – typischerweise als Docker-Container-Schritt, der cfn-guard validate -r rules.guard -d template.yaml ausführt – lässt die Pipeline fehlschlagen, bevor eine nicht konforme Ressource erstellt wird. Bei einem Verstoß veröffentlicht die Pipeline in einem SNS-Thema, das das Sicherheitsteam abonniert hat. Dies gibt ihnen Transparenz, ohne dass sie zu einem manuellen Genehmigungs-Engpass werden. Sich allein auf StackSets oder die Überprüfung von CloudFormation Change Sets zu verlassen, um das Sicherheitsteam zu benachrichtigen, ist eine Falle: Keiner der beiden Dienste gibt Compliance-Ergebnisse pro Ressource aus, und zum Zeitpunkt der Erstellung eines Stacks existiert die Ressource bereits im Konto.

Service Catalog ergänzt Guard auf der letzten Meile. Anstatt Entwicklern zu erlauben, beliebige CloudFormation-Vorlagen zu schreiben, veröffentlicht das Plattformteam geprüfte Produkte (VPC-Baselines, RDS-Muster, EKS-Cluster) als Service Catalog-Portfolios, die über AWS RAM kontenübergreifend geteilt werden. Entwickler starten diese mit eingeschränkten Parametern, und eine IAM-Rolle mit Start-Einschränkung (Launch Constraint) provisioniert Ressourcen mit erweiterten Berechtigungen, die der Entwickler selbst nicht besitzt. Dies ermöglicht ein auditierbares Self-Service-Bereitstellungsmodell, bei dem die zugrunde liegende Vorlage bereits die Guard-Prüfungen bestanden hat.

StackSets selbst benötigen eine korrekte Konfiguration: Verwenden Sie das SERVICE_MANAGED-Berechtigungsmodell bei der Bereitstellung aus dem Organisations-Verwaltungskonto, aktivieren Sie den vertrauenswürdigen Zugriff (Trusted Access) für CloudFormation in Organizations und konfigurieren Sie die Ausführungsrollen sorgfältig. Das AdministrationRoleARN/ExecutionRoleName-Paar (im selbstverwalteten Modus) oder die serviceverknüpften Rollen (im service-verwalteten Modus) müssen die Berechtigung iam:PassRole für die CloudFormation-Servicerolle haben, die tatsächlich die Ressourcen erstellt. Wenn man vergisst, eine CloudFormation-Servicerolle anzuhängen und sich stattdessen auf die Anmeldeinformationen des bereitstellenden Benutzers verlässt, führt dies zu sporadischen AccessDenied-Fehlern bei iam:PassRole – eine häufige Ursache für fehlgeschlagene StackSet-Operationen. Das korrekte Muster ist eine dedizierte Servicerolle pro Stack, die nur die Berechtigungen besitzt, die zur Erstellung der deklarierten Ressourcentypen erforderlich sind.

Automatisierte Behebungs-Pipelines

Wenn Config eine Nichtkonformität feststellt, muss die Behebung für alles, was sicher selbst repariert werden kann, automatisch erfolgen. Der Ereignisfluss ist wie folgt:

• Config veröffentlicht ein Compliance Change-Ereignis im Standard-Event-Bus.

• Eine EventBridge-Regel filtert nach NON_COMPLIANT-Ergebnissen für bestimmte Regeln und leitet diese entweder an ein Systems Manager Automation-Dokument (für einfache, idempotente Korrekturen wie die Aktivierung der S3-Verschlüsselung), eine Lambda-Funktion (für Korrekturen auf API-Ebene) oder eine Step Functions State Machine (für mehrstufige Workflows, die Genehmigungen, Wiederholungsversuche oder eine dienstübergreifende Orchestrierung erfordern) weiter.

Wenn beispielsweise s3-bucket-public-read-prohibited ausgelöst wird, behebt ein SSM Automation Runbook AWS-DisableS3BucketPublicReadWrite das Problem. Für komplexere Abläufe – beispielsweise eine KMS-Schlüsselrichtlinie, die abweicht und abgeglichen werden muss, während das zuständige Team benachrichtigt wird – koordiniert Step Functions die Schritte: Lesen der aktuellen Richtlinie, Vergleich mit der Golden-Version, Aufruf von kms:PutKeyPolicy und anschließende Veröffentlichung in SNS. Die Speicherung der Behebungslogik in Step Functions anstelle einer einzelnen Lambda-Funktion bietet Einblick in jeden Schritt und eine saubere Wiederholungssemantik.

IAM Access Analyzer und Richtlinienvalidierung

IAM Access Analyzer beantwortet zwei verschiedene Fragen. Erstens identifizieren externe Zugriffsanalysatoren Ressourcen (S3, KMS, IAM-Rollen, Lambda, SQS, Secrets Manager), deren Richtlinien Zugriff für Prinzipale außerhalb einer definierten Vertrauenszone gewähren – entweder des Kontos oder der Organisation. Aktivieren Sie den Analysator auf Organisationsebene vom delegierten Administratorkonto aus, damit die Ergebnisse zentral zusammengefasst werden.

Zweitens werden die Richtlinienvalidierung (policy validation) und Richtliniengenerierung (policy generation) von Access Analyzer während der Erstellung ausgeführt. aws accessanalyzer validate-policy gibt Sicherheitswarnungen, Fehler und Vorschläge zurück (z. B. das Markieren von zu weitreichenden Resource: "*" in Kombination mit sensiblen Aktionen). Integrieren Sie dies in dieselbe CI/CD-Stufe wie cfn-guard, damit in CloudFormation eingebettete IAM-Richtlinien vor der Bereitstellung überprüft werden. Access Analyzer kann auch eine Richtlinie mit den geringsten Rechten (Least-Privilege-Policy) aus dem CloudTrail-Verlauf generieren. Dabei wird eine Wildcard-Richtlinie durch die exakten Aktionen ersetzt, die eine Rolle tatsächlich verwendet hat – die mechanische Antwort auf die Anforderung, „geringste Rechte für den Datenzugriff durchzusetzen“, ergänzt durch eine bereichsbezogene KMS-Schlüsselrichtlinie, die kms:Decrypt nur dann erlaubt, wenn der aufrufende Dienst S3, DynamoDB, Lambda oder EKS ist, was über kms:ViaService-Bedingungen gesteuert wird.

Praktisches Problem: Anwendungsfallszenario

Szenario: Meridian Financial betreibt eine AWS Organization mit mehreren Konten, die Produktions-, Staging-, Sandbox- und ein zentrales Sicherheitskonto umfasst. Sie stellen Workloads mit einer Mischung aus CloudFormation-Vorlagen und von Entwicklern erstellten Vorlagen in der Sandbox bereit. Die Zuständigkeit ist auf verschiedene Teams verteilt, und sie müssen interne Governance-Vorgaben für Datenverschlüsselung und den Zugriff mit geringsten Rechten (Least-Privilege) erfüllen.

Herausforderung: Entwickler in der Sandbox haben versehentlich öffentliche S3-Buckets und zu freizügige IAM-Richtlinien erstellt, die sich auf andere Konten ausgebreitet haben. Dem Sicherheitsteam fehlt eine konsistente, automatisierte Durchsetzung und Vorlagenvalidierung über die gesamte Organisation hinweg.

Empfohlener Ansatz:

1. Erstellen Sie Service Control Policies (SCPs) auf Organisationsebene, um öffentlichen S3-Zugriff zu verweigern, die Bucket-Verschlüsselung zu erzwingen und privilegierte IAM-Aktionen auf der Stammebene der Organisation einzuschränken, um präventive Leitplanken zu schaffen.
2. Stellen Sie vom zentralen Sicherheitskonto aus einen AWS Config Aggregator und Conformance Packs mithilfe von CloudFormation StackSets in jedem Konto und jeder Region bereit, um den öffentlichen S3-Zugriff, Muster bei der Zuweisung von IAM-Richtlinien und die Einhaltung der Verschlüsselungsvorgaben kontinuierlich zu bewerten.
3. Integrieren Sie CloudFormation Guard (cfn-guard)-Regeln in die CI/CD-Pipeline (CodePipeline/CodeBuild) und schreiben Sie die Verwendung von Service Catalog-Produkten für genehmigte Infrastruktur vor, damit Vorlagen validiert und nur konforme Stacks bereitgestellt werden können.
4. Aktivieren Sie die automatisierte Behebung durch AWS Config mit SSM Automation-Dokumenten oder Lambda-Runbooks für Ergebnisse mit hoher Priorität (automatisches Blockieren von öffentlichem S3-Zugriff, Beheben zu weitreichender IAM-Richtlinien) und lösen Sie zusätzliche Workflows über EventBridge aus.
5. Führen Sie IAM Access Analyzer und die Richtlinienvalidierung zentral aus, nehmen Sie die Ergebnisse in Security Hub auf und automatisieren Sie die Ticketerstellung oder die Ausführung von Behebungs-Playbooks für entdeckte kontoübergreifende oder zu freizügige Richtlinien.

Begründung: Dieser Ansatz kombiniert präventive, organisationsweite Leitplanken (SCPs), kontinuierliche Erkennung (Config/Conformance Packs), nach links verlagerte Vorlagenvalidierung (Shift-Left, cfn-guard/Service Catalog) und automatisierte Behebung mit IAM Access Analyzer, um das Prinzip der geringsten Rechte durchzusetzen und eine konsistente Governance über mehrere Konten gemäß den AWS Best Practices zu erreichen.

AWS Config: Organisationsregeln, Aggregatoren und delegierte Administration

AWS Config ist die Grundlage für die detektivische Compliance (Compliance-Überwachung) auf AWS. Der Dienst zeichnet kontinuierlich Ressourcenkonfigurationen auf und bewertet sie anhand von Regeln – entweder von AWS verwalteten (z. B. restricted-ssh, vpc-flow-logs-enabled, encrypted-volumes) oder benutzerdefinierten (gestützt durch Lambda oder Guard). Im Unternehmensmaßstab sind drei Architekturentscheidungen wichtiger als die Regeln selbst: wie Regeln bereitgestellt werden, wie Ergebnisse aggregiert werden und wer für die Werkzeuge verantwortlich ist.

Für Multi-Account- und Multi-Region-Deployments unter AWS Organizations ist das korrekte Muster, ein delegiertes Administratorkonto (typischerweise das Sicherheits- oder Audit-Konto, nicht das Verwaltungskonto) über aws organizations register-delegated-administrator --service-principal=config-multiaccountsetup.amazonaws.com zu bestimmen. Von diesem Konto aus verwenden Sie PutOrganizationConfigRule oder PutOrganizationConformancePack, um Regeln an jedes Mitgliedskonto und jede Region zu verteilen. Das Überspringen der delegierten Administration zwingt Sie dazu, Config in jedem Konto manuell zu aktivieren oder alles vom Verwaltungskonto aus auszuführen – letzteres verstößt gegen das Prinzip der Funktionstrennung (Separation of Duties) und ersteres skaliert nicht über eine Handvoll Konten hinaus.

Organisationsregeln verteilen eine einzelne Regeldefinition; Aggregatoren sammeln die resultierenden Auswertungen. Erstellen Sie einen Aggregator im delegierten Administratorkonto mit einer OrganizationAggregationSource, die alle Konten und Regionen abdeckt. Das Aggregator-Dashboard beantwortet dann Fragen wie „Welchen VPCs in 200 Konten fehlen Flow Logs?“, ohne dass man mit kontoübergreifenden Rollen jonglieren muss. Beachten Sie, dass Aggregatoren schreibgeschützt sind: Sie zeigen den Compliance-Status an, führen aber selbst keine Behebungsmaßnahmen durch.

Conformance Packs zur Durchsetzung von Baselines

Ein Conformance Pack bündelt Config-Regeln und deren Behebungsmaßnahmen in einer einzigen YAML-Vorlage. AWS liefert Pakete, die auf Frameworks wie PCI DSS, HIPAA, NIST 800-53 und CIS abgestimmt sind. Die Bereitstellung eines Organisations-Conformance-Packs vom delegierten Administrator aus zielt auf bestimmte OUs ab – zum Beispiel, um ein strengeres Paket auf die Prod-OU als auf die Sandbox-OU anzuwenden. Dies ist die effizienteste Methode, um eine konsistente Baseline über Hunderte von Konten hinweg durchzusetzen, da ein einziger API-Aufruf das Regelwerk und seine Behebungs-Verkabelung auf einmal überall verbreitet.

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

Automatische Behebungsmuster

Es gibt zwei kanonische Behebungspfade, und die Wahl zwischen ihnen hängt von den Anforderungen an Latenz und Komplexität ab.

Der Pfad der Config-nativen Behebung verwendet AWS::Config::RemediationConfiguration, um ein SSM Automation Runbook aufzurufen, wann immer eine Regel NON_COMPLIANT meldet. AWS stellt vorgefertigte Runbooks wie AWS-EnableVPCFlowLogs, AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules und AWSConfigRemediation-EncryptSNSTopic zur Verfügung. Dieser Pfad ist deklarativ, lässt sich sauber in Conformance Packs integrieren und ist ideal, wenn eine Verzögerung von mehreren Minuten akzeptabel ist.

Der EventBridge-gesteuerte Pfad ist erforderlich, wenn die Latenz eine Rolle spielt oder wenn eine benutzerdefinierte Orchestrierung benötigt wird. Config gibt bei jedem Zustandsübergang ein Config Rules Compliance Change-Ereignis aus. Eine EventBridge-Regel filtert nach detail.newEvaluationResult.complianceType = NON_COMPLIANT und zielt auf eine Lambda-Funktion (oder Step Function oder direkt ein SSM Runbook). Da EventBridge innerhalb von Sekunden nach der Auswertung auslöst, werden Behebungsfenster von unter einer Minute realisierbar.

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

Der Lambda-Handler ruft dann RevokeSecurityGroupIngress für die beanstandete SG auf. Welchen Pfad Sie auch wählen, die Automatisierung muss eine IAM-Rolle mit den minimalen Berechtigungen übernehmen, um die Zielressource zu ändern. Ein häufiger Fehlermodus ist eine Config-Regel, deren Compliance-Status unendlich zwischen NON_COMPLIANT und COMPLIANT hin- und herwechselt, weil das Behebungs-Runbook mit einem AccessDenied-Fehler abbricht – Config zeichnet den Aufruf auf, fährt aber stillschweigend fort. Überprüfen Sie immer den Ausführungsverlauf von SSM Automation und gewähren Sie der Runbook-Rolle die spezifischen verändernden Berechtigungen, die sie benötigt (z. B. ec2:CreateFlowLogs, iam:PassRole für die Flow-Log-Bereitstellungsrolle und logs:CreateLogGroup).

Systems Manager Automation und Patch Manager

SSM Automation Runbooks sind das Arbeitspferd für imperative Behebungsmaßnahmen. Es handelt sich um versionierte YAML/JSON-Dokumente, die Schritte beschreiben – API-Aufrufe, Genehmigungen, Verzweigungen –, die von einer von Ihnen angegebenen IAM-Rolle ausgeführt werden. Über die von Config ausgelöste Behebung hinaus führen sie geplante Hygieneaufgaben aus: Rotation von Zugriffsschlüsseln, Taggen von nicht angehängten EBS-Volumes oder Beenden von gestoppten Instanzen nach 30 Tagen.

Patch Manager ist ein Subsystem von SSM, das Betriebssysteme konform zu einer Patch-Baseline hält (ein Satz von genehmigten Patches, Klassifizierungen und Schweregradfiltern). Instanzen werden über den Patch Group-Tag in Patch-Gruppen eingeteilt; ein Wartungsfenster plant die Ausführung des AWS-RunPatchBaseline-Dokuments für sie. Der Compliance-Status fließt zurück in Config und Security Hub und schließt so den Kreis zwischen dem Zustand auf Betriebssystemebene und dem organisationsweiten Reporting.

Service Catalog, CloudFormation StackSets und präventive Guardrails

Erkennung und Behebung sind reaktiv. Um Nichtkonformität zu verhindern, verwenden Sie präventive Kontrollen:

• Service Catalog veröffentlicht kuratierte, parametrisierte CloudFormation-Templates als Produkte. Entwickler starten genehmigte Muster (eine gehärtete VPC, ein verschlüsselter RDS-Cluster), ohne IAM-Berechtigungen für die zugrunde liegenden Dienste zu benötigen, was die Trennung der Zuständigkeiten zwischen dem Plattformteam und den Nutzern durchsetzt.

• CloudFormation StackSets stellen identische Stacks über Konten und Regionen hinweg bereit. Mit dienstverwalteten Berechtigungen und OU-Targeting bringt ein einziger Vorgang Config-Rekorder, IAM-Rollen oder GuardDuty-Detektoren in jedes Konto der Organisation, einschließlich neu erstellter Konten durch automatische Bereitstellung.

• Service Control Policies (SCPs) sind der einzige Mechanismus, der einen API-Aufruf an der Organisationsgrenze direkt verweigern kann. Config und SSM können einen RunInstances-Aufruf ohne Verschlüsselung nicht verhindern – sie können ihn nur nachträglich erkennen und beheben. Der Versuch, strikte Verbote („niemals öffentliche S3-Buckets“) ausschließlich mit Config-Regeln durchzusetzen, hinterlässt ein Zeitfenster zwischen der Erstellung der Ressource und der Behebung. Kombinieren Sie eine detektivische Config-Regel mit einer SCP, wie z. B. der Verweigerung von s3:PutBucketPublicAccessBlock, um diese Lücke zu schließen.

Disaster Recovery: Backup, Vorlagen und Quellcodeverwaltung

Das Erreichen von RPO/RTO-Zielen erfordert, dass sowohl Daten- als auch Infrastrukturdefinitionen wiederherstellbar sind. AWS Backup zentralisiert Backup-Richtlinien für EBS, RDS, DynamoDB, EFS und FSx; Organisations-Backup-Richtlinien setzen Pläne über Mitgliedskonten hinweg durch, und regions- sowie kontoübergreifende Kopien schützen vor dem Verlust einer Region und der Kompromittierung eines Kontos. Der RPO wird durch die Backup-Frequenz bestimmt; der RTO hängt von den Wiederherstellungsmechanismen ab (eine DynamoDB-PITR-Wiederherstellung dauert Minuten; eine RDS-Snapshot-Wiederherstellung über Regionen hinweg kann eine Stunde dauern).

Die Wiederherstellung der Infrastruktur basiert auf CloudFormation-Templates, die in CodeCommit (oder einem anderen Git-Anbieter) als Single Source of Truth gespeichert sind. Die erneute Bereitstellung eines StackSets aus versionierten Vorlagen baut VPCs, IAM und Anwendungs-Stacks in einer Wiederherstellungsregion in wenigen Minuten wieder auf. Wenn Vorlagen nur in der Konsole – ohne ein Repo – aufbewahrt werden, wird der RTO unvorhersehbar, da es kein reproduzierbares Artefakt gibt.

Fallenanalyse

Drei Missverständnisse führen immer wieder zu falschen Antworten. Erstens, Config als präventive Kontrolle zu betrachten: Es wertet aus, nachdem CloudTrail die Änderung aufgezeichnet hat, daher erfordern echte Verbote SCPs. Zweitens, die Einrichtung einer Behebung ohne eine ausreichend berechtigte IAM-Rolle – das SSM-Dokument existiert und die Config-Regel wird ausgelöst, aber das Runbook schlägt stillschweigend aufgrund von Berechtigungsfehlern fehl. Drittens, organisationsweite Dienste vom Verwaltungskonto auszuführen, anstatt einen delegierten Administrator zu registrieren, was eine manuelle Aktivierung pro Konto erzwingt und das korrekte Funktionieren von organisationsweiten Aggregatoren blockiert.

Praktisches Problem: Anwendungsfallszenario

Szenario: Meridian Financial betreibt eine AWS-Umgebung mit mehreren Konten, mit getrennten Produktions-, Entwicklungs- und Sicherheitskonten unter AWS Organizations. Das Sicherheitsteam muss die kontinuierliche Einhaltung interner Kontrollen und regulatorischer Vorgaben nachweisen und dabei Hunderte von EC2-Instanzen, S3-Buckets und Lambda-Funktionen über verschiedene Regionen hinweg verwalten.

Herausforderung: Eine kürzlich durchgeführte Prüfung ergab ungepatchte EC2-Instanzen, öffentliche S3-Buckets und eine inkonsistente Durchsetzung von Baselines über die Konten hinweg; die Behebung erfolgt manuell und langsam, und präventive Kontrollen werden nicht einheitlich angewendet.

Empfohlener Ansatz:

1. Das Sicherheitskonto als delegierten Administrator für AWS Config festlegen und einen AWS Config Aggregator über CloudFormation StackSets bereitstellen, um Konfigurations- und Konformitätsdaten aus allen Konten und Regionen zu sammeln.
2. Organisationsweite AWS Config Conformance Packs vom Sicherheitskonto aus (mithilfe von StackSets) bereitstellen, um Baseline-Kontrollen (öffentlicher S3-Zugriff, Verschlüsselung, Tagging) zu kodifizieren, sodass dieselben Regeln konsistent angewendet werden.
3. Automatische Behebungsaktionen von AWS Config an Regeln mit hohem Risiko anhängen, die AWS Systems Manager Automation-Dokumente (als Behebungs-Runbooks registriert) aufrufen, sodass Verstöße automatisch eine SSM Automation- oder Run Command-Behebung auslösen.
4. AWS Systems Manager Patch Manager mit SSM Patch Baselines und State Manager verwenden, um Patch-Gruppen zu definieren und das Patchen von Betriebssystemen kontoübergreifend zu automatisieren; die Ergebnisse der Patch-Konformität in den Config Aggregator einspeisen.
5. Genehmigte CloudFormation-Templates in AWS Service Catalog veröffentlichen und CloudFormation StackSets verwenden, um konforme Stacks bereitzustellen oder zu aktualisieren; präventive Guardrails mit AWS Organizations Service Control Policies durchsetzen, um die Erstellung unzulässiger Ressourcen zu blockieren (z. B. die Erstellung öffentlicher S3-Buckets deaktivieren).
6. Amazon EventBridge (CloudWatch Events) und SNS konfigurieren, um das Sicherheitsteam bei Nichtkonformität zu benachrichtigen und zusätzliche SSM Automation-Workflows für komplexe Vorfälle auszulösen.

Begründung: Die Zentralisierung der Erkennung mit dem Config Aggregator und Conformance Packs, die Automatisierung der Behebung durch SSM und die Durchsetzung präventiver Guardrails über Service Catalog/StackSets und SCPs bieten konsistente, prüfbare Kontrollen und eine schnelle Behebung im Einklang mit den AWS Best Practices für Sicherheit, Compliance und das Prinzip der geringsten Rechte (Least Privilege).

← Edge- und Anwendungssicherheit · Alle Domänen · Schwachstellen →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →