Amazon SCS-C02: Verschlüsselung, KMS und Secrets — Lernleitfaden
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.
AWS KMS-Schlüsseltypen, -Richtlinien und Zugriffskontrolle
AWS KMS unterstützt drei Hauptkategorien von Schlüsseln. Die Wahl des richtigen Typs bestimmt, wer das Schlüsselmaterial kontrolliert, wo es gespeichert ist und wie es rotiert werden kann. AWS-eigene Schlüssel sind für Sie nicht sichtbar, kostenlos und werden von Diensten wie S3 verwendet, wenn Sie SSE-S3 aktivieren. AWS-verwaltete Schlüssel (mit dem Alias aws/<service>) ermöglichen es einem Dienst, in Ihrem Namen zu verschlüsseln, aber Sie können deren Schlüsselrichtlinie nicht ändern, weshalb sie für kontoübergreifenden Zugriff oder eine feingranulare Governance ungeeignet sind. Kundenseitig verwaltete Schlüssel (CMKs) sind das Arbeitspferd: Sie kontrollieren die Schlüsselrichtlinie, die Rotation (jährlich automatisch oder bei Bedarf), Grants, Aliase und das Löschfenster.
Zwei spezialisierte Varianten sind wichtig. Importiertes Schlüsselmaterial wird verwendet, wenn regulatorische oder BYOK-Anforderungen es erzwingen, Schlüsselmaterial außerhalb von AWS zu generieren und in einen KMS-Schlüssel zu importieren. Importiertes Material ist die einzige Möglichkeit, ein explizites Ablaufdatum für Schlüsselmaterial zu konfigurieren – von AWS generierte CMKs laufen niemals ab. Sie können die automatische jährliche Rotation von AWS für importierte Schlüssel nicht aktivieren; Sie müssen das Material selbst neu importieren. Multi-Region-Schlüssel teilen dieselbe Schlüssel-ID und dasselbe Material über Regionen hinweg durch Replika-Schlüssel, sodass ein in us-east-1 erzeugter Chiffretext in us-west-1 ohne erneute Verschlüsselung entschlüsselt werden kann. Jeder Replika-Schlüssel hat seine eigene, unabhängige Schlüsselrichtlinie und Aliase, aber das kryptografische Material wird synchronisiert.
Die am häufigsten missverstandene Kontrollinstanz ist die KMS-Schlüsselrichtlinie. Im Gegensatz zu den meisten AWS-Ressourcen, bei denen IAM-Richtlinien allein den Zugriff gewähren, verwenden KMS-Schlüssel ihre Schlüsselrichtlinie als grundlegende Autorisierung. Eine IAM-Richtlinie, die kms:Decrypt für einen Schlüssel gewährt, ist wirkungslos, es sei denn, die Schlüsselrichtlinie delegiert den Zugriff ebenfalls an IAM (über einen Principal des Konto-Stammelements plus einer entsprechenden Anweisung oder durch direkte Benennung des Principals). Aus diesem Grund kann ein Engineer mit AdministratorAccess immer noch eine AccessDenied-Fehlermeldung erhalten, wenn er Decrypt für einen CMK aufruft, dessen Richtlinie dem Konto nicht vertraut. Die kanonische Delegierungsanweisung sieht wie folgt aus:
{
"Sid": "EnableIAMPermissions",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": "kms:*",
"Resource": "*"
}
Grants und ViaService-Bedingungen fügen zusätzliche Einschränkungsebenen hinzu – zum Beispiel, indem erzwungen wird, dass ein Schlüssel nur über S3 in einer bestimmten Region mit kms:ViaService: s3.us-east-1.amazonaws.com verwendet werden darf.
Serverseitige und clientseitige Verschlüsselung
Für S3 unterscheiden sich die beiden gängigen serverseitigen Optionen hauptsächlich in Bezug auf Kontrolle und Überprüfbarkeit:
- SSE-S3 (AES-256): S3 verwaltet die Schlüssel vollständig; es gibt keine für den Kunden sichtbare Schlüsselrichtlinie, keine CloudTrail-Entschlüsselungsereignisse pro Schlüssel und keine kontoübergreifende Governance. Ausreichend für eine grundlegende Verschlüsselung im Ruhezustand, aber unzureichend, wenn Compliance-Anforderungen den Nachweis erfordern, wer Daten entschlüsselt hat.
- SSE-KMS: Verwendet einen von Ihnen kontrollierten CMK; jeder Entschlüsselungsaufruf wird protokolliert, die Schlüsselrichtlinie erzwingt den Zugriff, und Sie können Einschränkungen über den Verschlüsselungskontext (Encryption Context) vornehmen. Es ist teurer pro Anfrage und verbraucht KMS-TPS-Kontingente, daher sollten Bucket-Schlüssel (
BucketKeyEnabled: true) aktiviert werden, um die Anzahl der KMS-Aufrufe drastisch zu reduzieren.
Die clientseitige Verschlüsselung mit dem AWS Encryption SDK ist geeignet, wenn Daten verschlüsselt werden müssen, bevor sie die Anwendung verlassen, oder wenn der Speicherdienst niemals Klartext sehen darf. Workloads mit hohem Durchsatz sollten das SDK mit dem Caching Cryptographic Materials Manager (CachingCryptoMaterialsManager) wrappen, der Datenschlüssel über viele Nachrichten hinweg innerhalb konfigurierbarer Byte-, Nachrichten- und TTL-Limits wiederverwendet. Ohne Caching löst jeder encrypt-Aufruf eine GenerateDataKey-Anfrage aus, was die KMS-Anfragekontingente schnell ausschöpft und die Kosten in die Höhe treibt.
from aws_encryption_sdk import CachingCryptoMaterialsManager, LocalCryptoMaterialsCache
cache = LocalCryptoMaterialsCache(capacity=100)
ccmm = CachingCryptoMaterialsManager(
master_key_provider=mkp, cache=cache,
max_age=600.0, max_messages_encrypted=10000)
Secrets Manager und Parameter Store
Secrets Manager speichert Anmeldeinformationen, die mit einem KMS-CMK verschlüsselt sind, und unterstützt die automatische Rotation durch eine Lambda-Funktion – AWS stellt Vorlagen für RDS, Redshift und DocumentDB bereit, und benutzerdefinierte Lambdas können alles andere handhaben. Die Rotation durchläuft eine vierstufige Zustandsmaschine (createSecret, setSecret, testSecret, finishSecret), die neue Anmeldeinformationen unter dem Label AWSPENDING bereitstellt, bevor sie zu AWSCURRENT heraufgestuft werden. Anwendungen sollten Authentifizierungsfehler abfangen, das Secret aktualisieren und es erneut versuchen – dieses Muster eliminiert Ausfallzeiten, da die vorherigen Anmeldeinformationen über AWSPREVIOUS kurzzeitig gültig bleiben.
Wenn die Rotations-Lambda innerhalb einer VPC ausgeführt wird (typisch für den Zugriff auf eine private RDS-Instanz), benötigt sie ausgehenden Netzwerkzugriff auf den Secrets Manager Service-Endpunkt. In einer privaten VPC ohne NAT müssen Sie einen Interface-VPC-Endpunkt (com.amazonaws.<region>.secretsmanager) bereitstellen und der Sicherheitsgruppe der Lambda erlauben, den Endpunkt auf Port 443 zu erreichen. Dies zu vergessen ist ein klassischer Fehler: Die Rotation scheint konfiguriert zu sein, aber jeder Aufruf endet mit einem Timeout.
Für regionenübergreifende Ausfallsicherheit verwenden Sie einen Multi-Region-KMS-Schlüssel und die Replika-Secret-Funktion von Secrets Manager. Das primäre Secret in us-east-1 wird mit dem primären CMK verschlüsselt; das Replikat in us-west-1 entschlüsselt mit dem Replika-CMK. Aliase wie alias/prod-db können bei Bedarf auf eine neue Schlüssel-ID umgelenkt werden, um eine schnelle Schlüsselrotation ohne Änderung des Anwendungscodes zu ermöglichen.
Der SecureString-Typ des Parameter Store ist eine leichtgewichtige Alternative, wenn Sie keine Rotation benötigen. Beide Dienste bieten dynamische Referenzen in CloudFormation ({{resolve:secretsmanager:MySecret:SecretString:password}}), sodass Stack-Vorlagen niemals Klartext enthalten.
EBS-, RDS-, Aurora- und Snapshot-Verschlüsselung
Die Verschlüsselung im Ruhezustand wird pro Volume oder pro Instanz bei der Erstellung aktiviert und kann nicht nachträglich umgeschaltet werden. Das Korrekturmuster für eine nicht konforme, unverschlüsselte Ressource ist eine Kopie eines Snapshots mit aktivierter Verschlüsselung:
aws ec2 copy-snapshot --source-snapshot-id snap-abc \
--source-region us-east-1 --encrypted \
--kms-key-id alias/prod-ebs
aws ec2 create-volume --snapshot-id snap-newEncrypted ...
Für RDS und Aurora stellen Sie den verschlüsselten Snapshot in einer neuen Instanz wieder her und schalten dann um. Die kontoübergreifende Wiederherstellung erfordert das Teilen des Snapshots und die Gewährung von kms:CreateGrant und kms:Decrypt für das Zielkonto auf dem CMK über die Schlüsselrichtlinie – das alleinige Teilen des Snapshots schlägt fehl, da das Zielkonto den Datenschlüssel nicht entschlüsseln kann. Die standardmäßige EBS-Verschlüsselung auf Kontoebene sollte aktiviert werden, damit neu erstellte Volumes immer verschlüsselt sind, unabhängig vom Verhalten des Aufrufers.
TLS: ACM- und ALB-Richtlinien
ACM stellt öffentliche Zertifikate kostenlos aus und erneuert sie automatisch, wenn sie an integrierte Services (ALB, CloudFront, API Gateway) gebunden sind. Zertifikate können nicht exportiert werden, daher erfordert auf EC2 terminiertes TLS entweder ACM Private CA (für private Zertifikate, die Sie exportieren können) oder ein importiertes Zertifikat. Ein pragmatisches Muster: öffentliches TLS am ALB mit einem ACM-Zertifikat terminieren und ein selbstsigniertes oder privates CA-Zertifikat für den Hop vom ALB zur EC2 verwenden, falls eine Ende-zu-Ende-Verschlüsselung erforderlich ist. Zwingen Sie Clients zur Verwendung moderner Ciphers mit einer Sicherheitsrichtlinie wie ELBSecurityPolicy-TLS13-1-2-2021-06, die TLS 1.0/1.1 und schwache Suites deaktiviert.
Häufige Fallstricke
IAM ohne Schlüsselrichtlinie. Die Gewährung von kms:Decrypt in einer IAM-Richtlinie, während die Schlüsselrichtlinie des CMK den Account-Principal auslässt, führt zu AccessDenied. KMS behandelt die Schlüsselrichtlinie als maßgeblich; IAM-Berechtigungen können nur weiter einschränken, was die Schlüsselrichtlinie erlaubt.
Rotations-Lambda ohne VPC-Endpunkt. Wenn die Lambda-Funktion in privaten Subnetzen läuft und die VPC keinen NAT-Gateway und keinen secretsmanager-Interface-Endpunkt hat, kann der Rotationsaufruf an secretsmanager.<region>.amazonaws.com nicht aufgelöst oder verbunden werden. Die Sicherheitsgruppe am Endpunkt muss ebenfalls Port 443 von der SG der Lambda erlauben.
SSE-S3 mit SSE-KMS gleichgesetzt. SSE-S3 verwendet einen AWS-eigenen Schlüssel ohne vom Kunden bearbeitbare Richtlinie, keine Entschlüsselungsprotokollierung pro Objekt in CloudTrail und keine kontoübergreifende Schlüssel-Freigabe. Es erfüllt die Anforderung „Verschlüsselung im Ruhezustand“ (encrypt at rest), kann aber nicht erzwingen, welche Prinzipale bestimmte Objekte entschlüsseln dürfen – nur SSE-KMS mit einem CMK bietet diese Governance.
Praktisches Problem: Anwendungsfallszenario
Szenario: Meridian Financial betreibt eine AWS Organization mit mehreren Konten, darunter ein Security-Konto, separate Prod-/NonProd-Konten, Microservices in ECS/EKS hinter einem ALB, RDS/Aurora-Cluster, EC2-Instanzen mit EBS-Backing und S3-Data-Lakes. Entwickler und Automatisierung nutzen derzeit eine Mischung aus von AWS verwalteten Schlüsseln, SSM-Parametern im Klartext und gelegentlicher manueller Freigabe von Snapshots zwischen Konten.
Herausforderung: Ein Ingenieur hat versehentlich einen unverschlüsselten RDS-Snapshot für das Konto eines Drittanbieters freigegeben, und es wurde entdeckt, dass mehrere API-Anmeldeinformationen als Klartext-SecureString-Parameter gespeichert waren, was das Risiko von Datenexfiltration und unbefugtem Wiederherstellungszugriff schuf.
Empfohlener Ansatz:
- Erstellen Sie einen organisationsweiten, kundenverwalteten, symmetrischen AWS KMS CMK im Security-Konto mit einer Schlüsselrichtlinie, die die Nutzung über
aws:PrincipalOrgIDfür Mitgliedskonten gewährt, und aktivieren Sie die automatische Rotation; verwenden Sie Grants für kurzlebige, kontoübergreifende Operationen. - Bereinigen Sie bestehende Artefakte, indem Sie den unverschlüsselten RDS-Snapshot und alle EBS-Snapshots kopieren und dabei den neuen CMK auswählen, um verschlüsselte Kopien zu erstellen. Löschen Sie dann die ursprünglichen unverschlüsselten Snapshots; legen Sie Kontostandards fest, sodass neue RDS- und EBS-Ressourcen standardmäßig verschlüsselt erstellt werden.
- Migrieren Sie Secrets in den AWS Secrets Manager (oder SSM Parameter Store SecureString), verschlüsselt mit dem CMK, aktivieren Sie die automatische Rotation von DB-Anmeldeinformationen im Secrets Manager über Lambda und beschränken Sie den Zugriff mithilfe von ressourcenbasierten Richtlinien und IAM-Rollen nach dem Prinzip der geringsten Rechte (Least Privilege).
- Erzwingen Sie die Verschlüsselung während der Übertragung (encryption in transit) durch die Bereitstellung von ACM-verwalteten TLS-Zertifikaten und deren Anfügen an ALBs mit einer modernen TLS-Richtlinie (TLS 1.2/1.3), und konfigurieren Sie Datenbanken und Clients so, dass sie TLS-Verbindungen erfordern.
- Verhindern Sie ein erneutes Auftreten durch Guardrails: Wenden Sie Service Control Policies an, um die Erstellung/Freigabe von unverschlüsselten Snapshots und unverschlüsselte S3-Puts zu verweigern, aktivieren Sie AWS Config-Regeln für verschlüsselte Ressourcen und überwachen Sie die Nutzung von KMS und Secrets Manager über CloudTrail und CloudWatch Alarms.
Begründung: Zentrale CMKs mit Richtlinien auf Organisationsebene, automatisierte Neuverschlüsselung, Secrets Manager für den Lebenszyklus von Secrets, Durchsetzung von TLS und präventive Guardrails folgen den AWS Best Practices für Least Privilege und Defense-in-Depth, um Klartext-Secrets und unbefugten Zugriff auf Snapshots zu eliminieren.
Kundenverwaltete CMKs: Multi-Region, importiertes Schlüsselmaterial und Schlüsselrichtlinien
Ein kundenverwalteter CMK ist die Steuerungsebene für jede kryptografische Operation auf Daten, die Sie in AWS besitzen. Die drei Eigenschaften, die am häufigsten darüber entscheiden, ob ein Design erfolgreich ist oder einen Ausfall verursacht, sind die Regions-Topologie des Schlüssels, der Ursprung seines Schlüsselmaterials und die ihm angehängte Richtlinie.
Multi-Region-Schlüssel sind ein Satz von KMS-Schlüsseln in verschiedenen Regionen, die dieselbe Schlüssel-ID und, was entscheidend ist, dasselbe zugrunde liegende Schlüsselmaterial teilen. Sie werden nicht automatisch repliziert wie DynamoDB Global Tables – Sie erstellen Replikate explizit aus einem primären Schlüssel mit ReplicateKey. Da das Schlüsselmaterial über alle Replikate hinweg identisch ist, kann in us-east-1 erzeugter Chiffretext in us-west-1 ohne regionsübergreifende KMS-Aufrufe entschlüsselt werden. Dies ist genau die Eigenschaft, die bei der Replikation eines Secrets Manager-Secrets über Regionen hinweg erforderlich ist: Das Replikat-Secret in der Failover-Region muss lokal entschlüsselbar sein, sowohl um die regionsübergreifende Latenz bei jedem GetSecretValue-Aufruf zu eliminieren als auch um einen regionalen Ausfall der primären Region zu überstehen. Ein Single-Region-CMK kann kein Secrets Manager-Replikat in einer anderen Region unterstützen. Das korrekte Muster besteht also darin, das primäre Secret mit einem Multi-Region-CMK zu verschlüsseln, den Schlüssel in die Zielregion zu replizieren und dann das Secret zu replizieren, während man auf das Replikat des CMK verweist.
aws kms create-key --multi-region --region us-east-1
aws kms replicate-key --key-id mrk-abc123 \
--replica-region us-west-1
aws secretsmanager replicate-secret-to-regions \
--secret-id prod/db \
--add-replica-regions Region=us-west-1,KmsKeyId=mrk-abc123
Importiertes Schlüsselmaterial (externer Ursprung, Origin=EXTERNAL) liegt vor, wenn Sie das rohe AES-256-Material außerhalb von AWS generieren und es in eine KMS-Schlüsselhülle importieren. AWS hat niemals eine Kopie dieses Materials außerhalb des geschützten Speichers des HSM, und es gibt kein Backup. Wenn Sie das importierte Material löschen – sei es über DeleteImportedKeyMaterial oder weil sein Ablaufdatum überschritten wurde – geht der Schlüssel in den Zustand PendingImport über, und jeder unter diesem Schlüssel erzeugte Chiffretext ist unwiederherstellbar, es sei denn, Sie importieren exakt dieselben Bytes erneut. Dies ist der Wiederherstellungspfad, wenn beispielsweise ein EBS-Volume nicht angehängt werden kann, weil sein verschlüsselter Datenschlüssel nicht entschlüsselt werden kann: Importieren Sie das identische Schlüsselmaterial aus Ihrer Offline-Verwahrung (Escrow) erneut, und das Volume wird wieder verwendbar. Es gibt keine AWS-seitige Wiederherstellung, keinen Rotations-Trick und kein Support-Ticket, das gelöschtes importiertes Material wiederherstellen kann. Behandeln Sie die Offline-Kopie als Tier-Zero-Infrastruktur.
Schlüsselrichtlinien sind die Vertrauensbasis (Root of Trust) für jeden KMS-Schlüssel. Im Gegensatz zu IAM allein erfordert KMS eine explizite Erlaubnis (Allow) in der Schlüsselrichtlinie selbst; eine IAM-Richtlinie, die kms:Decrypt gewährt, ist unwirksam, es sei denn, die Schlüsselrichtlinie delegiert an IAM (eine Kombination aus "Principal": {"AWS": "arn:aws:iam::111122223333:root"} und einer Bedingungsanweisung). Für die kontoübergreifende Nutzung muss die Richtlinie des Schlüssels das externe Konto oder den Prinzipal explizit benennen, und das externe Konto muss dann seinen eigenen Benutzern die Berechtigung über IAM erteilen. Das Vergessen der Schlüsselrichtlinien-Seite ist die häufigste Ursache für kontoübergreifende Fehler im Secrets Manager – die Ressourcenrichtlinie des Secrets Manager erlaubt dem externen Prinzipal den Aufruf von GetSecretValue, aber der zugrunde liegende Decrypt-Vorgang schlägt fehl, weil der CMK den Aufrufer immer noch abweist.
Muster für Secrets Manager und Parameter Store SecureString
Sowohl Secrets Manager als auch SSM Parameter Store SecureStrings delegieren die Verschlüsselung an KMS, unterscheiden sich aber in Kosten, Rotationssemantik und regionsübergreifendem Verhalten. Secrets Manager unterstützt native Multi-Region-Replikation, Versionierung mit Staging-Labels (AWSCURRENT, AWSPENDING) und Lambda-gestützte Rotation. Parameter Store SecureString ist kostengünstiger, lässt sich in hierarchische Pfade integrieren und eignet sich gut für Geheimnisse im Konfigurationsstil, die selten rotieren.
Für den kontoübergreifenden Zugriff müssen Sie sowohl die Ressourcenrichtlinie für das Secret (oder die IAM-Richtlinie im konsumierenden Konto des Parameter Store) als auch die KMS-Schlüsselrichtlinie für den verschlüsselnden CMK aktualisieren. Die Annahme, dass allein die Berechtigungen des Secrets Manager ausreichen, ist falsch, da der Abrufvorgang immer einen impliziten kms:Decrypt-Aufruf gegen den CMK durchführt. Ohne eine Erlaubnis in der Schlüsselrichtlinie für das externe Konto erhält der Aufrufer eine AccessDeniedException beim Decrypt-Schritt, obwohl die eigene Richtlinie des Secrets erfüllt ist.
- Secrets Manager: verwaltete Rotation, JSON-Struktur, ~$0,40/Secret/Monat, integrierte Multi-Region-Replikation
- Parameter Store SecureString (Advanced): günstiger bei vielen Werten, 8 KB pro Parameter, keine integrierte regionsübergreifende Replikation
- Parameter Store SecureString (Standard): kostenloses Kontingent (Free Tier) für KMS-verschlüsselte Parameter bis zu 4 KB, kein Rotations-Framework
Envelope-Verschlüsselung, Bucket-Schlüssel und Grant-Tokens
Envelope-Verschlüsselung (Umschlagverschlüsselung) bedeutet, dass KMS Ihre Massendaten niemals direkt verarbeitet. Sie rufen GenerateDataKey auf, was sowohl einen Klartext-Datenschlüssel (der lokal zur Verschlüsselung Ihrer Nutzdaten mit AES-GCM verwendet wird) als auch eine verschlüsselte Kopie dieses Datenschlüssels (die zusammen mit dem Chiffretext gespeichert wird) zurückgibt. Zum Entschlüsseln rufen Sie Decrypt für den verschlüsselten Datenschlüssel auf und leiten den Klartextschlüssel lokal wieder ab. Dieses Muster ist unerlässlich, da KMS Anforderungsquoten (pro Region, pro Schlüssel) und Preise pro API-Aufruf hat. Wenn Sie jeden 4-KB-Datensatz mit einem direkten Encrypt-Aufruf verschlüsseln, werden Sie auf Drosselungen und Kostenfallen stoßen; wenn Sie einen Datenschlüssel pro Stapel oder pro Datei generieren, skaliert der Durchsatz linear mit Ihrer lokalen Krypto-Bibliothek.
S3 Bucket Keys wenden dasselbe Prinzip innerhalb von S3 für SSE-KMS an. Ohne einen Bucket-Schlüssel erzeugt jedes PUT und GET eines SSE-KMS-Objekts einen GenerateDataKey- oder Decrypt-Aufruf. Bei einem Bucket, der Tausende von Objekten pro Sekunde empfängt, führt dies sowohl zu KMS-Drosselungen als auch zu einer überraschend hohen KMS-Rechnung. Die Aktivierung eines Bucket-Schlüssels bewirkt, dass S3 einen kurzlebigen Schlüssel auf Bucket-Ebene generiert und diesen für viele Objekte wiederverwendet, wodurch das KMS-Anforderungsvolumen um Größenordnungen reduziert wird:
aws s3api put-bucket-encryption --bucket app-data \
--server-side-encryption-configuration '{
"Rules":[{
"ApplyServerSideEncryptionByDefault":{
"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/app"},
"BucketKeyEnabled":true}]}'
Grants sind eine Alternative zu Schlüsselrichtlinien für eine temporäre, feingranulare Delegierung. Sie sind aus betrieblicher Sicht wegen der Eventual Consistency von Bedeutung: Nachdem CreateGrant zurückgekehrt ist, ist der Grant nicht sofort für jeden KMS-Endpunkt in der Region sichtbar. Wenn ein Client wenige Millisekunden später einen Encrypt-Versuch unternimmt, kann er eine AccessDeniedException erhalten. Der Antwortkörper von CreateGrant enthält eine GrantToken-Zeichenfolge, die, wenn sie bei nachfolgenden KMS-Aufrufen über den Parameter --grant-tokens übergeben wird, KMS zwingt, den Grant sofort anzuerkennen, unabhängig vom Propagierungsstatus.
TOKEN=$(aws kms create-grant --key-id $KEY \
--grantee-principal arn:aws:iam::111122223333:role/worker \
--operations Encrypt Decrypt --query GrantToken --output text)
aws kms encrypt --key-id $KEY --plaintext fileb://payload \
--grant-tokens "$TOKEN"
Sich auf Wiederholungsversuche mit Backoff anstelle des Grant-Tokens zu verlassen, ist eine gültige, aber schlechtere Abhilfemaßnahme – sie verschwendet Latenz und schlägt unter Last immer noch fehl. Die Standardantwort lautet immer: Geben Sie den Grant-Token von dem Dienst zurück, der den Grant erstellt, und verlangen Sie von den Aufrufern, ihn bei ihrer ersten Operation vorzulegen.
Praktisches Problem: Anwendungsfallszenario
Szenario: Meridian Financial betreibt eine AWS-Umgebung mit mehreren Konten, in der personenbezogene Daten (PII) von Kunden in S3, Transaktionsdatenbanken in RDS und serverlose Verarbeitung über Lambda gehostet werden. Sie verwenden kundenseitig verwaltete CMKs mit importiertem Schlüsselmaterial, um regionale Vorschriften zur Schlüsselaufbewahrung zu erfüllen, und replizieren Schlüssel für die Notfallwiederherstellung (Disaster Recovery) in eine zweite Region.
Herausforderung: Eine kürzlich durchgeführte Prüfung ergab eine falsch konfigurierte KMS-Schlüsselrichtlinie, die kontoübergreifende Entschlüsselungen erlaubte. Ein externer Prüfer benötigt temporären Zugriff, um eine Teilmenge von S3-Objekten zu entschlüsseln. Zudem benötigt Meridian eine sichere Rotation von Geheimnissen und eine effiziente Verschlüsselung für große Objekte, um die Kosten für KMS-Anfragen zu kontrollieren.
Empfohlener Ansatz:
- Ersetzen Sie die falsch konfigurierte CMK-Richtlinie in AWS KMS durch eine Richtlinie mit den geringsten Rechten (Least Privilege), die explizit nur den erforderlichen IAM-Prinzipalen und -Rollen Berechtigungen erteilt, und erstellen Sie einen Multi-Region-Replikat-CMK für DR unter Verwendung von KMS Multi-Region Keys.
- Importieren Sie das Schlüsselmaterial erneut oder planen Sie dessen Lebenszyklusverwaltung gemäß den Compliance-Zeitfenstern und aktivieren Sie automatische Benachrichtigungen über den Ablauf/die Rotation des Schlüsselmaterials mithilfe von AWS Config und EventBridge.
- Erstellen Sie für den Prüfer einen KMS-Grant mit einer kurzen TTL und verwenden Sie den Grant-Token sofort in der Assume-Role-Sitzung des Prüfers, um temporäre Entschlüsselungsvorgänge zu ermöglichen, ohne die Schlüsselrichtlinie zu ändern.
- Verschieben Sie langlebige Anmeldeinformationen in den AWS Secrets Manager mit Lambda-basierter Rotation, die an den zugrunde liegenden Dienst (RDS- oder API-Schlüssel) gebunden ist, und speichern Sie Infrastrukturparameter als SecureString im Systems Manager Parameter Store für nicht rotierende Elemente. Erzwingen Sie dabei die Verschlüsselung mit dem CMK sowie strenge ressourcenbasierte Richtlinien.
- Implementieren Sie die Envelope-Verschlüsselung für große S3-Objekte, indem Sie KMS
GenerateDataKey(Encrypt/Decrypt) im Anwendungscode oder über das AWS SDK aufrufen, und aktivieren Sie S3 Bucket Keys, um die Anzahl der KMS-Anfragen und die Kosten für die serverseitige Verschlüsselung großer Objekte zu reduzieren. - Aktivieren Sie die Protokollierung mit CloudTrail und die Protokollierung der KMS-Schlüsselnutzung, und erstellen Sie CloudWatch Alarms/GuardDuty-Regeln, um bei unerwarteten Entschlüsselungen oder der Erstellung von Grants zu warnen.
Begründung: Dieser Ansatz erzwingt den Schlüsselzugriff nach dem Prinzip der geringsten Rechte (Least Privilege), gewährleistet die Compliance für importiertes Material und die Multi-Region-Kontinuität, verwendet temporäre Grants für den sicheren Zugriff durch Dritte, zentralisiert Geheimnisse mit Rotation und optimiert die KMS-Nutzung und -Kosten gemäß den AWS Best Practices.
← Protokollierung · Alle Domänen · Datenschutz und S3 →
Diese Fragen üben → · Zeitlich begrenzte Übung auf 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.
Bestehe deine Prüfung →