Amazon DVA-C02: Sicherheit, IAM, KMS und Secrets-Management (Cognito, Secrets Manager, SSM) — Lernleitfaden

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

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

IAM, Rollen, Richtlinien und kontoübergreifender Zugriff

Das Identitäts- und Zugriffsmanagement sollte nach dem Prinzip der geringsten Rechte (Least Privilege), kurzlebigen Anmeldeinformationen und einer klaren Trennung zwischen Dienst- und menschlichen Identitäten konzipiert sein. Für Anwendungen, die auf EC2, ECS oder Lambda laufen, sollten Instanz-/Task-/Funktions-Rollen anstelle von eingebetteten Zugriffsschlüsseln bevorzugt werden. Die AWS SDKs verwenden automatisch die von der Umgebung bereitgestellte Kette von Anmeldeinformationsanbietern (Credential Provider Chain) und erneuern temporäre Anmeldeinformationen. Kontoübergreifender Zugriff sollte AWS STS AssumeRole (API: sts:AssumeRole) verwenden, mit einer expliziten Rollen-Vertrauensrichtlinie (Role Trust Policy) im Zielkonto und einer IAM-Richtlinie im aufrufenden Konto, die einschränkt, welche Rollen-ARNs übernommen werden können. Wenn Sie MFA für sensible Operationen benötigen, erzwingen Sie dies mit einer Bedingung (Condition) in der Rollen- oder Ressourcenrichtlinie unter Verwendung von aws:MultiFactorAuthPresent oder fordern Sie sts:GetSessionToken für menschliche Benutzer an. Für Web- oder mobile Clients verwenden Sie AssumeRoleWithWebIdentity (sts:AssumeRoleWithWebIdentity) über Cognito Identity oder föderierte Anbieter, um langlebige Anmeldeinformationen zu vermeiden. Hüten Sie sich vor häufigen Fallen: übermäßig freizügige Wildcard-Aktionen/-Ressourcen, das Verlassen auf ressourcenbasierte Richtlinien ohne passende Principal-Bedingungen und das Vergessen, die Bedingungen SourceAccount oder aws:SourceVpc für kontoübergreifenden S3- oder KMS-Zugriff einzuschließen. Verwenden Sie den IAM Policy Simulator und sts:GetCallerIdentity zum Debuggen. Erwägen Sie die Verwendung von Service Control Policies (SCPs) auf Organisationsebene, um Leitplanken (Guardrails) durchzusetzen und riskante Aktionen wie kms:CreateGrant oder iam:CreateAccessKey gegebenenfalls explizit zu verweigern (Deny).

KMS, Verschlüsselungsmuster und Schlüsselzugriffskontrolle

Verwenden Sie AWS KMS für die Envelope-Verschlüsselung: Mit GenerateDataKey/GenerateDataKeyWithoutPlaintext wird ein Datenschlüssel für die client- oder serverseitige Verschlüsselung erzeugt. Rufen Sie dann Encrypt/Decrypt für kleine Payloads auf oder verwenden Sie den Datenschlüssel für die Massenverschlüsselung (Bulk Encryption). Wählen Sie den richtigen CMK: AWS-eigene (AWS owned) für Bequemlichkeit, AWS-verwaltete (AWS managed, aws/*) für die Service-Integration oder kundenverwaltete (customer-managed) für volle Kontrolle und Rotation. Schlüsselrichtlinien (Key Policies) sind das primäre Steuerungselement für KMS. Fügen Sie IAM-Richtlinien an, die kms:Decrypt und kms:Encrypt erlauben, und verwenden Sie Grants, wenn Sie eine temporäre, delegierte Schlüsselnutzung für Dienste wie CloudHSM-gestützte Operationen oder kontoübergreifende Lambda-Aufrufe benötigen. Fügen Sie einen EncryptionContext hinzu, um den verschlüsselten Text (Ciphertext) an den Nutzungskontext zu binden, und fordern Sie ihn über eine kms:EncryptionContextEquals-Bedingung für eine höhere Sicherheit an. Die kontoübergreifende Nutzung von KMS erfordert explizite Einträge in der Schlüsselrichtlinie, die dem externen Principal oder der Rolle Berechtigungen erteilen, sowie in einigen Fällen die Berechtigungen CreateGrant/RetireGrant. Für Auditing und Forensik aktivieren Sie CloudTrail-Datenereignisse (Data Events) für KMS und S3, um GenerateDataKey- und Decrypt-Aufrufe zu erfassen. Die CloudTrail-Protokolle enthalten arn:aws:kms und Details darüber, welcher Principal den Schlüssel verwendet hat. Häufige Fallstricke sind das Vergessen, kms:CreateGrant für Dienste zu erlauben, die Grants im Hintergrund verwenden, das Versäumnis, kundenverwaltete Schlüssel zu rotieren, und die Annahme, dass IAM-Richtlinien allein KMS-Operationen ohne entsprechende Einträge in der Schlüsselrichtlinie autorisieren können.

Secrets Management: Secrets Manager vs. Parameter Store

Secrets Manager und Systems Manager Parameter Store bieten beide verschlüsselte Speicherung für Secrets, unterscheiden sich jedoch in Funktionen und Kostenprofil: Secrets Manager unterstützt automatische Rotation (mit Lambda-Rotationsvorlagen), integrierte Versionierung und Replikation und wird pro Secret abgerechnet. Der Parameter Store (SecureString) ist für viele Parameter im kostenlosen Kontingent (Free Tier) enthalten und eignet sich besser für einfache Konfigurationen. Der Zugriff wird durch IAM-Richtlinien gesteuert, die secretsmanager:GetSecretValue oder ssm:GetParameter mit WithDecryption=true gewähren. Der zugrunde liegende KMS-Schlüssel muss dem Principal die Entschlüsselung (Decrypt) erlauben. Verwenden Sie ressourcenbasierte Richtlinien für Secrets Manager für kontoübergreifende Secrets oder die Replikation mit Secrets Replication. Wenn Sie SDKs verwenden, rufen Sie secretsmanager.getSecretValue({ SecretId }) oder ssm.getParameter({ Name, WithDecryption: true }) auf und vermeiden Sie die Protokollierung der Secret-Werte. Setzen Sie Lambda-Umgebungsvariablen so, dass sie Referenzen auf Secrets Manager oder Parameter Store mit dynamischer Auflösung in CloudFormation oder SAM verwenden, oder rufen Sie die Werte beim Start über das SDK ab. Häufige Fehler von Entwicklern sind das Speichern von Secrets im Klartext in der Quellcodeverwaltung, das Verlassen auf Lambda-Umgebungsvariablen für sehr sensible Daten ohne KMS-Schutz und übermäßig freizügige IAM-Richtlinien, wie z. B. die Gewährung von secretsmanager:* für weitreichende Rollen. Stellen Sie für die Rotation sicher, dass die Rotations-Lambda die korrekten Berechtigungen secretsmanager:RotateSecret und kms:GenerateDataKey besitzt und dass der Anwendungscode Verbindungen nahtlos neu initialisieren kann, wenn sich die Anmeldeinformationen ändern.

Cognito-Authentifizierung, -Autorisierung und API-Integration

Amazon Cognito bietet Benutzerpools für die Authentifizierung und Identitätenpools für temporäre AWS-Anmeldeinformationen. Verwenden Sie Cognito-Benutzerpools, um die Registrierung, die Multi-Faktor-Authentifizierung und die Ausstellung von JWTs (ID-, Zugriffs-, Aktualisierungs-Token) zu verwalten. Browserbasierte Single-Page-Anwendungen müssen App-Clients ohne Client-Secret verwenden und sollten die gehostete Benutzeroberfläche oder das Amazon Cognito SDK (amazon-cognito-identity-js) nutzen, das den SRP-Flow implementiert, um die Preisgabe von Passwörtern zu vermeiden. Verifizieren Sie JWTs auf dem Server oder im API Gateway, indem Sie die JWKS-URI aus dem Benutzerpool abrufen und die Signatur, den Aussteller (Issuer), die Zielgruppe (Audience, aud) und die Gültigkeitsdauer des Tokens validieren. API Gateway JWT-Authorizer oder benutzerdefinierte Lambda-Authorizer können diese Validierung durchführen. Für die Server-zu-Server-Authentifizierung tauschen Sie das Benutzerpool-Token über einen Cognito-Identitätenpool mit sts:AssumeRoleWithWebIdentity gegen temporäre Anmeldeinformationen ein. Zu den Fallstricken gehören falsch konfigurierte Callback- oder Abmelde-URLs, die Nichtvalidierung von Token-Scopes oder -Gruppen und die Erwartung, dass ID-Token direkt für AWS-API-Aufrufe verwendet werden können (sie müssen über einen Identitätenpool ausgetauscht werden). Für eine feingranulare Autorisierung verwenden Sie Gruppen oder benutzerdefinierte Claims und kombinieren Cognito mit ressourcenbasierten Richtlinien und IAM-Bedingungsschlüsseln wie aws:userid oder cognito-identity.amazonaws.com:sub, wenn Sie Identitäten auf AWS-Rollen abbilden. Überwachen Sie Anmelde- und Admin-Aktionen über CloudTrail und aktivieren Sie die erweiterten Sicherheitsfunktionen in Cognito zur Erkennung kompromittierter Anmeldeinformationen.

Praktisches Problem: Anwendungsfallszenario

Szenario: PixelForge, ein Spielestudio, betreibt ein serverloses Backend in einem einzigen AWS-Konto mit Lambda, API Gateway, S3, DynamoDB und Cognito-Benutzerpools. Sensible API-Schlüssel und Datenbank-Anmeldeinformationen werden für mehrere Bereitstellungsstufen gespeichert, und ein externes Auditteam muss für 1–24 Stunden auf Teilmengen von Produktionsbildern in S3 zugreifen.

Herausforderung: Sicherer, kurzlebiger und prüfbarer Zugriff auf Produktionsbilder für externe Auditoren bereitstellen, sicherstellen, dass Anwendungs-Secrets rotiert und von Lambda sicher abgerufen werden, und MFA für den kontoübergreifenden Admin-Zugriff erzwingen.

Empfohlener Ansatz:

1. Erstellen Sie einen kundenverwalteten KMS-Schlüssel mit einer Schlüsselrichtlinie, die die Entschlüsselung für das PixelForge-Konto und Berechtigungen (Grants) für eine Auditor-IAM-Rolle erlaubt. Aktivieren Sie die Schlüsselrotation und fordern Sie bei Entschlüsselungsvorgängen einen EncryptionContext an.
2. Speichern Sie Anmeldeinformationen im Secrets Manager (separate Secrets pro Stufe) und weisen Sie den Lambdas eine IAM-Rolle mit minimalen Berechtigungen für secretsmanager:GetSecretValue und kms:Decrypt für den KMS-Schlüssel zu. Implementieren Sie Lambda-Startcode, der

undefined

über das AWS SDK aufruft. 3. Für den Auditor-Zugriff erstellen Sie eine separate Rolle im Auditor-AWS-Konto und erlauben sts:AssumeRole vom Auditor-Konto in einer ressourcenbasierten S3-Bucket-Richtlinie, die durch aws:PrincipalArn und eine zeitlich begrenzte, vorkonfigurierte Rollenzuordnung eingeschränkt ist. Generieren Sie kurzlebige Anmeldeinformationen über sts:AssumeRole und erzwingen Sie MFA mit der Bedingung aws:MultiFactorAuthPresent beim Übernehmen der Rolle. 4. Protokollieren Sie alle Zugriffe mit CloudTrail (Verwaltungs- und Datenereignisse für S3 und KMS) und aktivieren Sie die S3-Protokollierung auf Objektebene sowie Amazon Macie oder S3-Zugriffsprotokolle für zusätzliche Forensik. Fordern Sie, dass temporäre Auditor-Sitzungen einen spezifischen EncryptionContext verwenden, und versehen Sie Objekte/Anfragen mit Tags zur Nachverfolgbarkeit.

Begründung: Die Verwendung von Secrets Manager mit KMS und kurzlebigen STS-Anmeldeinformationen erzwingt das Prinzip der geringsten Rechte (Least Privilege), ermöglicht die automatisierte Rotation und vermeidet das Einbetten von Secrets. Zeitlich begrenzte Assume-Role-Muster mit MFA und CloudTrail-Datenereignissen bieten einen prüfbaren, widerrufbaren Zugriff für Dritte und wahren gleichzeitig die Funktionstrennung (Separation of Duties).

← Bereitstellung und CI · Alle Domänen · Monitoring →

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

Amazon durchsuchen →