KMS AccessDeniedException: Key-Policy- und Grant-Fehlkonfigurationen beheben

Sie migrieren eine Anwendung in ein neues AWS-Konto und plötzlich schlagen S3-Leseoperationen mit diesem Fehler fehl:

An error occurred (AccessDeniedException) when calling the Decrypt operation:
The ciphertext refers to a customer master key that does not exist, does not
exist in this region, or you are not allowed to access.

Oder vielleicht scheitert die Kopie Ihres EBS-Volume-Snapshots mit:

An error occurred (AccessDeniedException) when calling the CreateGrant
operation: User: arn:aws:iam::123456789012:role/MyRole is not authorized
to perform: kms:CreateGrant on resource: arn:aws:kms:us-east-1:...

Die KMS AccessDeniedException ist einer der verwirrendsten AWS-Fehler, weil KMS ein duales Autorisierungsmodell hat. Anders als bei den meisten AWS-Services, bei denen IAM-Policies allein den Zugriff steuern, erfordert KMS eine Autorisierung sowohl durch die Key Policy als auch durch IAM-Policies. Fehlt eine der beiden Schichten, erhalten Sie eine AccessDeniedException mit einer Nachricht, die nicht verrät, welche Ebene den Zugriff blockiert hat.

Nach Jahren des Debuggens von KMS-Problemen bei Kunden habe ich festgestellt, dass die Ursache in eine von fünf Kategorien fällt. Hier erfahren Sie, wie Sie jede einzelne diagnostizieren und beheben.

Das KMS-Autorisierungsmodell verstehen

Bevor wir in die Fehlerbehebung einsteigen, müssen Sie verstehen, wie sich die KMS-Autorisierung von Standard-IAM unterscheidet. KMS verwendet ein Zwei-Schichten-Modell:

1. Key Policy — Die ressourcenbasierte Policy, die direkt an den KMS-Schlüssel angehängt ist. Dies ist der primäre Autorisierungsmechanismus.
2. IAM-Policies — Standard-IAM-Policies, die dem aufrufenden Principal (Benutzer, Rolle oder Gruppe) zugeordnet sind.

Der entscheidende Punkt: Eine KMS-Key-Policy kann entweder direkt Zugriff gewähren oder Zugriffsentscheidungen an IAM delegieren. Wenn die Key Policy die Root-Account-Anweisung nicht enthält, die IAM-Policies aktiviert, können IAM-Policies allein keinen Zugriff gewähren — egal welche Berechtigungen sie enthalten.

Ursache 1: Key Policy aktiviert IAM-Policies nicht

Dies ist die einzeln häufigste Ursache für KMS AccessDeniedException. Wenn Sie einen KMS-Schlüssel über die Konsole erstellen, fügt AWS automatisch diese Anweisung zur Key Policy hinzu:

{
  "Sid": "Enable IAM policies",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:root"
  },
  "Action": "kms:*",
  "Resource": "*"
}

Diese Anweisung gewährt niemandem direkt Zugriff. Sie teilt KMS mit, IAM-Policies bei Autorisierungsentscheidungen zu berücksichtigen. Ohne sie können nur Principals, die explizit in der Key Policy genannt sind, den Schlüssel verwenden.

Diagnose

Rufen Sie die Key Policy ab und prüfen Sie auf die Root-Account-Anweisung:

aws kms get-key-policy \
  --key-id arn:aws:kms:us-east-1:123456789012:key/mrk-abc123 \
  --policy-name default \
  --output text | python3 -m json.tool

Suchen Sie nach einer Anweisung mit "Principal": {"AWS": "arn:aws:iam::ACCOUNT_ID:root"}. Wenn sie fehlt, werden IAM-Policies für diesen Schlüssel ignoriert.

Lösung

Fügen Sie die Root-Account-Anweisung zur Key Policy hinzu. Sie müssen ein bestehender Key-Administrator sein, um dies zu tun:

# Aktuelle Policy abrufen
aws kms get-key-policy \
  --key-id mrk-abc123 \
  --policy-name default \
  --output text > /tmp/key-policy.json

# Policy bearbeiten und Root-Anweisung hinzufügen, dann anwenden
aws kms put-key-policy \
  --key-id mrk-abc123 \
  --policy-name default \
  --policy file:///tmp/key-policy.json

Ursache 2: Fehlende spezifische KMS-Berechtigungen in IAM

Auch wenn die Key Policy IAM-Policies aktiviert, benötigen Sie die korrekten KMS-Aktionen. Verschiedene Operationen erfordern unterschiedliche Berechtigungen, und hier machen viele Teams Fehler.

Hier ist eine Zuordnung häufiger Operationen zu erforderlichen KMS-Berechtigungen:

Diagnose

Prüfen Sie, welche KMS-Berechtigungen die aufrufende Rolle hat:

# KMS-Aktion simulieren, um zu prüfen, ob IAM sie erlaubt
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/MyRole \
  --action-names kms:Decrypt kms:GenerateDataKey kms:CreateGrant kms:DescribeKey \
  --resource-arns arn:aws:kms:us-east-1:123456789012:key/mrk-abc123 \
  --query 'EvaluationResults[*].{Action:EvalActionName,Decision:EvalDecision}'

Lösung

Fügen Sie die erforderlichen KMS-Berechtigungen zur IAM-Policy hinzu. Hier ist eine Policy, die die gängigsten Verschlüsselungsoperationen abdeckt:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowKMSOperations",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyWithoutPlaintext",
        "kms:DescribeKey",
        "kms:ReEncryptFrom",
        "kms:ReEncryptTo"
      ],
      "Resource": "arn:aws:kms:us-east-1:123456789012:key/mrk-abc123"
    }
  ]
}

Für Operationen, die Grants erfordern (EBS, RDS, etc.), fügen Sie auch hinzu:

{
  "Sid": "AllowKMSGrants",
  "Effect": "Allow",
  "Action": [
    "kms:CreateGrant",
    "kms:ListGrants",
    "kms:RevokeGrant"
  ],
  "Resource": "arn:aws:kms:us-east-1:123456789012:key/mrk-abc123",
  "Condition": {
    "Bool": {
      "kms:GrantIsForAWSResource": "true"
    }
  }
}

Ursache 3: Cross-Account-KMS-Zugriff nicht konfiguriert

Der Zugriff auf einen KMS-Schlüssel in einem anderen AWS-Konto erfordert Konfiguration auf beiden Seiten — die Key Policy im Konto des Schlüssels und die IAM-Policy im aufrufenden Konto. Fehlt eine Seite, führt dies zu AccessDeniedException.

Diagnose

Identifizieren Sie, ob kontoübergreifender Zugriff beteiligt ist, indem Sie das Konto des Schlüssels mit dem Konto der aufrufenden Rolle vergleichen:

# Konto des Schlüssels aus seiner ARN abrufen
aws kms describe-key \
  --key-id arn:aws:kms:us-east-1:111111111111:key/mrk-abc123 \
  --query 'KeyMetadata.{Account:AWSAccountId,KeyId:KeyId,KeyState:KeyState}'

Wenn die Konto-ID in der Schlüssel-ARN sich von dem Konto Ihres Aufrufers unterscheidet, benötigen Sie ein Cross-Account-Setup.

Lösung

Im Konto des Schlüsselbesitzers muss die Key Policy das externe Konto zulassen:

{
  "Sid": "AllowCrossAccountAccess",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::222222222222:root"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

Im aufrufenden Konto muss die IAM-Policy die gleichen Aktionen auf die Cross-Account-Schlüssel-ARN erlauben. Beide Seiten sind erforderlich.

Ursache 4: KMS-Schlüssel ist deaktiviert oder zur Löschung vorgesehen

Ein KMS-Schlüssel, der deaktiviert oder zur Löschung vorgesehen ist, lehnt alle kryptografischen Operationen mit AccessDeniedException ab. Die Fehlermeldung gibt den Schlüsselstatus nicht immer deutlich an.

Diagnose

Prüfen Sie den Schlüsselstatus:

aws kms describe-key \
  --key-id mrk-abc123 \
  --query 'KeyMetadata.{KeyState:KeyState,DeletionDate:DeletionDate,Enabled:Enabled,Description:Description}'

Das Feld KeyState hat einen der Werte: Enabled, Disabled, PendingDeletion, PendingImport oder Unavailable.

Lösung

Wenn der Schlüssel deaktiviert ist, aktivieren Sie ihn erneut:

aws kms enable-key --key-id mrk-abc123

Wenn der Schlüssel zur Löschung vorgesehen ist, brechen Sie die Löschung ab (sofern noch innerhalb der Wartezeit):

aws kms cancel-key-deletion --key-id mrk-abc123
aws kms enable-key --key-id mrk-abc123

Ursache 5: Fehlende KMS-Grants für AWS-Services

Mehrere AWS-Services verwenden KMS-Grants statt IAM-Policies für Verschlüsselungsoperationen. Wenn EBS ein Volume verschlüsselt, RDS einen Snapshot verschlüsselt oder Lambda Umgebungsvariablen entschlüsselt, erstellt der Service in Ihrem Namen einen KMS-Grant. Wenn der aufrufende Principal keine kms:CreateGrant-Berechtigung hat, schlagen diese Service-Operationen fehl.

Diagnose

Listen Sie bestehende Grants auf dem Schlüssel auf, um zu sehen, ob der erwartete Service-Grant existiert:

aws kms list-grants \
  --key-id mrk-abc123 \
  --query 'Grants[*].{
    GrantId:GrantId,
    Grantee:GranteePrincipal,
    Operations:Operations,
    RetiringPrincipal:RetiringPrincipal
  }'

Lösung

Stellen Sie sicher, dass der aufrufende Principal die kms:CreateGrant-Berechtigung mit der Bedingung kms:GrantIsForAWSResource hat. Dies beschränkt die Grant-Erstellung auf AWS-Services und folgt dem Prinzip der geringsten Berechtigung.

Sie können auch manuell einen Grant zum Testen erstellen:

aws kms create-grant \
  --key-id mrk-abc123 \
  --grantee-principal arn:aws:iam::123456789012:role/MyRole \
  --operations Decrypt GenerateDataKey \
  --retiring-principal arn:aws:iam::123456789012:role/MyRole

Systematischer Debugging-Ansatz

Wenn Sie eine KMS AccessDeniedException begegnen, folgen Sie dieser Checkliste in der Reihenfolge:

# 1. Schlüssel identifizieren
aws kms describe-key --key-id KEY_ID \
  --query 'KeyMetadata.{State:KeyState,Account:AWSAccountId,Manager:KeyManager}'

# 2. Key Policy prüfen
aws kms get-key-policy --key-id KEY_ID --policy-name default --output text

# 3. IAM-Berechtigungen des Aufrufers prüfen
aws iam simulate-principal-policy \
  --policy-source-arn CALLER_ARN \
  --action-names kms:Decrypt kms:GenerateDataKey \
  --resource-arns KEY_ARN

# 4. Bestehende Grants prüfen
aws kms list-grants --key-id KEY_ID

# 5. Bei Cross-Account beide Seiten verifizieren

Best Practices zur Prävention

AWS-Managed Keys verwenden, wenn möglich

Wenn Sie keinen kontoübergreifenden Zugriff oder benutzerdefinierte Key Policies benötigen, verwenden Sie AWS-managed Keys (Alias aws/s3, aws/ebs, etc.). Sie handhaben die Autorisierung automatisch durch IAM-Policies allein.

Schlüsselverwaltung zentralisieren

Pflegen Sie eine Schlüsselverwaltungsstrategie, die dokumentiert, welche Schlüssel von welchen Services verwendet werden und welche Principals Zugriff haben. Verwenden Sie Tags, um den Schlüsselbesitz zu verfolgen:

aws kms tag-resource \
  --key-id mrk-abc123 \
  --tags \
    TagKey=Owner,TagValue=platform-team \
    TagKey=Environment,TagValue=production \
    TagKey=Application,TagValue=payment-service

Schlüsselnutzung mit CloudTrail überwachen

Alle KMS-API-Aufrufe werden in CloudTrail protokolliert. Richten Sie Alarme für AccessDeniedException-Ereignisse ein, um Fehlkonfigurationen frühzeitig zu erkennen:

aws logs create-metric-filter \
  --log-group-name CloudTrail/DefaultLogGroup \
  --filter-name KMSAccessDenied \
  --filter-pattern '{ $.eventSource = "kms.amazonaws.com" && $.errorCode = "AccessDeniedException" }' \
  --metric-transformations \
    metricName=KMSAccessDeniedCount,metricNamespace=Security,metricValue=1

Schlüsselzugriff vor dem Deployment testen

Fügen Sie einen Validierungsschritt hinzu, der den KMS-Zugriff vor dem Deployment von Ressourcen überprüft, die von Verschlüsselung abhängen:

# Decrypt-Zugriff testen
aws kms decrypt \
  --key-id mrk-abc123 \
  --ciphertext-blob fileb://test-encrypted.bin \
  --query 'KeyId' 2>&1 || echo "KMS-Zugriffsprüfung fehlgeschlagen"

Brauchen Sie Hilfe bei der AWS-Verschlüsselung?

KMS-Fehlkonfigurationen sind eine Hauptursache für Deployment-Fehler und Datenzugriffsprobleme in AWS-Umgebungen. Wir haben Dutzenden von Organisationen geholfen, ihre KMS-Key-Policies zu entwirren und Best Practices für die Verschlüsselung zu etablieren. Wenn Sie mit AccessDeniedException-Fehlern kämpfen oder eine kontoübergreifende Verschlüsselungsstrategie entwerfen müssen, können wir helfen.

Kontaktieren Sie uns für eine kostenlose AWS-Beratung