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.
Problembehandlung bei ABAC für AWS KMS
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
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.
{ "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. TagResource
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 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
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: verwendet, um den Zugriff auf KMS-Schlüssel in verschiedenen Regionen des Kontos mit einem der angegebenen Aliase zu ermöglichen.
{ "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 CreateAliasEinträge UpdateAlias, und DeleteAlias.
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 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
Benutzer, die aufgrund einer KMS: ResourceAliases -Bedingung zur Verwendung eines KMS-Schlüssels autorisiert sind, erhalten eine AccessDenied Ausnahme, wenn der KMS-Schlüssel die Standardaliase pro KMS-Schlüsselkontingent 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
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 TagResourceVorgang abgeschlossen ist und die ListResourceTagsAntwort 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
Sie können Aliasse auch aktualisieren, wodurch ein vorhandenes Alias einem anderen KMS-Schlüssel zugeordnet wird.
Entschlüsselungen und ReEncryptAnfragen, die den Aliasnamen oder Alias-ARN 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 CreateAliasUpdateAlias, und nach Protokolleinträgen suchen. DeleteAlias Sie können auch den Wert des LastUpdatedDate Felds in der ListAliasesAntwort verwenden, um eine Änderung zu erkennen.
Die folgende Beispielantwort zeigt ListAliasesbeispielsweise, 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 auf Aliasse ein, die sie verwalten müssen.
