Handbuch

Eine potenziell kompromittierte EC2-Instance in einer Auto Scaling-Gruppe erfordert eine Untersuchung mit minimaler Unterbrechung.

→Aus der ELB-Zielgruppe deregistrieren, aus der Auto Scaling-Gruppe entfernen und eine restriktive "forensische" Sicherheitsgruppe anwenden, die den gesamten Datenverkehr außer dem Zugriff der forensischen Workstation verweigert.

Warum: Dies isoliert die Instance vom Netzwerk, während ihr flüchtiger Zustand (Speicher, laufende Prozesse) für die forensische Analyse erhalten bleibt. Eine sofortige Beendigung zerstört Beweismittel.

Einen mehrstufigen Incident-Response-Workflow (z. B. Snapshot, Isolation, Benachrichtigung), ausgelöst durch einen GuardDuty-Befund, automatisieren.

→Eine EventBridge-Regel verwenden, um den spezifischen Befund zu erfassen und eine AWS Step Functions-Zustandsmaschine auszulösen. Die Zustandsmaschine orchestriert die Abfolge der Aktionen mit Fehlerbehandlung und Wiederholungslogik.

Warum: Step Functions bieten eine robuste Orchestrierung für mehrstufige Workflows, die Zuverlässigkeit und Zustandsverwaltung gewährleistet, was einer einzelnen monolithischen Lambda-Funktion überlegen ist.

Laufzeitbedrohungen (z. B. Cryptomining, Privilege Escalation) in laufenden ECS Fargate- oder EC2-Containern ohne Bereitstellung von Sidecar-Agenten erkennen.

→Amazon GuardDuty ECS Runtime Monitoring aktivieren. Für EC2 den GuardDuty-Sicherheitsagenten als DaemonSet bereitstellen. Für Fargate die automatische Agentenkonfiguration verwenden.

Warum: Dies bietet eine agentenlose (für Fargate) oder zentral verwaltete (für EC2) Laufzeit-Bedrohungserkennung, die das Verhalten innerhalb von Containern erfasst, ohne Anwendungsaufgaben zu ändern.

Referenz↗

Einen spezifischen AWS Security Hub-Befund, wie z. B. einen öffentlich zugänglichen S3-Bucket, automatisch beheben.

→Eine EventBridge-Regel erstellen, die dem spezifischen Befundtyp (z. B. `S3.1`) entspricht und eine Lambda-Funktion oder ein SSM Automation-Dokument zur Behebung auslöst.

Warum: Dies ist das native, ereignisgesteuerte Muster für die automatisierte Security Hub-Reaktion, das eine nahezu Echtzeit- und zielgerichtete Behebung bietet.

Ein IAM-Zugriffsschlüssel wurde öffentlich zugänglich. Den Vorfall eindämmen und den potenziellen Schadenbereich bewerten.

→1. Den exponierten Zugriffsschlüssel deaktivieren. 2. Eine "deny-all"-Inline-Richtlinie an den Benutzer/die Rolle anhängen, um aktive STS-Sitzungen zu entwerten. 3. CloudTrail-Protokolle auf alle mit dem Schlüssel getätigten API-Aufrufe überprüfen. 4. Alle nicht autorisierten Ressourcen oder IAM-Principals, die vom Angreifer erstellt wurden, entfernen.

Warum: Die Deaktivierung des Schlüssels verhindert die zukünftige Verwendung. Die "deny-all"-Richtlinie ist entscheidend, um aktive Sitzungen zu widerrufen, die *vor* der Deaktivierung des Schlüssels erstellt wurden. CloudTrail bietet den Audit-Trail für die Schadensbewertung.

GuardDuty-Bedrohungserkennung mit unternehmens- oder branchenspezifischen Bedrohungsdaten-Feeds verbessern.

→Eine Klartextdatei mit bösartigen IP-Adressen/CIDRs in S3 hochladen. Ein neues Threat Intel Set in GuardDuty erstellen und aktivieren, das auf die S3-Datei verweist.

Warum: Dies ermöglicht es, die verwaltete Bedrohungsintelligenz von GuardDuty mit benutzerdefinierten IOCs zu erweitern und Befunde zu generieren, wenn Ihre Ressourcen mit diesen angegebenen IPs kommunizieren.

EC2-Instances mit über spezifische Ports offenen Netzwerkpfaden zum Internet identifizieren, unter Berücksichtigung aller Netzwerkkonfigurationen.

→Amazon Inspector aktivieren und seine Befunde zur Netzwerkerreichbarkeit überprüfen.

Warum: Inspector führt eine vollständige Netzwerkpfadanalyse von IGWs zu Instances durch und bewertet Sicherheitsgruppen, NACLs und Routing-Tabellen, um die tatsächliche Erreichbarkeit zu bestimmen. Dies ist genauer als nur die Überprüfung einzelner Sicherheitsgruppenregeln.

Den vollständigen Umfang eines Sicherheitsbefunds untersuchen und alle zugehörigen Entitäten sowie das historische Verhalten visualisieren.

→Amazon Detective verwenden. Zum Entitätsprofil (z. B. für eine EC2-Instance oder IAM-Rolle) navigieren, um den Verhaltensgraphen und die Zeitleiste der zugehörigen API-Aufrufe, Netzwerkverbindungen und GuardDuty-Befunde anzuzeigen.

Warum: Detective korreliert automatisch Protokolle von CloudTrail, VPC Flow Logs und GuardDuty und bietet eine kontextbezogene Analyse, die die Ursachenermittlung im Vergleich zur manuellen Protokollkorrelation erheblich beschleunigt.

Audit-Protokolle (z. B. CloudTrail, VPC Flow Logs) zur langfristigen Aufbewahrung manipulationssicher und abfragbar speichern, um Compliance-Anforderungen zu erfüllen.

→Protokolle an einen S3-Bucket mit aktiviertem S3 Object Lock im Compliance-Modus liefern. Amazon Athena zum Abfragen verwenden.

Warum: Object Lock im Compliance-Modus verhindert das Löschen oder Ändern durch jedermann, einschließlich des Root-Benutzers, und gewährleistet die Unveränderlichkeit der Protokolle. Athena bietet Ad-hoc-SQL-Abfragemöglichkeiten für die gespeicherten Protokolle.

Referenz↗

Alle Management- und Datenereignisse für eine gesamte AWS Organisation zentral erfassen.

→Im Management-Konto einen CloudTrail Organisation Trail erstellen. Um Daten auf Objektebene zu erfassen, erweiterte Ereignis-Selektoren verwenden, um spezifische Ereignistypen (z. B. S3 PutObject, Lambda Invoke) für wertvolle Ressourcen zu protokollieren.

Warum: Ein Organisation Trail protokolliert Ereignisse automatisch für alle Mitgliedskonten. Erweiterte Ereignis-Selektoren sind entscheidend für die kostengünstige Protokollierung von datenintensiven Ereignissen, indem nur die notwendigen Ressourcen angesprochen werden.

Komplexe, SQL-basierte Analysen von CloudTrail-Ereignissen der gesamten Organisation über mehrere Jahre hinweg durchführen.

→AWS CloudTrail Lake aktivieren und einen Event Data Store auf Organisationsebene mit der erforderlichen Aufbewahrungsdauer (bis zu 7 Jahre) erstellen. Den integrierten SQL-Abfrageeditor für die Analyse verwenden.

Warum: CloudTrail Lake bietet einen verwalteten, unveränderlichen Datenspeicher und eine Abfrage-Engine, die speziell für CloudTrail-Ereignisse entwickelt wurde, wodurch die Notwendigkeit entfällt, S3, Glue und Athena für die Protokollanalyse zu verwalten.

Alle DNS-Abfragen von Ressourcen innerhalb einer VPC zur Bedrohungssuche oder Fehlerbehebung überwachen.

→Route 53 Resolver DNS Query Logging aktivieren und konfigurieren, um Protokolle an CloudWatch Logs, S3 oder Kinesis Data Firehose zu senden.

Warum: Dies bietet detaillierte Einblicke in die DNS-Auflösungsaktivitäten innerhalb Ihrer VPCs, indem die abgefragte Domain, die Quell-Instance und die Antwort erfasst werden, was für die Erkennung DNS-basierter Bedrohungen entscheidend ist.

Sicherheitsprotokolle aus verschiedenen AWS- und Drittanbieterquellen in einem Data Lake mithilfe eines Standardschemas zentralisieren und normalisieren.

→Amazon Security Lake bereitstellen. Es sammelt und normalisiert Daten automatisch in das Open Cybersecurity Schema Framework (OCSF) und speichert sie im Parquet-Format in S3.

Warum: Security Lake automatisiert die Erstellung und Verwaltung eines Sicherheits-Data-Lakes und reduziert den Betriebsaufwand für den Aufbau benutzerdefinierter ETL-Pipelines zur Normalisierung.

Die Sammlung von Nachweisen für Compliance-Audits gemäß Frameworks wie SOC 2, PCI DSS oder HIPAA automatisieren.

→AWS Audit Manager verwenden. Ein vorgefertigtes Framework auswählen, das automatisch Nachweise von AWS-Diensten (CloudTrail, Config, Security Hub) sammelt und diese spezifischen Compliance-Kontrollen zuordnet.

Warum: Audit Manager automatisiert und zentralisiert den Nachweissammlungsprozess, wodurch der manuelle Aufwand für die Vorbereitung und Durchführung von Compliance-Audits erheblich reduziert wird.

Sensible Daten (PII, PHI, Finanzdaten) in allen S3-Buckets automatisch entdecken und klassifizieren.

→Amazon Macie aktivieren und automatisierte Aufträge zur Erkennung sensibler Daten konfigurieren. Verwaltete Daten-Identifikatoren für gängige Datentypen verwenden und benutzerdefinierte Daten-Identifikatoren für proprietäre Formate erstellen.

Warum: Macie bietet eine verwaltete, skalierbare Lösung für die S3-Datenklassifizierung. Um Befunde für bekannte nicht-sensible Daten (z. B. Testdaten) zu unterdrücken, Macie-Zulassungslisten verwenden.

Mehrere Sicherheitskontrollen für einen S3-Bucket durchsetzen, z. B. SSE-KMS mit einem bestimmten Schlüssel erforderlich machen und HTTP-Anfragen verweigern.

→Eine Bucket-Richtlinie mit mehreren `Deny`-Anweisungen und Bedingungsschlüsseln verwenden: `aws:SecureTransport: false`, `s3:x-amz-server-side-encryption: "aws:kms"` und `s3:x-amz-server-side-encryption-aws-kms-key-id: "key-arn"`.

Warum: Bucket-Richtlinien bieten eine feingranulare Steuerung auf Ressourcenebene. Die Verwendung mehrerer Bedingungsschlüssel in Deny-Anweisungen ist der Standardweg, um eine mehrschichtige Sicherheitslage für einen Bucket durchzusetzen.

Sicherstellen, dass alle neuen EBS-Volumes organisationsweit mit einem spezifischen kundenverwalteten KMS-Schlüssel verschlüsselt werden.

→EBS-Verschlüsselung standardmäßig in den Kontoeinstellungen für jede Region aktivieren und den CMK angeben. Eine SCP anwenden, die `ec2:CreateVolume` verweigert, wenn der `encrypted`-Parameter `false` ist, als präventive Schutzbarriere.

Warum: Die Standardeinstellung bietet Komfort, während die SCP eine harte Durchsetzungs-Schutzbarriere bietet, die einen Defense-in-Depth-Ansatz für die Datenruhe-Verschlüsselung für EBS schafft.

Große (> 4KB) Datenobjekte mit AWS KMS verschlüsseln.

→Umschlagverschlüsselung verwenden. `KMS:GenerateDataKey` aufrufen, um einen Klartext-Datenschlüssel und einen verschlüsselten Datenschlüssel zu erhalten. Den Klartextschlüssel verwenden, um das große Objekt lokal zu verschlüsseln. Das verschlüsselte Objekt und den verschlüsselten Datenschlüssel zusammen speichern. Den Klartextschlüssel verwerfen.

Warum: Die KMS Encrypt API hat eine 4KB-Grenze. Die Umschlagverschlüsselung ermöglicht die Verschlüsselung von Daten beliebiger Größe, während der kleine Datenschlüssel durch KMS geschützt wird, was Kosten und Latenz im Vergleich zum Streaming von Daten durch KMS reduziert.

Referenz↗

Denselben Verschlüsselungsschlüssel über mehrere AWS-Regionen hinweg für Disaster Recovery oder globale Anwendungskonsistenz verwenden.

→Einen KMS Multi-Region Primärschlüssel in einer Region erstellen und Replika-Schlüssel in anderen Regionen erstellen. Daten, die mit einem Schlüssel in einer Region verschlüsselt wurden, können mit dem Replika in einer anderen entschlüsselt werden.

Warum: Multi-Region-Schlüssel teilen dasselbe Schlüsselmaterial und dieselbe Schlüssel-ID, was die regionsübergreifende Datenportabilität ohne regionsübergreifende API-Aufrufe zur Entschlüsselung ermöglicht.

Anmeldeinformationen (z. B. Datenbankpasswörter, API-Schlüssel), die von Anwendungen verwendet werden, sicher speichern und automatisch rotieren lassen.

→Anmeldeinformationen in AWS Secrets Manager speichern. Automatische Rotation mit einer benutzerdefinierten oder von AWS bereitgestellten Lambda-Rotationsfunktion konfigurieren. Anwendungen rufen Geheimnisse zur Laufzeit über eine IAM-Rolle ab.

Warum: Secrets Manager ist ein speziell entwickelter Dienst für den gesamten Lebenszyklus von Geheimnissen, einschließlich sicherer Speicherung, Zugriffssteuerung, Auditierung und automatischer Rotation, wodurch das Risiko von fest codierten oder veralteten Anmeldeinformationen reduziert wird.

Sowohl öffentliche TLS-Zertifikate für Websites als auch private Zertifikate für die interne Microservice-Kommunikation (mTLS) verwalten.

→AWS Certificate Manager (ACM) für kostenlose öffentliche Zertifikate, die in ELB/CloudFront integriert sind, verwenden. Eine private Zertifizierungsstelle mit ACM Private CA erstellen, um private Zertifikate für interne Dienste auszustellen und zu verwalten.

Warum: Dies trennt öffentliche und private PKI und verwendet das geeignete Tool für jeden Anwendungsfall. ACM verwaltet den Lebenszyklus öffentlicher Zertifikate, während ACM Private CA eine vollständig verwaltete private PKI-Hierarchie bereitstellt.

Daten unveränderlich für eine feste Aufbewahrungsdauer speichern, wobei nicht einmal der Root-Benutzer sie löschen kann.

→S3 Object Lock für den Bucket aktivieren. Objekte unter einer Aufbewahrungsdauer mit Compliance-Modus platzieren.

Warum: Der Compliance-Modus ist die stärkste WORM (Write-Once-Read-Many)-Kontrolle, die das Löschen durch jeden Benutzer verhindert. Der Governance-Modus kann von autorisierten Principals umgangen werden.

Backups vor dem Löschen schützen (z. B. aufgrund von Ransomware oder kompromittierten Anmeldeinformationen) für eine obligatorische Aufbewahrungsdauer.

→AWS Backup Vault Lock im Compliance-Modus mit einer Mindestaufbewahrungsdauer aktivieren.

Warum: Vault Lock im Compliance-Modus macht den Backup-Vault WORM-konform, wodurch verhindert wird, dass Benutzer, einschließlich des Root-Benutzers, Wiederherstellungspunkte vor Ablauf der Aufbewahrungsdauer löschen.

Hochsensible Daten verarbeiten, bei denen die Daten niemals dem Betriebssystem, dem Hypervisor oder AWS-Operatoren ausgesetzt werden dürfen.

→AWS Nitro Enclaves verwenden, um eine kryptografisch isolierte Computing-Umgebung zu erstellen. KMS-Attestierung verwenden, um sicherzustellen, dass nur verifizierte Enklaven Daten entschlüsseln können.

Warum: Nitro Enclaves bieten das höchste Maß an Schutz für Daten in Verwendung auf AWS, indem sie Hardware-Attestierung nutzen, um eine vertrauenswürdige Ausführungsumgebung zu schaffen.

AWS-Dienste mit Verschlüsselungsschlüsseln verwenden, die physisch in einem On-Premises-HSM außerhalb von AWS gespeichert und verwaltet werden.

→Einen KMS External Key Store (XKS) konfigurieren, der kryptografische Operationen von KMS an einen externen Schlüsselmanager weiterleitet.

Warum: XKS ermöglicht es Kunden, die Kontrolle über ihr Schlüsselmaterial außerhalb von AWS zu behalten, um Souveränitäts- oder Compliance-Anforderungen zu erfüllen, während es weiterhin mit KMS-fähigen AWS-Diensten integriert ist.

Eine strikte "keine öffentlichen S3-Buckets"-Richtlinie in einer gesamten Organisation mit präventiven und detektiven Kontrollen durchsetzen.

→S3 Block Public Access auf Organisationsebene über das Management-Konto aktivieren. Ergänzen mit einer SCP, die Aktionen wie `s3:PutBucketPolicy` verweigert, wenn die Richtlinie öffentlichen Zugriff erlaubt. AWS Config verwenden, um Abweichungen zu erkennen.

Warum: Dieser geschichtete Ansatz bietet eine Standardblockierung (Organisations-Einstellung), eine präventive Schutzbarriere, die Fehlkonfigurationen verhindert (SCP), und eine detektive Kontrolle für die kontinuierliche Überwachung (Config).

Den gesamten inter-VPC- und Internet-gebundenen Datenverkehr mit einer zentralisierten Sicherheits-Appliance (z. B. AWS Network Firewall) inspizieren.

→Eine dedizierte Inspektions-VPC erstellen. Ein Transit Gateway verwenden, um alle VPCs zu verbinden. TGW-Routing-Tabellen so konfigurieren, dass der gesamte Datenverkehr durch die Inspektions-VPC gesendet wird. Den Appliance-Modus an der TGW-Anbindung für symmetrisches Routing aktivieren.

Warum: Dies ist das Standard-Hub-and-Spoke-Modell für die zentralisierte Datenverkehrsinspektion, das Skalierbarkeit und konsistente Richtliniendurchsetzung ohne komplexe VPC-Peering-Netze bietet.

Eine Webanwendung (auf CloudFront/ALB) vor OWASP Top 10, Bots und Account-Übernahmeangriffen schützen.

→AWS WAF mit AWS Managed Rules (z. B. `AWSManagedRulesCommonRuleSet`), der verwalteten Regelgruppe Bot Control und der verwalteten Regelgruppe Account Takeover Prevention (ATP) anfügen.

Warum: Dieser geschichtete Ansatz verwendet mehrere verwaltete Regelgruppen für breiten Schutz (Common), automatisierte Datenverkehrserkennung (Bot Control) und spezialisierte Sicherheit für Login-Endpunkte (ATP).

Sicheren, privaten Zugriff auf einen SaaS-API-Dienst von Kunden-VPCs aus bereitstellen, ohne den Dienst dem Internet auszusetzen.

→Einen AWS PrivateLink Endpunktdienst erstellen, der von einem Network Load Balancer (NLB) unterstützt wird. Kunden erstellen in ihren VPCs Interface-VPC-Endpunkte, um auf den Dienst zuzugreifen.

Warum: PrivateLink hält den Datenverkehr auf dem privaten AWS-Backbone, vermeidet das öffentliche Internet und eliminiert die Notwendigkeit komplexer VPC-Peerings, VPNs oder IP-Whitelisting. Es ist das standardmäßige, skalierbare Muster für private SaaS-Konnektivität.

Den S3-Bucket-Zugriff so einschränken, dass Inhalte nur über eine CloudFront-Distribution zugänglich sind.

→CloudFront Origin Access Control (OAC) verwenden. Die S3-Bucket-Richtlinie aktualisieren, um den Zugriff nur vom Service-Principal der CloudFront-Distribution zu erlauben, bedingt durch den spezifischen Distribution ARN.

Warum: OAC ist die aktuell empfohlene Methode, die der veralteten Origin Access Identity (OAI) überlegen ist. Es unterstützt alle S3-Funktionen, einschließlich SSE-KMS, und folgt bewährten Sicherheitspraktiken.

Sicheren, auditierbaren Shell-Zugriff auf EC2-Instances in privaten Subnetzen bereitstellen, ohne SSH/RDP-Ports zu öffnen oder Bastion-Hosts zu verwalten.

→Den SSM-Agenten auf EC2-Instances installieren. AWS Systems Manager Session Manager für den Zugriff verwenden. IAM-Richtlinien steuern, wer Sitzungen starten kann. Sitzungsaktivitäten können in CloudWatch Logs und S3 protokolliert werden.

Warum: Session Manager bietet sicheren, browserbasierten oder CLI-Zugriff über einen verschlüsselten Tunnel, wodurch die Notwendigkeit für Inbound-Ports, Bastion-Hosts und SSH-Schlüssel entfällt, während gleichzeitig eine vollständige Auditierbarkeit gewährleistet ist.

DNS-Filterung implementieren, um zu verhindern, dass VPC-Ressourcen bekannte bösartige Domains auflösen.

→Route 53 Resolver DNS Firewall mit verwalteten Domainlisten (für Malware, C2) und benutzerdefinierten Blocklisten konfigurieren. Die Firewall-Regelgruppe mit den VPCs verknüpfen.

Warum: Dies bietet einen zentralisierten, verwalteten DNS-Filterdienst auf VPC-Ebene, der bösartige Aktivitäten am frühestmöglichen Punkt (DNS-Auflösung) blockiert, ohne hostbasierte Agenten zu erfordern.

Netzwerkkontrollen mit den geringsten Rechten für eine dreistufige Webanwendung implementieren.

→Separate Sicherheitsgruppen für jede Stufe erstellen. Die ALB SG erlaubt eingehenden Datenverkehr auf Port 443 von `0.0.0.0/0`. Die App SG erlaubt eingehenden Datenverkehr nur von der ALB SG. Die DB SG erlaubt eingehenden Datenverkehr nur von der App SG auf dem Datenbankport.

Warum: Die Verwendung von Sicherheitsgruppenreferenzen als Quellen bietet eine dynamische, IP-agnostische Mikro-Segmentierung, die sicherstellt, dass jede Stufe nur von ihrer angrenzenden, autorisierten Stufe erreicht werden kann.

Feingranulare AWS-Berechtigungen auf Pod-Ebene für Anwendungen, die auf EKS laufen, gewähren und dabei die Verwendung gemeinsam genutzter Node-IAM-Rollen vermeiden.

→IAM Roles for Service Accounts (IRSA) auf dem EKS-Cluster aktivieren. Eine IAM-Rolle mit spezifischen Berechtigungen für die Anwendung erstellen. Das Kubernetes-Servicekonto der Anwendung mit dem IAM-Rollen-ARN annotieren.

Warum: IRSA stellt temporäre Anmeldeinformationen direkt für Pods bereit, basierend auf deren Servicekonto, implementiert das Prinzip der geringsten Rechte auf Pod-Ebene und eliminiert das Sicherheitsrisiko übermäßig permissiver Node-Rollen.

VPN-losen Zugriff auf interne Webanwendungen basierend auf Benutzeridentität und Geräte-Sicherheitspostur bereitstellen.

→AWS Verified Access bereitstellen. Integration mit dem Unternehmens-IdP als Benutzervertrauensanbieter und einer Geräteverwaltungslösung als Gerätevertrauensanbieter. Zugriffsrichtlinien pro Anwendung erstellen.

Warum: Verified Access wurde speziell für Zero-Trust-Zugriff entwickelt, wobei jede Anfrage anhand von Richtlinien bewertet wird, die sowohl den Benutzer- als auch den Gerätekontext berücksichtigen, wodurch die Abhängigkeit von der Netzperimeter-Sicherheit entfällt.

Entwicklern erlauben, IAM-Rollen zu erstellen, aber verhindern, dass sie Rollen erstellen, die ihre eigenen Privilegien eskalieren könnten.

→Eine Berechtigungsgrenzenrichtlinie erstellen, die die maximal erlaubten Berechtigungen definiert. In der IAM-Richtlinie der Entwickler die `iam:CreateRole`-Berechtigung so bedingen, dass die Anbindung dieser spezifischen Grenze über den Bedingungsschlüssel `iam:PermissionsBoundary` erforderlich ist.

Warum: Berechtigungsgrenzen legen die maximalen Berechtigungen fest, die eine IAM-Entität haben kann. Dies verhindert die Eskalation von Berechtigungen, indem sichergestellt wird, dass jede Rolle, die ein Entwickler erstellt, durch die Grenze gedeckelt wird, unabhängig von der von ihm angehängten Identitätsrichtlinie.

Referenz↗

Verhindern, dass Benutzer in Mitgliedskonten (einschließlich Administratoren) risikoreiche Aktionen ausführen, wie z. B. CloudTrail deaktivieren oder einen gemeinsamen S3-Bucket löschen.

→Eine Service Control Policy (SCP) auf das Root oder die relevante OU anwenden, die eine `Deny`-Anweisung für die eingeschränkten Aktionen enthält (z. B. `cloudtrail:StopLogging`, `s3:DeleteBucket`).

Warum: SCPs sind die ultimative Schutzbarriere in AWS Organizations. Sie legen die maximalen Berechtigungen für alle Principals in einem Konto fest, und eine explizite Deny-Anweisung in einer SCP kann durch keine IAM-Richtlinie innerhalb des Kontos außer Kraft gesetzt werden.

Sicheren, auditierbaren kontoübergreifenden Zugriff für eine Anwendung oder einen Benutzer bereitstellen.

→Im Zielkonto eine IAM-Rolle mit einer Vertrauensrichtlinie erstellen, die den Principal-ARN des Quellkontos angibt. Im Quellkonto dem Principal die `sts:AssumeRole`-Berechtigung für die Zielrolle erteilen. Die Anwendung verwendet STS AssumeRole, um temporäre Anmeldeinformationen zu erhalten.

Warum: Dies ist das Standardmuster für den kontoübergreifenden Zugriff. Es verwendet temporäre, kurzlebige Anmeldeinformationen und ist in beiden Konten über CloudTrail vollständig auditierbar.

IAM Identity Center mit einem externen IdP (z. B. Okta, Azure AD) integrieren und die Benutzer-/Gruppenbereitstellung automatisieren.

→Den externen IdP als Identitätsquelle in IAM Identity Center konfigurieren. Automatische Bereitstellung über SCIM aktivieren, um Benutzer und Gruppen zu synchronisieren. Berechtigungssätze den synchronisierten Gruppen zuweisen.

Warum: SCIM (System for Cross-domain Identity Management) bietet eine automatisierte, nahezu Echtzeit-Synchronisierung von Identitäten, eliminiert die manuelle Benutzerverwaltung und stellt sicher, dass der AWS-Zugriff vom IdP gesteuert wird.

Zugriff auf Ressourcen (z. B. EC2) basierend auf Tags gewähren, wobei Principals nur Ressourcen verwalten können, die mit ihrem eigenen Team-/Abteilungsnamen getaggt sind.

→Sowohl IAM-Principals (Benutzer/Rollen) als auch Ressourcen (EC2-Instances) mit einem gemeinsamen Schlüssel (z. B. `Team`) taggen. Eine einzige IAM-Richtlinie erstellen, die Aktionen mit einer Bedingung erlaubt, die `aws:PrincipalTag/Team` mit `aws:ResourceTag/Team` vergleicht.

Warum: Attributbasierte Zugriffssteuerung (ABAC) bietet ein skalierbares Berechtigungsmodell, das keine Richtlinienaktualisierungen erfordert, wenn neue Ressourcen oder Teams hinzugefügt werden. Berechtigungen werden dynamisch basierend auf Tags bestimmt.

Ein Principal in Konto B muss ein S3-Objekt in Konto A lesen, das mit einem KMS-Schlüssel ebenfalls in Konto A verschlüsselt ist.

→Drei Berechtigungen sind erforderlich: 1) Die S3-Bucket-Richtlinie in Konto A muss dem Principal aus Konto B Zugriff gewähren. 2) Die KMS-Schlüsselrichtlinie in Konto A muss dem Principal aus Konto B `kms:Decrypt` erlauben. 3) Der Principal in Konto B benötigt eine IAM-Richtlinie, die `s3:GetObject` und `kms:Decrypt` erlaubt.

Warum: Der Zugriff auf KMS-verschlüsselte Daten erfordert Berechtigungen sowohl vom Datendienst (S3) als auch vom Verschlüsselungsdienst (KMS). Die KMS-Schlüsselrichtlinie ist eine Ressourcenrichtlinie und entscheidend für die Gewährung kontoübergreifenden Zugriffs.

Das endgültige Ergebnis der Berechtigungen verstehen, wenn mehrere Richtlinien (IAM, Ressource, SCP, Grenze) angewendet werden.

→Die Evaluierungslogik ist: Ein explizites Deny in einer beliebigen Richtlinie überschreibt immer jedes Allow. Wenn kein Deny vorhanden ist, gewährt ein explizites Allow in einer anwendbaren Richtlinie den Zugriff. Die effektiven Berechtigungen sind die Schnittmenge aller anwendbaren Richtlinien.

Warum: Dies ist ein grundlegendes IAM-Konzept. Ein explizites Deny ist die mächtigste Aussage und dient als hartes "Nein". Dies zu verstehen ist entscheidend für die Fehlerbehebung bei Zugriffsproblemen.

Verhindern, dass ein IAM-Benutzer oder eine Rolle eine hochprivilegierte Rolle an einen AWS-Dienst (z. B. EC2) weitergibt, was seine Privilegien eskalieren würde.

→Die `iam:PassRole`-Berechtigung in der IAM-Richtlinie des Benutzers/der Rolle eingrenzen. Das `Resource`-Element auf nur die spezifischen, am wenigsten privilegierten Rollen-ARNs beschränken, die die Entität übergeben darf.

Warum: `iam:PassRole` mit einem Wildcard (`"Resource": "*"`) stellt ein erhebliches Risiko für die Privilegienausweitung dar. Die Beschränkung auf spezifische, weniger privilegierte Rollen ist eine kritische Sicherheitskontrolle.

Benutzer nur dann mit MFA herausfordern, wenn ein Anmeldeversuch als riskant eingestuft wird (z. B. neues Gerät, ungewöhnlicher Standort).

→Erweiterte Sicherheitsfunktionen im Cognito User Pool aktivieren und adaptive Authentifizierung mit risikobasierter MFA-Durchsetzung konfigurieren.

Warum: Dies bietet eine bessere Benutzererfahrung als die Anforderung von MFA bei jeder Anmeldung und verbessert gleichzeitig die Sicherheit, indem Herausforderungen nur bei anomalen Anmeldeversuchen angewendet werden.

On-Premises-Servern, die eine private PKI verwenden, den Zugriff auf AWS-Dienste ohne langfristige AWS-Anmeldeinformationen ermöglichen.

→IAM Roles Anywhere konfigurieren. Einen Vertrauensanker mithilfe des privaten CA-Zertifikats erstellen. Profile erstellen, die Zertifikate IAM-Rollen zuordnen. Server verwenden ihre Zertifikate, um temporäre AWS-Anmeldeinformationen zu erhalten.

Warum: Dies erweitert IAM-Rollen auf externe Workloads durch Nutzung bestehender PKI, wodurch die Notwendigkeit entfällt, AWS-Zugriffsschlüssel On-Premises zu verwalten.

Die Bereitstellung nicht-konformer Ressourcen, die in CloudFormation-Vorlagen definiert sind, *bevor* sie bereitgestellt werden, verhindern.

→Proaktive Kontrollen von AWS Control Tower aktivieren. Diese verwenden CloudFormation-Hooks, um Ressourcenkonfigurationen vor der Bereitstellung anhand von Richtlinien (geschrieben in cfn-guard) zu validieren.

Warum: Dies ist eine "Shift-Left"-Kontrolle, die Fehlkonfigurationen an der Quelle verhindert, was effektiver ist als deren Erkennung und Behebung nach der Bereitstellung.