

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# ABAC für AWS KMS
<a name="abac"></a>

Die attributebasierte Zugriffskontrolle (ABAC) ist eine Autorisierungsstrategie, die Berechtigungen auf der Grundlage von Attributen definiert. AWS KMS unterstützt ABAC, indem es Ihnen ermöglicht, den Zugriff auf Ihre vom Kunden verwalteten Schlüssel auf der Grundlage der mit den KMS-Schlüsseln verknüpften Tags und Aliasnamen zu kontrollieren. Die Tag- und Alias-Bedingungsschlüssel, die ABAC ermöglichen, AWS KMS bieten eine leistungsstarke und flexible Möglichkeit, Principals zur Verwendung von KMS-Schlüsseln zu autorisieren, ohne Richtlinien bearbeiten oder Zuschüsse verwalten zu müssen. Sie sollten diese Funktion jedoch mit Vorsicht verwenden, damit Prinzipalen der Zugriff nicht versehentlich zugelassen oder verweigert wird. 

Wenn Sie ABAC verwenden, beachten Sie, dass die Berechtigung zum Verwalten von Tags und Aliassen jetzt eine Zugriffssteuerungs-Berechtigung ist. Stellen Sie sicher, dass Sie die vorhandenen Tags und Aliasse für alle KMS-Schlüssel kennen, bevor Sie eine Richtlinie bereitstellen, die von Tags oder Aliassen abhängt. Treffen Sie angemessene Vorsichtsmaßnahmen beim Hinzufügen, Löschen und Aktualisieren von Aliassen sowie beim Markieren und Entmarkieren von Schlüsseln. Erteilen Sie Berechtigungen zum Verwalten von Tags und Aliassen nur Prinzipalen, die sie benötigen, und beschränken Sie die Tags und Aliasse, die sie verwalten können. 

**Hinweise**  
Achten Sie bei der Verwendung von ABAC für darauf AWS KMS, den Prinzipalen die Erlaubnis zur Verwaltung von Tags und Aliasnamen zu erteilen. Wenn Sie ein Tag oder einen Alias ändern, wird die Berechtigung für einen KMS-Schlüssel eventuell erlaubt oder verweigert. Schlüsseladministratoren, die nicht über die Berechtigung zum Ändern von Schlüsselrichtlinien oder zum Erstellen von Erteilungen verfügen, können den Zugriff auf KMS-Schlüssel steuern, wenn sie über die Berechtigung zum Verwalten von Tags oder Aliassen verfügen.   
Es kann bis zu fünf Minuten dauern, bis Tag- und Alias-Änderungen Auswirkungen auf die KMS-Schlüsselautorisierung haben. Letzte Änderungen sind möglicherweise in API-Operationen sichtbar, bevor sie sich auf die Autorisierung auswirken.  
Um den Zugriff auf einen KMS-Schlüssel basierend auf seinem Alias zu steuern, müssen Sie einen Bedingungsschlüssel verwenden. Sie können keinen Alias verwenden, um einen KMS-Schlüssel im `Resource`-Element einer Richtlinienanweisung darzustellen. Wenn ein Alias im `Resource`-Element erscheint, gilt die Richtlinienanweisung für den Alias und nicht für den zugeordneten KMS-Schlüssel.

**Weitere Informationen**
+ Einzelheiten zur AWS KMS Unterstützung von ABAC, einschließlich Beispielen, finden Sie unter und. [Verwenden Sie Aliase, um den Zugriff auf KMS-Schlüssel zu steuern](alias-authorization.md) [Verwenden Sie Tags, um den Zugriff auf KMS-Schlüssel zu steuern](tag-authorization.md)
+ Weitere allgemeine Informationen zur Verwendung von Tags zur Steuerung des Zugriffs auf AWS Ressourcen finden Sie unter [Wozu dient ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)? AWS und [Steuern des Zugriffs auf AWS Ressourcen mithilfe von Ressourcen-Tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) im *IAM-Benutzerhandbuch*.

## ABAC-Bedingungsschlüssel für AWS KMS
<a name="about-abac-kms"></a>

Verwenden Sie die folgenden Bedingungsschlüssel in einer Schlüsselrichtlinie oder IAM-Richtlinie, um den Zugriff auf KMS-Schlüssel basierend auf deren Tags und Aliassen zu autorisieren.


| ABAC-Bedingungsschlüssel | Description | Richtlinientyp | AWS KMS Operationen | 
| --- | --- | --- | --- | 
| [als: ResourceTag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) | Tag (Schlüssel und Wert) auf dem KMS-Schlüssel entspricht dem Tag (Schlüssel und Wert) oder dem Tagmuster in der Richtlinie | Nur IAM-Richtlinie | KMS-Schlüsselressourcen-Operationen 2 | 
| [aws:RequestTag/*Tag-Schlüssel*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag) | Tag (Schlüssel und Wert) in der Anforderung entspricht dem Tag (Schlüssel und Wert) oder dem Tagmuster in der Richtlinie | Wichtige Richtlinien und IAM-Richtlinien 1 | [TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html), [UntagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_UntagResource.html) | 
| [aws: TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys) | Die Tag-Schlüssel in der Anforderung entsprechen den Tag-Schlüsseln in der Richtlinie | Schlüsselrichtlinien und IAM-Richtlinien 1 | [TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html), [UntagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_UntagResource.html) | 
| [km: ResourceAliases](conditions-kms.md#conditions-kms-resource-aliases) | Aliasse, die dem KMS-Schlüssel zugeordnet sind, stimmen mit den Aliassen oder Aliasmustern in der Richtlinie überein | Nur IAM-Richtlinie | KMS-Schlüsselressourcen-Operationen 2 | 
| [km: RequestAlias](conditions-kms.md#conditions-kms-request-alias) | Der Alias, der den KMS-Schlüssel in der Anforderung darstellt, entspricht dem Alias oder den Aliasmustern in der Richtlinie. | Schlüsselrichtlinien und IAM-Richtlinien 1 | [Kryptografische Operationen](kms-cryptography.md#cryptographic-operations), [DescribeKey[GetPublicKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetPublicKey.html)](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) | 

1 Jeder Bedingungsschlüssel, der in einer Schlüsselrichtlinie verwendet werden kann, kann auch in einer IAM-Richtlinie verwendet werden, jedoch nur, wenn [die Schlüsselrichtlinie es erlaubt](key-policy-default.md#key-policy-default-allow-root-enable-iam).

2Eine *KMS-Schlüsselressourcen-Operation* ist eine Operation, die für einen bestimmten KMS-Schlüssel autorisiert ist. Um die KMS-Schlüsselressourcen-Operationen zu identifizieren, suchen Sie in der Tabelle mit [AWS KMS -Berechtigungen](kms-api-permissions-reference.md#kms-api-permissions-reference-table) nach dem Wert des KMS-Schlüssels in der `Resources`-Spalte für die Operation. 

Beispielsweise können Sie diese Bedingungsschlüssel verwenden, um die folgenden Richtlinien zu erstellen.
+ Eine IAM-Richtlinie mit `kms:ResourceAliases`, die die Berechtigung zur Verwendung von KMS-Schlüsseln mit einem bestimmten Alias oder Aliasmuster ermöglicht. Dies unterscheidet sich ein wenig von Richtlinien, die auf Tags basieren: Sie können zwar Aliasmuster in einer Richtlinie verwenden, aber jeder Alias muss in einer AWS-Konto UND-Region eindeutig sein. Auf diese Weise können Sie eine Richtlinie auf einen ausgewählten Satz von KMS-Schlüsseln anwenden, ohne die Schlüssel ARNs der KMS-Schlüssel in der Richtlinienerklärung aufzulisten. Um KMS-Schlüssel aus dem Satz hinzuzufügen oder zu entfernen, ändern Sie den Alias des KMS-Schlüssels.
+ Eine Schlüsselrichtlinie mit `kms:RequestAlias`, die es Prinzipalen ermöglicht, einen KMS-Schlüssel in einer `Encrypt`-Operation zu nutzen, aber nur dann, wenn die `Encrypt`-Anforderung diesen Alias verwendet, um den KMS-Schlüssel zu identifizieren.
+ Eine IAM-Richtlinie mit `aws:ResourceTag/tag-key`, die die Berechtigung zur Verwendung von KMS-Schlüsseln mit einem bestimmten Tag-Schlüssel und Tag-Wert verweigert. Auf diese Weise können Sie eine Richtlinie auf einen ausgewählten Satz von KMS-Schlüsseln anwenden, ohne den Schlüssel ARNs der KMS-Schlüssel in der Richtlinienerklärung aufzulisten. Um KMS-Schlüssel aus dem Satz hinzuzufügen oder zu entfernen, markieren oder entmarkieren Sie den KMS-Schlüssel.
+ Eine IAM-Richtlinie mit `aws:RequestTag/tag-key`, die es Prinzipalen erlaubt, nur `"Purpose"="Test"`-Tags von KMS-Schlüsseln zu löschen. 
+ Eine IAM-Richtlinie mit `aws:TagKeys`, die die Berechtigung zur Markierung oder Entmarkierung eines KMS-Schlüssels mit einem `Restricted`-Tag-Schlüssel verweigert.

ABAC macht das Zugriffsmanagement flexibel und skalierbar. Sie können beispielsweise den `aws:ResourceTag/tag-key`-Bedingungsschlüssel verwenden, um eine IAM-Richtlinie zu erstellen, die es Prinzipalen erlaubt, einen KMS-Schlüssel für bestimmte Operationen nur dann zu verwenden, wenn der KMS-Schlüssel einen `Purpose=Test`-Tag hat. Die Richtlinie gilt für alle KMS-Schlüssel in allen Regionen des AWS-Konto.

Wenn sie einem Benutzer oder einer Rolle zugeordnet ist, können Prinzipale mit der folgenden IAM-Richtlinie alle vorhandenen KMS-Schlüssel mit einem`Purpose=Test`-Tag für die angegebenen Operationen nutzen. Um diesen Zugriff auf neue oder vorhandene KMS-Schlüssel zu gewähren, müssen Sie die Richtlinie nicht ändern. Fügen Sie einfach das `Purpose=Test`-Tag de KMS-Schlüsseln an. Um diesen Zugriff von KMS-Schlüsseln mit einem `Purpose=Test`-Tag zu entfernen, bearbeiten oder löschen Sie das Tag. 

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AliasBasedIAMPolicy",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "arn:aws:kms:*:111122223333:key/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Purpose": "Test"
        }
      }
    }
  ]
}
```

------

Wenn Sie diese Funktion verwenden, sollten Sie jedoch vorsichtig sein, wenn Sie Tags und Aliasse verwalten. Das Hinzufügen, Ändern oder Löschen eines Tags oder Aliasses kann versehentlich den Zugriff auf einen KMS-Schlüssel zulassen oder verweigern. Schlüsseladministratoren, die nicht über die Berechtigung zum Ändern von Schlüsselrichtlinien oder zum Erstellen von Erteilungen verfügen, können den Zugriff auf KMS-Schlüssel steuern, wenn sie über die Berechtigung zum Verwalten von Tags oder Aliassen verfügen. Um dieses Risiko zu mindern, sollten Sie [Berechtigungen zum Verwalten von Tags](tag-permissions.md#tag-permissions-conditions) und [Aliassen](alias-access.md#alias-access-limiting) beschränken. Sie können es beispielsweise nur ausgewählten Prinzipalen erlauben, `Purpose=Test`-Tags zu verwalten. Details dazu finden Sie unter [Verwenden Sie Aliase, um den Zugriff auf KMS-Schlüssel zu steuern](alias-authorization.md) und [Verwenden Sie Tags, um den Zugriff auf KMS-Schlüssel zu steuern](tag-authorization.md).

## Tags oder Aliasse?
<a name="abac-tag-or-alias"></a>

AWS KMS unterstützt ABAC mit Tags und Aliasen. Beide Optionen bieten eine flexible, skalierbare Strategie zur Zugriffssteuerung, unterscheiden sich jedoch geringfügig voneinander. 

Sie können sich entscheiden, Tags oder Aliase zu verwenden, die auf Ihren speziellen AWS Verwendungsmustern basieren. Wenn Sie beispielsweise den meisten Administratoren bereits Markierungs-Berechtigungen erteilt haben, ist es möglicherweise einfacher, eine Autorisierungsstrategie basierend auf Aliasse zu steuern. Oder, wenn Sie nahe am Kontingent für [Aliasse pro KMS-Schlüssel](resource-limits.md#aliases-per-key) sind, verwenden Sie möglicherweise lieber eine Autorisierungs-Strategie, die auf Tags basiert. 

Die folgenden Nutzen sind von allgemeinem Interesse.

**Vorteile einer Tag-basierten Zugriffskontrolle**
+ Derselbe Autorisierungsmechanismus für verschiedene AWS Ressourcentypen. 

  Sie können denselben Tag- oder Tag-Schlüssel verwenden, um den Zugriff auf mehrere Ressourcentypen zu steuern, z. B. einen Amazon-RDS (Amazon Relational Database Service)-Cluster, ein Amazon-EBS (Amazon Elastic Block Store)-Volume und einen KMS-Schlüssel. Diese Funktion ermöglicht verschiedene Autorisierungsmodelle, die flexibler sind als herkömmliche rollenbasierte Zugriffskontrolle.
+ Autorisieren des Zugriffs auf eine Gruppe von KMS-Schlüsseln

  Sie können Tags verwenden, um den Zugriff auf eine Gruppe von KMS-Schlüsseln in demselben AWS-Konto und in derselben Region zu verwalten. Weisen Sie den ausgewählten KMS-Schlüsseln denselben Tag- oder Tag-Schlüssel zu. Erstellen Sie dann eine einfache easy-to-maintain Richtlinienerklärung, die auf dem Tag oder dem Tag-Schlüssel basiert. Um einen KMS-Schlüssel aus Ihrer Autorisierungsgruppe hinzuzufügen oder zu entfernen, fügen Sie das Tag hinzu oder entfernen Sie es. Sie müssen die Richtlinie nicht bearbeiten.

**Vorteile einer Alias-basierten Zugriffskontrolle**
+ Autorisieren Sie den Zugriff auf kryptografische Operationen basierend auf Aliassen.

  Die meisten anforderungsbasierten Richtlinienbedingungen für Attribute, einschließlich [aws:RequestTag/*tag-key*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag), betreffen nur Operationen, die das Attribut hinzufügen, bearbeiten oder löschen. Der RequestAlias Bedingungsschlüssel [kms:](conditions-kms.md#conditions-kms-request-alias) steuert jedoch den Zugriff auf kryptografische Operationen auf der Grundlage des Alias, der zur Identifizierung des KMS-Schlüssels in der Anfrage verwendet wird. Sie können beispielsweise einem Prinzipal die Berechtigung erteilen, einen KMS-Schlüssel in einer `Encrypt`-Operation zu nutzen, aber nur dann, wenn der Wert des `KeyId`-Parameters `alias/restricted-key-1` ist. Diese Bedingung zu erfüllen, erfordert Folgendes:
  + Der KMS-Schlüssel muss diesem Alias zugeordnet sein.
  + Die Anforderung muss den Alias verwenden, um den KMS-Schlüssel zu identifizieren.
  + Der Prinzipal muss über die Berechtigung zur Verwendung des KMS-Schlüssels verfügen, sofern die `kms:RequestAlias`-Bedingung es erlaubt. 

  Dies ist besonders nützlich, wenn Ihre Anwendungen häufig Aliasnamen oder Alias verwenden ARNs , um auf KMS-Schlüssel zu verweisen.
+ Stellen Sie sehr eingeschränkte Berechtigungen bereit.

  Ein Alias muss in einer AWS-Konto UND-Region eindeutig sein. Daher kann es wesentlich restriktiver sein, Prinzipalen Zugriff auf einen KMS-Schlüssel basierend auf einem Alias zu gewähren, als ihnen Zugriff basierend auf einem Tag zu gewähren. Im Gegensatz zu Aliassen können Tags mehreren KMS-Schlüsseln in demselben Konto und derselben Region zugewiesen werden. Wenn Sie auswählen, können Sie ein Aliasmuster verwenden, z. B.`alias/test*`, um Prinzipalen Zugriff auf eine Gruppe von KMS-Schlüsseln in demselben Konto und derselben Region zu gewähren. Allerdings ermöglicht das Erlauben oder Verweigern des Zugriffs auf einen bestimmten Alias eine sehr strenge Kontrolle über KMS-Schlüssel.

# Problembehandlung bei ABAC für AWS KMS
<a name="troubleshooting-tags-aliases"></a>

Die Steuerung des Zugriffs auf KMS-Schlüssel basierend auf ihren Tags und Aliassen ist bequem und leistungsstark. Es ist jedoch anfällig für einige vorhersehbare Fehler, die Sie verhindern möchten.

## Zugriff aufgrund von Tag-Änderung geändert
<a name="access-denied-tag"></a>

Wenn ein Tag gelöscht wird oder sein Wert geändert wird, wird Prinzipalen, dessen Zugriff auf einen KMS-Schlüssel nur auf diesem Tag basiert, der Zugriff auf den KMS-Schlüssel verweigert. Dies kann auch passieren, wenn ein Tag, das in einer Zugriffsverweigerungs-Richtlinienanweisung enthalten ist, einem KMS-Schlüssel hinzugefügt wird. Das Hinzufügen eines richtlinienbezogenen Tags zu einem KMS-Schlüssel kann Prinzipalen den Zugriff erlauben, denen der Zugriff auf einen KMS-Schlüssel verweigert werden soll.

Angenommen, ein Prinzipal hat Zugriff auf einen KMS-Schlüssel basierend auf dem `Project=Alpha`-Tag, z. B. die Berechtigung, die in der folgenden IAM-Richtlinienanweisung bereitgestellt wird. 

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "IAMPolicyWithResourceTag",
      "Effect": "Allow",
      "Action": [
        "kms:GenerateDataKeyWithoutPlaintext",
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:ap-southeast-1:111122223333:key/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "Alpha"
        }
      }
    }
  ]
}
```

------

Wenn das Tag aus diesem KMS-Schlüssel gelöscht wird oder der Tag-Wert geändert wird, hat der Prinzipal keine Berechtigung mehr, den KMS-Schlüssel für die angegebenen Operationen zu verwenden. Dies kann deutlich werden, wenn der Principal versucht, Daten in einem AWS Dienst zu lesen oder zu schreiben, der einen vom Kunden verwalteten Schlüssel verwendet. Um die Änderung des Kennworts nachzuverfolgen, überprüfen Sie Ihre CloudTrail Logs auf [UntagResource Einträge](ct-untagresource.md). [TagResource](ct-tagresource.md)

Um den Zugriff wiederherzustellen, ohne die Richtlinie zu aktualisieren, ändern Sie die Tags auf dem KMS-Schlüssel. Diese Aktion hat minimale Auswirkungen außer für einen kurzen Zeitraum, während sie in allen Bereichen von AWS KMS in Kraft tritt. Um einen Fehler wie diesen zu vermeiden, erteilen Sie Berechtigungen zum Markieren und Entmarkieren nur an Prinzipale, die sie benötigen, und [beschränken Sie ihrer Markierungs-Berechtigungen](tag-permissions.md#tag-permissions-conditions) auf Tags, die sie verwalten müssen. Bevor Sie einen Tag ändern, durchsuchen Sie Richtlinien, um den Zugriff zu erkennen, der vom Tag abhängt, und erhalten Sie KMS-Schlüssel in allen Regionen, die das Tag enthalten. Sie könnten erwägen, einen CloudWatch Amazon-Alarm zu erstellen, wenn bestimmte Tags geändert werden.

## Änderung des Zugriffs aufgrund von Aliasänderungen
<a name="access-denied-alias"></a>

Wenn ein Alias gelöscht oder einem anderen KMS-Schlüssel zugeordnet wird, wird Prinzipalen, dessen Zugriff auf den KMS-Schlüssel nur auf diesem Alias basiert, der Zugriff auf den KMS-Schlüssel verweigert. Dies kann auch passieren, wenn ein Tag, das in einer Zugriffsverweigerungs-Richtlinienanweisung enthalten ist, einem KMS-Schlüssel hinzugefügt wird. Das Hinzufügen eines richtlinienbezogenen Tags zu einem KMS-Schlüssel kann Prinzipalen den Zugriff erlauben, denen der Zugriff auf einen KMS-Schlüssel verweigert werden soll.

In der folgenden IAM-Richtlinienerklärung wird beispielsweise der ResourceAliases Bedingungsschlüssel [kms:](conditions-kms.md#conditions-kms-resource-aliases) verwendet, um den Zugriff auf KMS-Schlüssel in verschiedenen Regionen des Kontos mit einem der angegebenen Aliase zu ermöglichen.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AliasBasedIAMPolicy",
      "Effect": "Allow",
      "Action": [
        "kms:List*",
        "kms:Describe*",
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:*:111122223333:key/*",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "kms:ResourceAliases": [
            "alias/ProjectAlpha",
            "alias/ProjectAlpha_Test",
            "alias/ProjectAlpha_Dev"
          ]
        }
      }
    }
  ]
}
```

------

Um die Aliasänderung nachzuverfolgen, überprüfen Sie Ihre CloudTrail Logs auf [CreateAlias](ct-createalias.md)Einträge [UpdateAlias](ct-updatealias.md), und [DeleteAlias](ct-deletealias.md).

Um den Zugriff wiederherzustellen, ohne die Richtlinie zu aktualisieren, ändern Sie den Alias, der dem KMS-Schlüssel zugeordnet ist. Da jeder Alias nur einem KMS-Schlüssel in einem Konto und einer Region zugeordnet werden kann, ist die Verwaltung von Aliassen etwas schwieriger als die Verwaltung von Tags. Das Wiederherstellen des Zugriffs auf einige Prinzipale auf einem KMS-Schlüssel kann denselben oder anderen Prinzipalen den Zugriff auf einen anderen KMS-Schlüssel verweigern. 

Um diesen Fehler zu vermeiden, erteilen Sie Alias-Verwaltungs-Berechtigungen nur für Prinzipale, die diese benötigen, und [schränken Sie ihre Alias-Verwaltungs-Berechtigungen](alias-access.md#alias-access-limiting) auf Aliasse ein, die sie verwalten müssen. Suchen Sie vor dem Aktualisieren oder Löschen eines Aliasses Richtlinien, um den Zugriff zu erkennen, der vom Alias abhängt, und finden Sie die KMS-Schlüssel in allen Regionen, die dem Alias zugeordnet sind.

## Zugriff aufgrund eines Aliaskontingents verweigert
<a name="access-denied-alias-quota"></a>

Benutzer, die aufgrund einer KMS[: ResourceAliases -Bedingung zur Verwendung eines KMS-Schlüssels](conditions-kms.md#conditions-kms-resource-aliases) autorisiert sind, erhalten eine `AccessDenied` Ausnahme, wenn der KMS-Schlüssel die [Standardaliase pro KMS-Schlüsselkontingent](resource-limits.md#aliases-per-key) für dieses Konto und diese Region überschreitet. 

Um den Zugriff wiederherzustellen, löschen Sie Aliasse, die dem KMS-Schlüssel zugeordnet sind, damit er dem Kontingent entspricht. Oder verwenden Sie einen alternativen Mechanismus, um Benutzern Zugriff auf den KMS-Schlüssel zu gewähren. 

## Verzögerte Autorisierungsänderung
<a name="tag-alias-auth-delay"></a>

Es kann bis zu fünf Minuten dauern, bis sich die Änderungen, die Sie an Tags und Aliassen vornehmen, auf die Autorisierung von KMS-Schlüsseln auswirken. Infolgedessen kann eine Tag- oder Aliasänderung in den Antworten von API-Operationen widergespiegelt werden, bevor sie sich auf die Autorisierung auswirken. Diese Verzögerung ist wahrscheinlich länger als die kurze eventuelle Konsistenzverzögerung, von der die meisten AWS KMS Vorgänge betroffen sind. 

Beispielsweise können Sie eine IAM-Richtlinie verwenden, die es bestimmten Prinzipalen erlaubt, einen KMS-Schlüssel mit einem `"Purpose"="Test"`-Tag zu nutzen. Dann fügen Sie das `"Purpose"="Test"`-Tag einem KMS-Schlüssel hinzu. Obwohl der [TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html)Vorgang abgeschlossen ist und die [ListResourceTags](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListResourceTags.html)Antwort bestätigt, dass das Tag dem KMS-Schlüssel zugewiesen ist, haben die Prinzipale möglicherweise bis zu fünf Minuten lang keinen Zugriff auf den KMS-Schlüssel.

Um Fehler zu vermeiden, bauen Sie diese erwartete Verzögerung in Ihren Code ein. 

## Fehlgeschlagene Anforderungen aufgrund von Alias-Aktualisierungen
<a name="failed-requests"></a>

Sie können Aliasse auch aktualisieren, wodurch ein vorhandenes Alias einem anderen KMS-Schlüssel zugeordnet wird. 

[Entschlüsselungen](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) und [ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html)Anfragen, die den [Aliasnamen oder [Alias-ARN](concepts.md#key-id-alias-ARN)](concepts.md#key-id-alias-name) angeben, schlagen möglicherweise fehl, da der Alias jetzt mit einem KMS-Schlüssel verknüpft ist, der den Chiffretext nicht verschlüsselt hat. Diese Situation gibt in der Regel `IncorrectKeyException` oder `NotFoundException` zurück. Oder wenn die Anforderung keinen `KeyId`- oder `DestinationKeyId`-Parameter enthält, schlägt die Operation möglicherweise mit einer `AccessDenied`-Ausnahme fehl, da der Aufrufer keinen Zugriff mehr auf den KMS-Schlüssel hat, der den Chiffretext verschlüsselt hat. 

Sie können die Änderung nachverfolgen, indem Sie in den CloudTrail Protokollen nach [CreateAlias[UpdateAlias](ct-updatealias.md)](ct-createalias.md), und nach Protokolleinträgen suchen. [DeleteAlias](ct-deletealias.md) Sie können auch den Wert des `LastUpdatedDate` Felds in der [ListAliases](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListAliases.html)Antwort verwenden, um eine Änderung zu erkennen. 

Die folgende Beispielantwort zeigt [ListAliases](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListAliases.html)beispielsweise, dass der `ProjectAlpha_Test` Alias in der `kms:ResourceAliases` Bedingung aktualisiert wurde. Daher verlieren die Prinzipale, dessen Zugriff auf dem Alias basiert, den Zugriff auf den zuvor zugeordneten KMS-Schlüssel. Stattdessen haben sie Zugriff auf den neu zugeordneten KMS-Schlüssel. 

```
$ aws kms list-aliases --query 'Aliases[?starts_with(AliasName, `alias/ProjectAlpha`)]'

{
    "Aliases": [
        {
            "AliasName": "alias/ProjectAlpha_Test",
            "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Test",
            "TargetKeyId": "0987dcba-09fe-87dc-65ba-ab0987654321",
            "CreationDate": 1566518783.394,
            "LastUpdatedDate": 1605308931.903
        },
        {
            "AliasName": "alias/ProjectAlpha_Restricted",
            "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Restricted",
            "TargetKeyId": "1234abcd-12ab-34cd-56ef-1234567890ab",
            "CreationDate": 1553410800.010,
            "LastUpdatedDate": 1553410800.010
        }
    ]
}
```

Die Lösung für diese Änderung ist nicht einfach. Sie können den Alias erneut aktualisieren, um ihn dem ursprünglichen KMS-Schlüssel zuzuordnen. Bevor Sie jedoch handeln, müssen Sie die Auswirkungen dieser Änderung auf den aktuell zugeordneten KMS-Schlüssel berücksichtigen. Wenn Prinzipale den letzteren KMS-Schlüssel in kryptografischen Operationen verwendet haben, müssen sie möglicherweise weiterhin darauf zugreifen. In diesem Fall sollten Sie die Richtlinie aktualisieren, um sicherzustellen, dass Prinzipale über die Berechtigung verfügen, beide KMS-Schlüssel zu verwenden. 

Sie können einen Fehler wie diesen verhindern: Bevor Sie einen Alias aktualisieren, suchen Sie Richtlinien, um den Zugriff zu erkennen, der vom Alias abhängt. Rufen Sie dann KMS-Schlüssel in allen Regionen ab, die dem Alias zugeordnet sind. Erteilen Sie Alias-Verwaltungs-Berechtigungen nur für Prinzipale, die diese benötigen, und [schränken Sie ihre Alias-Verwaltungs-Berechtigungen](alias-access.md#alias-access-limiting) auf Aliasse ein, die sie verwalten müssen.